Evidence-based Decision Making

Introductie

Dit draaiboek kan jou en je organisatie helpen om te komen tot evidence-based decision making in een beslissingproces. Door de hieronder beschreven flow te doorlopen kan je het beslissingsproces van je organisatie verder gaan ondersteunen.

Deze flow detaileert het volledige process doorheen het platform & hoe het een beslissingsproces kan ondersteunen vanuit verschillende perspectieven. De oplossing zal niet één enkele applicatie zijn. Maar wel een combinatie van verschillende aspecten

• Technologische componenten
• Een andere mindset om met data te werken waar data centraal staat
• Gealigneerde bedrijfsprocessen
• De juiste rollen, verantwoordelijkheden & skills

Het schema is opgedeeld in 4 stroken, hieronder in meer detail uitgelegd.

• B voor Business
• D voor Data
• M voor Modellen
• A voor Applicaties

Voor iedere strook zijn een aantal actie gedefinieerd die je kan doorlopen.

De BPMN werd opgesteld in MIRO, een webapplicatie die met een kosteloze licentie toelaat deze BPMN te importeren, te visualiseren en aan te passen. Hoe dit kan, vind je terug op de community van Miro.

Strook 1: Business perspectief

• B01 =  Business Motivation & Goals
  • Specifieer heel duidelijk wat het problem is.
  • Waarom is het relevant?
  • Welke outcome is wenselijk?
  • Hoe zal het resultaat geëvalueerd worden?
• B02 =  Business Glossary
  • Definieer alle termen die gebruikt worden nauwgezet & zo wetenschappelijk mogelijk.
  • Leg alle termen vast (wanneer spreekt men over geluidsoverlast, hoe definieer je ‘bereikbaarheid’ van de horeca, ...).
  • Op welke modaliteiten willen we focussen?
  • Welke metriek gebruiken we, NO2, PM1, PM2.5, BelAQI? Decibels? Is alles even storend? Verkeersintensiteit of snelheid? (e.g. #/min, #/m, ...)
  • Kunnen we patronen afleiden a.h.v. klachten (e.g. welke straten, welke timeslots (AM of PM), ...)?
  • Identificeer de geografische regio (de stad Brugland, of enkele wijken, ...).
  • Zijn er bepaalde standaarden die limieten vastleggen van ‘te veel’ verkeer, lawaai of slechte lucht?
  • Kunnen we dit vergelijken met andere buurten of gemeenten?
• B03 = Zoek data die relevant zijn voor de business case
  • Onderzoek welke data gebruikt kan worden om te bewijzen dat er inderdaad een significant probleem is.
  • E.g. aantal klachten, historische groei van verkeersintensiteit, ...
  • Eerst en vooral data die gebruikt kan worden om het problem te valideren.
  • Dezelfde data zal later het beslissingsproces ondersteunen om het probleem op te lossen.
• B04 = Definieer queries bouwend op de vorige stap
  • Bereken de verkeersintensiteit, luchtkwaliteit & geluidsdruk
  • Gedurende de ochtend-spits vs. de avond-spits
  • Week dagen vs. weekends
  • Hoofdwegen vs. secundaire Wegen
  • Schoolvakanties vs. werkdagen
  • Evolutie over de tijd heen
  • Drukte per wijk ~ De eigenlijke number-crunching

Deze stappen zijn NIET optioneel. Ze zijn cruciaal als startpunt in het ‘evidence-based decision-making’ process.

Strook 2: Data Engineering perspectief

• D01 = Verkrijg de data
  • Krijg toegang tot de data die nodig was om de business case te ondersteunen
  • E.g. downloads, extracts, API, pipelines, ...
  • Linkt sterk met de FAIR data principes
• D02 = Evalueer de datasets
  • Technische stap die hand in hand gaat met B04, schrijf queries
• D03 = Breng de dataset under governance
  • Als beslist wordt dat de dataset inderdaad nuttig is in deze exploratieve fase, kan de volgende stap van start gaan (e.g. raw files on datalake, queried with notebooks)
  • Ze worden onder governance gebracht zodat men ze structureel kan gebruiken, i.p.v. enkel ad-hoc (link met B02)
• D05 = Data collection
  • Kickstart (continue) collectie van data naar het datalakehouse
  • Deze stap vervormt de datasets om tot echte assets
  • De data zal niet enkel in notebooks, gedeconnecteerde analyzes of scripts gelaten worden, maar alles kan hergebruikt worden in toekomstige flows én wordt continu bijgewerkt.
• D06 = Data projection
  • Niet enkel op de brondata, maar ook op de data projections of feature engineering
  • Voer de relevante queries (and possibly persist) uit
  • E.g. The specific query for rainy days, summer holidays, ...
  • E.g. Feature engineering to add relevant predictors

Strook 3: Modelleringsperspectief

• We begrijpen reeds de business case & hebben de data onder controle
  • De business case is uitgedrukt in uniforme termen & wordt geverifieerd door data.
  • De datasets & queries zijn gemanagede assets die transparent & efficient gebruikt kunnen worden.
• M1, M2 & M3 = Zoek & bekom het juiste model voor de use case
  • e.g. Brugge context, multiple model providers evaluated
• M4 & M5 = Probeer modellen & data management te ontkoppelen
  • Geen hidden feature engineering als deel van het model.
  • Werk beter met een transparente signature die inputs vastlegt.
  • Werk niet met hardcoded flatfiles, maar met data under management.
• M6 = Train, score & evalueer meerdere verises van het model
  • e.g. weekdag model vs. weekend model
  • e.g. zomer vs. winter model
  • e.g. fiets vs. auto model
  • e.g. SVM-algorithme vs. FF Neural Network

Strook 4: Applicatie perspectief

• Niet enkel één model run, wel:
  • Meerdere modellen, cross-domain
  • Verschillende scenario’s
  • Of zelfs meerdere versies van hetzelfde model

• Alles werkt transparant
  • Op welke data was het model getraind?
  • Op welke data is het gevalideerd?
  • Welke bewerkingen worden uitgevoerd?
  • Wat kan ik verwachten als output?
• Zodat we het resultaat niet enkel visueel kunnen interpreteren
  • Maar ook wetenschappelijk gebaseerd op de input & output datasets.
  • Dit alles wordt terug gelinkt aan de originele business case.
  • Het is een process dat zich herhaalt en geen lineair process dat je 1 keer doorloopt.