Estimeret læsetid: 1 minut
Man læser igen og igen om mislykkede forsøg på at erstatte et stordata-system, der har udviklet sig over årtier, med en “lille“ løsning som Navision eller Business Central. Der er mange grunde til fiasko. Og mange af dem er korrekte, alle er unødvendige.
Hvis du har travlt, kan du gå direkte til Hvordan gør man det rigtigt
Hvorfor? Navision / Business Central er den “naturlige“ efterfølger til enhver SNI/Comet/AS400-løsning!
–> Da Navision og Business Central følger samme princip om datadrevethed, som ud over AS/400 med sin DB2 også allerede gjorde Clipper & Dbase samt Access til en succesmodel.
Ak… forresten: Ja, Access er også sådan en datadrevet applikation. For gamle, voksende, efterhånden overbelastede (fordi alt for langsomme) Access- eller Filemaker-løsninger, melder Navision eller Business Central sig næsten som en naturlig afløser. Nå ja, og for excel som “universalløsning inden for erhvervsøkonomi".. Så skulle det egentlig bare handle om at “afløse & erstatte, så hurtigt som muligt, ligegyldigt med hvad“.
Exkurs: Den optiske lighed mellem Access og Navision er endda så stor, at de første designkurser for den dengang helt nye rapportgenerator fra Navision blev lavet under... Access 🙂 “Under hjelmen“ kan Access naturligvis hverken nå Navision eller Business Central til sokkeholderne. Dengang ikke, og i dag endnu mindre. Det skader dog ikke at have hørt om disse tidlige slægtskaber.
En simpel årsag til fiasko er f.eks. tidspres, forårsaget af nødvendighed. Tidspres opstår, fordi der f.eks. ikke længere er reservedele til AS400, ingen ved længere „hvor denne AS/400 egentlig står i huset“ (virkeligt! oplevet!), og/eller den hidtidige interne AS/400- eller Crossbasic/Netbasic (tidligere Business Basic) specialist endelig går på pension. Eller, også populært for tidspres: Fordi han allerede er gået på pension. I bedste fald. I værste fald er han død.
Så bliver det svært at erstatte en Access- eller midrange-løsning. Man søger hurtigt en partner, der “gør omstillingen hurtig, nem og billig“. Og så? Falder det hele tilbage på en. Hvorfor er det sådan? Hvad gør de gamle midrange- og stormaskiner ved Lidl eller Liqui-Molly , Haribo, Otto eller sågar Postvæsenet så meget bedre eller anderledes end et moderne økonomisystem som Navision / Business Central på mere eller mindre standardiseret hardware fra byggemarkedet?
Spoileralert: Det er IKKE, hvordan AS400 integrerer grafiske elementer, e-mails eller webshops. Disse løsninger kan alligevel som oftest genkendes med det samme som “tilknyttet“, “lagt ind“ eller “virker ikke anderledes“ (men... de kører!).
Ville en udskiftning af en datadrevet systemplatform med en ny, ligeledes datadrevet løsning som Navision (Business Central) ikke være utrolig nem? Jeg kan jo også ret nemt erstatte en Mercedes-varevogn med en Ford-varevogn.
Hvor ligger faldgruberne, der får sådanne erstatningsprojekter af AS400 eller Access, Dbase, SNI Comet til at fejle?
Tidlig slægtskab mellem AS400, Navision Dynamics og Microsoft Business Central 365
I dagens Business Central verden er det sandsynligvis ikke længere kendt. Men databaseserveren fra Navision (dengang stadig Navision Dynamics) kørte engang på AS/400'eren!
Omkring år 2000 blev der tilbudt en AS/400-version af den oprindelige Navision-databaseserver. Denne Navision-version var en revolution på det tidspunkt, og ikke en lille en! Mens de daværende 2.01'er og 3.01'er SQL-forsøg fra Navision snarere kunne betegnes som ynkelige ("tortur" var også et nærliggende begreb), gav AS/400 (AS400) den oprindelige databaseserver fra Navision (på det tidspunkt fandtes der endnu ikke Business Central) et utroligt ydelsesløft. Den oprindelige databaseserver var altid lynhurtig, og Microsoft måtte virkelig strække sig langt for gradvist at kunne afbilde SIFT-modellen (den teknologiske kerne i Flowfields) i SQL-serveren.
Datidens oprindelige database i Navision (i sin kerne stadig en version fra 1993!) var meget simpelt opbygget. Dens eneste problem på det tidspunkt: den kunne kun lave tabel-locking. Og gennem en – lad os kalde det “lidt ukonventionel“ – sikring af komplet bogføring, startede enhver bookingproces med en tabel-lock på vareposter (tabel 32) eller bogføringsposteringer (tabel 17).
Oversat til hverdagssprog: Så snart nogen i huset bogførte et finansbilag, et varelagerbilag, en indkøbsordre eller en salgsfaktura, var enhver anden bogføring forudbestemt til at vente på afslutningen(!) af den forrige bogføring. Og forbundet med store, små og de mindste programmerings-/designfejl bemærkede alle i salgsafdelingen, når bogholderiet igen bogførte kontoudtog. Det behøvede ikke at være sådan, men allerede dengang var der dårlige Navision programmører. 🙂
Og så kom den oprindelige Navision databaseserver version til AS400 ... hvilket i øvrigt heller ikke var særligt svært: En Unix-server til Navision havde eksisteret længe, og således var springet til i5 eller AS400 kun meget lille. En udskiftning eller udvidelse stod dermed ikke længere i vejen.
Og denne server havde det i sig. Før, altså omkring år 2000, anså man 80-120 brugere på en Navision-database for „godt muligt“ (en omskrivning af “lige akkurat“), men med AS400 blev der pludselig på månedsbasis frigivet 150, 200, 250, til sidst 400 Navision-brugere (Microsoft var indtil da “kun“ strategisk partner, endnu ikke navngiver). Uden ændring i Navision programkoden C/Side (CSide) viste AS400 den etablerede serverhardware, hvor "skabet stod" (et udtryk for at være overlegen).
Og Microsoft SQL-serveren kunne hverken konkurrere med denne oprindelige databaseserver fra Windows, Unix, OS/2 (Jep, den fandtes også!), eller komme i nærheden af at konkurrere med AS/400. Derfor blev især denne gren af AS400 opgivet med det samme, da Microsoft købte Navision i 2002. Og efterhånden blev alle oprindelige Navision-servere erstattet af en klar fokusering på MS-SQL-servere. Ærgerligt.
Fortrolighedseffekter og tabsaversion
Som beskrevet ovenfor, kan det være teknisk eller organisatorisk nødvendigt at erstatte et eksisterende varestyringssystem (ligegyldigt om det er AS400, Siemens Nixdorf, Quattro, Dbase, Oracle, Baan, Sage KHK, Lexware…) med en moderne ERP-løsning (Navision Financials Attain findes jo ikke længere som en mulighed, derfor forhåbentlig Microsoft Business Central 365 :-)). Og: Måske er det også klart for mange medarbejdere og især for ledelsen...
Men: du og dine medarbejdere har vænnet jer til den nuværende løsning. I ved, hvordan de kan (eller skal) håndtere eksisterende fejl. Netop ledelsen, men også medarbejdere, der har været længe i virksomheden, undgår ofte rent intuitivt at skulle lære nyt. Hertil kommer alle de skrækhistorier, du har hørt om andre nye ERP implementeringer. Måske spiller erfaringen med en allerede påbegyndt, men derefter mislykket, ny implementering af et nyt varestyringssystem også en negativ rolle for følelserne.
Du frygter den ekstra indsats, ændringen, endnu en fiasko, ekstra udgifter, overarbejde... måske frygter du endda erkendelsen af, at du i øjeblikket ridder på en døende hest, og det med stort besvær.
Dermed kommer vi til…
De vigtigste punkter for succes med ældre systemer
De gamle systemer var hverken bedre eller mere magiske end de teknikker, der er tilgængelige i dag. Den væsentlige fordel var allerede dengang den dybe integration af databasen/datahåndteringen i de sprog, der var tilgængelige for programmering, såsom Cobol og RPG på System36 eller AS400 (i dag System i) på IBM-siden og i Business Basic på Siemens Nixdorf Quattro Pro-siden (med Comet varelagerstyring og bogholderi). Lidt mere moderne gælder dette også Access, lidt mere historisk også dBase, Filemaker og Clipper-programmer.
Uanset om det er mere moderne lagerstyringssystemer (som VLEX Plus) og delvist bogholderier på AS/400 (f.eks. Manhattan Associates Warehouse Management solution for IBM i (WMi), Baierl og Partners BP-lagerstyring, ERP-softwaren Frida fra Command såvel som Oxaion): De drager alle fordel af den dybe integration af DB2 eller DB/400 i den samlede løsning AS400 (eller den mere moderne iSeries).
Således behøvede udviklere på disse systemer aldrig at bekymre sig rigtigt om datalagring, datahukommelse, dataforespørgsler: Dataene vandrede simpelthen ind i datalageret (DB2 på AS400, filer på SNI Quattro Pro). Og med en kommando dukkede de simpelthen op igen, og det også i en forudsigelig og forudbestemmelig rækkefølge. På de ældre systemer fra IBM og SNI med meget støvede skærmbilleder sammenlignet med i dag, men hurtige og pålidelige.
Hvis du allerede har beskæftiget dig med Navision eller Business Central, burde dette virke meget velkendt: Især i den blå („Dos-Navision“) og de ældre versioner af Navision op til Navision Dynamics 2009R2 besidder Navision præcis den samme magi... eller den samme teknologiske fordel, som gjorde Cobol & RPG-programmer på AS400 og Business Basic synlige for brugerne i de (overvejende) Comet-applikationer, der var ægte, succesfulde, pålidelige og (for datidens forhold) utroligt hurtige.
Netop dette slægtskab af datastyret programmering gør udfasningen, en migrering fra Comet eller AS400 uventet enkel! Kender du dBase og Clipper? Den samme datadrevne natur styrer også AS400 og Navision / Business Central. Med Navision Financials Dynamics eller Microsoft Business Central BC365 er WMS (Warehouse Management System) allerede inkluderet i ERP'en – det er kun den relativt simple integration med et transportanlæg, der mangler.
Bygget af dataloger
Denne kerneteknologi, denne datahåndtering eller database (som Siemens Nixdorf Quattro er afbildet på via kald i filsystemet), blev udviklet af IT-tænkere som f.eks. Edgar Codd .
Da regnekraft og især dataadgang til langtidslager som harddiske dengang ikke var ubegrænset tilgængelig, blev disse databasesystemer optimeret til maksimal ydeevne ud fra den underliggende, uforanderlige hardware. Ligesom spil til spillekonsoller i dag stadig er designet til at udnytte det maksimale af den givne hardware.
 |
