Зачем описывать процессы?
Обилие вокруг проектов по описанию процессов поражает. Кого из коллег не спросишь, все только тем и занимаются, что описывают процессы.
Не боясь прослыть занудой, я всем, кто занимается описанием процессов у себя в организации, задаю один вопрос: «зачем?». И получаю схожие, по сути, ответы: «чтобы оптимизировать», «сделать управляемыми», «понять, как построена деятельность» — в различных вариациях. По моему глубокому убеждению, неудача проекта по описанию процессов закладывается уже на этом этапе: когда разработчик плохо себе представляет, кто потребитель результата его проекта, в чем ценность результата для этого потребителя и какие решения потребитель будет принимать на основании сформированных результатов. Вот, например, один из ответов на эти три вопроса:
1. Для собственников
2. Понять, что получилось в результате активной покупки всего подряд
3. Для принятия решения об инвестициях в автоматизацию
Если кто-то может связать эти три ответа воедино, поздравляю! У меня же никак не получается. Если взять «1+2», то выходит, что собственников интересует некая карта бизнеса — по-крупному, в смысле «а что у нас есть». Но тогда третий пункт совершенно выпадает. Если принять, что собственники решили определиться с инвестициями в автоматизацию, то что делать с пунктом 2?
Ну а вопрос: «Зачем собственникам для всего этого нужно описание процессов?» уж и не решился задать.
Если бы я сам не был свидетелем того, как проваливались проекты по описанию процессов (практически все! да, да, и мои тоже!), то я не был бы так настойчив.
Но опыт-то — пусть и негативный — должен чему-то учить?!
Беседуя с одной из коллег, которой поручили — что бы Вы думали? — конечно, описывать процессы, я посоветовал ей взглянуть на дело с такой точки зрения.
По сути, любая карта процессов может иметь одно из двух назначений:
1) быть нормативной, т. е. задавать состояние «как должно быть»,
2) быть рефлективной, т. е. отражать состояние «как есть».
Нормативная карта — это результат проектирования системы, в ней закреплено нормативное состояние. И на аудит системы мы пойдем с ней. Ее особенность в том, что она содержит (обобщенно) минимально необходимый (обязательный) набор элементов системы, обеспечивающий ее работоспособность.
Рефлективная карта потребуется нам, когда надо будет произвести анализ какой-либо деятельности.
Отсюда следует важный вывод: нормативную карту процессов архитектор системы строит сам, исходя из своего взгляда на систему и требований к ней. Попытка проектировать систему на основании опросов руководителей бессмысленна и безрезультатна.
