Kuuntele substantiiveja
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)
Moduuli 1/6 luvussa Tietojen mallintaminen merkityksen kautta, Data Architect -kurssin luku 2. Jokainen moduuli on itsenäinen. Edellinen: luvun yleiskatsaus · Seuraava: Piirrä suhteet
Kysymys, johon tämä moduuli vastaa: Miten löydän tietomallin alun liiketoimintakeskustelusta?
Yksi asioista, joita teen ensimmäisessä puhelussa asiakkaan kanssa, on kuunnella substantiiveja.
En puhu ensimmäisestä suunnittelupalaverista. Puhun siitä alkukeskustelusta, jossa yritän vielä ymmärtää liiketoimintaa ja sitä, mitä he yrittävät saavuttaa.
He puhuvat. Minä kuuntelen.
Ja kuuntelen sanoja kuten:
Vähittäiskauppakumppani (Retail Partner). Vastaanottaja (Recipient). Jakelukeskus (Distribution Center). Kuormaluettelo (Manifest). Toimitus (Delivery). Reitti (Route). Tiimi (Crew). Kuorma-auto (Truck).
Nuo substantiivit kiinnittävät heti huomioni, koska jossain siinä keskustelussa ovat tietomallini alkuaineet.
En odota, kunnes luulen ymmärtäväni ongelman täysin. Alan nähdä tiedot jo kuunnellessani: kuulen substantiivit, alan luonnostella, miten ne liittyvät toisiinsa, ja se luonnos auttaa minua kehystämään seuraavan keskustelun. Joskus minulla on ensimmäisen asiakastapaamisen lopussa jo oma yksityinen tietomallini piirrettynä.
Minulla se alkaa substantiiveista.
Unohda Salesforce hetkeksi
Osio nimeltä “Unohda Salesforce hetkeksi ”Tässä kohtaa haluan sinun vastustavan vaistoa, joka on erityisen vahva, jos olet ollut Salesforce-ylläpitäjä jo jonkin aikaa.
Asiakas sanoo asiakas, ja sinä ajattelet:
Tili (Account).
Hän sanoo henkilö, ja sinä ajattelet:
Yhteyshenkilö (Contact).
Hän sanoo jakelukeskus, ja mietit jo, tarvitsetko mukautetun objektin.
Älä tee sitä vielä.
Tässä vaiheessa minua ei kiinnosta, tuleeko asiakkaasta lopulta tili, henkilötili (Person Account), mukautettu objekti vai jotain muuta. Ensin haluan ymmärtää liiketoiminnan.
Siinä on ero liiketoiminnan mallintamisen ja Salesforcen konfiguroinnin välillä. Jos aloitan Salesforce-objekteista, olen jo rajannut ajatteluni yhteen toteutukseen. Saatan päätyä juuri sinne, minne odotinkin, mutta haluan päätyä sinne, koska liiketoiminta vei minut sinne, en siksi, että tili ja yhteyshenkilö olivat ensimmäiset kaksi objektia, jotka tunsin.
Unohda siis Salesforce muutamaksi minuutiksi. Kuuntele, miten liiketoimintaa oikeasti pyörittävät ihmiset kuvaavat maailmaansa.
Istu, paikka, mallinna
Osio nimeltä “Istu, paikka, mallinna ”Ennen kuin kuuntelemme liiketoimintaa, kuunnellaan jotain, minkä kaikki jo ymmärtävät. Kun opetan tätä livenä, aloitan koirista.
Tässä on koira: Marcus omistaa Bellan. Maple Ridge Kennels kasvatti sen. Se on labradorinnoutaja, ja se osaa temput Istu, Paikka ja Anna tassu.
Kuuntele substantiiveja: Marcus, Bella, Maple Ridge Kennels, labradorinnoutaja, Istu. Ne ovat kuitenkin nimiä: tiettyjä asioita. Haluan tietää, millaiseen asiaan kukin nimi kuuluu. Bella on koira. Marcus on omistaja. Maple Ridge Kennels on kasvattaja. Labradorinnoutaja on rotu. Istu on temppu. Viisi substantiivia, viisi ehdokaslaatikkoa.
Sitten kysymys, jonka esitän jokaisesta substantiivista: onko se henkilö, joka tekee työtä, vai pala tietoa? Marcus on henkilö. Mutta Bellan omistaminen ei ole työ; se on tosiasia Bellasta, ja ennemmin tai myöhemmin joku kysyy: ”Kuka omistaa tämän koiran?” Omistaja kuuluu siis malliin. Kouluttaja, joka opetti Bellan antamaan tassua, on henkilö, joka tekee työtä, eikä hän ehkä koskaan tarvitse laatikkoa, ellei liiketoiminta ala kysyä, kuka opetti minkäkin tempun.
Ja huomaa sana ehdokas. Onko rotu todella oma laatikkonsa vai vain koiraan kirjoitettu sana? Pidä tämä kysymys mielessä; vastaamme siihen, kun normalisoimme moduulissa 4.
Siinä on koko tekniikka, jollakin pienellä. Kuunnellaan nyt oikeaa liiketoimintaa.
Substantiivit antavat sinulle ehdokasentiteetit
Osio nimeltä “Substantiivit antavat sinulle ehdokasentiteetit ”Kuunnellaan Steve Truckingia, perheyritystä, jota käytämme koko kurssin ajan. Se toimittaa suuria tuotteita (jääkaappeja, pesukoneita, televisioita) suurten vähittäiskauppaketjujen jakelukeskuksista ihmisten koteihin ja asentaa osan niistä.
Ensimmäisessä keskustelussa kuulemme:
- Vähittäiskauppakumppani (Retail Partner)
- Vastaanottaja (Recipient)
- Jakelukeskus (Distribution Center)
- Kuormaluettelo (Manifest)
- Toimitus (Delivery)
- Reitti (Route)
- Tiimi (Crew)
- Kuorma-auto (Truck)
Se on jo hyödyllistä. Voin alkaa piirtää laatikoita valkotaululle.
Laita siis substantiivit suorakulmioihin. Sitä ne tässä vaiheessa ovat: laatikoita. Ei viivoja, ei värejä, ei mitään, mikä sanoisi Salesforce. Myöhemmin kurssilla muodot ja värit alkavat merkitä jotain. Toistaiseksi suorakulmio on vain asia, josta liiketoiminta puhuu.
Ala sitten asemoida niitä. Kun sijoitat kunkin laatikon, mieti kahta asiaa: miten ne liittyvät toisiinsa ja millaista tietoa ne ovat. Osa on asiakastietoja: yritykset ja ihmiset, joiden kanssa työskentelemme. Osa on tapahtumatietoja, kuten tilaukset ja tilausrivit: asiat, jotka tapahtuvat yhä uudelleen. Ja osa on viitetietoja, kuten tuotteet tai palvelut, joita yritys tarjoaa: asiat, joista työ riippuu.
Steve Truckingissa vähittäiskauppakumppani ja vastaanottaja ovat asiakastietoja. Kuormaluettelo, toimitus ja reitti ovat tapahtumia. Jakelukeskus, tiimi ja kuorma-auto ovat sitä, mistä työ riippuu.
Mutta tässä on tärkeä sana: ehdokas.
Substantiivi on vihje. Se ei ole automaattisesti entiteetti, eikä se todellakaan ole automaattisesti Salesforce-objekti.
Kun olen kartoituspalaverissa, kirjoitan jokaisen substantiivin ylös. Jokaisen sanomansa substantiivin kohdalla kysyn itseltäni yhden kysymyksen: onko se henkilö, joka tekee työtä, vai pala tietoa? Liiketoiminnan kehityspäällikkö on henkilö, joka tekee työtä. Se on käyttäjä, rooli, ehkä käyttöoikeusjoukko. Tilaukset, laskut, rivit: ne ovat paloja tietoa. Molemmat ovat tärkeitä, mutta ne päätyvät suunnitelmassa hyvin eri paikkoihin, ja niiden lajittelu ajoissa säästää minut piirtämästä laatikkoa jokaiselle organisaatiokaavion tehtävänimikkeelle.
Osa noista substantiiveista on ihmisiä. Steve Truckingissa niitä ovat jääkaappia odottava vastaanottaja, vähittäiskauppakumppanin ihmiset, jotka lähettävät kuormaluettelon, ja tiimi: kuorma-auton kuljettajat ja apulaiset. Nämä ovat rooleja, eikä rooli välttämättä vaikuta tiedolta. Mutta kun ihmiset toimivat tietojen pohjalta tai liittyvät niihin, heidätkin täytyy esittää tiedoissa. Kuka toimitti tämän? Kuka kuittasi sen? Kuka lähetti kuormaluettelon? Siksi monet roolit, joskus kaikki, päätyvät myös malliin.
Kuuntele, miten Steve Truckingissa puhutaan, niin huomaat jotain. He eivät koskaan sano vain ”asiakas”. Asiakkaita on kahdenlaisia. Vähittäiskauppakumppani on suuri kauppaketju, jonka puolesta Steve Trucking toimittaa: se lähettää kuormaluettelon ja maksaa toimituskohtaisesti. Vastaanottaja on henkilö, jolle jääkaappi toimitetaan. Vastaanottaja osti sen kaupasta eikä ole ehkä koskaan kuullutkaan Steve Truckingista.
Jos olisin piirtänyt yhden laatikon nimeltä Asiakas, olisin sekoittanut kaksi täysin eri asiaa.
Ehkä jakelukeskus on niin tärkeä, että sillä on oma tietueensa, historiansa, suhteensa ja attribuuttinsa.
Ehkä jokin toinen substantiivi osoittautuu pelkäksi jonkin muun attribuutiksi.
Sitä yritämme selvittää. Emme luo vielä objekteja. Rakennamme ymmärrystämme liiketoiminnasta.
Kuuntele nyt suhteita
Osio nimeltä “Kuuntele nyt suhteita ”Substantiivit antavat minulle lähtöpaikan. Sitten kuuntelen, miten liiketoiminta yhdistää ne.
Vähittäiskauppakumppani ylläpitää jakelukeskuksia.
Vähittäiskauppakumppani lähettää kuormaluettelon kutakin jakelukeskusta ja toimituspäivää kohden.
Kuormaluettelossa luetellaan toimitukset.
Toimitus menee vastaanottajalle.
Reitti on päivän ajo, jossa on noin kymmenen pysähdystä (Stop).
Kahden hengen tiimi ajaa kuorma-autoa.
Nyt jotain tapahtuu. En enää katso substantiivien luetteloa. Alan nähdä mallin.
Tässä kohtaa alkaa myös ilmaantua kysymyksiä.
Voiko vähittäiskauppakumppanilla olla useampi kuin yksi jakelukeskus?
Onko toimitus sama asia kuin pysähdys?
Voiko yhdellä pysähdyksellä toimittaa kahdelle vastaanottajalle?
Onko tiimissä aina samat kaksi ihmistä?
Kiinnostaako meitä, millä kuorma-autolla mikin tiimi ajoi viime kuussa, vai vain se, millä kuorma-autolla he ajavat tänään?
Huomaa, mitä teemme. Emme vielä kysy Salesforce-kysymyksiä. Kysymme liiketoimintakysymyksiä. Ja niiden vastaukset ohjaavat lopulta Salesforce-suunnittelua.
Ensimmäisen mallisi ei tarvitse olla täydellinen
Osio nimeltä “Ensimmäisen mallisi ei tarvitse olla täydellinen ”En odota, että ensimmäiset piirtämäni laatikot säilyvät muuttumattomina. Itse asiassa olisin epäluuloinen, jos ne säilyisivät.
Ensimmäisen mallin tarkoitus ei ole olla oikeassa. Tarkoitus on antaa meille jotain niin konkreettista, että huomaamme, missä olemme väärässä.
Laita toimitus, reitti, tiimi ja kuorma-auto taululle, niin ihmiset voivat reagoida niihin.
”Itse asiassa toimitus ei aina ole yksi tuote. Se voi olla pesukone, kuivausrumpu ja vanhojen poisvienti.”
Hyvä. Kerro lisää.
”Emme osoita tiimiä toimitukselle. Osoitamme tiimin reitille.”
Loistavaa. Mitä reitillä on?
”Ja jos mukana on asennus, tiimi ei voi sulkea pysähdystä ennen kuin tarkistuslista ja kuvat on tehty.”
Nyt opimme jotain tärkeää.
Kaavio on muuttanut epämääräisen keskustelun joksikin, mitä voimme haastaa. Se on yksi syy, miksi pidän varhaisesta mallintamisesta. En yritä tehdä vaikutusta huoneeseen kauniilla kaaviolla. Yritän oppia nopeammin.
Malli on osa keskustelua.
Tämä on käsitteellinen mallisi
Osio nimeltä “Tämä on käsitteellinen mallisi ”Sille, mitä olemme alkaneet rakentaa, on virallinen nimi: käsitteellinen tietomalli.
Tällä tasolla minua kiinnostavat tärkeät asiat, joista liiketoiminta välittää, ja se, miten ne liittyvät toisiinsa. En vielä murehdi vakio- vai mukautettuja objekteja, kenttien API-nimiä, lookup- vai master-detail-suhdetta, pakollisia kenttiä, indeksejä, automaatiota, Apexia tai Flow’ta. Niillä on merkitystä, ja pääsemme niihin. Mutta jos päätämme ne ennen kuin ymmärrämme, mitä mallinnamme, ratkaisemme ensin väärää ongelmaa.
Käsitteellisen mallin pitäisi olla järkevä niille huoneessa oleville, jotka eivät tunne Salesforcea. Se on hyödyllinen testi. Jos minun täytyy selittää, mitä Delivery__c tarkoittaa, ennen kuin operatiivinen johtaja pystyy lukemaan kaavioni, olen siirtynyt toteutukseen liian aikaisin.
Haluan heidän katsovan mallia ja sanovan:
”Kyllä, näin liiketoimintamme toimii.”
Tai vielä parempi:
”Ei, ei se näin toimi.”
Koska nyt minulla on jotain korjattavaa.
Sama tekniikka toimii, vaikka kukaan ei puhu
Osio nimeltä “Sama tekniikka toimii, vaikka kukaan ei puhu ”Tämä ei ole vain jotain, mitä käytän asiakkaiden kartoituksessa. Se toimii myös silloin, kun ”asiakas” on dokumentti.
Kun käyn läpi vaatimusdokumenttia, teen pitkälti saman asian. Mitkä ovat tärkeät liiketoiminnan käsitteet? Mitä suhteita kuvataan? Mikä toistuu? Millä on oma elinkaarensa, mikä täytyy tunnistaa omana itsenään tai mikä tarvitsee historiaa? Mitä luodaan, muutetaan, osoitetaan, siirretään, aikataulutetaan tai poistetaan käytöstä?
Nämä ovat samoja asioita, joita kuuntelen ensimmäisessä tapaamisessa. Paperilla nuo vihjeet muuttavat kappaleittain vaatimuksia malliksi, jonka avulla voin päätellä asioita, ja paremmiksi kysymyksiksi seuraavaan keskusteluun.
Malli ei ole vain jotain, minkä tuotat ratkaistuasi ongelman. Se on yksi työkaluista, joilla ongelma ratkaistaan.
Mitä arkkitehti tässä päättää
Osio nimeltä “Mitä arkkitehti tässä päättää ”Tämän ensimmäisen kierroksen lopussa yritän päättää:
- Mitkä substantiivit edustavat merkityksellisiä ehdokasentiteettejä.
- Mitkä eri sanat edustavat samaa liiketoiminnan käsitettä ja mikä yksi sana kätkee kaksi (kuten ”asiakas”).
- Mitkä käsitteet tarvitsevat oman tietueen ja oman elinkaaren.
- Miten tärkeimmät käsitteet liittyvät toisiinsa.
- Mihin kysymyksiin liiketoiminnan täytyy vastata ennen kuin voin mallintaa ne luottavaisin mielin.
En vielä päätä Salesforce-toteutuksesta. Ensin meidän täytyy ymmärtää liiketoiminta niin hyvin, että pystymme piirtämään sen. Ja kun substantiivit ovat taululla, seuraavaksi haluan ymmärtää niiden väliset viivat.
Kokeen jälkeen: mitä tekoäly muuttaa. Anna tekoälytyökalulle vaatimusdokumentti, niin se löytää substantiivit, ehdottaa entiteettejä ja luonnostelee suhteita sekunneissa. Käytä sitä nopeuttamaan kartoitusta, mutta älä ulkoista ymmärtämistä: se ei voi tietää, että ”asiakas” tarkoittaa Steve Truckingissa kahta eri asiaa, ellei liiketoiminta kerro sitä sinulle. Vie sen ensimmäinen malli liiketoimintaa pyörittävien ihmisten eteen ja kysy: ”Toimiiko liiketoimintanne todella näin?”