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

Что осталось прежним?

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

Что поменялось?

Если раньше были какие-то варианты – с чем и как будут сравнивать предлагаемое решение представители заказчика, то сейчас ситуация другая. Общаться придется со специалистами, которые 15 и более лет работают в западной ERP-системе. И, скорее всего, это будет опыт работы с лидером мирового рынка. Поэтому новое решение будет сравниваться с решением лидера мирового рынка. Никак не ниже. И при этом придется общаться с двумя группами «слушателей». Первая – это менеджеры, над которыми висит обязанность импортозамещения и которые настроены на поиски компромиссов.

Другая группа – технические специалисты заказчика, которые свою задачу на встрече с вами видят приблизительно так: «Сейчас мы озвучим вам перечень проблем, которые за 15 лет не смогли решить с помощью системы-лидера мирового рынка. Выслушаем, что и ваш продукт «по щелчку пальцев» тоже не может решить эти проблемы (раз лидер не смог). В результате гарантированно составим отрицательное заключение, чтобы наши руководители оставили нас в покое — хотя бы года на 3 — и мы продолжим работать в привычной нам среде импортного продукта».

Это реальность текущего импортозамещения.

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

Известен кейс — один из крупных заказчиков SAP ERP в течение 10 лет не оплачивал поддержку вендора и нормально работал, даже не получая обновлений системы. И только когда компании понадобился новый функционал, она решила возобновить оплату поддержки.

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

Есть еще одна особенность процесса импортозамещения, которая проявилась на рынке ERP совсем недавно, буквально в течении последних двух-трех лет. Это необходимость использования концепции MVP (Minimum Viable Product, «минимально жизнеспособный продукт») при продвижении ERP-решения. Казалось бы, где концепция MVP, а где ERP -система? MVP — это мир стартапов, это «сделаем быстро-быстро, иначе не взлетим», а ERP – это нечто очень большое, основательное, дорогое, где процессы внедрения порой идут годами. Но «импортозамещать» приходится системы, которые дорабатывались под нужды конкретного заказчика порой 10-15 лет, соответственно, чтобы уложиться в сжатые сроки замещения такой высококастомизированной системы на российскую, необходимо быстро показать заказчику ожидаемый результат. Заказчик не планирует ждать еще 15 лет, а значит для вас абсолютно необходимо использовать концепцию MVP, показывая заказчику прообраз кастомизированного решения уже сейчас.

Возможности доработки ERP-решения

При внедрении или дальнейшем развитии системы так или иначе придется решать задачи реализации отсутствующих функций и модификации существующих.

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

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

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

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

Благодаря использованию паттерна разработки MVC (Model-View-Controller), разработчики в системе «Ma-3» могут в 50 строк кода создавать экранные формы для существующих моделей данных. Достаточно создать «модель данных» (указать нужную таблицу или несколько таблиц «со связями» между ними), определить доступные пользователю в меню стандартные операции (просмотр, правка, редактирование, удаление, печать), закрепить модель данных к представлению интерфейса, и, при необходимости, связать с другими моделями.

Еще один эффективный инструмент разработки в «Ma-3» — это точки расширения, которые позволяют кастомизировать (изменить) существующие в системе подпрограммы, функции и процедуры под конкретные задачи клиента. В системе точки расширения существуют в виде зарезервированных названий функций. В ходе работы программа проверяет наличие в репозитории реализации данных функций – если она присутствуют, то вызывается соответствующий код с пользовательскими доработками.

Реализация протокола REST позволяет интегрировать обмен данными с любыми системами. Более того, стандартные REST методы POST, GET, PUT и DELETE автоматически реализуются в системе для подпрограмм, созданных по паттерну MVC. Если текущие модели или методы не подходят, то можно всегда создать собственный метод.

Система «Ма-3» использует несколько репозиториев для раздельного хранения стандартных подпрограмм и пользовательских доработок, что позволяет обновлять систему без опасения потери кастомного (проектного) функционала.

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

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