”Saumaton ERP-integraatio” on vakiolupaus, jota käytännössä seuraa kolmen kuukauden projekti. Julkaisemme API-oppaamme, jotta IT-osastonne voi tarkistaa ennen sopimuksen allekirjoittamista, mitä tietoja todellisuudessa haetaan. Tässä on se, mitä teidän tulisi tietää ennen integraatioprojektia.
Mitä ERP-järjestelmänne todella on toimitettava
Jotta DPP voidaan luoda, tarvitsemme kustakin tuotteesta:
- Perustiedot - tuotenumero, nimike, variantit, painot, mitat, kuvat
- Osaluettelotiedot - komponentit määrineen ja kierrätysosuuksineen
- Alkuperätiedot - tuotantopaikka, eränumero, valmistuspäivämäärä
- Ympäristötiedot - CO2eq yksikköä kohti, vedenkulutus, energiankulutus
- Toimittajatiedot - kuka toimittaa minkäkin komponentin (due diligence -tarkastusta varten)
Teoriassa nämä tiedot ovat kaikki saatavilla ERP-järjestelmässänne. Käytännössä ne ovat hajallaan 4-7 moduulissa: materiaalinhallinta (MM), tuotanto (PP), laatu (QM), toimittajat (LFA1), joskus erillinen EHS-moduuli ympäristötietoja varten, joskus PLM-järjestelmä reseptejä varten.
Integraatiokysymys ei ole: ”Toimittaako ERP-järjestelmänne tietoja DPP:lle?” Kysymys on: ”Kuinka yhdistätte viiden alijärjestelmän tiedot yhtenäiseksi tietokokonaisuudeksi?”
Kolme todistettua integraatiomallia
Malli 1: OData / REST-Pull
Toimii hyvin nykyaikaisten ERP-järjestelmien kanssa (SAP S/4HANA Cloud, Dynamics 365, Odoo). DPP-palveluntarjoaja hakee tiedot OData- tai REST-rajapinnan kautta. Inkrementaalinen, aikataulutettu tai tapahtumapohjainen.
Edut: vähän kehitystyötä teidän puoleltanne, te toimitatte lukuoikeudet, palveluntarjoaja rakentaa muunnoksen.
Haitat: ei toimi vanhempien SAP ECC -asennusten kanssa ilman ylimääräistä API-kerrosta. Tarvitsette hallintaa tietojen käyttöpyynnöille.
Malli 2: Tapahtumapohjainen integraatio
SAP Event Mesh, Apache Kafka, RabbitMQ. ERP-järjestelmänne julkaisee muutostapahtumat, ja DPP-palveluntarjoaja käsittelee ne.
Edut: lähes reaaliaikainen, tyylikkäästi skaalautuva, irrotettu.
Haitat: Asennus on vaativa ja vaatii infrastruktuuria, jota kaikilla IT-osastoilla ei ole. Pienemmille yrityksille yleensä liioiteltu ratkaisu.
Malli 3: Middleware / ETL
Käytössä on integraatiokerros (Mulesoft, Boomi, Informatica, Azure Data Factory) ERP-järjestelmän ja ulkoisten järjestelmien välillä. Middleware toimii rajapintana - DPP-palveluntarjoaja kommunikoi middlewaren kanssa, ei koskaan suoraan ERP-järjestelmän kanssa.
Edut: olemassa olevat investoinnit voidaan hyödyntää, hallinto on vakaata, kolmansilla osapuolilla ei ole suoraa pääsyä ERP-järjestelmään.
Haitat: Middleware-kustannuksenne kasvavat järjestelmän laajentuessa.
Mitä teemme toisin konkreettisissa projekteissa
Monet toimittajat haluavat muodostaa suoran yhteyden ERP-järjestelmäänne. Me sisällytämme periaatteessa välivaiheen: API:mme hyväksyy neutraalin JSON-skeeman, jonka voitte täyttää valitsemallanne työkalulla. Tämä tarkoittaa:
- Voitte hoitaa tietojen esikäsittelyn itse, tiiminne tuntemilla työkaluilla
- Voitte vaihtaa palveluntarjoajaa - neutraali muoto on siirrettävissä
- Voitte hakea koko tietokantanne takaisin milloin tahansa - CSV-, XLSX-, JSON-LD- ja SQL-muodoissa sekä REST-API:n kautta
- Toimitamme tuontivalidaattorin, joka tarkistaa tietosi ennen niiden lataamista
Täydellinen skeema ja kaikki päätepisteet on dokumentoitu julkisesti /apidocs -sivustolla OpenAPI-määrityksenä. IT-osastonne voi testata rajapintaa ennen sopimuksen allekirjoittamista - mukaan lukien esimerkkikyselyt, virheviestit ja todennustiedot.
Tämän lähestymistavan aikataulu käytännössä:
- Päivä 1-2: Kartoitustyöpaja. Mikä ERP-kenttä vastaa mitä DPP-kenttää?
- Päivä 3-5: Ensimmäiset JSON-vientiä ERP-järjestelmästä, validoituna validointityökalullamme.
- Päivä 6-8: Virheiden korjaus (puuttuvat kentät, epäjohdonmukaiset koodaukset).
- Päivä 9-10: Ensimmäiset DPP:t ovat tuotannossa.
Kaksi viikkoa, ei kolmea kuukautta. Ratkaiseva vaihe on kartoitusworkshop - siellä päätetään tietojen laadusta.
Mitä voi mennä pieleen: yleisimmät sudenkuopat
Tuotetiedot useissa järjestelmissä: SAP:ssa on tuotenumero, PIM:ssä kuvat ja markkinointitekstit, PLM:ssä osaluettelo. Kukaan ei näe yhtenäistä kokonaiskuvaa. Ratkaisu: määritelkää ennen projektin alkua, mikä järjestelmä on kunkin kentän ”Source of Truth”.
Sertifikaatit PDF-tiedostoina: toimittajat toimittavat GOTS-, OEKO-TEX- tai REACH-sertifikaatit skannattuina PDF-tiedostoina. Tämä ei ole jäsennelty tietolähde. Ratkaisu: Sertifiointielimet tarjoavat yhä useammin API-kyselyjä (OEKO-TEX on edellä, GOTS jää jälkeen). Tai: syötä tiedot manuaalisesti, mutta lisää voimassaolopäivä, jotta DPP:ssä ei näy vanhentuneita sertifikaatteja.
Koostumuksen salassapito: erityisesti kosmetiikka-, elintarvike- ja lääketeollisuudessa: täydellinen koostumus on liikesalaisuus. Pitäisikö DPP:n julkistaa ne? Ratkaisu: ESPR:n kolmitasoinen malli. Tuoteryhmä on julkinen, viranomaiset näkevät täydellisen koostumuksen. Tämä ei ole lähes koskaan este, mutta asia on selvitettävä varhaisessa vaiheessa.
Toimittajakohtaiset CO2-tiedot: Toimittajanne ilmoittaa keskiarvon koko tuotevalikoimastaan, ei eräkohtaisesti. Ratkaisu: Hyväksytään tilapäisesti, pitkällä aikavälillä toimitussopimuksia mukautetaan. ESPR vaatii tuotekohtaisia arvoja tietystä päivämäärästä lähtien, mutta nykyinen käytäntö on kompromissi.
Paikalliset kieliversiot: ERP-järjestelmässänne on vain tuotenimet saksaksi ja englanniksi. 27 EU-maata varten tarvitsette enemmän. Ratkaisu: konekäännös terminologiatietokannan avulla; tästä on erillinen artikkeli.
Kysymykset, jotka teidän tulisi esittää ennen projektin aloittamista
Ennen kuin lähetätte tarjouspyynnön kolmelle toimittajalle, vastatkaa sisäisesti seuraaviin kysymyksiin:
- Kuinka monelle tuotteelle/tuotenumerolle DPP:t tulisi luoda? (10, 10 000, 1 miljoona?)
- Mitkä järjestelmät sisältävät tällä hetkellä DPP:n kannalta merkityksellisiä tietoja?
- Mikä osasto hallinnoi kutakin järjestelmää?
- Onko teillä middleware-investointia, jota tulisi hyödyntää?
- Onko ERP-järjestelmänne päällä jo toimiva API-kerros?
Vastaukset määrittävät, mikä kolmesta mallista sopii teille parhaiten. Ne myös ratkaisevat, kestääkö projekti kaksi viikkoa vai kuusi kuukautta.