Krångla inte till det
Jag läste i morse om Transportstyrelsens problem med olycksstatistiken på vägarna. Tydligen var polisens rapportsystem under 2014 så krångligt att många olyckor inte rapporterades. Det ledde i sin tur till att olycksstatistiken nu inte går att lita på.
Återigen handlar det om polisens IT-satsning PUST Siebel, ett system som blev så katastrofalt att man till slut tvingades att besluta om nedläggning (2014). Totalkostnaderna ligger någonstans i spannet från enorma till katastrofala.
Från rätt till fel
Polisens IT-satsning är lite speciell, eftersom man från början gjorde det mesta rätt. Det första PUST-systemet skrevs i Java (PUST Java 2010-2011), hade bra projektstyrning och visade sig fungera förvånansvärt bra. De som använde systemet var nöjda och deras arbete gick betydligt snabbare än tidigare. De 100 miljoner kronor som investerats framstod som hyfsat väl placerade pengar.
Men glädjen blev kortvarig. Redan efter ett par månader kom beslutet att systemet skulle skrivas om från grunden i ett standardsystem (Siebel från Oracle). För att frigöra utvecklingskapacitet lades PUST Java ner och alla ägg hamnade i ”PUST Siebelkorgen”.
Men PUST Siebel blev en katastrof. Trots att utvecklingen i första hand gick ut på att kopiera ett befintligt system misslyckades det. Ändå infördes det nya systemet och poliserna fick det tvivelaktiga nöjet att gå från ett fungerande system till ett system som inte fungerade. Konsekvenserna har varit enorma.
Addera funktioner
PUST skiljer sig från de flesta andra misslyckade konstruktioner i det att man faktiskt gjorde rätt från början. Mera vanligt är att alltför många försöker klämma in alltför mycket i en konstruktion. När det hela står klart visar det sig att produkten eller systemet egentligen inte är bra på något.
Det kanske mest underhållande exemplet finns i TV-filmen The Pentagon Wars (HBO), där man bland annat häcklar utvecklingen av det amerikanska trupptransportfordonet Bradley.
Det som definieras och godkänns som ett billigt och snabbt fordon för att transportera 11 soldater (plus en förare) genomgår här en ganska underbar metamorfos, där ledningen för olika vapenslag hela tiden adderar nya önskningar till listan.
Resultatet blir efter många år och massor av omkonstruktioner något som har väldigt lite med ursprungsfordonet att göra. I stället för elva soldater ryms nu bara sex. I stället för bara en förare krävs nu tre besättningsmän. Det låga och svårupptäckta fordonet har blivit högt och har fått ett kanontorn. Trupptransportfordonet har blivit en ganska värdelös stridsvagn med dålig bepansring till ett högt pris. Alla har fått vara med och bestämma och resultatet gör egentligen ingen nöjd.
Lägg ner tidigt
Den här typen av misslyckanden är vanliga och i vanliga kommersiella företag brukar de sluta i att projektet läggs ner. Inte så sällan leder de till att hela företag går i konkurs. Normalt sett kan man inte konkurrera med undermåliga produkter (det finns undantag).
Jag tror nog att de flesta kan komma på rader av misslyckade produkter som tvingats bort från marknaden. Här har marknadsekonomin kanske sin allra största fördel jämfört med planekonomin. Marknadsekonomin konkurrerar ut det som är fel tänkt, fel genomfört eller det som blir fel på grund av ändrade förutsättningar. Hårt, men effektivt.
Om projekten går i offentlig regi är risken mycket större att de får fortsätta långt efter att allt gått åt skogen. Det kan handla om undermåliga sjukvårdssystem, undermåliga skoldatorprojekt, alltför sena telekomprojekt (TeleGuide) eller misslyckade polissystem (PUST Siebel).
Välfyllt serverrum
Jag minns förresten ett av våra egna exempel på misslyckade och överdimensionerade datorsatsningar. I slutet av nittiotalet hade Elektronik i Norden expanderat till att ha förvånansvärt många anställda och vi anlitade proffs för att skapa ett välstrukturerat datorsystem. Serverrummet fylldes med rader av serverdatorer, nätverksutrustning och backupsystem. Kilometervis med kablar drogs överallt och det krävdes nästan en hel konsulttjänst för att hålla alltsammans snurrande.
Problemet var bara att huvuddelen av systemen, underhållet och utbildningen gick till att hantera själva systemet. Användarna hade inte så ruskigt mycket nytta av det hela.
Så när nedgången för facktidningarna började göra sig märkbar några år in på 2000-talet verkade datorinstallationen vara ett intressant ställe att spara pengar. Det mesta i nätverksväg samlades i en två enkla datorer med FTP-mjukvara (varav en backup). Och när vi flyttade till nya lokaler hamnade i stort sett allt från serverrummet i källaren. Där blev det sedan stående tills det var dags för skroten. Så kan det gå.
Vad kan man då lära sig av detta? Kanske att det är dumt att bygga upp system som man inte behöver. Och kanske att man skall akta sig för att lämna över kontrollen av ett projekt så till den milda grad att man inte längre har en aning om vad som pågår.
För tyvärr är det nog så att projekt eller system som lämnas utan styrning får ett eget liv och blir något helt annat än vad som var tänkt. Och projekt där alla får vara med och styra kan lätt resultera i att ingen blir nöjd, trots att allt ”i princip” finns med.
Filed under: Göte Fagerfjäll
Hej!
Jag känner igen mycket. Har varit med om allt från ABC80, ABC800, PDP-maskiner, Vax-datorer, PC-revelutionen, mängder av dåliga program, uppdateringar som gjorde datorerna ännu segare osv. i all oändlighet. Enormt mycket arbetstid har gått åt för själva datorstrulet och ibland har det viktiga konstruktionsjobbet kommit i andra hand. Jag upphör aldrig att förvånas.
Jag kan rekommendera en bok, ”Jävla skitsystem” (i min mening felaktig titel), skriven av IT-arkitekten Jonas Söderström.
Gå in på: http://www.javlaskitsysten.se så är det nog många som känner igen sig.
Med vänlig hälsning
//Evald i Bara