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

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

Сценарии развития рынка ERP

В связи с этим мы задались вопросом — что может произойти с рынком ERP в ближайшие несколько лет? Чтобы ответить на него, рассмотрим наиболее вероятные сценарии развития:

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

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

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

Анализ сценариев

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

▪ объем необходимых инвестиций со стороны заказчика и вендоров;
▪ возможность обеспечить проект и последующую поддержку человеческими ресурсами;
▪ сроки реализации проекта;
▪ возможные риски.

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

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

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

Сценарий «Миграция с одной платформы на другую»

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

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

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

Повысить вероятность выбора данного сценария могут громкие победы определенных ИТ-решений — успешный запуск системы в промышленную эксплуатацию в крупной компании. Таким образом, доверие к платформе повысится и привлечет «новую кровь», включая студентов, которые сейчас выбирают все больше Open Source разработку, а не ERP. В итоге бизнес в целом остается в привычной для себя парадигме (одна система — один вендор), но одновременно с этим возрастают политические и технологические риски с точки зрения нагрузки на единую систему.

Сценарий «Импортозамещение одной западной платформы на множество отечественных»

Данный подход решает такие проблемы предыдущего сценария, как:

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

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

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

Сценарий «Разработка новой платформы»

При сравнении с первым вариантом можно выделить два основных аргумента в его пользу:

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

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

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

Мы в RAMAX Group придерживаемся концепции, что заказная разработка может быть очень полезна при внедрении ERP для решения конкретных локальных задач и автоматизации определенных бизнес-функций, если существующие на рынке продукты и их функционал объективно не соответствуют потребностям заказчика. Однако за основу все же имеет смысл брать существующее решение от вендора.

Заключение

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

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

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

Источник: CNews.