En leverantör frågar förr eller senare: vad ska systemet kunna göra? Svaret finns inte hos leverantören och inte i en lista med funktioner som andra företag redan kryssat i. Svaret finns i er egen process: vilka datapunkter ni samlar in, vem som levererar dem, varifrån de kommer, och vad som går fel om ingen tittar.
Den vanliga vägen är: välja ett verktyg, konfigurera verktyget, och först då upptäcka vilken data som ska komma varifrån. Den ordningen fungerar bakvänt, eftersom ett verktyg inte har någon uppfattning om er process. Det efterfrågar indata, och den indatan måste komma från någonstans. Om det någonstans — datapunktregistret, ägarskapet, källorna — ännu inte finns, blir konfigurationen av verktyget en sökprocess som ingen hade planerat.
Den andra ordningen börjar med processen. Först kartlägga vilka datapunkter som behövs, vem som levererar dem, från vilket system eller vilket kalkylblad de kommer, och vilka kvalitetsregler som gäller. Först därefter blir det tydligt vilka krav ett verktyg egentligen ska uppfylla. Inte abstrakta krav som "användarvänligt" eller "skalbart", utan konkreta krav som: måste kunna koppla till detta specifika källsystem, måste kunna särskilja tre ägare inom en enda datapunkt, måste kunna flagga en avvikelse om en siffra faller utanför en förutbestämd marginal.
Ordningen är inte en metodpreferens; den följer av vad som funktionellt logiskt föregår verktyget. Ett verktyg kan bara få krav när det finns något att härleda kraven från. Det något är processen: dataflödet från källa till rapport, med alla manuella steg, överlämningar och antaganden som hör därtill. Utan den överblicken sätter en organisation krav baserat på vad ett verktyg kan göra, inte baserat på vad processen behöver. Det låter som en subtil skillnad, men den avgör om verktyget senare passar in i verkligheten eller hamnar bredvid verkligheten.
Detta ansluter till frågan hur man väljer ett verktyg utan att få ånger efteråt: ånger uppstår ofta inte på grund av ett dåligt verktyg, utan på grund av ett verktyg som fick gissa sig till krav eftersom ingen hade skrivit dem ner.
Om verktyget kommer först och processen senare, uppstår två slags kostnader. Den första är direkt omkonfiguration: funktionalitet som inte passar, kopplingar som ändå måste byggas, fält som förblir tomma eftersom ingen vet vem som ska fylla i dem. Den andra kostnaden är mindre synlig men tyngre: verktyget börjar leverera rapporter som ser snyggare ut, medan siffrorna bakom dem fortfarande inte kan spåras till en källa eller en ägare. Denna risk beskrivs mer utförligt på sidan om vad det kostar att sätta ett verktyg ovanpå en oorganiserad process: verktyget döljer problemet i stället för att lösa det.
Frågan om vilken ordning som blir billigare beror på hur många datapunkter, system och ägare som redan finns och hur mycket av det som ännu inte är dokumenterat. Vid en liten process med få källor är skadan av den omvända ordningen begränsad. Vid en process som är utspridd över flera avdelningar, system och kalkylblad växer den skadan med varje datapunkt som inte är utredd innan verktyget frågar efter den. Denna avvägning är utarbetad på sidan köpa ett verktyg först eller organisera processen först: vad skillnaden kostar.
Innan ett verktyg kan få krav måste det finnas en översikt över vilka datapunkter som behövs för rapporteringen, varifrån varje datapunkt kommer, vem som ansvarar för att den är korrekt, och vilken regel som avgör om ett värde är rimligt. Den översikten är inget tekniskt dokument och inget verktyg i sig; det är ett register som utgör grunden för varje efterföljande steg, oavsett om det steget är ett verktyg, en manuell process, eller en kombination av båda.
Frågan om vilka funktionella krav som följer därav är alltså egentligen frågan: vad står i det registret, och vad saknas fortfarande? Så länge den frågan inte är besvarad förblir varje krav på ett verktyg en gissning. Detta samband mellan krav och underliggande process är vidare utarbetat på sidan om vilka funktionella krav som följer av er egen process och vad en felaktig ordning kostar i det avseendet.
När datapunktregistret och ägarskapet väl är i ordning, förskjuts frågan från vad ett verktyg ska kunna göra till vad som händer med de människor som i dag utför detta arbete: insamling, kontroll och avskrivning av siffror från kalkylblad och system. En del av dessa uppgifter är repetitiva och följer fasta regler, och det är precis den typ av arbete som delvis kan tas över av AI. [Arbetsanalysen från FTE TO AI](https://ftetoai.nl) beräknar per uppgift hur stor del av den som kan automatiseras, så att det blir tydligt var människor fortfarande behövs och var arbetet kan överlämnas till ett system som kontrollerar och levererar enligt fasta 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.