ERP modernizavimas ir pasitraukimas iš SAP ECC: inžinerinis darbas aplink migraciją, kurio niekas neįvertino

Kiekvienoje ERP migracijoje slypi du projektai. Vienas yra plane (nauja sistema, procesų projektavimas, sistemų integratorius), o kitas išnyra ketvirtą mėnesį, kai kas nors suskaičiuoja sąsajas.

Tas antrasis projektas yra mūsų. Aštuoniasdešimt individualių integracijų, ataskaitos, nuo kurių priklauso finansų skyrius, bet kurių niekas neprižiūri, sandėlio terminalai, besikreipiantys į duomenų bazės rodinį, klientų portalas, skaitantis tiesiai iš senųjų lentelių, dvidešimties metų duomenys, kurie į naują sistemą turi patekti tokio pavidalo, kokį ji priims. Pradinėje apimtyje to retai būna, o būtent tai dažnai ir lemia datą.

Kodėl tai darbotvarkėje būtent dabar

Įprastinė SAP ECC 6.0 priežiūra baigiasi 2027 m. gruodžio 31 d. Išplėstinė priežiūra leidžia sistemą naudoti iki 2030 m. pabaigos, tačiau už papildomą kainą ir mažesne apimtimi. Didelė dalis įdiegtų sistemų dar net nepradėjo migracijos, migracijos paprastai trunka nuo aštuoniolikos iki trisdešimt šešių mėnesių, o partnerių ir debesijos tiekėjų pajėgumai joms atlikti rezervuojami jau dabar.

Toks pat spaudimas yra ir už SAP ribų. Oracle EBS klientai turi savo palaikymo horizontą, Dynamics AX ir NAV diegimai stumiami link Business Central ir Dynamics 365, o ilga įmonių eilė naudoja ERP, kurį prieš dešimtmetį smarkiai pritaikė seniai išėję žmonės.

Kad ir kokia būtų paskirties sistema, problema ta pati: ERP nėra sala, o tai, kas prie jo prijungta, paprastai neaprašyta.

Ką darome

Sąsajų paieška ir inventorizacija

Kad būtų galima ką nors planuoti, kas nors turi nustatyti, kas iš tikrųjų bendrauja su ERP. Tai darome empiriškai (skaitydami duomenų bazės žurnalus, tinklo srautą, suplanuotas užduotis, integracinės tarpinės programinės įrangos konfigūraciją ir pirminį kodą), o ne išsiuntinėdami klausimyną ir tikėdamiesi geriausio.

Rezultatas yra visų sąsajų sąrašas su kryptimi, protokolu, dažnumu, duomenų apimtimi, verslo savininku, jei jį pavyksta rasti, ir įvertinimu, ar sąsają reikia perkurti, galima išjungti ar galima pritaikyti. Klientai paprastai randa nuo dviejų iki penkių kartų daugiau sąsajų, nei tikėjosi, o nemaža jų dalis apskritai niekam nebetarnauja.

Integracinio sluoksnio perkūrimas

Perkuriame sąsajas, kurios turi išlikti, ir mieliau jas kuriame per abstrakcijos sluoksnį, o ne nukreipiame tiesiai į naująją sistemą. Integracinis sluoksnis tarp jūsų palydovinių programų ir ERP reiškia, kad kita migracija (o ji bus) nekartos šio darbo. Be to, jis leidžia perkelti programas bangomis, o ne per vieną perėjimo savaitgalį.

Šis darbas apima IDoc ir BAPI sąsajas, OData paslaugas, ankstesnės kartos SOAP galinius taškus, plokščių failų ir SFTP mainus, kuriais vis dar veikia pusė Europos B2B, pranešimų eiles ir šiuolaikines REST API naujojoje pusėje.

Duomenų migracijos inžinerija

Išgavimas, valymas, transformavimas, įkėlimas ir (dažniausiai neįvertinama dalis) sutikrinimas. Migraciją kuriame kaip pakartojamą kodą, o ne vienkartinį scenarijų, kad ją būtų galima paleisti dešimtis kartų su vis švaresniais duomenimis ir kaskart automatiškai palyginti rezultatus.

Būtent sutikrinimas lemia pasitikėjimą. Finansų skyrius nepatvirtins migracijos vien todėl, kad įkėlimas pavyko; jis patvirtins, kai sutaps likučiai, sutaps kiekiai, o likę skirtumai bus paaiškinti ir raštu priimti.

