Murmel Murmel... ERP?

Hvad laver konsulenter og programmører?

Uden for konsulenter og (interesserede) projektledere er det meget svært at forklare mit job. Hvorfor har man overhovedet brug for en konsulent til en ERP-integration, og hvorfor er det bare meget bedre, når konsulenten og udvikleren er den samme person? Hvorfor er der så mange gnidninger og misforståelser, når for mange personer er involveret i overførselskæden? Nå... Lad os bare forestille os, hvordan en proces typisk afbildes i klassiske projekter, f.eks. SAP-projekter.

Arbejdsdeling i ERP-projekter

En konsulent interviewer en medarbejder om, lad os sige, ordremodtagelse. Og vil/skal vide mere om prisdannelsen.
Medarbejderen vil ofte ikke kunne forklare helt 100% af prissætningen. Og intervieweren / rådgiveren / konsulenten ved jo ikke, hvad han skal spørge om: Han er jo selv en fremmed i denne virksomhed. Der opstår altså praktisk talt altid et gab, et delta, mellem de forespurgte og dokumenterede processer og virkeligheden. Disse gab opstår naturligvis ikke kun ved prissætningen, men også ved godkendelsesprocesserne, ved afregning af repræsentanter, ved lagerreservationsprocessen og så videre og så videre…

Typisk udfører den projektleder (konsulent, rådgiver) på ERP-siden ikke alle interviews selv af tids- og omkostningsmæssige årsager. Han/hun har derfor støttende medarbejdere, der udfører dele af processerne på samme måde (interview, dokumentation). Hver enkelt medarbejder har en vis egen arbejdsmetode, formulering af spørgsmål og naturligvis også en egen forståelse af de processer, som medarbejderne forklarer (arbejdsgange). Og selv medarbejderne har her allerede en indflydelse på detaljeringsgraden af de processer og tilhørende baggrunde, som den enkelte medarbejder beskriver i interviewet.

Procesdokumentation Kravspecifikation Ønskespecifikation

Nu har intervieweren / rådgiveren en procesdokumentation for 1 til n processer. Delvist selv oprettet, delvist modtaget som input. Disse forskellige dokumentationer bliver nu (normalt) skrevet sammen af projektlederen (rådgiver/konsulent, uanset om det er for Navision / Business Central, SAP, Baan, Great Plains, AS/400 (AS400) eller hvad det ellers måtte være). Hvis denne projektleder er dygtig, vil han/hun bemærke uoverensstemmelser, som der vil blive spurgt ind til. På den anden side vil fortolkninger og misforståelser af optagelserne også forringe kvaliteten af optagelserne. Her sker der derfor allerede for 3. gang (1.: gengivelse af processerne af medarbejdere. 2.: forståelse og dokumentation af de beskrevne processer/arbejdsgange) en kvalitativ ændring (oftest: en forringelse) af procesdokumentationen.

Denne procesdokumentation vil – forhåbentlig – blive gennemgået med kunden igen. Ofte bliver den nu blot overdraget til kunden (meget mod betaling), og kunden kan så sige „ja“ eller „nej“. Oftest siger kunden „ja“, fordi han er overvældet af kompleksiteten i sine egne processer, som nu er dokumenteret. En feedback med medarbejderne finder typisk ikke sted. Der kan være mange årsager til dette:

Feedback hos kunden

• Det forstår de jo alligevel ikke. En ret arrogant, men desværre også ofte korrekt vurdering.
• Der står for mange forskellige interne ting i den, vi kan ikke give det hele til alle medarbejdere.. Helt forståeligt og ofte også korrekt, men desværre kontraproduktiv (skadelig) vurdering.
• Det koster for meget tid/penge, hvis vi skal vende det hele igen nu.. Dette er uden tvivl den mest brugte argumentation (begrundelse).
• Det skal nok passe, det er jo fagfolkene. Der ligger megen ærbødighed og håb i dette... desværre oftest ubegrundet. „Eksperterne“ har desværre ingen erfaring med processerne, de gentager (som regel) kun kundens medarbejderes ord... så godt som de nu har forstået det.

Mediebrud på vejen mod udvikler programmering

