Почему это
важно
К примеру, в эталонной
модели бизнес-процессов
eTOM, рекомендуемой
консорциумом TelemanagementForum, описывается
около 400 процессов верхнего уровня.
Представьте себе стандартную
ситуацию, когда руководство той или иной компании приняло решение о
внедрении модели
eTOM.
Это означает, что поставлена задача по управлению по
меньшей мере 400 взаимосвязанными проектами.
Спецификой такой проектной
задачи является рост количества таких проектов параллельно с завершением
каждого из них. Действительно, проектирование каждого из процессов
включает операцию декомпозиции процесса и, следовательно, порождения новых
проектов.
Естественно, среда системы
IDEF0\Doctor легко
справляется с таким многообразием в части поддержки процедуры
проектирования процессов и формирования регламентов исполнения БП, но
является бессильной в части планирования такой работы. Собственно, это и
не является ее задачей.
Для планирования проектных
работ принято использовать специализированные инструменты. Вопрос только в
том, как внести данные о 400 процессах в базу данных этих инструментов и
как осуществлять манипуляции (например, фильтрацию) с таким большим числом
проектных задач. Не руками же это делать?
Функцию интеграции с одним
из таких инструментов (MS Project)
и исполнения рутинных операций берет на себя система
IDEF0\Doctor. Интеграция с
MS Project
заключается в:
-
возможности автоматического формирования
шаблона плана проектных работ в
MS Project под данным IDEF0-модели;
-
возможности автоматической корректировки
плана работ в MS Project,
в соответствии с проведенными изменениями (доработками) модели;
-
автоматизации рутинных операций фильтрации
проектных задач в среде
MS Project;
-
поддержке других функций проектирования.
Немного о
методе
Система
IDEF0\Doctor вносит
сведения о проекте в систему
MS Project наиболее естественным с точки зрения методологии
SADT способом. А именно, для каждого из
процессов, описанных в IDEF0-модели, в листе
задач MS Project
формируется группа задач следующей структуры:
Задачи выполняются в
следующей последовательности:
Формирование требований
к процессу -> Проектирование архитектуры
процесса -> Разработка регламента процесса.
Последний этап не является
обязательным.
На этапе
Формирование требований
к процессу
проектировщик описывает интерфейсы проектируемого процесса (ресурсы
процесса). На этапе
Проектирование
архитектуры процесса
проектировщик проводит декомпозицию
проектируемого процесса на составляющие.
Если после завершения этапа
Проектирование
архитектуры процесса
провести корректировку плана работ
средствами системы IDEF0\Doctor,
задача
Проектирование
архитектуры процесса
в листе задач системы
MS Project, декомпозируется на несколько
групп задач описанной выше структуры. Количество этих групп будет
соответствовать числу элементов декомпозированного процесса.
