Artikel top billede

Hvorfor ender vi altid i specialprogrammerede it-løsninger? - de giver så mange problemer

Klumme: Igen og igen hører vi om store it-projekter, der er gået i hegnet. Ofte er sygdommen en dårlig proces med specialprogrammering. Her får du mit bud på, hvordan vi kan undgå problemerne.

Denne klumme er et debatindlæg og er alene udtryk for skribentens synspunkter.

Igen og igen hører vi om store it-projekter, der er gået i hegnet.

Beskyldningerne flyver fra højre mod venstre mellem kunder og den virksomhed, der har leveret it-ydelsen.

Overskriften er næsten den samme hver gang: ERP-, CRM- eller servicesystemet er blevet programmeret i stykker, så det er blevet uoverskueligt og umuligt at få sat i drift.

Men hvorfor går det så galt, er der mange der tænker?

It-virksomheden lever af programmering og konsulenttimer kontra virksomheder, der mener, at de har så specielle flow og processer, at de ikke kan følge den måde, som eksempelvis et ERP system tænker på. Konflikten er uundgåelig.

Men lad os prøve at se hvordan vi kan undgå dette.

Først kigger vi ind til virksomheden, hvor symptomerne typisk er henne:

Vi vil gerne have et nyt ERP eller opgradere det gamle. Men vi ved faktisk ikke, hvordan det nye ERP fungerer - altså bortset fra, at det er smart.

Det vil sige, at vi typisk kopierer et dårligt flow med masser af egne opfundne regler fremfor standardflows.

Når vi sidder på en workshop, så oplever vi dertil, at ERP-leverandøren blot nikker, når ønskerne vælter frem, fordi leverandøren tænker penge i kassen. Et dårligt flow bliver derfor aldrig udfordret.

Når man går ind i et flow/proces, så er det oftest meget let at tegne den direkte vej op - for eksempel fra en salgsordre kommer ind, til den ekspederes.

Men når man så begynder at høre om afvigelserne, så vælter det frem.

• Ved kunde x betaler vi altid hans omkostninger ved reklamationer – men ikke de andre 87 kunder.

• Den kunde har vi lovet at altid have x antal varer på lager – de andre kunder må bare vente osv.

Men et it-system er jo ”sort/hvidt”, så derfor ender vi i special-programmering, fordi vi ”opfinder” en masse ekstra knapper og/eller andre funktionaliteter til at dække over disse behov fremfor at sætte nogle standardregler.

Har ikke fået ryddet op

En dårlig proces med specialprogrammering er ofte sygdommen, som vi ikke har fået ryddet op i.

Hvis man for eksempel laver et standarddesign på en reklamation - så er det den, som alle kunder får og ikke specialversioner, hvor der sidder en person fra virksomheden og laver en masse manuelt arbejde med dertilhørende risiko for fejl og specialprogrammering.

Integrationer til andre systemer er ofte uundgåelig – men fortvivl ikke!

En god og klart defineret integration mellem to systemer, hvor eksempelvis kundens data kun vedligeholdes et sted giver et meget bedre flow – fordi man så ikke behøver at tænke på specialprogrammering.

Integrationer kan være svære - men ofte er pengene givet godt ud, da det giver et rent flow, der er tydeligt for alle i virksomheden og letter tingene ved opgraderinger.

Kan ikke undgå tilpasninger

Naturligvis kan vi ikke undgå tilpasninger – men disse skal skabe værdi og give virksomheden en gevinst i form af sparet tid eller for eksempel bedre leveringsservice.

Så når en programtilpasning beskrives og estimeres, så har både leverandøren og virksomheden en pligt til at beskrive, hvorfor denne tilpasning skal laves, og hvad er gevinsten og hvornår programmeringen er tilbagebetalt.

Her skal leverandøren være kritisk, hvis man gang på gang ser ønsker til ændringer, der er baseret på følelser i stedet for hårde fakta.

Så se et it-projekt som et fællesprojekt og ikke som to boksere, der står overfor hinanden.

Så ender det med de boksekampe, som ikke er skønne at se på andet end for advokater og andre mæglere, der skal indover og agere kampledere.

Gode råd:

- Du bør udfordre din it-programmør/leverandør på, hvad er rent faktisk er standard, og hvordan det virker.

- Få ryddet op i dine processer – så du får dræbt dine mange afvigelser og specialregler der er bygget op gennem årene.

- Ryd op i stamdata, så du ikke slæber rundt på en masse unødige stop i den enkelte proces.

- Sørg for at integrationspunkterne til andre systemer er klart defineret så for eksempel varenummeret og vareteksten kun oprettes en gang og dermed kun vedligeholdes et sted – så undgår vi ekstra programmering og dataoprydning.

- Vær ærlige mod hinanden, når der programmeres – skaber det værdi eller er det et ”plejer-syndrom,” der er opstået i virksomheden

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.