Projektledelse/projektstøtte
Hånden på hjertet: Har du virkelig tid til at give en ny ERP-implementering den opmærksomhed, den fortjener? Ved siden af din daglige forretning?
Kan du vurdere, om arbejdsprocesserne er blevet kortlagt som aftalt?
Er du i stand til at dokumentere dine egne arbejdsgange så pålideligt, at dit Navision/Business Central-systemhus kan implementere dem i henhold til dine ønsker og krav?
Hvis du har tøvet eller endda afvist et projekt en eneste gang, er en erfaren projektkonsulent hårde kontanter værd for dig - også selv om det koster penge. Fejl og snublesten er billigere at fjerne, jo tidligere de opdages i projektet.
Jo hurtigere du får mig om bord, jo hurtigere kan du undgå en ulykke. Og Din store fordelSiden De Betal mig, jeg arbejder og analyserer også i din interesse - og ikke i systemhusets interesse.
En selvstændig (freelancer) Navision- eller Business Central-konsulent kan hjælpe dig med at fra det værste bevare.
Hvorfor mislykkes projekter?
Årsagen er enkel: Projekter eller, mere generelt, indkøb mislykkes meget ofte efter samme mønster. Det er derfor, jeg ikke har brugt ordet ERP eller Navision/Dynamics/Business Central i denne overskrift.
Forresten kan du finde flere grunde til fiasko, men også instruktioner til vellykkede projekter, find her.
Mønsteret er altid det samme
Du, kunden, er ved at planlægge et køb. Et varestyringssystem, en ny hal, nye netværkskabler eller et nyt privat hus. Listen kunne fortsætte i meget lang tid.
Denne liste vil dog ikke omfatte f.eks. en særlig maskine eller en meget individuel ferie. Hvorfor det er sådan, vil du forstå efter de følgende afsnit.
To elementære ting kommer sammen og forårsager fiasko
a) Et produkt, der er sammenligneligt i sine egenskaber, og som tilbydes af forskellige, uafhængige leverandører.
b) En kunde, der vil betale så lidt som muligt for et sådant produkt.
Hvad sker der?
Jeg går nu direkte ind på ERP-markedet, uanset om produktet hedder Navision/Dynamics/Business Central, eller om det hedder SAP, Concord XAL, Sage KHK, Axapta eller hvad ved jeg. Det gør ingen forskel for dette mønster.
Kunden forsøger at beskytte sig selv ved at sætte en høj definitionstærskel, ofte på grund af tidligere dårlige erfaringer. De mest abstruse specialtilfælde og undtagelser er inkluderet i specifikationerne (ofte også fra kundens side). fejlagtigt mærket som „specifikationer“). Intet særtilfælde er sjældent nok til, at den medarbejder, der tager notaterne, ikke får et skulderklap. Kompliceret er altid muligt, ingen ønsker at forenkle. Fordi meget få mennesker kan.
Konkurrerende udbydere i et dilemma
Forskellige konkurrerende udbydere bliver nu kontaktet med disse specifikationer. Udbyderne står nu i et dilemma:
Hvis udbyderne tager emnet alvorligt, har de brug for meget tid til at bearbejde specifikationerne.
En udbyder ville være nødt til at skille skidt fra kanel, det vigtige fra det uvæsentlige. Urimelige påstande skal forklares grundigt som sådanne, og der skal udvikles forslag til en fornuftig ændring af en standardproces.
Tilbudsgiveren bliver dog ikke betalt for denne tid. På dette tidspunkt skal han stadig tage højde for, at han IKKE får tildelt kontrakten.
Udbyderen skal beregne omkostningerne fornuftigt. Samtidig har han kun en lille margin på selve ERP-licensen.
Gode programmører er dyre, så for at være konkurrencedygtig er han nødt til at beregne og arbejde med mindre gode (=billigere) programmører. Det kan dog betyde, at mange krav ikke kan realiseres til kundens (i det mindste planlagte) tilfredshed. I denne artikel fra Heise Dette dilemma illustreres ret tydeligt fra de rekrutterende virksomheders perspektiv.
For at gøre sit sortiment mindre sammenligneligt tyer han til færdige ekstra løsninger. Disse giver igen forhandleren den nødvendige margin for at overleve, men gør dele af sortimentet mindre forståeligt og mindre sammenligneligt.
Hvorfor bliver gode programmører kun betalt pr. time, aldrig pr. linje?
Som et lille sidespring, en hyldest til „de gamle dage“, så at sige: Hvorfor kan du ikke finde en godt En programmør, der bliver betalt pr. kodelinje, var stadig almindeligt for et par årtier siden? En god programmør er som en god maler eller en god fotograf. Han (eller hun) er sjældent tilfreds med det første resultat. Der foretages forbedringer, databaseadgange tælles, nøgler undersøges, kodelinjer erkendes som unødvendige. Det er det samme med fotografering: Man tager hundredvis af billeder og ender med at have nogle få billeder, som virkelig er værd at se. God programkode „modnes“. Jeg observerer det ofte selv: Der skabes snesevis eller hundredvis af linjer med programkode, som er med til at omdanne tanker til programkode. Derefter bliver denne kode gransket, forkortet og „forfinet“. Det er netop ved denne korsvej, at hveden skilles fra avnerne. For mange programmører er „det virker“ godt nok. Resultatet er programkode, der ikke kan vedligeholdes, og som med tiden sluger vedligeholdelse og dermed penge. God (og faktisk også „smukkere“) Programkode Men ligesom god vin tager det tid. Tid, der også skal betales for. Hvis jeg gennemgår et par programmer, kan jeg nemt komme frem til forhold på 10:1 til langt over 25:1: Programmer, som i sidste ende består af f.eks. 10 kodelinjer, har tidligere haft 100 eller 250 eller flere kodelinjer. Måske ikke alle på én gang, men alt i alt. Der er to måder at håndtere dette på som god programmør: A) At skamme sig over, at man tager en masse penge for 10 nettolinjer kode. Det er ikke sundt. Eller min måde: B) At være stolt over, at du var i stand til at løse et komplekst problem på 10 pæne linjer.
„Vi løser dit problem for X euro“
Nu modtager kunden forskellige tilbud fra forskellige forhandlere, som alle var i ovenstående dilemma. I alle tilbuddene vil han stort set finde: „Vi løser dit problem for X euro“.
Nogle af disse forhandlere (jo mere egoistisk kunden er, desto flere leverandører: For på den måde kan kunden stadig få en masse ekspertise leveret gratis) er nu inviteret til en præsentation.
I denne præsentation vises nogle få højdepunkter i softwareløsningen på så kort tid som muligt: Ejendomssalg, salg af aktiepakker eller forsikringer, salg af lastbiler. De følger alle et lignende mønster.
I sidste ende indser kunden, at de fleste udbydere på en eller anden måde vil levere den ønskede service. Den næstbilligste udbyder vinder som regel. På „en eller anden måde“ stoler man ikke på den billigste udbyder, men man vil heller ikke bruge for meget mere. „På en eller anden måde“ var alle præsentationerne „på en eller anden måde“ overbevisende.
Hvad er konsekvensen?
Udbyderen sætter sine - ofte meget friske - udviklere under tidspres og inkluderer et par ekstra moduler i pakken. Resultatet for kunden:
-Et softwareprodukt, der er svært at sætte op og vedligeholde
-Større afhængighed af udbyderen (fordi ekstra moduler ikke kan udskiftes frit, uanset om de er nødvendige eller ej).
Et ERP/software-produkt installeret under tidspres
-Under lanceringen opstår der diskussioner om, hvad der skal være med i produktet (set fra kundens synspunkt: Meget! Ellers kommer der ekstra omkostninger. Fra leverandørens synspunkt: Så lidt som muligt! Hellere ekstra omkostninger). Det fører til mere diskussion og mindre produktion.
Og en BC-udvikler, der er fanget mellem fronterne og forsøger at få et job hos en slutkunde så hurtigt som muligt - for bedre penge og bedre arbejdsvilkår.
-Fluktuationsraten sikrer igen, at nye udviklere sendes på korte kurser for få penge for at komme videre med de næste projekter ... eller køre dem i sænk.
Problemet: undersøg det nærmere kunden kan endnu ikke købe produktet på tidspunktet for købsbeslutningen.. Og derfor forsøger han Så meget kraft som muligt for Så få penge som muligt for at få.
Kontinuerlig forbedring af kvaliteten
Præcis dette Detaljer (uvidenhed) på uregulerede markeder sikrer en kontinuerlig reduktion af kvaliteten - forårsaget af den mere eller mindre bevidste „Stædighed er cool“ Kundens mentalitet.
Mere præcist har dette George A. Akerlof blev allerede analyseret i 1970 i en artikel, som først blev belønnet med en pris og anerkendt som grundlæggende langt senere. Dette kan også læses mere tydeligt i dette reklamelink her:
En særlig leverandør
Nu ved du også, hvorfor for eksempel meget individualiserede ferier eller køb af specialmaskiner normalt er. ikke mislykkes: Leverandørmarkedet er for lille her! Du er ofte nødt til at købe fra en specialiseret leverandør, og kun de kan løse dit problem.
Han vil give dig en fair pris, og du vil (være nødt til at) acceptere denne pris som en selvfølge. I sidste ende har du betalt en sum penge for en tjeneste og har fået den ønskede tjeneste. På dette tidspunkt er pengebeløbet ikke længere så vigtigt.
Konkurrerende udbydere
Det er forskellen til markeder med konkurrerende leverandører og behovet for regler. Motorkøretøjer skal f.eks. have en verificerbar bremseevne (deceleration). Dette testes af TÜV. Du kan derfor stole på, at biler, der sælges i Tyskland, bremser ganske godt.
Der er ingen regler for bildæk, kun nogle få regler. Derfor er der bildæk til salg, som „griber“ utroligt godt på en våd vej og bringer en bil (med dens testede bremser) til standsning på meget kort tid. Og der findes meget billige bildæk. Ofte, men ikke altid, fra Fjernøsten. Det er mere sandsynligt, at de får dig til at skride ud end at stoppe i regnvejr.
Det er ikke anderledes med din ERP. Der er altid nogen, der kan tilbyde en service, der er lidt dårligere og lidt billigere. Og fordi kvaliteten ikke altid er umiddelbart synlig, beslutter kunderne sig ofte for den pris, der altid er synlig.
Køb Navision eller Business Central
Hvis du ikke ønsker at komme ind i denne onde cirkel af skyld i første omgang: Du kan købe BC (KUN Business Central, Navision og Dynamics er desværre ikke længere tilgængelige. Jeg sælger ikke SAP og KHK og alt muligt andet) via mig & min partner. Dette fungerer dog anderledes end det sædvanlige og mønster forklaret ovenfor.
Min „Bedste praksis„:
- Du giver mig dine 15 vigtigste dokumenter.
Et par af dem er allerede booket:
I. Salgsfaktura
II. salgsfølgeseddel
III Bekræftelse af salgsordre
IV. Udbud til salg
V. Indkøbsordre
VI Erstatningsløsning
VII Værdiansættelse af aktier
VIII. BWA
Hvis du ikke foretager nogen særlig lagervurdering, f.eks. blot lagerværdi = faktisk lager på skæringsdatoen x sidste kostpris, eller hvis du ikke opretter nogen salgstilbud, så vil disse punkter naturligvis blive udeladt fra listen.
Saml selv de vigtigste analyser/rapporter i din virksomhed. Også fra skygge-EDB'en, f.eks. fra Excel-lister, der oprettes hver uge med en masse sved på panden. „15“ er ikke et tal, der er hugget i sten. Beslut selv i dette trin, hvad der er vigtigt for dig. Hvis du har manglet en evaluering i lang tid, så beskriv den bare kort! - Du giver mig denne liste med forståelige eksempler. Du skal blot notere eventuelle yderligere specialfunktioner på eksemplerne.
- Jeg analyserer disse rapporter. Det giver os et grundlag for dialog.
Herfra har vi et - meget groft - grundlag for Omkostningsoverslag. - Du tæller dine medarbejdere, som skal arbejde med Business Central. Dette resulterer i Licensomkostninger løsningen.
Ud fra disse værdier beregner jeg et „pi x tommelfinger“-beløb til dig, uden krav på endelighed. Den tid, der kræves til denne procedure, er valgfri og vil blive opkrævet af dig. Uanset din efterfølgende beslutning.
Realisering af projektet:
Jeg kommer til jer, og vi går i gang sammen. Jeg specificerer, hvilke stam- og transaktionsdata jeg skal bruge fra dig, og hvilke afdelinger jeg skal besøge.
Hvert trin udføres i dialog, dvs. at du til enhver tid kan få et skøn (!) over den efterfølgende indsats fra mig og også til enhver tid beslutte, om denne proces er dette skønnede beløb værd for dig.
På den måde bliver kravene hurtigt sorteret mellem „vigtigt“, „rart at have“ og „hvilken idiot fandt på det“. Ja, det sidste punkt er også overraskende almindeligt! Hvis der f.eks. er blevet etableret nogle arbejdsprocesser i virksomheden, som for længst har mistet deres eksistensberettigelse. Eller aldrig har haft det. Men som der aldrig blev sat spørgsmålstegn ved, før jeg kom til.
Mine projekter vokser med paradigmet: Jeg vil hellere bruge 10 timer på at diskutere end én time på at programmere. Det lyder forfærdeligt. Men jeg lover dig: Du vil elske resultatet.
Så mange ændringer som nødvendigt, så få ændringer som muligt. Det sikrer lave opfølgningsomkostninger, kortere indkøringstider, komplette ERP-systemer fra én kilde og hurtige arbejdsgange i stedet for endeløse klikorgier.
Hvert skridt, hver indsats kan opkræves. Det giver dig automatisk en forståelse for det udførte arbejde. Og jeg lærer din virksomhed så godt at kende uden økonomisk pres, at jeg kan give dig velbegrundede anbefalinger til procesoptimering. Uden at jeg kommer med en generel „fyr 10 % af dine medarbejdere“. Lad os overlade det til nogle managementkonsulenter, der lige er kommet ud af universitetet som erhvervsøkonomer.
Min erfaring fra næsten 30 års IT-implementeringer: En virksomhed, der har hyret en managementkonsulent behov, står allerede med en fod i insolvens.
Krav og specifikationer
Det hjælper også. Hvis I allerede har sådan noget, er det et godt arbejdsdokument. Vi kan også arrangere et par workshops sammen i din virksomhed og skabe et fælles arbejdsdokument, som beskriver vigtige rammebetingelser.
Det er op til dig, om vi kalder dette en funktionsspecifikation eller en kravspecifikation. Den forbliver et gratis planlægningsdokument til orientering og kan korrigeres i løbet af projektet i overensstemmelse med den voksende erfaring på begge sider.
Denne indsats er selvfølgelig også frivillig.
Mener jeg det alvorligt med denne tilgang?
Ja.
Du behøver ikke at købe Navision og Business Central på denne måde. Og du behøver heller ikke at købe det af mig. Jeg kommer også gerne til dig, når barnet for længst er faldet i brønden. Både som Redningsmand såvel som Voldgiftsmand.