В кінці 2027 року підтримка пакету бізнес-додатків SAP Business Suite 7 (до складу якого входить флагманське рішення SAP ERP 6.0) закінчиться. Деякі компанії за великі гроші зможуть продовжити її до кінця 2030 року, але після цього залишиться лише один варіант – SAP S/4HANA. Підтримку цієї системи продовжили як мінімум до кінця 2040 року.

Навіщо переходити на SAP S / 4HANA, якщо SAP ERP 6.0 буде працювати ще 7 років

Здається, що зараз хвилюватися нема про що: ERP-система, яку ви запустили на початку 2000-х років, відмінно працює, в ній все налаштоване та все знайоме. Але якщо ви роками працюєте в ERP та не оновлюєте її, така «заморожена» система з кожним роком все більше розростається та все сильніше застаріває. А ось вартість підтримки при цьому постійно зростає. Коли ви нарешті вирішите перейти на S/4HANA, неминуче зіткнетеся з безліччю неприємних нюансів: десь версія не відповідає, десь не виходить запустити перевірку, десь взагалі не працюють модулі. Все це сильно ускладнить перехід або навіть зробить його неможливим. Часто застарілі системи не можна перенести в рамках конверсії, доводиться робити нове впровадження.

Система, яка застаріла вже сьогодні, через 7 років застаріє остаточно, а відмовитися від неї все одно доведеться. Краще витратити цей час не на дорогу підтримку старої ERP, а на знайомство з новими можливостями S/4HANA, які принесуть користь вашому бізнесу. S/4HANA – це висока продуктивність, аналітика в режимі реального часу, безшовна інтеграція з платформами Internet of Things та Big Data, можливість використання хмарних рішень та простий зручний інтерфейс для користувачів.

Коли почати міграцію на S/4HANA, щоб встигнути вчасно

2027 рік не так далеко, як хотілося б. Якщо почати перехід на SAP S/4HANA занадто пізно, то можна не встигнути завершити міграцію вчасно. Запустивши процес за пару років до закінчення підтримки, ви можете витратити рік на підготовку, а потім ще рік на оновлення модулів та елементів системи. Часу на те, щоб спокійно перейти на SAP S/4HANA, не залишиться.

Адже робота в компанії не зупиняється: вам потрібно вести бухгалтерський та податковий облік, закуповувати матеріали та обладнання, наймати нових співробітників, укладати договори з партнерами. Ваша ERP-система щодня поповнюється новими даними. За минулі роки їх накопичилося величезна кількість, а за наступні 7-10 років стане в рази більше. Міграція накопичених історичних даних в нову версію SAP S4/HANA – одне з ключових завдань модернізації системи. Чим менше об’єм цих даних, тим дешевше та швидше пройде перехід на S/4HANA. Додайте сюди вартість модернізації обладнання або архівування існуючих, постійно зростаючих обсягів даних для того, щоб зберігати продуктивність вашої ERP-системи на прийнятному рівні.

Тому вже зараз варто почати з технічної оцінки переходу на S/4HANA. Ви дізнаєтеся, скільки часу та ресурсів вам буде потрібно для переходу, зможете точно спланувати роботу з міграції, отримати повну розкладку по існуючим та потенційним ризикам, а також інноваційним можливостям S/4HANA. А далі можна буде вирішувати: впроваджувати нову ERP зараз, через рік, через 5 років.

Оцінка залежить від розміру системи та займає від 2 тижнів до 2-3 місяців. На саму міграцію потрібно від 3-4 місяців для малого та середнього бізнесу до 7 місяців та більше для великого. Технічна оцінка не тільки триває, а й коштує в рази менше, ніж сама міграція. При цьому вона може виявити такі нюанси, через які перехід на S/4HANA може зрушити на кілька місяців. Адже чим раніше бізнес отримає можливість користуватися перевагами інноваційної платформи, тим швидше вона окупиться та почне приносити вигоду.

Як перейти з Business Suite 7 на S/4HANA: 4 сценарії

