Давайте посчитаем, уважаемые кроты…
Вспомним ненадолго рис. 3 из главы 4. (Для удобства читателя и устранения потерь времени при перелистывании приводим его здесь.)
Рис. 3. Фазы проектов по «улучшайзингу»
Если помните, мы говорили, что обсудим, почему контроль несколько смещен на рисунке. По сути, нужно говорить о нескольких «контролях».
1. РАЗРАБОТКА ПЛАНА КОНТРОЛЯ.
Что это такое? А это как раз наша диагностическая карта и план эвакуации в одном лице. Другими словами, набор метрик и их целевых значений, которые помогают определить, работает ли улучшенный процесс как надо или что-то в нем не так. Например, написано, что время на процесс не должно превышать 2 часа 10 минут. Кроме того, план контроля содержит конкретные шаги, которые необходимо предпринять, если время на протяжении трех дней составляет 2 часа и 30 минут или больше.
2. КОНТРОЛЬ ПРОЕКТА ПО ВОПЛОЩЕНИЮ РЕШЕНИЙ В ЖИЗНЬ.
Необходимо отслеживать ход работы над исполнением плана внедрения. И не только с точки зрения соблюдения сроков и последовательности решений, но и сохранения их ключевой сути. В противном случае можно столкнуться с ситуацией, когда все формальные требования соблюдены, но ничего не работает.
Никогда не забуду проект по улучшению закрытия операционного дня. Когда я приехал с проверкой, я испытал настоящий шок. Все требуемое оборудование было установлено, только все настройки были некорректными (и соответственно ничего не работало так, как было задумано). Апофеозом комичности был момент, когда менеджер, ответственный за проект, дал мне документацию. Сначала в первой половине стопки были все заметки и наработки команды «улучшайзинга», подчеркнутые и чуть ли не перевязанные красной ленточкой. А затем без перехода или даже какого-либо, пускай формального, объяснения – совершенно другие графики, разработки, настройки. И никто про это не знал. То есть формальности соблюли, а дальше – как хочу, так и ворочу.
3. КОНТРОЛЬ САМОГО УЛУЧШЕННОГО ПРОЦЕССА.
Вы не поверите, но план контроля нужно не только написать, но и исполнять… Замеры, которые нужно сравнивать с планом, необходимо кому-то выполнять. Проблема в том, что часто так: замерили один раз по графику (например, недели через две), и все. А зачем еще мерить, все же хорошо? Скажу по секрету, что процесс можно назвать саморегулирующимся, после того как в течение года (да-да, вы не ослышались) все показатели были в пределах допустимых отклонений или могли быть объяснены какими-либо причинами (внезапный разовый отказ энергосистем, ураган, свадьба генерального директора и т. д.).
А зачем было нужно это скучное повествование, спросите вы? Плохое понимание видов контроля приводит к появлению нескольких важных подводных камней, которые могут испортить все в последний момент.
1. КОМАНДА НЕ МЕНЯЕТСЯ ПРИ ПЕРЕХОДЕ К ВНЕДРЕНИЮ ИЛИ МЕНЯЕТСЯ ПОЛНОСТЬЮ.
И то и другое пагубно. Аналитики, выявляющие проблемы, могут не разбираться в тонкостях выбивания бюджетов, составления безразмерных заявок и убалтывания важных шишек, чтобы получить финансирование и ресурсы для претворения решений в жизнь. Другая крайность – смена команды полностью приводит к тому, что просто нет человека, который бы объяснил, что же такое гениальное они придумали, а также проконтролировал, что по пути не потеряется никаких важных деталей.
2. ПРОМЫШЛЕННОЕ ИСПОЛЬЗОВАНИЕ НАЧИНАЕТСЯ ЕЩЕ ДО ОКОНЧАНИЯ ТЕСТОВ.
На одном из моих первых проектов команде приказали вводить решение (новый ИТ-продукт), которое не было до конца протестировано. Я очень сильно возражал, но главный идеолог согласился. Оказалось, что решение не было рассчитано на огромный поток поступающих документов. А дальше у меня и коллег было 3 незабываемых бессонных недели, которые мы до сих пор вспоминаем с дрожью в голосе.
3. НИКТО НЕ ПОДТВЕРЖДАЕТ ЭФФЕКТ И НЕ ПОДВОДИТ ИТОГИ.
Если вы помните, в начале проекта мы устанавливаем цели, которых, по идее, должны достичь. По моему опыту только в 30 % проектов по «улучшайзингу» кто-то вообще о них вспоминает в конце.
Да и зачем? Вы провернули сложное дело (действительно сложное, без капли сарказма). Разработали супер-пупер прикольный процесс, способ, штуковину (сарказм нарастает). Кому какое дело до того, что там в начале накалякали на бумажке (крещендо!).
СУТЬ ПРОЕКТНОЙ ДЕЯТЕЛЬНОСТИ В ТОМ, ЧТОБЫ СОЗДАВАТЬ И ПРОБОВАТЬ, А НЕ ИСКАТЬ ЕДИНСТВЕННО ПРАВИЛЬНЫЙ ОТВЕТ.
Никого при этом не смущает, что:
– цели не достигнуты частично или полностью;
– мы получили совсем другие результаты, то есть не то, что мы планировали (повысили скорость обслуживания, а должны были снизить количество брака);
– расчет эффекта от проекта не позволяет определить, достигли мы чего-то или нет.
Отдельно стоит рассказать про подсчет эффекта.
Во-первых, чаще всего в момент тестирования решения очень сложно дать фактически подтвержденный эффект, поскольку еще требуется время (месяцы, полугодия), чтобы подтвердить его на практике. Но эффект считается на момент создания плана контроля. И получается, что на бумаге эффект огромен, но спустя год его никто не проверяет и сказать достигла ли команда хоть чего-либо, достоверно невозможно.
Во-вторых, при подсчете нет учета затрат. А зачем? Мы же делали интеллектуальное упражнение, в командировки не ездили и т. д. Но позвольте, команда тратила свое время (которое можно учесть в деньгах), значит, компания несла альтернативные издержки, связанные с тем, что работу за членов команды либо никто не делал, либо пришлось перераспределять обязанности и повышать нагрузку.
Ну и наконец, в-третьих, помните детскую загадку «на одной березке росло 3 яблока, а на другой 4. Сколько всего яблок?»? Правильный ответ: на березах яблоки не растут. Абсолютно не важно, что новый продукт может варить кофе, если при этом качество управления как было плохим, так таким и осталось. Тут двух мнений быть не может. Такой проект стоит признать провальным.
