SAP уходит из России: как адаптироваться к новым условиям

19.01.20231675 Время чтения: 12 мин.
Алексей Порхачев работал в коммерческом департаменте ООО "САП СНГ" (SAP) и в различных российских стартапах (в том числе базирующихся в Сколково). В последние четыре года занимался, по собственному определению, "лицензионным консалтингом", помогая корпоративным заказчикам в РФ создавать справедливые и устойчивые взаимоотношения с вендорами - Oracle и SAP. В сентябре 2022 года Алексей Порхачев присоединился к команде RAMAX Group, став директором по развитию сервисов поддержки программного обеспечения SAP. В докладе на конференции ITSMIR он представил продуманный подход к обеспечению работоспособности систем SAP, которые остались без развития и должного уровня поддержки со стороны глобального разработчика.
В феврале 2022 года моя работа в сфере "лицензионного консалтинга" стала неактуальной: SAP, Oracle и другие западные ИТ-вендоры либо покинули рынок РФ, либо остановили свою деятельность - но желание обеспечивать справедливые и устойчивые условия для нашего потребителя иностранного ПО стало сильным как никогда. Российским заказчикам SAP теперь приходится жить с тем, что осталось - а остались огромные системы с большим количеством пользователей, и их полноценная замена на отечественные аналоги - процесс долгий, который потребует больших усилий и исключительных навыков создания развивающегося и востребованного на открытом рынке продукта. В отсутствие таковых придется докатывать свою "иномарку" - точнее, ПО SAP, пока "мотор не застучит".

Проблематика вокруг темы ERP-систем в России начинается с того, что полноценных замен SAP пока нет, то есть по полному спектру функционального и технологического стеков. Процессы импортозамещения SAP сейчас проходят там, где есть политическая воля - как, например, в государственных компаниях, компаниях с госучастием или компаниях с большим объемом КИИ. На текущем уровне зрелости отечественного ПО и компаний-разработчиков это приводит к "лоскутной автоматизации" со всеми вытекающими. Однако в прочих коммерческих компаниях подобная активность преимущественно остается на уровне размышлений и проработок. На первом месте стоит экономическая целесообразность этой замены. Такие ИТ-гиганты, как SAP, ежегодно тратят на R&D многие миллиарды долларов. И нам, чтобы хоть как-то конкурировать (а конкурировать нужно, не замыкаясь на российском рынке и не пользуясь исключительно сложившейся конъюнктурой, которая может измениться в будущем), хорошо бы приблизиться по затратам на разработку отечественных продуктов хотя бы к уровню 10% от этих сумм. И нужно задаваться целью не заменить "шило на мыло", а превзойти, выйти на новый уровень, создать следующее поколение систем, чтобы обеспечить ту самую экономическую целесообразность для любого сегодняшнего потребителя SAP вне зависимости от страновой принадлежности. Это залог долгосрочного и устойчивого развития.

Кадры решают

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

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

Известная фраза "кадры решают все" в нашем случае сверхактуальна. Нужно очень хорошо подумать, как сохранить экспертов, которые внедряли и развивали системы SAP. Необходимо их правильно замотивировать для работы с рынком в его новом состоянии. Важно сформулировать новые лучшие практики, ведь ни одной презентации SAP не проходило без первого слайда о том, что использование его продуктов – это "Best practices" и "The best-run businesses run SAP" ("лучшие практики" и "самые успешные компании используют SAP").

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

Ценный актив

Хорошая новость: у нас осталась возможность не только эксплуатировать, но и развивать системы SAP. Но важно понять, в каких условиях это можно делать и как обеспечить безопасность.

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

До февраля 2022 г. компании во всех отраслях экономики формировали собственные ИТ-стратегии на 3-5 лет, а некоторые – и на десятилетие. И в подавляющем большинстве случаев у крупных компаний эта стратегия была SAP-based. На перестройку стратегий придется потратить много времени, и заказчикам нужно в этом помочь. С февраля отечественные вендоры и интеграторы начали наперебой предлагать клиентам свои различные идеи по замене или альтернативной поддержке используемых систем SAP. Порой за неделю к ИТ-директору приходит с десяток таких компаний, причем со столь разнонаправленными идеями, что он вынужден разворачивать их в ожидании более системного и стратегически выверенного предложения. Для любого ИТ-директора поспешные решения в этих вопросах чреваты рисками несоразмерными с теми, которые существуют при длительном сохранении текущего статус-кво.

Новая экономическая политика

Да, для многих пока SAP заменить нельзя. Все рычаги были и остаются на его стороне, а технологический суверенитет – это способность и возможность влиять на принимаемые решения. После февраля компании SAP, Oracle, Microsoft и другие западные ИТ-вендоры приняли самостоятельное одностороннее и политически-мотивированное решение об уходе с российского рынка. И, хочу особенно отметить, они сделали это в отсутствие вынуждающих их внешних факторов – заказчиков и сотрудников в РФ они не спрашивали, существенных технических и юридических препятствий для этого действия не было, действующим законодательством РФ не регулировалось: это явный признак отсутствия у нас суверенитета. Эти рычаги нужно изымать. И даже если завтра SAP или Oracle вернутся, взаимоотношения с ними следует выстраивать в новом договорном и законодательном поле.