Individualios programos, kurios gyvuos ilgiau nei ERP

Dauguma įmonių turi aplink senąjį ERP sukurtų programų, kurios daro tai, ko ERP negalėjo: konfigūratorius, kainodaros įrankis, gamybos cecho terminalas, klientų portalas, planavimo skaičiuoklė, be kurios nieko neveikia. Kai kurias reikėtų atsisakyti ir pereiti prie naujosios sistemos standartinių funkcijų. Kai kurios yra tikras konkurencinis pranašumas, ir jas reikėtų tinkamai perkurti kaip savarankiškas programas, nebeprikaustytas prie duomenų bazės schemos, kuri netrukus pasikeis.

Padedame atskirti vienas nuo kitų, o tada sukuriame tas, kurias verta išlaikyti.

Ataskaitos ir šešėlinis duomenų ūkis

Aplink kiekvieną ilgai veikiantį ERP susidaro ataskaitų, duomenų išrašų ir skaičiuoklių sluoksnis. Perėjimo metu jie sugenda su trenksmu, o plane jų beveik niekada nėra. Juos inventorizuojame, nustatome, kuriais verslas iš tikrųjų remiasi, ir perkuriame juos pagal naująjį duomenų modelį arba per ataskaitų sluoksnį, kuris juos nuo jo atskiria.

Senosios sistemos išjungimas ir duomenų saugojimas

Senojoje sistemoje yra įrašų, kuriuos pagal įstatymą privalote saugoti daug metų po jos išjungimo. Laikyti ECC veikiantį tik skaitymo režimu dešimtmetį yra brangus būdas įvykdyti saugojimo taisyklę. Sukuriame duomenų perkėlimą į prieinamą archyvą su paieška ir eksportu, kurių auditoriai ir mokesčių institucijos iš tikrųjų prašo, kad senąją sistemą būtų galima išjungti.

Ko nedarome

Nesame SAP funkcinių konsultacijų įmonė. Nekonfigūruojame FI/CO, neprojektuojame jūsų procesų šablonų ir nesame partneris, vykdantis S/4HANA programą. Tai specialistų vaidmenys, ir jiems turėtumėte pasitelkti specialistą.

Esame inžinierių komanda, kuri dirba greta to partnerio su viskuo, ką ERP paliečia, bet ko ERP programa neapima. Praktiškai mus samdo arba tiesiogiai klientas, kad apsaugotų savo programos pusę, arba programą vykdantis sistemų integratorius kaip subrangovą.

Jei ieškote, kas prisiimtų visą S/4HANA konversiją, pasakysime, kad tai ne mes, ir mieliau tai padarysime per pirmąjį pokalbį nei per trečiąjį.

Kur dirbame

Greta S/4HANA programos: integracijų perkūrimas, duomenų migracijos inžinerija, palydovinių programų darbai ir senojo ūkio išjungimas.

Visiškas pasitraukimas iš SAP: į Odoo, Dynamics 365 Business Central, ERPNext, Netsuite ar konkrečiai šakai skirtą sistemą, dažniausiai vidutinėse įmonėse, kurioms S/4HANA yra neproporcingai didelis. Čia integracijų ir duomenų darbai sudaro didžiąją projekto dalį.

Oracle, Dynamics AX/NAV ir Infor ūkiai, kuriuos slegia tas pats gyvavimo ciklas, tik jiems skiriama mažiau dėmesio.

Įmonės, kurios iš viso nemigruoja, nusprendusios kol kas likti ten, kur yra, ir kurioms reikia modernizuoti aplinkines sistemas, padaryti sąsajas prižiūrimas ir sumažinti riziką, kol jos laukia.

Kaip vyksta darbas

Tyrimas: nuo trijų iki šešių savaičių. Sąsajų inventorizacija, duomenų kokybės įvertinimas, palydovinių programų peržiūra ir rašytinė ataskaita apie tai, kaip iš tikrųjų atrodo aplinkinis ūkis. Šį etapą sąmoningai siūlome ir kaip atskirą darbą: keli klientai juo pasinaudojo, kad iš naujo derėtųsi dėl sistemų integratoriaus pasiūlymo apimties ir kainos, ir tai su kaupu atsipirko.

Kūrimas, lygiagrečiai su pagrindine programa: integracinis sluoksnis, migracijos konvejeris, programų perkūrimas, pagal jūsų grafiką ir jūsų perėjimo datą.

