Steve Truckingin järjestelmäkartta

🌐 Saatavilla myös 28 kielellä

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Español (México) · Français (Canada) · Deutsch (Schweiz)

Kuva on luotu tekoälyllä

Tekoälyn kääntämä. Yhteisö ei ole vielä tarkistanut käännöstä. Lue englanniksi

Moduuli 6/6 luvussa Yrityksen tietojen ymmärtäminen, Data Architect -kurssin luku 4. Jokainen moduuli on itsenäinen. Edellinen: Org-strategia on järjestelmäkartan päätös · Seuraava: seuraava luku, Tietojen laatu ja hallinta

Kysymys, johon tämä moduuli vastaa: Mitä todellinen järjestelmäkartta kertoo meille ennen kuin suunnittelemme mitään?

Tässä luvussa olemme vetäneet kameraa taaksepäin: Salesforce yhtenä järjestelmänä monien joukossa, tietojen lajit, Salesforcea ympäröivät järjestelmät, järjestelmäkartan piirtäminen ja org-strategia. Nyt kootaan kaikki yhteen Steve Truckingin kohdalla. Mutta emme korjaa vielä mitään. Se on koko kurinalaisuuden ydin: piirrä se, mikä on olemassa, kävele jokainen nuoli läpi ja katso, mitä järjestelmäkartta kertoo.

Aloita siitä, mitä tiedämme

Steve Truckingilla on yksi Salesforce-org Yhdysvalloissa. Service Cloud käsittelee vastaanottajien (Recipient) ja vähittäiskauppakumppaneiden (Retail Partner) tapaukset; Field Service hoitaa käynnit, tiimit ja mobiilisovelluksen; Experience Cloud antaa vähittäiskauppakumppaneille portaalin, jota käytetään nykyään vain korvausvaatimuksiin ja raportteihin; Sales Cloud seuraa kumppanisopimuksia ja tarjouksia uusista jakelukeskuksista (DC). Salesforce tulee siis keskelle.

Vasemmalle ihmiset: 45 ajojärjestelijää, jotka työskentelevät vähittäiskauppakumppaneiden jakelukeskuksissa, noin 700 tiimiläistä 330 kuorma-autossa, 60 asiakaspalvelijaa, 40 henkilöä operatiivisissa, talous- ja myyntitehtävissä sekä noin 300 vähittäiskauppakumppanien käyttäjää. Jo tämä kertoo jotain: kyse ei ole yhden osaston CRM:stä. Se on operatiivinen alusta suurimmalle osalle liiketoimintaa. Mutta se on silti yksi laatikko. Katsotaan nyt, mitä sen ympärillä on.

Click to enlarge

Steve Trucking tänään, ennen kunnollista toteutusta. Jokainen kuormaluettelo päätyy RouteDeskiin; ajojärjestelijät syöttävät reitit käsin Salesforceen ja valmiit pysähdykset takaisin; FleetLinkiltä puuttuu yhteys.

Merkitse, mikä on vialla

Tämä on nykytila ennen kunnollista toteutusta, ja sanon sen piirroksessa. Sitten otan värit käyttöön. Valmiin järjestelmän kartassa en käytä punaista; nykytilassa käytän. Punainen merkitsee huonoa tai virheellistä prosessia, katkoviiva käsin tehtyä työtä ja punaiset pisteet puuttuvaa yhteyttä. Myös pois jätetty nuoli kertoo jotain. Mikään tästä ei ole koristetta: jokainen punainen viiva on vaatimus, joka odottaa kirjoittamista.

Kolme kumppania, kolme integraatiota

Kolme vähittäiskauppakumppania lähettää kuormaluettelot (manifest) kolmella eri tavalla, joten piirrä jokainen erikseen.

Keystone pudottaa CSV-kuormaluettelon SFTP-palvelimelle joka iltapäivä toimitettavaksi kahden päivän päästä ja haluaa tilatiedoston takaisin joka yö. Kaksi nuolta: kuormaluettelo sisään tiedostona, Keystonen avaamana, ja tila ulos tiedostona, RouteDeskin avaamana. Asynkroninen, ja aikaikkuna on leveä.

Redrock lähettää kuormaluettelot REST API:n kautta ja odottaa tilapäivityksiä webhookilla sitä mukaa kuin niitä syntyy. Kaksi nuolta, kaksi mekanismia: Redrock kutsuu sisään kuormaluetteloilla API:n kautta, ja RouteDesk kutsuu ulos tilalla webhookin kautta. Lähes reaaliaikainen.