Hermed lagde systemudviklerne, altså arkitekterne bag System/36, senere AS/400 eller SNI, grundlaget og fundamentet for at udvikle effektive, datadrevne programmer. Enhver, der byggede videre på dette fundament, kunne således drage fordel af systemarkitekternes højt komplekse forarbejde... hvis vedkommende kendte og respekterede systemernes begrænsninger.
Modificeret af fagfolk
Vare-, finansielle og lønsystemer, der senere byggede på disse fundamenter, blev som regel varetaget af fagfolk inden for de respektive områder, hvis ikke sågar programmeret af dem.
Her har intet ændret sig fra min 90'er udtalelse: Jeg gør hellere en revisor til en udemærket programmør end en programmør til en udemærket revisor. Det var også sådan dengang, takket være systemudviklernes forarbejde.
De rammebetingelser, som programmerne dengang opererede inden for, blev allerede fastlagt af databasemodellen fra SNI Quattro eller AS400. En overtrædelse var i visse områder slet ikke mulig, f.eks. en forespørgsel med eller uden filtrering uden et indeks (en sorteringsspecifikation).
Naturligvis kunne man så stadig vælge et forkert filter eller et upassende indeks (sorteringsspecifikation). Men det blev derefter så radikalt hurtigt straffet af systemet med eksorbitante responstider, at selv den dårligste programmør hurtigt blev klar over, at han eller hun havde lavet rod i det.
Selv i dag er dette en grund for mig til at teste udviklinger lejlighedsvis på servere med meget få kerner og meget lidt hukommelse. Når først cachen eller hardwaren skal redde, hvad programmøren/udvikleren tidligere har fordrejet, er skaden allerede sket. Hvis man opdager dette i tide (men for at gøre det, må man have ignoreret et par grundregler på forhånd), kan man i det mindste stadig gribe barnet i benene, hvilket betyder: Man kan eller bør genoverveje udviklingen.
Optimeret til effektivitet
De gamle systemer, som f.eks. en IBM AS400, en System36 eller endda en SystemR, var, ligesom en Siemens Nixdorf Quattro, 8860 eller 8870 udstyret med lagerstyringssystemet Comet fra starten. Udviklere kendte rammerne, begrænsningerne, men selvfølgelig også systemernes geniale muligheder. Da disse bevægede sig inden for snævre rammer, var oplæringstiden for programmører ofte overraskende kort, og kvaliteten af de udviklede applikationer var ofte (selvfølgelig ikke altid) på et meget højt niveau.
Systemernes retningslinjer gav også en meget konsistent brugervejledning. Fra et nutidigt perspektiv anakronistisk, nærmest en fornærmelse for øjet og den finger, der er vant til at klikke med musen. Men genkendelig og konsistent i hele systemet. I hele Comet gjaldt: F3 opretter en ny post (ordre, kunde, leveringsbetingelse), F4 sletter en post. Uanset hvor / i hvilket program man befandt sig. Dem, der stadig kender “DOS-Navision“ (den blå version) eller det “gamle Navision“ (Windows-Navision fra version 1.3, 20.1 til version 2009R2), vil helt sikkert genkende dette. 🙂
Du finder endnu mere information om dette spændende emne her.
De mest almindelige fejl i nye systemer
Der er utroligt mange fejl, man kan begå. Men der tegner sig nogle mønstre af dødssynderne ved migrering/opdatering fra et gammelt, udfaset ERP-system. Dette gælder ikke kun for den gode gamle AS400, System i eller andre programmer baseret på Cobol, RPG eller Business Basic. Disse dødssynder påvirker stort set enhver softwaremigration. Af indlysende årsager fokuserer jeg her dog direkte på mine erfaringer med redningsoperationer af migreringer til Navision eller Business Central 365.
For dette er en kendsgerning: I min tid som selvstændig (freelancer) Navision / Business Central konsulent, underviser, programmør, vurderingsmand, blev jeg kun sjældent kaldt til en Navision / Business Central (BC) migrering „på bar bund“. Jeg blev oftest søgt og fundet, når barnet allerede var faldet så dybt i brønden, at det lå med hovedet i vandet, og fødderne var uden for rækkevidde for enhver redningsmand.
Først da, efter min erfaring, er beslutningstagere villige til at lytte til mine koncepter. Ofte var resultatet så en komplet ny start.
Brug af “brancheløsninger“
Den ultimative dødssynd. Virkelig. Siden jeg fik kontakt til Navision, og det har jeg haft siden 1993, har jeg kun oplevet lidelse med disse såkaldte “brancheløsninger“. Derfor skriver jeg også kun denne betegnelse her i anførselstegn.
Hvorfor jeg ikke bryder mig så meget om disse “brancheløsninger“? Følgende skal du vide til det:
Hvordan opstår “brancheløsninger“?
Navision / Business Central kan „ud af boksen“ allerede utroligt meget: Ordreindtastning, lagerstyring i et ubegrænset antal lagre, ubegrænsede leveringsadresser, omlægninger også på tværs af lagerhaller (“afdelinger“), omkostningsregnskab, dimensionsbogholderi. Omkostningssteder & omkostningsbærere? Det er for begyndere som Datev, Diamand, H&S… Navision / Business Central har kunnet håndtere et vilkårligt antal bogføringsdimensioner i årtier! Ikke kun 2. Jeg snakke om det en hel dag… Det er uden sidestykke i bogholderiets verden!!, komplicerede prisberegninger (men faktisk ikke med et tillæg i standarden!), provisionsregnskaber for repræsentanter, analyser, ABC-analyser (nå ja… med minimale justeringer).
Navision / Business Central kan „ud af boksen“ printe fakturaer, sende følgesedler via e-mail. De nye versioner fra RTC kan direkte oprette PDF'er og e-mails fra applikationen (de gamle også, med lidt hjælp…).
Den (fra mit synspunkt) bedste, nemmeste og mest effektive bogføring er også altid med ombord.
Med dette kan enhver enkelt Navision-sælger eller Business Central-konsulent eller endda ethvert systemhus prale. Det er der altid, og det fungerer altid! Fra begyndelsen. Bare installer det, og du kan - i princippet - styre en virksomhed efter GOB. Selv GdPDU logikken er klar, UVA'er kunne systemet. Lidt opsætning, måske en rigtig SKR03 eller SKR04 ind, og så er det færdigt.
Og så kom (eller rettere: kom der) en træhandler, en bilforhandler, en slagter, en fødevareproducent, et bygningsselskab hen til et eller andet systemhus og sagde: “Det er jo alt sammen godt og vel, men vi har stadig brug for følgende funktion:“
Og systemhuset sagde: OK, giv os penge for det, så tilpasser vi dit Navision Dynamics eller Microsoft Business Central præcist til disse ønsker, så vi begge kan blive glade.
Og kunden gav penge. Og systemhuset gjorde som det blev bedt om. Og begge levede lykkelige og tilfredse indtil…
…Ja. Her begynder elendigheden. Systemhuset tænkte: Hov, vi har overordentligt mange tilpasninger af den store slags. Kan vi få dem til at blive til gyldne penge igen? Og systemhuset hang et flag op på kontoret: Vi har en “brancheløsning“ til bilforhandlere/slagtere/træhandel/ejendomshandel…
Men i de fleste tilfælde var det sådan, at systemhuset ikke havde grundlæggende kendskab til denne branche. Hvorfra skulle de? De implementerede jo kun i 2-20 uger de tilpasninger, som kunden efterspurgte mere eller mindre kvalificeret. Og som systemhuset derefter implementerede mere eller mindre kvalificeret.
Og så skete det uundgåelige: Den næste kunde kommer rundt om hjørnet, læser skiltet “brancheløsning“, og... køber!
Kunden bemærker dog hurtigt og smertefuldt, at de forretningsprocesser, som hans forgænger (husker du? Den første faglige kunde hos systemhuset...) udtænkte, slet ikke passer til ham. Det giver ballade og yderligere tilpasninger og dermed ekstra omkostninger. På et tidspunkt kører det hele.
Nu har systemhuset en endnu mere gradbøjet “brancheløsning“, der har mindre og mindre at gøre med det elegante (ægte!), hurtige (ægte!) og fejlfri (ægte!) Navision eller Business Central, som Microsoft engang brændte på DVD.
Det generer dog ikke BC-forhandleren! Han har fattet interesse, eller mere præcist: har lugtet penge. Og så sig endelig, at penge ikke stinker. Og sådan kommer der endnu en kunde, som efterlader et endnu mere forvrænget system for de efterfølgende kunder.
I mellemtiden udskiftes udviklerne i systemhuset, uerfarne programmører ødelægger endnu mere, osv. osv.
Præcis sådan opstår “brancheløsninger“!
Hvad er problemet med “brancheløsninger“?
Du lader som om, at du kan afspejle en hel branches problemer i en samlet løsning. Men løsningen er dog kommet for langt væk fra det oprindelige Navision / Business Central, og indeholder under overfladen (nogle gange også synligt) voldsomme programfejl, der stadig udbredes mere og mere til kundeinstallationer.
Desuden har markedet, kunden og systemhuset en tendens til at overbelaste kunderne. Måske har den 20. bilforhandler kun brug for en lille tilpasning til standarden for præcis sine procedurer (processer). Men han får serveret et forvrænget, fejlbehæftet og fejlstyret Navision eller Business Central 365 og skal nu finde sig i det.
Kort og godt: Det bliver ikke til noget!
Dette er i øvrigt en specialitet på Navision / Business Central markedet! Tidligere opstod brancheløsninger ved, at kvalificerede udviklere satte sig sammen med kvalificerede konsulenter og udvalgte kunder, drøftede branchespecifikke detaljer og derefter implementerede dem målrettet.
Et softwarehus har som regel kun tilstrækkelig kapacitet til at afspejle og servicere én enkelt branche, f.eks. frisører, bilværksteder, håndværkere eller banker. På softwareleverandørsiden har der således opbygget sig en enorm faglig viden om den pågældende branche.
Ofte arbejder eller arbejdede fagfolk fra den pågældende branche også direkte i softwarehuset for at formidle mellem kunder og udviklere eller for at oversætte. Tidligere var ikke alt bedre, for guds skyld. Faktisk var kun – hvis vi skal være ærlige – meget lidt bedre. Bortset fra måske søndag. Tidligere var det søndag, i dag er det mandag. Men det faktum, at brancheløsningerne, som man må skrive uden “ “, virkelig passede til den pågældende branche: DET var virkelig bedre.
I dag – og især i Navision / Business Central-verdenen – er det i det væsentlige blevet til: “Vi har serviceret en eller to kunder fra denne branche før.“ Selvom ingen af de daværende medarbejdere længere er ansat i systemhuset. Og “branchespecifik faglige viden“ er reduceret til “der kan tjenes mange penge på det“.
Brug af programmører i stedet for dataloger
Det er faktisk ikke ordkløveri, det er en enorm forskel. De tidligere basissystemer (altså f.eks. Navision / Business Central “ud af boksen“, Trampolin, aswaw400 (as/waw 400), Oxaion, Portolan, Perform, LFS400, Charisma, Assistent... på AS400, Comet (fandtes der overhovedet et alternativ?) på Siemens Nixdorf Quattro Pro 8870, 8860 med Business Basic (henholdsvis derivaterne Cross Basic, Surfbasic og NetBasic) eller helt andre systemer som Steeb, blev og bliver udviklet som grundversion i tæt samarbejde mellem applikationsspecialister og IT-folk.
OK, hos Microsoft er det blevet en dårlig vane, det kan man mærke på kvaliteten og meningen med nye funktioner eller mangel på samme.
Så grundversionerne af de respektive ERP-systemer var (og er faktisk stadig) erfaringsmæssigt meget hurtige og stabile.
Først når IT-grundprincipperne ikke længere mestres af programmører, der foretager ændringer, bliver disse systemer langsommere og mere fejlbehæftede.
Det var og er heller ikke et stort problem i enkelte virksomheder!
Hvis den “hvidhårede computergud“ laver en ridse i sit ERP-system (lagerstyring eller bogholderi) med en skruetrækker, kan han (for det meste) stadig meget nemt spore, hvad der forårsagede det, og straks fortryde eller rette sin ændring.
Men hvis en programmør, der slet ikke kender baggrunden for en ændring, og som slet ikke har sat sig ind i basisapplikationen, f.eks. Navision eller Business Central, foretager en sådan ændring... Åh nej!...
Og hvis den ændring så har skjulte fejl, og de bliver leveret til mange kunder... Åh nej!
Og når denne programmør så forlader systemhuset, og en endnu mindre erfaren efterfølger roder videre med disse allerede ødelagte programmer… Åh nej! Åh nej! Åh nej!...
Brug af sælgere i stedet for rådgivere
Tidligere blev sådanne systemer sjældent solgt af klassiske sælgere, der promoverede noget, kunden ikke havde brug for. I stedet anmodede en kunde om en demonstration, og de første samtaler blev ført med eksperter og konsulenter, der kendte deres produkt godt til meget godt. På den måde blev kundens forventninger straks korrigeret til det mulige, og (ændrings-)kravene blev ligeledes korrigeret til det fornuftige, betalelige og realistisk opnåelige. På den måde kunne selve kontrakten klargøre for begge parter, hvad der ville blive leveret. Og ligeledes: Det der ikke ville blive leveret.
Men de høje dækningsbidrag ved softwaresalg, som var almindelige i 90'erne, tiltrak desværre også sælgere, der intet forstod af det egentlige produkt, som heller ikke forstod kunden, og som heller ikke kunne formidle mellem kunde og udvikler. Kunden blev (og bliver stadig) lovet guld og grønne skove... og udvikleren får at vide: Du klarer det nok. Det må efterlade en røgsky... og det gør det ofte.
Kunderne søger ofte deres redning i selv at ansætte den håbløst overbebyrdede programmør, for at redde hvad der kan reddes. Og i systemhuset bliver der ansat en ny, uerfaren, måske endnu et par euro billigere programmør, som (endnu) ikke aner noget som helst om Navision / Business Central… og heller ikke om “branchenløsningen“. Bingo!
Det skal tilbage til det, det var før
Stædigheden (der er næppe nogen høflig omskrivning her, nogle gange må man endda ty til “dumhed“) hos tidligere stordata brugere, uanset om det er AS400, Comet eller Quattro Pro, er også legendarisk i sådanne projekter.
“Ja, selvfølgelig vil vi gerne gøre det hele meget moderne og rigtig pænt. Rådgiv os venligst. Men i sidste ende skal det hele gøres som før, ellers kan vi ikke arbejde.“ Du kan nok fornemme det: Jeg foretrækker at sige tingene ligeud frem for at snakke udenom.
Min egen skelsættende oplevelse var en papirfabrik nær Kassel. Efter at fakturaskabelonerne var sat op i Navision, blev der skrevet et par testfakturaer. Næsten alle med en eller få cents afvigelse. Det blev en lang aften…
Efter flere timer fandt jeg endelig fejlen: Siemens Nixdorf Quattro Pro, selvfølgelig med Comet, regnede forkert! Den havde en hidtil uopdaget afrundingsfejl med gruppemængderabatter. Jeg kunne bevise dette med en lommeregner og en kuglepen på de originale fakturaer!
Direktørens kommentar: Vi har altid gjort det på denne måde, og det skal fortsat beregnes på denne måde. Jeg kastede kuglepennen og udskrifterne i hjørnet og implementerede fra det tidspunkt alt det skrammel, som direktøren ville have “som før“. Og kom ikke med flere forbedringsforslag.
Med og for sådanne rådsresistente mennesker bør man ikke spilde sin tid. Det bliver alligevel ikke værdsat, og man kan alligevel ikke ændre noget i sådanne virksomheder. Denne tankegang løber altid tværs gennem hele virksomheden, ifølge min observation.
Selvfølgelig kan man også introducere Navision / Business Central med succes i sådanne virksomheder. Især værktøjerne op til BC 14 gør disse produkter mere egnede end nogen anden konkurrent på markedet. Også det netop beskrevne projekt blev implementeret, og den beskrevne fejl er stadig indbygget i 2013-versionen af Navision her i 2022. Denne “det har vi altid gjort“ har jeg aldrig oplevet i en så ufleksibel tankegang som blandt brugere af stordatasystemer.
Her er det meget, meget vigtigt, at du som kunde retter blikket indad og stiller dig selv spørgsmålet: “Vil vi virkelig have det hele, som det var før?“. Det vil koste dig mange ekstra euro, forlænge omstillingen væsentligt, og dit system vil blive praktisk talt ikke-opdaterbart – præcis som før, ligesom “det har altid været sådan“. Uanset hvad du er blevet lovet eller har fået tilsagn om tidligere.
Siden Business Central 15 vil nogle af de ting, du var vant til fra din gamle AS400 eller Siemens Nixdorf Quattro Pro Comet, simpelthen ikke længere kunne implementeres inden for standardapplikationen. Her kan selv små ting som “det skal være som før“ føre til en utrolig udviklingsindsats. For penge kan man få meget...
Trods alt må jeg som rådgiver også være fair og se på det fra de hidtidige stormaskinebrugeres synspunkt: Kæmperne i kælderen har ofte arbejdet i årtier med minimale ændringer på en “det har vi altid gjort sådan“-måde, og hele virksomheden har indrettet sig derefter. Dette introducerer og cementerer arbejdsgange og workarounds på en måde, der ofte er ukendt for Navision / Business Central-udviklere.
I vores verden lever vi af dynamik og forandring, ikke af “vi har altid gjort det sådan“. Ved en storcomputerudskiftning støder paradigmernes verdener om nogen sammen. Her er det desto vigtigere at adressere styrker og svagheder på forhånd og også at pege på umuligheder. Alt, hvad der forsømmes på forhånd, vil falde tungt ned på projektpartnernes fødder senere hen.
Muligheden for en omstilling, en ny introduktion
Hvis du er nået så langt, har du alligevel allerede tænkt på det. Dine kunder vil have PDF-fakturaer eller EDIfact-filer. Din webshop ser ud som om den er hjemmelavet ... og det er den måske også. Nye medarbejdere er længe om at lære ubrugelige talkombinationer, ikke-intuitive forkortelser og komplicerede løsninger på kendte fejl. De er måske ikke længere i stand til at tage backup af data, fordi der er en evig fejl i databasen. Du kan ikke skifte til pc-teknologi eller et moderne operativsystem af tekniske årsager. Man har brug for nye grænseflader til rapportering eller skal lave forskellige workarounds og analyser i Excel eller Word. Måske har du endda en managementkonsulent i huset, som tydeligt har beskrevet mange af flaskehalsene i din nuværende IT ... Eller du har måske selv indset det i forbindelse med et perspektivskifte: Din IT er forældet, din virksomhed lider under det, din konkurrent løber fra dig og snupper kunder fra dig med bedre service. Eller dine medarbejdere skal bruge så meget tid på at håndtere manglerne i din IT, at du har brug for nye administrative medarbejdere alene af den grund. Disse analyser tyder på, at du bør modernisere dit IT-landskab og din lagerstyring.
Og så spørger vi os selv...
Hvordan gør man det rigtigt?
Egentlig er opsummeringen simpel: Lidt ydmyghed. Lidt ydmyghed over for det eksisterende, at-erstatte-system. Men også over for det nye, erstattende (installationsklare) system, f.eks. (men ikke kun) Navision eller Microsoft Business Central 365. Ud fra det udspringer resten næsten af sig selv. Således f.eks.:
Respekt for IT
Sørg for at få støtte fra din hidtidige IT-supporter. Vær forsigtig! Dette behøver ikke nødvendigvis at være IT-chefen. Find ud af, hvem der virkelig hjælper og kan hjælpe, når en ordre ikke kan bogføres. Dine medarbejdere ved det som regel. Betoningen ligger på medarbejder. Afdelingsleder har ofte ikke længere tilstrækkelig kontakt med arbejdet. Derfor hedder de også ledere og ikke arbejdere. Også her bekræfter undtagelsen reglen.
Hvis IT-chefen virkelig er vild med det nye varesystem
Din heldige kartoffel!
Dette er (se næste punkt) yderst sjældent tilfældet. Hold ham engageret! Giv ham projektansvar. Giv ham ansvar. Inkluder ham i alle møder. Send ham på kurser. Forsøg under ingen omstændigheder at "skrotte“ ham med det nye lagerstyringssystem, bare fordi din sælger (se ovenfor) sagde, at "I ikke længere vil have brug for IT i fremtiden", “ det hele bliver meget billigere i skyen nu.“
Dette løfte bliver aldrig holdt. Aldrig.
Når IT-chefen slet ikke orker det nye ERP
Dette er ofte udgangspunktet. Måske allerede præget af din IT-ansvarliges alder. Ofte bliver sådanne udskiftninger af gamle løsninger først sat i gang af den nuværende IT-leders truende afgang. Nogle gange også efterfølgende.
I årtier blev vedligeholdelse og modernisering af IT skubbet foran sig, taget for let på. Og så kom beskeden: “Hey chef, er jeg stadig inviteret til næste julefrokost?“
“Hvorfor?“
“For jeg er jo allerede gået på pension. Forresten... hvem skal være min efterfølger nu?“.
Og allerede der brænder det på. Og nu, meget hurtigt, med al kraft, installer et efterfølgersystem... Men med en langsom start. Indtil det hele er for sent. Og så rigtigt. Du kender det...
Og denne medarbejder siger så: “Åh, jeg er for gammel til det her lort.“ Eller “Jeg behøver det ikke mere, næste år er jeg væk.“ Eller noget lignende.
Og du står der, og er afhængig af din nye „brancheløsningseksperts“ - ofte ikke-eksisterende - knowhow. Åh, gud, åh gud!…
Genvind din hidtidige IT-vejleders goodwill! Tilbyd ham en konsulentkontrakt. En 3-måneders rejse til Maldiverne, når det nye system kører. En firmabil i de første 2 pensionsår. Uanset hvad: Hold ham til ilden, brug hans erfaring til dit projekt. Lad nybegynderne, der skal overtage et ERP-system, der er vokset over årtier, lære af ham.
Hver en øre, du forsøger at spare her, vil du få tidobbelt tilbage til dit systemhus i løbet af projektet.
Hvilket også giver mulighed for (allerede oplevet), at en virksomhed netop vil udnytte denne mulighed for at befri sig fra den hidtidige IT-ansvarliges magt. Det er også muligt. Så skal man bare investere nok energi i at finde de gode sagsbehandlere i huset.
Respekt for medarbejderne
Dine medarbejdere, især dem, der virkelig arbejder, har over årene opbygget stor ekspertise om dine processer. Ofte har de fundet workarounds, som selv din IT-chef ikke kender til. Måske har de flyttet processer til excel-ark (“skygge-IT“), som nu akut skal integreres i det nye ERP-system. Inkludér dine nøglemedarbejdere (dem skal du lige identificere…) i projektforløbet.
Respekt for arbejdsgange
Programmører forstår normalt ingenting af deres processer. De læser kun arbejdsbeskrivelsen fra sælgerne (se mere om dette ovenfor) og programmerer derefter det, de har forstået ud fra den.
Legede du som barn gerne “hviskeleg“ og grinede virkelig meget af resultatet til sidst?
En afdelingschef, der ikke lever efter processerne, forklarer en sælger, der ikke kender virksomheden, hvordan en opgave skal udføres. Sælgeren, der hverken kender din virksomhed eller Navision / Business Central, forklarer en programmør, der knap nok kender begge dele, hvad han skal gøre. Og denne stakkels programmør er i sidste ende altid synderen, når resultatet ikke har meget med virkeligheden at gøre.
Hviskeleg for voksne og med pengeindsats….
Respekt for ens egen applikation
Lige som en “ung knægt“ kan man ikke vente med at vise kunden, hvor fantastisk Navision Dynamics og Business Central er i forhold til de gamle Comet og AS400 applikationer.
“Ja, selvfølgelig, det gør vi. Det går hurtigt.“
Man farer hurtigt vild med det!
Praktisk talt enhver Navision-udvikler, der har arbejdet for mere end 2 firmaer, har på et tidspunkt udvidet varebeskrivelsesfeltet. Og uger, måneder eller endda år senere støder han på diverse bogholderidokumenter, der havde et problem med det.
Selv den ret enkle deaktivering af “data per virksomhed“, f.eks. for debitortabel 18, eller for kontotabel 15, eller, meget populært, varetabel 27. Og først i løbet af projektet gik det op for den mest entusiastiske udvikler, hvad han (eller hun) egentlig havde sat i gang af en kæmpe fejl.
Heldigvis har Microsoft nu skubbet denne plage en smule frem. Desværre med massive følgeskader, så det nu er en dags arbejde at angive (det næsten altid nødvendige) Navn 2 & Beskrivelse 2 på dusinvis af sider ... og en god fingerøvelse til de første udvidelsesskridt.
Respekt for databaseserveren
Jeg tager chancen: 90% af alle mennesker, der laver tilpasninger i Navision eller Business Central, aner ikke, hvordan databaseserveren sammensætter de nødvendige data. Modigt, fordi jeg tror, at 90% stadig er sat for lavt.
“Transaktioner“: Den, der ikke kender dette ord, skal ikke undre sig, hvis selv tilsyneladende små ændringer i et flowfield, en side, en nøgle kan bremse hele ERP-systemet. Og den, der her mener, at en “transaktion“ er en bundet datamanipulation, der kun må udføres fuldt ud eller slet ikke, forveksler her forskellen mellem database/harddisk/bookingtransaktioner.
Respekt for den gyldne regel
Du kan – helt generelt, ikke kun ved AS/400, RPG, Cobol, Navision, Comet – i princippet få 3 slags servicekvaliteter på markedet:
- Godt
- Billigt
- Hurtigt
Du kan købe disse kombinationer på markedet - inden for visse grænser -:
- Godt & Billigt. Det er ikke HURTIGT.
- Godt & Hurtigt. Det er ikke BILLIGT.
- Hurtigt & Billigt. Det er ikke GODT.
- Godt, Hurtigt & Billigt. Det er UMULIGT.
Kritisk gennemgang af ens egen applikation og hidtidige processer
Det er hverken tilfældigt eller vilkårligt, at dette punkt er anført som det sidste.
Selv kvaliteten af Navision / Business Central bliver, 100% Microsoft-konform, ringere og ringere.
Flowfields i lister, vilkårlige sorteringer i vilkårlige tabeller, emulering af taster uden feedback til udvikleren: Ja, teknisk set er det fantastisk, at det kan lade sig gøre. Men i en rigtig virksomhed kan det bare ikke.
“Hardwaren er for svag“ siger man så ofte.
Nej, det er den ikke. Kravene er simpelthen urealistiske.
Reservering? Sikke noget sjusk! Hvordan kunne det ske, at et dårligt system blev så dybt integreret i systemet?
Lagerregulering? En byggeplads i 20 år. Se også flydende-gennemsnitspris-i-navision-business-central
Forudbetalingsfaktura? Mere kompliceret kan det altid blive, er der en, der har tænkt… og har så også gjort det mere kompliceret. Derved er der ikke engang den mindste styring med i det! Dertil rækker en ordrebekræftelse for 98% af kunderne, hvortil man efter ønske kan udskifte ordet “ordrebekræftelse“ med ordene “Proforma faktura“. Sågar til udlandsleveringerne.
**Løn**… En evig byggeplads. En meget, meget seriøs anbefaling: Lav ikke løn i Navision. Nej. Aldrig!
OCI & EDIfact? Kender nogen overhovedet Microsofts BizzTalk Server længere? Findes den stadig? Alt er skrald. Microsoft har aldrig haft en fornuftig EDIfact løsning. Andre kan gøre det bedre.
På trods af al den begejstring for Navision Dynamics eller Business Central, er det vigtigt at være klar over, at selv dette fantastiske system har sine grænser. Og det er bedst at kende disse grænser.
Men det, der igen er fantastisk: For migrering fra AS/400 (as400) eller Comet-programmer, uanset om de er fra RPG, Cobol eller BusinessBasic (NETbasic, CrossBasic), gælder dette ikke! Selv ældgamle dBase- og Clipper-programmer! Hvad disse gamle systemer kunne, det kan Navision og Business Central allerede for længst!
Og hvis ikke: Dynamics & Business Central blev lavet til netop at sy de “manglende guldkanter“ hurtigt og effektivt på det fantastiske varelagerstyringssytem og flotte bogholderi.
Tro mig.
(Forsidebillede af MHMcCabe)
Estimeret læsetid: 1 minut