Універсального плану міграції не існує: кожній компанії підходить свій сценарій. Вибір залежить від розміру та віку підприємства, кількості користувачів, наявності інших систем, які керують бізнес-процесами. Після технічної, функціональної та стратегічної оцінки ІТ-структури компанії консультант разом з SAP-фахівцями визначає, як міграція на SAP S/4HANA може поліпшити бізнес та допомогти йому в цифровий трансформації.

Після проведення оцінки ви отримаєте список завдань, які потрібно буде виконати, та рекомендацію про те, який сценарій краще використовувати. Для переходу на «наземну версію» S/4HANA On-premise їх чотири:

1. Нове впровадження (Greenfield Implementation).
2. Перетворення ERP в S/4HANA (System Conversion/Brownfield).
3. Гібридна міграція (Hybrid/Selective Data Transition).
4. Трансформація ландшафту (Landscape Transformation).

1: Нове впровадження

Нове впровадження (Greenfield) підходить не тільки в тих випадках, коли раніше компанія не користувалася ERP взагалі або працювала з іншим вендором, наприклад, 1С. Буває, що власник бізнесу колись вирішив вкласти гроші в створення ERP-системи, впровадив багато модулів SAP, провів багато інтеграцій та налаштувань, але в підсумку використовував лише малу їх частину. Вийшла «роздута» система, в якій є багато всього, що нікому не потрібно. Якщо провести міграцію, вийде ще одна система з дорогим непотрібним функціоналом, який вимагатиме постійних вкладень. Простіше зробити нове впровадження тільки з тими бізнес-процесами, на яких сфокусований бізнес.

Аналіз великої кількості існуючих систем показує: до 60% розробленого при первинному впровадженні «під замовлення» функціоналу (розширень ERP-системи) ніколи не використовується. Чому це відбувається – предмет окремої розмови.

2: Перетворення ERP в S/4HANA

Перетворення ERP в S/4HANA (System Conversion/Brownfield) рекомендується, коли бізнес-процеси зрозумілі та описані. Якщо за роки роботи з SAP ERP 6.0 ви постійно підтримували та оновлювали систему, відключали невикористовувані модулі та навчали своїх співробітників роботі з новим функціоналом, то це допоможе провести міграцію швидко та комфортно. Активація нових можливостей S/4HANA виконується після завершення проекту – зі швидкістю, зручною конкретному підприємству.

3: Гібридна міграція

Гібридна міграція (Hybrid / Selective Data Transition) проводиться тоді, коли необхідно не тільки конвертувати те, що зараз є в системі, а й кастомізувати функціонал, по-новому налаштувати його в S/4HANA. Наприклад, компанія давно використовує ERP (або кілька таких систем), і в них є багато вдалих рішень, які активно використовуються та відмовлятися від яких не доцільно. В рамках проекту гібридної міграції створюється нова S/4HANA-система (як при New Implementation), але в неї переносяться вдалі рішення та необхідні дані (як при System Conversion). Є багато вдалих прикладів реалізації описаного підходу.

4: Трансформація ландшафту

Трансформація ландшафту (Landscape Transformation) потрібна тоді, коли в компанії використовуються кілька SAP ERP систем та/або неSAP-додатки, функціональність яких доцільно поетапно перенести в нову, єдину систему S/4HANA: аналітичні платформи, програми для управління персоналом, додатки для організації закупівлі тощо. В такому випадку потрібно налагодити перехід зі старого ландшафту на новий: провести міграцію даних з різних джерел за допомогою спеціальних інструментів SAP Landscape Transformation. Дані, які зберігаються в успадкованих додатках, будуть зведені в ядро S/4HANA. Це стане першим швидким кроком до єдиної системи, після чого залишиться спланувати поетапне перенесення в єдину систему S/4HANA застарілих бізнес-додатків з виведенням їх з експлуатації.

Перейти на S/4HANA якомога раніше варто ще й для того, щоб в майбутньому у вас не виникало таких проблем з оновленнями та міграцією даних.

