Pilvitietomalli

Tämä on mallin keskeinen yhteentoimivuuslupaus: jaettu, sovellusagnostinen sanasto, jonka avulla hankinta-, ERP-, logistiikka- ja analytiikkajärjestelmät voivat sopia siitä, mikä “toimittaja” on.

Supplier-entiteetti sisältää kaksi laajaa attribuuttiperhettä: identiteetti ja luokittelu (kuka toimittaja on) ja suorituskykypisteytys (kuinka hyvin toimittaja suoriutuu). Pisteytysattribuutit on ryhmitelty kolmeen painotettuun luokkaan – sopimus, tyytyväisyys ja kilpailukyky –, jotka summautuvat yhdeksi supplierScore-arvoksi. Näiden osien yhteensopivuuden ymmärtäminen on välttämätöntä kaikille, jotka toteuttavat toimittajien tuloskortteja, toimittajien perustietoja tai hankinta-analytiikkaa CIM:n päälle.

Keskeiset takeawayt

• Supplier on Party Role, ei itsenäinen entiteetti. Se perii identiteetin Party-entiteetiltä ja lisää roolikohtaisia attribuutteja, joten toimittajan perustietoja ei koskaan eroteta (forkata) asiakkaan perustiedoista.
• Pisteytys on painotettu kolmen luokan malli. Sopimus-, tyytyväisyys- ja kilpailukyky-mittarit sisältävät kukin weightPercent- ja weightScore-arvot; yleinen supplierScore yhdistää ne.
• Useimmat arvokentät ilmaistaan kokonaislukuina, jotka edustavat prosentteja tai määriä, mikä pitää mallin yksinkertaisena, mutta siirtää pyöristys- ja normalisointipäätökset toteutukseen.
• id ja activeFromDate ovat pakollisia. Jokainen toimittajatietue tarvitsee vakaan GUID-ensisijaisen avaimen ja alkamispäivämäärän aktiiviselle jaksolleen.
• isCarrier on kevyt erikoistumislippu, jonka avulla logistiikkalogiikka tunnistaa kuljetusliikkeet (esim. FedEx, UPS) ilman erillistä entiteettiä.
• CIM on suunniteltu laajennettavaksi. Malli on avoimen lähdekoodin ja se on tarkoitettu haaroitettavaksi ja mukautettavaksi, joten käsittele näitä attribuutteja perussopimuksena, ei suljettuna skeemana.

Miksi Supplier on mallinnettu Party Roleksi

CIM:n tärkein suunnittelupäätös on Party / Party Role -jako, joka on malli, jota esiintyy myös vakiintuneissa yritysmalleissa, kuten TM Forumin tietokehyksessä (SID) ja yleisesti perustietojen hallintakäytännöissä. Party on pysyvä asia – oikeushenkilö, organisaatio tai henkilö. Party Role on ajallisesti rajoitettu suhde, joka kyseisellä osapuolella on yritykseen.

Tällä on merkitystä, koska todellisessa liiketoiminnassa toimitaan useissa rooleissa. Sopimusvalmistaja voi myydä sinulle valmiita tuotteita (Supplier), ostaa komponentteja sinulta (Customer) ja kehittää tuotetta yhdessä kanssasi (Partner).

Jos mallinnat jokaisen erilliseksi tietueeksi, saat päällekkäisiä toimittaja-/asiakasperustietoja, sovituspainajaisia ja epäjohdonmukaisia hierarkioita. Tekemällä Supplierista roolin, CIM antaa sinun liittää yhden Party-entiteetin useisiin rooleihin ja säilyttää yhden “golden record” -tietueen.

Käytännön vaikutukset:

Aiheeseen liittyvä: Fivetran — Täysin hallittu ELT-putkisto, joka vain jatkaa käynnissä.

• Duplikointi estetään Party-tasolla. Kaksi Supplier-tietuetta, jotka viittaavat samaan Partyyn, ovat sama oikeushenkilö.
• Roolit ovat ajallisia. activeFromDate- ja activeToDate-kenttien avulla toimittajasuhde voi alkaa ja päättyä poistamatta historiaa.
• Roolikohtaiset tiedot pysyvät roolissa. Toimittajan sijoitus- ja tuloskorttimittarit kuuluvat Supplier-entiteetille, ei Party-entiteetille, koska ne ovat järkeviä vain toimittajan kontekstissa.

Identiteetti- ja luokitusattribuutit

Identiteettiattribuutit ovat tarkoituksella minimaalisia, mikä on tyypillistä jaetulle mallille, jonka on voitava kartoittaa puhtaasti moniin lähdejärjestelmiin.

