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

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

Если говорить о конкретных цифрах, то, например, автоматизация производства занимает в среднем месяцев 8-10. Блок оперативного учета – от 4 до 8. Финансовый учет – от 4 до 6 месяцев.

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

Можно. Но для успешного внедрения есть ряд необходимых критериев.

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

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

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

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

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

3. Проект по внедрению нескольких модулей сможет реализовать только команда профессионалов. И это не два-три человека.

Состав команды зависит от того, какое количество блоков необходимо одновременно внедрить. Должен быть руководитель проекта. Функциональный архитектор (методолог), несколько консультантов-аналитиков. Также нужен технический архитектор и разработчики в его подчинении.

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

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

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

• Организационные риски
  Политическая воля руководства в поддержке данного проекта. Проект сложный, длинный, дорогостоящий. Если поддержки не будет, то проект реализован не будет. Попытка ради попытки – это трата сил, времени, материальных ресурсов.
• Бюджетные риски
  Если есть желание внедрить ERP 1С Предприятие за миллион рублей, то никакого внедрения по факту не будет. Финансирование должно соответствовать масштабу проекта и выполняться по заранее согласованному плану.
• Методологические риски
  Возможны неприятные «сюрпризы», если методология противоречит фактическому состоянию дел. Или требования отдельных подразделений не укладывается в общую идеологию. Если надо будет какие-то решения принимать, то готов ли заказчик их принимать – не всегда понятно. Например, требуется вести учет в таких-то разрезах, при этом бухгалтерия категорически отказывается.
• Технические риски
  Наличие оборудования, серверной инфраструктуры, сетевой инфраструктуры, наличие хороших каналов связи.

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

Совместно с клиентом разрабатывается дорожная карта, в рамках которой происходят все действия. Дорожная карта определяет очереди внедрения и этапы работ внутри очередей.

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

Свернуть текст