Топ-5 ошибок при цифровой трансформации бизнеса

Ошибки, допущенные в самом начале цифровой трансформации, обходятся компаниям очень дорого. Как обойти все грабли на пути к счастливому цифровому будущему, рассказывает заместитель директора по работе с корпоративными клиентами ALP Group Павел Мельник.

Когда мы говорим о цифровой трансформации, мы подразумеваем полноценное преобразование бизнеса и выстраивание сложного корпоративного IT-ландшафта, а не простую цифровизацию отдельных бизнес-процессов в компании. На такую трансформацию способны, по сути, только действительно крупные холдинги и корпорации.

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

1. Совмещение цифровой трансформации с трансформацией бизнеса

Создаваемая ИТ-архитектура становится неактуальной в момент трансформации бизнеса. Любая система формируется под конкретный вид бизнеса, под определенное количество пользователей и организационный объем компании. Если в ходе внедрения компания начнет менять род деятельности, тип продаваемых товаров или свою структуру, то система потребует серьезных доработок, оптимизации, а то и вовсе разработки с нуля.

Вы скажете, что никто в здравом уме не станет перекраивать бизнес-процессы параллельно с внедрением ERP-системы. Но мы видим такие примеры на каждом шагу! В моей практике, например, был случай, когда структура заказчика со множеством «дочек» схлопнулась в одну компанию с единой базой данных. Долгие месяцы мы работали над многофилиальной системой, с соответствующими обменами данных, десятком серверов, заведением первичной документации, консолидацией отчетов и быстрым закрытием периода в филиалах. Внезапно первичка появилась в головной компании, а механизм быстрого закрытия периода перестал работать. В результате нам пришлось серьезно менять подход к внедрению и перепиливать систему уже на стадии эксплуатации.

Был и другой случай, когда поменялась не только структура компании, но даже суть бизнеса. В группе компаний заказчика были предприятия, которые занимались финансовой и туристической деятельностью. Во время подготовки к МСФО и бюджетированию к ГК добавились производственные предприятия, а туристический бизнес вышел из структуры. Отсюда — совершенно другая подготовка расчетов себестоимости и бюджетирования. Ну а нам снова пришлось всё перекраивать в режиме ошпаренной кошки…

2. Невнимательное отношение к ТЗ

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

Как правило, клиенты не заморачиваются с детальным ТЗ, когда считают, что их бизнесу подойдет типовая ERP-система. К запросу на «коробочное» решение они в лучшем случае прилагают небольшой список требований по дополнительной функциональности. Например: «Мы хотим, чтобы люди получали задания через терминал, чтобы график учитывал роли и переквалификации, и чтобы производственная цепочка шла не стандартным путем, а через конкретный цех».

Мы забираем эти требования и отправляемся на внедрение… А уже в процессе узнаем, что система должна не только выдавать задания, но и фиксировать их исполнение, включая любые отклонения от плана, что она должна учитывать переделы или рассчитывать премии. И даже если мы уточняем подробности по ходу дела, к моменту сдачи продукта заказчик вдруг возмущается: «Почему вы сделали какую-то ерунду?! Так никто не делает». Мы: «Да мы знаем, что так никто не делает, но вы ведь нам так описали в письме». На что в ответ раздается коронное: «Я другое имел в виду. И вообще, это письмо было не для вас». С такой ситуацией хоть раз сталкивался любой интегратор.

3. 100% Agile

Мы уже рассказывали, что на крупных проектах по внедрению корпоративного ПО лучше всего себя показывает гибридное проектное управление. По Agile-методологиям ведутся небольшие и некритичные процессы, а по Waterfall — критичные и большие.

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

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

Важно понимать, что современные холдинги отличаются вертикально-интегрированной структурой и сквозными процессами. Это значит, что подразделения компании нельзя рассматривать в отрыве друг от друга. В противном случае, внедренная система будет выглядеть как костюм, про который шутил Аркадий Райкин. Придется ее «распарывать» и перешивать сначала.

4. Переоценка собственных сил

Еще одна распространенная проблема — когда заказчик неправильно рассчитывает свои силы (или силы подрядчика). К примеру, клиент может взять на себя обязательства по вводу первичных данных («мы же ведем весь этот учет, мы всё умеем!»). А в ходе цифровой трансформации выясняется, что в определенный период проходит двойной учет, и необходимо вводить вдвое больше первички. Люди не справляются с повышенной нагрузкой, и все сроки по проекту срываются.

5. Незаинтересованность бизнеса

Последняя, и при этом, возможно, главная ошибка — это полагать, что сторона, которая отвечает за цифровую трансформацию, может осуществить ее, не привлекая ресурсы бизнеса. Заказчик надеется, что всё сделают «под ключ», а он просто сядет работать в новой программе. Ни один такой проект из мне известных еще не заканчивался успехом.

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

Итог

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