Если вы когда-либо сталкивались с отказом в поддержке вашей инициативы или сейчас готовитесь защищать новый проект, наш опыт может оказаться полезным.
Мы расскажем, как сформулировать гипотезу, превратить ее в проект, учесть особенности мышления тех, кто принимает решения, и выйти на защиту с высокими шансами на успех. Все это — на примере реального кейса, где один из нас (Алексей) выступал в роли инициатора и исполнителя, а другой (Тарас) помогал в роли внешнего советника и иногда даже адвоката дьявола.
Описание проекта
Как это часто бывает в компаниях, где ИТ-ландшафт развивался методом коллективного написания письма в Простоквашино (если забыли, финальная версия описывала «вашего сына Дядю Шарика, у которого то лапы ломит, то хвост отваливается»), розничная сеть к моменту старта проекта оказалась в типичной для таких случаев ситуации. В компании использовалось сразу несколько различных систем построения корпоративной отчетности — все на разной стадии внедрения и зрелости. Корпоративное хранилище данных (DWH) не обладало исчерпывающим набором информации для построения отчетов. Не было единой версии правды: значения одних и тех же показателей могли существенно отличаться в разных системах. Подготовка и поддержка отчетности требовала колоссальных усилий как со стороны ИТ, так и со стороны бизнеса. И, наконец, секретная последовательность шагов по превращению набора Excel-файлов в корректный с точки зрения руководства отчет часто находилась исключительно в голове одного конкретного сотрудника с риском исчезнуть при его увольнении или отпуске.
Гипотеза, лежащая в основе проекта, звучала просто: если сократить количество систем отчетности и, за счет этого, сэкономить на стоимости их поддержки и используемой инфраструктуре; если доработать DWH так, чтобы в нем появились все необходимые для бизнес-аналитики данные; если автоматизировать ключевые отчеты и избавиться от ручного трудаи в результате предоставить сотрудникам бизнес-подразделений возможность самостоятельно исследовать данные в рамках единой BI-системы, без необходимости привлекать ИТ, то итоговая экономия должна будет с запасом покрыть все затраты на реализацию этой инициативы.
Критерии принятия решения по проекту
Прежде чем разворачивать гипотезу в полноценный проект и двигаться дальше по корпоративной процедуре, стоит остановиться на двух вещах, без понимания которых шансы на успешную защиту стремятся к нулю. Это психология принятия решений топ-менеджментом и критерии, на основании которых эти решения вообще принимаются.
Для наемного менеджера среднего звена деньги компании — просто цифры в Excel, инструмент достижения личных целей. Вы не вкладываете свои средства, ничем особенно не рискуете, и, в худшем случае, останетесь без премии за провальный проект. Ну или, если совсем не повезет, попросят на выход. Но и тогда вы все равно в плюсе: приобрели опыт за счет компании, получали зарплату, пока занимались неудачной инициативой, и еще, возможно, получили выходное пособие. Через пару недель будете уже в другой организации запускать аналогичный проект.
Компания же в результате получает потраченное время, ресурсы и прямые финансовые или репутационные потери. Именно для того, чтобы таких ситуаций не возникало, на позиции топ-менеджеров приходят люди, представляющие интересы акционеров, а часто сами и являющиеся ими. Поэтому они оценивают инициативы не в логике «верим — не верим», «надо — не надо», «у конкурентов есть — и мы хотим», а исключительно через призму бизнес-результатов. Все упирается во влияние на финансовые показатели компании и, как следствие, на размер их собственных бонусов.
Ключевое, что интересует первую линейку — это четыре простых и беспощадных вопроса. Повлияет ли проект на P&L, то есть приведет ли он к росту выручки или снижению затрат, а, лучше, к обоим эффектам сразу? Какие другие проекты не получат финансирования , если выберут именно вашу инициативу? Какие риски несет проект — технологические, операционные, рыночные, юридические? И, наконец, в какие сроки все будет завершено и когда начнется окупаемость?
И здесь не получится сказать, что какой-то из этих пунктов менее важен, чем остальные. Они работают только в комплексе.
Бюджета на все никогда не хватит. Всегда будет конкуренция — за рубль, за внимание, за ресурс. Каждый вложенный в ИТ рубль — это рубль, который не пошел на маркетинг, на открытие новых точек, на закупку продукции. А поскольку планировать далеко вперед в текущих условиях практически невозможно, приоритет часто отдают тем проектам, которые приносят эффект здесь и сейчас. Высокая ключевая ставка тоже добавляет прагматизма: если срок окупаемости проекта растягивается, проще положить эти деньги в банк под процент, и многие компании именно так и поступают.
Поэтому ключевым элементом вашей защиты становится финансовая модель, или, если классически, технико-экономическое обоснование (ТЭО).
Технико-экономическое обоснование проекта
Базово существует три сценария: проект либо напрямую приносит компании доход; либо является enabler’ом – не зарабатывает сам, но открывает возможности для роста; либо просто экономит деньги, позволяя делать тот же объем работы дешевле или больше работы за те же деньги. В идеале, конечно, комбо: больше работы за меньшие деньги.
Нашему проекту как раз выпал шанс попасть в эту идеальную категорию: по замыслу, он одновременно должен был и повысить эффективность труда, и сократить затраты. То есть, как говорится, и рыбку съесть, и бюджет оптимизировать.
На этапе анализа мы пошли по самому банальному пути — с секундомером в руках. Посетили все подразделения, задействованные в подготовке отчетности, оцифровали текущие процессы, составили реестр операций, провели валидацию с исполнителями и руководителями. В результате получили ключевую цифру: сколько человеко-часов можно освободить ежемесячно за счет автоматизации. С финансистами эти часы были переведены в рубли.
Добавили прямую экономию на поддержке разношерстных BI-систем — инфраструктура, лицензии, саппорт: сегодня на это уходит X рублей, после проекта будет Y. Учли и сокращение числа сотрудников, занятых в отчетности, в тех случаях, где это возможно.
Не забыли и про косвенную экономию. Автоматизация снимает с ИТ необходимость вручную подготавливать данные для отчетов, высвобождает ресурсы и позволяет обрабатывать накопившийся бэклог бизнесовых задач без расширения команды. То же касается сотрудников бизнес-подразделений: часть из них не будет сокращена, а просто переключится на другие задачи, что избавит от необходимости нанимать новых людей в другие функции.
Так сформировалась доходная часть проекта или предполагаемая экономия, распределенная по всем вовлеченным подразделениям.
Расходная часть оказалась вполне ожидаемой: лицензии, инфраструктура, доработки DWH, миграция данных, изменения во внутренних системах, обучение пользователей. Все это собрано, подсчитано, P&L проекта построен — и результат положительный.
Можно ли на этом этапе идти на защиту? Пока нет. И вот почему.
Любой проект — это не гарантия, а гипотеза. На защите вы не продаете результат, вы продаете веру в то, что именно предложенным вами способом можно достичь описанного эффекта. Проект — это всегда набор вероятностей: насколько точно оценен эффект, реально ли уложиться в сроки и бюджет, какие есть риски, насколько они критичны и какие изменения приоритетов могут произойти в компании за время его реализации.
И чем дороже проект, тем выше требования к обоснованности, зрелости и уровню проработки. Недостаточно просто принести расчеты. Важно честно показать, с какой степенью неопределенности вы работаете. Как вы оцениваете точность своих расчетов? Какие видите риски и что предлагаете, чтобы их снизить? Какие альтернативы рассматривались и почему именно этот вариант оказался предпочтительным? Кто, кроме вас, поддерживает проект и разделяет уверенность в нем?
Такой подход вызывает больше доверия и, как нам кажется, является единственно рабочим. Показ best case-сценария без обсуждения рисков — путь в никуда. А если вы демонстрируете осознанность, понимаете уязвимости проекта и показываете, как будете с ними работать, то вы снижаете тревожность у тех, кто принимает решение. И, между прочим, свою собственную тоже.
О важности поиска союзников
Если ваша идея действительно способна помочь какому-то подразделению, например, сократить прямые или непрямые финансовые потери, увеличить доходы или открыть новые возможности, то обсудите ее с этим подразделением еще до того, как вы двинетесь по формальной процедуре. Чем раньше вы начнете рассказывать о своем проекте заинтересованным коллегам, чем больше союзников привлечете на этапе подготовки, тем меньше вероятность, что упустите что-то важное, и тем выше шанс, что вашу инициативу поддержат.
Не стоит ждать момента, когда проект дойдет до комитета, чтобы впервые показать его топ-менеджерам. К тому времени у проекта уже должны быть искренние сторонники. «Одинокие» инициативы, даже самые разумные, почти не имеют шансов на успех. А вот союзники на комитете — это ценный ресурс: они подтверждают ожидаемый эффект, выражают заинтересованность своих подразделений, показывают, что проект — это не чей-то частный интерес, а коллективная необходимость, принимают на себя часть рисков. Один в поле не воин, особенно в корпоративной среде.
В нашем случае стартовые условия были весьма благоприятными: раздражение от существующей отчетности достигло точки кипения. Не было единой версии правды — каждое подразделение оперировало своими цифрами. А объем времени, уходящего на ручную подготовку отчетов, давно вышел за пределы разумного. Так что эмоциональная почва была подготовлена заранее. Оставалось только собрать детали, подбить цифры и перевести коллективное недовольство в аргументированную поддержку проекта.
И не забывайте: в расчетах вы не просто можете, а должны учитывать не только прямой финансовый эффект для своего подразделения, но и выгоды для тех, кто станет вашим смежником и соавтором этой инициативы. Это усилит позицию и придаст проекту вес.
Как подготовить презентацию
Чтобы инициатива получила шанс, она должна быть правильно упакована. У топ менеджмента нет времени, чтобы разбираться в ваших мыслях, и нет свободной оперативной памяти, чтобы загрузить в нее все нюансы и детали, которые есть у вас.
Какая информация в презентации является обязательной:
- Резюме и ключевая суть предложения. Разумно разместить суть предложения в первом смысловом слайде презентации, чтобы сразу было понятно, о чем пойдет речь.
- Описание проблемного настоящего (состояние AS IS).
- Описание светлого будущего (состояние TO BE).
- Roadmap AS IS -> TO BE, с ориентировочными сроками;
- Сколько стоит переход в светлое будущее – финансово-экономическое обоснование проекта.
- Какие риски ждут компании на этом пути, как их снижаем, какие принимаем и почему;
- Что произойдет, если проект не выполнить или выполнить частично;
- Заключение соответствующих комитетов о том, что предлагаемое в проекте решение соответствует всем техническим политикам компании;
Детали расчетов, иные ненужные подробности или развернутые ответы на каверзные вопросы обязательно должны быть в презентации, но их необходимо вынести в конец презентации, в отдельный раздел. В них на защите погружаться не нужно, но если вдруг возникнет потребность – вы легко сможете показать нужный слайд.
Предложение должно быть четким, вода должна быть «выпарена», а мысли - кристаллизованы. Недопустимы расплывчатые формулировки без подтверждения цифрами, вида «станет удобнее работать», «будет ускорен процесс принятия решений», «станет эффективнее». Это, по факту, бесполезная вода, которая затрудняет процесс восприятия и настраивает коллег против вас.
Про визуал и подачу информации. Скорее всего, у вас в компании существуют шаблоны презентаций, и среди них есть «шаблон для защиты проекта». Если вдруг нет – воспользуйтесь в качестве ориентира презентацией с предыдущей успешной защиты. Креатив в таких делах может лишь навредить.
Важный момент: редко когда ИТ-проекты не влекут за собой существенных трат. И, даже если ваша компания не испытывает финансовых трудностей, один из показателей добросовестности, да и успешности менеджера – это реализация изменений за минимально возможный в данной ситуации бюджет (без ущерба для сути изменения, само собой).
Но легко можно оказаться в ситуации, когда уменьшить бюджет проекта уже нельзя, а он все еще слишком велик для данной конкретной компании в данный момент времени. В этом случае разбивайте проект на этапы. Защитите первый этап с минимально возможным набором работ, покажите эффект от их выполнения, подтвердите свои гипотезу и финмодель – и тогда следующие этапы защитить станет намного легче.
Особенности процедуры
Как мы уже отмечали, основная работа по защите проекта проводится ДО комитета: поиск союзников, убеждение, работа с возражениями, изменения в результате полученной конструктивной обратной связи и тд. Если подготовительная работа проделана должным образом, то результат защиты будет известен заранее, а сама процедура защиты превратится в формальное одобрение, нужное для принятия коллективной ответственности топ-менеджментом за выдвинутую инициативу согласно корпоративным регламентам.
Ситуация, которой свидетельствует о проваленной подготовке (чего всеми силами нужно избегать), когда во время доклада на какой-либо из тезисов будет возражение от того, кого выдвинутый тезис затрагивает – это прямой путь к «развивающей обратной связи» и уходу на второй круг для лучшей проработки.
В идеальном сценарии автор инициативы с коалицией союзников будут вместе доказывать остальным, почему этот проект обязательно нужно делать. Тем не менее, успешно пройденный подготовительный этап – не повод не готовиться к защите. Для доклада обязательна репетиция (dry run). Лучше – перед кем-то, чтобы понять, как доклад воспринимается слушателем и получить обратную связь. Обязательно к защите нужно подготовить ответы на наиболее вероятные вопросы, которые на ней могут задать.
Может получиться так, что инициативу примут с оговорками или признают интересной, но требующей более глубокой проработки в ряде аспектов. В таком случае непроработанные зоны подлежат обязательному внесению автором инициативы в свой собственный TODO-лист, полученные договоренности тоже. Бывает так, что итоговый протокол несколько отличается от реальной ситуации на встрече – тут и пригодятся собственные заметки.
Заключение
Топ-менеджмент не мыслит (во всяком случае, не должен, хотя корпоративная практика знает и обратные примеры) категориями «верю/не верю» или «нравится/не нравится». Экономическая ситуация, требования акционеров, действия конкурентов и желание получить свой бонус заставляют принимать решения на основе цифр, после тщательного анализа рисков и доступных альтернатив. Если вы хотите, чтобы вашу инициативу услышали и поддержали, то формулируйте ее в соответствующих терминах, на языке топ-менеджмента.
Важное замечание: отказ на профильном комитете – это не приговор. Это приглашение вам поразмышлять над вашей идей с позиций топ-менеджеров и акционеров. Приближает ли она компанию к своим стратегическим целям, или это шаг в сторону? Даст ли она бОльшую отдачу для компании, по сравнению с альтернативными вариантами инвестиций? Не слишком ли высоки риски неудачного исхода? Достаточно ли проработаны меры по их снижению?
Возможно, лучше проработав эти вопросы, вы сможете найти дополнительные аргументы для убеждения коллег при следующей попытке. Не исключено, что все эти аргументы у вас были с самого начала, и вам просто нужно поработать над их визуализацией и вашей манерой доносить их во время обсуждения.
Но не стоит отбрасывать мысль, что и аргументы, и их подача абсолютно безукоризненны, но... ваш проект компании текущих обстоятельствах не актуален.
Такой вариант не исключен: так бывает. В любом случае, всем удачных защит и интересных проектов.