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

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

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

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

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

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

2. Невнимательное отношение к техническому заданию

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

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

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

3. 100% Agile

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

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

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

***

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

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