# Красные и синие конверты: как проверить процесс шаг за шагом
> Разбор лекции по процессному управлению из программы MBA CIO: практический аудит процесса по шагам жизненного цикла — плюс, минус, плюс-минус, — типичные разрывы между схемой и жизнью, почему владелец процесса не может его закрыть, зачем нужен архив и чем процесс отличается от прецедента.
Источник: https://blog.uspeshnyy.ru/blog/krasnye-i-sinie-konverty/
Автор: Александр Успешный · blog.uspeshnyy.ru
Опубликовано: 2014-12-13
Теги: MBA, система, автоматизация, аналитика, Процессное управление, Владислав Сирота
---
Почта Франции долго и мучительно решала техническую задачу: письма приходили в конвертах двух цветов — красных и синих, — и раскладывать их по двум стопкам приходилось руками. Заказали сканер, который сортировал бы автоматически. Обошлось в сумму с большим количеством нулей.
Когда машина заработала, кто-то наконец спросил: **а зачем вообще два цвета?**
Оказалось — со времён Второй мировой. Одна почта шла на оккупированную территорию, вторая на освобождённую. Территорий давно нет, разделения нет, смысла нет — цвета остались. И их автоматизировали.
Это самая дорогая ошибка процессного управления в чистом виде: **вместо того чтобы спросить «зачем», спросили «как быстрее»**. Разбираю, как её ловить — по седьмой лекции процессного управления из программы MBA CIO. В [предыдущей](/blog/pochemu-v-kompaniyah-voyuyut-otdely/) мы разбирали цепочку ценности; здесь занятие практическое: как взять свой процесс и проверить его шаг за шагом. Читает её Владислав Сирота — тот самый преподаватель, который через несколько лет стал [научным руководителем моей дипломной работы](/blog/diplom-mba-cio-ranhigs/).
## Инструмент: плюс, минус, плюс-минус
Метод простой до неприличия, и именно поэтому им никто не пользуется.
У процесса есть жизненный цикл — пять этапов, у каждого этапа свой набор шагов. Инициирование — самый нагруженный, там семь шагов. Ликвидация — самый короткий, всего два.
Параллельно у процесса есть **ролевая модель**: заказчик, владелец процесса, потребитель, участники. Каждый шаг жизненного цикла описан в терминах этих ролей — например: «заказчик выявляет потребность потребителя».
Дальше начинается работа. Берёте свой реальный процесс, подставляете вместо ролей конкретные фамилии и должности — и по каждому шагу честно отвечаете на один вопрос: **так ли это делается у нас?**
| Ответ | Что ставите | Что пишете в примечании |
|---|---|---|
| Да, делается | **+** | ничего |
| Нет, не делается | **−** | к чему это может привести |
| Иногда так, иногда нет | **±** | к чему приводит, когда не делается |
Всё. Час работы — и у вас карта расхождений между схемой, которую вы держите в голове, и тем, что происходит на самом деле.
Ценность здесь не в плюсах, а в колонке примечаний. Минус сам по себе ни о чём не говорит: бывают шаги, которые вы сознательно пропускаете, и ничего страшного не происходит. Смысл появляется, когда вы дописываете **последствие**.
## Две ошибки, на которых спотыкаются все
Прежде чем сесть за таблицу, две оговорки — обе из практики, обе повторяются от группы к группе.
**Ошибка первая: рассматривать прецедент вместо процесса.** Разница фундаментальная. Компания была системным интегратором — поставляла железо, строила инфраструктуру. Потом решила разрабатывать прикладное ПО под заказ. Вот **создание такой деятельности** — это процесс. А «пришёл конкретный заказчик и попросил написать ему офисную систему» — это прецедент, один из тысяч запусков процесса.
Когда вместо процесса разбирают прецедент, аудит превращается в разбор одного случая — и все выводы оказываются неприменимы к следующему.
**Ошибка вторая: что-то не вписывается в ролевую модель.** Это не повод бросить упражнение — это и есть результат. Причин ровно две, и обе полезные:
- жизненный цикл не учитывает особенность именно вашего процесса;
- ваша ролевая модель составлена неверно.
Искать нужно в одном из этих двух мест. Оба открытия дороже, чем аккуратно заполненная таблица. Сама [ролевая модель разобрана отдельно](/blog/pochemu-v-detskom-sadu-kormyat-tak/): одиннадцать ролей, какие из них стоит совмещать и почему заказчик не может быть слабее владельца процесса.
А чтобы ролевая модель и целевые показатели не оказались придуманными за потребителя, требования сначала [собирают у людей](/blog/opros-u-kassy/) — и делают это в определённом порядке.
## Разрыв первый: заказчик не выявляет потребности
Самый частый минус в первой строке таблицы: заказчик не выясняет потребности потребителя.
Разберём на живом примере. Процесс — внутренняя автоматизация. Заказчиком назначили генерального директора, потребителями — сотрудников компании. И сразу видно: генеральный не пойдёт по кабинетам выяснять, чего именно не хватает каждому сотруднику. Не пойдёт никогда.
К чему это приводит, известно всем, кто внедрял внутренние ИТ-системы. **Примерно в девяти случаях из десяти софт не учитывает, удобно ли им пользоваться конкретному человеку.** А человек реагирует единственным доступным ему способом — перестаёт им пользоваться.
Канонический пример этого жанра: чтобы сообщить, что у вас не работает интернет, вам предлагают написать письмо по электронной почте.
Лечится это не героизмом генерального, а перестановкой шагов:
Владелец процесса назначается раньше — и именно он обходит людей, собирает требования и приносит заказчику готовые параметры на утверждение. Заказчик принимает решение, а не собирает информацию.
Ту же проблему решает и второй ход: **взять заказчика уровнем ниже**. Если процесс обслуживает конкретное подразделение и платит за него руководитель этого подразделения, генеральный в схеме вообще не нужен. Правило простое — **заказчик там, где деньги**: платит подразделение, значит заказчик его руководитель; платит компания централизованно, значит алгоритм придётся менять.
## Разрыв второй: участники не проверяют модель
Ещё один минус, который выглядит формальностью: участники процесса не верифицируют модель.
Понятно, почему это пропускают: водителю, который выполняет один квадратик схемы, неинтересна вся модель целиком. Но у него есть свой квадратик со стрелкой на входе и стрелкой на выходе — и вот их он должен увидеть и подтвердить.
Что бывает, когда не увидел. Трансферы в мусульманской стране: у водителя есть жёсткое требование — в машину садится только трезвый пассажир. Для него это не каприз, это дороже заработка. В модель процесса требование не попало, потому что его никто не спросил. Конфликт всплыл на исполнении: рейс прилетает, пассажир в обычном для дальнего перелёта состоянии, водитель его не сажает.
Формулировка, которую стоит держать при проектировании любого процесса: **шаг верификации можно пропустить, но тогда требования исполнителя вы узнаете от клиента**.
## Разрыв третий: владелец не может закрыть свой процесс
Последний этап жизненного цикла — ликвидация, и здесь почти в каждой группе появляется минус в одном и том же месте: **решение об упразднении процесса принимает его владелец**.
Так не бывает. Это самоубийство по должностной инструкции: закрыв процесс, владелец становится не нужен. Никто не подносит себе пистолет к голове по собственной инициативе.
Последствие тоже одинаковое: компания продолжает платить за существование процесса, прецеденты которого либо не запускаются вообще, либо запускаются раз в год по особой просьбе.
Как выглядит правильная развязка. Директор турфирмы-агента смотрит на цифры: туроператоры освоили интернет, клиенты покупают напрямую, доход агентской прослойки за год — символический. Решение закрыть направление принимает он, а не руководитель этого направления. Тот, если спросить его, найдёт двадцать причин потерпеть ещё год.
**Правило: решение об упразднении принимает тот, кто платит.** Никогда — тот, кто исполняет.
**И побочный эффект смены ролей.** Владелец процесса на этапах создания и на этапе исполнения — часто разные люди: схему ставит руководитель крупного подразделения, а работает по ней начальник отдела уровнем ниже. В авторитарной структуре это убивает шаг корректирующих действий: тот, кто ниже, не станет перестраивать схему, поставленную сверху. Он будет причёсывать реальность под схему, пока это возможно. В нормальной структуре ему, наоборот, скажут: «Я поставил, ты меняй, для этого ты и есть».
## Архив: работа, которую никто не хочет делать
Второй шаг этапа ликвидации — сохранить всю информацию процесса. Здесь у групп наступает редкое единодушие: **архив не хочет делать никто**.
Причина понятна. Архивом занимаются в последние недели, когда сил уже нет. Тот, кто закрывал большой проект, знает это состояние: человек приходит домой, снимает один ботинок, начинает развязывать шнурки на втором — и открывает глаза утром, в одном ботинке, когда ребёнок идёт мимо на кухню. В таком режиме не именуют документы.
Именно поэтому имена файлов к концу выглядят как `важное_сообщение_версия_115194_bis.doc`, и никакая система документооборота этого не спасает.
Так зачем всё-таки архив? Четыре причины, и они разного веса.
**1. Претензии, которые придут позже.** Заказчик вернётся и спросит, почему было сделано так, — и сам уже не будет помнить, что этого просил.
**2. Статистика вместо интуиции.** Без цифр оценка риска звучит как «мне кажется, этот поставщик подведёт нас с вероятностью процентов тридцать». Это эвристика, а не управление. Здесь же — важное различение: **процесс даёт статистику, проект — нет**. Проект уникален, и опыт предыдущего далеко не всегда переносится на следующий. Но десять лет существования процесса, где ежедневно запускается один прецедент, дают три с половиной тысячи точек — этого достаточно для любого анализа. Оговорка, которая всё расставляет по местам: **управление проектами в масштабах компании — это процесс**. Для руководителя проекта его проект уникален; для директора компании это одно и то же, повторяющееся каждый день.
**3. Метапроцесс.** Если в компании появится или изменится другой процесс с тем же метапроцессом, ему неоткуда будет взять информацию. Ничего смертельного, но работа будет сделана заново.
**4. Дисциплина по ходу.** Самая недооценённая причина. Если вы **заранее знаете**, что архив придётся сдавать, вы держите документы в нормальном состоянии всю дорогу. Если не знаете — начинаете разгребать в момент, когда сил на это нет.
**И честная оговорка о том, когда архив не нужен.** Если информационная система уже фиксирует все необходимые показатели процесса — сроки, корректирующие действия, смену поставщиков, — отдельный архив не нужен, шаг можно вычеркнуть. Проверять надо именно это: фиксируется ли **всё необходимое**, а не «что-то фиксируется». Обычно оказывается, что сроки система пишет, а корректирующие действия — нет.
**Где сегодня помогает AI.** Главная беда архивов не в том, что их нет, а в том, что они нечитаемы: тысяча файлов с бессмысленными именами. Современные модели разбирают такой массив и собирают из него связную картину — кто что решал, какие были отклонения, где повторяются одни и те же грабли. Работа, на которую раньше не хватало ни у кого времени, стала выполнимой.
**И ещё одно применение архива, о котором забывают.** Иногда архив — самый ценный актив закрывающегося бизнеса. Клиентская база фотостудии или турагентства после закрытия стоит больше, чем стоил сам бизнес в последний год работы.
## Вывод
Аудит процесса по шагам — упражнение на час, которое даёт больше, чем месяц обсуждений «как нам улучшить работу».
Три вещи стоит унести. **Сначала «зачем», потом «как быстрее»** — иначе вы автоматизируете красные и синие конверты и оплатите машину для сортировки правил, которых нет уже семьдесят лет. **Заказчик должен быть там, где деньги**: если он слишком высоко, шаг с выявлением требований превращается в фикцию, а система, которую построят по такой схеме, останется невостребованной. И **закрывает процесс не тот, кто им управляет** — иначе он не закроется никогда.
**Следующий шаг:** выпишите пять этапов жизненного цикла своего ключевого процесса и по каждому шагу поставьте плюс, минус или плюс-минус. Заполняйте не колонку с оценкой, а колонку с последствиями: что произойдёт, если этот шаг не выполняется. Если в примечаниях набралось три и больше пунктов с реальными последствиями — это и есть [ваше слабое звено](/blog/pochemu-v-kompaniyah-voyuyut-otdely/), а не то, что вы собирались улучшать.