Проверьте: 5 дорогих ошибок при цифровизации бизнеса в Казахстане

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

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

Ошибка №1. Начинать проект без бизнес-цели и измеримого результата

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

В IBA Group рекомендуют начинать проект по внедрению ERP-системы не с выбора платформы или расчета бюджета, а с ответа на вопрос, какую задачу бизнеса компания решает этим внедрением. Бизнес-цель отвечает на вопрос «что изменится в работе компании», а не только «какую систему необходимо заменить».

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

Ошибка №2. Писать техническое задание только силами своих сотрудников

Это одна из самых дорогих ошибок. Сотрудники предприятия хорошо знают собственные процессы, но не всегда знают возможности SAP S/4HANA. Поэтому они могут описывать будущую систему так, как компания работает сегодня, а не так, как процессы должны быть устроены после внедрения.

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

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

Ошибка №3. Считать бюджет раньше технического задания

Обычно компания сначала определяет сумму, которую готова потратить на внедрение, а уже затем ищет исполнителя. В SAP-проектах последовательность должна быть обратной: сначала появляется техническое задание, затем компания собирает и сопоставляет предложения подрядчиков, и только после этого утверждает бюджет, рассчитанный по реальному объему работ.

Сумма, названная до подготовки требований, ничем не обоснована. Компания узнает об этом уже на тендере, когда предложения подрядчиков оказываются выше заложенной цифры. Затем приходится либо увеличивать бюджет, либо сокращать объем проекта. Оба решения принимаются в спешке, потому что сроки перехода на SAP S/4HANA к этому моменту уже определены.

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

Ошибка №4. Переносить старые процессы в новую систему

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

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

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

Ошибка №5. Распускать проектный офис после подписания договора

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

Проектный офис, который готовил ТЗ, должен оставаться на стороне заказчика до завершения внедрения. Его участники отвечают на вопросы консультантов, принимают решения по спорным вопросам, согласовывают изменение объема работ и проверяют, что готовая система соответствует утвержденным требованиям.

Что сделать до старта проекта

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

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

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