Hvornår har din virksomhed brug for et skræddersyet system, og hvornår kan de nuværende værktøjer bruges bedre?

Begynd med den seneste vanskelige sag, ikke med en funktionsliste.

Vælg en ordre, rapport eller henvendelse, hvor noget gik galt. Gennemgå forløbet: Hvor opstod informationen, hvem ændrede den, og hvornår opdagede nogen problemet? Notér også, hvad teamet måtte gøre for at rette op på situationen.

Hvis årsagen var uklart ansvar, vil et nyt program ikke afklare det af sig selv. Hvis to personer redigerede forskellige versioner af en fil, og ingen kan udpege den korrekte, kan værktøjet faktisk begrænse processen. Den skelnen beskytter dig mod blot at genskabe det samme kaos digitalt.

• Hvad skete der helt konkret?
• Hvor ofte opstår en lignende situation?
• Hvilken information eller regel kunne have forhindret den?

Første tegn: Svaret afhænger af, hvem du spørger.

Sælgeren oplyser en anden leveringsdato end planlæggeren. Lagerets beholdning stemmer ikke med kundeservices regneark. Lederen venter på den eneste person, der ved, hvor den aktuelle fil ligger. Problemet er da ikke tabellens udseende, men manglen på en fælles informationskilde.

Undersøg, om I kan udpege ét system som den autoritative kilde til hver vigtig oplysning. Nogle gange er det nok at skabe orden i de eksisterende værktøjer. Et skræddersyet modul bliver relevant, når information skal gennem flere roller, og de tilgængelige løsninger ikke kan håndtere de nødvendige ændringer og godkendelser.

• Udpeg den ansvarlige for status, frist og kundedata.
• Aftal, hvem der må ændre oplysningerne, og hvor det skal ske.

Andet tegn: Reglerne virker kun, fordi medarbejderne husker dem.

Før afsendelse skal partiet kontrolleres, efter en mængdeændring skal tilbuddet godkendes igen, og bestemte ordrer kræver et ekstra dokument. Hvis reglerne kun findes i hovedet på nogle få personer, bliver risikoen tydelig ved næste afløsning eller nye medarbejder.

Skriv betingelserne som: »Hvis X sker, har vi brug for Y.« Tilføj en undtagelse til hver regel. Først med den beskrivelse kan I vurdere, om konfiguration af et standardprodukt, en enkel automatisering eller et system med egne arbejdsgange er det rette. Ikke alle undtagelser kræver straks en selvstændig funktion; nogle kan håndteres af en person med de rette beføjelser.

Sammenlign tre veje med det samme scenarie.

Sammenlign ikke et standardprogram med en ønskeliste til jeres egen applikation. Forbered én repræsentativ proces, og afprøv den i hver mulighed: de nuværende værktøjer efter oprydning, et tilgængeligt produkt og en skræddersyet løsning. Se på manuelle omveje, dataeksport, integrationer og behovet for oplæring af teamet.

Et eget system kan tilpasses, men kræver designbeslutninger, vedligeholdelse og videreudvikling. Et standardprodukt kan få jer hurtigere i gang, men dets regler, licensomkostninger og begrænsninger skal være kendt, før I vælger. En kombineret løsning gør det ofte muligt at bevare det, der allerede virker, og kun tilføje den manglende arbejdsgang.

• Kan processen gennemføres fra start til slut?
• Hvad skal stadig udføres uden for værktøjet?
• Hvordan får vi vores data ud, og hvem skal vedligeholde løsningen?

Beregn omkostningerne ved den nuværende arbejdsform og ved den kommende ændring.

Saml eksempler fra en repræsentativ periode. Skeln mellem aktiv arbejdstid og ventetid på beslutninger. Et kvarters indtastning og flere dages ventetid er forskellige problemer, selv om begge forsinker kunden. Notér også rettelser, dubletter og situationer, som kræver flere personers deltagelse.

For den nye løsning skal du medregne analyse, udvikling, integrationer, migrering, oplæring af brugere og vedligeholdelse. Nogle gevinster handler om bedre overblik, ikke om direkte at spare en stilling. Beskriv den værdi frem for at tilskrive hver funktion et tilsyneladende præcist investeringsafkast.

Den første version skal dække én hel arbejdsgang.

I en tilbudsproces kan det være modtagelse af henvendelsen, udarbejdelse af en tilbudsversion, en beslutning og overdragelse af den godkendte sag til udførelse. Sådan en helhed kan vurderes i praksis. Skærmbilleder til kunder, dokumenter og indstillinger beviser endnu ikke systemets nytte, hvis de ikke hænger sammen.

Fastlæg, hvad der ikke indgår i første etape. Avanceret analyse kan vente, men manglende håndtering af et afvist tilbud vil sandsynligvis spænde ben for det daglige arbejde. Vælg omfang ud fra en komplet proces frem for funktioner, der ser attraktive ud under en præsentation.

• Start: Hvad sætter sagen i gang?
• Undervejs: Hvem udfører handlingen og træffer beslutningen?
• Slut: Hvilket resultat betyder, at sagen er afsluttet?

Aftal, hvem der får ansvar for systemet, før I beslutter jer.

Der skal være en person, som kan afgøre spørgsmål om processen og prioriteterne. Uden den person kan hvert nyt forslag ændre projektets retning. Inddrag også de fremtidige brugere: De undtagelser, de møder i hverdagen, findes ofte ikke i ledelsens beskrivelse.

Aftal, hvordan løsningen godkendes: nogle konkrete scenarier med forventede resultater, testpersoner og eksempeldata. Drøft opdateringer, sikkerhedskopier, adgang til dokumentation og rammerne for videreudvikling. Beslutningen om at bygge software omfatter hele brugsperioden, ikke kun dagen, hvor systemet tages i drift.