В предыдущей статье я упоминал, что каждый процесс должен иметь «цель», и эта цель есть смысл существования процесса. Приводился пример, при котором целью процесса управления программными активами была «лицензионная чистота организации», а не «полный учет всего на свете».
Это правило формирования целей, конечно, корректное, но есть исключения.
Любой программист знает такие понятия как «процедура» и «функция». Эти механизмы позволяют заметно упростить код, сократить его объем и повысить надежность за счет единожды отлаженных участков кода, изолированных вызовом этой процедуры или функции.
В процессном управлении иногда используются те же самые механизмы.
Для оптимизации процессной модели часто бывает необходимо создание подобных «функций». Рассмотрим простой пример: «Процесс резервирования рабочих ресурсов». Continue reading →

Краткая памятка о тонкостях создания процессов. Потому что многие консультанты и технические писатели сводят понятие «создание процесса» к «давайте пропишем всё на бумаге, а потом начнём думать».
Нет, я согласен, что для создания процесса нужно иметь общее видение решаемого вопроса, но полностью законченный регламент на бумаге (и только на бумаге) — это устройство для сбора пыли.
Итак, если мы хотим создать не гору бумаги плюс «чем-то занимающихся сотрудников» (которым мы будем предъявлять претензии «почему не по процессу»), а нормальный, работающий и развивающийся процесс, идем следующим путем.
Шаг 1. Цели и задачи. Прописываем сразу и вешаем на видном месте.
Понятия «целей» и «задач» часто путаются. Точнее, не путаются, а смешиваются. А нужно их различать. «Цель» — это смысл существования процесса, его предназначение. Если Вы пишете в начале документа фразу «Целью процесса управления программными активами является учет лицензий и контроль расходов на покупку программного обеспечения», то это неправильно. Учет и контроль сам по себе ничего не даёт и целья являться не может. Continue reading →