Практика использования современных проектных технологий при внедрении ERP-систем

О методологиях управления современными IT-проектами

Как и в любой отрасли современной экономики, в деятельности по внедрению ERP существуют свои технологии, методики и приёмы эффективной работы. Процесс внедрения программного продукта «1С:ERP. Управление предприятием 2», появившегося на рынке в 2013 году и уже получившем широкое распространение в России, вобрал в себя множество мировых практик успешной реализации ИТ-проектов, как с учетом общероссийских традиций внедрения, так и специфики самой системы программ «1С:Предприятие». В данной статье мы постараемся провести краткий обзор современных технологий внедрения ERP-систем применительно к проектам внедрения 1С:ERP на предприятиях малого, среднего и крупного бизнеса. В том числе будут рассмотрены подходы, применяемые руководителями проектов ГК «СофтБаланс». Надеемся, что это поможет сотрудникам и командам, ответственным за внедрение ERP, а также собственникам предприятий, более уверенно ориентироваться на российском рынке ERP-внедрений и принимать оптимальные решения о выборе технологии управления проектом.

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

• Классическая «водопадная» модель (waterfall). Предполагает строгую последовательность этапов проекта (если кратко: обследование, моделирование, разработка ТЗ, программирование, тестирование, обучение, ввод в эксплуатацию). Планируется, как правило, на весь проект – заранее и максимально подробно. Предполагает строгую и достаточно сложную процедуру проведения изменений плана проекта в случае такой потребности.
• Гибкие методики разработки (agile/scrum). Не содержат строгой последовательности в выполнении видов работ, нацелены на максимально быстрое получение (пусть не идеального) результата, с возможностью лёгкой процедуры проведения изменений на основании полученного результата. Данное семейство проектных технологий имеет свои ограничения, как по масштабу проекта, так и по составу решаемых задач/целей проекта.

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

Ещё в 2005 году фирма 1С в стремлении снабдить своих фирм-партнёров 1С:Франчайзи методологическим аппаратом, разработала три методики внедрения своих программных продуктов:

1. 1С:Технология стандартного внедрения (1С:ТСВ)
2. 1С:Технология быстрого результата (1С:ТБР)
3. 1С:Технология корпоративного внедрения (1С:ТКВ)

Первый сценарий – технология стандартного внедрения – фактически непроектная деятельность. Это методика, как принято называть в 1С, типового запуска, которая может быть регламентирована системой менеджмента качества (СМК), в частности – ISO:9001. Предполагает полное отсутствие кастомизации (доработок функционала типового продукта) и содержит набор стандартных действий специалистов-автоматизаторов, повторяемых с минимальным количеством отклонений от предписанного сценария. Методика предназначена, в первую очередь, для масс-маркета, то есть для предприятий малого бизнеса, которым ради экономии проще подстроиться под возможности программы, чем доработать её под свои нужды. В группе компаний «СофтБаланс» по методике, близкой к 1С:ТСВ, работает отдел типового запуска. В приоритете отдела – внедрение на небольших предприятиях таких конфигураций, как:

• 1С:Управление торговлей 8 (редакция 11)
• 1С:Управление небольшой фирмой
• 1С:Документооборот (причём, как правило, его версия КОРП)
• 1С:CRM 3.0
• 1С:Комплексная автоматизация 2.0

Более подробно о типовом запуске  см. здесь. В контексте данной статьи, внедрение на основе 1С:ТСВ не имеет прямого отношения ни к Agile-технологиям, ни к водопадной методологии управления проектом.

Второй сценарий внедрения – 1С:Технология быстрого результата. Перекликается по методикам с agile-технологиями, а если быть точнее – с концепцией экстремального программирования (содержит принципы коротких циклов программирования, парной организации исполнителей, а также предполагает «близость заказчика» - для получения максимально быстрой обратной связи). ТБР позиционируется фирмой 1С, как технология, позволяющая с минимальными рисками и затратами достичь желаемого результата на проектах любого масштаба. Лозунг данного подхода – «Ни месяца без результата!». Во многом адаптирована под относительно высокую частоту выпуска фирмой 1С редакций своих конфигураций. В нашем примере при внедрении по 1С:ТБР программного продукта 1С:ERP предполагается его внедрение последовательно по редакциям 2.0, затем 2.1 и т.д. – с попутными корректировками требований к системе.

Этапность проекта, внедряемого по 1С:ТБР, подробно описана здесь. На практике, в «чистом» виде ТБР на проектах ГК «СофтБаланс» не применяется, но была использована, как шаблон для построения своей методологии управления (см. ниже).

