5 проблем при внедрении 1С:ERP и как их избежать: опыт интегратора 30+ лет

Внедрение системы управления ресурсами предприятия (ERP) на платформе 1С – сложный и многогранный процесс, требующий тщательной подготовки и глубокого понимания специфики бизнеса. За 30+ лет работы в сфере интеграции мы столкнулись с множеством непростых ситуаций, без решения которых успешное внедрение было бы невозможным. Основываясь на нашем опыте, мы составили обзор наиболее распространённых проблем и предложили способы их предотвращения.

Типовые ошибки при внедрении 1С:ERP

1. Недостаточное, некачественное обследование

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

1.1. Внедрённая система не соответствует процессам и требованиям Заказчика

Это основная проблема, когда система не решает реальные задачи бизнеса.

• Автоматизация "как есть" (as is), а не "как должно быть" (to be). Если в процессе обследования вы изучаете только "как есть", без фиксации "как должно быть", то просто не будут выявлены узкие места и неэффективные процессы, они перенесутся в новую систему со старыми проблемами. В итоге компания получает дорогостоящую автоматизацию хаоса, а не инструмент для оптимизации.
• Пропуск уникальных бизнес-процессов. В крупных предприятиях часто есть нетиповые операции (сложная логистика, специфический производственный цикл, уникальные схемы мотивации). Если их просто зафиксировать, без погружения в детали процесса, в системе просто не окажется нужных механизмов для их поддержки. Например, Заказчик говорит вам, что клиентам запрещена отгрузка в случае наличия задолженности/просроченной задолженности. Вы фиксируете данное требование и предлагаете решение с контролем задолженности в момент формирования отгрузочных документов. При этом фактически контроль задолженности осуществляется до загрузки машины, в момент формирования графика отгрузок на следующий день, то есть накануне. В этом случае схемы настройки условий и графиков оплат, а также процесс оформления документов в системе будут разными, если это не учесть на обследовании, то впоследствии будет получена система без соответствия процессам Заказчика.

1.2. Финансовые и проектные риски

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

1.3 Репутационные риски

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

Советы и рекомендации:

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

2. Неправильная оценка сроков и ресурсов

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

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

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

Советы и рекомендации:

• Составляйте реалистичные планы-графики с учётом возможных рисков.
• Адекватно оценивайте команду и ресурсы, планируйте график только в привязке к ресурсам, их доступности.
• Включайте в план-график работы Заказчика со сроками.
• Формулируйте чёткие критерии приёмки этапов работ.
• Регулярно отслеживайте прогресс выполнения задач.

3. Отсутствие вовлечённости руководства

Внедрение 1С:ERP — это не просто установка программного обеспечения, а проект по трансформации бизнес-процессов всей компании. Руководство в этом процессе должно выступать не только как заказчик, но и как главный идеолог, спонсор изменений. Отсутствие поддержки высшего руководства негативно сказывается на мотивации сотрудников и общей атмосфере проекта.

На нашем опыте были проекты, в которых директор появлялся только тогда, когда запуск системы не произошёл в плановые сроки, при этом сроки запуска были совместно пересмотрены и согласованы. Директор полностью делегировал проект ИТ-директору, а тот в свою очередь отчитывался, что "всё по плану", статус-отчеты по проекту генеральный директор не читал. Когда наступил час X, директор осознал, почему запуск сдвинут, потребовалось дополнительное финансирование.

Также одним из проявлений отсутствия вовлечённости руководства является игнорирование сопротивления персонала. Любое крупное изменение встречает сопротивление сотрудников. Если руководство не участвует в проекте, оно не может (и не хочет) выступать авторитетом, который объясняет необходимость перемен и мотивирует коллектив. В результате сотрудники саботируют внедрение.

Советы и рекомендации:

• Доносите до Заказчика, что куратором проекта должен быть представитель топ-менеджмента компании.
• Хорошей практикой является проведение установочного совещания о старте проекта с участием генерального директора, ведь никто другой не донесёт до участников ключевые цели проекта и его значимость для компании.
• Привлекайте спонсора проекта к участию во встречах управляющего комитета проекта (УКП).
• Своевременно информируйте участников УКП о возможных изменениях в сроках, границах, бюджете проекта.

4. Отсутствие этапа полноценного тестирования с привлечением конечных пользователей

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

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

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

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

Советы и рекомендации:

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

5. Технические и архитектурные проблемы

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

5.1. Проблемы с данными и нормативно-справочной информацией (НСИ)

• Низкое качество мастер-данных. Без аудита НСИ (номенклатуры, контрагентов, складов) проект сталкивается с проблемой "мусор на входе — мусор на выходе". Очистка и приведение данных к единому стандарту уже в ходе внедрения требует огромных трудозатрат и может привести к срыву сроков.
• Отсутствие единой системы кодирования. В разных подразделениях одна и та же номенклатура может называться и кодироваться по-разному. Без выявления и устранения этой проблемы в ходе обследования в 1C:ERP создается хаотичная структура справочников и возникают дубли.

5.2 Миграция исторических данных

Некоторые Заказчики требуют переноса данных и оборотов за несколько лет, а это требует разработки сложных правил трансформации. Непроработанная стратегия очистки данных перед загрузкой приводит к переносу накопленного мусора (битых ссылок, незакрытых регистров), что может привести к аварийному первому запуску системы. Это влияет на бюджет проекта, увеличивая его. Реальная необходимость в переносе оборотов требуется только для систем расчета заработной платы, для всех остальных систем, как правило, достаточно перенести НСИ и остатки, оставив доступ в старую систему на просмотр данных. В случае внедрения регламентированного учета важно корректно спланировать график работ, чтобы ОПЭ начиналась с начала года.

5.3 Избыточность кастомизации системы

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

5.4. Проблемы с производительностью

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

5.5. Проблемы с адаптацией в смежных интегрируемых системах

Внедрение 1С:ERP редко происходит обособленно. Как правило, систему необходимо корректно вписать в уже работающий ИТ-ландшафт. На предприятиях к моменту внедрения 1С:ERP уже работают системы MES (управление производством), WMS (складской учет), корпоративные порталы, банковские модули или исторически сложившиеся самописные базы данных. Именно на стыке этих систем возникает наибольшее количество проблем при адаптации.

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

Советы и рекомендации:

• До начала проекта проанализируйте состояние основной НСИ у Заказчика. При необходимости, рекомендуйте Заказчику выносить в отдельный проект/задачу нормализации НСИ, чётко прописывайте ограничения по объёму услуг в договоре в части задач по переносу НСИ.
• В части миграции данных придерживайтесь стратегии "Очистка — Остатки — Доступ к архиву". Перенос движений за несколько лет ради красивых отчетов сравнения план/факт экономически неоправдан.
• В части избыточности доработок типовой конфигурации придерживайтесь политики сохранения типового функционала и управления требованиями. Ранжируйте требования совместно с Заказчиком с точки зрения влияния на бизнес, привлекайте вышестоящее руководство для принятия решений по доработкам.
• Используйте тестовые стенды с реальным объёмом данных. Привлекайте специализированные компании для правильной настройки кластера серверов 1С (балансировка нагрузки, параметры перезапуска рабочих процессов).
• Откажитесь от сопоставления НСИ по названию, переходите к жестким идентификаторам (GUID, кодам).
• Используйте промежуточный слой данных и транспортную шину для обмена со старыми системами.