Forestil dig et byggeri hvor arkitekten aldrig har sat fod på byggepladsen. Vedkommende har set grundplanen, kender målene og har tegnet en løsning der ser fantastisk ud på papiret. Men arkitekten ved ikke at grunden skråner mod øst, at der er en vandledning tæt under overfladen, eller at naboens garage stikker halvanden meter ind over det der på matrikelkortet ser ud som fri passage.
Håndværkeren ved alt det. Men håndværkeren har aldrig set tegningen i sin helhed.. kun de enkelte arbejdsbeskrivelser der kommer færdigbagte, én ad gangen. Så håndværkeren bygger præcis det der står. Og tre uger inde i projektet opdager alle at fundamentet skal flyttes, fordi ingen kombinerede arkitektens overblik med håndværkerens viden om terrænet.
Det er ikke et byggeri-problem. Det er præcis hvad der sker i Business Central-branchen.
Da NAV-konsulenten kunne det hele
Der var engang hvor én person løftede begge roller. Dengang hed systemet Dynamics NAV, og den typiske konsulent sad med til mødet hos kunden, forstod forretningsprocessen, gik hjem og kodede løsningen, og kom tilbage og satte den i drift. Samme person. Arkitekt og håndværker i én (og ja, koden var nok ind imellem også derefter).
Det fungerede, men Business Central er blevet et langt mere komplekst system end NAV var. Kravene til forretningsforståelse og teknisk dybde er vokset så meget at det sjældent giver mening at pakke det hele ind i én person. Derfor har de fleste BC-partnere i dag splittet rollen op: en forretningskonsulent (konsulent) der forstår processerne, og en teknisk konsulent (udvikler) der bygger tilpasningerne.
Det er i sig selv fornuftigt. Specialisering giver dybde. Men det har haft en utilsigtet konsekvens som vi i branchen ikke taler nok om.
Udvikleren forsvandt fra samtalen
Da rollerne blev splittet, skete der noget som ingen havde planlagt. Den tekniske konsulent (udvikleren) rykkede væk fra bordet. Ikke som en bevidst beslutning, men som en langsom glidning. Udvikleren gik fra at sidde i mødelokalet og høre kundens udfordringer direkte, til at sidde i et andet lokale (eller en anden by) og modtage en beskrivelse af hvad der skal bygges.
I byggeri-analogien: arkitekten og håndværkeren holder op med at mødes på pladsen. I stedet sender arkitekten tegninger, og håndværkeren bygger efter dem. Det er mere effektivt.. på papiret. I praksis mister man noget der er svært at sætte ord på. Håndværkeren ser ikke længere terrænet. Arkitekten hører ikke længere de problemer håndværkeren støder på. Og kunden (bygherren) sidder i midten og undrer sig over hvorfor tingene ikke blev som forventet.
I min optik er det den største usynlige risiko i BC-projekter i dag. Ikke dårlige specifikationer, ikke manglende test, ikke forkert kode. Det er at de tre roller (kunde, konsulent og udvikler) der skal samarbejde tættest er endt med at sidde længst fra hinanden.
Telefon-legen
Kender I legen fra børnefødselsdage? Én hvisker en sætning til den næste, og når den når den sidste i rækken, er budskabet et helt andet.
I et BC-projekt ser den sådan ud. En lagermedarbejder har et problem, det tager tyve minutter hver morgen at tjekke om gårsdagens varetilgange er bogført korrekt, fordi der ind imellem mangler en dimension på indkøbslinjerne. Lagermedarbejderen fortæller det til virksomhedens product owner/superbruger/ERP Ansvarlig. Superbrugeren beskriver det til forretningskonsulenten. Forretningskonsulenten formulerer en løsning og sender den til udvikleren. Og udvikleren bygger præcis det der står: en validering der kræver at dimensionen er udfyldt.
To uger senere ringer lageret igen. Valideringen virker, men nu kan indkøberne ikke oprette linjer på rammeordrer hvor dimensionen først kendes ved levering. Det var noget “alle vidste”, undtagen udvikleren, der aldrig har set indkøbs flowet i praksis.
Og jo hurtigere det skal gå, jo mere forsvinder der i oversættelsen. Når et projekt er under tidspres, bliver specifikationerne kortere, møderne færre og antagelserne flere. Det er præcis i de situationer at telefon-legen gør mest skade — fordi det er der vi har mindst tid til at rette op.
Der er ingen plads til at prøve sig frem
Det andet der går tabt er muligheden for at bygge noget, vise det frem og justere. I den gamle NAV-verden kunne konsulenten lave en hurtig prototype, vise den til lageret, få feedback og rette til, alt sammen inden for en dag. Det var rodet, men det fungerede, fordi den der byggede også var den der hørte feedbacken.
Det skal ikke være smukt, det skal være færdigt.
I dag er processen mere formel: specifikation, godkendelse, udvikling, test, levering. Og struktur er godt, jeg er ikke ude på at vi skal tilbage til det gamle. Men når udvikleren aldrig er i rummet med de folk der bruger systemet, forsvinder muligheden for det der øjeblik hvor nogen fra lageret kigger på en halvfærdig løsning og siger:
“Ja, men hvad med når vi modtager varer fra den svenske leverandør? Der bruger vi altid en anden lokation.”
Den slags opdagelser sker ikke i en specifikation. De sker når nogen ser noget konkret og reagerer. Og de sker kun hvis udvikleren er tæt nok på virkeligheden til at vise noget halvfærdigt, og kunden er tæt nok på udvikleren til at reagere ærligt.
Tættere sammen, ikke smeltet sammen
Jeg siger ikke at vi skal rulle specialiseringen tilbage. Forretningskonsulenten og udvikleren er to forskellige roller af gode grunde. Men vi er nødt til at rykke lidt mere ind over hinandens banehalvdel.
Det betyder at udvikleren skal tilbage til bordet. Ikke til alle møder, men til de rigtige, når en proces skal designes, når der testes, og når kundens folk viser hvordan de faktisk arbejder, ikke hvordan proceduren siger de burde arbejde. En udvikler der har set en lagermedarbejder scanne varer klokken 06.30 forstår konteksten på en måde som ingen specifikation kan beskrive.
Og det betyder at forretningskonsulenten skal tættere på teknikken. Ikke at konsulenten skal skrive kode, men at vedkommende skal vide nok om hvad der er nemt og svært at bygge til at specifikationerne afspejler virkeligheden. Hvis konsulenten ved at Business Central allerede har en leveringstidsberegning på varekortet, debitoren og lokationen, så skriver vedkommende en helt anden specifikation. For så kan konsulenten stille det rigtige spørgsmål: “Skal vi overskrive den eksisterende beregning, eller bygge videre på den?”
Det er ligesom byggeriet. De bedste resultater kommer ikke af at arkitekten og håndværkeren er den samme person. De kommer af at arkitekten har stået på pladsen og kender terrænet, og håndværkeren har set tegningen og forstår helheden. Overlappet er det der gør forskellen, ikke at rollerne forsvinder.
Det handler om at opleve hinandens problemer
Det hele koger ned til noget simpelt: vi er nødt til at opleve hinandens virkelighed. Ikke bare læse om den i et dokument.
Når forretningskonsulenten aldrig ser hvad der sker når specifikationen rammer udvikleren (alle de spørgsmål der ikke er besvaret, de edge cases der ikke er beskrevet, de antagelser der skal gættes) så fortsætter konsulenten med at skrive specifikationer på samme måde. Og når udvikleren aldrig ser den frustration en lagermedarbejder har over et system der ikke passer til virkeligheden, så bygger udvikleren noget der teknisk fungerer men ikke løser det egentlige problem.
Vi er nødt til at opleve hinandens hverdag oftere. Udvikleren skal med ud til kunden. Konsulenten skal se koden tage form (og forstå hvorfor udvikleren bander over en specifikation der mangler tre afgørende detaljer).
For det bedste ERP-samarbejde opstår ikke i overlevering. Det opstår i overlap, når vi spiller på samme hold.