Третий сценарий – 1С:Технология корпоративного внедрения, предполагает внедрение систем в среднем и крупном бизнесе, с полным прохождением проекта по этапам. Корпоративное внедрение в сравнении с ТБР и ТСВ максимально наполнена документами на выходе каждого этапа, основана на классическом подходе «водопадного» внедрения. С учетом требований рынка по составу проекта, его сроков и бюджета, в «чистом» виде концепция ТКВ не применяется. 

Единая методика управления проектами внедрения ГК «СофтБаланс»

В ГК «СофтБаланс» за длительный период работы (начиная ещё с внедрения 1С:УПП) для всех проектов внедрения, в том числе 1С:ERP, выработан единый принцип построения календарного плана-графика проекта, и в соответствии с ним – набор методик управления проектом. В основе методики – «модульный» принцип. Это означает, что существует единый шаблон набора этапов проекта, который при необходимости сокращается под конкретного заказчика. При этом, наша методика объединяет в себе наработки 1С по ТБР, ТКВ и основывается как на «водопадных-», так и на agile-технологиях. Соответствие методик изображено в таблице ниже:

Суть единой методики заключается в следующем:

• Заранее подготовлен общий, максимально подробный перечень последовательных этапов проекта, конкретно:
  • Экспресс-обследование
  • Обследование
  • Моделирование
  • Разработка Технического задания
  • Разработка Технического проекта
  • Программирование и сопутствующее тестирование
  • Документирование
  • Обучение пользователей
  • Тестовая эксплуатация (функциональное и нагрузочное тестирование)
  • Ввод/перенос НСИ
  • Ввод/перенос начальных остатков
  • Запуск в промышленную эксплуатацию
• Для каждого проекта на этапе планирования (как правило, ещё до заключения контракта) составляется список функциональных блоков. Набор блоков для среднестатистического проекта может быть такой:
  • Управление нормативно-справочной информацией (НСИ)
  • Управление взаимоотношениями с клиентами (CRM)
  • Управление продажами
  • Объемно-календарное планирование (ОКП)
  • Оперативное планирование
  • Посменное планирование производства
  • Диспетчирование производства
  • Управление качеством
  • Разработка нового продукта (NPD) и нормирование
  • Управление производственными активами (EAM)
  • Управление запасами
  • Управление закупками
  • Складская логистика (WMS)
  • Транспортная логистика (TMS)
  • Управленческий учет затрат, расчет себестоимости и финансового результата
  • Интеграция со смежными системами
  • Казначейство
  • Бюджетирование
  • Регламентированный учет
  • Международный учет (МСФО)
  • Управление персоналом
  • Кадровый учет
  • Расчет заработной платы
  • Управление ТО и ремонтами
  • Управление автотранспортом
  • Документооборот и управление бизнес-процессами
• Для каждого функционального блока проекта руководитель проекта на этапе планирования определяет методику внедрения: agile или классическая водопадная модель.
• Для функциональных блоков, внедряемых по классической модели, определяется состав этапов внедрения из списка выше. При этом в зависимости от начальных условий проекта часть этапов может быть опущена (например – экспресс-обследование или разработка технического проекта). Кроме того, некоторые этапы могут быть объединены (особенно на проектах малого и среднего масштабов).
• Дополнительно весь проект разбивается на 1-3 очереди внедрения. Внутри каждой очереди – свой набор этапов/функциональных блоков.

Как итог, в результате такого планирования может быть сформирован календарный план-график проекта, пример которого изображён ниже:

О концепции MVP

В приведённом примере некоторые блоки внедряются по методике гибкой разработки, в частности – планирование – по причине высокой степени уникальности процессов планирования на каждом предприятии. При внедрении данного блока необходимо максимально быстро получать обратную связь от заказчика, и при необходимости корректировать процесс разработки/внедрения, вплоть до фиксации новых требований к системе, упущенных на этапе обследования. При внедрении планирования (особенно – оперативного межцехового и внутрицехового) нам видится малоперспективным: в процессе моделирования, как правило, «всплывают» требования, о которых заказчик не упомянул на этапе обследования, в результате чего что внедренцам, что заказчику стоит серьёзных усилий – эмоциональных и финансовых – для проведения соответствующих изменений.

Помимо выбора Agile для планирования, в данном графике важным является отказ от разработки технического проекта (техническое задание, написанное терминами конфигуратора 1С) – предполагается, что программисты на проекте имеют достаточную квалификацию, чтобы на своё усмотрение выбрать технический способ реализации требований, подробно описанных в ТЗ.

Таким образом, единый шаблон графика проекта, используемый в проектной деятельности ГК «СофтБаланс», как конструктор, позволяет быстро и максимально осознанно подобрать для каждого проекта оптимальный состав этапов и применяемых технологий.

