Управленческие ошибки при инвестировании в технологии
Вложения в ИТ для бизнеса — как правило, практичный шаг. От каждого инвестированного рубля ждут «работы», то есть мультипликации бизнес-показателей: увеличения валового дохода, ускорения бизнес-процессов, снижения затрат и потерь и т.д.
Обычно эти ожидания оправданы, поскольку ПО обладает большим мультипликатором. Какие ошибки могут помешать реализовать потенциал интеграции и как их избежать, рассказывает Андрей Путин, управляющий партнёр ИТ-интегратора kt.team.
Ошибка № 1. ПО — это всегда silver bullet
Иногда информационные технологии воспринимаются как безотказное средство для решения любой проблемы в бизнесе. Планка ожиданий от внедрения нового ПО неоправданно завышается: от ПО ждут, что оно отладит бизнес-процессы, которых нет, выстроит систему продаж, наладит контроль качества.При таком уровне ожиданий топ-менеджмент неизбежно бывает разочарован реальным эффектом. «Мы потратили миллионы на CRM, а клиенты по-прежнему не хотят заказывать наши насосы». Вывод: это плохая CRM или внедрением занимался плохой подрядчик.
Как правильно: ПО помогает оптимизировать бизнес-процессыНо для этого бизнес-процессы, во-первых, должны быть , во-вторых, должны быть описаны и, в-третьих, должны выполняться.
Причиной низких продаж могут быть упущенные лиды. А может, менеджер по продажам ошибается в написании email-адресов. Или у вас неконкурентные цены. Или качество насосов низкое, потому что нет чётко выстроенного процесса контроля качества. Или поставки несвоевременные из-за того, что логистические процессы не исполняются.
Чтобы понять, где именно результат «проседает», нужно выстроить процесс, обозначить контрольные точки, выбрать метрики и т. д. ПО не может заменить регулярный менеджмент. Оно автоматизирует процесс, сокращает количество ошибок и потерь — и таким образом обеспечивает мультипликацию.
В каких-то случаях при построении автоматизации приходится уточнять и прорабатывать бизнес-процессы, и это позволяет улучшать бизнес. В таких ситуациях учтите, что ПО должно обладать высокой степенью гибкости, как, например, low-code платформы.
Ошибка № 2. Модное ПО подходит всем
Успешные кейсы создают иллюзию «универсального решения», которое подходит любой компании. Менеджер переносит чужой опыт на себя: «Если компания A, компания B и компания C интегрировали в свою работу конкретную ERP-систему и довольны внедрением, эта ERP-система подойдёт и нам».Подобные экстраполяции уместны, когда речь идёт о внедрении простого ПО. Оно автоматизирует конкретную задачу с предсказуемым результатом. С ERP, CRM, OMS и другим ПО, которое решает несколько связанных задач и оптимизирует несколько процессов, результат уже не столь предсказуем. Помимо внедрения ПО, компании придётся перестраивать бизнес-процессы, а это уже другой уровень работы.
Как правильно: ИТ-консалтинг поможет подобрать ПО, оптимальное для васРабота с определённым сегментом или сферой бизнеса развивает глубинную экспертизу ИТ-директора. Но она же иногда не даёт времени или возможности ознакомиться со всем объёмом рынка ИТ-решений.
Качественный ИТ-консалтинг, напротив, обладает широкой экспертизой и по рынку ИТ-продуктов, и по внедрению этих продуктов в деятельность компаний разного масштаба и профиля. Он может сравнить решения не только по маркетинговым плюсам, но и с точки зрения «прикладных» минусов.
В сотрудничестве с консалтингом вам будет проще найти именно те из существующих решений, которые окажутся наиболее эффективными и мультиплицирующими, учитывая масштабы бизнеса, особенности его работы, объём задач.
Ошибка № 3. Если меняться, то глобально
Посыл «think big», то есть мыслить крупными масштабами, встречается у многих руководителей, вплоть до Дональда Трампа и Стива Джобса. Если уж создавать лучшее производство, то с нуля: возводить инновационные цеха, покупать «от и до» самые дорогие и производительные станки. И, конечно, в один заход выстраивать глобальную ИТ-инфраструктуру.Правда, при таком подходе от идеи до реализации пройдёт не один год. Как бизнес будет жить всё это время?
Как правильно: постоянные небольшие изменения эффективнее«Think big — start small» — более жизнеспособный подход, которому нас учат теория ограничений и кайдзен.
Чтобы повысить эффективность, необязательно строить новый завод: можно начать с одного станка, который расширит «бутылочное горлышко».
В ИТ ситуация абсолютно такая же. Огромный проект устареет ещё на этапе согласований и составления технического задания — словом, задолго до реализации. Лучшая стратегия: идти по пути коротких итераций и небольших изменений.
Результат каждой инновации в той или иной мере будет мультиплицировать бизнес-показатели. Да, каждый «множитель» будет меньше, чем у гипотетической перестроенной ИТ-инфраструктуры, но он начнёт действовать уже через пару месяцев.
Ошибка № 4. Разработка общей стратегии — бесполезная трата времени
Информационные технологии меняются слишком быстро, чтобы можно было следовать глобальному плану — он потеряет актуальность уже через полгода. Лучше проводить интеграции ситуативно, точечно. Так, как подсказывает рынок сегодня. Тем более что Agile — актуальный подход, который используют крупнейшие ИТ-компании.
Как правильно: каждое изменение работает на глобальные целиРынок действительно меняется быстро. Приходят новые игроки, открываются новые возможности, появляются новые технологии. И действовать по ситуации — нормальная бизнес-практика.
ИТ-стратегия, которая коррелирует с общей стратегией компании и учитывает её цели, метрики и перспективы, — единственный способ не потерять глобальные ориентиры. В противном случае велик риск распылить своё внимание (и деньги) на решения, которые сегодня кажутся удачными и перспективными, но никак не работают на компанию в долгосрочной перспективе.
Это не означает, что в ИТ-стратегии должны быть прописаны все ходы на пять лет вперёд: динамика рынка не позволяет детализировать отдалённые задачи. Достаточно общего вектора и стратегии компании в целом. Их соблюдение позволит выбирать наиболее эффективные ИТ-решения для мультипликации ключевых показателей.
Ошибка № 5. Центр принятия решений отделён от проектной команды
В «красных» или «синих» компаниях (см. теорию спиральной динамики) к каждому внедрению нового ПО относятся как к сугубо стратегическому процессу, в рамках которого все решения должны проходить через C-level. Неважно, идёт ли речь о цифровой трансформации или об автоматизации последней мили.Менеджеры среднего звена присутствуют в проектной команде исключительно в виде проводников информации: они посещают промежуточные встречи с исполнителями и снимают с руководства некоторую часть нагрузки. Но прав что-то решать у них нет.
Цифровая трансформация в таких компаниях вряд ли возможна в принципе. «Пропускная способность» у центров принятия решений в них невелика, а значит, процесс трансформации каждый день будет «спотыкаться» о согласования, совещания, утверждения.
В «красных» компаниях решения высшего звена не подразумевают обратной связи ни на одном из этапов внедрения — подчинённые просто боятся давать фидбэк. В «синих» компаниях внедрению мешает ещё и страх изменений, ведь цифровая трансформация по определению связана с изменением устоявшихся процессов.
Как правильно: проектная команда, которая имеет право принимать решения по цифровой трансформацииДовольно простой совет: проектная команда должна одновременно быть и центром принятия решений.
Почему это важно? Повышается скорость реализации, облегчается получение обратной связи от конечных пользователей ПО. Нет многоуровневой иерархии принятия решений, а значит, изменения быстрее начинают влиять на ключевые показатели работы компании.
Ошибка № 6. Неправильно выстроена коммуникация с подрядчиком
ИТ-подрядчик — простой исполнитель. Ему необязательно знать ваши цели, метрики, KPI, чтобы выполнить свою работу. Более того, вам тоже необязательно опираться на метрики при реализации проекта. Главное — ощущения от процесса реализации: достаточно ли быстро он проходит, всё ли соответствует плану.Как правильно: ориентироваться на чёткие метрики
Личные ощущения — плохой ориентир при реализации проекта. Они всегда субъективны и не дают никакой обоснованной информации, особенно на промежуточных отсечках.
Наличие метрик и KPI позволяет вести более конструктивный диалог с подрядчиком. Не на уровне «мне что-то не нравится», а на уровне взаимосвязи работы с конкретными измеримыми результатами, со скоростью бизнес-процессов и т. д.
Метрики позволят вам фиксировать, всё ли в проекте соответствует плану (и насколько соответствует), и своевременно вносить коррективы. То есть, по сути, работать по Scrum — небольшими итерациями с понятными метриками и целями.
Для подрядчика наличие метрик — тоже важный показатель. Зная, каких результатов вы ожидаете, он сможет предложить вам оптимальные решения. Где-то, например, предложит заменить выбранную технологию на альтернативную, которая больше соответствует вашим целям, или предложит low-code решение вместо традиционной разработки.
Благодаря такому проекту вы с большой долей вероятности получите от внедрения именно тот технологический и финансовый результат, на который рассчитывали.
Ошибка № 7. Для расчёта ROI внедрения достаточно стоимости лицензий
Стоимость внедрения ПО и её ROI — достаточно простая величина. Она вычисляется по стоимости лицензий выбранного ПО и стоимости интеграции. Интеграцию оценит подрядчик до заключения договора: заказчик предоставит ему подробное ТЗ, чтобы получить достоверную оценку.Далее ПО только приносит деньги, единственные возможные расходы в перспективе — возобновление действия лицензий и оплата услуг облачных сервисов.
Как правильно: стоимость владения ПО — тоже часть формулы ROIИнтеграция ПО в инфраструктуру компании — это только начало. По мере роста ИТ-инфраструктуры, появления новых интеграций (внутренних и внешних), изменений в инфраструктуре партнёров и т. д. приходится вносить изменения в код.
Это не только затраты на разработку — неважно, внутреннюю или внешнюю, — но и аналитическая работа, совещания, согласования, возможные потери от несвоевременных изменений.
Эти затраты часто забывают учитывать при расчёте ROI. Как следствие, предварительный расчёт (to-go ROI) радикально отличается от фактического (to-date ROI). Соответственно, и гипотетический мультипликатор отличается от фактического, что для стейкхолдеров может стать негативным сигналом.
Единственный способ синхронизировать план и факт — учесть в расчётах все переменные. С одной стороны, с этим должен помочь подрядчик: он даст примерную оценку по изменениям в часах и стоимости. С другой — как технический директор, вы по опыту можете вывести примерную стоимость внутренних согласований и утверждений и предоставить её финансовым аналитикам для оценки.
На самом деле, этими семью ошибками дело не ограничивается. Более того, каждую из ошибок, приведённых в статье, можно декомпозировать до частных случаев и нюансов. С чем-то мы сталкивались на практике, с чем-то наверняка сталкивались вы. Приглашаю обменяться опытом в комментариях.
