God software begynder med at forstå dit arbejde.

01. Vi lærer arbejdet at kende indefra.

Den første samtale handler om den situation, du vil ændre. Hvad forsinker arbejdet? Hvor opstår der rettelser? Hvilke oplysninger mangler den, der skal træffe en beslutning? Derefter gennemgår vi en konkret sag med de mennesker, der håndterer den. Både lederens og medarbejderens perspektiv hjælper os med at se den samme proces fra flere sider.

I en stor organisation kan én ordre eller ét dokument passere gennem flere afdelinger. Vi leder efter de steder, hvor ansvaret skifter, arbejdet venter, eller sammenhængen går tabt. Det er ofte netop dér, den største mulighed for at forenkle arbejdet findes.

• Projektets mål og den måde, opgaven løses på i dag.
• De mennesker, der skal bruge løsningen og træffe beslutninger.
• Det mest almindelige forløb og de situationer, der skaber problemer.

02. Vi afklarer regler, data og den første afgrænsning.

Vi beder om repræsentative eksempler: en formular, et dokument eller en oversigt, hvor personoplysninger og unødvendige fortrolige oplysninger er fjernet. Vi ser ikke kun på det korrekte forløb, men undersøger også mangler, gentagelser og rettelser. Vi aftaler, hvem der må ændre data, og hvornår en godkendelse er nødvendig.

Vi vælger en lille, men komplet del af processen. Den skal have en begyndelse, et forløb og et brugbart resultat. Den afgrænsning gør det muligt at afprøve løsningen i praksis. Vi beskriver også afhængighederne og de dele, vi bevidst udskyder til senere.

• Hvad sætter en sag i gang, og hvordan ved vi, at den er afsluttet?
• Hvem har ansvaret for de enkelte oplysninger?
• Hvordan håndterer vi en undtagelse eller en beslutning, der trækkes tilbage?

03. Vi afprøver idéen med en prototype.

Vi skitserer de vigtigste skærmbilleder og gennemgår den kommende brugers opgaver. Forstår brugeren status? Kan vedkommende finde dokumentet? Er det tydeligt, hvorfor en handling ikke er mulig? Her undersøger vi sproget, rækkefølgen af handlinger og de oplysninger, der er nødvendige for at træffe beslutninger.

Prototypen giver et grundlag for at tale om arbejdsgangen. Den foregiver ikke at være et færdigt system: Reelle integrationer, adgangsstyring og lagring af data skal udvikles og testes. Vi omsætter konklusionerne til et omfang, der kan bygges og godkendes.

04. Vi bygger løsningen sammen med dens integrationer.

Vi forbinder grænsefladen med regler, data og de nødvendige systemer. Vi undersøger adgangen til API'er, dokumentation og miljøer, før vi forudsætter fuld udveksling af oplysninger. Vi aftaler, hvilket værktøj der er datakilden, og hvordan forbindelsen skal reagere ved afbrydelser eller gentagne hændelser.

Vi udvikler projektet i aftalte dele, som kan vises og afprøves. Nye idéer registreres og vurderes i forhold til målet. En vigtig ændring kan dermed bevidst påvirke omfanget i stedet for ubemærket at ændre forventningerne til tid og pris.

05. Vi tester også det, der kan gå anderledes.

Vi kontrollerer de scenarier, vi aftalte under analysen: det korrekte forløb, manglende data, forkerte rettigheder og usædvanlige beslutninger. Ved integrationer tester vi gentagne forsøg og utilgængelige kilder. Ved datamigrering sammenligner vi oplysningerne for at bekræfte, at de har bevaret deres betydning.

Brugerne får mulighed for at afprøve væsentlige opgaver i den sammenhæng, de skal arbejde i. En applikation på en telefon kræver et andet blik end et system, der bruges ved skrivebordet. Acceptkriterierne knyttes til konkrete resultater og det aftalte omfang.

• Kan brugeren afslutte den relevante opgave?
• Kan brugeren kun se og ændre de oplysninger, vedkommende har adgang til?
• Er en fejl forståelig, og findes der en aftalt vej til at håndtere den?

06. Vi sætter løsningen i drift på virksomhedens præmisser.

Hvis processen tillader det, begynder vi med en pilot for en udvalgt gruppe eller en del af dataene. Det giver mulighed for at sammenligne arbejdet med det hidtidige forløb og justere detaljerne, inden flere får adgang. Ellers planlægger vi et aftalt tidspunkt for overgangen og en fremgangsmåde ved eventuelle problemer.

Inden afleveringen aftaler vi ansvar, information til brugerne og håndtering af henvendelser. Rettigheder til kode, adgang, dokumentation og vilkår for overdragelse følger kontrakten og det aftalte omfang. Vi drøfter dem på forhånd, så virksomheden ved, hvad den modtager, og hvordan løsningen kan videreudvikles.

07. Vi vurderer effekten og planlægger de næste skridt.

Vi vender tilbage til det problem, vi begyndte med. Vi undersøger tidsforbruget på opgaven, ventetiden, antallet af rettelser eller et andet kriterium, vi valgte på forhånd. Ikke enhver gevinst behøver at være en graf: Et vigtigt resultat kan være at kunne finde en status uden at opspore den person, der kender svaret.

Vedligeholdelse, sikkerhedskopier, overvågning, opdateringer og håndtering af henvendelser fastlægges som en del af det aftalte samarbejde. Nye moduler tager udgangspunkt i brugernes erfaringer og virksomhedens prioriteter. På den måde følger udviklingen reelle behov, mens den grundlæggende proces forbliver under kontrol.