Dette indlæg er alene udtryk for skribentens egen holdning.

Vision - billigt til salg

1. februar 2012 kl. 15:1918
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

Så er den gal igen. Et offentligt IT-system er forsinket og budgetterne er igen overskredne. Aktørerne har vi lissom også set før: CSC og Skat.

Denne gang er omkostningerne ved forsinkelsen dog endnu mere tydelige end vi er vant til. Systemet er hjørnestenen i den fremtidige offentlig gældsinddrivelse.

I Politiken fra den 24 januar fremgår det at EFI systemet, der skulle have været idriftsat i 2009, er helt nødvendigt for at det offentlige kan inddrive de svimlende 72,9 milliarder som der er ude at svømme.

Således burde det være relativt nemt at beregne systemets "cost of delay". Hvad koster det samfundet måned for måned, hvor systemet stadig ikke er i drift? Hvilke renter løber der på og hvilke offentlige services bliver beskåret, fordi der mangler penge i kassen? Hvilke fordringer bliver endnu sværere eller sågar måske helt umulige at inddrive, fordi der går så lang tid fra restancens opståen, til den bliver forsøgt kradset ind?

Artiklen fortsætter efter annoncen

Her følger et fempunktsprogram, der måske kunne være til lidt inspiration, hvis der skulle være nogle embedsmænd og politikere der endnu ikke har givet helt op, og oprigtigt ønsker at stoppe det utrolige spild af skatteborgernes penge vi igen og igen er vidner til.

1. Find en bedre måde at lave kontrakter på: Giv juristerne til opgave at finde en måde at indgå aftaler, som sikrer at projektet har en ligeligt fordelt risiko mellem leverandør og kunde og animerer til samarbejde, istedet for den kamp der finder sted idag, hvor de to parter står overfor hinanden som antagonister. Det findes faktisk fremsynede jurister der har nogle bud på dette.

2. Udvælg leverandører på andet end pris og undgå dem der ikke kan levere. Sæt evt. at andet hold jurister til at finde ud af, hvordan det kan gøres indenfor de eksisterende regler. For selvfølgelig kan det lade sig gøre. Det er nu engang ikke røde blyanter, vi skal have til den billigst mulige pris. Sørg først og fremmest for at få op løst for den helt uholdbare situation, hvor en række store leverandører, som mest minder om Dinosaurer, igen og igen påtager sig opgaver de ikke kan løse.

3. Forlang bedre kvalitet fra starten. Myten om, at det ikke er muligt at lave IT-systemer der ikke er fulde af fejl skal udryddes og der skal være et større incitament til at levere ordentligt kvalitet, end til at overholde en ligegyldig milepæl. Dårlig kvalitet koster altid og er ikke noget man kan ofre for at levere hurtigere.

Artiklen fortsætter efter annoncen

4. Dekomplicér opgaven. Man har ofte på fornemmelsen at IT-branchen har en overvægt af folk, der ser det som deres fornemste opgave at gøre ting mere komplicerede, end de behøver at være. Det er en uskøn blanding af folk der tror, at man kun kan få et godt system, ved at have skrevet hver eneste lille detalje og krølle ned i en omfattende kravspecifikation, og IT- og Enterprise arkitekter, der hjernevasket på fine konferencer afholdt af Oracle, Microsoft og IBM, tror at man absolut skal anvende den nyeste (næppe afprøvede) teknologi, som de omtalte firmaer har en kæmpe interesse i at promovere.

5. Sikkerhed for levering. Sørg for at den situation, hvor et system ikke leveres simpelthen ikke kan opstå, ved at have masser af del-leveringer og reel idriftsættelse af dele af den færdige løsning i hele projekt-forløbet. Således at kunden hele tiden kender den reelle status på projektet og dermed undgår den alt for ofte sete situation, hvor det en måned før deadline bliver bekendtgjort at "det er nødvendigt med 6 måneder og x millioner mere før systemet kan blive klart". Denne model giver også mulighed for rent faktisk at lære noget undervejs, så det kan sikres at systemet rent faktisk kommer til at fungere hensigtsmæssigt i relation til de arbejdsprocesser det skal integreres med.

Lyder det svært? Det er det bestemt.

Er det muligt? Det er det bestemt også.
Det praktiseres idag af talrige IT-virksomheder, der faktisk er nødt til at levere til tiden og til kundernes tilfredshed for at overleve.

18 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
18
Indsendt af Thomas Hansen (ikke efterprøvet) den søn, 02/05/2012 - 13:29

Fordi man fra politisk side / embedsmændene, ikke har intention, eller evner, til at overskue og/eller løse opgaven, så går det galt.

Det ER jo ikke så svært.

I tilfældet med "Det digitale samfund", så er det rystende enkelt, vi skal kun finde frem til løsningerne, på baggrund at kompetente embedsmænds beskrivelse af mål, som igen hviler på engagerede politikeres visioner.

