Риски при внедрении 1С:ERP. Последствия. Пути решения

Внедрение 1С:ERP — это часто длительный и дорогостоящий процесс, который далеко не всегда проходит гладко. Наступление рисковых событий, если проектная команда к ним не готова, приводит к затягиванию сроков проекта, к увеличению его стоимости, к недостижению поставленных целей и в худшем случае — к остановке и закрытию проекта. Остановимся на некоторых наиболее важных рисках из практики ГК «КомЛайн». Рассмотрим последствия, к которым они могут привести, и необходимые действия, которое обеспечат успешность перехода.

Запуск системы в промышленную эксплуатацию не с 1 января
Изменение бизнес-процессов в ходе опытной эксплуатации
Бизнес-процессы на предприятии отсутствуют либо не полностью выстроены
Работы выполняют несколько подрядчиков и сам заказчик
Неусвоение материала пользователями
Отсутствие у интегратора четкого понимания задач проекта
Обновление релизов внешних систем
Отсутствие проектной команды на предприятии
Недостаточная производительность серверов

Запуск системы в промышленную эксплуатацию не с 1 января

Наиболее гладко запуск 1С:ERP в промышленную эксплуатацию происходит с 1 января, потому что завершается отчетный период и на конец года сверены все остатки.

Запуск системы в продуктив в другое время может привести к тому, что: 

• Необходим перенос не только НСИ и остатков, но и некоторых документов, таких как счета-фактуры и реализации. При этом в базе 1С:ERP они должны быть под теми же номерами, что и в старой учетной системе, для того чтобы данные корректно отражались в книге продаж;

• Формировать квартальную и годовую отчетность придется вручную, потому что часть этих данных будет храниться в старой системе, а часть - в новой;

• Потребуется корректировка остатков в течение одного месяца.

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

1. Одновременный запуск подсистем. Это лучше делать по завершении периода — месяца либо квартала. Предпочтительнее запускаться с начала квартала;

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

Изменение бизнес-процессов в ходе опытной эксплуатации

Кардинальное изменение бизнес-процессов в ходе опытной эксплуатации, затрагивающее несколько подсистем 1С:ERP, может вызвать такие проблемы:

• Незавершение опытной эксплуатации в срок;

• Переход в промышленную эксплуатацию с неотлаженными процессами;

• Увеличение сроков промышленной эксплуатации.

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

1. Запуск системы в промышленную эксплуатацию с теми бизнес-процессами, которые были смоделированы в соответствующей фазе. В ходе промышленной эксплуатации бизнес-процессы видоизменяются и дорабатываются.

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

3. Изменение сроков запуска системы в промышленную эксплуатацию, в случае если руководство предприятия настаивает на одновременном запуске подсистем. Это необходимо для перемоделирования бизнес-процессов или доработки системы.

Бизнес-процессы на предприятии отсутствуют либо не полностью выстроены

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

В этом случае мы рекомендуем:

1. Составлять перечень бизнес-процессов и их описания в нотациях, например, в BPMN. При этом описания будущих бизнес-процессов нужно прорабатывать детально — вплоть до конкретных документов;

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

3. При отдельном внедрении бизнес-процессов проводить их перемоделирование.

4. Для подстраховки другие бизнес-процессы выстраивать так, чтобы они работали независимо от запуска нового блока.

Работы выполняют несколько подрядчиков и сам заказчик

В этом случае могут возникнуть такие сложности:

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

• Границы проекта могут потерять четкие очертания;

• В случае возникновения проблемной ситуации не всегда понятно, кто несет за нее ответственность и кто должен ее разрешить;

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

Чтобы не допустить появления описанных проблем, в части общих бизнес-процессов мы рекомендуем следующее:

1. Выполнение работ исполнителем проекта, заказчиком и сторонними подрядчиками должно быть синхронизировано;

2. Требуется строгий контроль сроков выполнения работ каждой из сторон и в случае их несоблюдения — оперативная корректировка;

3. Важно обеспечить прямое взаимодействие исполнителей.

В части разработки необходимо:

1. Согласовывать регламент разработки;

2. Постоянно контролировать выполнение плана разработки;

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

4. Синхронизировать технические задания.

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

Неусвоение материала пользователями

В рамках опытной эксплуатации в 1С:ERP необходимо ввести до 30% данных. Но это сделать не удастся, если пользователи недостаточно хорошо усвоили материал. В результате из-за их некорректной работы могут затянуться сроки промышленной эксплуатации, в худшем случае придется вернуться в старую систему.

Для успешной подготовки пользователей необходимо:  

1. Придерживаться плана обучения, предложенного интегратором;

2. Мотивировать персонал к обучению и контролировать процесс;

3. Проводить срезы по усвоению материала каждые два-три дня, чтобы иметь возможность скорректировать ситуацию;

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

Центр компетенций дает предприятию определенные преимущества.

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

Отсутствие у интегратора четкого понимания задач проекта

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

Чтобы затраты труда, времени и денег не оказались напрасными, мы рекомендуем:

1. Четко определить свои боли, пожелания и ожидания от реализации проекта. Эти боли и ожидания нужно донести до команды интегратора максимально честно;

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

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

Обновление релизов внешних систем

Неожиданное обновление релизов внешних систем, таких как «Честный знак», «Меркурий», ФГИС «Зерно» или ЕГАИС, может привести к тому, что необходимые интеграции перестают работать, и запуск систем, связанных с ними, приходится откладывать. А если в договоре или в другой проектной документации не зафиксированы релизы систем, которые берутся в проект, возникают споры, оплачивать работы по актуализации интеграций или нет. Подобные разборки неизбежно приводят к затягиванию сроков реализации и сдачи проекта.

Чтобы избежать таких проблем, необходимо:

1. Фиксировать даты или номера релизов в документах проекта либо в протоколах управляющего совета;

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

3. Запланировать рисковый фонд в бюджете проекта.

Отсутствие проектной команды на предприятии

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

Чтобы этого не случилось, мы рекомендуем:

1. Выбирать руководителя проекта с проактивной позицией и необходимыми полномочиями;

2. Включать ключевых пользователей в проектную команду и контролировать их участие в проекте;

3. Мотивировать участников проектной команды;

4. Оперативно реагировать на сигналы интегратора о проблемах с командой.

Недостаточная производительность серверов

Недостаточная производительность серверов — это еще один распространенный риск, связанный с тем, что 1С:ERP — достаточно энергоемкая система. 

Овеществление этого риска может привести к следующим последствиям:

• Медленная работа 1С:ERP. В течение смены сотрудники не будут успевать создать и проводить необходимое количество документов, что вызовет задержки в отгрузках;

• Длительный процесс закрытия месяца, который вместо 2-4 часов может продолжаться несколько суток;

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

Что делать для недопущения овеществления такого риска?

1. IT-службе предприятия необходимо провести анализ характеристик и производительности оборудования, воспользовавшись, например, рекомендациями фирмы «1С» для 1С:ERP;

2. Заполнить анкету, в которой указываются характеристики оборудования, чтобы интегратор мог заранее понять, с чем ему придется работать;

3. Если по результатам анализа производительности или заполнения анкеты выясняется, что характеристики оборудования не отвечают требованиям «1С», возможны несколько вариантов действий:

• заложить в бюджет приобретение необходимого оборудования; 

• рассмотреть возможность аренды сервера в дата-центре;

• если ни первый, ни второй варианты не подходят, стоит отложить внедрение 1С:ERP до того момента, как будет решен вопрос с оборудованием.

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