 | |  |
| |
Универсальность моделей eEPC. Плюсы и минусы для формирования регламентов процессов.
Сегодня аналитик справедливо ожидает от средства моделирования автоматизацию хотя бы части своих функций. Каждый для себя или проекта выбирает свой ряд автоматизирующих средств, при этом самым популярным является формирование регламентов на основании диаграмм. Действительно, накопленная и обработанная информация не должна оставаться «картинкой в компьютере», напротив, ей место в руках пользователей этой информации.
Паспорт процесса, карта процесса, регламент, инструкция – все это синонимы для скрипта, ведь ему для формирования этих документов типично найти информацию в базе моделей, обработать ее и вывести в документ.
Часто необходимость формирования нормативных документов наступает после того, как основная доля процессов уже готова. При формировании скрипта получается, что к моделированию выдвигаются новые требования. Аналитику приходится либо переделывать все готовые модели, либо довольствоваться теми возможностями, которыми они уже обладают.
Существуют два подхода к формированию базы знаний компании: классический и функционально ориентированный.
При классическом моделировании аналитик лишь стремится максимально подробно описать деятельность с минимальными временными затратами, не задумываясь о применимости этих данных. При этом подходе наименования объектов (а ведь это и есть данные для выгрузки в текстовый регламент!) являются обособленными. К примеру, функцию обычно называют: «Провести приходную накладную» или «Проведение приходной накладной», а событие может выглядеть так: «Возникла необходимость проведения новой приходной накладной».
 Рисунок 1. Пример классического подхода к моделированию.
Все эти наименования полны и хороши для чтения, пока помещаются в рамки объекта, но насколько они применимы далее? А далее программист вместе с аналитиком пытаются построить на основе этих данных удобоваримое текстовое описание процесса. Этот текст является важнейшим составляющим руководящего документа и недопустимы его разночтение или хотя бы частичная потеря смысла.
Применительно к первой функции примера (см. рисунок 1) фактически получается, что необходимо сформировать внятное предложение, описывающее этап процесса из следующей информации:
- Возникла необходимость в разработке нового классификатора – событие;
- Формирование запроса-предложения по разработке классификатора – функция;
- Запрос-предложение по разработке классификатора от заинтересованных организаций – документ, электронный носитель, выход;
- Организация-инициатор – организационная единица, исполнитель;
- Предложения сформированы – событие.
Составить единое предложение из этого не получается. Можно ограничиться лишь частью информации, к примеру, «1. Формирование запроса-предложения по разработке классификатора. Исполнитель – Организация-инициатор». Однако смысл частично искажен отсутствием информации о выходных документах, а также инициирующем и результирующем событиях.
Выйти из положения можно, пересмотрев требование к регламенту, теперь нам не нужно формировать целостное предложение, нам достаточно вывести всю информацию об этапе процесса в каком-то структурированном виде. Вот, что выходит на практике в большинстве случаев (выделенный текст является наименованиями объектов):
Таблица 1. Структурированный вывод информации о процессе.
№
| Входящие документы
| Действие
| Исходящие (изменяемые) документы
| Результаты
| Исполнитель
| 1
| -
| Формирование запроса-предложения по разработке классификатора
| Запрос-предложение по разработке классификатора от заинтересованных организаций
| Предложения сформированы (далее п.1)
| Организация-инициатор
| ...
|
|
|
|
|
| 3
| Запрос-предложение по разработке классификатора от заинтересованных организаций
| Рассмотрение предложений
| -
| Принято решение отказать в разработке (далее п. 4);
Принято решение осуществить разработку (далее п. 5).
| Разработчик классификатора
| ...
|
|
|
|
|
| 5
| Запрос-предложение по разработке классификатора от заинтересованных организаций
| Исследование подлежащего классификации вида информации
| Результаты обследования
| Исследование вида информации произведено
| Разработчик классификатора
|
Супротив классическому подходу, функционально-ориентированное моделирование подразумевает узкую направленность при описании деятельности. Эта направленность определяется конкретной применимостью моделей. К примеру, если база моделей eEPC строится лишь для формирования текстовых описаний, то при моделировании аналитик может использовать наименования, «слагая» из них предложения.
Рисунок 2. Пример функционально-ориентированного подхода к моделированию.
Используя такой подход, в базе данных АРИС формируются лишь те аспекты деятельности компании, которые должны быть документированы, что (в данном примере) обеспечивает вывод информации в виде предложений, которые формируются исходя из наваний объектов функции и его окружения.
Пример:
1. В случае если необходимо разработать новый классификатор Организация-инициатор формирует (изменяет) Запрос-предложение по разработке классификатора от заинтересованных организаций (в эл. виде).
…
3. Разработчик классификатора на основании документа Запрос-предложение по разработке классификатора от заинтересованных организаций (в эл. виде) проводит анализ, в результате чего либо принято решение отказать, либо принято решение осуществить разработку.
…
5. В случае если принято решение осуществить разработку Разработчик классификатора на основании документа Запрос-предложение по разработке классификатора от заинтересованных организаций (в эл. виде) исследует соответствующий вид информации, формирует (изменяет) Результаты обследования (в эл. виде).
Обратите внимание, что ряд событий пропал, т.к. теперь они не просто несут информацию, а управляют процессом (остались инициирующее событие, события с условиями ветвления), наименования объектов упростились, а в случае с первой функцией наименование и вовсе исчезло.
Приведенный пример не является идеалом моделирования, в каждом проекте он обретает собственный стиль и диктует свои требования, как к моделированию, так и к программированию скрипта.
|
Категория: Пользователю ARIS | Добавил: easyaris (05.03.2008)
| Автор: Селезнев Константин 
|
| Просмотров: 4649
|
Добавлять комментарии могут только зарегистрированные пользователи. [ Регистрация | Вход ] | |
 | |  |
|
|