Hvis kunden svarer „Ja“, bliver det resulterende pjank (tykt bog, brochure) overdraget til en eller flere programmører. Og det er her, den største mediebrug typisk finder sted. Programmøren eller programmørerne har som regel ikke foretaget interviews og har heller ikke set de originale noter. De ved kun, hvad de nu finder i dette kravspecifikation/funktionsspecifikation. Og dertil kommer et tids- og omkostningspres i nakken. „Få det gjort på 6 uger, ellers går vi i minus!“ er en ofte forekommende udtalelse. Så programmørerne går i gang med at omsætte de krav, de finder i kravspecifikationen/funktionsspecifikationen, til bits og bytes. Og disse programmører/udviklere har ofte nok en programmørbaggrund, men i langt de fleste tilfælde absolut ingen kommerciel viden.

Nu vender vi tilbage til Navision / Business Central. Ovenstående proces er universel og vedrører næsten alle ERP-installationer eller endda de fleste IT-projekter generelt. Den følgende del er mere specifik for ERP-integrationer, ofte erstatning af ældre systemer som AS400, SNI Quattro Pro Comet, JD Edwards, Baan og mange flere.

Problem i specialtilfældet ERP/varestyring

ERP-systemer, ofte integreret (forbundet) på en eller anden måde med et regnskabssystem, dækker mange delaspekter af virksomhedsledelse (ERP = Enterprise Resource Planning, virksomhedsprocesstyring). For eksempel det allerede nævnte regnskab, lagerstyring, indkøb, tilbudsbehandling (ofte forbundet med kundestyring, CRM (Customer Relationship Management)), prisfastsættelse, repræsentationsafregninger, prisberegninger, dækningsbidragsberegning, processtyring (driftsstyring) med kontroller, plausibilitetskontroller, blokeringer, adgangsrettigheder og meget mere.

Disse detaljer er ofte ukendte for klassiske programmører, i hvert fald i en brugbar detaljeringsgrad. Programmører tænker i klasser, objekter, undtagelser, deklarationer, funktioner. Ikke i beholdninger, balancer og saldi.

Debet og kredit

Disse programmører kaster sig nu f.eks. over et - i princippet - færdigt varesystem som Navision eller Business Central, og bygger med deres programmeringsviden nu alt ind, som de forstår konsulenternes dokumentation. De vil delvist genskabe eksisterende funktioner, simpelthen fordi de ikke kender dem. De vil modificere eksisterende funktioner, og derved lejlighedsvis også beskadige dem. Og de har ringe baggrundsviden om den faktiske brug af de funktioner, de efterspørger - og mindre om den mulige forkert brug og fejltastninger der kan opstå.

Og den første grove test foretages naturligvis med input, der giver „mening“. Meget vigtigere er dog testene netop med „meningsløse“ data!

De programmer/tilpasninger, der er oprettet på denne måde, overdrages nu til kunden – nogle gange af konsulenten eller rådgiveren, nogle gange af programmøren. Her kommer brugerne ind i billedet igen for første gang.

Udvikler / programmør og konsulent i én person

Kan du huske det oprindelige spørgsmål? Hvorfor er det bedre, når programmører/udviklere og konsulenter/rådgivere er den samme personMange af ovenstående løkker falder simpelthen væk. Dette reducerer allerede enormt omkostningerne til indsamling/forståelse/implementering af kravene. Men endnu vigtigere: Ved uklarheder under implementeringen (udførelsen) kan han direkte henvende sig til den ansvarlige medarbejder for at stille opklarende spørgsmål. Omvendt kan medarbejderen også under testningen direkte kontakte den kendte Navision eller Business Central udvikler/programmør med yderligere definitioner, ændringer, glemte detaljer for at levere specifikationer, der tidligere er blevet glemt.

Forståelse gennem et praktisk eksempel

Disse feedbacksløjfer, prøv og test og fejl, er meget vigtige manifestationer af agil udvikling. Og den er for de fleste mennesker meget sværere at forstå end den ældgamle arbejdsmetode beskrevet ovenfor. Hvis du vil dykke lidt dybere ned i dette:
Se dig bare omkring se denne video her. Det handler om en - helt fremmed for ERP - udvikling af en kuglemusikmaskine. Det interessante i denne video er dog noget helt andet: Hvor mange detaljer skal man overveje i et projekt, hvor mange efterfølgende tilpasninger og finesser skal man tage hensyn til? Og hvordan opdages og løses eller forbedres disse bedst? Hvilke skønheder (Ja! Software kan være „skøn“!) kan man opdage og integrere gennem efterarbejde? Hvor detaljeorienteret kan man være? Lad bare videoen virke ind på dig...