Denne klumme er et debatindlæg og er alene udtryk for skribentens synspunkter.
Denne klumme er et debatindlæg og er alene udtryk for skribentens synspunkter.
Læs hele klummen her: Opråb til ERP-leverandørerne: Stram op - I opfører jer uanstændigt
Jeg tror ikke, der er problemer med at levere et system til fast pris og tid. Problemet ligger i implementering og individuel tilretning.
For ikke at tage hul på en lang og meget teoretisk diskussion, vil jeg indlede med et par populistiske lommefilosofiske betragtninger:
Du siger til mig: Du kan ikke svømme over på den anden side af et svømmebassin under vandet. Jeg siger, at det kan jeg. Så kan vi godt indgå en væddemål.
Men hvis du siger til mig, at jeg ikke kan dykke ned under vandet og blive nede, indtil du siger, at jeg må komme op, kan vi ikke indgå et væddemål. Vi har ingen målstreg.
Udvikling og implementering af et it-system minder ofte mere om den sidste situation end om den første.
Implementering og udvikling af et it-system involverer næsten altid handlinger, der skal varetages af virksomheden selv.
Den er afhængig af nøglepersoner i virksomheden, der forstår den omstilling, der skal foregå, og har gennemslagskraft til at flytte organisationen. Ellers sker der ingenting.
Hvis du spørger mig, hvad det vil koste, og hvor lang tid det vil tage at lære dig at spille violin, vil jeg give dig min timepris og en dato, hvor vi kan begynde. Jeg aner ikke, hvor lang tid du skal bruge på at lære det.
Det samme gælder stort set altid for implementering af et it-system.
Du kan godt give en fast pris i tillid til, at ingen rigtigt kan gennemskue, hvor målstregen er. Hvis din pris er for lav, vil implementeringen sikkert ikke blive uproblematisk.
En gang omkring 1990 var jeg til et foredrag hos IBM om ”iterativ udvikling”. Der var indkaldt en konsulent helt fra Amerika for at indføre os i dette begreb.
Efterhånden som det gik op for os, hvad det indebar, blev stemningen lidt løssluppen, og der lød små latterudbrud i salen.
Det, konsulenten underholdt os med, var at forklare, hvordan vi rent faktisk arbejdede.
De fleste havde en lidt dårlig samvittighed over, at vi ikke som for eksempel byggefolk kunne levere en fast ydelse til en bestemt pris.
Det var godt at høre en udefra fortælle, at det ikke var et personligt problem.
Hvis nogle er interesseret i denne diskussion, kan der søges på ”iterativ development” eller ”agile software development”.
Jeg synes ikke, det er konstruktivt at søge tilbage til start (cirka 1957) og ærgre sig over, at it-projekter ikke kan gennemføres med samme præcision som mindre byggeprojekter.
Anders Dyrholm peger på it-leverandørerne som problemet. Da der skal to til en tango, er det også relevant at se på kundens rolle.
Da Anders selv er it-leverandør, er det naturligvis meget dårlig stil at pege på kunden som et problem.
Det er bedre stil at pege på sig selv, tage det fulde ansvar og sige ”kan vi ikke gøre det lidt bedre?” og ”lad os se fremad”.
Dette er en populær attitude, men det fører ikke frem til en dybere indsigt.
Hvis andre leverandører så stiller sig op ved siden af og siger: ”Se på os, vi kender slet ikke det problem. Kom til os”, kan det godt blive lidt anstrengt.
Der er naturligvis også masser af gode fortællinger. Det er dog ikke nødvendigvis dem, der sidder med de problematiske sager, der er skurke, og dem med de gode sager, der er helte.
Jeg kan se, at Anders Dyrholm ikke har grebet sin opfattelse af ERP-leverandører ud af den blå luft. Der dukker nok alligevel ikke mange leverandører op i denne debat for at fortæller om deres vanskelige sager, selvom det nok er dem, der er mest interessante.
Da vi implementerede ERP-systemer omkring 1990, og systemet ikke indeholdt det, en kunde havde forventet, var replikken: ”Jeg troede, jeg havde købt en bil med fire hjul” populær.
En lidt mere indholdsrig version var: ”I skal ikke prøve at lære mig at drive min virksomhed. Systemet må indrette sig efter den måde, jeg arbejder på”.
Vi måtte så forsigtigt forsøge at forklare kunden, at dette var kunden i sin gode ret til at mene, men at det godt kunne blive en meget dyr og tidskrævende beslutning.
Hvis vi virkelig skulle tilrette systemet efter kundens vaner, var det ikke givet, at vi ville ende med noget, der kunne bruges, så kunden havde en stor risiko for at ende med, at det alligevel blev it-systemet, der kom til at bestemme.
For de mindre kunder løste udfordringen nogenlunde sig selv.
Der var ikke mange, der havde økonomisk styrke til at indgå i et udviklingsforløb.
Dette var i mange tilfælde en stor fordel både for virksomhederne og systemleverandøren. Man var tvunget til at ensrette og finde løsninger, der kunne bruges bredt.
En del af de virksomheder, Anders Dyrholm henviser til som problematiske, er måske dem, der faktisk havde midlerne til at foretage en omfattende tilpasning - men i værste fald ikke til at føre den til dørs.
En del er endt med et voldsomt kostbart system, der ikke nødvendigvis fungerer særligt godt, og som koster en formue at vedligeholde.
Jeg kan fint leve mig ind i, at det er vanskeligt bare at trække en lagerliste ud af et sådant system.
Systemet er måske bygget op i flere lag. Dem, der oprindeligt har udviklet det, er gået på pension for længe siden, og hver gang nogen rører ved det, giver det uforudsete resultater.
Det er ikke umuligt, at virksomhedens organisation er i samme forfatning.
Ingen har et samlet overblik. Den sikre løsning bliver derfor ikke at ændre for meget - hverken i organisationen eller systemet.
Vi bygger lige et nyt lag på og tager en tur mere, selv om det koster kassen.
Et skift af systemet eller en gennemgribende omskrivning vil kræve, at en del små personlige genialiteter opgives og sikkert også at organisationen gentænkes. Dette er ikke en opgave, alle kan løfte.
Selv om denne beskrivelse er forenklet og sat på spidsen for at gøre historien bedre, tror jeg, at der er mange, der kan genkende deres egen situation i dette - i et eller andet omfang.
Jeg tror, at der i dag er langt færre, der går i denne fælde end tidligere.
I dag har virksomheder et langt mere realistisk forhold til, hvad et standardsystem indebærer.
Man ved godt, at man ikke kan købe en bil og få bilforhandleren til lige at gøre den 20 centimeter højere, fordi enhver kan se, at man har brug for at transportere en bestemt kasse i den (jeg troede, jeg købte en bil med fire hjul).
Faktisk kan man godt, men de sidste 20 centimeter kommer til at koste voldsomt meget i forhold til resten af bilen.
Udvikling af it-systemer er et samspil mellem virksomheder og institutioner på den ene side og it-folk på den anden side.
Der er tale om en udvikling af en effektiv kultur, som vi alle er en del af. Det gælder både dem, der dummer sig, og dem der er mere heldige.
Nogen skal desværre høste de dyrt købte erfaringer.
Vi er måske blevet klogere på anvendelse af standardsystemer.
En ny udfordring er forenkling af forretningslogik og standarder for interaktion mellem systemer. Dette er områder, vi kun lige har taget hul på.
Der findes et rigt udvalg af fantasifulde løsninger, og der vil være gode muligheder for at være bagklog omkring dette om måske 20 år.
Er der egentligt sket meget andet end udveksling af UBL-dokumenter, der for alvor rykker?
Der findes faktisk UBL-definitioner på mange ting. De bliver desværre ikke anvendt. Vi opfinder endnu engang en lille fedtet kommafil, hver gang vi skal flytte et lager fra ét system til et andet.
Der er meget få virksomheder, der kan modtage en UBL-faktura eller ordre. Der anbringes stadig tonsvis af bilag i mapper.
Der var også noget med en standardiseret virksomheds-selvangivelse engang. Den kom vist ikke videre.
Og var der ikke engang noget, der hed Dansk Standardiseringsråd. Kom de længere end til stikkontakter?
(Jeg ved godt, at jeg her burde vide bedre. DS er faktisk fremme på banen. Bare ikke lige dér, hvor jeg savner dem)
Jeg håber med dette indlæg at træde nogen så meget over tæerne, at der kommer nogle interessante indlæg. Jeg mener at Anders Dyrholms spørgsmål bør besvares og ikke bare benægtes.
Klummer er læsernes platform på Computerworld til at fortælle de bedste historier, og samtidig er det vores meget populære og meget læste forum for videndeling.
Har du en god historie eller har du specialviden, som du synes trænger til at blive delt?
Læs vores klumme-guidelines og send os noget tekst, så kontakter vi dig - måske bliver du en del af vores hurtigt voksende korps af klummeskribenter.
Rambøll Management Consulting
Senior/Lead Software Engineer @ Ramboll Stakeholder IntelligenceStory House Egmont A/S
Story House Egmont søger Tech-Lead (.NET / JavaScript)Statens IT
Teamleder til Statens Its ServicedeskQuadsat ApS
Robotics EngineerSydbank
Data Engineer til Digital BankingDSV
Senior Change ManagerCapgemini Danmark A/S
Network ArchitectFOA
FOA søger backendudvikler med fokus på datamodellering