Vælger man, at satse hele puljen på en enkelt leverandør, som man i stor udstrækning har gjort, så skal man være klar over, at det er et højt spil. Man skal på baggrund af empirisk erfaring, være klar over, at det oftest går galt. De er altså mere sandsynligt at man taber det spil, end at man vinder.

En mere systematisk løsning, hvor man beskriver visionen, og de delmål der er i at forfølge visionen, ville have spredt risikoen meget mere, og dermed reducerer omkostningen når det går galt.

Delmål KAN løses hierarkisk. Efterhånden som de gensidige afhængigheder etablerer interface, kan man udbygge kompleksiteten, og dermed hurtigere nå frem til målet. Der kan simpelthen sættes flere på den samlede opgave, efterhånden som de enkelte grundlag bygges op. Der skabes overskuelighed over målsætning og vision, hvilket gør det en del enklere at overskue status i opgaven. Den samlede opgave bliver hurtigere løst, for man opbygger et hierarki der fordeler kompleksiteten, men begrænser tidshorisonten.

17
4. februar 2012 kl. 14:54

Da jeg brændte ud af stress, måtte sælge min lejlighed og bo på lejet værelse, kunne jeg ikke overskue alle rudekuverterne, og fik ikke afmeldt min licens. Selvom jeg de steder jeg har boet i den årrække har været dækket af andres licens, er min gæld akkumuleret til ~15.000,-. De var så flinke nok til at indse, at de ikke kunne plukke håret af en skaldet, mens jeg havde en nettoindtægt på 6.400/mnd, men én måned efter jeg fik tilkendt pension, fik jeg en regning i min brevkasse fra Skattefar, og nu trækker de 400,- af min pension hver måned.

15
2. februar 2012 kl. 22:58

[quote]Jeg tror faktisk at et opstart firma af en vis modenhed, vil være en både bedre og billigere løsning. ... [/quote}

Enig. Mindre virksomheder har en stor interesse(læs markedsføring) i at levere en høj kvalitet til en rimelig pris, og derved vise hvad de kan levere, og derved få nye kunder/ordrer/osv.

16
2. februar 2012 kl. 23:08

Enig. Mindre virksomheder har en stor interesse(læs markedsføring) i at levere en høj kvalitet til en rimelig pris, og derved vise hvad de kan levere, og derved få nye kunder/ordrer/osv.

Man skulle tro at alle virksomheder havde denne interesse?

Jeg tror desværre at mange af de leverandører vi ser fejle, er dem som ikke hr omstillet sig til egentligt at skulle levere løsninger, men i virkeligheden lever af drift. Hele deres forretning går på at sælge drift og hosting. Dvs. de ikke har kompetencerne til at løse opgaverne, men tager dem, for at få driftsdelen - den er der jo en masse penge i, specielt så længe vi ikke kan cloude offentlige løsninger fornuftigt. Det kan godt være der tabes penge på systemkonstruktionen, og det bliver et mareridt, men hvad gør det når nu det skal driftes de næste 30-40 år nede i kælderen hos leverandøren og der skovles penge ind herfor?

Kompetence-niveauet hos leverandører som ikke skal tjene på at udleje hardware, mht. kostruktion af software og levering af løsninger til kunder, har jeg også udelukkende set være højere hos leverandører som ikke har en interessekonflikt i form af at have hosting selv.

12
2. februar 2012 kl. 11:48

at man skal være dækket ind med kompetente folk på alle niveauer, der forstår deres eget fagområde og kan forstå hovedtrækkene i de fagområder de grænser op til. Og så skal der være nogen der har det overordnede overblik og den fornødne beslutnings kompetence.

// Jesper

11
2. februar 2012 kl. 08:48

http://blogs.hbr.org/ashkenas/2011/05/when-managing-complexity-less.html

Gode gamle Ludwig Mies van der Rohe: Less is more....


Når så alt er sagt om hvor forfærdeligt der laves systemer, så hænger rigtigt meget af det på ledelsen i de forskellige institutioner, som forventer at selvom de gør som de altid har gjort så vil resultatet blive et andet denne her gang. Det er for at sige det lige ud, dumt. Hvis der ønskes et andet resultat, må der ske noget andet. Om det er en anden leverandør, er ikke sikkert. Men det er helt sikkert at processen for frembringelsen af en løsning skal være anderledes. Hvor det retrospektive der analyserer tidligere projekter, eller løbende analyserer et projekt, og sørger for at rette processen (som jo ofte kører skævt tidligt i forløbet) op, så der fremadrettet fokuseres på de rigtige ting - og ikke alle de ting som ikke bidrager til målet?

13
2. februar 2012 kl. 12:05

Jeg er meget enig.

6
1. februar 2012 kl. 20:53

Managing complexity is the most important technical topic in software development. In my view, it’s so important that Software’s Primary Technical Imperative has to be managing complexity. - Steve McConnell

