Краткая памятка о тонкостях создания процессов. Потому что многие консультанты и технические писатели сводят понятие «создание процесса» к «давайте пропишем всё на бумаге, а потом начнём думать».
Нет, я согласен, что для создания процесса нужно иметь общее видение решаемого вопроса, но полностью законченный регламент на бумаге (и только на бумаге) — это устройство для сбора пыли.
Итак, если мы хотим создать не гору бумаги плюс «чем-то занимающихся сотрудников» (которым мы будем предъявлять претензии «почему не по процессу»), а нормальный, работающий и развивающийся процесс, идем следующим путем.
Шаг 1. Цели и задачи. Прописываем сразу и вешаем на видном месте.
Понятия «целей» и «задач» часто путаются. Точнее, не путаются, а смешиваются. А нужно их различать. «Цель» — это смысл существования процесса, его предназначение. Если Вы пишете в начале документа фразу «Целью процесса управления программными активами является учет лицензий и контроль расходов на покупку программного обеспечения», то это неправильно. Учет и контроль сам по себе ничего не даёт и целья являться не может.
Нужно думать глубже — «зачем мне учитывать и контролировать расходы на ПО». Ответов, скорее всего, будет два: сокращение расходов и лицензионная чистота организации.
Поэтому пишем в виде цели — «Отсутствие лицензионных претензий к организации».
Шаг 2. КПЭ процесса. Должен напрямую быть завязан на цель. Для этого и нужно разделение целей и задач. Если мы начнем строить КПЭ не к «цели», а к «задачам», то процесс запросто пойдет не в том направлении, котором надо.
В случае нашего примера с «Управлением Программными Активами» КПЭ будет, например, не «Процент учтенных экземпляров ПО», а «Количество исков против организации по вопросам лицензионных нарушений». Потому что, возможно, процесс добьется этого совершенно другим путём, чем «учёт всего на свете».
Шаг 3. Необходимо определить объекты процесса. «Объекты» — это артефакты, жизненный цикл которых и есть суть работы процесса. Это не обязательно один тип объекта. Их может быть несколько. При прохождении процесса они могут создаваться и исчезать. Входной и выходной артефакт могут быть разными, а могут быть одним и тем же артефактом в разных статусах. Но определены они должны быть именно сейчас. В будущем это сильно упростит построение процесса, т.к. будут отсеиваться все активности, которые находятся вне зоны обработки объектов процесса.
Например, для процесса Управления Изменениями, «объектами» могут быть следующие артефакты: «Запрос на изменение (RFC)», «Заявка на согласование», «Задача по RFC». Два последних являются подчиненными первому объекту, и могут описываться отдельными подпроцессами.
Для объектов нужно определить не только их название и местоположение, но и, желательно, перечень атрибутов и связей с другими объектами.
Теперь важно! Многие рисуют процессы с отрывом от системы автоматизации. Аргументируя это тем, что «главное выстроить процесс, а на чём его автоматизировать — дело второе». Мой опыт показывает, что это в корне неверно. Представьте себе «процесс управления автомобилем», который подошел бы и к яхте, и к самолету, с формулировкой «целью ведь является доехать до конечной точки, какая разница на чём».
Оторванным от автоматизации может быть только очень высокоуровневое описание деятельности, типа «Положения о процессе» или «Стратегия». То есть тот уровень, на котором автоматизация невозможна или нецелесообразна.
Когда мы формализуем реальный «боевой» процесс, мы должны понимать, что автоматизация неизбежна. Даже электронная почта и Word — это уже автоматизация, и это нужно четко прописать. Если радеете за чистоту документа, выведите это в «Приложение». Если Вас беспокоят сроки согласования (а для громоздких документов это случается) — разделите документ на несколько уровней. Но привязка к системе автоматизации нужна для шага 5.
Шаг 4. Роли. Необходимо четко определить роли, которые участвуют в процессе. Четкий перечень, который впоследствии будет прописан во всех блок-схемах процесса. Никакие другие роли в дальнейшем (при описании процесса) участвовать не должны.
Роли могут иметь одинаковое название и отличаться, например, географическим расположением. Например, «Оператор дежурной службы» может разделяться на «Оператор дежурной службы (Москва)» и «Оператор дежурной службы (Хабаровск)». Подобное разделение также нужно указать в соответствующем разделе.
Если на этом шаге ошибетесь — ничего страшного. Роли можно добавить. Но основной перечень ролей должен быть уже понятен.
Шаг 5. Измерение деятельности процесса. Тут мы прописываем алгоритм измерения КПЭ и метрик, которые мы описали на шаге 2.
Для точного описания получения метрики необходимо использовать данные объектов из шага 3, а делать это будут сотрудники на ролях из шага 4. Если того или другого не хватает — дописывайте артефакты, дописывайте роли.
Нет более бесполезного КПЭ, чем КПЭ, которое невозможно измерить. Либо, когда неизвестно — кто это будет делать. Можете на таком процессе сразу поставить крест.
По моему личному убеждению, минимальный процесс, который может существовать, это «четкая цель + в реальности измеряемый КПЭ». Это — скелет. Остальное вокруг этой связки нарастет. Может быть. Но без этой связки — точно не получится.
Шаг 6. Четко прописываем входы и выходы процесса. Чем подробнее, тем лучше. Что получаем, откуда, и какой стартовый объект при этом создается (см. шаг 3). Заодно добавим (официально в документе, или в заметках для себя): с какой частотой срабатывает триггер начала работы процесса, кто отвечает за входные данные, насколько надежный это источник. После этого: что отдаем, кому и какой финальный объект является этим результатом. А заодно: кому он нужен.
Подготовительная часть готова. За шесть шагов мы подготовили все возможные ограничения для деятельности процесса.
Шаг 7. Ввести дополнительные ограничения, по мене необходимости. Внешние регламентирующие документы, ограничения по времени выполнения, и т.п.
И, наконец, шаг 8. Само описание процесса. Тут форматов и нотаций — море. Как прописано в Вашем корпоративном стандарте, так и разрабатывайте.
Дальнейшее описание этапов/подэтапов/шагов процесса должно следовать лишь одному правилу: использовать ресурсы только из предыдущих семи шагов, и никаких других.
Часто описание процесса начинается сразу с п.8, с формулировкой «ввяжемся в бой, а там посмотрим». Как следствие, обычно — бесконечное затягивание создания алгоритма действий, т.к. участники не понимают охвата и ограничений.
Первые семь шагов для этого и предназначены: они помогут шагу 8 быть законченным.
Если есть возможность, одновременно с формированием документа пишите бизнес-требования на автоматизацию. Раздел за разделом. Идеальным вариантом было бы сказать — «и сразу автоматизируйте», но это получается не всегда
Не оставляйте на потом, потому что «потом» процесс может приобрести такую сложность, что БТ будете переписывать по несколько раз. Или, что еще хуже — по несколько раз внедрять не то, что надо. Бывает и такое.