Управленческие ошибки при инвестировании в технологии

9 марта 2021
Управленческие ошибки при инвестировании в технологии

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

Обычно эти ожидания оправданы, поскольку ПО обладает большим мультипликатором. Какие ошибки могут помешать реализовать потенциал интеграции и как их избежать, рассказывает Андрей Путин, управляющий партнёр ИТ-интегратора 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). Соответственно, и гипотетический мультипликатор отличается от фактического, что для стейкхолдеров может стать негативным сигналом.

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

На самом деле, этими семью ошибками дело не ограничивается. Более того, каждую из ошибок, приведённых в статье, можно декомпозировать до частных случаев и нюансов. С чем-то мы сталкивались на практике, с чем-то наверняка сталкивались вы. Приглашаю обменяться опытом в комментариях.




480
Поделиться
Предметная область
Отрасль
Управление