Существующая геополитическая ситуация обнажила множество проблем, в том числе зависимость отечественных предприятий от рынка зарубежного программного обеспечения. Курс на импортозамещение программных приложений был озвучен еще в 2014 году, однако лишь немногие компании действительно ему следовали, в частности, говоря о замещении программных решений класса ERP и ERP2. Да и чем руководствовались даже те немногие, кто решили заместить ERP системы на российские аналоги, тоже большой вопрос: стратегия импортозамещения или сокращение затрат, ведь общеизвестно, что траты на лицензии и поддержку зарубежных продуктов ежегодно обходятся в кругленькую сумму. Дошло даже до того, стоимость лицензии на определенные западные продукты оценивалась и контрактовалась как фиксированный процент от выручки предприятия. На текущий момент ситуация меняется в сторону реального, а не маркетингового импортозамещения. Фокус внимания с некогда популярного в Росси немецкого продукта SAP ERP закономерно смещается на линейку решений от 1С. Несомненно, есть еще и продукты от Галактики, Паруса, Монолита, однако по масштабу имплементаций в России 1С является лидером, который, кстати говоря, еще до этого конкурировал с SAP, Oracle и Microsoft. На страницах этой статьи, мы поговорим об отличие во внедрении двух ERP-продуктов: 1С и SAP.
Несмотря на то, что класс программных решений ERP подразумевает схожий функционал программных систем для автоматизации бизнес-процессов, каждый вендор добавляет свою отличительную особенность как в методологию имплементации, так и само программное решение. В списке ниже даны основные отличия ERP-проектов от 1С и SAP:
-
методология внедрения;
-
фазы внедрения по каскадной схеме;
-
состав проектной команды;
-
демо база и подготовка ландшафта;
-
виды тестирования продукта;
-
бизнес катовер.
Программные решения от компании SAP всегда рассматривались как крупномасштабные и, что немаловажно, конфигурируемые. То есть функциональное ядро SAP-системы практически не претерпевало изменений, а критические пользовательские требования в большинстве решались настройками, в то время как доработки применялись для «бантиков». Именно поэтому практически все проекты внедрения SAP ERP – это история об использовании каскадной методологии внедрения. Применение гибридных методов имплементации все равно сводилось к каскадной схеме, обогащенной принципами Agile. Методология гибкой разработки, например, Agile Scrum, использовалась лишь в проектах развития и усовершенствования существующих программных решений, имплементированных изначально по каскадной схеме [1]. Напротив, 1С ERP нередко реализуется как на базе гибких и гибридных подходов, так и каскадной методологии. Выделяют 3-и методологии внедрения продуктов 1С: технология стандартного внедрения (1С: ТСВ), технология быстрого результата (1С: ТБР) и технология корпоративного внедрения (1С: ТКВ) [2]. Принцип выбора технологии для имплементации 1С-решения дан на рис.1, как видно из иллюстрации к крупномасштабным проектам применима лишь одна технология корпоративного внедрения. 1С: ТКВ является модифицированной версией классической спиралевидной модели внедрения, где каждый виток спирали представим каскадной схемой внедрения, в которой этап реализации представим итерациями разработок и настроек, а число витков имплементации (или волн внедрения), определяется на основе приоритизации бизнес-требований.
Каждый вендор предлагает свой способ внедрения. Так в большинстве SAP проектов используется методология ASAP или SAP Activate, первая относится к каскадной схеме, вторая представляет собой гибрид (каскадная схема с элементами гибкой методов имплементации) [3]. Каскадная модель внедрения, рекомендованная SAP, имеет классические 5-ть фаз: подготовка, проектирование, реализация, переход и гиперподдержка. Довольно часто в практике имплементации SAP продуктов используется адаптированная схема, наиболее подходящая под российские проекты: подготовка, анализ, проектирование, тестирование, переход и гиперподдержка. Оба подхода имеют место быть, их общая отличительная черта состоит в том, что каждый этап, документ и задача строго регламентированы, детально описаны и повторяются от проекта к проекту. Наиболее представительная методология имплементации 1С: ТКВ подразумевает инициацию и формирование требований на начальных этапах работ. Далее, согласно спиралевидной модели внедрения, повторяются такие фазы, как: проектирование, разработка, подготовка и проведение опытной эксплуатации и/или опытно-промышленной эксплуатации, а также подготовка и проведение промышленной эксплуатации [2]. Однако, каждый проект уникален, уникальна и методология внедрения, в связи с чем 1С допускает изменение состава работ, документов и этапов в методологии 1С: ТКВ. Изменения, вносимые технологию внедрения 1С: ТКВ предлагается компенсировать качественной обработкой рисков: необходимо оценить риски, возникающие по причине модификации метода имплементации, предложить способы реагирования на них и заложить возникшие издержки в бюджет проекта.
Типовая структура проектной SAP команды включает преимущественно следующие роли, помимо руководителя проекта:
-
архитектор, обеспечивает выстраивание сбалансированного, интегрируемого и непротиворечивого программного решения. Роль достаточно редкая, встречается преимущественно в крупных российских проектах, в контур которых входит внедрение и интеграция нескольких SAP продуктов;
-
лидер по функциональному направлению: закупки, сбыт, склад, производство, ТОРО, БУ и НУ, МСФО и др., управляет функциональными консультантами и аналитиками своего направления;
-
лидер по разработкам, контролирует работу ABAP-разработчиков;
-
лидер по базису, ведет работы по развертыванию ландшафта SAP системы, технической настройке системы и установке нот;
-
лидер по ключевым задачам: тестирование, обучение, миграция, катовер, курирующий выполнение соответствующих активностей;
-
консультанты и аналитики по функциональным направлениям, а также разработчики.
Оргструктура команды в проектах внедрения 1С решений имеют схожий состав:
-
функциональный архитектор, обеспечивающий построение целостного ИТ решения;
-
технический архитектор является экспертом по технической настройке и подготовке ИТ ландшафта, а также разработкам. Он лидирует и руководит разработчиками;
-
лидеры по функциональным направлениям;
-
функциональные консультанты, аналитики и разработчики.
Из приведенных структур проектных команд легко заметить, что:
-
роль функционального архитектора обязательна в 1С проектах, но опциональна для SAP проектов;
-
роль технического архитектора 1С сопоставима с должностями лидеров по разработке и базису в SAP проектах;
-
в 1С проектах не выделяют роли для лидирования тестирования, обучения, миграции и катовера, перенося тем самым нагрузку на руководителя проекта и лидеров функций.
Сформировав проектную команду, стартуют активности по сбору и детализации требований. Отправной точкой здесь служит документ тендерного задания. SAP проекты предполагают проведение сессий для идентификации требований в разрезе процессов 2-3 уровня из типовой отраслевой карты процессов, подготовленной заранее. Сессии сопровождаются показам материалов, позволяющих объяснить суть того, как процесс реализуется в стандартном пакетном SAP-решении: копии экранов программной системы, обучающие инструкции от вендора, реже примеры документов из «песочницы». Наоборот, в проектах внедрения 1С продуктов практически всегда готовится демо база решения, демонстрируемая заказчику для уточнения требований. Следует отметить, что подобное возможно, так как для развёртывания сред и копий 1С системы необходимо гораздо меньше времени и усилий, по сравнению с SAP...