• id (guid, pakollinen) — ensisijainen avain. GUID:n käyttäminen luonnollisen avaimen sijaan välttää törmäykset yhdistettäessä tietueita useista järjestelmistä.
• activeFromDate (päivämäärä, pakollinen) — milloin toimittajasuhde aktivoitui.
• activeToDate (päivämäärä) — milloin se päättyi, jos on päättynyt.
• supplierType (merkkijono) — vapaatekstinen luokitus, kuten Retailer, Distributor, Manufacturer tai Merchant.
• isCarrier (boolean) — totta, kun toimittaja on kuljetusyritys, kuten FedEx tai UPS.
• supplierSpend (kokonaisluku) — tuotteiden hankintaan toimittajalta käytetyt kokonaiskustannukset.

Huomautus supplierType-kentästä: koska se on pelkkä merkkijono, se on hallittu sanasto konvention, ei skeeman mukaan. Todellisessa käyttöönotossa sinun tulee rajoittaa se luettelolla tai viitetietoluettelolla, muuten “Manufacturer”, “manufacturer” ja “Mfg” pirstovat raportointisi. Tämä on klassinen kompromissi jaetuissa malleissa – joustavuus vastaan johdonmukaisuus – ja CIM nojaa joustavuuteen odottaen toteuttajien tiukentavan sitä.

Vastaavasti supplierSpend kokonaislukuna herättää valuutta- ja mittakaavakysymyksen. Malli ei määritä valuutta- tai alayksikkökäytäntöä, joten sinun on päätettävä (esimerkiksi tallentaa alayksiköt ja yhdistää kenttä oman laajennuksesi valuuttakoodiin) ennen kuin aggregoit kuluja eri alueiden välillä.

Jos olet ostoksilla: Boomi AtomSphere — Enterprise iPaaS hybridi pilvestä on-prem -integraatioon.

Toimittajan tuloskortti: sopimus, tyytyväisyys ja kilpailukyky

Supplier-entiteetin sydän on sen tuloskortti, joka on kolmen mittausluokan painotettu yhdistelmä. Jokaisella luokalla on weightPercent (kuinka paljon se vaikuttaa kokonaissummaan) ja weightScore (pistemäärä, joka annetaan kyseisen luokan mittausten analysoinnin jälkeen). Yleinen supplierScore määritellään seuraavasti:

(sopimuspaino × pistemäärä) + (tyytyväisyyspaino × pistemäärä) + (kustannus/kilpailukyky-painoprosentti × pistemäärä)

Sopimuksen suoritusmittaukset

Nämä ovat objektiivisia, toiminnallisia mittareita, jotka on sidottu ostosopimukseen:

• contractOnTimeDeliveryRate — oikea-aikaiset toimitukset luvattuihin päivämääriin nähden ÷ kokonaistoimitukset.
• contractDeliveryCorrectnessRate — toimitukset, joissa määrä on oikein ÷ kokonaistoimitukset.
• contractProductQualityRate — viallisten tuotteiden prosenttiosuus.
• contractProductReturnRate — palautettujen tuotteiden prosenttiosuus.
• contractInvoiceAccuracyRate — kuinka usein laskut olivat virheellisiä viimeisen 12 kuukauden aikana.
• contractSLAIssueRate — kuinka monta kertaa SLA rikottiin viimeisen 12 kuukauden aikana.
• contractBudgetCostRate — yksikkökustannusten prosentuaalinen poikkeama sovitun ostotilaushinnan yläpuolelle.
• contractSourcingCycleDays — päivät hankinnan alkamisesta sopimuksen allekirjoittamiseen.

Tyytyväisyysmittarit

Nämä ovat subjektiivisempia, suhteisiin perustuvia arvioita:

• satisfactionCustomerServiceRank — kuinka asiakkuuden hallintaan liittyvät ongelmat reititetään ja ratkaistaan.
• satisfactionTechnicalSupportRank — miten koulutus ja dokumentaatio on arvioitu.
• satisfactionEthicsRank — työkäytännöt, turvalliset työolosuhteet ja jakelukelpoisuus.

Kilpailulliset mittarit

Nämä kuvaavat, miten toimittaja pärjää vaihtoehtoihin verrattuna:

• competitiveCostAvoidanceRank — arvo, joka on saavutettu ilmaisen koulutuksen, toimituksen ja vastaavien myönnytysten kautta.
• competitiveMarketingRank — toimittajaan liittyvän goodwillin aste.
• competitiveProductPriceRank — todennäköisyys saada ensimmäiset tai parhaat hinnat suhteen elinkaaren aikana.
• competitiveWarrantyRank — tarjottu takuu suhteessa muihin toimittajiin.

Jokainen luokka antaa sitten yhteenvetoon arvot competitiveWeightPercent / competitiveWeightScore, contractWeightPercent / contractWeightScore ja satisfactionWeightPercent / satisfactionWeightScore.

