1. Определение выхода.
Если выход определили, необходимо уточнить соответствие модели сценарию. Данная процедура, если она возможна в данной ситуации, должна быть смоделирована, чтобы показать такую возможность. Многие исследователи забывают моделировать негативный результат, производимый действием. Негативный результат часто используется как обратная интерфейсная стрелка в начало действия и должна учитываться для каждого действия. Также важно включать «сомнительные» интерфейсные стрелки в диаграмму и позволить экспертам процесса решать, нужно ли их включать в модель.
2. Определение входа.
После того, как выходы были определены, должен продумываться вход. Вход специфически трансформирован или обработан действием для производства выходов. В производственной сфере легче представить, как «сырье-вход» трансформировано и/или обработано в противоположный «выход-продукт». Таким образом, в сфере информационного обмена ввод данных может вначале быть вообще не трансформирован или обработан. Очень редко интерфейсная стрелка входа именуется также как и интерфейсная стрелка выхода. В общем, это показывает, что либо данное действие добавляет некоторую ценность бизнесу, либо выход был неправильно назван. Решением этого может быть использование прилагательных для модифицирования существительных в наименовании стрелок для указания на трансформацию, которая имеет место в действии. Для примера, вход мог быть назван «исходная информация» и корреспондируемый выход мог быть назван как «верифицированная информация». Прилагательные «исходная» и «верифицированная» модифицируют данные для понимания результатов трансформации.
3. Определение ресурса.
После создания выхода и входа нужно продумывать ресурсы, относящиеся к действию. Ресурсы включают людей, оборудование, компьютерные базы данных и т.д.
4. Определение управления.
В завершении следует добавить интерфейсную стрелку «управление», управляющую действием. Управление существует в форме правил, регламента, политики, процедур или стандартов. Всем действиям в IDEF0 требуется хотя бы одна контрольная интерфейсная стрелка. Контроль является формой входа в действие.
Когда контекстная диаграмма становится завершенной и стабильной, задайте к ней следующие вопросы:
--- диаграмма суммирует действия, которые будут смоделированы;
--- контекстная диаграмма сочетается ли последовательно с границей, точкой зрения и целями;
--- находятся ли интерфейсной интерфейсные стрелки на подходящем уровне детализации для действия. (Для этого Вам нужно ограничить количество стрелок до шести каждого типа);
--- есть ли согласие рабочей группы по поводу модели.
5. Нумерация действий и диаграмм.
Все действия в стандарте IDEF0 пронумерованы. Может быть использован префикс любой длины, но почти во всех моделях использован символ А. После префикса следует число. Базовое действие всегда нумеруется символом А0. Префикс повторяется для каждого действия. Числа используются для представления того, как детализированы действия. Действие А0 декомпозировано в А1, А2, А3 и т.д. А1 также декомпозировано в А11, А12, А13 и т.д. А 11 также декомпозировано в А111, А112, А113 и т.д. К каждому уровню декомпозиции добавляются последовательные дополнительные цифры. Единственное исключение к этому формату --- это первый уровень, где А0 декомпозирован не в А01, А02 и т.д., а в А1, А2 и т.д.
6. Взаимоотношения диаграммы с родительским действием (границы и иерархия).
Действие декомпозируется, если для его понимания необходима большая детализация. Когда действие декомпозируется, не забывайте о его жизненном цикле. Это предопределяет список кандидатов в дочерние действия. К примеру, узел «делать пирожные» может иметь жизненный цикл «собирать ингредиенты», «приготовить масло», «печь тесто» и т.д.
В стандарте функционального моделирования IDEF0 важно осознавать, что границы дочерней диаграммы --- это границы родительского действия. Это имеет важное последствие. Вся работа осуществляется на листе (нижний уровень) действия.
В отличие от иерархии, как это определено в структурированном программировании, действия на высшем уровне не являются управляющими по отношению к дочерним действиям. «Дочки» и есть родительские действия, только представленные более детализировано.
Коды ИКОМ расположены в конце границы интерфейсной интерфейсные стрелки в дочерней диаграмме для указания, где корреспондируемся интерфейсная стрелка находится на родительской диаграмме. Они используются в качестве проверки последовательности и полезны, когда порядок стрелок в дочерних действиях отличается от родительских. Код ИКОМ состоит из букв И, К, О, М и числа, указывающего «верх - низ» или «лево - право», расположение этой интерфейсной интерфейсные стрелки на родительском действии, например И1, К1, О1, М1.
7. Моделирование «вширь» и «вглубь».
Модели могут быть разработаны как «вширь» (в которой каждая диаграмма детализирована наиболее подробно перед началом ее декомпозиции), так и «вглубь» (в которой иерархия действий сначала определена, а уже затем изображаются интерфейсной интерфейсные стрелки, соединяющие все воедино). Конечно, обе технологии могут быть задействованы на протяжении создания одной модели. Иерархия действий иногда будет незаметно изменяться при изображении стрелок, потому что изображение стрелок идентифицирует некие новые взгляды на структуру модели.
2.6. Пример: моделирование бизнес-процесса на основе стандарта IDEF0.
Для перехода к непосредственному практикуму по стандарту IDEF0 нами была предложена модель процесса консалтингового проекта. Для более простого анализа предложенной модели нами были выделены и сформулированы основные функции консалтингового проекта. Предлагаемые ниже функции взяты из книги «Управленческое консультирование» под редакцией Милана Кубра.
Итак, перечень функций консалтингового проекта состоит из пяти компонентов:
1. Подготовка к консультационному заданию.
2. Диагностика.
3. Планирование действий.
4. Внедрение.
5. Завершение.
Прежде, чем перейти к изучению модели бизнес-процесса следует проанализировать перечисленные выше функции.
Подготовка к консультационному заданию.
Любая работа состоит из начала и окончания. В консалтинговом проекте немаловажное место занимает подготовка к вступлению консультанта к проектному заданию. В частности к этой функции относятся следующие подфункции:
- контакты с клиентом;
- предварительная диагностика проблемы;
- формирование технического задания;
- формулирование предложений клиенту;
- заключение контракта на проведение консалтинговых работ.
Схематически рассматриваемую функцию можно представить следующим образом:
Рис.2 Действие отображаемое в стандарте IDEF0
Диагностика.
Основная задача диагностики выявить силы и факторы, которые вызывают проблему.
В нашей модели основными компонентами функции «Диагностика» являются:
- выявление необходимых факторов;
- анализ и синтез материала;
- детальное изучение проблемы.
Диагностика схематически представлена ниже.
Рис.3 Диагностика
Планирование действий.
Цель данной функции – определить верное решение проблемы клиента. Данная функция осложнена тем, что в случае ошибки на стадии диагностики необходимым станет возврат к предыдущему этапу и повторное проведение диагностики проблемы.
В данной функции модели выделены следующие компоненты:
- выработка решений;
- оценка альтернативных вариантов;
Рис.4 Планирование действий |
- предложения клиенту;
- планирование практической реализации решения.
Как и в предыдущих двух функциях ниже представлен блок «Планирование действий».
Внедрение.
Эта функция осуществляет реализацию разработанных ранее консультантами решений проблем клиента. Компонентами описываемой функции принято считать:
- помощь в осуществлении предложенного;
- корректировка предложений;
- обучение персонала клиентской компании;
- планирование и контроль за внедрением.
Ниже представлена модель функции «Внедрение» на основе стандарта IDEF0.
Рис.5 Внедрение
Завершение.
Итак, завершающая функция в нашей модели – «Завершение». На этой стадии консалтинговых работ сдается последний отчет, производятся взаимные расчеты между сторонами и в случае успешного сотрудничества происходят переговоры о дальнейшем сотрудничестве. Ниже мы представили перечень выделенных компонент функции «Завершение»:
- оценка сделанного;
- конечный отчет;
- расчет по обязательствам;
- оценка планов на будущее;
- уход консультанта.
- |
Рис.7 Контекстная диаграмма бизнес-процесса |
Рис.6 Завершение
Теперь для полноты картины о вышеописанных функциях консалтингового бизнеса ниже будет представлен полностью описанный бизнес-процесс на основе стандарта IDEF0.
Рис. 8 Бизнес-процесс консалтингового проекта
... попытаемся дать характеристику этих среднесрочных колебаний в рамках дифференциальной конъюнктуры и в аспекте методики реинжинирингового подхода к управлению организационными циклами. Изучая теорию организации, остается необъясненным подробно одним из основных предметов исследования – цикличность в развитии организации. Существуют несколько подходов к представлению о цикле развития организации. ...
... процессов и методы быстрой разработки приложений RAD (Rapid Application Development). Именно эта тенденция и наблюдается сейчас в развитии методологий и инструментальных средств реинжиниринга бизнес-процессов. Объектно-ориентированное моделирование признано сегодня базовой методологией BPR. Традиционно, создавая информационные системы компаний, разработчики отталкивались от данных. В результате, ...
... проект по реинжинирингу в Отделе Транспорта. При стоимости проекта 746 тыс. долл. ожидаемый эффект от экономии составляет 2 млн. долл. ежегодно. Всего несколько лет назад на Западе реинжиниринг бизнес-процессов стоял на первом месте в списке приоритетов любого консультанта, а Джеймса Чампи и Майкла Хаммера, авторов супербестселлера «Реинжиниринг корпорации», в то время называли гуру. А сегодня? ...
... продукции (услуги) или ее элементов. В современной науке и практике управления основным направлением менеджмента и его инновационной технологией признается, как уже подчеркивалось ранее, процессный подход, под которым понимается управление деятельностью организации как системой взаимосвязанных бизнес-процессов (далее - БП). Любое предприятие рассматривается как бизнес-система, состоящая из БП, ...
0 комментариев