Если зарубежные ИТ-компании придут в Россию с предложением возобновить сотрудничество, мы должны предъявить им ряд принципиальных условий. Одно из них – распределенная система рычагов. Можно привести в пример те компании, которые купили у SAP "облачные" платформы e-commerce Hybris. Для некоторых эта платформа является единственным или одним из ключевых инструментов продаж: она находится в "облаке", которое размещено в европейских дата-центрах. Но SAP отказался продлевать "облачные" соглашения с российскими компаниями. Сотни миллионов, а где-то и миллиарды рублей были вложены в активы, которые не принадлежат потребителю (согласно "облачной" модели). Все, что SAP предлагает, это забрать бизнес-данные продуктивных систем, используемых по "облачной" модели, сейчас или по окончании соглашения. Можно ли после таких эксцессов все рычаги оставлять на стороне SAP? Глобалистская "облачная" модель использования ИТ-продуктов себя дискредитировала. Заказчики во всех странах теперь будут с большей осторожность подходить к размещению всех систем в "облаке" SAP при условии, что у него остаются все рычаги влияния.

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

Сам себе эксплуататор

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

Многие считают, что поддержка ограничивается обработкой инцидентов. На самом деле нужно решать вопросы на трех уровнях: стратегическом, тактическом и оперативном. Стратегический уровень предполагает выстраивание новых отношений с вендором, тем более что лицензионные соглашения SAP с российскими заказчиками продолжают действовать, они продолжают легальное использование ПО SAP.

Тактический уровень начинается с переработки ИТ-стратегий, добавив туда важнейший критерий – автономность (возможность работы без вендора). Кроме того, нужно сформировать центр экспертизы – как внутренней, так и внешней, а также разработать регламенты взаимодействия. Представители нефтегазовых и иных промышленных компаний активно хвалят внутренние разработки, но действительно ли они хотят стать вендорами и войти в ИТ-бизнес? Для того чтобы эти продукты не остались in-house (по принципу "собака на сене") и постоянно развивались, их нужно выводить в новые структуры или отдавать профильным продуктовым компаниям, которые смогут найти правильные стратегии для их продвижения. Схожая история происходит с теми заказчиками, которые намереваются своими силами обслуживать системы SAP: при таком сценарии рынку не хватит ни консультантов, ни разработчиков. Да и самим специалистам не очень интересно работать в одной компании: и им, и рынку нужна кросс-клиентская и кросс-индустриальная экспертиза. Я призываю не закрываться внутри компаний, а все неключевые и неспецифические задачи по поддержке SAP делегировать независимым профильным рыночным игрокам.

Возвращаясь к теме тактического уровня обеспечения автономной работы систем SAP – нужно создать базу знаний, доступного ПО, патчей, пакетов расширений. Пока это доступно только на портале SAP в рамках действующей поддержки. После расторжения договора поддержки использование базы и инсталляторов возможно в той части, которая была доступна на дату расторжения. Пока эта база будет вырабатываться, нужно реализовывать стратегию непрерывного совершенствования и поддержания уровня безопасности: этим должна заняться профильная компания, которая возложит на себя ответственность сопровождать ПО SAP в условиях автономии. Если этим будет заниматься in-house команда у каждого клиента SAP по отдельности, системной работы не будет.

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

Также на тактическом уровне необходимо разработать модель проведения профилактических мероприятий по повышению уровня стабильности эксплуатации систем SAP. Мало кто знает, что в стандартных договорах SAP Enterprise Support, помимо предоставления доступа к базе знаний и патчей, можно заказывать сервисы постоянных проверок качества (Continuous Quality Check, CQC), которые помогают оптимизировать производительность системы, находить узкие места – в условиях автономии эти сервисы необходимо проводить регулярно. Эксперты компании SAP были ценны своим богатым кросс-клиентским опытом, оттого качество реализации сервисов было на хорошем уровне. Держать таких специалистов в рамках одной компании – клиента SAP и использовать его опыт и навыки только для внутренних задач губительно как для этой компании, так и для самого эксперта.

Последнее, но не по значимости, в тактическом блоке – поддержка локализации. Если SAP прекратит выпускать локализационные пакеты, этим тоже придется заняться самостоятельно – в том числе и для соблюдения российского законодательства. Если каждый пользователь SAP займется локализацией in-house, получится супер-задублированная и затратная работа – логичнее объединить усилия, хотя бы на уровне отраслей.

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

Работы хватит на всех

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

С февраля на рынке появились компании, которые приходили к заказчикам, выясняли, что те платят в SAP, скажем, 22% от стоимости системы за поддержку и предлагали: "Платите нам 11% и у вас все будет замечательно". Но на вопросы о том, что же будет замечательно и за счет чего, структурного ответа, как правило, не следовало. Другие предлагали клиентам в России восстановить доступ к нотам, сделав фиктивного, так называемого, S-пользователя в Узбекистане или Казахстане. Я даже слышал о предложении перевыставлять инциденты российского заказчика через компанию-прослойку за рубежом от ее имени – и решать их таким образом. Это, мягко говоря, несистемные предложения, и они находятся на грани закона, если не за гранью. Между тем для многих клиентов по-прежнему важно соблюдать лицензионную и юридическую чистоту.

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

Источник: https://www.comnews.ru/content/223885/2023-01-19/2023-w03/sap-ukhodit-avtonomnoe-plavanie

Читайте также по теме

Цифровизация актуальна. И на импортных, и на отечественных решениях

RAMAX Group подводит итоги конференции «ИТ-суверенитет: мифы и реальность»

ИТ-суверенитет: от "русского кодинга" - к полному стеку и перестройке мозгов


Понравилась статья?

Время чтения: 12 мин.
Комментарии (0)
Отправить запрос
* — заполните обязательно
Отправить запрос
* — заполните обязательно