Terug naar CoDesk homepage
Link naar het CoDesk webmail portaal
Link naar het CoDesk CoDrive portaal
Link naar het CoDesktop  WebAccess portaal
Link naar het CoDesk SSPR portaal
Voor alle vragen over modern workplaces, remote werken, veilig thuiswerken en cloud

Je zit op goud (zonder het te weten)

door | 14 april 2021

Data is het nieuwe goud wordt er wel eens geroepen. Vraag maar aan Google. Of lees de discussie over de data die autofabrikanten verzamelen met hun nieuwe auto’s die contant online zijn en bergen data verzamelen. Nuttig voor verzekeraars, makers van navigatiesystemen en garagebedrijven, maar wie mag er nu wel of niet bij? Interessante vragen!

Data is binair goud

Wij als CoDesk zijn ook altijd bezig met data: ‘meten = weten’. Dat hoort ook wel bij het soort werk wat wij als CoDesk doen. Het is ook wel een beetje een ‘nerd’ dingetje om alles te willen uitdrukken in vastomlijnde eenheden.
We zijn dus best goed in het geautomatiseerd samenbrengen van data uit diverse bronnen en op diverse manieren.

Voor veel van onze klanten is hun core business veel minder bepaald door keiharde grenzen of ‘performance indicatoren. Wat klanten vaak wel aanvoelen is dat ze toch op berg data zitten waar voordeel uit te halen is. Maar meer in de zin van: wat laat ik liggen?

Goudkoorts

Zoals je op TV ook wel ziet: goud zoeken vraagt veel tijd en vooral veel apparatuur en kennis.

Het goud voor onze klanten zit ergens verscholen zit in databases van hun applicaties. Vaak weten ze vaak ook nog wel waar. Ze missen alleen de spullen om er makkelijk bij te komen.

Binair goud

En zoals met een echte goudkoorts, zijn er diverse partijen die zoeken naar de beste manier om het goud te delven. En mensen die daar weer variaties op verzinnen.
Voor een aantal klanten hebben we nu diverse verzamelplaatsen van data draaien onder de noemer data warehouse, data repository, cube, container en nog meer mooie termen.

Het idee is altijd hetzelfde: vanuit verschillende bronnen die data bij elkaar brengen waar je echt wat mee kan en daar dan een rapportagetool tegen aan zetten.

Goud geld

Wij worden regelmatig (en steeds vaker eigenlijk) betrokken bij projecten van klanten om hun data te ontsluiten. Niet voor bouwen van rapportages of het functioneel beschrijven van de informatiebehoefte, want dat kunnen klanten en applicatiebeheerders doorgaans prima zelf.  Zodra de tools er eenmaal zijn dan tenminste…

Praktijk is dat klanten en/of hun adviseur een poging hebben gedaan om een projectplan te maken, dan bij ons komen om de bedachte randvoorwaarden te implementeren en dat wij dan lastige vragen gaan stellen.
Wij willen helemaal niet lastig te doen, maar je wil ook niet kijken naar ongeluk in slow motion. En dat is wel wat er zonder een compleet plan gebeurt. Dan valt het project in duigen of wordt te laat opgeleverd, worden er bedrijfskritische processen geraakt of ligt er komt data op straat. Dat soort dingen kost geld, veel geld!

Op basis van onze ervaring (en de ‘vervelende’ vragen die we dan stellen) hebben we checklist gemaakt van wat je moet weten voor je aan de slag gaat met ontginnen van je data.

Wat wil je laten zien?

 De eerste vraag is: wat  wil je laten zien? Moeten het rapportages in detail zijn?  Of juist een dashboard met kengetallen? Ga je het printen? Laten zien op een monitor aan de muur?
Dus de vraag is: wat is de functionele wens?  

Waar staat jouw data?

Een beetje datacollectie kent meerdere bronnen (applicaties). En zoals steeds vaker staat er data zowel ‘on premise’ of in de cloud. Maar wat staat waar precies?
En als je dan weet waar, is het datamodel beschreven? Het maakt het bouwen van een rapportages een stuk makkelijker als je weet welke data waar staat en hoe dat koppelt met data in andere tabellen.

Hoe kom je bij die data?

Als je waar de data staat, dan is de volgende vraag: hoe kan je die data benaderen. Kun je de data direct benaderen omdat je bij de database(server) kan? Is er een ODBC-koppeling mogelijk? Of kan het alleen op basis van een API?

Wanneer haal je data op?

Als je dan bij de data kan, dan is de vraag wanneer je die data op gaat halen. Want soms kan je door het ophalen van data uit de database de records ‘locken’.  Of je hindert de performance van database zodanig dat je een productieproces in de weg zit. Het draaien van een verloning of facturatie run zijn van die beruchte momenten.

Hoe actueel moet het zijn?

