Привет, Хабр!
Меня зовут Сергей Шумаков, я архитектор разработки в команде ИТ Северстали, которая занимается программным модулем ремонтов SAP Plant Maintenance (он же PM, он же EAM, он же ТОРО/ТОиР). Хорошая штука, этот модуль — помогает автоматизировать различные процессы техобслуживания и ремонта оборудования на производстве.
Многое в этой деятельности связано с документацией, и значительная часть алгоритмов SAP PM состоит из работы со статусами документов. Но вот неприятность: штатные средства для этой работы совершенно ужасны.
Проблемы с штатными средствами
Неподготовленный разработчик наверняка совершит множество ошибок и попадет хотя бы в одну из ловушек, расставленных SAP. Чтобы избежать этого, мы разработали подход, который упрощает работу разработчиков и консультантов, экономит время и повышает читаемость кода.
Проект Offline Security
Недавно я начал работу над проектом под названием Offline Security. Это клиент-серверное приложение для анализа безопасности систем SAP. Для генерации отчетов вы собираете информацию самостоятельно, формируете запрос на сервер и получаете результаты в формате Excel.
Уже сейчас приложение позволяет анализировать системы на известные уязвимости (SAP Security Notes), просто выгрузив названия установленных компонентов и их версии из целевой системы. Данные абсолютно анонимные, не содержат чувствительной информации и не предоставляют возможности для злоумышленников.
Удобный отчет
Отчет, сгенерированный Offline Security, очень удобен и понятен. Призываю вас опробовать его – это бесплатно и занимет всего 5 минут. Также вы можете сравнить результаты с вашей системой и оценить ее эффективность и качество базы знаний.
Offline Security содержит ноты, выпущенные с 2015 по 2023 год, и регулярно обновляется. Следите за новыми версиями с дополнительным функционалом на сайте Offline Security.
Visit our website: Offline Security
SAP прекращает облачные сервисы в России
Немецкая компания SAP объявила об отключении российских пользователей от своих облачных сервисов. Поддержку софта в России была отключена уже в конце 2023 года. В письме, отправленном клиентам, представители SAP предупреждают, что все данные нужно выгрузить из облаков до 20 марта 2024 года.
Перспективы и варианты для российских клиентов SAP
Компания OXYGEN рассматривает перспективы и варианты для российских клиентов SAP. Согласно генеральному директору сети OXYGEN Павлу Кулакову, платформа SAP является системой управления базами данных, способной обрабатывать миллионы транзакций и проводить множество операций в секунду. Он отмечает, что эта платформа особенно актуальна для ритейла, e-com, банков и крупных отраслевых предприятий.
Миграция российских компаний и аналоги SAP
По мнению Павла Кулакова, практически все крупные российские компании за последние два года перешли с облачных платформ SAP. Он также отмечает, что российские компании уже предлагают услуги, аналогичные тем, что предоставляла SAP.
Новые возможности для отечественных разработчиков
Chief solution architect компании OXYGEN, Андрей Вахутинский, уверен, что уход SAP из России может сподвигнуть отечественных разработчиков улучшать качество своих продуктов. Он также считает, что спрос на услуги на инфраструктуру и аренду железа будет только расти.
Закрытие доступа к облачным услугам для клиентов из России
Информация о закрытии доступа к облачным услугам для клиентов из России была получена из источников СМИ. Согласно этой информации, с 20 марта 2024 года компания SAP закроет доступ к своим облачным сервисам для клиентов из России. SAP выразила готовность провести переговоры о досрочном прекращении договора на облачные услуги со всеми оставшимися клиентами в РФ.
Подробнее о возможностях облачных сервисов OXYGEN можно узнать на нашем сайте.
Здесь вы также можете подписаться на наш канал в Telegram для интересных новостей.
Российские компании переходят на аналоги SAP
Около 20% российских компаний к концу 2023 года перешли на аналоги программного обеспечения немецкой SAP. Из более чем 200 зарегистрированных аналогов ERP от SAP в реестре российского ПО, около 60% компаний в нефтегазовой, горнодобывающей, металлургической сферах и машиностроении продолжают использовать продукты немецкого вендора.
Остановка бизнеса SAP в России
В начале марта 2022 года, SAP приостановила бизнес в России из-за санкций и прекратила продажи услуг и продуктов клиентам из России и Беларуси. Компании, как Сбер и Газпром, а также многие малые и средние предприятия в России использовали решения SAP, такие как ERP, CRM, SCM, ERP Production Planning, MES, EAM, CAD.
Закрытие доступа к техподдержке
До конца 2023 года SAP планировала заблокировать российским клиентам доступ к корпоративной системе техподдержки для получения обновлений ПО, патчей безопасности и размещения заявок на помощь в рамках контрактов.
Лаб СП и их CRM- и ERP-системы
В феврале 2024 года компания Лаб СП, основанная менеджерами российского подразделения SAP, планирует выпустить собственные CRM- и ERP-системы. Первый выпуск MVP ERP-системы запланирован до конца года.
Поддержка SAP до конца 2023 года
Разработчик решений SAP прекратит поддержку партнёров и клиентов в России до 31 декабря 2023 года. Это включает блокировку доступа к системе техподдержки для обновлений ПО, патчей и запросов на помощь в рамках контрактов.
Переход к локальным IT-компаниям
Большинство корпоративных пользователей SAP в России уже передали техподдержку своих систем локальным IT-компаниям. Бывшие сотрудники SAP перешли в Лаб СП, которая предоставляет техническую поддержку и исправления систем SAP.
Необходимость аналогов SAP
Эксперты считают, что полная замена SAP в ближайшее время невозможна, поскольку решения компании являются основными для многих предприятий, а полноценных аналогов пока нет.
Источники:
- СМИ
- Российские компании
- SAP
Миграция системы учёта хозяйственной деятельности от SAP к 1С
В апреле 2023 года Аэрофлот начал процесс миграции с немецкой ERP-системы учёта хозяйственной деятельности и управления бизнес-процессами SAP на российский аналог на базе решений 1С, включая 1С:ERP. Эксперты предполагают, что миграция займет около двух лет и обойдется Аэрофлоту примерно в 1 млрд рублей. Российская авиакомпания активно использовала SAP с 2012 года.
Уход SAP из РФ
В апреле 2022 года SAP объявила, что полностью уходит из России. Разработчик решений для управления бизнес-процессами завершил работу со всеми российскими заказчиками и прекратил поддержку локальных версий своих продуктов. Пользователям облачных сервисов был предоставлен выбор: выгрузить данные, удалить их или перенести на сервер за пределы России. Однако даже в последнем случае SAP не будет работать с данными после окончания подписки. Пользователи смогут продолжать использовать ранее приобретенное и установленное ПО от SAP.
Несколько крупных российских IT-компаний и интеграторов начали дорабатывать и поддерживать ПО зарубежных вендоров, покинувших российский рынок, включая ERP-решения от SAP.
Действия SAP в РФ и странах СНГ
1 июня компания SAP сообщила о том, что уволит всех сотрудников в своих офисах в России и Беларуси, выплатит компенсации. Уволенные сотрудники смогут подать заявки на позиции в других офисах SAP за рубежом. Реструктуризация персонала компании в России и Беларуси началась и завершится до конца 2022 года, при этом все офисы SAP в этих странах будут закрыты.
SAP продолжит работу в странах СНГ: Армении, Азербайджане, Грузии, Казахстане, Кыргызстане, Узбекистане, Таджикистане и Туркменистане, создав новый кластер на базе рабочих команд, переехавших из России и Беларуси.
Отложенный уход SAP из России
В октябре прошлого года SAP отложила свой уход из России из-за невозможности найти покупателей на свои активы в стране. После уменьшения штата сотрудников и закрытия офиса SAP продолжит закрывать юридические вопросы в России в 2023 году.
Блокировка доступа к системе SAP для российских клиентов
С января 2023 года SAP планировала заблокировать доступ российским клиентам к своей корпоративной системе техподдержки для получения обновлений ПО, патчей безопасности и размещения заявок по действующим контрактам.
Преимущество новой системы учёта хозяйственной деятельности 1С
После успешной миграции системы от SAP к российской 1С, Аэрофлот сможет продолжать свою деятельность без зависимости от зарубежных решений. Кроме того, использование российских продуктов повысит общую безопасность данных и позволит компании сохранить конфиденциальность информации.
В результате критически важные для бизнеса данные – информация об ценах на товары — не успевали подгружаться в единственно возможное с точки зрения времени окно — к утру следующего дня.
Ситуация осложнялась еще некоторыми факторами:
С такими вводными мы приступили к поиску решения.
Шаг первый — что в системе?
Анализ проблемы в SAP всегда начинается с наиболее нагруженной части системы – базы данных. Мы стали искать «тяжелые» запросы в ней во время возникновения проблемы, но зафиксировать их нам не удалось. Более того, нагрузка на БД никак не коррелировала с замедлением загрузки цен. Следовательно, проблема кроется где-то на уровне сервера приложений, предположили мы.
Производительность приложения анализировали стандартно — с помощью транзакции st03n. В топе нагрузки мы заметили программу SAPLSENA — это косвенно говорило о том, что проблема находится где-то на уровне сервера блокировок.
Спустились на уровень работы операционной системы и увидели красивую полочку по CPU, которая коррелировала с проблемами в работе заданий:
ENQ-сервер полностью утилизировал одно ядро. Логичное решение – это увеличение количества тредов enqserver для повышения производительности, что мы и сделали. Описание изменяемого параметра:
The number of I/O threads. Normally you do not need to change this parameter. It may be useful to change it for increasing system performance, but this should only be done with support from SAP or your hardware provider. Experience up to now shows that a value higher than 4 has never resulted in an increase in throughput.
Для этого добавили ядер на виртуалку, и количество потоков enqserver выросло до двух. При синтетической нагрузке (кстати, ее можно генерить в sm12) получили ожидаемые 200% утилизации CPU:
Однако под продуктивной нагрузкой ничего не изменилось. У нас по-прежнему утилизировалось одно ядро. Параллелизм не отрабатывал.
Шаг второй — трассировка enqserver
На этом этапе анализ проблемы состоял из двух частей: включение логирования и разбор полученного лога. Для этого у SAP есть инструмент Enqueue Log Analyzer (Note 2763999 — How to analyze enqueue log with enqueue log analyzer).
Для включения логирования enqserver с помощью enqt необходимо выполнить следующие шаги:
Результат работы утилиты — появление файла ENQLOG99 в рабочей директории.
Так как запись debug логов дело затратное, то для снижения нагрузки на систему и уменьшения количество генерируемых логов мы скорректировали подход, включая трассировку на несколько секунд раз в 10 минут. Для этого написали скрипт и запланировали трассировку каждые 10 минут в надежде поймать проблему.
Результаты собранных данных и работу Log Analyzer можно увидеть ниже. Программа сама выделила желтым подозрительные данные:
Хотя первопричину на тот момент мы еще не нашли, в нашем паззле появилась еще одна деталь: при высокой и постоянной утилизации ядер происходило значительное снижение (Throughput) пропускной способности. То есть сильно нагруженный enqserver утилизировал CPU, но при этом обрабатывал меньше блокировок. Предположили, что это баг. Обновили ядро, но ситуация не изменилась.
Идем в код
Первоначальная диагностика помогла выдвинуть предположение о локализации проблемы, но не приблизила нас к ее решению. Поэтому пошли вглубь — в код. На этом этапе нам сильно повезло: мы поймали проблему утром, проанализировали ее и получили тайминги работы программы, обращавшейся к ENQ-серверу.
Скриншот в момент возникновения проблемы выглядел так:
Сразу смутила SAPLSENA, которая работала 1 000 секунд, что подозрительно много. Тем не менее полученные результаты были недостаточными. Мы не понимали, какую блокировку запрашивал конкретно этот пользователь. Отягчающим обстоятельством стала и невозможность моделировать проблему из-за работы с боевыми данными. Оставалось только запускать трассировку программы через st12/st05 и надеяться, что размера трассировки хватит, и проблема повторится.
Просто так ждать не стали и написали агрегатор количества блокировок по объекту и пользователям. На скриншоте ниже приведен размер таблицы блокировок в записях.
В этом месте нашли топ-пользователя по количеству блокировок. Посмотрели количество блокировок по пользователю:
Ниже посмотрели агрегацию по объекту блокирования:
Дальнейший анализ показал прямую зависимость между возникновением проблемы со стороны пользователя и количеством блокировок на таблицы MARC и MBEW. С точки зрения функциональных специалистов подобное совпадение не вызывает подозрений — эти блокировки нужны. Но тогда почему так медленно работает ENQ-сервер? Еще раз вернулись к CPU-утилизации. Теперь явно прослеживалась четкая зависимость между проблемой и нагрузкой на CPU.
Дальше мы посмотрели количество блокируемых объектов по пользователю:
На этом этапе возникло подозрение, что всё-таки происходит какая-то внутренняя блокировка в ENQ-сервере. Ведь по графику CPU утилизировалось только одно ядро, хотя в параметрах стояла утилизация четырех. Мы предположили, что проблема возникала из-за внутреннего цикла или еще какой-то нагрузки, снижающей отзывчивость к некоторым запросам. Судя по данным, тормозили только обращения к MARC и MBEW, остальные блокировки обрабатывались корректно. Помимо этого, логировалось и время обработки метода. Дальнейший лог сервера блокировок показывал: один и тот же метод (см. скрины ниже) в первом случае обрабатывал намного меньше записей и тратил на это намного меньше времени.
До проблемного задания:
Во время проблемного задания:
Красным мы выделили время операции в мс.
Зафиксировали промежуточные итоги проделанной работы:
Для подтверждения гипотезы с многократным обрабатыванием блокировок решили отключить второе задание. Иииии — бинго! Это помогло снять все симптомы.
Детальная трассировка второго задания по стеку вызовов продемонстрировала следующую картину:
Стали искать по именам программ ноты, связанные с проблемами производительности ENQ. Нашли Note 2991565 (High load on lock server) и выставили значение в настроечную таблицу:
После применения этой настройки задания стали отрабатывать штатно — проблема решена!
Эта статья будет интересна в первую очередь архитекторам и консультантам по решениям на основе популярного продукта компании SAP — корпоративного хранилища данных SAP BW.
Если вы отвечаете за развитие корпоративного хранилища данных на базе SAP BW on HANA или SAP BW/4 HANA, вы рано или поздно (лучше — рано) задумаетесь о контроле роста объемов данных «колоночных» таблиц, которые загружаются в оперативную память сервера БД SAP HANA. По рекомендации SAP, суммарный объем табличных данных («поколоночных» и «строчных») таблиц в памяти не должен превышать эмпирического значения 50% от выделенной на SAP HANA памяти сервера(ов). В противном случае, процессы в SAP HANA станут выполняться менее предсказуемо в части длительности, а порой и просто стабильности. Это относится и к процессам трансформации данных в BW (т. н. DTP), и к выполнению пользовательских отчетов.
Столкнувшись с нехваткой памяти, SAP HANA инициирует процессы вытеснения из памяти сегментов (колонок поколоночных таблиц или их партиций), которые использовались наиболее давно и имеют более высокий приоритет к вытеснению. В SAP HANA за это отвечает параметр UNLOAD PRIORITY, который устанавливается на «поколоночную» таблицу и может быть изменен впоследствии. Однако, в ситуации, когда одновременно десяткам, а порой и сотням параллельных процессов требуется больше памяти, внутренним методам выделения и освобождения памяти в HANA приходится «в авральном режиме» решать задачу определения, сколько нужно вытеснить, что именно можно вытеснить и выполнить само вытеснение. Очевидно, что это не добавляет производительности процессам, ради которых это вытеснение и выполняется. И даже при наличии таких совершенных алгоритмов возникают ошибки нехватки памяти в HANA (OOM), что приводит к проблемам уже на уровне приложения SAP HANA, а именно — SAP BW. Это выражается в аварийном прерывании процесса. И хорошо еще, если этот процесс‑ некритичный пользовательский отчет. Совсем другое дело, если это ночная загрузка. Без должного реагирования пользователи утром могут не увидеть в отчетах свежие данные.
Таким образом, задача контроля использования памяти таблицами — ключевая для стабильности работы SAP BW, основанных на SAP HANA. Задача довольно непростая, особенно если ваша система SAP BW развивается и эксплуатируется уже десяток лет сотнями пользователей. Маловероятно, что вам поможет какая‑то одна из мер, какое‑то одно из «лекарств». Скорее всего, речь пойдет о комплексной и постоянной терапии — ведь кол‑во данных прибавляется день ото дня, даже если бизнес не растет. А если, к счастью, бизнес прирастает год‑к-году, то каждый следующий год будет больше новых данных, чем в предыдущий.
В основе всех оптимизационных мер — разделение данных на, условно, «нужные» каждый день (hot), «нужные пореже» (warm) и «нужные очень редко» (cold). Эти три категории данных должны хранится в разных «контейнерах» (обобщенная формулировка, поэтому в кавычках), чтобы либо у администратора BW, либо у процессов SAP HANA была возможность выгрузить такой контейнер из оперативной памяти сервера, а то и выгрузить совсем из SAP BW. Такими «контейнерами» могут быть партиции ADSO, партиции ADSO в NSE, партиции в SAP IQ (бывш. Sybase IQ) или даже целиком ADSO. Подробнее про NSE и SAP IQ лучше почитать в официальной документации SAP. Выскажу лишь персональные наблюдения. Использование сторонней БД SAP IQ для хранения самых редко используемых данных не является эффективным. Это сильно усложнит серверный ландшафт (особенно в случае полного резервирования оборудования Disaster Recovery), потребует от вашей команды компетенций администрирования еще одной СУБД, которую в силу лицензий вы можете использовать только для одного сценария — хранение cold‑данных с доступом только из SAP BW. И влиять на производительность отчетов, использующих cold‑данные, гораздо сложнее, потому что это «внутренняя кухня» SAP BW и SAP HANA. На мой взгляд, при наличии лицензии OpenHub (входит в лицензию SAP BW/4) более оптимально использовать для cold‑данных подходящую стороннюю СУБД, по которой в вашей компании уже есть компетенции либо вы готовы их развивать. Хотя в этом вопросе много пространства для дискуссий.
Если начать разделение на hot‑warm‑cold с данных, имеющих наибольший размер, то и первые результаты будут заметнее и вдохновят вас на дальнейшие работы. Определить данные наибольшего размера в SAP HANA удобнее через системные view. Вам решать, какой критерий для этого использовать: занимаемую оперативную память или занимаемую память на диске. На мой взгляд, если мы видим в оперативной памяти огромный непартицированный ADSO, хранящий данные за 3 последних года, а, по словам пользователей (или по данным статистики), необходимы лишь данные последнего года, то, очевидно, грамотное партицирование может принести толк. Напишите в комментах, почему партицирования все же недостаточно для того, чтобы SAP HANA хранила в оперативной памяти данные только последнего года.
Переведя партиции с «warm»‑данными в NSE, вы ограничите «сверху» объем оперативной памяти HANA, которое СУБД использует для _всех_ сегментов (партиций или целых таблиц), относящихся к NSE. Цена, которую придется за это заплатить, производительность доступа к таким данным. Но ее придется платить не всегда. И причина этого — та же, что и в моем вопросе выше по тексту.
Оптимизировав структуру хранения TopN ADSO вы уже можете добиться если даже не сокращения среднего потребления памяти под все таблицы, то хотя бы прекращения его роста на горизонте нескольких месяцев. Что можно предпринять далее? Наладить процессы регулярного (раз в 1–2 месяца) мониторинга SAP HANA и изменения структуры хранения данных ADSO. У каких‑то ADSO надо создать дополнительные партиции, у других, наоборот, объединить в одну, у третьих — перевести часть партиций в NSE, что‑то вообще выгрузить из BW, что‑то переместить в «cold» ADSO и выгрузить из памяти. Поскольку хранилище не только прирастает новыми данными в текущих ADSO, но и создаются новые ADSO, то процесс оптимизации хранения должен быть в составе регулярного обслуживания SAP BW. Как регулярная уборка в квартире или доме.
По аналогии с квартирой или домом, в HANA есть свой «робот‑пылесос». Как и в случае с реальным пылесосом, он не будет эффективен, если его движению создаются помехи. Но если помех нет, то это хорошее подспорье для администратора SAP BW. Речь идет о параметрах сервера unused_retention_period и unused_retention_period_check_interval. Каждые N секунд, определяемые во втором параметре, SAP HANA проверяет, какие сегменты (колонки, партиции, таблицы) не использовались последние M секунд (определяемые 1-м параметром) и выгружает их в очередности согласно UNLOAD PRIORITY. Значение по умолчанию для 1-ого параметра — 0, что означает отключение автоматического механизма «робота‑пылесоса». Значение по умолчанию для 2-ого параметра — 7200 (2 часа). По нашему опыту, значение 1-ого параметра 86 400 (24 часа) наиболее эффективно, т.к. соответствует регулярности использования данных. Пробуя выставить параметр на 18h получили заметный рост потребления CPU (контроль выполняли по одному из SAP HANA MiniChecks) и вернулись к исходным 24h. Впрочем, оптимальная настройка параметров определяется для каждой системы в каждый момент времени индивидуально.
Настройка (при выполненном заранее партицировании) позволила снизить среднее потребление памяти сразу на 40%. И теперь мы получили новый средний уровень потребления, который не только обеспечил нам стабильность выполнения ночных процессов, но и дает больше уверенности в том, что текущее оборудование для SAP HANA будет достаточно по памяти еще несколько лет. Рост под контролем!
Компания SAP заявила о решении покинуть Россию в марте 2022 года, а в сентябре приняла решение и о завершении поддержки клиентов на территории страны. По данным исследования IBS, более 70% крупных отечественных компаний, использующих ПО этого вендора, планируют перейти на импортонезависимые аналоги. При этом 42% опрошенных отметили, что уже начали миграцию, 28% пока находятся в поиске альтернативного ПО.
При этом на отечественном рынке труда остаются тысячи консультантов и разработчиков SAP. Мы спросили у специалистов этой сферы из IBS, как они оценивают потенциал своей профессии и что думают о будущем саперов в России.
Александр Николаев, ведущий разработчик: "По словам экспертов, есть программные решения, которые пока заменить крайне сложно, и одним из таких решений можно назвать продукты SAP. Аналогом продуктов SAP в первую очередь выступают продукты от 1С. ПО данных вендоров имеет как свои преимущества, так и свои недостатки. При прочих равных основным преимуществом продуктов SAP является высокая производительность на больших объемах данных. И если для мелких и отдельных средних компаний это преимущество не будет значимым, то для крупных производств, имеющих сложную структуру и большое количество производственных процессов, а также уже работающее решение на базе продуктов SAP, выбор оптимального решения не столь очевиден.
С технической точки зрения дальнейшее использование уже внедренных продуктов SAP после ухода вендора не представляет собой неразрешимой задачи. Система предоставляет инструменты как для расширения стандартной функциональности от вендора, так и возможность написания программных решений с нуля. Уже настроенные бизнес-процессы будут продолжать работать. Все законодательные изменения, которые раньше отрабатывал вендор, переходят в область пользовательской разработки решений, либо привлеченных российских ИТ-сервисных компаний, либо внутренней ИТ-команды. Также можно отметить, что использование продуктов SAР без привлечения поддержки вендора было успешно реализовано в отдельных российских компаниях еще до объявления политики импортозамещения, что может служить показателем работоспособности такого решения.
Исходя из вышесказанного, можно сделать вывод, что универсального ответа на вопрос «оставить / заменить ПО» нет. Каждая компания, у которой есть подобный выбор, должна взвесить риски, провести технический анализ, просчитать бюджеты решений и на основании полученных данных сделать свой выбор. И вполне ожидаемо, что часть компаний сделает выбор в пользу уже внедренных продуктов SAP, что повлечет за собой потребность в разработке решений описанных выше и востребованность специалистов SAP решений, пусть и в меньшем объеме, чем ранее.
Дарья Чувашова, заместитель начальника отдела заказной ABAP-разработки: "Мы столкнулись с непростыми временами в нашей профессии после ухода SAP из России. Реакция российских компаний-заказчиков на эту новость была различной, некоторые крупные заказчики приняли решение начать ускоренное импортозамещение, другие же выбрали ожидание. Сегодня ситуация стабилизировалась и можно сделать некоторые предположения о будущем саперов в России. Во-первых, не все компании приняли решение отказываться от SAP, им по- прежнему требуются услуги разработки на SAP -платформе. Такие компании стали усиливать свои внутренние команды и приглашать новых специалистов к себе в штат. Во-вторых, компании, принявшие решение импортозамещаться, не могут сделать это в один момент, поэтому услуги по abap-разработке им также будут требоваться все время, пока не закончится миграция.
По моим предположениям, ближайшие 3-4 года (возможно, и дольше) SAP-специалисты будут востребованы. Сейчас мы наблюдаем достаточно высокий спрос на специалистов старших грейдов, а вот спрос на специалистов младших грейдов значительно снизился. Полагаю, что данная тенденция будет сохраняться ближайшие годы.
Что касается более далекого будущего, то, скорее всего, большая часть компаний будет постепенно отказываться от SAP и внедрять отечественное ПО. Могу предположить, что в более далекой перспективе некоторым ИТ-специалистам в сфере SAP придется менять стек.
Проще всего осваивать новый стек технологий «молодым» специалистам, которые только начали свое погружение и не доросли до сеньорских позиций. Для них этот процесс должен пройти менее болезненно. Что касается опытных специалистов, то, с одной стороны, им будет сложнее сменить стек, с другой стороны, наработанный опыт может значительно им помочь в переквалификации. Но, повторюсь, что спрос на опытных разработчиков в России останется и в далекой перспективе.
Я придерживаюсь позиции, что ИТ-специалисты по определению должны быть открыты новому и не бояться перемен. Технологии менялись и меняются с экстремальной скоростью, и наша профессия обязывает нас это принимать и постоянно учиться, даже если ты эксперт в своем узком направлении. И время для освоения новых компетенций однозначно есть.
Что касается компаний, оказывающих услуги заказной разработки, то им следует начать процесс диверсификации сотрудников, переобучать персонал, предлагать программы переквалификации, и стараться сделать этот процесс менее болезненным для сотрудников любого уровня".
Кирилл Путин, руководитель группы разработки: "После того как вендор покинул страну, образовалась свободная ниша на рынке поддержки существующих систем, требуются непрерывные доработки, исправление багов, оптимизация и рефакторинг. Также законодательная база все время меняется, требуя привести в соответствие ERP-систему, что ложится на плечи штатного персонала компаний. Очень часто их сил и компетенций недостаточно, чтобы решить поставленную задачу комплексно и в срок. Для этого необходимо прибегнуть к помощи консалтинга, который располагает требуемыми ресурсами. Конечно, рассчитывать на большие проекты сейчас сложно, но, обеспечивая вышеописанные потребности, можно ожидать стабильного роста количества сравнительно небольших проектов для консалтинга сроком до года с переходом в поддержку.
Что же касается меня, то я решил развиваться в сфере управления проектами, так как считаю, что именно управление проектами раскроет мои способности в полной мере. Как разработчик я уже достиг определенного уровня, и хочется попробовать себя в более ответственной роли, открыть новые горизонты и даже в каком-то смысле испытать себя. Другим специалистам по SAP я могу посоветовать всестороннее профессиональное развитие, углубление знаний, расширение компетенций, такими областями может выступить 1с, архитектура информационных систем и общие языки программирования, а также развитие в области управления проектами, как в моем случае".
Елизавета Заклюковская, разработчик: "На мой взгляд, многие компании/предприятия уже осуществляют или пока планируют замену SAP другими продуктами только в том случае, если эти продукты способны полностью заменить функционал. Но также, мне кажется, есть ряд компаний/предприятий, которым пока сложно найти другой продукт (или продукты), которые способны полностью перекрыть тот функционал, который сейчас обеспечивают системы SAP в этих компаниях.
Я думаю, что со временем спрос на SAP-разработчиков будет падать, но при этом все равно останется потребность в данных специалистах.
Например, для поддержки систем SAP или миграции на другие системы без специалистов, разбирающихся в ПО вендора, не обойтись".
В целом SAP-разработчики сходятся во мнении, что количество проектов на отечественном рынке уменьшится, но совсем обойтись без них ни у тех, кто решился на миграцию, ни у тех, кто пока остается на ПО вендора, не удастся. Это подтверждает и рекрутинг-партнер IBS, специализирующийся на SAP, Дарья Макарова. По ее словам, после ухода вендора из РФ был краткосрочный промежуток, когда консультанты ощущали нестабильность своего будущего, часть компаний ушли с рынка, и консультантов из них сократили, часть консультантов уехали из России.
«Но оставшиеся в стране специалисты быстро поняли, что все еще востребованы на рынке труда, ведь после прекращения поддержки со стороны вендора эту роль на себя взяли другие российские компании, предоставляющие аутсорсинговые услуги в этой области. Также часть компаний успели приобрести лицензии до ухода SAP и сейчас осуществляют перевнедрения на S4Hana. Опираясь на информацию о проектах и их сроках, можно спрогнозировать наличие загрузки для SAP-консультантов как минимум на ближайшие 3 года», — добавляет Дарья.
Эффекты от внедрения подхода
У консультантов теперь появилась возможность неограниченного расширения статусных схем. Можно добавлять пользовательские статусы в любые схемы, не заботясь о том, чтобы их коды совпадали. Можно размножать, объединять, удалять статусные схемы — лишь бы набор текстов и смысл каждого текста статуса оставались уникальными. Изменения в статусных схемах теперь никак не затрагивают программную часть, всё работает, как прежде.
Класс ZCL_STATUS был использован в разработках примерно 350 раз, и даже если предположить, что труд программиста + консультанта + тестировщика сокращается на 10 минут за одно использование в одной программе, то это уже полных 7 сэкономленных рабочих дней. На самом деле экономия выходит в разы, а то и в десятки раз больше. Не говоря уже про то, что работать с классом ZCL_STATUS просто комфортнее.
Возможные минусы
Были подозрения, что если вместо подхода «статусная схема+код» применять подход «язык+текст», то это приведёт к ошибкам. Но, пока вся работа ведётся на одном языке, количество ошибок минимально. Будут ли проблемы при разработках на разных языках, неизвестно. Однако как минимум мы к ним готовы, все инструменты имеются.
Остались одинаковые тексты системных статусов. Так, в нашей системе текст «ОТКР» есть для кодов I0001 и I1002. Однако в реальности таких проблем не возникало ни разу, ни в одном документе такого не встретилось.
Остались одинаковые тексты для системных и пользовательских статусов. Например, к системному «I0002 ДЕБЛ» добавился пользовательский «E0004 ДЕБЛ». Правильным решением будет изменить текст пользовательского статуса. Но на всякий случай есть методы etext_check, itext_check, которые проверяют только пользовательский и только системный статус соответственно.
Скорость работы не отличается от стандарта, так как класс, по сути, является обёрткой. Внутренности практически полностью стандартные, основаны на функциях STATUS_READ, STATUS_CHANGES_GET, STATUS_TEXT_CONVERSION.
Главный итог
Любое ПО для автоматизации обслуживания и ремонта (ТОРО) автоматизирует не сам физический ремонт, а всё, что окружает этот процесс:
Документы здесь — основа, и всем участникам этих процессов важно видеть, на каком этапе исполнения они (и связанные с ними работы) находятся. Состояние документа в данный момент как раз и показывают наши с вами статусы.
Статусы документов — это, по сути, набор флажков. В процессе работы с документом его статус меняется: от только что созданного (ОТКР НУТВ — открыт, не утверждён) к обрабатываемому (ДЕБЛ УТВ — деблокирован, утверждён) и далее к выполненному (ТЗКР ПДТВ УТВ — технически закрыт, подтверждён, утверждён).
Статусы бывают номерные и неномерные. В один момент времени в документе может стоять только один из номерных. Неномерные могут быть установлены и сняты независимо.
Статусы бывают системные и пользовательские. У статуса есть код-префикс (например, I0001 для системных, E0001 для пользовательских) и есть текст, состоящий из четырёх символов и ведущийся на разных языках (например, ОТКР, ЗАКР). Код системного статуса всегда уникален, то есть I0001 ОТКР всегда и везде имеет смысл «открыто». Коды пользовательских статусов, напротив, неуникальны. Под одним и тем же кодом E0001 могут скрываться совершенно разные по сути статусы в разных статусных схемах.
Ох уж эти двуличные статусные схемы пользовательских статусов!
Статусная схема — это такая штука, которая определяет набор пользовательских статусов, установленных в определённом виде документа (например, в заказе). У документов одного типа могут одновременно существовать несколько статусных схем. В системе можно переключить статусную схему, но тогда вчерашний заказ будет иметь схему PM1, а сегодняшний, новый, точно такой же заказ, будет создан со схемой PM2. При этом код Е0001 во вчерашнем заказе имел текст и смысл ГТВ (Готов), а в сегодняшнем имеет совершенно другой смысл — УТВ (Утверждён).
Это ловушка №1 для разработчика. С ней связана и ловушка №2, которая заключается в том, что в интерфейсе штатной функции STATUS_CHECK вообще нет статусной схемы ни в каком виде! Извини, дорогой разработчик, но, проверяя код статуса E0001 в заказе, ты должен сам заранее узнать, что именно означает этот код в данном конкретном документе — готов, утверждён или даже удалён?
При первоначальном внедрении SAP таких расхождений в статусных схемах в системе нет. Но проходят годы, схемы меняются, устаревают, размножаются и разделяются по типам, видам и датам документов, и проблемы всплывают резко и неожиданно.
Нормальные статусные схемы системных статусов, но ненормальное проставление
Технически можно проставить любой системный статус любому документу. Но, как правило, для каждого типа документа есть специфические стандартные функциональные модули, которые кроме проставления статусов совершают ещё ряд обязательных действий. Проставление системного статуса напрямую, а не через нужный функциональный модуль, с большой вероятностью приведёт к порче документа. Это ловушка №3: догадайся, что статус нельзя ставить напрямую, а потом пойди найди необходимую функцию для нужного документа.
Количество статусов, которые можно установить для документа, практически не ограничено. Но стандарт предусматривает выдачу текстовых строк со статусами: 40 символов для вывода системных и 40 — для пользовательских статусов. С учётом четырёхсимвольного текста статуса и пробела в каждую из строк влезает до восьми статусов. Остальные, увы, за бортом. И да, приоритет (порядок) вывода статусов в строку — это тоже отдельная и весьма неочевидная настройка.
Кроме этих весёлых ловушек, есть ещё и проблема с большим количеством строк кода, который требуется для каждой отдельной проверки
Простейший пример проверки статуса занимает минимум 9 строк кода:
CALL FUNCTION ‘STATUS_CHECK’ EXPORTING objnr = caufvd-objnr "номер объекта документа status = stk_cugt "код статуса EXCEPTIONS object_not_found = 01 status_not_active = 02. IF sy-subrc = 0. "Результат проверки "Требуемые действия ENDIF.
Более сложные примеры (проверка неактивного статуса, того, что статус установлен впервые или только изменённых статусов) требуют гораздо больше строк кода. А значит, вероятность ошибки тоже возрастает.
Конечно же, многие разработчики пишут «обёртки» для стандарта, чтобы облегчить свою жизнь. И именно огромное количество таких обёрток, ни одна из которых не была достаточно универсальной, побудила нас написать средство для проверки статусов. Резюмируем предпосылки разработки решения.
Вот что мы решили сделать
Во-первых, договорились, что мы перестаём использовать коды статусов (Е0001/I0001) и переходим с пары «статусная схема + код статуса» на пару «язык + текст статуса». Уникальность текста статуса в пределах статусной схемы была возложена на консультанта (ага, это была ловушка №7: для разных кодов статусов Е0001, Е0002 в пределах одной статусной схемы может быть одинаковый текст на одном языке, причём вообще неочевидном; к примеру, пустой текст у всех статусов — на зимбабвийском).
Во-вторых, определили набор методов, который будет необходим и достаточен для полноценной проверки статусов.
В-третьих, написали класc ZCL_STATUS, который реализует внутри себя всю необходимую логику. Причём работа с данным классом реализована таким образом, что у разработчика отрезается возможность случайно сделать что-то не так.
Вот как это выглядит с точки зрения разработчика
Для начала в среде разработки Eclipse мы пытаемся сделать простую проверку на статус «ОТКР» (открыто).
2. Выбираем RU, вводим параметр (он тут один, ошибиться невозможно — это номер объекта) и переходим к методам интерфейса zif_status_updkz. Тут у нас есть выбор, какие именно статусы объекта нас интересуют:
Каждый из этих методов возвращает ссылку на следующий интерфейс: zif_status. Параметров тут нет (за ненадобностью).
3. Выбираем актуальные статусы, метод actual. Теперь у нас появляется список основных методов по проверке. Он большой, в скриншот целиком не помещается. Основные методы:
У каждого из этих методов максимум один входной и один выходной параметр, так что ошибиться при вводе невозможно.
Итог: запись выражения в одну строку, большую часть которой получаем автозаполнением.
Сравните это с традиционным подходом:
CALL FUNCTION ‘STATUS_CHECK’ EXPORTING objnr = iv_order_objnr status = ‘I0001’ "Код статуса ОТКР EXCEPTIONS object_not_found = 1 status_not_active = 2 OTHERS = 3. IF sy-subrc = 0. MESSAGE ‘Открыто’ TYPE ‘S’. ENDIF.
Даже в элементарнейшей ситуации, когда проверяем системный статус (то есть, никаких статусных схем!), видно значительное упрощение кода. А уж в случаях, когда статусные схемы разъехались, и нужно проверять код пользовательского статуса, выигрыш просто разгромный.
Более того, греет душу сам факт того, что вместо архаичного способа записи можно использовать подход, напоминающий современные языки программирования.
А что с ловушками?
Ловушки 1 и 2. Статусные схемы теперь не интересуют разработчика от слова «совсем». Консультант отвечает за то, что пользовательский статус «ГТВ» — это всегда «Готово». И какая тут статусная схема, какой код статуса — E0001 или E1510, совершенно неважно.
Ловушка 3, где статус нельзя ставить напрямую остаётся, так как класс ZCL_STATUS не имеет функциональности по проставлению статусов. Связано это с тем, что изменение статуса используется в десятки раз реже, чем проверка.
Ловушки 4 и 5. Проверка по текстовой строке с несколькими статусами заменена на индивидуальную проверку. Поэтому случайно перепутать «ГТВ» и «НГТВ» невозможно. Также невозможно потерять статус из-за того, что он не влез в 40 символов.
Ловушка 6. Другой язык. У нас все тексты статусов ведутся и используются на русском языке. Однако если какая-то разработка принципиально должна использовать английские тексты, никто не мешает это делать. Для переводов есть метод TRANSLATE, возвращающий интерфейс с соответствующим набором методов.
Ловушка 7. Одинаковые (пустые) тексты статусов в пределах статусной схемы для определённого языка. Не используйте этот язык. Или попросите консультантов настроить статусную схему должным образом.
