- •Библиография
- •Предисловие
- •Содержание
- •Введение
- •Область применения
- •Нормативные ссылки
- •Определения
- •Общие положения
- •Процессный подход
- •Сеть процессов
- •Бизнес-процесс
- •Функции и функциональная модель в стандарте IDEF0
- •Функциональное моделирование бизнес-процесса
- •Построение функциональных блоков
- •Декомпозиция функциональных блоков
- •Документация по процессам
- •База знаний процессов
- •Документ «Перечень процессов»
- •Документ «Функциональная модель процесса»
- •Документ «Спецификации процесса»
- •Порядок работ по созданию описаний процессов
- •Подготовительный этап
- •Сбор информации
- •Управление процессом функционального моделирования
- •Приложение. Формы документов по процессам
- •Бланк «Перечень процессов»
- •Бланк «IDEF0-Диаграмма»
- •Бланк «Спецификации процесса»
Функциональное моделирование процессов на базе стандарта IDEF0. Методические рекомендации.
7 Порядок работ по созданию описаний процессов
7.1Управление проектом должно представлять собой процесс, в ходе которого координируется работа авторов, экспертов и тех, кто принимает окончательную версию модели системы или ее части.
7.2Следует в полной мере использовать возможности методологии, основанной на разделении функций участников проекта и итерационном характере рецензирования.
7.3В ходе рецензирования следует проверять корректность диаграмм и/или моделей, а также соответствие их поставленной цели и точке зрения.
7.4В деятельность по созданию описаний процессов рекомендуется включать следующие основные этапы:
•подготовительный этап;
•сбор информации;
•разработка функциональных моделей;
•документирование процессов;
•утверждение документов.
8 Подготовительный этап
Создание описаний процессов следует начать с подготовительного этапа, который должен включать:
•формулировку цели, точки зрения о представлении будущих моделей процессов и об их предполагаемом использовании в будущем.
•формирование рабочей группы из числа сотрудников организации и/или привлеченных специалистов.
•согласование планов и сроков по проекту среди всех участников, назначение ответственных исполнители по проекту, а также составление и утверждаются сроков и бюджета по проекту.
9 Сбор информации
9.1 Сбор информация для разработки функциональных моделей процессов следует производить с учетом того, что информация может быть получена из различных источников.
Источник информации |
|
|
|
Описание |
|
|
|
||
чтение документов |
|
Преимущества: источник информации, доступный в удобное |
|||||||
|
|
время, знакомиться можно в удобном темпе, удобно |
|||||||
|
|
формулировать |
|
вопросы |
для |
|
экспертов. |
||
|
|
Недостатки: необходимость поддерживать библиотеку |
|||||||
|
|
документов, |
не |
описаны |
текущие |
|
нюансы |
и |
|
|
|
недокументированные аспекты. |
|
|
|
|
|||
наблюдение |
за |
Преимущества: получение информации из первых рук, |
|||||||
выполняемыми |
|
возникают вопросы, которые никогда не появились бы при |
|||||||
операциями |
|
чтении |
документов |
и |
общении |
с |
экспертом. |
||
|
|
Недостатки: слишком долгое наблюдение приводи к |
|||||||
|
|
избыточному привыканию к состоянию дел, возможна потеря |
|||||||
|
|
объективности и отсутствие видения альтернативных путей |
|||||||
|
|
описания системы. |
|
|
|
|
|
||
анкетирование |
|
Преимущества: возможность опросить большие группы |
|||||||
|
|
экспертов, возможность быстро получить различные точки |
|||||||
|
|
зрения на систему, позволяет выявить, какие части системы |
|||||||
15
|
|
|
Функциональное моделирование процессов на |
|||
|
|
|
базе |
стандарта |
IDEF0. |
Методические |
|
|
|
рекомендации. |
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
требуют |
|
|
улучшения. |
|
|
|
Недостатки: на практике, информация малодостоверна, |
||||
|
|
необходимо четко формулировать вопросы на языке |
||||
|
|
экспертов, не может использоваться на начальном этапе |
||||
|
|
знакомства с системой. |
|
|
|
|
использование |
Преимущества: аналитик является источником информации, |
|||||
собственных знаний |
знания проверены на практике и разносторонни. |
|||||
|
|
Недостатки: может не хватить знаний, специфических для |
||||
|
|
данной системы, при описании специфики необходимо |
||||
|
|
полагаться на экспертов, а не на себя. |
|
|
||
составление описания |
Преимущества: возможность получения альтернативных схем |
|||||
|
|
функционирования системы, о которых эксперты никогда не |
||||
|
|
думали. |
|
|
|
|
|
|
Недостатки: Необходимость изучения предметной области, |
||||
|
|
необходимость нескольких доброжелательно |
настроенных |
|||
|
|
экспертов. |
|
|
|
|
|
|
|
|
|
|
|
9.2Опрос специалистов и экспертов следует осуществлять для:
•сбора фактов
•определения проблем
•принятия решений
•уточнения функциональных моделей
9.3Опрос для сбора фактов следует проводить, когда необходимо определить, как выполняется процесс или работает система. Опросы для определения проблемы - когда необходимо выяснить претензии к процессу. Совещания для принятия решений - когда необходимо получить представление, как должен функционировать будущий процесс, чтобы устранить недостатки в существующем процессе. Диалоги автор-читатель - обсуждение между автором и рецензентом при возникновении разногласий.
9.4Для всех типов опроса следует использовать подход, имеющий три этапа:
1.подготовка,
2.проведение опроса,
3.завершение.
9.5Хорошая подготовка оптимизирует время опроса, проведенное с источником информации, и дает надежный поток информации. Следует включать следующие шаги:
•выбор необходимого собеседника;
•предварительную договоренность о встрече;
•согласованную программу встречи;
•изучение сопутствующей информации;
•согласование действий с группой проектирования и аналитиками.
9.6Установив цель встречи и договариваясь о встрече, следует ограничить ее продолжительность в пределах часа или менее. Если тематика обширна, следует разбить беседу на несколько встреч. Следует установить программу беседы и определить круг вопросов, обратив внимание на те, от ответов на которые зависит продолжение моделирования.
9.7При опросе следует правильно организовывать и поддерживать поток информации от эксперта к аналитику:
•делайте паузы, когда эксперт думает, давая возможность ему обдумать, что сказать дальше;
•никогда не перебивайте, подсказывая ответ или задавая другой вопрос;
16
Функциональное моделирование процессов на базе стандарта IDEF0. Методические рекомендации.
•не задавайте наводящих вопросов, и вопросов, на которые можно дать однозначный ответ (Да/Нет) - это не дает эксперту возможность делиться знаниями;
•старайтесь не задавать контрольных вопросов - это прерывает поток информации;
•делая записи, не стенографируйте, а готовьте следующий вопрос и фиксируйте только факты, иначе легко потерять контроль над опросом.
9.8В ходе опроса следует отслеживать:
•вы получили достаточно информации;
•вы получаете большой объем ненужной информации;
•обилие информации вас подавляет;
•эксперт начинает уставать;
•с экспертом у вас часто возникают конфликты.
9.9 Материалы следует оформлять сразу же после встречи с экспертом, чтобы минимизировать потери информации. Следует сделать редакцию своих диаграмм, а копии, вместе с сопроводительными материалами направьте эксперту.
10 Управление процессом функционального моделирования
10.1В процессе IDEF0-моделирования рекомендуется выделить специальную группу людей, ответственных за то, что создаваемая в процессе анализа модель будет точна и используема в дальнейшем. Эта группа отвечает за контроль качества моделей, создаваемых разработчиками проекта. Рабочая группа следит за выполняемой работой и ее соответствием конечным целям всего проекта. Члены рабочей группы обсуждают модель и оценивают, насколько она может быть использована и будет использована соответствующим образом в ходе выполнения проекта для достижения его глобальных целей.
10.2Таким образом, рабочая группа находится в наиболее выгодном положении при определении текущего направления развития проекта и выработке предложений по его корректировке. Рабочая группа реализует это с помощью рецензий. Модели, которые достигли желаемого уровня детализации и точности с точки зрения технических требований, направляются членам рабочей группы для обсуждения и утверждения. Рабочая группа оценивает, насколько применима данная модель. Если модель признана рабочей группой применимой, она одобряется и утверждается. В противном случае разработчикам направляются замечания для необходимой доработки.
17