Багато інноваційних можливостей для цифрової трансформації бізнесу вже зараз доступні тільки в хмарнії версії S/4HANA. Щоправда, для такого проекту доступний тільки один сценарій – нове впровадження.

Про SAP-практику IBA Group

Більше 3500 кінцевих користувачів вже працюють в системах SAP S/4HANA, реалізованих фахівцями компанії IBA Group по всьому світу.

IBA Group володіє статусами SAP S/4HANA, HANA Recognized Expertise та є золотим сервісним партнером компанії SAP.

Бізнес-завдання

Провести міграцію існуючої системи управління закупівлями для забезпечення виробничих процесів виробника автомобільної техніки на платформу Java з подальшою підтримкою і розвитком нової системи.

Рішення

Фахівці IBA Group за підтримки замовника здійснили міграцію системи управління закупівлями автомобільного концерну з платформи SmallTalk на платформу Java. При цьому була відтворена за кодом проектна документація, що описує функціональну поведінку системи. У період з 2003 по 2005 рік команда на стороні IBA Group досягала 100 чоловік.

У період з 2005 року команда IBA Group продовжила супровід і розвиток нової системи. В даний період за запитом замовника в систему вносилися зміни, яких вимагали постійно мінливі умови ведення бізнесу: відкриття нових заводів, створення виробничих майданчиків в нових регіонах, зміни в економіці і законодавчій базі, розвиток коопераційних відносин з іншими виробниками автомобільної техніки, зміна внутрішніх процесів замовника. Також були реалізовані технічні зміни, пов’язані з еволюцією платформи Java.

Результат

У період з 2003 по 2005 рік команда IBA Group провела міграцію існуючої системи на платформу Java з повною заміною системи в промисловій експлуатації на нову систему.

У період з 2005 року командою IBA Group реалізовано понад 900 запитів на зміну системи в зв’язку з новими вимогами бізнесу.

Система впроваджена на всіх заводах замовника по всьому світу. Загальна кількість користувачів системи – близько 50 000 фахівців із закупівлі.

Цілі і завдання проекту

Замовник хоче мінімізувати витрати на міграцію своїх розподілених систем на S/4HANA. Для цього до самої міграції проводиться технічна оцінка. Вона дозволяє оцінити обсяг робіт, визначити необхідні поліпшення та скласти бюджет проекту.

Опис проекту

Спочатку IT-підрозділ замовника планував провести технічну оцінку самостійно. Після запуску відповідних програм адміністратори SAP отримали перелік з 17 000 помилок. Для розробки рішення своїми силами їм не вистачало компетенцій, тому було вирішено звернутися до підрядчика. Серед головних вимог було знання німецької мови та можливість постійно працювати в Німеччині. Тому в проекті беруть участь фахівці з IBA Group та колеги в Німеччині на суб-підряді.

План міграції на S/4HANA включає в себе конверсію дев’яти розподілених SAP-систем в період з 2020 по 2025 рік. На проведення технічної оцінки було виділено 40 людино-днів. Фахівці з IBA Group на прикладі 2 систем оцінили майбутню міграцію та виробили рекомендації для всіх учасників проекту.

Результати проекту

Замовник отримав документацію з вмістом робіт з міграції, переліком поліпшень та рекомендацій, деякою оцінкою бюджету та термінів проекту.

До 2025 року SAP відмовиться від підтримки своєї ERP, тому його користувачам доведеться перейти на платформу S/4HANA. та хоча кожен клієнт SAP знає про майбутній перехід, багато хто до цих пір навіть не уявляють з чого почати цей перехід та як правильно до нього підготуватися.

Про те, з чого починати міграцію, щоб завершити її вчасно, не вийти за рамки узгодженого бюджету, а також про ціну на послуги технічної оцінки до міграції та терміни її надання розповідає Ігор Бордаков, керівник підрозділу SAP Global delivery center компанії IBA Group.

