Een computer die vastloopt, een Excel-bestand dat steeds trager wordt of een handmatige handeling die dagelijks terugkomt. Meestal begint een vraag heel concreet. Er is iets dat niet goed werkt en dat moet opgelost worden.
Dat is ook waar mijn achtergrond ligt: uitzoeken waarom iets niet werkt en het weer aan de praat krijgen.
Alleen merk ik in mijn eigen projecten hoe vaak het technische probleem maar een deel van het verhaal is.
Eerst het probleem oplossen
Een trage spreadsheet kan bijvoorbeeld een technisch probleem zijn. Misschien staan er te veel formules in, is de opzet onnodig ingewikkeld of wordt hetzelfde bestand op allerlei manieren gedeeld.
Dan kun je beginnen met optimaliseren. Soms is dat voldoende.
Maar als verschillende mensen gegevens moeten invoeren, iemand anders die gegevens moet controleren en er vervolgens weer een rapport moet worden gemaakt, wordt de vraag interessanter: hoort dit hele proces eigenlijk nog in Excel thuis?
Een kleine applicatie kan dan logischer zijn. Niet omdat een app per definitie beter is, maar omdat je invoer, rechten, controles en rapportage op één plek kunt organiseren.
Dan pas kijken wat slimmer kan
Ik probeer daarom drie vragen uit elkaar te houden.
Wat werkt er nu niet? Dat moet je concreet kunnen aanwijzen. Een foutmelding, vertraging, terugkerende correctie of een stap die steeds vergeten wordt.
Waarom doen we het op deze manier? Misschien is er ooit een handige tijdelijke oplossing bedacht die ondertussen de vaste werkwijze is geworden.
Wat moet er straks beter gaan? Minder handmatig overtypen, meer overzicht, sneller kunnen terugvinden wat er is gebeurd of minder afhankelijk zijn van één persoon.
Die derde vraag verandert regelmatig de oplossingsrichting.
Een voorbeeld uit mijn eigen werk
Bij het bouwen van een urenregistratiedemo ging het niet alleen om een formulier waarin iemand zijn uren invoert. De interessantste vragen zaten eromheen: wie ziet de registraties van een team, wat gebeurt er met verlof en overuren, wie keurt iets goed en hoe blijft achteraf zichtbaar wat er is aangepast?
Een mooi scherm bouwen is één onderdeel. Een proces ontwerpen dat voor medewerkers én leidinggevenden begrijpelijk blijft, is minstens zo belangrijk.
De demo is daarmee een manier om een werkwijze tastbaar te maken, niet het bewijs dat iedere organisatie hetzelfde nodig heeft.
Waar ik heen wil
Ik blijf graag zelf bouwen en technische problemen oplossen. Tegelijk wil ik steeds vaker het hele vraagstuk kunnen meenemen: van de eerste storing of irritatie tot een verbetering die mensen daadwerkelijk gebruiken.
Dat kan een kleine automatisering zijn, een betere inrichting van bestaande software of een eigen applicatie. Soms is de beste uitkomst juist dat er géén nieuw systeem nodig is.
Wat mij betreft is het doel niet meer techniek. Het doel is minder gedoe en een werkwijze die ook morgen nog logisch is.
Verder lezen: Mijn projecten · Technisch sparren · Over mij