Tuotteen paino löytyy materiaalinhallinnasta. Kierrätysmateriaalin osuus löytyy reseptijärjestelmästä. Toimittajan sertifikaatti on PDF-tiedostona verkkoasemalla. Tuotetiedot tarvitsevat kaikki kolme tietoa yhdessä tietueessa, ja juuri tässä piilee integraatioprojekti, ei kahden järjestelmän yhdistämisessä.
”Saumaton ERP-integraatio” on vakiolupaus, jota seuraa käytännössä kolmen kuukauden projekti. Julkaisemme oppaamme, jotta IT-osastonne voi tarkistaa ennen sopimuksen allekirjoittamista, mitä tietoja todellisuudessa kysytään. Tämä artikkeli kertoo, mitä tietoja tuotepassi tarvitsee järjestelmistänne, millä kolmella tavalla ne saapuvat meille ja miksi se onnistuu kahdessa viikossa.
Mitä ERP-järjestelmänne todella on toimitettava
Jotta tuotepassi 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 (huolellisuusvelvoitteiden täyttämiseksi)
Teoriassa nämä tiedot ovat kaikki saatavilla ERP-järjestelmässänne. Käytännössä ne ovat hajallaan 4-7 moduulissa: materiaalinhallinta, tuotanto, laatu, toimittajatietokanta, joskus erillinen moduuli ympäristötiedoille, joskus oma järjestelmä resepteille ja osaluetteloille.
Integraatiokysymys ei ole: ”Toimittaako ERP-järjestelmänne tietoja DPP:lle?” Kysymys on: ”Kuinka yhdistätte viidestä alijärjestelmästä peräisin olevat tiedot yhtenäiseksi tietokokonaisuudeksi?”
Kolme toimivaksi todettua tapaa
Tapa 1: Tietojen hakeminen ERP-järjestelmästä
Toimii hyvin nykyaikaisten ERP-järjestelmien kanssa (SAP S/4HANA Cloud, Dynamics 365, Odoo). DPP-palveluntarjoaja hakee tiedot ERP-järjestelmän rajapinnan kautta (teknisesti OData tai REST). Vain muutokset, aikataulun mukaan tai tapahtuman laukaisemina.
Edut: vähän kehitystyötä teidän puoleltanne, te myönnätte lukuoikeuden, palveluntarjoaja rakentaa muunnoksen.
Haitat: ei toimi vanhempien SAP ECC -asennusten kanssa ilman ylimääräistä rajapintakerrosta. Tarvitsette selkeät säännöt siitä, kuka saa lukea mitäkin tietoja.
Tapa 2: Muutosten välittäminen
ERP-järjestelmänne ilmoittaa jokaisesta muutoksesta tapahtumana (SAP Event Meshin, Apache Kafkan tai RabbitMQ:n kautta), ja DPP-palveluntarjoaja vastaanottaa ne.
Edut: lähes reaaliaikainen, skaalautuu tarpeen mukaan, järjestelmät eivät ole riippuvaisia toisistaan.
Haitat: Asennus on vaativa ja vaatii infrastruktuuria, jota kaikilla IT-osastoilla ei ole. Pienemmille yrityksille yleensä liioiteltu ratkaisu.
Tapa 3: Käytä olemassa olevaa integraatiokerrosta
Sinulla on jo integraatiokerros (Mulesoft, Boomi, Informatica, Azure Data Factory) ERP-järjestelmän ja ulkoisten järjestelmien välillä. Tämä kerros toimii välittäjänä: DPP-palveluntarjoaja kommunikoi sen kautta, ei koskaan suoraan ERP-järjestelmän kanssa.
Edut: olemassa olevat investoinnit voidaan hyödyntää, säännöt pysyvät vakaina, kolmansilla osapuolilla ei ole suoraa pääsyä ERP-järjestelmään.
Haitat: integraatiokerroksen kustannukset kasvavat mukana.
Mitä teemme toisin konkreettisissa projekteissa
Monet palveluntarjoajat haluavat muodostaa yhteyden suoraan ERP-järjestelmäänne. Me rakennamme periaatteessa välivaiheen: rajapintamme vastaanottaa neutraalin tietomuodon (JSON-skeeman), jonka voitte täyttää valitsemallanne työkalulla. Tämä tarkoittaa:
- Voitte hoitaa tietojen kä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 tietonne ennen niiden lataamista
Täydellinen formaatti ja kaikki kyselyt on kuvattu julkisesti osoitteessa API-dokumentaatio OpenAPI-standardin mukaisena rajapintakuvauksena. IT-osastonne voi tarkistaa rajapinnan ennen sopimuksen allekirjoittamista - mukaan lukien esimerkkikyselyt, virhevastaukset 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ä, jotka käyvät läpi validointityökalumme.
- Päivät 6-8: Virheiden korjaus (puuttuvat kentät, epäjohdonmukaiset koodaukset).
- Päivät 9-10: Ensimmäiset DPP:t ovat tuotannossa.
Kaksi viikkoa, ei kolmea kuukautta. Ratkaiseva tekijä on kartoitusworkshop - siellä päätetään tietojen laadusta.
Mikä menee 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 johtava kunkin kentän osalta.
Sertifikaatit PDF-tiedostoina: alihankkijat toimittavat GOTS-, OEKO-TEX- tai REACH-sertifikaatit skannattuina PDF-tiedostoina. Tämä ei ole jäsennelty tietolähde. Ratkaisu: Sertifiointielimet tarjoavat yhä useammin mahdollisuuden hakea tietoja rajapinnan kautta (OEKO-TEX on edellä, GOTS on jäljessä). 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 väliaikaisesti, pitkällä aikavälillä toimitussopimuksia mukautetaan. ESPR vaatii tuotekohtaisia arvoja tietystä päivämäärästä lähtien, mutta nykykäytäntö on kompromissi.
Paikalliset kieliversiot: ERP-järjestelmässänne on vain tuotenimitykset 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ä integraatiokerros, jota tulisi hyödyntää?
- Onko ERP-järjestelmänne kautta jo toimiva rajapinta?
Vastaukset määrittävät, mikä kolmesta vaihtoehdosta sopii teille parhaiten.
Vastaukset ratkaisevat, kestääkö projekti kaksi viikkoa vai kuusi kuukautta.
Kysymyksiä tästä artikkelista
Riittääkö REST-rajapinta, vai tarvitsemmeko väliohjelmistoa?
Rajapinta riittää. Nämä kolme mallia eroavat toisistaan siinä, missä muunnos tapahtuu, eivät siinä, mitä vastaanotamme - rajapintamme hyväksyy neutraalin JSON-skeeman riippumatta siitä, millä ohjelmalla se on luotu. Nouto modernista ERP-järjestelmästä, tapahtumavirta ja olemassa oleva integraatiokerros päätyvät kaikki samaan päätepisteeseen. Middleware on kannattava ratkaisu, jos käytätte sitä muutenkin ja jos sen on tarkoitus toimia sopimuksen osapuolena kolmansien osapuolten kanssa. Jos sellaista ei tällä hetkellä ole, älkää hankkiko sitä tuotepassin vuoksi.
Mistä päätetään kartoituspajassa?
Mikä ERP-kenttä vastaa mitä passikenttää - ja mikä järjestelmä on ensisijainen lähde, jos useammassa järjestelmässä on sama arvo. Työpaja pidetään päivinä 1 ja 2, ja se on koko projektin ratkaiseva vaihe, koska siellä päätetään tietojen laadusta eikä vasta myöhemmin koodin yhteydessä. Tuokaa mukaan ne henkilöt, jotka ylläpitävät järjestelmiä, älkää vain niitä, jotka vastaavat projektista - perustiedot, tuotanto, laatu ja hankinta sijaitsevat harvoin samassa osastossa. Kaikki sen jälkeinen, eli vienti, validointi ja virheiden korjaus, on ammattitaitoa.
Sertifikaattimme ovat saatavilla vain PDF-skannauksina. Mitä teemme niillä?
Skannaus ei ole jäsennelty tietolähde, joten sitä ei voi käyttää passissa. On kaksi toimivaa tapaa: varmentajat tarjoavat yhä useammin API-kyselyjä, ja jos niitä ei ole, syöttäkää arvot käsin, mutta aina voimassaolopäivämäärän kera, jotta vanhentunut varmenne ei jää julkaistuun passiin. Suunnittele manuaalinen menetelmä toistuvaksi työtehtäväksi, älä kertaluonteiseksi tehtäväksi.
Voiko IT-osastomme tarkistaa rajapinnan ennen kuin allekirjoitamme mitään?
Kyllä. Täydellinen kaavio ja kaikki päätepisteet ovat saatavilla OpenAPI-määrittelynä osoitteessa API-dokumentaatio, mukaan lukien esimerkkikyselyt, virhevastaukset ja todennustiedot. Mikään näistä ei vaadi myyntineuvotteluja, joten integraatiotiimisi voi arvioida työmäärän jo ennen sopimuksen solmimista. Jos palveluntarjoaja ei esittele rajapintaansa tässä vaiheessa, sekin on jo vastaus.
Mitä tapahtuu tiedoillemme, kun vaihdamme palveluntarjoajaa?
Ne siirtyvät mukana. Rajapinta hyväksyy neutraalin JSON-skeeman omien formaattien sijaan, ja koko tietokantanne voidaan viedä CSV-, XLSX-, JSON-LD- ja SQL-muodoissa tai REST-API:n kautta. Tämä on tarkoituksellista - syöttämäsi muoto on siirrettävissä, joten vaihto vaatii vain viennin eikä uuden rakentamista. Esitä jokaiselle palveluntarjoajalle sama kysymys ennen kartoitusworkshopia, sillä sen jälkeen kenttänimesi näkyvät palveluntarjoajan mallissa.
Kuinka kauan liitäntä todella kestää?
Niissä projekteissa, joita tuemme, kuluu kaksi viikkoa - kaksi päivää kartoitusta, kolme päivää ensimmäisiin vientitoimintoihin validatorimme kautta, kolme päivää virheiden korjaamista, kaksi päivää ensimmäisten julkaistujen passien valmistumiseen. Pisin tie ei ole koskaan koodi, vaan se, mitä validointityökalu löytää - puuttuvat kentät, epäjohdonmukaiset koodaukset, arvot, joista kukaan ei tunne olevansa vastuussa. Varatkaa nämä päivät aikatauluunne sen sijaan, että lyhennätte niitä. Projekti, jossa nämä vaiheet ohitetaan, julkaisee puutteet mukana.
Pitääkö meidän liittää kaikki tuotteet kerralla?
Ei. Aloittakaa tuotteista, jotka tarvitsevat passin ensimmäisinä, ja lähdejärjestelmästä - neutraali malli hyväksyy osaluettelon yhtä hyvin kuin täydellisenkin, ja tuonnit ovat toistettavissa, joten myöhemmät ajot päivittävät varastosaldoa. Tämä pitää myös kartoitustyöpajan riittävän pienänä, jotta se voidaan toteuttaa kahdessa päivässä. Sen jälkeinen laajentaminen on kartoitustehtävä, ei uusi projekti.