Any questions, ladies?

8
1. februar 2012 kl. 23:46

Any questions, ladies?

Har du hørt om Divide-and-Concour, KISS og YAGNI. Næsten intet er meget kompliceret når det overflødige fedt fjernes og det resterende deles op i små bidder (læs a'la SCRUM-tidsestimering) :-)

[end serious humor]

9
2. februar 2012 kl. 00:19

Har du hørt om Divide-and-Concour, KISS og YAGNI.

Ja, det er et lille udsnit af de metoder jeg dagligt bruger til at "manage complexity".

4
1. februar 2012 kl. 16:57

Det er simpelthen så godt beskrevet. Der kan fyldes rigtig meget på her. Det der oftest glemmes er kernen, hvad er det vi forsøger at lave, hvilket problem skal løses. Det du nemlig beskriver er alle de andre interesser som plejes i projekterne, som ikke har ngoet som helst med løsning af kundens problem at gøre.

Der er ofte så mange aktiviteter i et projekt i dag som kun biddrager negativt i forhold til målet, det er det mest sørgelige. Det er i hvert fald ikke svært at starte med at skære det fedt fra, så vi får en højere produktivtet (et sundere forhold mellem input og output).

7
1. februar 2012 kl. 23:25

Det der oftest glemmes er kernen, hvad er det vi forsøger at lave, hvilket problem skal løses.

+1

Min nuværende opgave er defineret som en beskrivelse af formålet med løsningen, og hvad den skal kunne i sidste ende. = ingen unødvendige begrænsninger i en kravspecifikation, men kvalitet og usability i stedet for

2
1. februar 2012 kl. 16:49

Det bliver ofte brugt som argument for at vælge en stor leverandør med mange år i branchen. Men som CSC og andre har vist, er det ikke nogen garanti for rettidig leverance og fungerende systemer. I bund og grund kan man ikke forudsige det. Et opstartsfirma med 7 fastansatte medarbejdere kan være et ligeså godt bud som et internationalt kæmpefirma med 300 ansatte i den danske afdeling.

Med hensyn til punkt 5, så bør man lave kontrakten, så kunden uden videre kan opsige de efterfølgende delleveringer, hvis den første ikke er leveret til tiden eller ikke lever op til forventningerne. For at undgå at skulle starte forfra, bør kunden kræve præcis beskrivelse af dataformater og protokoller og adgang til kildekoden (både til læsning og modifikation) af hvert delsystem. Og start med de mindste og enkleste delsystemer.

14
2. februar 2012 kl. 12:09

Jeg tror faktisk at et opstart firma af en vis modenhed, vil være en både bedre og billigere løsning. Man kunne tvinge de store virksomheder som sidder tungt på de store systemer til at åbne op og stille API til rådighed og iøvrigt samarbejde med små, knap så fodslæbende virksomheder der kan have ansvaret for at levere løsningerne.

5
1. februar 2012 kl. 19:53

et bliver ofte brugt som argument for at vælge en stor leverandør med mange år i branchen. Men som CSC og andre har vist, er det ikke nogen garanti for rettidig leverance og fungerende systemer. I bund og grund kan man ikke forudsige det

Der er steder hvor der praktiseres reel konsekvens overfor leverandører. Altså noget med at hvis en leverandør har opført sig åndsvagt, så bliver de blacklistet i et stykke tid. Og bagefter kræves der en reel indsats for at komme ind i varmen igen. Det er fair nok at man som udgangspunkt ikke kan vurdere den ene leverandør overfor den anden, men hvis man utallige gange har brændt nallerne på en bestemt leverandør, så er det da logisk, at der er stor risiko for at man vil brænde sig igen hvis man vælger den leverandør igen. Reelt opmuntrer man jo leverandøren til at gøre det samme igen, når det nu ikke har kostet noget for dem at skære hjørner.

3
1. februar 2012 kl. 16:53

Med hensyn til punkt 5, så bør man lave kontrakten, så kunden uden videre kan opsige de efterfølgende delleveringer, hvis den første ikke er leveret til tiden eller ikke lever op til forventningerne. For at undgå at skulle starte forfra, bør kunden kræve præcis beskrivelse af dataformater og protokoller og adgang til kildekoden (både til læsning og modifikation) af hvert delsystem. Og start med de mindste og enkleste delsystemer.

Tja jo, men ville det ikke være super om vi der var en vej hvor risikoen var mere ligeligt fordelt? I dag er det enten den ene eller den anden part sm står med al risiko. Det du foreslår lægger i mine øjne op til endnu mere uproduktiv juristeri - noget som der ikke kommer løsninger ud af, og vi kan udsætte den omtalte indkrasning af restanser endnu mere.

1
1. februar 2012 kl. 15:53

Dekomplicér ... nårh, simplificér! :-) Kunne ikke lade være.