Efter EFI-skandalen: Trusler og fordomme ender med elendige it-løsninger

Enig eller ej, så er der rigtigt mange spændende signaler i sådan en udtalelse.

For mig at se især fordi fleksibilitet og agilitet er ønsker, som udspringer direkte fra forretningen, og det er endnu et symptom på, at der sker et skift i it-udviklingen.

Det er i stigende grad forretningen, som bliver den centrale drivkraft, når fremtidens it-strategi skal lægges. Dette ligger fuldstændigt i tråd med tendensen til, at stadig flere virksomheder reorganiserer it-afdelingen for at kunne leve op til de nye krav, og at CIO'er bliver mere forretningsmindede og centrale i udviklingen af kerneforretningen. 

En ting er dog, at diverse trendspottere rundt i verden bemærker denne tendens. En anden ting er, hvad den i praksis betyder for it-udviklingen.

Den betyder, at vi leverandører får en helt ny type kunde. Man kan måske ligefrem sige, at vi har fået den rette kunde. For det nytter ikke at sætte en mur af teknik og kravsspecifikationer op mellem et produkt og den person, som sidder med behovet. 

At fejle teknisk kontra at fejle logisk 

Det er vigtigt her, at man erkender, at it-udvikling består af både en teknisk del og en logisk/forretningsmæssig/behovsmæssig del. Og at synergien mellem disse er afgørende.

På hver side og i overgangen mellem dem er der et hav af sikkerheder, variabler, spørgsmål og usikkerheder. Dem skal vi kunne afklare sammen undervejs, ellers fejler vi.

Tag nu SKATs EFI. Der har været mange forskellige forklaringer, anklager og bud på løsninger ude i medierne.

LA's skatteordfører, Merete Riisager, udtaler til Computerworld, at løsningen i fremtiden kunne være ikke at betale, før produkter er leveret og virker.

Det er en voldsom reducering af projekter til, at det kun er teknik, der fejler. Udover at jeg som leverandør ikke kunne drømme om at byde på et projekt, hvor jeg alene bar risikoen (også for fejl begået hos kunden) og rent økonomisk skulle lægge ud for staten i et antal år, til produktet var leveret (hvilket kan blive konsekvensen), så tager løsningen slet ikke hånd om den forretningsmæssige del, hvor ansvaret i høj grad ligger på begge sider.

Det viser sig jo, at man groft har fejlberegnet kompleksiteten i det system, man skulle udvikle. En regel om, at der ikke sendes opkrævninger ud, som er forældede, er formodentlig en ret simpel ting rent teknisk at lave, hvis man ved, den skal laves. Det er næppe leverandøren, der har fejlet i dette tilfælde.

En del af Computerworlds læsere lader til at mene, at det er i leverandørers interesse at fejle, fordi de så kan opkræve flere penge. Det er en grov og urimelig forsimpling.

Alle leverandører vil gerne ind i den positive cirkel, hvor vi leverer succes, får gode referencer, nye kunder og glade medarbejdere (for de bedste gider bestemt ikke i længden levere bras, og der er kamp om dem).

Men vi er afhængige af, at vi kan få de rette data i rette kvalitet, og at vi kan behovsafdække og designe systemerne, så de passer til deres formål. Vi kan ikke bare overtage en kravsspecifikation og sende arme og ben ud for at producere kode. Det er langt mere komplekst end dette. Vi bygger ikke møbler; vi bygger forandring.

Dette indlæg er hverken ment som forsvar eller anklage. Eksemplet med SKAT er alene fremhævet, fordi det ligger nært i hukommelsen netop nu. Det er et opråb om, at vi naturligvis finder ud af, hvor det gik galt, men samtidig også bevarer fokus på, hvordan vi kan lykkes sammen i fremtiden. 

"Skru bissen på"-holdningen holder kun rent retorisk. I praksis handler det om at forene produkt og behov, og dét handler om samarbejde. Ikke gennem trusler, men gennem bedre kommunikation, forventningsafstemning og planlægning.

Det handler om at bygge tillid på fælles successer og tage ansvar for hver sin del - og for selve samarbejdet. Vi skal bygge broer, ikke fæstninger

Her har vi erfaret, at det både er værktøjer, metoder og medarbejdere, vi kan skrue på. Her er et par eksempler:

Værktøjer: Vi bruger interaktive mock-ups til at forventningsafstemme. Vi nøjes ikke med wireframing, vi tegner faktisk hele den grafiske brugerflade op og gør de vigtigste elementer klikbare. Dette træder i stedet for kravsspecifikationen, når vi forhandler med forretningen.

Det vil sige, at vi fra starten mødes om resultatet, og at vi aldrig fortaber os i diskussioner om data. Dem tager vi med andre dele af virksomheden.

Metoder: Vi arbejder meget i workshops, før vi afgiver bud på noget. Det er vi ikke ene om. Vi sørger dog meget for indholdsmæssigt at tale forretning.

Der er for eksempel mange virksomheder, som ikke har et klart overblik over deres værdikæde. Så sætter vi et par timer af, får den tegnet op og kortlagt systemerne under den og får på den måde koblet it på.
 

På medarbejdersiden vil jeg nødigt reducere noget til et punkt - heller ikke blot som eksempel - for det er uden tvivl her, det hele skal mødes.

UX-designere og forretningskonsulenter har naturligt fået en voksende rolle, ligesom dygtige projektledere er helt uundværlige. 

Medarbejdere skal dog forstås på begge sider af kunde/leverandør-forholdet. Her skal vi være meget opmærksomme på, at det team, vi sætter, er det rette.

Man skal passe på med blot at spejle det interne ledelseshierarki i projektorganisationen, som jeg tror, der kan være en tendens til. Mere om det en anden gang.

Det var blot nogle af vores metoder til bygge bro mellem forretning og it. Jeg håber, vi kan få en mere konstruktiv debat, hvor vi ikke forfalder til generaliserende og fordomsfuld kritik, men i stedet kan snakke om problemets kerne og løsningerne.

At læne sig tilbage og stoppe al udvikling for ikke at fejle igen er i hvert fald en meget dårlig løsning.