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

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

Поскольку команда ВЦ «Раздолье» - уже более 15 лет занимается внедрением российских систем ERP: в частности, «1С:ERP Управление предприятием» и «1С: Управление холдингом» и накопила огромный опыт в сфере автоматизации, мы решили разобраться с этим вопросом и проанализировать возможность перехода с одной из западных ERP-систем – SAP – на решения фирмы «1С».

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

Рецензентами настоящего анализа являются:

Грибков Евгений Александрович – руководитель ВЦ «Раздолье»,

Пикурен Вера Александровна – руководитель корпоративных проектов внедрения «1С:ERP» компании ВЦ «Раздолье» (специализация – автоматизация регламентированного учета и автоматизация производства),

Малышев Дмитрий Александрович – эксперт по технологической платформе «1С:Предприятие», технологический руководитель проектов внедрения решений «1С» на корпоративном рынке, компания ВЦ «Раздолье»,

Камко Юрий Александрович – к.э.н., PMP, ICAgile Professional, руководитель проектов внедрения SAP в энергетике, производстве, закупках, логистике, финансах, строительстве, ремонтах.

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

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

Начнем с рассмотрения, что же такое SAP ERP и SAP S/4HANA и возможна ли быстрая миграция из этой системы, как можно оценивать сложность перехода. Затронем также и вопрос организации перехода, возможных рисках, особенностях работы с этими рисками.

В основе SAP, также как и «1С», лежит платформа разработки прикладных решений. Платформа SAP называется SAP HANA. Это современная среда разработки, отладки, исполнения, на которой пишутся программы бизнес-автоматизации.

Сравнивая данную платформу с платформой «1С:Предприятие 8», можно сказать, что в части, касающейся разработки и отладки, SAP HANA примерно равнозначна по возможностям платформе «1С».

Широкий спектр языков программирования - «плюс» или «минус»?

Итак, имеется платформа SAP HANA, в рамках которой разрабатываются и исполняются программы. В терминологии SAP программа – это некий модуль, который может быть написан на комбинации языков ABAP, Java, SQL, SQLScript. Внешняя часть, с которой взаимодействуют пользователи, на языке JavaScript (фреймворк SAPUI5 и пр.). То есть, в отличие от платформы «1С:Предприятие», здесь используется широкий спектр языков программирования, они комбинируются для решения отдельных задач, что, с точки зрения SAP, позволяет получить максимальную производительность работы модулей.

Рисунок 1. Среда разработки 1С:Предприятие 8
Рисунок 1. Среда разработки 1С:Предприятие 8

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

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

Миф о конечных решениях

Давайте теперь разберемся – что понимается под «конечным решением» (например, что такое ERP-система SAP S/4HANA)? В терминах SAP — это набор модулей, используемых для решения тех или иных задач заказчика. Причем, они не являются жестким законченным готовым продуктом. На самом деле SAP S/4HANA собирается из готовых модулей индивидуально под потребности конкретного заказчика – в зависимости от того, что ему нужно.

Конечно, есть и традиционный набор модулей, используемых чаще всего. Это модуль управления сбытом (SD), модуль управления закупками (MM), модули управления производством (PP), модуль, связанный с бухгалтерским и налоговым учетом (FI), контроллинговый модуль, отвечающий за расчет себестоимости (CO). Можно назвать это неким ядром. К нему также по необходимости могут быть добавлены другие модули: например, модуль расширенного управления складской логистикой (EWM). Это WMS-система, написанная на платформе SAP HANA. Кроме модуля EWM есть еще модуль, отвечающий за транспортировку грузов (TM) и модуль управления качеством (QM).

Причем все указанные модули могут добавляться как отдельно стоящие базы данных, которые обмениваются данными через шину данных от SAP (таким образом, один модуль EWM может обслуживать несколько «ядер» отдельных предприятий как единая складская подсистема), так и как объединение нескольких модулей, работающих с одной и той же базой данных, за счет чего получается единая система, работающая в режиме «одного окна».

Если сравнивать термин «решение» в SAP с тем, что под этим понимается в «1С», то мы увидим, что у фирмы «1С» «решением» также может быть как отдельно стоящая конфигурация (например, «1С:ERP» для отдельного завода), так и произвольная комбинация конфигураций (1С:ERP, 1C:УХ, 1С:ДО, 1С:ЗУП, 1С:БП, 1С:УТ и т.д.) с территориально удаленными базами данных, связанных обменами организованными как с использованием механизмов самих баз (веб-сервисы, XML, COM и т.п.) или через «1С:Шину данных» или другие шины, где будут комплексно решаться задачи управления целым холдингом. Также доступны комбинации из основного решения «1С:ERP» со специализированными отраслевыми решениями, например, конфигурацией «1С:PLM», которая позволит дополнительно к задачам управления производством решать задачи конструкторско-технологической подготовки производства, или решениями по автотранспорту, строительству, пищевой промышленности и сельскому хозяйству и т.д.

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

К вопросу о базах данных

Удивительно, но экосистемы SAP и «1С» во многом схожи. Безусловно технологически, в деталях реализации, это разные системы, но по общим принципам работы они очень близки. Единственное существенное отличие у них – собственная СУБД HANA, которая, с точки зрения SAP, обеспечивает высокую производительность конечных «решений».

У «1С» в этом моменте собственная СУБД работает на небольших по объему базах, а в крупных решениях необходимо использовать СУБД других поставщиков – MS SQL Server, Oracle Database, PostgreSQL, IBM DB2.

Возможность выбора различных СУБД для 1С дает возможность использовать его как на операционных системах Microsoft, так Linux’овых ОС.

