En leverandør spørger før eller siden: hvad skal systemet kunne? Svaret ligger ikke hos leverandøren og heller ikke i en liste med funktionaliteter, som andre virksomheder også har afkrydset. Svaret ligger i Deres egen proces: hvilke datapunkter De indsamler, hvem der leverer dem, hvor de kommer fra, og hvad der går galt, hvis ingen holder øje.
Den almindelige vej er: vælge et værktøj, indrette værktøjet, og først derefter opdage hvilke data der skal komme hvorfra. Den rækkefølge virker mod hensigten, fordi et værktøj ikke har nogen mening om Deres proces. Det efterspørger input, og det input skal komme fra noget. Hvis det noget — datapunktregistret, ejerskabet, kilderne — endnu ikke findes, bliver indretningen af værktøjet en søgeproces, som ingen havde planlagt.
Den anden rækkefølge starter ved processen. Først kortlægges hvilke datapunkter der er nødvendige, hvem der leverer dem, hvilket system eller hvilket regneark de kommer fra, og hvilke kvalitetsregler der hører til. Først derefter bliver det tydeligt, hvilke krav et værktøj egentlig skal opfylde. Ikke abstrakte krav som "brugervenligt" eller "skalerbart", men konkrete krav som: skal kunne kobles til dette specifikke kildesystem, skal kunne skelne tre ejere inden for ét datapunkt, skal signalere en afvigelse, hvis et tal falder uden for en forudbestemt margin.
Rækkefølgen er ikke en metodepræference; den følger af det, der funktionelt logisk går forud for værktøjet. Et værktøj kan først få krav, når der er noget at udlede kravene af. Det noget er processen: strømmen af data fra kilde til rapport, med alle de manuelle trin, overdragelser og antagelser, der hører med. Uden det overblik opstiller en organisation krav baseret på, hvad et værktøj kan, ikke baseret på, hvad processen har brug for. Det lyder som en subtil forskel, men den afgør, om værktøjet senere passer til virkeligheden eller kommer til at stå ved siden af den.
Dette hænger sammen med spørgsmålet om hvordan De vælger et værktøj uden fortrydelse bagefter: fortrydelse opstår ofte ikke på grund af et dårligt værktøj, men på grund af et værktøj, der måtte gætte krav, fordi ingen havde skrevet dem ned.
Hvis værktøjet kommer først og processen senere, opstår der to slags omkostninger. Den første er direkte omindretning: funktionalitet der ikke passer, koblinger der alligevel skal bygges, felter der forbliver tomme, fordi ingen ved, hvem der skal udfylde dem. Den anden omkostning er mindre synlig, men tungere: værktøjet kommer til at levere rapporter, der ser pænere ud, mens tallene bagved stadig ikke kan spores tilbage til en kilde eller en ejer. Den risiko er beskrevet mere udførligt på siden om hvad det koster at placere et værktøj oven på en uorganiseret proces: værktøjet skjuler problemet i stedet for at løse det.
Spørgsmålet om hvilken rækkefølge der bliver billigst, afhænger af, hvor mange datapunkter, systemer og ejere der allerede findes, og hvor mange af dem der endnu ikke er dokumenteret. Ved en lille proces med få kilder er skaden ved den omvendte rækkefølge begrænset. Ved en proces der er spredt over flere afdelinger, systemer og regneark, vokser den skade med hvert datapunkt, der ikke er afklaret, før værktøjet efterspørger det. Denne afvejning er uddybet på siden først købe et værktøj eller først indrette processen: hvad den forskel koster.
Før et værktøj kan få krav, skal der være et overblik over, hvilke datapunkter der er nødvendige for rapporteringen, hvor hvert datapunkt kommer fra, hvem der er ansvarlig for rigtigheden, og hvilken regel der afgør, om en værdi er sandsynlig. Det overblik er ikke et teknisk dokument og heller ikke et værktøj i sig selv; det er et register, der danner grundlaget for ethvert efterfølgende skridt, uanset om det skridt er et værktøj, en manuel proces, eller en kombination af begge.
Spørgsmålet om hvilke funktionelle krav der følger deraf, er altså egentlig spørgsmålet: hvad står der i det register, og hvad mangler der stadig? Så længe det spørgsmål ikke er besvaret, forbliver ethvert krav til et værktøj et gæt. Denne sammenhæng mellem krav og bagvedliggende proces er uddybet på siden om hvilke funktionelle krav der følger af Deres egen proces, og hvad en forkert rækkefølge koster.
Når datapunktregistret og ejerskabet først er på plads, flytter spørgsmålet sig fra, hvad et værktøj skal kunne, til hvad der sker med de mennesker, der udfører dette arbejde nu: indsamling, kontrol og indtastning af tal fra regneark og systemer. En del af disse opgaver er repetitive og følger faste regler, og det er netop den slags arbejde, hvoraf en del kan overtages af AI. [Arbejdsscanningen fra FTE TO AI](https://ftetoai.nl) beregner for hver opgave, hvor stor en del af den der kan automatiseres, så det bliver tydeligt, hvor mennesker fortsat er nødvendige, og hvor arbejdet kan overdrages til et system, der kontrollerer og leverer efter faste regler.
Vraag maar waar een datapunt vandaan komt. Dat is meestal de hele vraag.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.