Een praktische gids voor het bouwen van interne bedrijfstools: hoe je het proces herkent dat er een nodig heeft, waarom de meeste interne tools worden verlaten, het bouwpad van een rommelige handmatige werkwijze naar software, en hoe je de regie houdt in plaats van er nog een tool bij te leggen die niemand onderhoudt.
Operationele teams, officemanagers, oprichters en groeiende bedrijven die een kritisch proces draaiende houden met handmatige stappen, chatberichten en geheugen.
- Een manier om te zien welk handmatig proces echt een tool nodig heeft
- Een bouwpad van een rommelige werkwijze naar software waar mensen op vertrouwen
- Een interne tool die van jou is en die je kunt aanpassen, niet weer een item op de backlog
Elk groeiend bedrijf draait op een paar processen die nergens wonen: een goedkeuring die via de chat gebeurt, een overdracht die alleen in iemands hoofd wordt bijgehouden, een status waar iedereen naar vraagt omdat hij nergens staat opgeschreven. Daar zijn interne tools voor. De reden dat er zo weinig worden gebouwd is niet langer de kosten; het is dat ze nooit boven de engineering-wachtrij uitkwamen. Deze gids gaat over het zelf bouwen van de juiste, zodat hij er ook echt komt.
Het proces dat een tool nodig heeft, is dat waar mensen elkaar steeds naar blijven vragen, waar het werk stilvalt in afwachting van een overdracht, en dat nu bij elkaar wordt gehouden door chatberichten en geheugen. Als een terugkerende vraag in je team een variant is van "wat is de status van X?" of "wie heeft Y nu?", dan is die vraag de specificatie: de tool bestaat om het antwoord zichtbaar te maken zonder dat iemand ernaar hoeft te vragen.
Interne tools gaan niet over het vervangen van mensen; ze gaan over het wegnemen van de coördinatiebelasting die met het team meegroeit. Een bedrijf van vijf mensen coördineert in zijn hoofd. Een bedrijf van twintig mensen dat nog steeds in zijn hoofd coördineert, besteedt een steeds groter deel van elke dag aan statusupdates, achter goedkeuringen aanzitten en opnieuw uitleggen hoe de zaken ervoor staan. Precies die onzichtbare overhead haalt een gerichte interne tool weg, en daarom mikt de juiste eerste tool op het proces dat de meeste tijd verliest aan coördinatie.
Kies op basis van pijn, eerlijk gemeten. Besteed een paar dagen aan opletten welk proces de meeste "snelle vraagjes" oplevert, de meeste gemiste overdrachten, de meeste "ik dacht dat jij dat deed". De winnaar is zelden het meest complexe proces; het is het proces dat het vaakst wordt gecoördineerd.
Interne tools mislukken om voorspelbare redenen, en die vooraf kennen is grotendeels wat de jouwe in leven houdt.
Een interne tool werkt wanneer hem gebruiken makkelijker is dan hem niet gebruiken. Vraag je voor je een functie toevoegt af of die de tool sneller of trager maakt in het gebruik. De meeste verlaten interne tools stierven aan goede bedoelingen: velden die iemand misschien zou willen, stappen die grondig aanvoelden, en dat alles maakte de dagelijkse route zwaarder tot mensen eraf stapten.
De overgang van een proces-in-de-hoofden-van-mensen naar een tool volgt een betrouwbare volgorde. De eerste stap overslaan is waarom zo veel tools het verkeerde probleem oplossen.
Het slechtste proces van een logistiek team was het uitgeven van apparatuur: wie welk apparaat heeft, sinds wanneer, en of het te laat is, allemaal bijgehouden in een chatkanaal en in het geheugen van één persoon. Een week bekeken kwam het neer op vier dingen: middelen, mensen, uitgiftes en een toestand teruggebracht/te laat. Versie één liet iedereen een apparaat meenemen, toonde de status van de hele vloot op één scherm, en markeerde te late items automatisch. De dagelijkse vraag "wie heeft de scanner?" stopte gewoon, omdat het scherm hem beantwoordde.
Het verschil tussen een interne tool die leeft en een die sterft, zit meestal niet in de functies; het zit in of het team hem in lijn met de werkelijkheid kan houden. Twee dingen beschermen hem.
Dit is waar het proces beschrijven en de tool eromheen laten bouwen wint van zowel een star sjabloon als een eenmalig script van een ontwikkelaar die daarna weer verdergaat. Je krijgt software die is gevormd naar je echte werkwijze, die je kunt blijven hervormen terwijl de werkwijze zich ontwikkelt, zonder je elke keer weer in de engineering-wachtrij te voegen. De tool blijft in leven omdat de mensen die het proces draaien hem eerlijk kunnen houden.
Mik op het proces waar mensen elkaar steeds naar blijven vragen en waar het werk stilvalt op overdrachten. Besteed een paar dagen aan opletten welke daarvan de meeste "snelle vraagjes" en gemiste overdrachten oplevert; het proces dat het vaakst wordt gecoördineerd, niet het meest complexe, is waar een tool de meeste verspilde tijd wegneemt.
Omdat ze een keurige versie van het proces oplossen in plaats van de echte, omdat ze bijwerken trager is dan het chatbericht dat ze vervingen, omdat ze niet kunnen meeveranderen met het proces, of omdat ze een datasilo worden. De oplossing is om eerst het echte werk te bekijken, de tool de snelste route te maken, en hem zelf te kunnen aanpassen.
Alleen het hoofdpad: het record aanmaken, het door zijn echte toestanden bewegen, de status zien en het overdragen, plus de rollen die bepalen wie wat doet en wie alleen hoeft mee te kijken. Voeg de uitzonderingen toe die je echt waarnam, geen bedachte, en laat al het andere voor nadat mensen hem gebruiken.
Niet meer, en hem zelf bouwen heeft een echt voordeel: interne processen veranderen constant, dus een tool die je kunt aanpassen terwijl het proces verschuift blijft nuttig, terwijl een die voor elke wijziging een engineering-ticket nodig heeft uit de pas raakt en wordt verlaten. Beschrijf de werkwijze en houd de mogelijkheid om hem aan te passen.