Можно ли объективно считать, что HANA превосходит по производительности MS SQL или PostgreSQL? К сожалению, нам не известны независимые исследования этого вопроса. 

Существенным плюсом HANA здесь является то, что ее база данных работает большую часть времени в режиме «In-Memory». То есть, высокую скорость во многом обеспечивает хранение и обработка данных в высокоскоростной оперативной памяти (RAM) сервера.

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

Рисунок 2. Интерфейс Fiori
Рисунок 2. Интерфейс Fiori

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

У «1С» ситуация немного иная: «1С:Предприятие» самостоятельно закрывает клиентскую часть и сервер приложений, а в качестве СУБД использует решения: MS SQL Server, Oracle Database, PostgreSQL, IBM DB2.

Вопросы мобильной платформы

Что еще хотелось бы сказать: SAPGUI ближе к концепции толстого клиента «1С», а Fiori ближе к концепции тонкого клиента «1С». В этом отношении у «1С» есть преимущество: не требуется создавать отдельное приложение, которое будет работать в режиме web-клиента на планшете и отдельное приложение для ноутбука или стационарного компьютера. Это все делается в рамках одной и той же разработки интерфейса пользователя, а уж сама платформа «1С:Предприятие» заботится о том, чтобы этот интерфейс работал везде.
Аналога мобильной платформы «1С:Предприятие» у SAP нет.

Предполагается, что на стороне модуля SAP определяются некие внешние интерфейсы (web-сервисы и т.п.), к которым может подключаться внешнее мобильное приложение, получая и отправляя данные. На чем и как будет написано и как будет выглядеть само внешнее приложение зависит только от его разработчика.

Это, с нашей точки зрения, некоторый минус SAP. Мобильная платформа «1С» позволяет разрабатывать мобильные приложения на том же языке «1С» (с некоторыми ограничениями и дополнениями), в той же логике, что и обычные приложения. Также приложение «1С» может организовывать собственные web-сервисы и работать в «режиме SAP». Модуль «1С:Аналитика» сразу адаптирован под работу на любых устройствах, в том числе - мобильных. 

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

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

Экосистемы «1С» и SAP

Давайте теперь абстрагируемся от технических деталей и попробуем сравнить экосистемы «1С» и SAP в целом.

Посмотрим на объективные преимущества SAP. Во-первых, здесь есть достаточно развитые, зрелые решения, связанные с планированием ресурсов и прогнозированием. Решение этих задач в качестве основных приоритетов развития экосистемы SAP было обозначено достаточно давно. SAP и сам развивал подобные продукты, и приобретал готовые программы у сторонних разработчиков, интегрируя их затем в собственные решения. Таким образом, SAP получил широкий ассортимент продуктов (модулей) для самых разных задач. Это могут быть решения для автоматизации товарного прогнозирования сбыта и снабжения. Например, в розничных продажах (модуль FR), комплексные решения интегрального планирования ресурсов (материальные потоки, оборудование, деньги в модуле IBP). 

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

Следующим плюсом SAP является то, что для западного рынка оно общепризнанно (как «1С» в России и странах СНГ). Люди, инвестировавшие в изучение/внедрение SAP, пользуются одними и теми же инструментами на протяжении нескольких десятков лет. Условно говоря, транзакция, имеющая код «se11» тридцать лет назад, будет иметь тот же код «se11» и алгоритм работы и сейчас. Конечно, может поменяться интерфейс, вид окошка, но набор реквизитов, общая суть транзакции, ее возможности остаются неизменными. В условиях дороговизны людских трудовых ресурсов, эта особенность SAP позволяет существенно экономить на обучении персонала – любой знакомый с системой человек при переходе из одной организации в другую увидит один и тот же интерфейс, привычный набор транзакций и приступит к работе без переобучения. Это усугубляется тем, что, что в отличие от «1С», затраты на локальную модификацию SAP ЗНАЧИТЕЛЬНЫ и многие вынуждены работать с типовым функционалом.

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

Посмотрим теперь, что является преимуществами экосистемы «1С».

Во-первых, это большое количество специалистов на рынке труда и быстрота и невысокая цена процесса адаптации системы под задачи заказчика. У SAP с этими показателями дела обстоят СУЩЕСТВЕННО хуже.

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

