Vi tester, når en kunde kræver det

I nogle virksomheder er der én fast anledning til at bestille en sikkerhedstest: en kunde, der beder om det. Det er en ærlig og forståelig praksis. Kunden betaler for virksomhedens ydelser, kravet er konkret, og testen har et klart formål. Men når kundekravet er den eneste grund, svarer testen på kundens spørgsmål og ikke på ledelsens egne. Det, kunden ikke spørger til, bliver ikke afprøvet, og tidspunktet bestemmes af andre end virksomheden. Det behøver ikke at være forkert, men ledelsen bør vide, hvad den fravælger.

Hvorfor praksis opstår

Der er gode grunde til at lade kunderne sætte dagsordenen. En test koster tid og penge, og et kundekrav gør det let at begrunde udgiften. Salget kan pege på en konkret ordre, som står på spil. Og ledelsen slipper for selv at skulle afgøre, hvornår og hvad der skal testes.

Hertil kommer, at kravet kan følge med en tidsfrist og en beskrivelse af, hvad kunden vil se. Det gør opgaven overskuelig. Ingen behøver drøfte, hvad virksomheden selv er mest bekymret for. Praksis er altså ikke udtryk for ligegyldighed, men for, at kundens spørgsmål er det mest presserende, der ligger på bordet.

Kundens spørgsmål er ikke jeres

En kunde, der beder om en test, vil have svar på, om det, kunden selv bruger, er beskyttet. Det er et rimeligt spørgsmål, men det er kundens. Virksomhedens egne spørgsmål kan være nogle helt andre:

Det, kunden ikke ser · interne systemer, økonomi, produktion og de ansattes adgange.
Det, flere kunder deler · fælles platforme, hvor et problem rammer alle på én gang.
Det, forretningen står og falder med · systemer, hvis nedbrud ville standse virksomheden.
Det, der er ændret · nye løsninger og leverandører, som ingen kunde har spurgt til endnu.

Når kun kundens spørgsmål bliver besvaret, kan virksomheden have en pæn rapport til kunden og samtidig mangle viden om det, der ville gøre mest skade. → Kronjuvelerne

Tidspunktet bliver styret udefra

Når testen bestilles, fordi en kunde beder om det, kan den blive bestilt i en fart. Kunden har en frist, ordren venter, og der er ikke tid til at overveje omfanget. Det kan føre til tre ting, ledelsen bør være opmærksom på:

Omfanget bliver snævert · der testes det, kunden kræver, og ikke mere.
Rettelserne får ikke plads · fundene skal helst være rettet, før rapporten sendes, men ingen har afsat tid til det.
Prisen bliver højere · en test, der skal laves hurtigt, kan koste ekstra.

Hvis kundekrav er den eneste anledning, kan virksomheden komme til at betale for hast igen og igen uden at få det overblik, en planlagt test ville have givet. Hvad der påvirker omfanget og prisen, kan ledelsen se under pris og tilbud. → Hastetest

Fra reaktion til plan

Ledelsen behøver ikke afvise kundekravene for at ændre praksis. Den kan bruge dem som en del af en plan, der også dækker virksomhedens egne behov. Det kræver et par beslutninger:

En egen liste over vigtige systemer · de systemer, ledelsen vil have afprøvet, uanset om nogen spørger.
En rytme · en plan for, hvornår de afprøves, så testen ikke kun sker under pres.
Kundekrav lagt ind i planen · når en kunde spørger, kan kravet måske dækkes af en test, der allerede er planlagt, eller ved at udvide den.
Plads til rettelser · budget og tid, så fund kan rettes, før rapporten skal bruges.

På den måde kan en test betale sig to gange: den besvarer kundens spørgsmål og ledelsens egne. → Kundekrav eller egne behov

Spørgsmål, ledelsen kan stille sig selv

Før ledelsen ændrer noget, kan det være nyttigt at se ærligt på den nuværende praksis. Et par spørgsmål kan bringe det frem, som kundekravene har skjult:

Hvornår blev der sidst testet uden en kunde bag? · hvis svaret er aldrig, er det i sig selv en oplysning.
Hvad ville vi teste, hvis ingen kunde spurgte? · svaret viser ledelsens egne prioriteringer.
Hvilke af vores vigtigste systemer har aldrig været med? · det er de blinde pletter.
Hvad har hasten kostet? · både i penge og i rettelser, der ikke nåede at komme med.

Spørgsmålene kræver ikke teknisk viden. De kræver, at ledelsen tager stilling til, hvad virksomheden selv vil vide om sin sikkerhed. Svarene kan bruges som grundlag for en plan, og de kan tages op igen, når planen skal evalueres. Hvis svarene viser, at kunderne i praksis har styret alt, er det ikke en fejl, nogen skal stå til ansvar for. Det er et udgangspunkt for at gøre det anderledes. → Spørgsmål til ledelsen selv

Et tænkt eksempel

Et rengøringsfirma med et digitalt system til planlægning af opgaver har testet systemet to gange, begge gange fordi en stor kunde i ejendomsbranchen krævede det inden kontraktfornyelse. Testene har handlet om den kundeportal, kunden bruger.

Ved en strategidrøftelse spørger et bestyrelsesmedlem, hvornår lønsystemet og medarbejdernes app sidst blev afprøvet. Ingen kan svare. Direktionen udarbejder en liste over de systemer, som virksomheden selv er mest afhængig af, og en plan for at afprøve dem over de næste år. Kundeportalen bliver en del af planen, så den næste test kan bestilles i god tid før kontraktfornyelsen. Lønsystemet bliver testet først, fordi det rummer oplysninger om alle medarbejdere. Direktøren aftaler med bestyrelsen, at planen gennemgås én gang om året, og at et nyt kundekrav ikke længere er den eneste vej til en test.

Det skal I lade være med

At lade kunderne bestemme alt, der bliver testet · I kender jeres egne risici bedst.
At bestille i sidste øjeblik hver gang · planlæg, så hast bliver undtagelsen.
At bruge kundens rapport som svar på jeres egne spørgsmål · den dækker det, kunden spurgte til.
At glemme interne systemer · de er også en del af virksomhedens risiko.
At sende en rapport, før fundene er håndteret · afsæt tid til rettelser.

Hvad kan og ikke kan konkluderes

En test, der er bestilt på grund af et kundekrav, giver et svar på det, kunden spurgte til, og kan være et godt grundlag for kunden. Den siger ikke noget om de dele af virksomheden, der lå uden for kravet. Når kundekravene indgår i en plan, ledelsen selv har lagt, kan de samme penge give både kunden og ledelsen et svar. → Hvem bestemmer, hvor ofte vi tester?