Що таке технічна оцінка для міграції? У чому полягає ця послуга?

Якщо спростити, то фахівці IBA Group допомагають замовникам розібратися в тому, як саме потрібно переходити на нову платформу, з чого починати та що саме робити, щоб уникнути помилок та збитків, які за ними слідують.

На жаль, не всі компанії до кінця уявляють масштаб необхідних робіт, глибину потенційних проблем та ціну можливих помилок. Роль IBA Group в цій ситуації – повністю вивчити SAP-екосистему компанії, знайти потенційно небезпечні місця, де можуть виникнути проблеми, а потім розробити покроковий план дій, робота по якому допоможе безболісно завершити міграцію.

У багатьох бізнесів є власні IT-відділи, які добре знають архітектуру своїх систем, їх сильні та слабкі сторони. Адже вони можуть впоратися з міграцією. Навіщо запрошувати незалежних експертів?

У багатьох компаній відмінні IT-відділи, але вони не завжди можуть адекватно оцінити масштаб потенційних проблем, які можуть виникнути при міграції. Справа в тому, що експлуатація системи та міграція – це не одне та те ж. Виконуючи проекти з міграції, ми помітили, що компанії використовують далеко не весь потенціал систем: частина встановленого ПЗ простоює роками та навряд чи буде потрібна в майбутньому. Тому перед початком проекту з міграції ми глибоко аналізуємо, що саме та як переносити.

Кому потрібно проводити такий аналіз?

Моя думка, технічну оцінку потрібно проводити всім, хто збирається переходити на S/4HANA. Результати оцінки допоможуть знизити терміни міграції та бюджет, якщо йдеться про варіант конвертації або гібридної міграції вашої SAP ERP на S/4HANA.

Скільки часу йде на повноцінну підготовку до міграції?

Для малого та середнього бізнесу (до 200 користувачів) приблизно 3-4 місяці, для великого – від 7 місяців (в залежності від розміру системи).

Від чого залежить вартість послуги технічної оцінки?

У неї фіксована ціна.

Чому в IBA впевнені, що впораються з подібним завданням?

Ми накопичили 5 000 людино-років сумарного досвіду роботи з рішеннями SAP, а наше партнерство з компанією почалося ще 1996 році. Виходячи з цього, ми здатні прогнозувати виникнення проблем, знаємо ефективні шляхи їх вирішення.

Короткий опис проекту:

Використовувані програми:

• Діловодство
• Архівна справа
• Нормативні акти
• Завдання

Було проведено обстеження підприємства замовника. Спільно із замовником здійснена оптимізація бізнес-процесів і вироблені вимоги щодо адаптації ППП «Канцлер» до їх особливостей.

На основі вироблених вимог була розроблена концепція і реалізована СЕД на базі ППП «Канцлер», що відповідає специфіці ведення документообігу на підприємстві.

Ряд компонентів системи модифікований з урахуванням особливостей процесів роботи з документами замовника.

Отримати консультацію експерта

Мета проекту

Модернізація централізованої системи управління, створеної на базі IBM Maximo 5.2, шляхом її міграції на платформу IBM Maximo 7.5. На момент початку реалізації проекту існуюча платформа IBM Maximo 5.2 перестала підтримуватися виробником і задовольняти зростаючі вимоги замовника, а також відповідати потребам в частині масштабованості, продуктивності і безпеки. Основні складності, які виникли перед проектною командою lifecell, були наступні:

