Традиционный подход стремится создать такой регламент бизнес-процесса, в котором смешано воедино и сам процесс, и все возможные сценарии его развития, и все действия персонала. Кроме того стремления описать цельную картину ведут к описанию не бизнес-процессов, а сквозных – E2E процессов или абстрактных потоков работ или потоков обработки документов. Ну и для полноты бардака, хочется отметить, что без умения четко выделять бизнес процессы и детализировать их – в таких регламентах описываются разноуровневые шаги процесса, а зачастую и шаги из принципиально различных бизнес-процессов. При этом такой документ становится похож больше на операционную инструкцию или на пожелания руководителя к объему исполняемых задач определенным сотрудником – таким, я бы сказал, отголоском требований к компетентности сотрудника, которого принимают на определенную должность. Приблизительно также можно изобразить ситуацию с должностной инструкцией. В нее стараются уместить и обязанности штатной единицы, и операционные обязанности, исполняемые в рамках непонятно как определенного набора процессов, и требования к компетенциям и знаниям. И вроде бы панацея от описанной выше ситуации известна – это получение автоматизированных регламентов бизнес-процессов и должностных инструкций из сред разработки бизнес-процессов, так как в регламент выводится только то, что смоделировано, внесено в атрибуты объектов, входящих в состав модели и утверждено коллегиально, а лихому творчеству отдельных сотрудников места нет. Но опыт показывает, что такие регламенты очень кратки и формальны, они определяют только основные шаги процесса, роли их исполняющие и события запускающие другие процессы. Т.е. мы получаем информацию только о конкретном шаге процесса, без объяснений как это шаг сказывается на других или собственно как он исполняется. Да, мы понимаем, какие еще процессы будут запущены, да, мы понимаем, какие данные или информация будет передана. Но, прочитав такой документ, общей картины мы не получаем. Т.е. мы получаем некую противоположность описанной в начале ситуации. И не смотря на то, что она более точно отвечает имеющейся модели деятельности компании – ее пригодность для восприятия сотрудниками своих задач и их места в общей картине деятельности Компании весьма спорна. Как же искать золотую середину? Представляется, что она состоит в более комплексном подходе. Т.е. мы безусловно должны учиться работать на основании формальных моделей и их не менее формальных регламентов – т.е. уходить от творчества сотрудника в каждом его шаге в сторону исполнения им конкретных ролей в процессе (ах). Ролей, которые обеспечены с одной стороны формальными регламентами, а, с другой стороны, подробными операционными инструкциями содержащими ответ на вопрос как исполнить ту или иную операцию. В итоге предлагается подходить к вопросу регламентации следующим образом: 1. Формализовать деятельность Компании в виде набора взаимодополняющих моделей, создающих в своей совокупности непротиворечивую картину архитектуры Компании и создавать на основе данных заложенных в эту модель соответствующие формальные регламенты. 2. Используя такую модель создавать E2E процессы, позволяющие отобразить и регламентировать все возможные варианты для: · достижения определенной бизнес задачи или получения продукта; · исполнения функций при прохождении документа от его инициации до закрытия; · поведения информационной системы для автоматизации операций исполняемых сотрудниками И создавать на основе анализа E2E процессов регламенты, обеспечивающие меппинг между шагами E2E процесса - действиями сотрудника по их исполнению – поведением системы, автоматизирующий данный шаг E2E процесса – и получаемыми результатами. Как пример можно привести следующую ситуацию: Перед нами отраслевой центр компетенции SAP, ну просто очень крупной компании. Основная цель деятельности ОЦК – «Оптимизация единой методологически целостной среды для поддержки Информационного решения в актуальном состоянии». А основной процесс, который все хотят увидеть формализованным и регламентированным – это процесс изменения Информационного решения – понятно не тот, который предлагает ITIL, а E2E процесс, который проходит через все процессы ОЦК. Причем увидеть по возможности все сценарии этого E2E процесса. Модель такого ОЦК содержит около 300 – 400 моделей процессов при этом на уровне групп процессов находятся 45 процессов, из них 18 требуют обязательной регламентации. Сюда попадают процессы управления инцидентами, проблемами, релизами, изменениями, конфигурациями, сервисами и операциями, разработки бизнес требований, концептуального проектирования и разработки прототипа системы, тиражирования и передачи на поддержку системы введенной в промышленную эксплуатацию и т.п. Возможных сценариев E2E процесса изменения Информационного решения около 10. Регламентация такого ОЦК будет включать: Процессные регламенты, которые определяют: структуру процесса (Процесс/ Сценарий/ Процедура/ Функция), исполнителей процессов (роли), инициализирующие события (входы и выходы – интерфейсы с другими процессами), информацию или документы и их изменение в рамках процесса, автоматизирующие процессы информационные системы и их поведение в рамках процесса. Должностные инструкции, которые определяют: состав операций исполняемых определенной ролью и состав ролей исполняемых определенной сотрудником, который занимает определенную должность. Сценарии E2E процесса изменения Информационного решения, которые определяют: шаги процесса, описание действий исполнителя шага процесса, описание экранов и поведения информационной системы при исполнении данного шага, описание состояний документов при исполнении данного шага, правила выбора и параметры перехода к другому шагу.