De snelste route lijkt alles \u00e9\u00e9n op \u00e9\u00e9n naar Fabric overzetten: dezelfde bronnen, dezelfde modellen, dezelfde koppelingen. Maar dan verhuist elke omweg mee, inclusief dat ene script dat niemand meer durft aan te raken. Je krijgt hetzelfde platform op een nieuwe plek. De rapportages blijven even traag en de discussies in het bedrijf even lang. De migratie is juist h\u00e9t moment om je datamodel opnieuw te ontwerpen. Doe je dat niet aan het begin, dan doe je het nooit meer.<\/p>\n
De redenering klinkt logisch: er is een datateam, dus dat team bouwt het platform wel. Maar een platform bouwen is iets anders dan het daarna draaiend houden. We zagen een datateam dat lang met de basis bezig bleef, terwijl de vragen uit de operatie en de planning zich opstapelden. Zes maanden werk. De business wachtte nog op het eerste rapport. Dat team was niet te klein voor het werk, het was te klein om het werk en de ambitie tegelijk waar te maken.<\/p>\n
Kennis van Fabric is nog jong en schaars. Wie zelf bouwt, zoekt dus dezelfde mensen als elke andere organisatie met hetzelfde plan. De specialist die je inhuurt, vertrekt op een dag weer. Wat achterblijft is een platform dat niemand in huis nog helemaal doorgrondt. Daar komt bij dat Fabric doorlopend verandert: nieuwe functies, aangepaste grenzen aan opslag en rekenkracht, en iemand moet dat blijven volgen. Dat is geen project met een einddatum, maar een vaste last die je in de businesscase zelden terugziet.<\/p>\n
Wie welke data mag zien, wie er eigenaar van is en hoe je voldoet aan wet- en regelgeving: dat leg je vast voordat je bouwt of je regelt het eigenlijk nooit meer. \u201cWe documenteren en beveiligen later wel\u201d klinkt redelijk, maar in de praktijk komt daar weinig van terecht. Governance die je er achteraf in bouwt blijft een inhaalslag en ondertussen ontstaan er onbedoelde datalekken, zoekgeraakte informatie en compliance-risico\u2019s. Groei door overnames maakt dat extra zichtbaar. Elke overname brengt een eigen boekhoudpakket, een eigen urensysteem en eigen rechten mee, terwijl de directie volgende maand de groepscijfers wil zien.<\/p>\n
Een migratie verplaatst je data, maar brengt die niet vanzelf samen. Systemen die nu langs elkaar heen werken, blijven dat na de overstap nog steeds doen. Tenzij je ze samenbrengt in \u00e9\u00e9n model, blijft de versnippering bestaan. Die versnippering kan op verschillende plekken ontstaan. Bronsystemen groeien jarenlang door, totdat niemand het overzicht nog heeft. Daarnaast zijn er vaak losse pakketten voor uren, klanten en facturatie die nooit op elkaar zijn afgestemd. Het gevolg? Vijf systemen leveren al snel verschillende definities op. Het MT discussieert daardoor over de cijfers, terwijl het gesprek eigenlijk over de koers zou moeten gaan. Dat is geen rapportageprobleem, maar een fundamentprobleem. Hoe je dat fundament inricht, bepaalt uiteindelijk of je \u00e9\u00e9n gedeelde waarheid overhoudt of vijf verschillende.<\/p>\n
Je kunt een technisch perfect werkend model bouwen dat de business toch links laat liggen. Simpelweg omdat het model niet de taal van de organisatie spreekt. Neem omzet. Als die in je model TBLORD<\/em>EXT_3 heet, exporteert finance de data naar Excel en bouwt daar een eigen waarheid op. Daarom is een model in de begrippen van de organisatie zelf zoals omzet, marge en declarabiliteit geen luxe bovenop de migratie. Het bepaalt of je platform straks daadwerkelijk wordt gebruikt of juist wordt omzeild.<\/p>\n Wie deze drie vragen scherp beantwoordt, haalt de grootste risico\u2019s uit de migratie voordat er \u00e9\u00e9n euro is uitgegeven. Meer weten over de meestvoorkomende valkuilen? In ons e-book staan de tien die wij het vaakst tegenkomen, elk met hoe je hem aanpakt en een tip die je direct toepast.<\/p>\nDe drie vragen die je beantwoordt v\u00f3\u00f3r de start<\/strong> <\/h2>\n
\n