Фирма "1С" завершает поддержку проверенного годами продукта "1С:Управление производственным предприятием". Для многих компаний самый логичный шаг — переход на "1С:ERP". Может показаться, что три месяца — достаточный срок для выполнения проекта перехода с УПП на ERP.

Однако внедрение начинается раньше, чем кажется. Проект — это совместная работа интегратора и заказчика, и работа требуется с обеих сторон.

"Почему нельзя просто сделать быстрее?" — спросите вы. Часто встречаются попытки выиграть время: сокращение обследования, полное отсутствие тестирования, ускорение обучения. В таком случае мы жертвуем качеством ради скорости и переносим риски ближе к дате запуска.

Также встречается вопрос: а может, стоит выполнить проект по гибкой методологии для ускорения?

Коротко напомним, какие методологии ведения проекта существуют.

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

Agile — итерационная работа небольшими шагами с быстрым получением промежуточного результата и постоянной обратной связью.

И тут важно понимать, что Agile не означает "быстрее". Это другая методика со своими плюсами и минусами.

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

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

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

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

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

Но ни Agile, ни Waterfall не отменяют сам объем работ.

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

Именно поэтому при расчете срока проекта нельзя считать только время работы интегратора. Если запуск запланирован на 1 января, то к этой дате должна быть готова не только программа. Должны быть готовы данные, пользователи, процессы и сама компания.

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

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

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

3. Разработка или модификация ERP в соответствии с техническим заданием. Каждый бизнес уникален, поэтому в зависимости от задач заказчика может потребоваться доработка системы или настройка дополнительных механизмов. Срок этапа сильно зависит от объема изменений и может быть сокращен за счет увеличения команды разработки интегратора. Однако ускорение ограничено не только возможностями исполнителя: работу нужно принимать, тестировать и согласовывать силами сотрудников заказчика, и их ресурс тоже конечен. Этот этап может занимать от одного месяца до полугода на крупных проектах.

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

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

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

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

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

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

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