In relatie tot de vorige vraag: hoe oud mag de data zijn? Realtime info zie je doorgaans in een applicatie zijn, de trends en correlaties bekijk je eerder in retrospectief. Dus hoef je ook niet steeds de nieuwste data op te halen. Dat geeft je wat ruimte om data op te halen buiten de tijden waarop je de productie in de weg zit.

Wat haal je op? Wat knoop je aan elkaar?

Het heeft ook geen zin om alles op te halen. Systeemtabellen heb je niet nodig. En veel kolommen in tabellen zijn bedoeld voor toepassingen die jij niet gebruikt in jouw bedrijf. Dus zonde om dat nog een keer dubbel op te slaan.

 

En als je data ophaalt en elders inleest, dan is dat ook een ideaal moment om data beter leesbaar te maken. Daar moet je vaak zelf aan denken want we weten dan externe specialisten vaak geen directe feeling hebben voor jouw ( functionele) behoefte aan informatie. Dus die gaan de link tussen verschillende tabellen niet snel zelf maken. En die link is nog lastiger als je gegevens uit meerdere bronnen haalt.
Dus zaak om dat duidelijk te formuleren en te delen met de mensen die met de data aan slag moeten.

Waar ga je het neerzetten?

Het is heel triviaal misschien, maar waar ga je het neerzetten? Lijkt een simpele vraag maar het raakt dingen als capaciteit, toegang, beveiliging en kosten.

Welke licenties heb je daar voor nodig?

Voor de database waar je alles onderbrengt heb je mogelijk licenties nodig. Dat geldt ook voor de tools waar je data mee bewerkt.

Hoe controleer je de integriteit?

Heb je eenmaal alles aan de praat, dan is het wel zaak om te controleren of alles het ook blijft doen. Worden alle import van datasets netjes gedraaid? Zijn er geen datasets beschadigd? Hoe controleer je dat ? Elke dag alles met de hand nalopen is ook zo wat. Dus je moet iets van monitoring bedenken.

Hoe ga je het beveiligen?

De gegevens die je uiteindelijk hebt samengebracht zijn is de set waar je echt wat mee, kan wat echt waarde heeft. Dus de kroonjuwelen zeg maar. Dat vinden andere mensen dus ook vast interessant. Beveiliging is dan nog belangrijker dan per bron al het geval is.

Hoe en aan wie stel je het beschikbaar?

Net als bij bouwen van een huis, je maakt eerst het ontwerp en daarna ga je pas bouwen. Dus je moet nadenken over de deuren, ramen en en (vooral) het hang- en sluitwerk.
Vertaald naar een database moet je nadenken over groepen, rollen en rechten.

De gulden middenweg

Eenmaal de ‘lastige’ vragen voorbij  is het tijd voor de volgende stap: het daadwerkelijk regelen van de oplossing. Nou zijn leveranciers van applicaties vooral goed in de applicatie bouwen en  BI / data science specialisten goed in data verwerken tot inzichten. Wat daartussen zit is de infrastructuur met alle bijbehorende instellingen van die specifieke inrichting. Dat is niet de expertise van de leveranciers van applicaties en de  BI c.q. data science specialist verwacht dat de data ‘gewoon’ beschikbaar is en de benodigde tools al geïnstalleerd staan.  Kortom: daar mist een stukje.

Het missende stukje techniek is wat wij leveren door tussen klant (of doorgaans de applicatieleverancier) en de rapportage-specialist te gaan staan.  We regelen dan bijvoorbeeld de benodigde routes, installatie van de tools , beveiliging, automatisering van ophalen en verwerken van data en vaak nog een stuk monitoring. De gulden middenweg zeg maar.

En wat ook redelijk standaard is: eenmaal onderweg ontwikkelen zich nog wat aanvullende wensen: als een klant eenmaal ziet dat A mogelijk is, kan B dan ook??
Omdat dit  mechanisme voor ons een gegeven is hebben we daar in de opzet van onze oplossingen al rekening mee gehouden en kunnen we leuk schakelen met beide kanten.

Gouden tandwielen

Koeien met gouden hoorns

Wat we willen zeggen is dat inzicht in eigen data zeker goud waard kan zeggen, maar dat de weg er naar toe te vaak wat simplistisch wordt voorgesteld. Er worden koeien met gouden hoorns beloofd, maar als je zelf het goud moet betalen is het zonde van het geld.

We denken daarom graag met je mee en in de tijd van 1 kopje koffie kunnen we je vaak al vele uren extra werk besparen.

Overleg onder het genot van een kopje goud melange iets voor jou?

Neem contact met ons op!
Bel 088-1881999 of mail sales@codesk.nl

Checklist data

Voor het gemak nog even de herhaling van de dingen waar je moet denken:

  • Functioneel plan
  • Waar staat de data
  • Wie heeft er kennis van het datamodel
  • Wie kan er toegang regelen
  • Wat wil  je wanneer verwerken
  • Waar ga je het (veilig) laten
  • Hoe en en aan wie publiceer je de resultaten
  • Wie gaat het bewaken  / Monitoring