Lyssna efter substantiven
Finns även på 28 språk
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Modul 1 av 6 i kapitlet Modellera data för mening, kapitel 2 i kursen Data Architect. Varje modul står på egna ben. Föregående: kapitelöversikten · Nästa: Rita relationerna
Frågan den här modulen besvarar: Hur hittar jag början på en datamodell i ett affärssamtal?
En av de saker jag gör vid ett första samtal med en kund är att lyssna efter substantiven.
Jag pratar inte om det första designmötet. Jag pratar om det inledande samtalet där jag fortfarande försöker förstå verksamheten och vad de försöker åstadkomma.
De pratar. Jag lyssnar.
Och jag lyssnar efter ord som:
Detaljhandelspartner. Mottagare. Distributionscentral. Manifest. Leverans. Rutt. Team. Lastbil.
De substantiven fångar direkt min uppmärksamhet, för någonstans i det samtalet finns början på min datamodell.
Jag väntar inte tills jag tror att jag förstår problemet helt. Jag börjar se data medan jag fortfarande lyssnar: jag hör substantiven, jag börjar skissa hur de hänger ihop, och den skissen hjälper mig att rama in nästa samtal. Ibland har jag redan min egen privata datamodell uppritad när det första mötet med en kund är slut.
För mig börjar det med substantiven.
Glöm Salesforce en stund
Section titled “Glöm Salesforce en stund ”Det är här jag vill att du står emot en instinkt som är särskilt stark om du har varit Salesforce-admin ett tag.
Kunden säger kund, och du tänker:
Konto (Account).
De säger person, och du tänker:
Kontakt (Contact).
De säger distributionscentral, och du funderar redan på om du behöver ett anpassat objekt.
Gör inte det än.
I det här läget bryr jag mig inte om huruvida en kund till slut blir ett konto, ett personkonto (Person Account), ett anpassat objekt eller något annat. Först vill jag förstå verksamheten.
Det är skillnaden mellan att modellera verksamheten och att konfigurera Salesforce. Om jag börjar med Salesforce-objekt har jag redan begränsat mitt tänkande till en implementation. Jag kanske hamnar precis där jag trodde, men jag vill komma dit för att verksamheten ledde mig dit, inte för att konto och kontakt var de två första objekten jag kände till.
Så glöm Salesforce i några minuter. Lyssna på hur de som faktiskt driver verksamheten beskriver sin värld.
Sitt, stanna, modellera
Section titled “Sitt, stanna, modellera ”Innan vi lyssnar på en verksamhet, låt oss lyssna på något som alla redan förstår. När jag undervisar det här live börjar jag med hundar.
Här är en hund: Marcus äger Bella. Maple Ridge Kennels födde upp henne. Hon är en labrador, och hon kan Sitt, Stanna och Tass.
Lyssna efter substantiven: Marcus, Bella, Maple Ridge Kennels, labrador, Sitt. Men det är namn: de specifika sakerna. Det jag vill ha är den sorts sak som varje namn hör till. Bella är en Hund. Marcus är en Ägare. Maple Ridge Kennels är en Uppfödare. Labrador är en Ras. Sitt är ett Trick. Fem substantiv, fem kandidatrutor.
Sedan frågan jag ställer om varje substantiv: är det en person som utför ett jobb, eller är det en bit data? Marcus är en person. Men att äga Bella är inget jobb; det är ett faktum om Bella, och förr eller senare frågar någon: ”Vem äger den här hunden?” Så Ägare hör hemma i modellen. Tränaren som lärde Bella att ge tass är en person som utför ett jobb, och behöver kanske aldrig någon ruta, om inte verksamheten börjar fråga vem som lärde ut vilket trick.
Och lägg märke till ordet kandidat. Är Ras verkligen en egen ruta, eller bara ett ord som står skrivet på hunden? Håll fast vid den frågan; vi besvarar den när vi normaliserar i modul 4.
Det är hela tekniken, på något litet. Nu lyssnar vi på en riktig verksamhet.
Substantiv ger dig kandidatentiteter
Section titled “Substantiv ger dig kandidatentiteter ”Låt oss lyssna på Steve Trucking, det familjeägda företaget som vi använder genom hela kursen. Det levererar stora varor (kylskåp, tvättmaskiner, tv-apparater) från stora detaljhandelskedjors distributionscentraler hem till folk, och installerar en del av dem.
I det första samtalet hör vi:
- Detaljhandelspartner (Retail Partner)
- Mottagare (Recipient)
- Distributionscentral (Distribution Center)
- Manifest (Manifest)
- Leverans (Delivery)
- Rutt (Route)
- Team (Crew)
- Lastbil (Truck)
Det är redan användbart. Jag kan börja sätta upp rutor på en whiteboard.
Så sätt substantiven i rektanglar. Det är allt de är i det här läget: rutor. Inga linjer, inga färger, inget som säger Salesforce. Längre fram i kursen kommer former och färger att börja betyda något. Just nu är en rektangel bara en sak som verksamheten pratar om.
Börja sedan orientera dem. När du placerar varje ruta vill du tänka på två saker: hur de hänger ihop med varandra, och vilken sorts data de är. En del är kunddata: de företag och de människor vi arbetar med. En del är transaktionsdata, som order och orderrader: de saker som händer, om och om igen. Och en del är referensdata, som de produkter eller tjänster en verksamhet erbjuder: de saker som arbetet beror på.
Hos Steve Trucking är detaljhandelspartnern och mottagaren kunddata. Manifestet, leveransen och rutten är transaktioner. Distributionscentralen, teamet och lastbilen är det som arbetet beror på.
Men det finns ett viktigt ord här: kandidat.
Ett substantiv är en ledtråd. Det är inte automatiskt en entitet, och det är definitivt inte automatiskt ett Salesforce-objekt.
När jag sitter i ett discovery-möte skriver jag ner varje substantiv. För varje substantiv de säger ställer jag mig en fråga: är det en person som utför ett jobb, eller är det en bit data? En affärsutvecklingschef är en person som utför ett jobb. Det är en användare, en roll, kanske en behörighetsuppsättning. Order, fakturor, rader: det är bitar av data. Båda spelar roll, men de hamnar på väldigt olika ställen i designen, och att sortera dem tidigt gör att jag slipper rita en ruta för varje jobbtitel i organisationsschemat.
En del av substantiven kommer att vara människor. Hos Steve Trucking är det mottagaren som väntar på kylskåpet, personerna hos detaljhandelspartnern som skickar manifestet, och teamet: förarna och medhjälparna på lastbilen. Det här är roller, och en roll kanske inte verkar vara data. Men när människor agerar på data, eller är relaterade till data, måste de själva finnas representerade i data. Vem levererade det här? Vem kvitterade? Vem skickade manifestet? Så många roller, ibland alla, hamnar också i modellen.
Lyssna på hur Steve Trucking pratar, så märker du något. De säger aldrig bara ”kund”. Det finns två sorters kunder. Detaljhandelspartnern är den stora detaljhandelskedjan som Steve Trucking levererar åt: den skickar manifestet och betalar per leverans. Mottagaren är personen som kylskåpet levereras till. Mottagaren köpte det i butiken och har kanske aldrig hört talas om Steve Trucking.
Om jag hade skrivit en ruta som hette Kund skulle jag ha blandat ihop två helt olika saker.
Kanske är distributionscentralen viktig nog att ha en egen post, historik, relationer och attribut.
Kanske visar sig ett annat substantiv inte vara något mer än ett attribut till något annat.
Det är det vi försöker upptäcka. Vi skapar inga objekt än. Vi bygger vår förståelse av verksamheten.
Lyssna nu efter relationerna
Section titled “Lyssna nu efter relationerna ”Substantiven ger mig en startpunkt. Sedan lyssnar jag på hur verksamheten kopplar ihop dem.
En detaljhandelspartner driver distributionscentraler.
En detaljhandelspartner skickar ett manifest för varje DC och leveransdag.
Ett manifest listar leveranser.
En leverans går till en mottagare.
En rutt är en dags körning med ungefär tio stopp.
Ett team på två personer kör en lastbil.
Nu händer det något. Jag tittar inte längre på en lista med substantiv. Jag börjar se en modell.
Det är också här frågorna börjar dyka upp.
Kan en detaljhandelspartner ha mer än en distributionscentral?
Är en leverans samma sak som ett stopp?
Kan ett stopp leverera till två mottagare?
Är ett team alltid samma två personer?
Bryr vi oss om vilket team som hade vilken lastbil förra månaden, eller bara vilken lastbil de kör i dag?
Lägg märke till vad vi gör. Vi ställer inga Salesforce-frågor än. Vi ställer affärsfrågor. Och de svaren kommer till slut att styra designen i Salesforce.
Din första modell behöver inte vara perfekt
Section titled “Din första modell behöver inte vara perfekt ”Jag förväntar mig inte att de första rutorna jag ritar ska överleva oförändrade. Jag skulle faktiskt bli misstänksam om de gjorde det.
Poängen med den första modellen är inte att ha rätt. Poängen är att ge oss något tillräckligt konkret för att upptäcka var vi har fel.
Sätt upp leverans, rutt, team och lastbil på tavlan, så kan folk reagera på dem.
”Faktiskt är en leverans inte alltid en enda vara. Det kan vara en tvättmaskin, en torktumlare och bortforsling av de gamla.”
Bra. Berätta mer.
”Vi tilldelar inte ett team till en leverans. Vi tilldelar teamet till en rutt.”
Utmärkt. Vad finns på rutten?
”Och om det ingår en installation kan teamet inte stänga stoppet förrän checklistan och fotona är klara.”
Nu lär vi oss något viktigt.
Ett diagram har gjort ett vagt samtal till något vi kan utmana. Det är ett av skälen till att jag gillar att modellera tidigt. Jag försöker inte imponera på rummet med ett vackert diagram. Jag försöker lära mig snabbare.
Modellen är en del av samtalet.
Det här är din konceptuella modell
Section titled “Det här är din konceptuella modell ”Det finns ett formellt namn på det vi har börjat bygga: en konceptuell datamodell.
På den här nivån är jag intresserad av de viktiga saker som verksamheten bryr sig om och hur de hänger ihop. Jag bekymrar mig ännu inte om standardobjekt eller anpassade objekt, API-namn på fält, lookup eller master-detail, obligatoriska fält, index, automatisering, Apex eller Flows. De sakerna spelar roll, och vi kommer dit. Men om vi bestämmer dem innan vi förstår vad vi modellerar löser vi fel problem först.
Den konceptuella modellen ska vara begriplig för dem i rummet som inte kan Salesforce. Det är ett användbart test. Om jag måste förklara vad Delivery__c betyder innan driftchefen kan läsa mitt diagram har jag gått in i implementationen för tidigt.
Jag vill att de tittar på modellen och säger:
”Ja, så fungerar vår verksamhet.”
Eller, ännu bättre:
”Nej, så fungerar det inte.”
För då har jag något att rätta till.
Samma teknik fungerar när ingen pratar
Section titled “Samma teknik fungerar när ingen pratar ”Det här är inte bara något jag använder när jag kartlägger hos kunder. Det fungerar också när ”kunden” är ett dokument.
När jag arbetar mig igenom ett kravdokument gör jag ungefär samma sak. Vilka är de viktiga affärsbegreppen? Vilka relationer beskrivs? Vad dyker upp gång på gång? Vad har en egen livscykel, behöver kunna identifieras för sig eller behöver historik? Vad skapas, ändras, tilldelas, överförs, schemaläggs eller pensioneras?
Det är samma saker jag lyssnar efter på det första mötet. På papper gör de ledtrådarna stycken av krav till en modell som jag kan resonera kring, och till bättre frågor inför nästa samtal.
En modell är inte bara något du tar fram efter att du har löst problemet. Den är ett av verktygen du använder för att lösa problemet.
Vad en arkitekt bestämmer här
Section titled “Vad en arkitekt bestämmer här ”När den här första genomgången är klar försöker jag avgöra:
- Vilka substantiv som representerar meningsfulla kandidatentiteter.
- Vilka olika ord som representerar samma affärsbegrepp, och vilket enskilt ord som döljer två (som ”kund”).
- Vilka begrepp som behöver en egen post och en egen livscykel.
- Hur de viktigaste begreppen hänger ihop med varandra.
- Vilka frågor verksamheten behöver besvara innan jag kan modellera dem med säkerhet.
Jag bestämmer inte implementationen i Salesforce än. Först måste vi förstå verksamheten tillräckligt väl för att kunna rita den. Och när vi väl har substantiven på tavlan är nästa sak jag vill förstå linjerna mellan dem.
Bortom provet: vad AI ändrar. Ge ett AI-verktyg ett kravdokument, så hittar det substantiven, föreslår entiteter och skissar relationer på några sekunder. Använd det för att snabba upp kartläggningen, men lägg inte ut förståelsen: det kan inte veta att ”kund” betyder två olika saker hos Steve Trucking om inte verksamheten berättar det för dig. Lägg fram dess första modell för dem som driver verksamheten och fråga: ”Är det verkligen så här er verksamhet fungerar?”