• EN 

Переход на «1С:ERP» и импортозамещение

Дата:
Источник:
it-world.ru
Автор:
Денис Окулов, функциональный архитектор PROF-IT GROUP

В 2022 году вынужденное импортозамещение вышло на первый план. Это обстоятельство становится триггером к тектоническому сдвигу на рынке продуктов класса ERP. Переход на 1С ERP стал безальтернативным в силу отсутствия отечественных решений на рынке ERP-систем, кроме 1С. Об особенностях перехода на 1С размышлял функциональный архитектор PROF-IT GROUP Денис Окулов.

Еще недавно по материалам Фирмы 1С и ее партнеров импортозамещение – было самой последней причиной выбора 1С. По данным отчетов партнеров 1С: 263 случая выбора ERP-решений «1С» вместо зарубежных ERP-систем (2018 гВ 2022 году мы столкнулись с зеркальной ситуацией, когда вынужденное импортозамещение вышло на первый план, более того данное обстоятельство становится триггером к тектоническому сдвигу на рынке продуктов класса ERP.

Переход на 1С ERP стал безальтернативным в силу отсутствия отечественных решений на рынке ERP-систем, кроме 1С.

Cегодня, пожалуй, единственное решение класса ERP по функциональным и техническим возможностям, которое может заменить все передовые импортные решения. Более того, все законодательные новеллы и «лучшие» бизнес-практики достаточно быстро находят свое отражение в ПО Фирмы 1С. Также, в пользу этого тезиса говорит выбор отечественного бизнеса. По данным компании «Эдит про», в 2021 г. большую половину ERP-рынка занимали западные вендоры: SAP, Oracle, Microsoft – около 60%. Порядка 35% у «1С». Оставшуюся долю занимают российские компании: «Галактика», «Парус» и «Компас».

Из всех распространенных ERP-решений на рынке России – главный игрок, наверное, это SAP.
Полагаю, что данный тезис также не стоит доказывать в данном материале? Однако, приведу еще немного цифр: В 2016 г. на российском рынке SAP занимала лидирующую позицию с долей в пределах 49% (статистика Tadviser), обгоняя российскую «1С» (32,9%) и американские Microsoft и Oracle (8,8% и 4% соответственно). Отечественная «Галактика» была на пятом месте с долей 2,2%. Также стоит заметить, что популярность внедренных решений на базе SAP в среде крупного бизнеса все еще очень высока.
Таким образом, можно говорить о полновесной конкуренции только SAP и 1С на рынке именно ERP-решений.

Давайте проведем сравнение решений 1С ERP и SAP:
- SAP имеет свои ограничения в плане встроенной бизнес-логики (некоторые процессы нельзя настроить, как они могут быть организованы в реальном бизнесе, например, некоторые дублирования одних и тех же процессов на разных участках цепочки документов, при различии контекстных условий, поэтому приходится подстраиваться под заложенные последовательности в SAP, иногда это крайне «неудобно»).

- Интерфейс SAP менее дружелюбен и удобен в работе пользователя, в 1С интерфейс и навигация настроена более системно и органично. Да есть в 1С недостатки юзабилити в части поиска нужных документов или элементов справочников, перехода из документов в контекстные отчеты и прочие моменты, например, недостаточное использование «помощников» (АРМ) и их функциональная скудность. Но при всех критических замечаниях со стороны бизнеса как ключевого потребителя, все равно сравнивать с SAP без слез, невозможно.

- Модульность SAP. Данное свойство одновременно выступает как достоинство, так и в качестве и недостатка. С одной стороны, модульность имеет возможность гибкой настройки только тех модулей, которые нужны заказчику и работает как конструктор ЛЕГО, однако, это несет в себе и обусловленность доменной логикой и структурой. Также необходимо всегда решать проблему консистентности данных. Более того, выигрыша от системности связей не получается в той мере, как в 1С маршруты внутренних взаимосвязей короче и их можно быстрее настроить.

- Как следствие, из модульности и жесткости бизнес-методологии в SAP распространена так называемая «склеенная» отчетность. Это делает АИС менее достоверной и прозрачной.

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

- Как следствие, от модульности SAP и избыточности внутренней архитектуры 1С вытекает следствие более высокой степени системной сложности 1С, что приводит к более высоким требованиям к аналитикам с части навыков познаваемости и абстрактного мышления. Если не сказать больше, 1С ERP в отличие от SAP имеет признаки технологической сингулярности как информационная система («вещь в себе»). Данное свойство как раз определяет трудность внедрений на проектах.

Однако из-за оптимизированности внутренней архитектуры функций и технических решений, SAP является наиболее мощной АИС и в плане нагрузоустойчивости является примером для подражания. Например, структура хранения данных по бухгалтерским проводкам упрощена до простой таблицы проводок списком записей. В 1С, напротив, проводки хранятся в структуре с учетом принципа «двойной записи», т.е. бухгалтеру видно все мэппинги по проводкам и сразу все наглядно и понятно.

Нельзя однозначно сказать, какой продукт лучше. Бесспорным является пока только факт «инерции» выбора для крупного бизнеса в пользу SAP. 1С чаще выбирают средние и малые предприятия. Крупные холдинги отдают предпочтения только, когда речь идет о частичной автоматизации отдельных функций бизнеса и выбирают такие продукты «вселенной 1С» как, например, 1С «Управление холдингом» (УХ) или 1С «Заработная плата и управление персоналом» (ЗУП).

Но при всех очевидных плюсах 1С на «ощущательном» уровне можно сказать, что рынок не торопится «развернуться» и затопить партнеров фирмы 1С заявками на внедрения и перевод с импортных решений.

Причины:
1 Надежда, что вся история с «уходами» с российского рынка внедрений ERP таких игроков, как SAP, Oracle и MS  - это временно и ненадолго;
2 Недоверие к 1С как к успешному решению;
3 Отсутствие широко-известного опыта и устоявшихся практик перехода с SAP на 1С;
4 Некая привычная инертность бизнеса, по типу «Работает – не трогай!».
Первый и последний пункты – обсуждать бессмысленно, т.к. это касается человеческой природы и управлять на рациональном уровне этим сложно.
А вот второй и третий моменты стоит раскрыть для читателя более подробно.

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

Отдельной темой можно выделить отсутствие практик проектного управления крупномасштабными внедрениями большими холдингами и группами. Если, например, крупномасштабных внедрениях в продуктовом семействе SAP можно разделить на несколько направлений сообразно автоматизируемым модулям и вести разработку и деплой по нескольким направлениям одновременно, то из-за монолитной структуры 1С негативные эффекты одновременной смежной разработки («дружественного огня») увеличивается циклы разработки технических решений, которые необходимы бизнесу в конкретных кейсах.

Таким образом, чтобы исключить эти эффекты, нужно «разделить» на стримы проектную команду и выделить несколько инстансов информационных баз, также нужно учитывать масштаб проектной команды. Как только уровней управления становится больше чем 2, например, 3 уровня (разработчик, технический архитектор и главный технический архитектор), обычно это автоматически происходит после увеличения численности проектной команды 15-20 человек, т.к. один лидер не может эффективно управлять командой более 7-8 человек. В итоге разрастание команды не приводит к положительному результату и сокращению проектных сроков, но более того, управляемость проекта снижается и те же сроки потом увеличиваются вследствие потери эффективности и необходимости постоянно синхронизировать решения, принятые несогласованно в разным центрах управления в команде либо от преобладания всевозможных общих собраний по обсуждению «всего на свете».

В таких условиях найдется немного охотников «покрутить колесо фортуны», что нас приводит к ответу на вопрос: почему пока мало случаев перехода с SAP на 1C. А дальше вы попадаем в заколдованный круг причины и следствия.

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

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

Для этого партнерам 1С нужно искать инструменты и технологии для дальнейшего развития практики 1С в части ERP-зации бизнеса в РФ.

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

Во-вторых, необходимо оптимизировать «неторопливые сроки» с учетом того, что за 1,5 -2 года обновляется технологический уклад в ИТ-системах, соответственно, любое отполированное техническое решение в среде ERP морально начинает устаревать.

В третью (но не последнюю по важности) очередь, нужно постоянно заниматься оптимизацией вычислительной производительности и снижением нагруженности АИС.

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

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

Другими словами, если раньше от «капитанов бизнеса» и глав функций многое зависело, то теперь вариантов принятия решений становится гораздо меньше…В соответствии с этим класс программных продуктов ERP в будущем неизбежно эволюционирует в более роботизированную плоскость, т.е. в направлении нового поколения данного класса систем - ERP-роботизации. В обыденной жизни мы же не задаемся вопросом, нужно ли нам настраивать автоплатежи за ипотеку, ЖКХ, домашний интернет в начале каждого месяца в личном кабинете или онлайн-банке. Если мы хотим экономить свое время – мы просто делаем это. Также обстоят дела с закрытием месяца в любой бухгалтерской службе любого предприятия, бухгалтера не выбирают, закрывать им отчетность по месяцу или заняться чем-либо другим… Все такие процессы можно настраивать в автоматическом режиме. Да, может показаться, что таких процессов очень мало в общем массиве, но это не так. Возьмем к примеру, развилки управленческих решений при оплатах по договорам с закрепленными сроками платежей или решениями бюджетных комитетов при превышениях бюджетных параметров по закупкам вследствие изменения рыночной конъюнктуры – свобода решений для бизнеса в данном случае эфемерна и остается только принять необходимость совершения какого-либо действия, так зачем же тратить время на видимость принятия решений?

Тот, кто начнет проектирование такого рода программных продуктов уже сегодня – будет «снимать сливки» этого рынка завтра.

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

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

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

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

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


Другие материалы