Трекинг для большой корпорации

Как отказаться от автоматизации процессов и… сэкономить сумму с 9-ю нолями

Сегодня у меня в гостях Дмитрий Морозов — выпускник нашей Школы и опытный трекер.

Дальше — кейс из первых уст:

«Мой собственный предпринимательский путь начался ещё в 1999 году в семейном бизнесе, а продолжился в корпоративном сегменте и собственных проектах.

Я больше 15-ти лет управлял проектами в системной интеграции для крупных госкомпаний и больших корпораций. Среди моих клиентов были «Росатом», Минобороны, Росавиация и подобные компании.

В прошлом году я закончил Школу трекеров Евгения Калинина и как трекер выбрал себе два направления — IT и производство. Хочу поделиться одним интересным кейсом из моей трекерской практики.

Моя история будет описана в общем виде, так как все детали и цифры под NDA.

Год назад меня пригласили стать корпоративным трекером проекта оптимизации технических решений внутри проектного института в одной крупной промышленной компании. Этот институт разрабатывает технические проекты ремонтов, реконструкции и строительства под внутренние запросы корпорации.

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

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

Руководители проектного института поняли, что можно сильно сэкономить деньги и время, если автоматизировать процесс принятия таких решений. Для этого было решено создать ПО, которое помогало бы инженерам-проектировщикам их искать.

Дважды проект останавливался на этапе написания ТЗ для этой программы. Потом они обратились ко мне как к трекеру. Моей задачей стало помочь разработать и внедрить эту систему.

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

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

Мы с командой составили список заинтересованных лиц: менеджеров, ГИПов, проектировщиков, чтобы найти среди них того, чью проблему решает система. Мы подготовились, составили структуру интервью, и команда пошла разговаривать со стейкхолдерами о том, как люди из этого проектного института в принципе принимают инженерные решения и что им мешает принимать более экономически эффективные. То есть, начали проводить клиентские интервью.

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

В первом учебнике трекинга Евгения Калинина, customer development — это самый главный бизнес-процесс. Он никогда не прекращается, ведь за счёт получения обратной связи от клиента можно понять решает ваш продукт его проблему или нет, получает клиент ценность от него или нет, постоянно развивать и адаптировать его к рынку. В книге Евгения есть подробный план, как правильно построить кастдев и даже скрипт проблемного интервью, по которому можно поговорить с потенциальным клиентом и оценить его готовность к покупке продукта.

В результате интервью случились два важных открытия.

Первое: проектировщики в этом бизнес-процессе не несут ответственность за стоимость инженерных решений и поэтому совершенно не заинтересованы в поиске лучшего.

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

Так мы сэкономили деньги компании, отказавшись от идеи разработки дорогой системы, которая могла бы сохранить деньги в будущем.

Вместо этого мы стали искать способы повысить ответственность проектировщиков и стимулировать их выбирать оптимальное техническое решение.

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

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

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

Вторым нашим шагом был регламент, который объяснял почему методика принятия решения должна быть именно такая и никакая другая.

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

Мы с командой сделали так, что экономия и верификация решений стала происходить сама.

Четыре месяца мы потратили на исследование и разработку MVP, месяц на внедрение и анализ его результатов. Всё заработало, и в итоге такой подход распространили на весь институт.

Руководство было в восторге, а экономический эффект через год превысил цифру с 9-ю нулями.

Если говорить о методологии, то внутри корпорации был уже свой продуктовый фрейм — зрелый процесс сопровождения инициативы (гипотеза, исследования, MVP и т.д.). Как трекер я в него встроился уже со своими инструментами.

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

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

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

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

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

Если вам понравился мой кейс — приходите в мой Telegram-канал, он называется «Первый Ярд»: там есть и другие кейсы, и мои наблюдения о жизни. А если вам хочется больше узнать про трекинг, наконец перестать страдать и начать делать бизнес — читайте книгу «Фокусируйся» Евгения Калинина. Инструменты методологии и разные хаки он разбирает в канале Школы трекеров — там всё коротко, просто и понятно».