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.
Ach… forresten: Ja, Access er også sådan en datadrevet applikation. For gamle, voksede, 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 „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 Navision eller Business Central det vand. 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. simpelthen 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!), eller/og 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. Bedst muligt. Dårligst muligt 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 Lidl eller en Liqui-Molly , en Haribo, en Otto eller en overhovedet Posten så meget bedre eller anderledes end et moderne økonomisystem som Navision / Business Central på mere eller mindre standardiseret hardware fra byggemarkedet?
Spoileradvarsel: 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“, „pålånt“ eller „går ikke anderledes“ (men... de virker!).
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 databaserseveren fra Navision (dengang stadig Navision Dynamics) kørte engang nativt på AS/400'eren!
Omkring år 2000 blev der tilbudt en AS/400-version af den native 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 native databaseserver fra Navision (på det tidspunkt fandtes der endnu ikke Business Central) et utroligt ydelseskick. Den native 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 Server.
Datidens native 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 – nu, lad os kalde det „lidt ukonventionel“ – sikring af komplet bogføring, startede enhver bookningsproces med en tabel-lock på vareposter (tabel 32) eller bogføringsposteringer (tabel 17).
I hverdagen oversat: 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å slutningen(!) af den forrige bogføring. Og forbundet med store, små og mindste programmerings-/designfejl bemærkede alle i salgsafdelingen, når finansbogholderiet 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 versionen af native Navision databaseserveren til AS400 ... hvilket i øvrigt heller ikke var særlig 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 for „lige akkurat“), men med AS400 blev pludselig på månedsbasis 150, 200, 250, sidst 400 Navision-brugere frigivet (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 Server kunne hverken konkurrere med denne native databaseserver på 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 på AS400 med det samme opgivet, da Microsoft købte Navision i 2002. Og efterhånden blev alle native Navision-servere erstattet med en klar fokusering på MS-SQL Server. Ærgerligt.
Fortrolighedseffekter og tabsaversion
Som beskrevet ovenfor, kan det simpelthen 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: De og Deres medarbejdere har vænnet Dem til den nuværende løsning. De 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, De har hørt om andre ERP-nye 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 (emotionerne).
De frygter den ekstra indsats, ændringen, endnu en fiasko, ekstra udgifter, overarbejde... måske frygter De endda erkendelsen af, at De i øjeblikket rider på en døende hest, og det med stor besvær.
Dermed kommer vi til…
De vigtigste punkter for succes for æ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 finansiel bogføring). 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 seriøst om datalagring, datalagring, dataservering: 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 i dag meget støvede skærmbilleder, 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 de ægte, for brugeren synlige Cobol & RPG-programmer på AS400 og Business Basic i de (overvejende) Comet-applikationer så succesfulde, pålidelige og (for datidens forhold) utroligt hurtige.
netop dette slægtskab af datastyret programmering gør udfasningen, en migrering fra en Comet eller AS400 uventet enkel! Kender du dBase og Clipper? Den samme datadrevne natur styrer også en 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.
Lavet af dataloger
Denne kerneteknologi, denne datahåndtering eller database (som Siemens Nixdorf Quattro er afbildet på via kald i filsystemet), blev af IT-tænkere som f.eks. Edgar Codd udviklet.
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, i det væsentlige 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, 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 programmeret af dem.
Her har intet ændret sig fra min 90'er udtalelse: Jeg gør snarere en revisor til en tilstrækkelig god programmør end en programmør til en tilstrækkelig god 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 en 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.
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 med varestyringssystemet Comet, koordineret 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 almindelige mønstre af dødsyndene 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ødsynder 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 mark“. Jeg blev oftest søgt og fundet, når barnet allerede var så dybt i brønden, at det sad 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 „bankløsninger“? Følgende skal du vide om det:
Hvordan opstår „branchenløsninger“?
Navision / Business Central kan „ud af boksen“ allerede utroligt meget: Ordreindtastning, lagerstyring i et ubegrænset antal lagre, ubegrænsede leveringsadresser, interne omlejringer 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øringsdimesioner i årtier! Ikke kun 2. Alene om det kunne jeg holde en hel dag… Det er uden sidestykke i finansbogføringens 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 „out of the box“ 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 mit an Bord.
Med dette kan enhver enkelt Navision-sælger eller Business Central-konsulent eller endda ethvert systemhus prale. Det er altid der, og det fungerer altid! Fra begyndelsen. Bare installer det, og du kan - i princippet - styre en virksomhed efter GOB. Selv de GdPDU Logik 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 bygningsstyringsselskab 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 lykkeligt og tilfreds indtil…
…Ja. Her begynder elendigheden. Systemhuset tænkte: Hov, vi har overordentligt mange tilpasninger af den mægtige slags. Kan vi få dem til at blive til gyldne penge igen? Og systemhuset hang et flag foran sin vest og på kontoret: Vi har en „branchens lø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? 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 „Branchens løsning“, og... køber!
Kunden bemærker dog hurtigt og smertefuldt, at de forretningsprocesser, som hans forgænger (husk? 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 bøjet „branchenlø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 skifter udviklerne i systemhuset, uerfarne programmører ødelægger endnu mere, osv. osv.
Præcis så „Brancheløsninger“ opstår!
Hvad er problemet med „brancheløsninger“?
I pretend to be able to map the problems of an entire industry in a single package. However, these packages have moved far too far away from the original Navision / Business Central, and contain (sometimes also directly visible) serious programming errors beneath the surface, which are being spread in more and more customer installations.
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.
Så meget, så kort: Det bliver ingenting!
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 også fagfolk fra den pågældende branche 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 søndag, i dag er det mandag. Men det faktum, at branchepakkerne, som man må skrive uden “ ", virkelig passede til den pågældende branche: STØJ 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 bassesystemer (altså f.eks. Navision / Business Central „out of the box“, 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 (u)meningen med nye funktioner.
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 finansiel bogføring) med en skruetrækker, kan han (for det meste) stadig meget godt 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.
Men de høje dækningsbidrag ved software-salg, 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 fik at vide (og får stadig) det blå ud af himlen... og udvikleren får at vide: Du klarer det nok. Det må efterlade en brændt jord... og det gør det ofte.
Kunderne søger ikke sjældent 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 blive som det var før igen
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.“ De kan nok mærke det: Jeg foretrækker at sige tingene ligeud frem for at snakke udenom.
Min egen skelsættende oplevelse var en hobbykartonfabrik 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 dette tidspunkt alt lort, som direktøren ville have „som før“. Og kom ikke med flere forbedringsforslag.
Min og for man bør ikke spilde unødig tid på sådanne rådsresistente mennesker. 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 konkurrent på markedet. Også det netop beskrevne projekt blev implementeret, og den beskrevne fejl er stadig indbygget i den efterhånden 2013-version af Navision i 2022. Denne „det har vi altid gjort“ har jeg aldrig oplevet i en så ufleksibel betonhovedtankegang 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 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å „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 sandelig paradigmernes verdener 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 med tonsvis 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 varestyring.
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. Afdelingleder 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
Du heldige lykkejæger!
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-lederens 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 brænder hytten. Og nu, meget hurtigt, med al kraft, installer et efterfølgersystem... Men med en langsom start. Indtil alt er alt for sent. Og så rigtig. 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, gid, gid!…
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 de nybegyndere, der skal afløse et ERP, der er vokset over årtier, lære af ham.
Hver en øre, du forsøger at spare her, vil du ti-doble betale 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
Programmere forstår normalt intet 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 „Syg Post“ og grinede så vildt af resultatet til sidst?
En afdelingschef, der ikke lever 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.
Stilleleg for voksne og med pengeindsats….
Respekt for ens egen applikation
Lige som en „ung knægt“ klør det i fingrene på én for 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 artikelbeskrivelsesfeltet. Og uger, måneder eller endda år senere er der stødt han på diverse postbladdokumenter, der havde et problem med det.
Selv den ret enkle deaktivering af „Data per Company“, f.eks. for debitor-tabel 18, eller for hovedbogstabel 15, eller, meget populært, artikeltabel 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 givet dette skubber nu en tyk rigel frem. Ulykker med massive følgeskader, så det nu er en dags arbejde at (næsten altid nødvendigvis) angive Navn 2 & Beskrivelse 2 på dusinvis af sider ... og en god fingerøvelse til de første skridt med udvidelser.
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.
„Transaktion“: Den, der ikke kender dette ord, skal ikke undre sig, hvis selv tilsyneladende små ændringer i en Flowfield, en side, en nøgle derefter bremser hele ERP-systemet. Og den, der her mener, at „transaktion“ er et 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 servicekvalitet på markedet:
- God
- Billig
- Hurtig
Du kan købe disse kombinationer på markedet - inden for visse grænser -:
- God & Billig. Det er ikke HURTIG.
- God & Hurtig. Det er ikke BILLIG.
- Hurtig & Billig. Det er ikke TARME.
- God, Hurtig & Billig. Det er UMULIGT.
Kritisk gennemgang af 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.
Strømningsfelter I en liste, 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 hun ikke. Kravene er simpelthen urealistiske.
ReservationSikke et molok! Hvordan kunne det ske, at et dårligt system blev så dybt integreret i systemet?
Lagerregulering? En byggeplads i 20 år. Se også glidende gennemsnitspris i Navision Business Central
Vorauskasse Recfornemmelse? Komplizierter geht es immer, muss sich da einer gedacht haben… und es dann auch noch komplizierter gemacht haben. Dabei ist da noch nicht einmal die Mindest-IST Versteuerung mit drin! Dabei reicht bei 98% der Kunden eine Auftragsbestätigung, auf der man per Wunsch das Wort „Auftragsbestätigung“ gegen die Worte „Pro-Forma Rechnung“ austauschen kann. Sogar für Auslandslieferungen.
**Løn**… En evig byggeplads. En meget, meget seriøs anbefaling: Lav ikke løn i Navision. Nej. Aldrig!
OCI & EDIfactKender 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 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 guldkant“ hurtigt og effektivt på den super varelagerstyring og flotte finansbogføring.
Tro mig.
(Forsidebillede af MHMcCabe)
Estimeret læsetid: 1 minut