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