Aiheeseen liittyvä: Matillion — Push-down ELT rakennettu pilvitietovarastoihin.

Laskuesimerkki

Oletetaan, että hankintaryhmä painottaa kolmea luokkaa seuraavasti ja antaa kullekin arvosanan 0–100:

Luokka	Paino %	Pisteet	Painotettu osuus
Sopimus	50	90	45,0
Tyytyväisyys	20	80	16,0
Kilpailukyky	30	70	21,0
Yhteensä (supplierScore)	100	—	82,0

Keskeistä on, että kolmen weightPercent-arvon summan on oltava 100. CIM ei valvo tätä, joten toteutuksenne tulisi validoida se. Jos summa ei ole 100, yhdistelmäpisteet ovat merkityksettömiä normalisoituna lukuna. Yleinen hallintatapa on kiinnittää painot keskitetysti (esim. 50/20/30), jotta pisteet ovat vertailukelpoisia koko toimittajakannassa, ja säätää painoja vain tiettyjen hyödykeluokkien osalta, joissa kompromissit todellisuudessa eroavat.

Kuinka päättää: käytännön ohjeita toteuttajille

Kun otatte Supplier-entiteetin käyttöön, muutamat päätökset määrittävät, onko tuloskorttisi luotettava.

Lukijan suosikki: Airbyte — Avoimen lähdekoodin ELT hallitulla pilvivaihtoehdolla.

• Normalisoi ennen painottamista. Raakadata-kentät ovat prosentteja ja määriä eri asteikoilla. Muunna jokainen mittari yhteiselle 0–100 asteikolle (tai 0–1) ennen painojen soveltamista, muuten yksittäinen suuri lukuarvo hallitsee tulosta.
• Määritä suuntaavuus eksplisiittisesti. Useimmissa kentissä korkeampi arvo on parempi — mutta contractProductReturnRate, contractSLAIssueRate, contractInvoiceAccuracyRate (kuten “virheellisten määrä”) ja contractBudgetCostRate (poikkeama sovitun hinnan yläpuolelle) ovat mittoja, joissa pienempi on parempi. Käännä ne pisteytyksen aikana.
• Käsittele puuttuvat tiedot harkitusti. Uudella toimittajalla ei ole 12 kuukauden historiaa. Päätä, jätetäänkö luokka pois, käytetäänkö neutraalia pistemäärää vai merkitäänkö toimittaja merkinnällä “riittämättömät tiedot” sen sijaan, että se pisteytettäisiin hiljaa nollaksi.
• Säilytä raakamittaukset. Tallenna taustalla olevat prosenttiosuudet yhdistelmäpisteiden rinnalle, jotta voit painottaa ja auditoida ne myöhemmin uudelleen. Yksittäinen supplierScore ilman alkuperää ei ole perusteltavissa hankinta-arvioinnissa.
• Versioi painot. Jos muutat painoja, historialliset pisteet eivät ole enää vertailukelpoisia. Kirjaa ylös voimassa ollut painotussetti, kun kukin pistemäärä on laskettu.

Toimittajatietojen integrointi eri järjestelmiin

Koska CIM on sovellusagnostinen, Supplier-entiteetti on arvokkain kanonisena kohteena integraatiolle. Tyypillinen putki hakee toimittajien perustiedot ERP-järjestelmästä (SAP, Oracle, Microsoft Dynamics), tuloskorttitiedot hankinta- tai SRM-työkalusta ja kuljetusliikennöitsijän tiedot kuljetuksen hallintajärjestelmästä, ja kartoittaa ne kaikki CIM Supplier -malliin.

• Kartoita luonnolliset avaimet id-kenttään. Jokaisella lähdejärjestelmällä on oma toimittajanumeronsa; ylläpidä ristiviittaustaulukkoa CIM GUID:iin.
• Täsmäytä Party-tasolla. Käytä Party-entiteettiä deduplikaation ankkurina, jotta samaa oikeushenkilöä ei lasketa kahdesti.
• Käytä isCarrier-kenttää reititysvinkkinä. Alavirran logistiikkalogiikka voi haarautua sen perusteella soveltaakseen kuljetusliikennöitsijäkohtaista käsittelyä.
• Julkaise malli sopimuksena. Työkalut, kuten dbt, Apache Atlas ja tietoluettelot, voivat dokumentoida CIM-kartoituksen, jotta analyytikot tietävät, mitä kukin kenttä tarkoittaa.

