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

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

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

Очень часто компании пытаются одновременно изменить свою бизнес-модель и внедрить новую IT-систему. Однако такая попытка привести в соответствие два столь масштабных процесса может привести к непреодолимым трудностям.

Каждая система создается для определенной структуры бизнеса: ее задачи, количество пользователей и объем данных жестко привязаны к текущим процессам компании. Если в процессе внедрения происходит значительное изменение бизнес-модели, например, смена структуры компании или пересмотр ассортимента, то новая IT-система нуждается в значительных доработках — или даже в полной переработке.

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

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

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

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

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

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

3. Абсолютная приверженность методологии Agile

Современные компании, стремясь быть гибкими, зачастую пытаются применять исключительно методологию Agile для управления проектами внедрения. Классический водопадный (Waterfall) подход кажется им «устаревшим».

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

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

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

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