Красные и синие конверты: как проверить процесс шаг за шагом

Почта Франции долго и мучительно решала техническую задачу: письма приходили в конвертах двух цветов — красных и синих, — и раскладывать их по двум стопкам приходилось руками. Заказали сканер, который сортировал бы автоматически. Обошлось в сумму с большим количеством нулей.

Когда машина заработала, кто-то наконец спросил: а зачем вообще два цвета?

Оказалось — со времён Второй мировой. Одна почта шла на оккупированную территорию, вторая на освобождённую. Территорий давно нет, разделения нет, смысла нет — цвета остались. И их автоматизировали.

Это самая дорогая ошибка процессного управления в чистом виде: вместо того чтобы спросить «зачем», спросили «как быстрее». Разбираю, как её ловить — по седьмой лекции процессного управления из программы MBA CIO. В предыдущей мы разбирали цепочку ценности; здесь занятие практическое: как взять свой процесс и проверить его шаг за шагом. Читает её Владислав Сирота — тот самый преподаватель, который через несколько лет стал научным руководителем моей дипломной работы.

Инструмент: плюс, минус, плюс-минус

Метод простой до неприличия, и именно поэтому им никто не пользуется.

У процесса есть жизненный цикл — пять этапов, у каждого этапа свой набор шагов. Инициирование — самый нагруженный, там семь шагов. Ликвидация — самый короткий, всего два.

flowchart TB
    A["Инициирование<br/>7 шагов"] --> B["Проектирование"]
    B --> C["Внедрение"]
    C --> D["Осуществление<br/>и анализ"]
    D --> E["Ликвидация<br/>2 шага"]
    D -.->|"корректирующие<br/>действия"| B

Параллельно у процесса есть ролевая модель: заказчик, владелец процесса, потребитель, участники. Каждый шаг жизненного цикла описан в терминах этих ролей — например: «заказчик выявляет потребность потребителя».

Дальше начинается работа. Берёте свой реальный процесс, подставляете вместо ролей конкретные фамилии и должности — и по каждому шагу честно отвечаете на один вопрос: так ли это делается у нас?

Ответ	Что ставите	Что пишете в примечании
Да, делается	+	ничего
Нет, не делается	−	к чему это может привести
Иногда так, иногда нет	±	к чему приводит, когда не делается

Всё. Час работы — и у вас карта расхождений между схемой, которую вы держите в голове, и тем, что происходит на самом деле.

Ценность здесь не в плюсах, а в колонке примечаний. Минус сам по себе ни о чём не говорит: бывают шаги, которые вы сознательно пропускаете, и ничего страшного не происходит. Смысл появляется, когда вы дописываете последствие.

Две ошибки, на которых спотыкаются все

Прежде чем сесть за таблицу, две оговорки — обе из практики, обе повторяются от группы к группе.

Ошибка первая: рассматривать прецедент вместо процесса. Разница фундаментальная. Компания была системным интегратором — поставляла железо, строила инфраструктуру. Потом решила разрабатывать прикладное ПО под заказ. Вот создание такой деятельности — это процесс. А «пришёл конкретный заказчик и попросил написать ему офисную систему» — это прецедент, один из тысяч запусков процесса.

Когда вместо процесса разбирают прецедент, аудит превращается в разбор одного случая — и все выводы оказываются неприменимы к следующему.

Ошибка вторая: что-то не вписывается в ролевую модель. Это не повод бросить упражнение — это и есть результат. Причин ровно две, и обе полезные:

• жизненный цикл не учитывает особенность именно вашего процесса;
• ваша ролевая модель составлена неверно.

Искать нужно в одном из этих двух мест. Оба открытия дороже, чем аккуратно заполненная таблица. Сама ролевая модель разобрана отдельно: одиннадцать ролей, какие из них стоит совмещать и почему заказчик не может быть слабее владельца процесса.

А чтобы ролевая модель и целевые показатели не оказались придуманными за потребителя, требования сначала собирают у людей — и делают это в определённом порядке.

Разрыв первый: заказчик не выявляет потребности