Концепция MVP хорошо прижилась в сфере IT-проектов, в том числе – при внедрении продуктов 1С. Данный подход мы стараемся применять на каждом своём проекте, ставя себе и заказчику задачу определить минимально возможный набор требований к системе, который необходимо реализовать для того, чтобы запустить систему первой очереди. Например, при внедрении 1С:ERP для запуска, как правило, достаточно запустить сначала учетные блоки (продажи, закупки, производственный и регламентированный учет), и уже затем наращивать функционал системы, внедряя производственное планирование, бюджетирование и т.п.

Важно понимать, что и производственное планирование можно (а иногда - нужно) стараться запустить к дате запуска системы в промышленную эксплуатацию (первая очередь проекта). Однако следует помнить, что внедрение производственного планирования – максимально рисковая часть проекта, в связи с чем мы рекомендуем внедрять его по технологии Agile. Такой подход позволяет вести подпроект автоматизации планирования параллельно основному проекту и запустить все подсистемы одновременно. Однако в случае, если подпроект по планированию затягивается – это не приводит к срыву сроков запуска системы в эксплуатацию, что существенно сокращает все риски внедрения как по срокам, так и по бюджету.

Яркий пример применения MVP-концепции: проект 2017 года ГК «СофтБаланс» по автоматизации предприятия пищевой промышленности. При конечных целях внедрить 1С:ERP практически по всем блокам (включая MES-модуль, объемно-календарное планирование и бюджетирование) было принято решение запустить первоначально только два блока – закупки и сырьевые склады. Такой подход несущественно увеличивает затраты на дальнейшую стыковку блоков, зато сводит до минимума риски как заказчика, так и исполнителя проекта внедрения.

Другой вариант применения MVP – наоборот начать только с производственного планирования, а затем внедрять учетные блоки. Подобный принцип применялся нами на внедрении 1С:ERP на заводе «Металл Индастри» группы EKF. Подробнее о проекте см. здесь.

Об управлении требованиями

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

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

• Выполнимость (требование должно быть технически достижимо)
• Недвусмысленность (требование не должно иметь различных трактовок – иначе высок риск появления разногласий и конфликтных ситуаций при сдаче-приёмке работ)
• Проверяемость (у заказчика и исполнителя должна быть возможность однозначно определить/проверить, реализовано ли требование в точности так, как оно сформулировано или нет)
• Атомарность (требование не должно быть описано так, что его можно разбить на более мелкие требования-составляющие)

На примере критерия недвусмысленности можно рассмотреть две ситуации. Так, формулировка «В системе необходим учёт номенклатуры параллельно в двух единицах измерения» гораздо менее предпочтительна, чем «Реализовать в системе учет движения материалов с возможностью указания в первичном документе как штучных единиц измерения с учетом упаковок, так и физического веса нетто». Конкретный случай с двум единицами измерения – одна из самых часто встречаемых нами ошибок в формулировании требований к системе учета. На практике внедрения 1С:ERP существует порядка четырёх-пяти различных сценариев учета ТМЦ, все из которых обобщенно именуются «учет параллельно в двух единицах измерения». Таким образом, чем точнее стороны сформулируют все требования по проекту до начала его реализации – тем меньше совместных рисков они оставят себе на следующие этапы.

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

• Функциональный блок (см. выше в описании единой методики планирования)
• Наименование требования
• Описание требования на бизнес-языке (как правило, формулируется совместно заказчиком и аналитиком)
• Владелец требования (какое подразделение или должностное лицо выступает источником)
• Статус

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

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

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

О формировании проектной команды

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

• какова численность команды проекта от заказчика;
• какие роли выделяются в команде;
• какими регламентами (уставами/приказами) руководствуются участники;
• какая схема мотивации используется руководством предприятия для каждого участника команды.

Что касается численности проектной команды заказчика, здесь мы выделяем два вида проектов:

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

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

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

Яркий пример – назначение в качестве ответственного за проект специалиста-эксперта/инженера. Очень часто «руководителем» проекта назначают штатного программиста 1С. Основной плюс такого подхода – отпадает необходимость тратить средства и время на поиск специалиста, имеющего опыт работы с системой программ 1С. Однако есть и возможные минусы:

• Отсутствие у программиста навыков, знаний и опыта в сфере проектного менеджмента;
• Отсутствие требуемого уровня авторитета в коллективе и полномочий (даже если ими его наделяет формальный приказ руководителя).

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

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

Заключение

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

• с одной стороны - знание и умение применять общемировые стандарты, принципов и подходов в проектном менеджменте;
• с другой стороны – знание самого предмета – функциональных возможностей платформы 1С и её тиражных решений.

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