Tiimeille, jotka virallistavat tämän, CIM:n avoimen lähdekoodin luonne tarkoittaa, että voitte forkata mallin ja lisätä entiteettejä tai attribuutteja, joita liiketoimintanne tarvitsee — esimerkiksi valuuttakoodin supplierSpend-kentälle tai kontrolloidun luettelon supplierType-kentälle — samalla kun ydinosapuoli/roolirakenne säilyy muuttumattomana. Alan standardeja, joihin kannattaa pyrkiä kohdistamaan malli, ovat TM Forum Information Framework (SID) party/role-malleille ja GS1 tuote- ja sijaintitunnisteille, koska toimittaja- ja tuotetiedot kulkevat usein yhdessä.

Hallinto- ja tiedonlaatunäkökohdat

Toimittajan tuloskortti on vain niin hyvä kuin sitä syöttävä data, ja toimittajatiedot ovat tunnetusti epäjärjestyksessä, koska ne ovat peräisin monista järjestelmistä ja muuttuvat ajan myötä.

• Omistajuus. Nimeä tietovastaava (data steward) toimittajien perustiedoille; tuloskorttikentillä on usein eri omistaja (hankinta) kuin tunnistetietokentillä (talous tai MDM).
• Tuoreus. 12 kuukauden ikkunat laskun tarkkuus- ja SLA-kentissä edellyttävät rullaavaa uudelleenlaskentaa. Määrittele päivitysväli ja tee se näkyväksi.
• Auditointi. Koska pisteet ohjaavat hankintapäätöksiä, säilytä auditointijälki syötteistä, painotuksista ja lasketuista tuloksista.
• Etiikka ja vaatimustenmukaisuus. satisfactionEthicsRank-kenttä koskee työkäytäntöjä ja turvallisia työoloja — aloja, jotka ovat yhä useammin toimitusketjun due diligence -säännösten alaisia. Käsittele sitä vaatimustenmukaisuussignaalina, ei vain pehmeänä arvosanana.

Usein kysytyt kysymykset

Mikä on Supplier-entiteetti Cloud Information Modelissa?

Supplier on CIM:n Party Role, joka kuvaa tavaroita tai palveluita yritykselle toimittavaa osapuolta. Se perii identiteetin Party-entiteetiltä ja lisää toimittajakohtaisia attribuutteja, kuten supplierType, isCarrier, supplierSpend sekä täydellisen suorituskyvyn tuloskortin. Mallintaminen rooliksi itsenäisen entiteetin sijaan mahdollistaa sen, että yksi osapuoli voi toimia sekä toimittajana että asiakkaana ilman päällekkäisiä perustietoja.

Miten supplierScore lasketaan?

supplierScore yhdistää kolme painotettua kategoriaa: sopimus, tyytyväisyys ja kilpailukyky. Jokainen kategoria antaa oman weightPercent-arvonsa kerrottuna weightScore-arvolla, ja tulokset lasketaan yhteen. Jotta yhdistelmä olisi mielekäs, kolmen painoprosentin summan tulee olla 100, ja jokainen taustalla oleva mittari on normalisoitava yhteiselle asteikolle ennen painotusta.

Mitkä Supplier-kentät ovat pakollisia?

Vain kaksi kenttää ovat pakollisia: id (GUID-ensisijainen avain) ja activeFromDate (päivämäärä, jolloin toimittajasuhde tuli aktiiviseksi). Kaikki muu, mukaan lukien activeToDate, supplierType ja kaikki tuloskortin attribuutit, on valinnaista, mikä mahdollistaa osittaisten tietueiden lataamisen asteittain.

Mitä isCarrier-lippu tarkoittaa?

isCarrier on totuusarvo, joka on tosi, kun toimittaja on kuljetusyritys, kuten FedEx tai UPS. Se tarjoaa kevyen tavan logistiikka- ja lähetyslogiikalle tunnistaa kuljetusyritykset ilman erillistä entiteettiä tai alatyyppiä, mikä pitää mallin kompaktina.

Miksi useimmat tuloskorttikentät ovat kokonaislukuja?

Rate- ja rank-kentät on tyypitetty kokonaisluvuiksi, ja ne edustavat tyypillisesti prosentteja tai määriä. Tämä pitää mallin yksinkertaisena ja siirrettävänä eri järjestelmien välillä, mutta se tarkoittaa, että toteuttajien on päätettävä pyöristys-, skaalaus- ja normalisointikäytännöistä itse sen sijaan, että he luottaisivat skeemaan niiden valvontaan.

Voinko laajentaa Supplier-entiteettiä?

Kyllä. CIM on avoimen lähdekoodin malli, joka on tarkoitettu muokattavaksi, joten voit lisätä attribuutteja – esimerkiksi valuuttakoodin supplierSpend-kentälle tai ohjatun luettelon (enumeration) supplierType-kentälle – tai lisätä uusia entiteettejä. Laajennusten tulisi säilyttää ydinosapuolen/osapuolen roolirakenne (Party/Party Role), jotta yhteentoimivuus muiden CIM-pohjaisten järjestelmien kanssa säilyy.