Een tool op een onduidelijk proces zetten digitaliseert vooral de onduidelijkheid. Dezelfde open vragen bestaan nog steeds — alleen nu met een login.
Wat moet vóór de tool duidelijk zijn?
- Welke informatie of prestatie wordt verwacht?
- Wie is verantwoordelijk voor de levering?
- Wie controleert de levering onafhankelijk?
- Wat geldt als geaccepteerd bewijs?
- Wie beslist als iets afwijkt of ontbreekt?
Waarom tooling anders te vroeg komt
Zonder deze afspraken wordt software een extra laag bovenop bestaande e-mails, spreadsheets, SharePoint-mappen en overlegmomenten. Dan wordt niet het proces gestandaardiseerd, maar de versnippering vastgelegd.
De werkelijke winst ontstaat wanneer de organisatie eerst één werkwijze invoert: rollen per item, een helder leverproces en een eenvoudige meting van voortgang en uitzonderingen.
Gebruik eerst wat er al is
Voor de eerste pilot is meestal geen nieuw platform nodig. Als de werkwijze niet functioneert met bestaande middelen, is het onwaarschijnlijk dat een nieuw systeem het onderliggende eigenaarschap oplost.
Pas nadat de werkwijze in een echte transactie of beheerketen standhoudt, wordt duidelijk welke functionaliteit werkelijk ontbreekt en dus productiseerbaar is.
De volgorde
- Norm en scope vastleggen
- Rollen en bewijs definiëren
- Eén proces daadwerkelijk uitvoeren
- Meten waar afwijkingen ontstaan
- Leren en standaardiseren
- Pas daarna tooling selecteren of bouwen
Veelgestelde vragen
Betekent dit dat software niet belangrijk is?
Nee. Goede tooling kan snelheid, audit trail en schaalbaarheid verbeteren. Maar pas nadat duidelijk is welk proces zij moet ondersteunen.
Kun je hiermee in Excel of SharePoint beginnen?
Ja. Voor een eerste procesproef is bestaande tooling vaak juist nuttig, omdat dan zichtbaar wordt of de werkwijze zelf klopt.
Wanneer is nieuwe software wel logisch?
Wanneer een bewezen werkwijze structureel wordt geremd door handwerk, ontbrekende integraties, onvoldoende audit trail of schaalproblemen.
PropSettle