Основная цель реинжиниринга бизнес-процессов в терминах IDEF0 заключается в построении модели TO-BE («как будет»). Естественно предположить, что данная модель базируется на реальном положении дел (AS-IS). Однако в отличии от модели AS-IS, модель TO-BE носит предписывающий характер. В ней должны быть учтены и исправлены все недостатки, выявленные в процессе анализа модели AS-IS. Очевидно, что процесс построения обеих моделей носит итерационный характер и подчиняется одинаковым правилам моделирования.
В общем случае процесс моделирования включает сбор информации об исследуемой области, документирование полученной информации и представление ее в виде модели, а также уточнение модели посредством итеративного рецензирования. Кроме того, этот процесс подсказывает вполне определенный путь выполнения согласованной и достоверной структурной декомпозиции, что является ключевым моментом в квалифицированном анализе деятельности организации.
В определенном смысле моделирование объединяет итеративный процесс создания модели, нотации, управляющие конфигурацией модели, язык ссылок для диаграмм, язык функций моделей с графическим языком описания системы, а также рекомендации по реализации аналитических проектов. Нотации, управляющие конфигурацией, гарантируют, что новые диаграммы будут корректно встроены в иерархическую структуру модели. Язык ссылок, правила сокращений для ссылок, адресованных к отдельным частям диаграммы, облегчают оформление замечаний при рецензировании модели. Язык функций позволяет декларативно определять правила работы системы, что часто является особенно важным завершающим шагом в описании системы.
Высокая эффективность процесса моделирования обусловлена его организацией, в основе которой лежит разделение функций, выполняемых участниками создания проектов: эксперты являются источниками информации, авторы создают диаграммы и модели, библиотекарь координирует обмен письменной информацией, читатели рецензируют и утверждают модели, а комиссия технического контроля принимает и утверждает модель.
В процессе моделирования сведения об изучаемой системе получают с помощью методов экспертного опроса.
Для получения наиболее полной информации используются различные ее источники (например, чтение документов, опрос экспертов, наблюдение за работой организации). Независимо от конкретного источника информации необходимо определить свои потребности в информации прежде, чем выбрать этот источник. Во время опроса графический язык используется как средство для заметок, которые служат основой для построения диаграмм.
На рис. 39 изображен процесс моделирования, описанный с помощью IDEF0 -диаграммы. Диаграмма отражает тот факт, что процесс моделирования является итеративной последовательностью шагов, приводящих к точному описанию системы.
Создание модели (блок 2 на рис. 34) - это второй важный этап в процессе моделирования, на котором аналитик документирует полученные им знания о данной предметной области, представляя их в виде одной или нескольких диаграмм. Процесс создания модели осуществляется с помощью специального метода детализации ограниченного субъекта. Автор вначале анализирует объекты, входящие в систему, а затем использует полученные знания для анализа функций системы. На основе этого анализа создается диаграмма, в которой объединяются сходные объекты и функции. Этот конкретный путь проведения анализа и документирования его результатов является особенностью всего процесса моделирования.
Моделирование – инженерная дисциплина. Это означает, что модели создаются исходя из действительной ситуации и что эти модели проходят через серию последовательных улучшений до тех пор, пока они в точности не будут представлять реальный мир. Одним из основных компонент при этом является итеративное рецензирование, в процессе которого автор и эксперт многократно совещаются (устно и письменно) относительно достоверности создаваемой модели. Итеративное рецензирование называется циклом «автор-читатель».
Рис.34. Процесс моделирования
Цикл «автор-читатель» начинается в тот момент, когда автор принимает решение распространить информацию о какой-либо части своей работы с целью получения отзыва о ней. Материал для распространения оформляется в виде «папок» - небольших пакетов с результатами работы, которые критически обсуждаются другими специалистами в течение определенного времени. Сделанные письменные замечания также помещаются в папку в виде нумерованных комментариев. Папки с замечаниями являются, таким образом, обратной связью, которую авторы получают на свою работу. Читатели - это те, кто читает и критикует создаваемую модель (блок 4 на рис. 34), а затем помещает замечания в папки. Их работа возможна благодаря тому, что графический язык диаграмм позволяет создавать диаграммы и модели, которые можно легко и быстро читать. Простота графического языка потому не случайна. Она позволяет получить представление о системе, на основе которого можно дать обоснованное заключение о достоверности модели.
Обычно отдельная папка рецензируется одновременно несколькими читателями, и все их замечания поступают к определенному сроку к автору. Затем автор отвечает на каждое замечание и обобщает критику, содержащуюся в замечаниях. С помощью таких обсуждений можно достаточно быстро обмениваться идеями. Таким образом, поддерживается как параллельный, так и асинхронный просмотр модели, что является наиболее эффективным способом распределения работы в коллективе.
Как правило, модель редко создается одним автором. На практике над различными частями модели могут совместно работать множество авторов, потому что каждый функциональный блок модели представляет отдельный субъект, который может быть независимо проанализирован и декомпозирован. Таким образом, модель сама координирует работу коллектива авторов, в то время как процесс моделирования координирует совместное рецензирование возникающих идей.
Организация своевременной обратной связи имеет важнейшее значение для эффективного моделирования, потому что устаревшая информация потенциально способна свести на нет все усилия по разработке модели. Поэтому выделяется специальная роль наблюдателя за процессом рецензирования. На рис.25 показано, что эту роль выполняет библиотекарь, который является главным координатором процесса моделирования, обеспечивая своевременное и согласованное распространение рабочих материалов. Библиотекарь распространяет полученные от авторов папки, контролирует их движение, рассылает напоминания о своевременном возвращении авторам папок с замечаниями и о сроках ответов авторов на предложения читателей. Кроме того, библиотекарь печатает законченные модели после того, как они одобрены и приняты к использованию.
Модели создаются с конкретной целью, и эта цель записана на диаграмме А-0 модели. В каком-то смысле эта цель определяет, как будет использоваться модель. Следовательно, как только завершено создание модели с требуемым уровнем детализации и модель проверена, она может применяться для достижения поставленной цели. Например, для обеспечения и поддержания реинжиниринга бизнес-процессов организации.
В процессе моделирования рекомендуется выделить специальную группу людей, ответственных за то, что создаваемая в процессе анализа модель будет точна и используема в дальнейшем. Эта группа, называемая условно комиссией технического контроля (блок 5 на рис. 34), отвечает за контроль качества моделей, создаваемых авторами проекта. Комиссия следит за выполняемой работой и ее соответствием конечным целям всего проекта. Специалисты комиссии обсуждают модель и оценивают, насколько она может быть использована и будет использована соответствующим образом в ходе выполнения проекта для достижения его глобальных целей.
Таким образом, комиссия технического контроля находится в наиболее выгодном положении при определении текущего направления развития проекта и выработке предложений по его корректировке. Модели, которые достигли желаемого уровня детализации и точности с точки зрения технических требований, направляются в комиссию технического контроля для обсуждения и утверждения. Комиссия оценивает, насколько применима данная модель. Если модель признана комиссией применимой, она публикуется. В противном случае авторам направляются замечания для необходимой доработки.
Лабораторная работа №9. Функционально-стоимостной анализ (Activity Based Costing)
Функционально-стоимостной анализ(ФСА) — метод определения стоимости и других характеристик изделий, услуг и потребителей, в основе которого лежит использование функций и ресурсов, задействованных в производстве, маркетинге, продаже, доставке, технической поддержке, оказании услуг, обслуживании клиентов, а также в обеспечении качества.
Метод ФСА разработан как «операционно-ориентированная» альтернатива традиционным финансовым подходам. В частности, в отличие от традиционных финансовых подходов метод ФСА:
· предоставляет информацию в форме, понятной для персонала предприятия, непосредственно участвующего в бизнес-процессе;
· распределяет накладные расходы в соответствии с детальным просчетом использования ресурсов, подробным представлением о процессах и функциях их составляющих, а также их влиянием на себестоимость.
В основе применения метода ФСА лежит разработка и применение на практике ФСА-моделей. Цель создания ФСA-модели для совершенствования деятельности предприятий — достичь улучшений в работе предприятий по показателям стоимости, трудоемкости и производительности. Проведение расчетов по ФСА-модели позволяет получить большой объем информации для принятия решения. При этом данная информация, особенно взаимосвязи отдельных ее элементов, для лиц, принимающих решения, является, как правило, неожиданной. Полученная информация позволяет обосновывать и принимать решения в процессе применения других методов совершенствования финансово-хозяйственной деятельности организации. Основные направления использования ФСА-модели для реорганизации бизнес-процессов — это повышение производительности, снижение стоимости, трудоемкости, времени и повышение качества.
Функционально-стоимостной анализ позволяет выполнить следующие виды работ:
· формирование релевантной информации об эффективности деятельности центров ответственности на предприятии;
· определение и проведение общего анализа себестоимости бизнес-процессов на предприятии (маркетинг, производство продукции и оказание услуг, сбыт, менеджмент качества, техническое и гарантийное обслуживание и др.);
· проведение сравнительного анализа и обоснование выбора рационального варианта технологии реализации бизнес-процессов;
· проведение функционального анализа, связанного с установлением и обоснованием выполняемых структурными подразделениями предприятий функций с целью обеспечения выпуска высокого качества продукции и оказания услуг;
· определение и анализ основных, дополнительных и ненужных функциональных затрат;
· сравнительный анализ альтернативных вариантов снижения затрат в производстве, сбыте и управлении за счет упорядочения функций структурных подразделений предприятия;
· анализ интегрированного улучшения результатов деятельности предприятия и др.
Построение функционально-стоимостных моделей осуществляется на основе применения методологической и технологической взаимосвязи между IDEF0 - и ФСА-моделями.
Связанность методов IDEF0 и ФСА заключается в том, что оба метода рассматривают финансово-хозяйственную деятельность предприятия как множество последовательно выполняемых функций, а дуги входов, выходов, управления и механизмов функций IDEF0 -модели соответствуют стоимостным объектам и ресурсам ФСА-модели.
На уровне функционального блока связь IDEF0 - и ФСА-моделей базируется на трех принципах:
1. Функция характеризуется числом, которое представляет собой стоимость или время выполнения этой функции.
2. Стоимость или время функции, которая не имеет декомпозиции, определяется разработчиком модели.
3. Стоимость или время функции, которая имеет декомпозицию, определяется как сумма стоимостей (времен) всех подфункций на данном уровне декомпозиции.
Следует отметить, что в AllFusion Process Modeler реализован упрощенный вариант ФСА. В то же время в программном продукте EasyABC ФСА реализован полностью, но в явном виде программная поддержка взаимосвязи между IDEF0 -моделью и EasyABC поддерживается только путем экспорта диаграммы Node Tree.
Исходные данные для ФСА
На производственном участке работают 5 сборщиков и 1 тестировщик.
В среднем в день собирается 12 настольных компьютеров и 20 ноутбуков.
Двое сборщиков - стажеры.
Зарплата диспетчера - 500$ в месяц, сборщиков и тестировщиков - 10$ в час, стажеров - 3$ в час.
Средняя стоимость компонент для настольного компьютера - 800$, для ноутбука -1400$.
1. В диалоге Model Properties (вызывается из меню Model) в закладке ABC Units установите единицы измерения денег и времени.
2. Перейдите в Model/Cost Center Editor... и вдиалоге Cost Center Editor внесите название и определение центров затрат (табл. 7).
Таблица 7
Описание центров затрат
| Центр затрат Определение | |
| Управление | Затраты на управление, связанные с составлением графика работ, формированием партий компьютеров, контролем над сборкой и тестированием |
| Рабочая сила | Затраты на оплату рабочих, занятых сборкой и тестированием компьютеров |
| Компоненты | Затраты на закупку компонент |
3. Для внесения центра затрат наберите наименование, определение и щелкните по кнопке Add.
Стоимость каждой работы отображается в нижнем левом углу прямоугольника.
Для отображения частоты или продолжительности работы перейдите в диалог Model Properties (закладка Display), и переключите радиокнопки в группе ABC Units. Можно вообще отключить режим отображения информации об ABC, отключив опцию Activity Cost/Freq/Dur. в диалоге Model Properties или меню View.
4. Для назначения стоимости работе следует щелкнуть по ней правой кнопкой мыши и выбрать в контекстном меню Cost Editor.
5. По табл. 8 внесите параметры ABC.
Таблица 8
Исходные данные для ФСА
| Activity Name Cost Center Cost Center Duration (Days) Frequency | ||||
| Cost ($ U.S.) | ||||
| Отслеживание расписания и управление сборкой и тестированием | Управление | 25,00 | 1,00 | 1,00 |
| Сборка настольных компьютеров | Рабочая сила | 5,00 | 1,00 | 12,00 |
| Компоненты | 800,00 | |||
| Сборка ноутбуков | Рабочая сила | 7,50 | 1,00 | 20,00 |
| Компоненты | 1400,00 | |||
| Тестирование компьютеров | Рабочая сила | 2,00 | 1,00 | 32,00 |
6. Посмотрите результат - стоимость работы верхнего уровня.
7. Сгенерируйте отчет Activity Cost Report.
Лабораторная работа №10. Использование свойств,
определяемых пользователем (User Defined Properties)
1. Перейдите в Model/UDP Definition Editor... и в диалоге User-Defined Property Dictionary Editor внесите название категорий.
2. Для внесения категории необходимо в поле New Keyword внести наименование категории и щелкнуть по кнопке Add Keyword.
3. Внесите следующие категории:
Resources Consumption (расход ресурсов);Documentation (документация);
Information System (информационная система);
Quality Measure (мера измерения качества).
4.Создайте UDP. Для этого в поле "User-Defined Property (UDP) to be added after selected property" внесите имя UDP, например, «Quality». Затем выберите тип UDP из выпадающего списка Datatype - «Text List (Single selection)». Затем щелкните по кнопке Add.
5.Для UDP типа List необходимо задать список значений. В поле New Member внесите значение «A-Terrific» и щелкните по кнопке Add Member. Затем внесите другие значения UDP Quality:
· B-Good
· С-ОК
· D-Poor
· E-Awful.
6. Для включения UDP в категорию щелкните по UDP в списке, затем щелкните по категории в нижнем списке, затем щелкните по кнопке Update. По табл. 9 внесите UDP.
Таблица 9
Определение UDP
| Наименование Тип Члены Категория | |||
| UDP | |||
| Application (приложения) | Text List (Multiple Selection) | COS- Customer Order System (модульоформления заказов) ESS- Employee Sheduler System (модуль создания и контроля расписания выполнения работ) PIS- Parts and Inventory System (модуль учета комплектующих и оборудования) PTS- Procedures and Troubleshooting System (модуль процедур сборки и поиска неисправностей) | Information System |
| Screen | Command | Information System | |
| Additional Documentation (дополнительная документация) | Command List | Winword.EXE samplel.doc Winword.EXE sample2.doc POWERPNT.EXE sample3.ppt | Documentation |
| Change History (история изменения) | Paragraph Text | Documentation | |
| Electricity Consumption (расход электроэнергии) | Real Number | Resources Consumption |
7. По табл. 10 внесите значения UDP для работ.
Таблица 10
Значения UDP для работ
| Activity Name Additional Application Change History Electricity Quality | |||||
| Documentation Consumption | |||||
| Отслеживание расписания и управление сборкой и тестированием | Winword.EXE sample2.doc | COS- Customer Order System | История изменения спецификаций | 10,00 | B-Good |
| Сборка настольных компьютеров | PIS PTS | 20,00 | A-Terrific | ||
| Сборка ноутбуков | PIS PTS | 25,00 | C-OK | ||
| Тестирование компьютеров | PIS PTS | 40,00 | B-Good |
8. После внесения UDP типа Command или Command List, щелчок по кнопке 
приведет к запуску приложения.
9. В диалоге Activity Properties щелкните по кнопке Filter. В появившемся диалоге Diagram Object UDP Filter отключите категорию Information System. Щелкните по ОК. Посмотрите результат.
10. Свойства UDP можно присвоить не только работам, но и стрелкам. Щелкните по стрелке правой кнопкой и выберите в контекстном меню UDP Editor. По табл. 11 задайте значения UDP стрелкам.
Таблица 11
Значения UDP для стрелок
| Arrow Name Quality | |
| Заказы на настольные компьютеры | B-Good |
| Ноутбуки | B-Good |
| Собранные компьютеры | A-Terrific |
11. Посмотрите отчет по UDP. Меню Tools/Reports/Diagram Object Report.
12. Самостоятельно проделайте следующее.
Создайте еще два UDP (табл. 12).
Таблица 12
Новые UDP
| Наименование UDP Тип Значения Категория | |||
| Responsibility (ответственность) | Text List (Single Selection) | Ivanov Petrov Sidorov | Quality Measure |
| Customer Sutisfaction (оценка клиента) | Integer List (Single Selection) | Quality Measure |
Задайте свойства работам (табл. 13).
Таблица 13
Использование новых UDP
| Activity Name Responsibility Customer Sutisfaction | ||
| Отслеживание расписания и управление сборкой и тестированием | Ivanov | |
| Сборка настольных компьютеров | Petrov | |
| Сборка ноутбуков | Petrov | |
| Тестирование компьютеров | Sidorov |
Лабораторная работа №11. Создание организационной диаграммы (Organization Chart)
1. Вызовите словарь групп ролей Role Group с помощью меню Dictionary/Role Group... и создайте необходимое количество групп.
2. Вызовите словарь ролей Role с помощью меню Dictionary/Role... и опишите роли, связав их с требуемыми группами. В данном случае роли -это аналог должностей.
3. Вызовите словарь ресурсов «Resource» с помощью меню Dictionary/Resource... и впишите имена людей, связав их с группами ролей и ролями.
4. С помощью меню Diagram/Add Organization Chart... вызовите диалог «Organization Chart Wizard» и, следуя его указаниям, создайте первый уровень организационной иерархии на основании словарей групп ролей, ролей и ресурсов.
5. Далее, вызывая контекстное меню Edit subordinate list..., создайте следующий уровень иерархии по аналогии с пунктом 4.
4. ИНТЕГРАЦИЯ ФУНКЦИОНАЛЬНЫХ МОДЕЛЕЙ И МОДЕЛЕЙ ДАННЫХ
Лабораторная работа №12. Создание диаграммы потоков данных (Data Flow Diagramming)
В AllFusion Process Modeler реализована нотация Гейна-Сарсона для построения диаграмм потоков данных (DFD-диаграмм). Диаграмма потоков данных описывает:
функции обработки информации (activity);
документы и другие объекты, которые участвуют в обработке информации (arrow);
внешние ссылки (external reference) на объекты, являющиеся внешними по отношению к модели;
хранилища данных (data store).
Взаимосвязь указанных компонент имеет вид, показанный на рис.40.
Рис. 35. Семантика DFD-диаграммы
Перед тем как приступить к созданию диаграмм DFD, необходимо перейти на диаграмму «Продажи и маркетинг» (рис.36).
При оформлении заказа важно проверить, существует ли такой клиент в нашей базе данных и, если не существует, внести его в БД и затем оформить заказ. Оформление заказа начинается со звонка клиента. В процессе оформления заказа БД клиентов может просматриваться и редактироваться. Заказ должен включать как информацию о клиенте, так и информацию о заказанных продуктах. Оформление заказа подразумевает чтение и запись информации о прочих заказах.
|
Рис. 36. Декомпозиция работу «Продажи и маркетинг»
В процессе декомпозиции, согласно правилам DFD преобразуем граничные стрелки во внутренние, начинающиеся и заканчивающиеся на внешних ссылках.
1. Декомпозируйте работу «Оформление заказов».
2. В диалоге Activity Box Count выберите количество работ 2 и нотацию DFD.
3. Щелкните по OK и внесите на новой диаграмме DFD имена работ:
· Проверка и внесение клиента
· Внесение заказа.
4. Внесите следующие хранилища данных:
§ Список клиентов
§ Список продуктов
§ Список заказов.
5.Удалите граничные стрелки с диаграммы DFD.
6. Внесите внешнюю ссылку
• Звонки клиентов.
7.Создайте внутренние ссылки согласно рис.37. При именовании стрелок используйте словарь.
|
Рис. 37. DFD-диаграмма
8. Обратите внимание, что стрелки «Информация о клиентах» и «Заказы клиентов» двунаправленные. Для того, чтобы сделать стрелку двунаправленной, щелкните правой кнопкой по стрелке, выберите в контекстном меню пункт Style Editor и в диалоге Style Editor выберите опцию Bidirectional.
9. На родительской диаграмме туннелируйте (Change to Tunnel) стрелки, подходящие и исходящие из работы «Оформление заказов» (рис. 38).
|
Рис.38. Туннелирование стрелок
10. Самостоятельно декомпозируйте работу «Исследование рынка» на диаграмму DFD. Создайте следующие работы: «Разработка прогнозов продаж», «Разработка маркетинговых материалов», «Привлечение новых клиентов».
11. Внесите хранилища данных:
• Список клиентов
• Список продуктов
• Список заказов.
12. Добавьте 2 внешние ссылки
• Маркетинговые материалы
• Прогноз продаж.
13. Свяжите объекты диаграммы DFD стрелками.
5. РАЗРАБОТКА МОДЕЛИ СИСТЕМЫ МЕНЕДЖМЕНТА
КАЧЕСТВА
