Геннадий Гончаров, руководитель проектов 1С:ERP системного интегратора для промышленности «Райтек ДТГ»: 

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

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

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

- Проект по внедрению 1С:ERP на этом предприятии был распланирован на полтора года и рассчитан на 50 тысяч человеко-часов. Первоначально к системе предъявлялось более тысячи функциональных требований, в том числе 150 отчетных, 160 печатных форм, 140 точек интеграции с историческими системами и 450 функциональных требований.

Расставляем приоритеты

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

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

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

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

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

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

Составляем план-график

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

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

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

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

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

- График должен быть наглядным. Поэтому в него нужно включать все задачи по разработке и моделированию системы, которые еще не выполнены. И в тех случаях, когда оценить задачу без детального погружения невозможно, стоит использовать усредненные оценки (например, средний отчет — 40 часов, средняя печатная форма — 32 часа). При этом время выполнения задачи должно учитывать работу и разработчика, и аналитика, а кроме того — выполнение подготовительных операций: сбор требований и постановку задачи, разработку, тестирование, сдачу заказчику и т. д. Не забудьте заложить и резерв времени для выполнения непредвиденных работ.

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

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

Распределяем задачи

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

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

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

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

Оптимизируем документацию

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

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

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

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

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

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

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

Источник: Telecom Daily.