Внедрение IBP: риски и ключевые шаги трансформации
Проектирование и внедрение процесса интегрированного бизнес‑планирования – это сложный, многоступенчатый эволюционный процесс трансформации компании от матрицы взаимодействия функций и календаря кроссфункциональных комитетов до системы целеполагания и мотивации. А его автоматизация сама по себе является вторым по сложности и масштабности влияния на бизнес типом проектов после внедрения ERP‑cистем.
Не пытайтесь мгновенно превратить IBP в мечту: это чревато не только пустой тратой времени и средств (которых сейчас ни у кого нет), но потерей ориентации в целеполагании, подменой приоритетов и фокусировании на ненужных задачах со всеми вытекающими. Но другого рынка (продавцов и покупателей) у нас с вами нет, поэтому попытаемся разобраться в том, где мы, как мы здесь оказались, и что со всем этим делать.
Что выросло – то выросло. А что выросло?
– Мальчик, сколько тебе лет?
– Скоро восемь, а пока три…
Наш рынок пребывает примерно в таком состоянии. Важность IBP‑процессов понимают все, запрос на решения такого класса огромен, но… Объективно говоря, его пока нечем удовлетворить. При этом старые глобальные «монстры» (SAP APO, BlueYonder, Kinaxis и др.) хоть и формально ушли с рынка, но фактически продолжают определять ИТ‑ландшафт крупных компаний, правда без развития и официальной поддержки. Это создаёт уникальную зону риска: критическая ИТ‑инфраструктура и бизнес‑процессы держатся на устаревших, невоспроизводимых и неразвиваемых системах. Компании вынуждены жить в режиме «отсроченной катастрофы» и приделывания дополнительных «костылей».
Крупные и зрелые заказчики это понимают, и находятся в режиме постоянного поиска — смотрят на все, что содержит буквы IBP в описании.
Рынок решений на сегодняшний день представляет собой богатый калейдоскоп, который порой вызывает недоумение:
- Понятие «продукт» искажено. Под ним часто предлагается красивое демо («а все остальное мы под вас напишем»), low‑code конструктор («а все остальное вы сами напишите»), или просто консалтинг с косметическими UI‑надстройками.
- Форк нецелевых систем, «натянутый» на функциональность IBP.
В своё время Anaplan (система, выросшая из модуля финансовой отчетности и планирования) по понятным причинам не воспринимался как альтернатива решениям уровня SAP APO или Quintiq. Но сейчас эта тенденция поменялась и снова почему‑то считается, что непрофильные системы способны решить требуемую задачу. А что – планирование и там, и там…
Упускается из вида, что планирование цепочки поставок требует много специфичных задач: моделирование ЦП, прогнозирование и понимание структуры спроса, интеграция с другими модулями (производство, продажи и т.п). - Незрелость решений прячется за гибкостью, по сути, перекладывая всю работу на заказчика.
«Мы напишем все процессы специально под вас!», – прекрасно, а до меня вы чем занимались? Или вы на мне будете всё отрабатывать? «Зато это дешево и все будет сделано только под вас!» (но это не точно). - Архитектура не приспособлена к высоким нагрузкам сложных задач и цепочек поставок.
Проблемы с откликом и производительностью, сайзинг систем – эти глубоко технические, подкапотные параметры часто выступают ограничителем работы системы и функционирования всего бизнес‑процесса.
В результате таких кавалерийских атак на сложную задачу проектирования и автоматизации процессов в первую очередь страдают сами вендоры:
- Быстрый старт, много проектов – не справились с масштабированием
- Задержка проекта – сash‑flow проблемы, перекладываемые на клиента
- Утонули в техническом долге…
- Проекты начинаются как MVP и «зависают» на стадии POC с кучей «костылей»
- Большие и объективно сложные и зрелые проекты оказываются изгоями, потому что все жаждут быстрых побед
Получается, что стратегия быстрых побед разрушает доверие к самому термину IBP. Все стараются, что‑то активно и очень усердно делают, а результат… Нет, конечно он не нулевой, но на мой взгляд точно не соответствует затраченным усилиям…
По факту рынок не эволюционирует – он имитирует зрелость. В итоге конкуренция сводится к демпингу по цене и соревнованию маркетологов…
Пелена на глазах у заказчика
Нет конечно, проблема не только в вендорах. Сами заказчики тоже подливают масла в огонь. А поскольку клиент у нас всегда прав – вот и приходится выполнять все пожелания клиента вместо того, чтобы выстроить с ним долгосрочную стратегию развития.
А желание продать (главное войти в проект – там разберемся!), наложенное на определенные предрассудки и иллюзии об IBP‑процессе у клиента, превращается не просто в туман, а в настоящую пелену на глазах заказчика:
- Поиск волшебной таблетки. Целевые процессы еще не спроектированы и не прописаны, а уже хочется системы, которая решит все проблемы. Ну и конечно менеджеры по продажам именно так и рассказывают, даже гарантируют.
- Вера в волшебную шляпу фокусника, отсутствие понимания сути задачи. Раньше (10 лет назад и ранее) системы обладали магическим свойством «лучшие отраслевые практики», и на тот момент это было действительно конкурентным преимуществом. Оно в общем‑то и сейчас осталось, но у крупных ИТ и индустриальных гигантов, которые обладают огромным опытом и уже проинвестировали в свое решение сотни тысяч, а то и миллионы человеко‑дней. Для создания более‑менее зрелой системы IBP необходимо порядка 60 тыс человек‑дней – SAP существует более 50 лет, представьте объем инвестиций в разработку. Ожидание, что лучшие практики сразу же заработают, как только компания воткнет флешку с продуктом в компьютер, губит заказчика, потому что:
- Эти лучшие практики надо правильно адаптировать и использовать их сильные стороны (см пункт выше), что невозможно без редизайна процессов.
- Требования со стороны бизнеса меняются катастрофически быстро, а значит и лучшие практики так же быстро устаревают.
- Как таковых лучших практик в современных IBP решениях нет ни у кого. Нет, конечно, что‑то там имеется: последовательность шагов S&OP цикла, CPFR, MRP, MRP II, DDMRP, прогнозирование на ML и еще куча умных аббревиатур и процессов – но это точно лучшие практики? Разве все эти вещи не стали базовыми более 10 лет назад?
- А, собственно, кто носитель этих самых лучших практик? С разрывом со всем миром мы, очевидно, потеряли часть экспертизы: рынок консультантов существенно обнулился, а новые игроки банально не успели набраться опыта. Нет, конечно все не так плохо, мамонты типа меня остались и их достаточно много, но наличие реальной бизнес‑экспертизы в команде стало дифференциатором среди решений.
- Завышенная планка ожиданий. «Мы хотим, чтобы все наши требования были сразу реализованы в системе!», – желание конечно понятное и в целом благое. Но оно точно адекватное? Может вместо выжимания всех соков из своего вендора лучше начать строить центр компетенций у себя и последовательными волнами повышать зрелость своих процессов и своего решения? Ведь пока вы стремитесь к идеалу в ходе проекта, полноценные эффекты для бизнеса не получаете, и проект превращается с вещь в себе.
- Смешиваются ожидания – вся команда топов хочет кнопку «идеальный план», которая все посчитает, и P&L, и промостратегию, и план производства. В то же время внутри контура IBP существуют системы разных классов (SCP, EPM, MES, Control Tower), каждая из которых имеет свою специализацию и требует интеграции в общий контур. Но почему‑то вендоры об этом не рассказывают и питают заказчика иллюзиями, что «все будет считаться мгновенно»… Интересно, почему?
- При всем при этом фактор большой политики никто не отменял, и публично неудачные проекты таковыми не признает почти никто.
Над всем этим грозно свисает наш SHIVA‑мир, «сложная, но интересная» экономическая ситуация, вызовы по оптимизации у абсолютно всех компаний и желание быстро получить эффекты.
Что со всем этим делать
Многие компании сейчас стоят на пороге принятия решения о выборе вендора и партнера по автоматизации IBP‑процесcа. Ниже рекомендации, как это сделать наиболее взвешенно и осознанно, чтобы потом не пожалеть о сделанном выборе.
1. Автоматизация IBP‑процесса – это завершающий этап комплексной трансформации бизнеса.
В начале идет оценка бизнес‑кейса, проектирование целевых процессов и операционной модели, внедрение изменений и оценка эффектов от пилотов. Этот классический подход сформирован не просто так. Если вас жизнь вынуждает иди по ускоренному сценарию (совмещение цифровизации с трансформацией) все дополнительные аспекты необходимо учитывать и планировать. Не надо питать себя иллюзиями, что все уложится само собой – наоборот, цифровизация только обострит имеющиеся неэффективности и пробелы в бизнес‑процессах.
2. Приступайте к выбору решения только после того, как пропишите целевые процессы.
3. Да, скорее всего вы их не сделаете самостоятельно, вам понадобится консалтинг. Его можно и нужно привлечь для этой задачи. Либо он есть у серьезного вендора. Ах нет? Хм, а почему?
Очевидно, что чем лучше ваши ФТ проработаны, тем более подходящую систему вы выберете (но это не точно – «заливать» все коммерсы сейчас умеют отлично).
Ваш потенциальный вендор вам гарантирует, то это все будет сделано в ходе проекта, но он уже заранее знает, что система вам идеально подойдет? Смело идите в проект, вендор знает говорит и вас ждет успех. Или нет?
4. Оценивайте общую стоимость владения системой (TCO) с момента старта проекта и на 3‑5 лет (допустим). Какие тут могут вылезти сюрпризы:
- Проектная стоимость минимальная, близкая к нулю (10 млн руб за модуль – это реально около нуля), а все затраты перенесены на последующие этапы, доработки и релизы, когда клиент уже завяз в проекте и отказаться не может.
- Сама стоимость системы минимальная, а вот ее интеграция в enterprise ИТ‑ландшафт – очень высокая.
- В ряде случаев доработки невозможны по технологическим причинам.
5. Считайте полноценный бизнес‑кейс от внедрения, а не только затратную часть. Формулируйте достижение бизнес‑эффектов в целях проекта. Это поможет вам не зацикливаться на стоимости, а видеть конечную цель и двигаться к ней. Конечно, 10 млн руб против 100 млн руб (например) – кардинальная разница. Но потерянные 10 млн руб. куда менее значимы, чем, например, недополученный 1 млрд.
6. Владельцем, ответственным за проект и принятие решения о выборе партнера должен быть человек уровня СЕО‑1. У всех остальных ниже уровнем может работать мотивация «если что – свалю на подрядчика».
7. При планировании работ проекта отдельно зафиксируйте жесткие вехи, которые не могут быть нарушены без последствий (лишение бонусной части команды, разрыв контракта, невыплата части суммы, сумасшедшие штрафы и т.п.) ни при каких обстоятельствах. Ни в коем случае не ведитесь на слова про продуктовый подход, гибкую разработку, agile и и прочие красивые фразы – подрядчик просто морочит вам голову и заранее «подкладывает соломку» для своей безответственности.
8. Для каждого этапа планируйте сценарий отката к старой функциональности или отказа от вендора и не стесняйтесь им пользоваться. Многие вендоры специально строят стратегию проекта таким образом, чтобы заказчик никуда не смог «сбежать».
9. Выбор вендора – это самостоятельный сложный проект, не стоит его делать «на бегу».
Например, в моей прошлой жизни этот проект длился около 6 месяцев – это, не считая подготовки ТЗ. Проверяйте шорт‑лист на пилотах (лучше даже за деньги), обсуждайте готовность на “success fee”, тестируйте сайзинг, соберите бизнесовый “steering committee” наконец. Тема критериев выбора достойна отдельной статьи.
10. При выборе оценивайте не только само решение, но и команду, которая будет его внедрять и развивать.
Банально, а есть ли она физически? Очень часто оказывается, что после внедрения (или даже в ходе него) команда растворяется – уходит к конкурентам, компанию поглощают и перенаправляют на другие задачи.
11. С самого начала закладывайте в план проекта создание центра компетенций. Интегрированное планирование – это реально элемент конкурентного преимущества. Поэтому нельзя полагаться на красивые обещания вендора о вечной поддержке и гибкой разработке. Более того, в какой‑то момент (и весьма скоро), мы поймете, что лучше знаете, что вам нужно и захотите это сделать сами. На этапе выбора вендора этот фактор надо учитывать: способен ли он организовать обучение, есть ли опыт создания таких центров, готов ли поддержать организационные изменения внутри компании и т.д.
Глобально говоря, вы выбираете не решение, не вендора, не платформу, а стратегического партнера. Который может как обеспечить вашей компании стратегическое конкурентное преимущество за счет эффективного IBP процесса, так и разрушить его.