Самый частый минус в первой строке таблицы: заказчик не выясняет потребности потребителя.

Разберём на живом примере. Процесс — внутренняя автоматизация. Заказчиком назначили генерального директора, потребителями — сотрудников компании. И сразу видно: генеральный не пойдёт по кабинетам выяснять, чего именно не хватает каждому сотруднику. Не пойдёт никогда.

К чему это приводит, известно всем, кто внедрял внутренние ИТ-системы. Примерно в девяти случаях из десяти софт не учитывает, удобно ли им пользоваться конкретному человеку. А человек реагирует единственным доступным ему способом — перестаёт им пользоваться.

Канонический пример этого жанра: чтобы сообщить, что у вас не работает интернет, вам предлагают написать письмо по электронной почте.

Лечится это не героизмом генерального, а перестановкой шагов:

flowchart LR
    subgraph N["Как обычно"]
        A1["Заказчик выявляет<br/>потребности"] --> A2["Заказчик задаёт<br/>параметры"] --> A3["Заказчик назначает<br/>владельца"]
    end
    subgraph R["Как работает"]
        B1["Заказчик назначает<br/>владельца"] --> B2["Владелец выявляет<br/>потребности"] --> B3["Владелец приносит<br/>параметры"] --> B4["Заказчик решает,<br/>нужен ли процесс"]
    end

Владелец процесса назначается раньше — и именно он обходит людей, собирает требования и приносит заказчику готовые параметры на утверждение. Заказчик принимает решение, а не собирает информацию.

Ту же проблему решает и второй ход: взять заказчика уровнем ниже. Если процесс обслуживает конкретное подразделение и платит за него руководитель этого подразделения, генеральный в схеме вообще не нужен. Правило простое — заказчик там, где деньги: платит подразделение, значит заказчик его руководитель; платит компания централизованно, значит алгоритм придётся менять.

Разрыв второй: участники не проверяют модель

Ещё один минус, который выглядит формальностью: участники процесса не верифицируют модель.

Понятно, почему это пропускают: водителю, который выполняет один квадратик схемы, неинтересна вся модель целиком. Но у него есть свой квадратик со стрелкой на входе и стрелкой на выходе — и вот их он должен увидеть и подтвердить.

Что бывает, когда не увидел. Трансферы в мусульманской стране: у водителя есть жёсткое требование — в машину садится только трезвый пассажир. Для него это не каприз, это дороже заработка. В модель процесса требование не попало, потому что его никто не спросил. Конфликт всплыл на исполнении: рейс прилетает, пассажир в обычном для дальнего перелёта состоянии, водитель его не сажает.

Формулировка, которую стоит держать при проектировании любого процесса: шаг верификации можно пропустить, но тогда требования исполнителя вы узнаете от клиента.

Разрыв третий: владелец не может закрыть свой процесс

Последний этап жизненного цикла — ликвидация, и здесь почти в каждой группе появляется минус в одном и том же месте: решение об упразднении процесса принимает его владелец.

Так не бывает. Это самоубийство по должностной инструкции: закрыв процесс, владелец становится не нужен. Никто не подносит себе пистолет к голове по собственной инициативе.

Последствие тоже одинаковое: компания продолжает платить за существование процесса, прецеденты которого либо не запускаются вообще, либо запускаются раз в год по особой просьбе.

Как выглядит правильная развязка. Директор турфирмы-агента смотрит на цифры: туроператоры освоили интернет, клиенты покупают напрямую, доход агентской прослойки за год — символический. Решение закрыть направление принимает он, а не руководитель этого направления. Тот, если спросить его, найдёт двадцать причин потерпеть ещё год.

Правило: решение об упразднении принимает тот, кто платит. Никогда — тот, кто исполняет.

И побочный эффект смены ролей. Владелец процесса на этапах создания и на этапе исполнения — часто разные люди: схему ставит руководитель крупного подразделения, а работает по ней начальник отдела уровнем ниже. В авторитарной структуре это убивает шаг корректирующих действий: тот, кто ниже, не станет перестраивать схему, поставленную сверху. Он будет причёсывать реальность под схему, пока это возможно. В нормальной структуре ему, наоборот, скажут: «Я поставил, ты меняй, для этого ты и есть».