Относительно вопросов адаптации следует сказать, что один и тот же язык, используемый и на серверной, и на клиентской части, наличие множества быстрых конструкторов кода, автогенерация интерфейса под разные среды исполнения, концепция low-code среды разработки «1С:Предприятие» (например, система СКД (быстрой генерации отчетов) – все это позволяет существенно удешевить адаптацию продуктов под специфику клиента. Это, как уже было сказано, порождает миф о том, что программы от «1С» всегда требуют доработки. Однако, на самом деле, дорабатывать их или нет – личный выбор заказчика системы, просто в экосистеме «1С» заказчик может позволить себе доработки систем 1С.
Второе существенное преимущество «1С» - готовности к использованию для малого и среднего бизнеса (СМБ). Есть и у SAP решения для СМБ, но предполагается, что они должны использоваться четко «из коробки». Любая кастомизация под уникальные процессы предприятия (часто составляющие «ноу-хау» и дающие конкурентное преимущество на рынке) приведет к необходимости заплатить СУЩЕСТВЕННЫЕ деньги, а такие манипуляции могут себе позволить не все заказчики.

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

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

Миграция модулей

Несколько слов «в общем» о том, какие модули SAP куда могут мигрировать в экосистеме «1С».

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

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

В случаях, когда дело касается автоматизации розничных продаж, то здесь мы можем рекомендовать использовать «1С:Розница», которая в связке с «1С:ERP» или «1C:Управление Холдингом» может закрыть потребности автоматизации целой торговой сети.

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

Говоря о функционале SRM (взаимоотношения с поставщиками, организация конкурсов, рекламационная работа – то что есть в SAP Ariba), то альтернативой ему служит решение «1С:Бизнес сеть».

В случаях , когда мы рассматриваем задачи корпоративных закупок, не обойтись без «1С:Управление Холдингом», как взятым отдельно, так и в комбинации с «1С:ERP».

По вопросам складского учета, управления запасами (что содержится в модуле ММ экосистемы SAP) есть два варианта автоматизации складского учета. Если используется только модуль ММ, который содержит базовый функционал складского учета, то достаточно будет «1С:ERP», которая даже перекроет возможности модуля MM (например, в части адресного хранения товара). А вот для модуля EWM возможностей «1С:ERP» может уже не хватить и надо рассмотреть комбинацию с использованием конфигурации «1С:WMS».

Автоматизация транспортировки грузов реализована в SAP модулем TM. При переходе на продукты «1С» функционала системы «1С:ERP» хватает для простой транспортировки – есть заявки на доставку, маршруты доставки и прочее. Если же заказчику этого не хватает, что возможно у транспортных, логистических предприятий, то следует добавить отраслевое решение, как вариант,  «1С:Управление автотранспортом».

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

За расчет себестоимости, бухгалтерский, налоговый учет в SAP отвечают модули FI и CO. Здесь для замены вполне подойдет «1С:ERP» или «1С:Управление Холдингом» в зависимости от масштаба решаемых задач.

Отметим, расчет себестоимости в SAP существенно отличается от производимого в «1С:ERP». В SAP практически везде используется плановая себестоимость. И только в конце месяца, когда рассчитывается фактическая себестоимость, осуществляется фиксация отклонений плановой и фактической себестоимости, отклонения сохраняются в отдельных регистрах и позволяют дать полную (фактическую) себестоимость в отчетах. В «1С:ERP» всегда считается фактическая себестоимость. Решение от SAP в рассматриваемой части не лучше и не хуже решения от «1С», оно просто другое и найти ему полную замену не получится. Лучше всего, в части расчета себестоимости, сразу осознать, что концепция «1С» другая, и на нее надо просто перейти – никакая точность анализа данных при этом не пострадает (для этого есть свои соответствующие инструменты получения и сравнения плановых и фактических цифр – например, в подсистеме бюджетирования или при использовании плановых калькуляций в производстве).

Функционал казначейства в модуле FI полностью перекроет функционал «1С:ERP» или «1С:Управление Холдингом» - в зависимости от конкретного типа заказчика.

По бюджетированию и финансовой отчетности нужно анализировать конкретные задачи заказчика. Если предстоит решать вопросы бюджетирования отдельного предприятия, то достаточно использовать функционал «1С:ERP», который удобно настраивается и имеет больше возможностей по сравнению с SAP. По задачам бюджетирования и отчетности холдинга, можно использование «1С:Управление Холдингом» вместе с «1С:Аналитика».

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

Что можно в целом посоветовать заказчику при переходе с экосистемы SAP на экосистему «1С»?

Прежде всего надо пройти обучение. Фирма «1С» сейчас готовит новый учебный курс по переходу с SAP, где будет рассматриваться маппинг экосистем в целом, достаточно подробно будет рассказываться о флагманских продуктах фирмы «1С»: «1С:ERP» и «1С:Управление Холдингом», будет даваться информация о прочих специализированных конфигурациях «1С», которые могут прийти на замену специализированных модулей SAP. Обладая необходимой информацией, заказчикам, работавшим с SAP, легче будет воспринять и оценить предложения интеграторов «1С».

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

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

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

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

В завершении несколько слов о рисках перехода

Существенный риск – наличие у SAP ряда готовых модулей, которых в «1С» пока нет. Это, например, управление качеством, интегральное планирование, прогнозирование. 

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

В текущих условиях, с учетом важности импортозамещения, а для некоторых отраслей и импортонезависимости, важно иметь наготове план «Б» на случай полного прекращения поддержки вендоров иностранного ПО. Еще лучше, на наш взгляд, проанализировать свои программные решения и модули и запустить пилотные проекты внедрения альтернативных решений на российском ПО, например, на базе «1С».

Комментарии (25)


  1. Nikolay_Pervukhin
    04.07.2022 12:09
    +2

    Спасибо большое за статью! Вы пишете про SAP, что "большая база данных требует десятков терабайтов оперативной памяти". Подскажите, пожалуйста, на какое ориентировочное кол-во пользователей рассчитаны столь невероятные ресурсы? Какую примерную конфигурацию серверов 1С можно сопоставить, чтобы справится с аналогичной нагрузкой?


    1. ERP Автор
      04.07.2022 16:52

      Николай, приветствуем. Дима Малышев просил передать, что «давно тебя не видел, а Зима близко» )))

      Оборудование зависит от числа пользователей и размера базы посмотри тут сервисы как подобрать

      https://infostart.ru/1c/articles/1062673/

      Большие сервера с терабайтами памяти есть и под 1С (например у Мясницкого ряда или Деловых линий)


  1. saipr
    04.07.2022 12:15
    +1

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

    У SAP-а есть одно неоспоримое достоинство. Это поддержка протоколов SNC (Secure Network Communications) и SSF (Secure Store and Forward). Протокол SNC используется для защиты от несанкционированного доступа путем аутентификации пользователей на сертификатах ключа проверки электронной подписи (ЭП) и защиты сетевого трафика в продуктах компании SAP, функционирующих на базе Web Application Server. Протокол SSF используется для защиты документов и обеспечения их целостности. В отличие от SNC механизм SSF встраивается в функционал ERP-системы, предоставляя приложениям программный интерфейс SSF-API. Протокол SSF позволяет как шифровать, так и подписывать электронные документы.
    Более того, эти есть реализация этих протоколов на российской криптографии (РЖД, например).
    Очень хочется надеяться, что что-то подобное есть и 1C. Сегодня трудно представить документооборот без использования электронной подписи.


    1. iliabvf
      04.07.2022 12:26
      +6

      Главное премущество SAP это поддержка интернациональных стандартов аудита, которым, конечно, в России все равно.


      1. saipr
        04.07.2022 12:52
        +1

        С этим не поспоришь.


    1. ERP Автор
      04.07.2022 16:52

      Шифрование трафика между клиентом и базой в 1С есть.

      Использование ЭЦП и ключей в 1С есть.

      Электронный документооборот и т.д. в 1С на гребне волны (в ногу со временем).


  1. LordDarklight
    04.07.2022 15:51
    +11

    Опять всё сравнение свелось к тому что дороже, что проще дорабатывать, и что быстрее и производительнее (да и то, в практически эта тема не затронута - потому что статья маркетинговая, написана 1С-никами как агитации 1С систем - а тут сравнение не в пользу них).

    Модули SAP разобраны очень поверхностно.

    То что по сути в экосистеме 1С Предприятие 8 нет модульности системы построения бизнес-решения - практически не сказано - попытка выдать отдельные решения за модули кажется смешной (так как все они разрознены, имеют различную архитектуру и кучу проблем взаимной интеграции), так же смешной как выдать за модульное решение гигансткого мудрёного и крайне не интрузивного монолита как 1С EPR 2.

    Опущены и проблемы интеграции разных решений друг с другом - такой единой шины интеграции как в SPA в 1С нет - есть попытки что-то такое наметить - но пока ничего конкретного не реализовано! Есть процессы обмена - но даже в них нет единения - хотя есть тенденция на внедрение протокола 1С Enterprise - но пока и тут всё не так уж хорошо - а сам протокол не идеален и имеет свой ворох недостатков, требующих активной работы напильником!

    Да - в 1С Предприятие 8 - доработки не сложны (ну если не брать в расчёт такой монолит как 1C ERP 2 и его агломерации с другими гигантскими продуктами) - вот только делать их придётся много и часто! А ещё раздельно для каждого продукта - ибо межконфигурационная совместимость доработок близка к нулю! А потом ещё и будет головная боль при обновлении таких доработанных решений - тут даже технология расширений конфигураций не панацея (в силу её большой ущербности)!

    О производительности 1С Предприятие 8 лучше вообще умолчать - не то, что она очень низкая - она достаточная - при умелом ручном скрупулёзном допиливание выявленных в реальной эксплуатации узких мест! Только не думайте - что с этим справятся рядовые 1С программисты. Нет тут нужны спецы уровня 1С Эксперт по технологическим вопросам. Так вот, с их помощью (или без) производительности хватит небольшим и средним предприятиям (если не ставить монолиты на базе 1С ERP 2) - особенно учитывая, что продукты 1С по отдельности можно достаточно эффективно распределить по разным кластерам серверов и даже разным СУБД - вот только обмен между ними придётся налаживать - хотя типовые схему будут - но если будете их дорабатывать - то будьте готовы к проблема в обмене, особенно после частых установок обновлений - а у 1С их много как и много ошибок в их решениях!

    И, вот, об ошибках и обновлениях тоже ничего не сказали - а 1С весьма забагованная система - и очень динамически меняющаяся - обновления частые, для разных решений свои, ошибки в них тоже свои, и примерно раз в несколько лет происходят весьма крупные обновления архитектуры решений - настолько - что они могут быть почти полностью с нуля переписанными (хотя бы на уровне отдельных подсистем - не путать с полноценным модулями - это в 1С такая виртуальная учётная единица элементов конфигураций - для построения интерфейсов)!

    Но возвращаясь к производительности - если у вас объёмы данных уровня BigData- то система 1С Предприятие 8 не лучшее решение - во-первых в ней нет должной интеграции с СУБД такого уровня. Во вторых - даже кластерная система с дата акселераторами не даёт такого преимущества как прямая обработка данных прям в памяти на кластере-серверов СУБД! И да - кластеров сервера приложений в 1С может быть много - а вот сервер СУБД для одного решения только один! Да - нетиповыми путями можно наладить различные схемы работы с разными СУБД - но всё это не из коробки - всё не просто - и всё без какой либо поддержки и гарантии со стороны 1С - а зачастую ещё и с нарушением лицензионного соглашения!

    Интерфейс в 1С тоже меняется - от обычного приложения к управляемым формам первого поколения, затем к Такси, и далее к "Такси 2.0" (название придуманное - т.к. в 1С с какого-то момента решили оставаться в рамках одного и того же нейминга и не пугать пользователей новыми именами "в тихую" меняя решения без изменения имён и зачастую без изменения редакций) - для более эффективной работы с мобильными приложениями!

    Вот мобильные приложения в 1С хороши - особенно мобильный клиент - но всё это требует особого подхода в разработке конфигурации решений (тот самый "ТАКСИ 2.0" и особые нюансы клиент-серверной разработки и взаимодействия через WEB-протоколы, чуждые большинству 1С программистов) - и типовых решений с поддержкой всего этого считай нет (как почти нет и не типовых).

    Отчётность в 1С - отдельная тема - вроде бы и средства неплохие есть - позволяющие достаточно быстро делать вполне крассивые отчёты - вот только устарели они уже всё давно!

    Чем хорош SAP или иные системы - тем что позволяют к себе легко прикручивать сторонние решения без каких-либо нарушений лицензионного соглашения! Вот эти сторонние решения на несколько порядков способны расширить возможности базового ущербного функционала SAP или какой-то другой импортной учетной системы. Да - разработка таких расшгений не проста - зато очень гибкая и эффект тоже очень значимый! Но главное - это стабильность - разработал один раз - и не нужно переделывать через каждые 5 лет - будут работать - можно развивать и украшать - будут рабоать и через 20 лет - не нужно тратить силы на постоянное переделывание!

    А у 1С такое попросту невозможно - вот и топчатся все на месте!

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

    А уж как устарели языки разработки в 1С и говорить тошно - платформа хоть и немного развивается - а языки разработки застряли на уровне конца XX века! И все они проприетарные! Внешние компиляторы не подключить (в силу ущербности так же застрявшей в конце XX века виртуальной стековой машины среды исполнения), как и не подключить и внешние библиотеки! Собственных библиотек не много - зато много их различных версий (плохо обратно совместимых друг с другом) разбросанных по разным актуальным конфигурациям решений.

    Хорошо - хоть есть поддержка внешних компонент - но в силу кроссплатформенной ориентированности - только компонент скомпилированных в машинных кодах и то - тут полно своих нюансов!

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

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

    IDE в 1С Предприятие тоже - "пиши пропало" - их сейчас две и обе ущербные! Устаревшие на пару десятилетий! Хотя да - лет 20 назад - зашли бы на ура!

    И т.д. и .п.

    У платформы 1С Предприятие 8 хороший был внутренний потенциал и исходная архитектура - но всё это было хорошо 20 лет назад - когда она и появилась - с тех пор всё очень сильно устарело! И очень сильно не хватает, как полноценной модульности архитектуры решений, так и развития платформы, виртуальной машины и языка под современные тенденции сокращения объёма кода и его повторное использование! И тут надо не догонять - а перегонять конкурентов! А не топтаться на месте где-то в 90-х годах прошлого века!

    Ну и надо развиваться в плане более эффективной интеграции и более быстрого исполнения алгоритмов обработки данных, и поддержки актуальных фишек СУБД для повышения производительности обработки больших порций данных! Вводить поддержку кластеров СУБД и гибкую поддержку специализированных СУБД NoSQL, а не только чисто реляционных - так как именно NoSQL СУБД сейчас наиболее востребованы при обработке BigData.

    Так же нужно более глубоко интегрироваться в микро сервисную архитектуру внутри СУБД - чтобы тратить меньше времени на посредников и передачу данных, а так же давать больше возможностей сторонним решениям расширять возможности всей системы за счёт более лёгкой интеграции в глубину, без нарушения лицензионных ограничений!

    Вот тогда у 1С будет будущее.

    Впрочем а зачем ей такое будущее - в нынешних реалиях 1С Предприятие 8 в России скоро будет практически единственной значимой учетной системой - так какой смысл в ней что-то менять - когда и так - почти ничего не делаю можно хорошо доить пользователей - в т.ч. давать хлеб многочисленным франчайзинговым компаниям - которые на слабостях платформы 1С уже давно научились делать собственную кассу - обирая клиентов после каждого обновления или доработки!

    А доработок в 1С нужно много - типовые решения (даже 1С EPR 2) - это уж очень своеобразные полуфабрикаты - малопригодные для ведения прямой коммерческой деятельности большинства предприятий - без доработок! Это не SAP - где можно привыкнуть работать! Это 1С где нужно привыкнуть её постоянно дорабатывать, обновлять и снова дорабатывать даже не под изменения в Российском законодательстве (что происходят достаточно часто) - ибо даже типовые решения после обновления если заработают без ошибок - то далеко не всегда так как нужно для сдачи регламентированной отчётности, выдачи нужных печатных форм или соблюдения тех или иных новых регламентов ведения бизнеса! Не говоря уже о том, что в типовых 1С конфигурациях нет и 1/16 всего функционала по минимуму необходимого для ведения большей бизнес деятельности в России без отраслевых конфигураций или доработок. Да и с отраслевыми "расширениями" тоже не будет и 50% охвата!

    P.S.

    Я не агитирую оставаться на SAP или каких-то других сторонних учётных импортных решениях. SAP HANA - на мой взгляд в целом хуже 1С (во всё, кроме эффективности работы с BigData, модульности, гибкости интеграции, стабильности и надёжности - а разве что-то ещё нужно - красоту при желании можно в SAP и лучше сделать, чем в 1С Предприятие 8 Такси, как и мобильную разработку).

    И мигрировать на 1С безусловно стоит (российским компаниям то уж точно).

    Но о проблемах этой миграции нужно знать куда больше - чем рассказано в данной статье и даже в моём комментарии!

    Сто раз надо подумать и тем, кто захочет создать свою персональную учётную систему для решения внутренних нужд - на Java, JavaScript, C#.... Этот путь по изобретению велосипеда очень тернист, сложен и чреват проблемами в будущем. Хотя - вот быть может именно из такой системы когда-нибудь и зародится конкурент для 1С Предприятие, которая в нынешних условиях окончательно рискует потерять весь стимул развития, и продолжит загнивать и топтаться на месте!


    1. atsi
      04.07.2022 17:00

      Огромное спасибо! Ваш комментарий несет больше смысловой нагрузки, чем статья выше ) Работаю с SAP, работала с 1С (не ERP, но хватило оценить "поддержку") - поддерживаю Ваше мнение обеими руками.


    1. ERP Автор
      04.07.2022 18:55
      +1

      Благодарим за развёрнутое детализированное мнение. Позвольте с некоторыми высказанными положениями не согласиться как с несколько устаревшими к настоящему времени. К сожалению, на такой же развёрнутый ответ пока не хватает времени.

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


    1. regint
      05.07.2022 06:46

      А как вам такое сравнение, когда фирма тратит лярд на внедрение SAP, нанимая интегратора крупного, но не выходит в релиз.


      1. LordDarklight
        05.07.2022 09:40

        Как-будто на кладбище проектов 1С нет таких примеров. Ну ярд там, наверное никто не терял в таких случаях - там просто порядок цен другой - куда более скромный - но слышал про некоторые случаи, где компании похоронили десятки миллионов долларов, но так и не получили желанный продукту - но в большинстве случаев остались на 1С - просто продолжая вкладывать и вкладывать и вкладывать - ибо альтернатив в России считай то и нет. Особенно в нынешнее время! А 1С тут хороша тем - что доработка не так уж и сложна и дорога, как у того же SAP - со временем довести до ума всё-таки можно будет! Тут всё в итоге только в производительность упрётся - но производительность штука очень интересная в плане оптимизации - если есть желание, деньги, а, главное, интеллект - мутить разные схемы её повышения до нужного уровня можно и в экосистеме 1С - доведя скорость выполнения бизнес-процессов до требуемого уровня - но перелопатить придётся мнгого - как и, вероятно, подключить сторонние СУБД через имеющиеся в 1С возможности - а они-таки есть - просто всё в руном режиме - так сказать - через одно место - даже через три места как минимум - но в 1С работают со сторонними СУБД - в т.ч. NoSQL - и на эту тему можно и статьи нарыть и даже некоторые готовые сторонние решения. И шины данных подключают - в т.ч. известные как RabbitMQ и другие. Жить можно - просто нужно быть готовым к трудностям - и к тому, что хороших спецов для преодоления этих трудностей почти нет - как и обширного пласта информационных материалов!


      1. ERP Автор
        06.07.2022 09:25

        Очень жёстко...


    1. Necessitudo
      05.07.2022 08:37

      Плюсую всеми фибрами души. Особенно хочу погоревать по поводу IDE - конфигуратор устарел уже лет 20 как и не развивается, а EDT пользоваться невозможно в силу огромного количества багов.


      1. LordDarklight
        05.07.2022 09:46

        1С EDT тоже не ахти какая современная, удобная и производительная среда разработки - тот же устаревший Eclipse на плагинах! Это вам не IntelliJ IDEA и не Visual Studio, и даже не VS Code - хотя у меня к этим именитым редакторам претензий не на много меньше чем к EDT (чисто архитектурных) - но всё-таки там есть умные помощники - которые в последних версиях очень очень очень очень сильно помогают набирать код, сразу находить в нём ошибки и производить его рефакторинг!


  1. krids
    04.07.2022 20:40
    +1

    Платформа SAP называется SAP HANA. Это современная среда разработки, отладки, исполнения, на которой пишутся программы бизнес-автоматизации.

    SAP HANA это СУБД. А "платформа" это SAP Netweaver. Неплохо бы в основах матчасти конкурента разобраться прежде чем "анализировать"


    1. LordDarklight
      05.07.2022 10:29
      -1

      Вот сколько слежу за темой SAP - а термином SAP Netweaver почти никто не пользуется - в ходу SAP ERP (SAP R/3) и SAP HANA (SAP R/4). И оба этих термина - это части SAP Netweaver (в сообществе устоялись SAP R3 и SAP HANA как старая и новая версия движка) . Но в целом - да - SAP Netweaver - это название для базовой платформы (к слову - термин не такой уж и старый - проявился с выходом SAP HANA но применим и к SAP ERP т.е. к SAP R/3 - хотя к ним этот термин почти не применяют - да и вообще R3 уже считается устаревшим решением). Просто SAP модульная даже платформа - и состоит из ряда отдельных программ. SAP ERP и SAP HANA - это непосредственно движки CУБД - SAP R/3 - работает с внешней СУБД, SAP HANA сама является СУБД (но может и к другим источникам данных подключаться). К этим движкам прикручиваются дополнительные прикладные как бы расширения или посредники - которые вместе уже SAP Business Suite (например: SAP PI, SAP BI, SAP EP, SAP MDM). В SAP Netweaver входит ещё один важный компонент - SAP Web Application Server - именно к нему прикручивают дополнительные инструменты - по сути это сервер приложений. В SAP Netweaver входят так же ещё SRM, CRM, SCM, PLM - это и расширения платформы - и модули одновременно - что-то вроде платформенных компонент в платформе 1С 7 как Оперативный учет, Бухгалтерия, Расчёт (в платформе 1С 8 аналога нет - ибо она совсем не модульная).

      Есть ещё продукт SAP BusinessOne - это дополнительная надстройка - в основном для графического представления и анализа данных - без неё возможности SAP в этой части очень скромны. В SAP Netweaver она не входит - и вообще разработана не SAP AG - но уже давно купена и находится под крылом компании SAP AG

      Вообще эта модульная архитектура SAP - шутка весьма запутанная. Тут нет чёткой грани между абстрактной платформой, движками и прикладными решениям! Но чёткие компоненты есть - как есть и чёткие зависимости между ними и чёткий функционал, который они обеспечивают - и чёткое раздельное лицензирование этих компонент! И к SAP есть ещё куча как бы внешних надстроек, в т.ч сторонних - за отдельную плату! Как бы внешние они потому, что интеграция в SAP между всеми компонентами достаточно низкоуровневая - и большой разницы межу внутренними и внешними компонентами нет - как нет и высокоуровневого API - поэтому всё дорабатывать решения на SAP, и, тем более, разрабатывать новые компоненты или модули - дело очень муторное, дорогое и сложное. Но большинство компонент модулей (особенно от SAP AG) разработаны очень давно и давно очень хорошо оптимизированы и отлажены - и со временем почти не меняются!

      И в целом SAP - это что-то типа платформы 1С 7 (скорее вместе с 1С ++ хотя ООП в SAP так же нет как и в 1С) - такой же в целом корявый - но модульный и вылизанный до внутреннего совершенства! Ну и SAP HANA - это своя и очень неплохая производительная inMemory СУБД (с очень жёсткими требованиями только на сертифицированное оборудование по заоблачным ценам) с хорошо реализованными микросервисами обработки данных на встроенном движке - SQLScript (это своё расширение SQL) и JavaScript. И SAP с высокими возможностями интеграции и расширения дополнительными программными продуктами (чего 1С тоже очень не хватает) - которые позволяют даже из корявого и некрасивого базового функционала сделать конфетку - куда более презентабельную чем 1С Предприятие 8 (без потерь в производительности)!

      Вот только ушла SAP AG из России - так какой смысл её обсуждать и далее рассматривать российским компаниям - деньги распилены и потрачены - фенито-ля комедия - теперь готовьте новый бюджет - и переходите на то, что пока ещё живо и процветает в России!


      1. PhysicalGraffiti
        06.07.2022 21:02
        +1

        Вы плохо следите за темой. Какой же у вас винегрет из всего

        Вот сколько слежу за темой SAP - а термином SAP Netweaver почти никто не пользуется - в ходу SAP ERP (SAP R/3) и SAP HANA (SAP R/4).

        Либо SAP R/3, либо SAP S/4Hana. Как найдете в гугле R/4 - сообщайте

        Но в целом - да - SAP Netweaver - это название для базовой платформы (к слову - термин не такой уж и старый - проявился с выходом SAP HANA но применим и к SAP ERP т.е. к SAP R/3 - хотя к ним этот термин почти не применяют - да и вообще R3 уже считается устаревшим решением)

        СУБД SAP HANA вышла в 2010 году (https://ru.wikipedia.org/wiki/Hana)

        SAP Neatweaver - именно платформа, Вышла в 2004 году (https://ru.wikipedia.org/wiki/SAP_NetWeaver)

        SAP ERP и SAP HANA - это непосредственно движки CУБД - SAP R/3 - работает с внешней СУБД, SAP HANA сама является СУБД (но может и к другим источникам данных подключаться)

        SAP ERP - это ERP система. СУБД могли быть самые разные (oracle, ms sql, db2, sybase, sapbase) https://en.wikipedia.org/wiki/SAP_ERP

        SAP HANA - СУБД (см. ссылку выше)

        SAP S/4HANA - снова ERP система (https://en.wikipedia.org/wiki/SAP_S/4HANA)

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

        Как пример:

        Есть ещё продукт SAP BusinessOne - это дополнительная надстройка - в основном для графического представления и анализа данных - без неё возможности SAP в этой части очень скромны

        SAP BusinessOne - это система ERP для малого и среднего бизнеса (вот как раз она - аналог 1С по целевому сегменту). https://en.wikipedia.org/wiki/SAP_Business_One


  1. krids
    04.07.2022 21:53

    если мы разобьем обе платформы на классическую трехзвенную архитектуру (клиентское приложение, сервер приложений, сервер базы данных), то система HANA будет перекрывать две функциональные задачи – задачу хранения данных (сервер базы данных) и сервер приложений. 

    Нет, не будет. Сервер(ы) приложений в ABAP- системах отдельная сущность как и в 1С. Опять не понимаете основы.


    1. LordDarklight
      05.07.2022 11:06
      +1

      В целом Вы правы. Как Выше написал - в SAP всё очень запутано и некоторые грани размыты. Я не буду утверждать - что это плохо или хорошо - просто так есть - но разобраться с наскока с этим не просто.

      По сути SAP HANA - это продвинутый движок СУБД - как бы со встроенным ORM API - через HTTP-сервис - сейчас популярное решение для NoSQL СУБД (хотя SAP HANA не стоит, наверное полностью причислять к NoSQL СУБД - поддержка подобия SQL там есть - но сама СУБД гибридная, а не чисто реляционная - в этом её сила).

      Так же внутри SAP HANA реализован и продвинутый программный интерфейс полу-прикладного уровня - позволяющий писать на SQLScript (особое языковое SQL подобное расширение - ну что-то типа продвинутого, скажем, Transact SQL в СУБД MS SQL Server) алгоритмы обработки данных.

      Так же там можно создавать алгоритмы и на JavaScript (есть эдакая встроенная своя реализация Node.js - хотя, наверное, сравнение не совсем правильное - ибо эта поддержка куда более скоромная по сравнению с Node.js - но распределённые транзакции алгоритмы вроде бы поддерживаются - но тут я не уверен). К слову, например, у СУБД MS SQL Server тоже, в общем-то есть свой аналог - там встроенный движок .NET (скомпилированных в IL с любого .NET ЯП, или прямо в СУБД писать алгоритмы на C#) - можно подгружать функции из библиотек DLL и вызывать их из Transact SQL. Есть ещё MS SQL Server и достаточно мощное встроенное расширение на базе статистического языка R - но это уже очень специфическая вещь. Есть аналогичные решения и СУБД Oracle - на базе Java. Просто там всё не так глубоко развито как в SAP HANA, и используется крайне редко.

      К слову - для ряда NoSQL СУБД - встроенный программный интерфейс явление более популярное и востребованное. Например в СУБД тарантул - внутренний API выстраивается на языке Lua - но тоже с очень ограниченными возможностями - хотя и используемыми очень часто.

      Такая модель внутреннего программного интерфейса в СУБД SAP HANA позволяет создавать прямо внутри движка СУБД высокопроизводительные микросервисы, с минимальными издержками производительности, как экспортируемый внешний API, которые могут выполнять основные команды обработки данных. Которые можно модифицировать и которые можно расширять. Отчасти бизнес-логика тут может быть реализована - но обычно всё ограничивается только встроенными микросервисами условно типовых модулей.

      Микросервисы дёргаются с сервера приложений - SAP Web Application Server (и из его надстроек) - где уже размещается основная бизнес логика, описываемая на языках ABAP/4 и даже на Java


  1. GordonFreemann
    06.07.2022 09:26

    "...стоит ли?" - ударение на какой букве) ?


    1. ERP Автор
      06.07.2022 09:27

      :)


  1. ZharkovIlya
    06.07.2022 09:28

    SAP и правда ушел из России и это надолго, поэтому обсуждать его смысла нет. В моем случае мы рассматривали вариант замещения нашей системы на 1С, но нам сразу сказали, что реализация в рамках одной инстанции 1С невозможна, ввиду того, что размер нашей СУБД около 150 Тб и предложили разбить на несколько баз. Только пользователи ждут именно "бесшовного" перехода, без значительных потерь ни в функционале ни в бизнес процессах. Проще говоря если раньше один человек проводил расчет ЗП для 200 тысяч ТН, он и в новой системе должен это делать в единой базе, этого нет. Сейчас сразу несколько крупных IT компаний(точно известно про 3) пытаются разработать замену SAP на основе собственной платформы на микросервисной архитектуре, а про шаги 1С в этом направлении мне неизвестно. Отдельно хочется сказать про ЗП специалистов, постоянно слышу что специалист 1С это дешево, а SAP дорого. Но все зависит от компетенции, та же МС архитектура требует привлечения DevOps инженеров с ЗП превышающей цену прикладных специалистов и SAP и 1С. Специалист получает ЗП не за знание ABAP, синтаксис можно за месяц выучить, а за свои практические знания и опыт.


    1. LordDarklight
      06.07.2022 10:24

      "одной инстанции 1С невозможна, ввиду того, что размер нашей СУБД около 150 Тб и предложили разбить на несколько баз. Только пользователи ждут именно "бесшовного" перехода"

      Да BigData 1С не по зубам пока. Но тут реально надо подумать - а действительно ли есть потребность сразу в этих всех 150Тб - что это за данные? Все ли они востребованы в рамках оперативного учёта - или там больше половины просто нужно отправить в архив?

      Если же это всё оперативные данные (или условно однородные используемые в каждом периоде)_ - то наверняка их можно секционировать - напрямую на одной СУБД разбить по файлам и дискам, и на кластерах 1С тоже распределить нагрузку на разные серверы и их процессы (процессоры). Да - придётся повозиться с доработками - но это не значит, что это невозможно!

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

      И насколько глубоко связаны бизнес-процессы, обрабатывающие эти 150Тб? Лично на мой взгляд - нет ничего уж очень адски плохого в дроблении на инстансы - например, оперативный-управленческий учёт легко отделяется от финансово-регламентированного как и от кадрового! А чтобы не было ярко выраженных швов - вставляют условные объекты-формы-заглушки и смежные вспомогательные реквизиты и таблицы - просто для ввода и отображения данных - а всю их обработку выносят в другие базы с которым налаживают синхронизацию по нужным контурам с нужной детализацией. Нужно взаимодействие в реальном времени - ну наладьте рантайм обращения в другую базу по HTTP сервисам в т.ч. через REST API - 1C это всё легко умеет - вот чего ей не хватает - так параллельности в клиентском контексте (в серверном контексте, условно, распараллеливание доступно - но через одно место) - а асинхронные вызовы уже завезли (но только на клиенте).

      Получение аналитической информации для отчётов в 1С так же можно делать из других баз - те же HTTP сервисы, REST API - а можно и по старике - через OLE. При желании можно и напрямую в СУБД влезть - САПерам же не привыкать к такому!

      И вообще - эра монолитов и больших баз уже проходит - сейчас рулит разбиение на микросервисы и отдельные компоненты - пусть платформа 1С Предприятие 8 изначально под это не затачивалась - но это не значит, что её нельзя под это приспособить!

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

      Интересно - что это за компании, которые решили разработать свой SAP? И что это за проекты? И что за собственная платформа на микросервисной архитектуре?


    1. ERP Автор
      06.07.2022 11:26

      Ну, Ваш проект, действительно, нетиповой. Тут мы Вам рекомендовали бы обратиться непосредственно в фирму "1С". Если нужны контакты – напишите в личку.


    1. iNomad
      06.07.2022 22:40

      SAP ушел, но от этого S4HANA не умерла. Всё что изменилось так это то что за отсутствие поддержки платить не нужно. А эти бюджеты можно перенавправить на своих разработчиков.