Материалы представленные на сайте исключительно с целью ознакомления пользователям Интернета и не преследуют коммерческих целей или нарушение авторских прав.
© 2018 - 2024
А1. Определить цели управленческого учета.
На этом этапе разрабатывается методология управленческого учета, которая контролирует следующие этапы. От его организации во многом зависит успешность процесса управленческого учета в целом.
А11. На первом этапе декомпозиции руководством определяется стратегия управленческого учета на основе потребностей в управленческой информации. Его задача – формализовать потребности и увязать их со стратегией предприятия.
А12. На следующем этапе определяются ресурсы для реализации стратегии управленческого учета, оценивается эффективность стратегии с точки зрения затрат имеющихся ресурсов и необходимость привлечения дополнительных ресурсов.
А13. На третьем этапе стратегия трансформируется в конкретные приемы и методы ведения управленческого учета с учетом ресурсов, имеющихся в распоряжении предприятия.
А2. Собрать и обработать данные.
На этом этапе готовятся данные, составляющие основу управленческой информации.
А21. Данные собираются и вводятся в информационную систему непосредственно центрами ответственности, что обеспечивает оперативность поступления информации. Состав данных, аналитические признаки и сроки их учета определяются методологией.
А22. По мере поступления первичных документов бухгалтерия подтверждает данные в информационной системе. В случае расхождений данные корректируются на основе первичных документов. Подтвержденные данные используются для составления финансовой отчетности.
А23. Данные в информационной системе распределяются по объектам учета и центрам ответственности. При наличии достаточной аналитики это осуществляется автоматически.
A3. Подготовить управленческую отчетность
На этом этапе формируется управленческая отчетность. При хорошо разработанной методологии отчетность может формироваться автоматически. Роль финансовой функции как механизма зависит от возможностей информационной системы.
A31. Распределение данных по объектам учета и центрам ответственности позволяет сформировать отчетность в разрезе центров ответственности. Форма отчетов и сроки их представления определяются методологией.
А32. Сводная отчетность формируется на основе консолидации отчетности центров ответственности и других обработанных данных. В части подтвержденных данных контрольные функции выполняет финансовая отчетность.
АЗЗ. Отчетность по требованию также основана на обработанных данных. Поскольку ее формы не предусмотрены методологией, они предварительно разрабатываются соответствующими подразделениями.
7.3. Применение структурного анализа
в проектировании информационных систем
Специфика проектирования информационных систем опирается на стандартные технологии поддержки жизненного цикла информационной системы.
Одним из путей совершенствования любого процесса является систематизация. С этой целью процесс делится на определенное число взаимосвязанных этапов. Их методичное и последовательное выполнение в соответствии с принятой технологией способствует значительному повышению эффективности по сравнению со стихийным продвижением к поставленной цели. Проектирование невозможно без творческой составляющей и не подразумевает полной автоматизации, однако создание четкого алгоритма, общей структуры процесса необходимо для облегчения рутинной работы.
SADT (Structured Analysis and Design Technique) – технология структурного анализа и проектирования – широко используется во многих областях начиная с 1973 г. Обычно SADT применяется на ранних стадиях создания системы для минимизации возможных ошибок, исправление которых на стадии проектировании обходится гораздо дешевле, чем во время функционирования системы. SADT-методология нашла свое применение в создании программного обеспечения, долгосрочном стратегическом планировании, обучении персонала, автоматизированном производстве, управлении финансами и т. д.
Уже на начальном этапе SADT-моделирования мы задаем цели, которые необходимо достичь, определяем исполнителей, указываем имеющиеся исходные данные и ресурсы, а также различного рода ограничения.
Любой процесс может быть описан с различной степенью детализации. Таким образом, схемы разных уровней являются расшифровкой элементов более общих схем и подробно описывают тот или иной этап.
Результаты некоторых стадий могут стать руководством к действию для последующих этапов. Возможны также обратные связи: при промежуточной оценке результатов принимаются решения о корректировке некоторых процессов, что приводит к изменению стратегии моделирования и новому планированию работ.
Стрелки (дуги) могут разветвляться и соединяться. При разъединении дуг агрегируются и интегрируются информационные механизмы реализации некоторых процессов. Соединение дуг подчеркивает общий результат.
Выводы. Анализируя построенные схемы и детализируя их в соответствии с текущими задачами, мы можем структурировать весь процесс проектирования информационной системы, составить план работы для каждого специалиста, привязать каждый этап к временным ограничениям. Но самое главное – структура и цели создаваемой информационной системы представляются как единый механизм, что необходимо для понимания конкретных функциональных задач предприятий.
ГЛОССАРИЙ
Анализ функций – методика анализа исполнения функций предприятия.
Бизнес-процесс – модель преобразования сущностей типа «вход – выход», понимаемая как работа по реализации приписываемой функции.
Бизнес-процесс-реинжиниринг (БПР) – методика кардинальной реструктуризации бизнес-процессов.
Бизнес-функция (Business-function) – термин, используемый для описания того, что в процессе функционирования организации выполняются те или иные действия. IDEF0 обеспечивает поддержку моделирования бизнес-функций посредством нотации, использующей действия и стрелки.
Вертикальное сжатие бизнес-процессов – объединение нескольких разноуровневых рабочих процедур в одну.
Внешняя среда – существенно важные объекты вне системы.
Вход (Input arrow) – стрелка, входящая в левую часть блока диаграммы IDEF0. Вход обозначает сырье или информацию, потребляемые действием, обозначенным данным блоком, которые необходимы для получения выхода.
Выход (Output arrow) – стрелка, выходящая из правой стороны блока диаграммы IDEF0. Выход обозначает изделия или информацию, полученные в результате выполнения действия, обозначенного блоком.
Горизонтальное сжатие бизнес-процессов – объединение нескольких одноуровневых рабочих процедур в одну.
Границы моделирования (Scope) – ширина охвата и глубина детализации при описании моделируемого набора объектов.
Действие (Activity) – описание набора мероприятий, имеющих целью обработку или передачу либо данных, либо ресурсов (например, «обработать заказ» или «провести технический контроль»). Модели IDEF0 выделяют неэффективные действия (у которых отсутствует управление или выход) и, таким образом, способствуют работе по проведению реинжиниринга бизнес-процессов. Действие в модели IDEF3, называемое также единицей работы, описывает обработку, мероприятие, принятие решения или другую процедуру, выполняемую системой или организацией. Действия в диаграммах DFD отображают обработку или передачу данных.
Динамическое бизнес-моделирование – методики и средства, описывающие изменение инжиниринговых моделей во времени.
Изменения организационной модели – сокращения и добавления продуктов, функций, звеньев в организационной модели предприятия, перераспределение ответственности звеньев за исполнение функции.
Изменения модели бизнес-процессов – сокращения, добавления, изменения образующих бизнес-процессы работ, изменение сетевой модели образующих бизнес-процессы работ, перераспределение ответственности звеньев за исполнение бизнес-процессов.
Команда процесса – выделенная группа менеджеров и специалистов, ответственная за реализацию процесса.
Количественные модели бизнес-инжиниринга – количественные описания инжиниринговых моделей предприятия.
Логистика – 1. Отрасль науки – совокупность самостоятельной методологии, теории, методов и способов оптимизации всех видов потоков (физических, информационных, энергетических и т. д.), сопровождающих экономические, социальные и коммуникативные процессы в сфере создания, воспроизводства и потребления товаров и услуг в условиях функционирования и развития рыночных отношений. 2. Теория планирования, управления и контроля процессов движения материальных, трудовых, энергетических и информационных потоков в человеко-машинных системах. 3. Совокупность теории и практики анализа и оптимизации перемещения продукта и сопровождающих его потоков в сфере производства и обращения товара.
Менеджмент – 1. Совокупность функций, необходимых для организации любой деятельности на том или ином иерархическом уровне рыночной экономики. 2. Форма описания, представления деятельности и роли отдельного лица или группы лиц, которые ставят и контролируют задачи по управлению процессами организации, планирования, координации и контроля в той или иной области воспроизводства или экономики в целом. 3. Наука управления рыночной экономикой, включающая теорию систем, теорию решений, социальную психологию, социологию, психологию, математику и др. 4. Руководство фирмы, возглавляющее процесс организации и функционирования производства и ответственное за результаты деятельности и выживаемость фирмы в условиях конкурентной борьбы. 5. Управление экономикой, производством, персоналом, ресурсами и т. д. в условиях рынка.
Метаструктура – устойчивые связи различающихся структур.
Механизм исполнения (Mechanism arrow) – стрелка, входящая в блок диаграммы IDEF0 снизу и обозначающая персонал, оборудование и другие не потребляемые в процессе функционирования ресурсы, используемые для выполнения действия, обозначаемого блоком.
Организация менеджмента – формирование и поддержание функциональных структур и бизнес-процессов предприятия.
Организационная культура – «мягкая» структура предприятия, проявляющаяся в виде корпоративных ценностей, ожиданий, норм поведения, «правил игры», поведенческих ритуалов, психологического климата, существующих на предприятии.
Организационная реструктуризация – изменение организационной модели предприятия.
Организационная структура – отражение функций, исполнительных звеньев и устойчивых связей между ними.
Подсистема – часть системы, образованная компонентами.
Программа действий по управлению изменениями – систематизированное представление управляющих воздействий (кто, что, когда, сколько) для программы реструктуризации предприятия.
Проектирование функциональной модели – методика определения иерархического упорядочивания необходимых функций предприятия.
Реинжиниринг – фундаментальное переосмысление и радикальное перепроектирование бизнес-процессов компаний для достижения коренных улучшений в основных показателях их деятельности: стоимость, качество, услуги и темпы и т. д.
Реструктуризация – изменение структуры предприятия.
Реструктуризация бизнес-процессов – изменение модели бизнес-процессов предприятия.
Стратегия – модель целей и способов их реализации.
Стратегический анализ – модель представления и анализа информации для принятия стратегических решений.
Стрелка (Arrow): стрелка на диаграмме IDEF0 представляет вход, управление, выход или механизм выполнения действия. На диаграммах IDEF3 стрелки обозначают порядок выполнения действий (стрелки, нарисованные сплошной линией), отношения (стрелки, нарисованные прерывистой линией) или поток (двухконечные стрелки, нарисованные сплошной линией). В DFD стрелка обозначает поток данных между действиями, хранилищами данных и внешними ссылками.
Структура процессов – отражение компонентов процессов и устойчивых связей между ними.
Функция – обособленный устойчивый вид деятельности.
Функциональная область – обладающая целостностью совокупность функций, выполняемых подразделениями.
Функциональная структура – отражение функций и устойчивых связей между ними.
Функциональные стратегии – документированные цели в функциональной области (продукты, бизнес-процессы, менеджмент, ресурсы) и систематизированные суждения о способах их достижения.
Управление (Control arrow) – ограничение для блока диаграммы IDEF0, определяющее, как, когда и при каких условиях выполняется действие, обозначенное этим блоком. Это правила, стандарты, законы, должностные инструкции и т. п. Стрелки, обозначающие управление, входят в блок диаграммы IDEF0 сверху.
Управленческий анализ – сложившийся систематизированный набор методик представления и анализа информации для принятия управленческих решений (маркетинговый анализ, финансово-экономический анализ, операционный анализ и т. д.).
IDEF0 – стандарт моделирования, поддерживающий графическое описание бизнес-функций как набора взаимозависимых действий и информации о ресурсах, необходимых для каждого действия. Назначение модели IDEF0 состоит в документировании и пересмотре назначения и состава функций для повышения эффективности функционирования организации.
IDEF3 – стандарт моделирования бизнес-процессов, поддерживающий графическое описание непосредственного механизма функционирования системы или организации. IDEF3 содержит правила разработки двух видов сетевых диаграмм: диаграмм потоков для бизнес-процессов и диаграмм изменения состояния объекта.
Orgware – методики и программное обеспечение для описания и проектирования структур.
Workflow – методики и программное обеспечение для описания и проектирования бизнес-процессов.
РЕКОМЕНДУЕМАЯ ЛИТЕРАТУРА
Основная литература
1. Маклаков С.В. Моделирование бизнес-процессов с BPwin 4.0. – М. : ДИАЛОГ-МИФИ, 2002. – 224 с.
2. Маклаков С.В. BPwin, ERwin. CASE-средства разработки информационных систем. – М. : ДИАЛОГ-МИФИ, 1999. – 256 с.
3. Структурный анализ систем: IDEF-технологии / С.В. Черемных, И.О. Семенов, B.C. Ручкин. – М. : Финансы и статистика, 2003. – 208 с. : ил. – (Прикладные информационные технологии).
Дополнительная литература
1. Бизнес-процессы: Регламентация и управление : учебник. – М. : Инфра-М, 2005. – 319 с. – (Учебники для программы МВА).
2. Вёндров А.М. CASE-технологии – современные методы и средства проектирования информационных систем. – М. : Финансы и статистика, 1998.
3. Ойхман Е.Г., Попов Э.В. Реинжиниринг бизнеса. – М. : Финансы и статистика, 1997.
4. Калянов Г.Н. CASE. Структурный системный анализ (автоматизация и применение). – М. : Лори, 1996.
5. Хаммер М., Чампи Дж. Реинжиниринг корпорации: манифест революции в бизнесе : пер. с англ. – СПб. : Изд-во С.-Петербург. ун-та, 1997.
6. Тельнов Ю.Ф. Реинжиниринг бизнес-процессов : учеб. пособие. – М. : Московский государственный университет экономики, статистики, информатики, 1999.
7. Буч Г. Объектно-ориентированное проектирование с примерами применения : пер. с англ. – М. : Конкорд, 1992.
8. Васкевич Д. Стратегии клиент/сервер. Руководство по выживанию для специалистов по реорганизации бизнеса. – Киев : Диалектика, 1996.
9. Зиндер Е.З. Бизнес-реинжиниринг и технологии системного проектирования : учеб. пособие. – М. : Центр информационных технологий, 1996.
10. Кравченко В.Ф., Кравченко Е.Ф., Забелин П.В. Организационный реинжиниринг. Учебное пособие для вузов. – М. : Приор, 1999.
11. Фишер Л. Совершенство на практике. Лучшие проекты в области управления бизнес-процессами и Workflow. – М. : Весть-Ме-татехнология, 2000.
12. Мильнер Б.З. Теория организаций. – М. : Инфра-М, 1998.
13. Попов Э.В. Бизнес-процесс «Реинжиниринг» и интеллектуальное моделирование компаний // Статические и динамические экспертные системы : учеб. пособие. – М. : Финансы и статистика, 1996.
14. Робсон М., Уллах Ф. Практическое руководство по реинжинирингу бизнес-процессов : пер. с англ. / под ред. Н.Д. Эриашвили. – М. : ЮНИТИ, 1997.
15. Росс Д. Структурный анализ: язык для передачи понимания // Требования и спецификации в разработке программ. – М. : Мир, 1984.
16. Черемных С.В. Материалы по изучению курса «Моделирование бизнес-процессов». – М. : Финансовая академия при Правительстве РФ, 2000.
17. Марка Д.А., МакГоуэн К. SADT-методология структурного анализа и проектирования. – М. : Метатехнология, 1993.
Приложение 1
Семейство стандартов IDEF
Применяемые в CASE-средствах разные методики и модели описывают различные свойства систем, важные, например, с точки зрения их автоматизации, а также позволяющие количественно оценить параметры проектов. Следует отметить, что спектр свойств систем различного назначения очень широк, и не все они к настоящему времени отражены в адекватных моделях. В то же время для класса информационных систем организационного типа (Management Information Systems – MIS) адекватные модели разработаны и поддерживаются соответствующими средствами автоматизации.
Взаимная совокупность методик и моделей концептуального проектирования IDEF (Integrated DEFinition) разработана в США по программе Integrated Computer-Aided Manufacturing. В настоящее время имеются методики функционального, информационного и поведенческого моделирования и проектирования, в которые входят IDEF-модели, приведенные в табл. П1.
Таблица П1
Методики IDEF-моделирования
| Название | Назначение |
| IDEF0 | Функциональное моделирование (Function Modeling Method) |
| IDEF1, IDEFlX | Информационное моделирование (Information and Data Modeling Method) |
| IDEF2 | Поведенческое моделирование (Simulation Modeling Method) |
| IDEF3 | Моделирование деятельности (Process Flow and Object Stale Description Capture Method) |
| IDEF4 | Объектно-ориентированное проектирование (Object-oriented Design Method) |
| IDEF5 | Систематизация объектов приложения (Ontology Description Capture Method) |
| IDEF6 | Использование рационального опыта проектирования (Design Rational Capture Method) |
| IDEF8 | Взаимодействие человека и системы (Human-System Interaction Design) |
| IDEF9 | Учет условий и ограничений (Business Constraint Discovery) |
| IDEF14 | Моделирование вычислительных сетей (Network Design) |
IDEF0 реализует методику функционального моделирования сложных систем. Наиболее известной реализацией IDEF0 является методология SADT (Structured Analysis and Design Technique), предложенная в 1973 г.
Д. Россом и впоследствии ставшая основой стандарта IDEF0. Эта методика рекомендуется для начальных стадий проектирования сложных искусственных систем управления, производства, бизнеса, включающих людей, оборудование, программное обеспечение.
IDEF1Х, IDEF1 реализуют методики инфологического проектирования баз данных.
В IDEF1X имеется ясный графический язык для описания объектов и отношений в приложениях, так называемый язык диаграмм «сущность – связь» (ERD – Entity-Relations Diagrams) Разработка информационной модели по IDEF1X выполняется в несколько этапов:
- выясняются цели проекта, составляется план сбора информации, при этом обычно исходные положения для информационной модели следуют из IDEF0-модели;
- выявляются и определяются основные сущности – элементы базы данных, в которых будут храниться данные системы;
- выявляются и определяются основные отношения, результаты представляются графически в виде так называемых ER-диаграмм;
- детализируются нестандартные отношения, определяются ключе- вые атрибуты сущностей. Детализация отношений заключается в замене связей «многие ко многим» на связи «многие к одному» и «один ко многим»;
- определяются атрибуты сущностей.
IDEF2 и IDEF3 реализуют поведенческое моделирование. Если методика IDEF0 связана с функциональными аспектами и позволяет отвечать на вопрос: «Что делает система?», то в этих методиках детализируется ответ: «Как система это делает». В основе поведенческого моделирования лежат модели и методы имитационного моделирования систем массового обслуживания, сети Петри, возможно применение модели конечного автомата, описывающей поведение системы как последовательность смен состояний.
Перечисленные методики относятся к так называемым структурным методам.
IDEF4 реализует объектно-ориентированный анализ больших систем. Он предоставляет пользователю графический язык для изображения классов, диаграмм наследования, таксономии методов.
IDEF5 направлен на представление онтологической информации приложения в удобном для пользователя виде. Для этого используются символические обозначения (дескрипторы) объектов, их ассоциаций, ситуаций и схемный язык описания отношений классификации, «часть – целое», перехода и т. п. В методике имеются правила связывания объектов (термов) в предложения и аксиомы интерпретации термов.
IDEF6 направлен на сохранение рационального опыта проектирования информационных систем, что способствует предотвращению структурных ошибок.
IDEF8 предназначен для проектирования диалогов человека и технической системы.
IDEF9 предназначен для анализа имеющихся условий и ограничений (в т. ч. физических, юридических, политических) и их влияния на принимаемые решения в процессе реинжиниринга.
IDEF14 предназначен для представления и анализа данных при проектировании вычислительных сетей на графическом языке с описанием конфигураций, очередей, сетевых компонентов, требований к надежности и т. п.
Приложение 2
Нотации моделирования
Рассмотрим основные виды моделей, необходимые для адекватного представления сложной системы, характеризуемой структурой, выполняемыми процессами (функциями), поведением системы во времени.
Для моделирования всех этих аспектов применяют функциональные, информационные и поведенческие модели, пересекающиеся друг с другом.
Функциональная модель системы описывает совокупность выполняемых системой функций, характеризует морфологию системы (ее построение) – состав подсистем, их взаимосвязи.
Информационная модель отображает отношения между элементами системы в виде структур данных (состав и взаимосвязи).
Поведенческая (событийная) модель описывает информационные процессы (динамику функционирования), в ней фигурируют такие категории, как состояние системы, событие, переход из одного состояния в другое, условия перехода, последовательность событии. Используется в основном для систем реального времени.
Сочетания типов моделей образуют стандартные CASE-модели.
На рынке программных продуктов имеется много CASE-средств для концептуального проектирования систем, поддерживающих перечисленные модели. Чаще всего речь идет о поддержке методологии IDEF. В России достаточно широко известны продукты BPwin, ERwin, OOwin фирмы Platimmi, Design/IDEF фирмы Meta Software, «CASE-аналитик» фирмы «Эйтэкс», Silverun фирм CSA, Paradigm Plus и др.
Система BPwin предназначена для разработки функциональных моделей по методике IDEF0.
Система ERwin служит для разработки информационных моделей по методике IDEF1X. Имеются средства, обеспечивающие интерфейс с серверами баз данных (от пользователя скрыто общение с ними на языке SQL), перевод графических изображений ER-диаграмм в SQL-формы или в форматы других популярных СУБД. В систему включены также типичные для CASE средства разработки экранных форм.
Система OOwin служит для поддержки объектно-ориентированных технологий анализа и проектирования систем.
Приложение 3
Структурный и объектно-ориентированный подход
Наиболее известная модель бизнеса – иерархическая структура предприятия. Эта модель совершенно недостаточна для того, чтобы спроектировать и (или) изменить предприятие. Вместо этого нужны модели, показывающие предприятие в связке с его клиентами, поставщиками, партнерами, то есть модели, которые представляют бизнес-процессы предприятия и то, как оно производит товары и услуги для внешнего мира.
Понять, как работает предприятие, значит провести работу по обратному инжинирингу. Обычно это делается для того, чтобы получить прочную основу для кардинального улучшения различных аспектов предприятия в будущем. Модель существующего предприятия важна и тогда, когда необходимо понять и объяснить, как функционирует предприятие или некоторый процесс. Например, если требуется при помощи реинжиниринга существенно улучшить временные характеристики, модель может выявлять узкие места, необходимые ресурсы и затраты на различных этапах процесса. Однако построение модели существующего предприятия дорого и требует много времени. В такой модели трудно добиться согласия. Следовательно, очень важно с самого начала определить, что следует моделировать и насколько подробно. Другими словами, ключ к решению проблемы – это правильное сужение поля деятельности. Следует сосредоточить внимание на тех частях бизнеса, которые должны быть радикально улучшены в результате реинжиниринга, то есть важно проявить прагматизм и моделировать только то, что имеет значение для решения задачи реинжиниринга.
Описание предприятия – это работа по прямому инжинирингу, которая начинается с формулирования целей и видения будущей характеристики предприятия. После этого набрасываются различные сценарии. Для каждого сценария создается описание процесса, включающее взаимодействие с заказчиками, поставщиками и т. д. Далее проводится имитационное моделирование различных процессов – при помощи деловой игры или компьютерной модели. Наконец, выбранная альтернатива реализуется.
Дата: 2019-03-06, просмотров: 212.