Pagalba perėjimo metu, įskaitant repeticijas, sutikrinimo paleidimus ir sustiprintos priežiūros laikotarpį, kai pagaliau pradedamos naudoti ir tos sąsajos, kurios testuojant taip ir nebuvo iki galo išbandytos.

Išjungimas, kai naujoji sistema veikia stabiliai, o archyvas patvirtintas.

Technologijos

Java, .NET, Python, Node.js ir PHP programų pusėje; SAP sąsajų technologijos, įskaitant IDoc, BAPI, RFC ir OData; tarpinė programinė įranga, įskaitant MuleSoft, Apache Camel, Kafka ir Azure Integration Services; SQL Server, Oracle, DB2, HANA ir PostgreSQL; AWS ir Azure. Jei esamas ūkis veikia su kuo nors senesniu (Delphi, VB6, PowerBuilder, COBOL greta ERP), mums tai pažįstama teritorija, o ne staigmena.

Dažnai užduodami klausimai

Kada tiksliai baigiasi SAP ECC palaikymas?

Įprastinė SAP ECC 6.0 priežiūra baigiasi 2027 m. gruodžio 31 d. Išplėstinė priežiūra galima iki 2030 m. pabaigos už papildomą mokestį ir mažesne apimtimi. Konkrečias sąlygas savo patobulinimų paketui ir sutarčiai pasitikslinkite tiesiogiai su SAP, nes jos skiriasi.

Jau pasirinkome sistemų integratorių. Kur čia jūs?

Greta jo. Integratorius atsakingas už ERP konversiją; mes atsakome už ūkį aplink jį: sąsajas, duomenų inžineriją, palydovines programas, ataskaitas ir išjungimą. Toks pasidalijimas įprastas, jis leidžia integratoriui susitelkti į sistemą, kurios specialistas jis yra, ir reiškia, kad kas nors atsako už tas dalis, kurios paprastai iškrenta tarp sutarčių.

Ar realu visiškai atsisakyti SAP?

Kai kurioms įmonėms taip. Tai priklauso nuo to, kiek jūsų veiklos yra standartinė, kiek jos slypi pritaikymuose ir ar mažesnė platforma gali atlaikyti jūsų apimtis ir reguliavimo reikalavimus. Vidutinio dydžio gamintojams ir platintojams tai tikra galimybė, o sudėtingoms tarptautinėms grupėms prasta. Tyrimo etapas jums suteikia įrodymų sprendimui, o ne argumentų ginčui.

Kiek trunka sąsajų inventorizacija?

Daugumai vidutinio dydžio ūkių nuo trijų iki šešių savaičių. Trukmę daugiausia lemia prieiga: kaip greitai galime pasiekti žurnalus, pirminį kodą, tarpinės programinės įrangos konfigūraciją ir žmones, kurie prisimena, kodėl kas nors egzistuoja.

Ar galite išlaikyti senąją sistemą prieinamą auditui, kai ją išjungsime?

Taip. Sukuriame duomenų perkėlimą į archyvą, kurį galima užklausti, su tokiu saugojimo laikotarpiu, paieška ir eksportu, kokių reikalauja jūsų auditoriai ir mokesčių institucijos. Paprastai tai gerokai pigiau nei dešimtmetį laikyti licencijuotą ERP veikiantį tik skaitymo režimu.

O jei nuspręsime kol kas nemigruoti?

Tai pagrįstas sprendimas, ypač kai išplėstinė priežiūra galima iki 2030 m. Tuomet darbas yra mažinti riziką laukimo metu: dokumentuoti ir stabilizuoti sąsajas, išjungti tai, kas niekam nenaudojama, ir modernizuoti programas aplink ERP, kad kai pagaliau persikelsite, aplinkinis ūkis nebūtų kliūtis.

Pradėkite

Parašykite mums, ką naudojate, kuriame sprendimo etape esate ir ar integratorius jau paskirtas. Pasakysime, kiek jums greičiausiai kainuos aplinkinis ūkis ir nuo ko pradėtume.

Susisiekite su mumis ir aptarkime sąsajų ir duomenų tyrimo apimtį.

Susijusios paslaugos

• Senųjų sistemų kodo priežiūra: sistemoms, kurios lieka ten, kur yra
• E. sąskaitų faktūrų integracija: prievolė, kuri dažnai užklumpa vidury migracijos
• Darbuotojų nuoma ir užsakomosios paslaugos: inžinieriai, įsiliejantys į komandą visam programos laikotarpiui