Brightwave lähettää EDI-tiedostoja kolmannen osapuolen verkon kautta ja odottaa EDI-tilaviestejä takaisin. Taas eri muoto, taas eri mekanismi.

Samat liiketoiminnan käsitteet (kuormaluettelo, toimitus, tila), kolme täysin erilaista integraatiota. Älä yksinkertaista piirrosta siksi, että toivoisit niiden olevan yhtenäisiä. Ne eivät ole. Se on nykytila.

Sitten kävele ne läpi. Keystone: miten SFTP-yhteys tunnistautuu, minne tiedosto päätyy, mikä sen poimii, mistä tiedämme, että koko tiedosto käsiteltiin, mitä virheelliselle riville tapahtuu ja miten Keystone kuulee muutoksesta ennen tämäniltaista tiedostoa? Redrock: miten API tunnistautuu, mitä tapahtuu, kun jompikumpi puoli on alhaalla, mikä lasketaan onnistuneeksi webhookiksi, entä jos sama tila saapuu kahdesti? Brightwave: kuka pyörittää EDI-verkkoa, missä muunnos tehdään, mitä kuittauksia palaa? Emme suunnittele mitään uudelleen. Etsimme kysymyksiä. Se on järjestelmäkartan tehtävä.

RouteDesk on yhä olemassa

RouteDesk on vanha työpöytäsovellus ajojärjestelyyn ja reititykseen, jolla ajojärjestelijät muuttavat kussakin jakelukeskuksessa kuormaluettelot reiteiksi. Siinä on kahdeksan vuoden toimitushistoria, ja se on määrä poistaa käytöstä. Piirrä se silti. Yleinen virhe on jättää pois järjestelmä, ”josta olemme luopumassa”. Milloin? Sanotaan, että vastaus on kahdeksantoista kuukautta. Silloin se on osa arkkitehtuuria vähintään kahdeksantoista kuukautta, eikä sen kahdeksan vuoden historia, noin viisi miljoonaa toimitusta, katoa sovelluksen mukana. Ja katso, mitä järjestelmäkartta paljastaa: RouteDesk ja Salesforce eivät ole yhteydessä. Tiimit hoitavat pysähdyksensä Salesforcen Field Service -sovelluksessa, mutta reitit rakennetaan RouteDeskissä, joten ajojärjestelijät syöttävät ne käsin Salesforceen joka ilta ja syöttävät sitten valmiit pysähdykset takaisin RouteDeskiin, jotta se voi lähettää tilan kumppaneille. Noin 3 300 pysähdystä päivässä, kahdesti, käsin. Se on piirroksessa katkoviivalla ja punaisella. Se kertoo myös, ettei Redrockin ”sitä mukaa kuin niitä syntyy” -webhook oikeasti ole sitä. Mitä RouteDesk omistaa tänään? Mikä on siitä riippuvainen? Minkä historian pitää säilyä sen jälkeen, ja missä: Salesforcessa, tietovarastossa, arkistossa? Emme vastaa vielä. Järjestelmäkartta vain paljasti kysymykset.

FleetLink on saari

Telematiikka-alusta FleetLink saa GPS-tiedot jokaisesta kuorma-autosta: noin 200 000 lukemaa päivässä, jokaisesta autosta, jokaisena minuuttina, jonka se on käynnissä. Eikä se ole yhteydessä mihinkään. Ajojärjestelijät katsovat sitä erilliseltä näytöltä. Piirrä siis FleetLink ilman nuolia. Ei mitään taianomaista integraatioviivaa siksi, että meidän mielestämme sellainen pitäisi olla.

Sitten laske nollat: 200 000 päivässä on yli 70 miljoonaa vuodessa. Se ei ole ”meillä on GPS-dataa”. Se on suoratoistolähde, jossa on paljon nollia, ja se on Salesforce-kokemuksen ulkopuolella. Tarvitseeko Salesforce 70 miljoonaa lukemaa vuodessa? Tuskin kaikkia. Se on suunnittelukysymys myöhemmäksi.

Taloushallinnolla on oma totuutensa