• Система управління містить близько 100 розроблених додатків зі складною бізнес-логікою. Виробником системи керування не підтримується міграція таких додатків
• Додатки, що підлягають міграції, погано документовані або не задокументовані взагалі. При цьому розробники, які брали участь в їх проектуванні та реалізації багатьох додатків системи, на той момент вже не працювали на проекті
• Окремі частини бізнес-логіки реалізовані у вигляді PL / SQL-процедур
• Система управління на базі IBM Maximo інтегрована з великою кількістю зовнішніх систем, включаючи SAP (обмін транзакціями по руху матеріалів), Oracle Identity Management (IdM) (інформація про користувачів, організаційна структура), NetAct Planner (інформація про сайти і радиолінк), HP TeMIP (управління Trouble Tickets і інформація про аварії на мережі), OSS-системи Nokia, Huawei і Ericsson (автоматичне халтірування сайтів)
• За первинною оцінкою процес міграції повинен бути здійснений протягом одного року. В рамках цього періоду необхідно було виконати роботи по створенню додатків і розвитку існуючих. Всі додатки повинні бути доступні протягом усього часу міграції.

Етапи проекту і виконані роботи

Проектні роботи почалися з етапу підготовки, який включав в себе візит до замовника для аналізу вимог і оцінки обсягів робіт. У грудні 2014 року IBA Group взяла участь у відповідному тендері і виграла його.

Проект з міграції офіційно стартував у березні 2015 року. Проектна команда складалася з шести розробників, включаючи двох сертифікованих фахівців з IBM Maximo, фахівця з Oracle, двох бізнес-аналітиків, QA-фахівця і технічного письменника.

Весь проект був розділений на чотири етапи, були сформовані групи додатків, міграція яких повинна здійснюватися на кожному етапі. Всі групи додатків були переведені на нову платформу цілком, перемикання з IBM Maximo 5 на IBM Maximo 7 відбувалося протягом однієї ночі. Після міграції першої групи додатків і до міграції останньої були налаштовані процедури синхронізації даних для забезпечення їх цілісності між системами IBM Maximo 5 і IBM Maximo 7.

Для кожного додатку, який був перекладений на платформу IBM Maximo 7, були виконані наступні роботи:

• Проведено реверс-інжиніринг для підготовки технічного завдання з перенесення програми на нову платформу. Технічне завдання включало опис архітектури додатку, об’єктів бази даних, бізнес-логіки, призначеного для користувача інтерфейсу і всіх використовуваних довідкових даних
• Підготовлено план міграції і синхронізації даних, який описував всі джерела даних, що підлягають міграції та синхронізації між IBM Maximo 5 і IBM Maximo 7, включаючи необхідні перетворення даних і схем
• Інтерфейс додатків IBM Maximo 5 на основі JSP-сторінок був перетворений в відповідні XML-подання додатків для IBM Maximo 7, при цьому була забезпечена ідентичність структури і розмітки сторінок
• Вся бізнес-логіка, включаючи техпроцеси і java-кастомізацію, була адаптована для платформи IBM Maximo 7
• Інститути, які PL / SQL-процедури були здебільшого перенесені у вигляді кронов IBM Maximo
• Дані були перенесені і перетворені відповідно до плану міграції
• Звіти були перетворені відповідно до зміненими структурами даних.

В ході проекту було розроблено інструментарій автоматизації, який став частиною середовища розробки для IBM Maximo, створеної і використовуваної в IBA:

• Автоматизоване управління конфігурацією IBM Maximo для створення та оновлення об’єктів (MBO, домени, групи тощо) на основі даних сховища
• Аналіз програм IBM Maximo 5 для виявлення і опису всіх джерел даних, які ними використовуються
• Автоматичне перетворення візуальних форм додатків IBM Maximo 5 в XML-вистави для IBM Maximo 7 зі збереженням вихідної розмітки.

Використовуючи створене середовище розробки, проектна команда впоралася з реалізацією 2-го, 3-го і 4-го блоків додатків з 80-и процентним скороченням трудовитрат у порівнянні з 1-м блоком.

Результати проекту

Проектні роботи були успішно завершені в грудні 2016 року зі високою оцінкою замовником якості виконаних робіт. Покращена система управління стала більш стабільною в роботі і відповідає суворим вимогам з безпеки. В даний момент, використовуючи доступний функціонал нової платформи, особливо REST API, система глибоко інтегрується в корпоративну інформаційну систему замовника відповідно до зростаючих вимог бізнес-підрозділів.