Архив: работа, которую никто не хочет делать

Второй шаг этапа ликвидации — сохранить всю информацию процесса. Здесь у групп наступает редкое единодушие: архив не хочет делать никто.

Причина понятна. Архивом занимаются в последние недели, когда сил уже нет. Тот, кто закрывал большой проект, знает это состояние: человек приходит домой, снимает один ботинок, начинает развязывать шнурки на втором — и открывает глаза утром, в одном ботинке, когда ребёнок идёт мимо на кухню. В таком режиме не именуют документы.

Именно поэтому имена файлов к концу выглядят как важное_сообщение_версия_115194_bis.doc, и никакая система документооборота этого не спасает.

Так зачем всё-таки архив? Четыре причины, и они разного веса.

1. Претензии, которые придут позже. Заказчик вернётся и спросит, почему было сделано так, — и сам уже не будет помнить, что этого просил.

2. Статистика вместо интуиции. Без цифр оценка риска звучит как «мне кажется, этот поставщик подведёт нас с вероятностью процентов тридцать». Это эвристика, а не управление. Здесь же — важное различение: процесс даёт статистику, проект — нет. Проект уникален, и опыт предыдущего далеко не всегда переносится на следующий. Но десять лет существования процесса, где ежедневно запускается один прецедент, дают три с половиной тысячи точек — этого достаточно для любого анализа. Оговорка, которая всё расставляет по местам: управление проектами в масштабах компании — это процесс. Для руководителя проекта его проект уникален; для директора компании это одно и то же, повторяющееся каждый день.

3. Метапроцесс. Если в компании появится или изменится другой процесс с тем же метапроцессом, ему неоткуда будет взять информацию. Ничего смертельного, но работа будет сделана заново.

4. Дисциплина по ходу. Самая недооценённая причина. Если вы заранее знаете, что архив придётся сдавать, вы держите документы в нормальном состоянии всю дорогу. Если не знаете — начинаете разгребать в момент, когда сил на это нет.

И честная оговорка о том, когда архив не нужен. Если информационная система уже фиксирует все необходимые показатели процесса — сроки, корректирующие действия, смену поставщиков, — отдельный архив не нужен, шаг можно вычеркнуть. Проверять надо именно это: фиксируется ли всё необходимое, а не «что-то фиксируется». Обычно оказывается, что сроки система пишет, а корректирующие действия — нет.

Где сегодня помогает AI. Главная беда архивов не в том, что их нет, а в том, что они нечитаемы: тысяча файлов с бессмысленными именами. Современные модели разбирают такой массив и собирают из него связную картину — кто что решал, какие были отклонения, где повторяются одни и те же грабли. Работа, на которую раньше не хватало ни у кого времени, стала выполнимой.

И ещё одно применение архива, о котором забывают. Иногда архив — самый ценный актив закрывающегося бизнеса. Клиентская база фотостудии или турагентства после закрытия стоит больше, чем стоил сам бизнес в последний год работы.

Вывод

Аудит процесса по шагам — упражнение на час, которое даёт больше, чем месяц обсуждений «как нам улучшить работу».

Три вещи стоит унести. Сначала «зачем», потом «как быстрее» — иначе вы автоматизируете красные и синие конверты и оплатите машину для сортировки правил, которых нет уже семьдесят лет. Заказчик должен быть там, где деньги: если он слишком высоко, шаг с выявлением требований превращается в фикцию, а система, которую построят по такой схеме, останется невостребованной. И закрывает процесс не тот, кто им управляет — иначе он не закроется никогда.

Следующий шаг: выпишите пять этапов жизненного цикла своего ключевого процесса и по каждому шагу поставьте плюс, минус или плюс-минус. Заполняйте не колонку с оценкой, а колонку с последствиями: что произойдёт, если этот шаг не выполняется. Если в примечаниях набралось три и больше пунктов с реальными последствиями — это и есть ваше слабое звено, а не то, что вы собирались улучшать.