Talouden ERP laskuttaa kutakin vähittäiskauppakumppania jokaisesta toimituksesta, asennuksesta ja vanhan tavaran poisviennistä ja maksaa tiimeille kannustimet. Ja toimitusmäärät päätyvät sinne kuukausittaisen taulukon kautta. Piirrä taulukko. Älä korvaa sitä siistillä API-nuolella siksi, että olemme arkkitehteja ja tiedämme paremmin; se on osa nykyistä arkkitehtuuria. Ja kun se on piirretty, kysymykset tulevat: kuka sen tekee, mistä järjestelmästä, kuka sen tarkistaa, entä jos toimitus muuttuu lähettämisen jälkeen, ja kenen luku voittaa? Vastauksiin liittyy rahaa.

Snowflake saa viikoittaisen viennin

Snowflakessa on operatiivinen ja taloudellinen analytiikka, ja sitä syötetään viikoittaisella viennillä. Snowflake ei tee sitä itse; jokin välissä tekee: ajastettu vientityö, joka ajetaan Salesforcen ulkopuolella, hakee tiedot Bulk API:n kautta ja lataa ne Snowflakeen. Analytiikka seuraa sitä, missä tiedot ovat, ja Snowflake on jo analytiikan koti. Mutta myös ajoitus kertoo jotain. ”Mitä tapahtui viime kuussa?” Viikoittainen syöte riittää. ”Missä tämä toimitus on juuri nyt?” Snowflakesta en lähtisi liikkeelle. Sama yritys, eri kuormitus, eri tuoreus, eri vastaus.

Identiteetti ei tavoita kaikkia samalla tavalla

Yrityksen identiteetinhallinnan palvelu (IdP) tulee Salesforcen yläpuolelle. Toimistohenkilöstö käyttää kertakirjautumista. Mutta ajojärjestelijät ja tiimit kirjautuvat Salesforcen tunnuksilla. Yksi luottamusviiva IdP:stä Salesforceen piilottaisi siis puolet tarinasta. Todellinen kysymys on, mitkä käyttäjät kirjautuvat minkäkin reitin kautta, ja se kuuluu järjestelmäkarttaan.

Vastaanottajan kokemuksessa on aukko

Tekstiviesti- ja sähköpostipalvelu lähettää vastaanottajille RouteDeskistä geneerisen viestin ”toimituksesi on huomenna”. Seurantalinkkiä ei ole. Samaan aikaan tapauksia on noin 180 000 vuodessa, ja noin 60 % niistä on ”missä toimitukseni on?”: noin 108 000 tapausta vuodessa, joissa kysytään samaa asiaa. Laita se nyt FleetLinkin viereen. Yritys tietää, missä sen kuorma-autot ovat. Sen vastaanottajat soittavat ja kysyvät. Eikä tietävä järjestelmä ole yhteydessä siihen, joka vastaa. Minun ei tarvitse vielä suunnitella ratkaisua. Järjestelmäkartta kertoo jo tarinan.

Laita nollat inventaarioon

Laske nyt, mikä liikkuu. Kuten moduulissa 4, nollat eivät mene nuoliin; ne menevät kuvan taakse inventaarioon, jossa ne ohjaavat mekanismeja, kun suunnittelemme. Noin miljoona toimitusta vuodessa, noin 3 300 päivässä, kasvua 30 % vuodessa; keskimäärin noin 1,6 toimitusriviä kussakin; noin kahdeksan tilapäivitystä kussakin, eli tänään kahdeksan miljoonaa tilapäivitystä vuodessa; neljästä viiteen miljoonaa valokuvaa vuodessa, nyt tiimiläisten omissa puhelimissa; noin 200 000 GPS-lukemaa päivässä; noin 180 000 tapausta vuodessa. Nuoli, jossa lukee ”toimituksen tila”, ei ole satunnainen viesti. Laatikot kertovat, mitä on olemassa. Nuolet kertovat, mikä liikkuu. Nollat kertovat, kestävätkö oletuksesi todellisuuden.

Click to enlarge

Steve Truckingin järjestelmäkartan takana oleva inventaario: volyymi sen mekanismin vieressä, jota se ohjaa.

Tavoitearkkitehtuuria ei vielä ole, ja silti näen jo, missä tärkeät tiedot ovat, minkä lajisia ne ovat, kuinka nopeasti ne liikkuvat ja miten järjestelmät vaihtavat niitä.

