Denne artikel søger at beskrive hvilke forhold, der bør tages højde for, når en gammel ejendomsløsning til Dynamics NAV skal erstattes med Dynamics Property.
Først og fremmest kræver Dynamics Property seneste version af afløseren til Dynamics NAV, nemlig ”Business Central”.
Således betyder en beslutning om at anvende Dynamics Property også en beslutning om at økonomisystemet skal opgraderes fra Dynamics NAV til Business Central.
Denne artikel er fremkommet som følge af en praktisk velgennemført opgradering, hvor vi ønsker at dele erfaringerne gjort i denne proces.
Når vi i denne artikel taler om ”Business Central” med en ejendomsløsning, mener vi at platformen driftes på Microsofts Business Central servere, dvs. som ”Software as a Service”. Business Central vil her altid blive opdateret til seneste version. Projektet der gennemgås, blev flyttet fra et lokalt hosting miljø til Microsoft's Business Central servere.
Der er flere årsager.
Vores stærke anbefaling er i øvrigt, at alle 3. parts løsninger som en kunde, ønsker at gøre brug af, bør være publiceret gennem ”AppSource”. Softwaren er her igennem en certificeringsproces og vedligehold af løsningen kan ske uden, at skulle huske og udføre manuelle opdateringer. Dynamics Property er naturligvis tilgængelig via AppSource.
Kort om kundetilpasninger. De er stadig en mulighed, men særlige foranstaltninger bør gøres for at disse fungerer efter opgraderingerne, hvilket ofte stiller specielle krav i form af automatiserede tests. Generelt fraråder vi specialtilpasninger medmindre fordelene er overbevisende store for kunden. I det konkrete projekt skulle der ikke håndteres specialtilpasninger.
I det konkrete projekt som denne artikel tager afsæt i, består løsningen alene af Business Central og Dynamics Property.
Er der nogle ulemper?
Ja, da vi ikke har tilgang til de benyttede servere, kan vi ikke justere på dem!
Samlet set er vores erfaring dog at fordelene langt overvejer ulemperne med en højere driftsstabilitet i skyen. Microsofts Power Platform er bygget i skyen, hvorfor det logiske valg er at bygge en sammenhængende arkitektur i skyen, medmindre specielle forhold gør sig gældende.
Af ovennævnte årsager, er der en bevægelse væk fra lokale installationer mod løsninger i skyen, som betegnes som ”Software as a Service”.
I projektet overgår kunden således fra en Hosted løsning til Business Central i skyen!
Blot for en god ordens skyld – Business Central og Dynamics Property kan også køre på en lokal server, men det er bestemt ikke vores umiddelbare anbefaling.
Enhver proces vil rumme unikke elementer. Både tekniske og arbejdsmæssige. For at komme godt igennem en opgraderingsproces, skal processen drøftes før der kan udfærdiges en plan.
I foranalysen bør også arbejdsmæssige belastningsmæssige forhold hos kunden afdækkes for at sikre at kundens organisation har taget højde for den arbejdsbelastning, som projektet indeholder.
I det konkrete projekt havde kunden travlt med at lave forbrugsregnskaber i perioden, hvorfor projektplanen blev justeret herefter.
Følgende centrale spørgsmål bør også afklares tidligt i processen:
Det stiller således krav til os som leverandører, at vi kan forholde os kritisk til forretningsprocesserne for at der kan ske en afstemning, hvad der evt. bør fjernes af funktionalitet.
I foranalyse fasen, bør der med afsæt i de centrale forretningsprocesser laves en testdrejebog, så brugerne er udstyret med et sæt af processer, der kan testes i testmigreringen (se nedenfor).
Foranalysen skal ikke blot fastsætte tidsforløbet men også projektøkonomien.
Der blev i projektet valgt en ”ren start”, dvs. hvad man starter med en ren Dynamics NAV – 3. parts produkter og kundetilpasninger slettes som det første i opgraderingsprocessen. Her anvendes Microsofts migrationsværktøjer. Når økonomistyringssystemet er opgraderet, installeres Dynamics Property og ejendomsstamdata migreres. Efter stamdata er migreret kan der laves åbningsposteringer.
Vores erfaring er at standard opgraderingsprocessen forløber relativt problemfrit. Vi havde dog til at starte med i det konkrete projekt en ufuldendt opgradering. Her stoppede opgraderingen blot uden at fejlmelde. Det skyldes i øvrigt nogle specialkarakterer i virksomhedsnavnene – her bør der som et eksempel ikke være gemt et dobbelt mellemrum.
Det fik os til at udvikle et sæt værktøjer til at kunne tjekke succesen af en opgradering for at være sikker på at processen blev afviklet korrekt.
En migrationsproces sker via trin, dvs. jo ældre en Dynamics NAV man har, jo flere versioner skal der opgraderes mellem. Vi partnere taler her om en opgraderingsmatrix. I det konkrete projekt kom kunden fra en Dynamics NAV 2013R2 og skulle løftes til seneste Business Central version. Det betød flere opdateringsforløb skulle udføres inden for såvel test-opgraderingen og live-opgraderingen.
Hvis tidligere tilpasninger ønskes medtaget, skal disse genkodes for at kunne køre i skyen. Det bør vurderes hvor kritiske eksisterende tilpasningerne er. Er de tilpas kritiske bør de naturligvis løftes, men de skal ledsages af automatiserede test, således man har vished for de fungerer som tilsigtet på tværs af de løbende opdateringer. I det konkrete projekt var det ikke tilpasninger, der skulle løftes.
Microsofts opdateringsværktøjer omfatter imidlertid ikke 3. parts produkter og tilpasninger. Det kræver en speciel designet proces for at håndtere denne del, som det ud fra et omkostningsperspektiv er gunstigt at undgå.
I projektplanen skal der afsættes tid til en testopgradering og en go-live-opradering.
I testmigreringen kan kunden validere migrerede data, men kan også uddannes i den nye funktionalitet med egne data og ikke mindst teste processer med afsæt i en testdrejebog udarbejder under foranalysen. Som leverandører laver vi denne fase en detaljeret arbejdsbeskrivelse af hvilke skridt vi udfører. Drejebogen anvender vi så ved den endelige migrering.
I live-opgraderingen producerer vi det der bliver det endelige driftsmiljø.
En opgradering består af en standard Business Central opgraderingsproces ved hjælp af Microsofts opgraderingsværktøjer. Er der kundetiloasninger der skal løftes skal de omkodes til AL-kode, der kan afvikles i skyen. Mange tilpasninger bruger ".net" biblioteker som var tilladte i den lokale installation af Dynamics NAV. De er ikke tilladte mere og der skal således findes et alternativ. I skyen er der ikke drev og filer, men man arbejder i stedet med streams og objekter.
Alt efter den tidsmæssige udstrækning af projektet, eller mængden af detaljer involveret kan kan det indimellem være relevant med en ekstra mellem-migrering. I det konkrete projekt valgte vi at lægge en sådan ind. Ikke mindst da projektet også indeholdt en selskabsfusion.
Ikke alle løsninger er lige insisterende på en korrekt datastruktur. Den gamle ejendomsløsning tillod flere lejere at optage et lejemål på samme tid.
Det er naturligvis ikke hensigtsmæssigt, da man ved denne struktur f.eks. ikke kan udarbejde forbrugsregnskaber.
En af erfaringerne vi gerne vil dele er hvor svært det er at flytte stamdata fra en ejendomsløsning med en løsstruktur til en ejendomsløsning med en fast struktur. I praksis kræver det en konverteringsmotor, der er et komplekst regneark, hvor konflikter bliver fremhævet, og dernæst håndteret via et regelsæt.
Næste trin er dernæst at importere data via rapid start pakker.
Rapid start pakker er gode til relativ simple data imports, men når det kommer et ydelseslinjer, der skal importeres, er det ikke muligt via rapidstart pakker.
Vi byggede derfor en motor til at konvertere ”opkrævningslinjer” til ”ydelseslinjer”. Motoren håndterede desuden det forhold, at Dynamics Property kan lægge ydelseslinjer på såvel lejemåls som lejerniveau, hvor løsningen under udfasning alene kunne lægge linjer på lejerniveau.
Det var vigtigt at få referencerne på plads, når der skulle bogføres åbningsposteringer. Den gamle ejendomsløsning havde et sekvensnummer. Dette sekvensnummer blev anvendt i nummer 2 feltet på henholdsvis lejemål og lejere.
Af andre innovative løsninger kan nævnes at det eksisterende dimensionssæt blev udvidet med en kørsel efter oprettelse af nye masterdata i Dynamics Property. ”LEJEMÅL”, blev omdøbt til ”XLEJEMÅL”. Dvs. LEJEMÅL og XLEJEMÅL kunne ses i samme sammenhæng. På den måde blev der bygget bro mellem nye og gamle dimensioner.
Det er meget svært at estimere denne del, da datakvaliteten er afgørende for hvor kompleks udførelsen er. Et godt råd er at gennemgå data i kildesystemet inden opgraderingsprocessen påbegyndes. Det blev ligeledes udført her, men grundet mængden af data, er det alligevel en kompleks proces. Det er klart at vi løbende supplerer vores værktøjskasse med redskaber til at gøre processen med at flytte stamdata mere strømlinet.
En projektplan bør give speciel opmærksomhed til betalingsservice. Skal der ske ændringer i aftalerne er der et vindue fra ca. den 10. i måneden til ca. 20. i måneden. Husk sidste deadline for opkrævninger, da at afvikle første opkrævningskørsel med succes kræver at planlagte test er udført forinden.
I Dynamics Property, har vi et skema der udleveres under foranalysen til at lægge den rette plan i forbindelse med betalingsservice.
Det kan være en kompliceret proces at opgradere en gammel Dynamics NAV version og samtidig udfase en gammel ejendomsløsning. Det er til at løse hvis, der lægges en detaljeret og afstemt plan. I Dynamics Property har vi erfaring med hele processen, og du/I er velkomne til at kontakte os for afklaring af hvordan I opgraderer til seneste Business Central version og gerne med Dynamics Property som ny ejendomsløsning.