Skriv ned hva piloten faktisk viste
Skill mellom det dere vet om modellen, brukeropplevelsen og den tekniske løsningen. Kanskje modellen laget gode utkast med nøye utvalgte kilder, men dere testet ikke hvor ofte de virkelige kildene mangler. Kanskje de ansatte likte forslaget, men brukte like lang tid på å kontrollere det som på å gjøre jobben selv.
Lag også en liste over det piloten ikke testet: pålogging, tilgangsstyring, personopplysninger, svartid, kostnad, mange samtidige brukere, tekniske feil og ansvar for oppdateringer. Dette er arbeid som må planlegges, ikke detaljer som ordner seg ved lansering.
Plasser løsningen der arbeidet skjer
Bestem hvor de ansatte eller kundene møter funksjonen, hvordan riktig informasjon hentes inn, og hva som skjer etter at løsningen har laget et forslag. Gjør det enkelt å se kildene, rette innholdet og sende vanskelige saker til en ansatt.
Unngå en ny portal hvis arbeidet naturlig hører hjemme i kundesystemet, publiseringsløsningen eller den digitale tjenesten dere allerede har. Hver ekstra innlogging og kopiering mellom systemer gjør det mindre sannsynlig at løsningen blir brukt.
Planlegg det som kreves i produksjon
- Hvem får tilgang til hvilke kilder og funksjoner?
- Hva logges, og hvem følger opp feil og kostnader?
- Hvilke tester må bestås før en ny versjon tas i bruk?
- Hva ser brukeren ved manglende kilde, lang ventetid eller teknisk feil?
- Hvem oppdaterer innhold, instruksjoner og testeksempler?
Fordel ansvaret mellom produkteier, fagansvarlig og teknisk ansvarlig. Navnene vil variere, men oppgavene må ha eiere før løsningen åpnes for flere.
La en liten gruppe bruke løsningen først
Start med ansatte som kjenner bruksområdet og kan beskrive presist hva som er feil. Gi dem opplæring i hva løsningen kan gjøre, hva de skal kontrollere, og hvordan de melder fra om problemer. Følg med på hvilke forslag de bruker, retter og forkaster.
Rett alvorlige og gjentatte feil før dere utvider. Når flere får tilgang, bør dere vite hvem som svarer på spørsmål, hvor feil rapporteres, og hvordan en tidligere versjon kan gjenopprettes hvis en endring gjør løsningen dårligere.
Sett av ansvar og tid til forbedring
Noen må holde kildene oppdatert, vedlikeholde testsettet og vurdere om endringer i modell eller leverandør påvirker kvaliteten. Uten navngitt ansvar vil en god pilot gradvis bli mindre pålitelig.
Jeg kan bistå hele veien fra idé og prototype til en løsning som blir utviklet, tatt i bruk og fulgt opp over tid, i samarbeid med fagfolkene og utviklerne deres. Målet er en løsning som fungerer i det daglige arbeidet, ikke en pilot som blir stående alene.