Kokeen jälkeen: mitä tekoäly muuttaa. Oletetaan, että Steve Trucking rakentaa agentin vastaamaan vastaanottajan kysymykseen ”missä toimitukseni on?” Mitä järjestelmää sen pitäisi kysyä? Salesforce tietää käynnin, FleetLink tietää, missä kuorma-auto on, kumppanin kuormaluettelo määritteli toimituksen. Nykyinen järjestelmäkartta on agentin kartta, ja ennen kuin agentti voi vastata turvallisesti, arkkitehdin on tiedettävä, mikä järjestelmä on auktoritatiivinen kunkin tiedon osalta ja kuinka ajantasainen se on. Osoita agentti väärään lähteeseen, niin vanhentuneesta tiedosta tulee itsevarma vastaus.

Lue kipukohdat, älä korjaa niitä vielä

Astu taaksepäin. Kolme kumppania, kolme integraatiotyyliä. Vanha ajojärjestelytyökalu, jossa on kahdeksan vuoden historia, ja ajojärjestelijät, jotka syöttävät 3 300 pysähdystä päivässä käsin Salesforceen ja takaisin. Telematiikka-alusta, jossa on 200 000 lukemaa päivässä, irrallaan. Taloushallinto, joka laskee toimitukset kuukausittaisesta taulukosta. Analytiikka viikon jäljessä. Kertakirjautuminen osalle käyttäjistä, ei kaikille. Ei seurantalinkkiä, ja 108 000 tapausta vuodessa, joissa kysytään, missä toimitus on. Ja kaikki kasvaa 30 % vuodessa.

Siinä on paljon arkkitehtuuria yhdestä kuvasta. Houkutus on alkaa korjata. Älä. Ei vielä. Haluan, että sinun on helppo jättää nykytilan kaavio rumaksi, koska joskus nykytila on ruma. Tarkoitus ei ole tehdä vaikutusta siistillä piirroksella; tarkoitus on yhteinen ymmärrys todellisuudesta. Jos suunnittelet uudelleen samalla kun dokumentoit, menetät lähtötason. Myöhemmin haluan voida sanoa: tämä oli olemassa, tämä oli ongelma, jonka ratkaisimme, tämän muutimme, ja tästä syystä. Luku 6 alkaa tehdä päätöksiä omistajuudesta ja identiteetistä, ja Tarkistuspiste 1 kokoaa osan 1 yhteen. Integration Architect -kurssi suunnittelee kumppanivirrat syvällisesti.

Mitä arkkitehti tässä päättää

Tässä vaiheessa arkkitehti ei päätä tavoitearkkitehtuuria. Päätös on, ymmärretäänkö nykytila riittävän hyvin, jotta sellainen voidaan suunnitella:

• Mitkä järjestelmät, käyttäjäryhmät, tietovarastot ja ulkoiset kumppanit ovat tänään todella olemassa.
• Mitkä tiedot ylittävät kunkin tärkeän rajan, mihin suuntaan, kuinka usein ja millä mekanismilla.
• Missä operatiiviset, analyyttiset, suoratoistetut, historialliset ja rakenteettomat tiedot ovat nyt.
• Mitkä virrat kantavat eniten volyymia ja ansaitsevat huomiota varhain.
• Mistä aukoista, manuaalisista vaiheista, irrallisista järjestelmistä, epäselvistä auktoriteeteista ja epäjohdonmukaisista malleista tulee eksplisiittisiä suunnittelukysymyksiä.

Tämä luku alkoi yhdestä ajatuksesta: piirrä järjestelmäkartta ennen kuin suunnittelet orgin. Jos olisin aloittanut Steve Truckingin tietomallista, olisin voinut käyttää tunteja objekteihin ja suhteisiin, kun FleetLink oli ulkopuolella 200 000 lukemaa päivässä, RouteDeskissä oli kahdeksan vuoden historia, kolme kumppania puhui kolmea kieltä, taloushallinto käytti taulukkoa ja sata tuhatta tapausta vuodessa kysyi, missä toimitus on. Ne eivät ole objektimallin kysymyksiä. Ne ovat yrityksen tietojen kysymyksiä. Piirrä rumat integraatiot, taulukko ja järjestelmä, josta olet muka luopumassa. Kirjoita nollat ylös. Kävele jokainen nuoli läpi. Sitten olet valmis muuttamaan sitä.

Lue lisää

• Steve Truckingin taustakuvaus, osiot 2–4, ja sen järjestelmäkarttakaavio.