De frictie schuilt in de schakels

"We hebben te veel tools."

Herkenbaar? Sta me toe dat even van tafel te vegen. Er zijn typisch een van twee dingen aan de hand wanneer je een overaanbod aan tools binnen je organisatie vaststelt.

De eerste is dat je overtuigd bent geraakt van een oplossing die een of meer van de bestaande tools kan vervangen. In de praktijk blijkt het toch niet helemaal zo te lopen als je jezelf had voorgesteld, waardoor je blijft vasthouden aan de oude oplossing naast de nieuwe oplossing. Het resultaat is een eeuwige tweespalt, met duplicatie en verwarring als gevolg. De juiste aanpak is een stap terugzetten en nuchter evalueren welke doelen bereikt zijn en waar het initiatief tekortschiet.

Hou daarbij de sunk cost fallacy in je achterhoofd. Doe je dat niet, dan ga je ervaren hoe passief de dooddoener "dit is zo historisch gegroeid" werkelijk klinkt.

De tweede is een stuk interessanter. De tools doen hierbij wel in grote mate wat je ervan verwacht, maar ze gaan net niet ver genoeg. Je moet gegevens eerst downloaden of bewaren, wachten en dan openen in de volgende applicatie. Je moet zelf enkele stappen uitvoeren voordat het eindresultaat overhandigd kan worden aan een medewerker, klant of leverancier.

Daar loopt het meestal stroef. Daar kan je vaak winst boeken.

De perfecte applicatie

Unix was een van de eerste besturingssystemen (of operating systems of OS), lang voor Windows en macOS bestonden. Een belangrijk fundament van de Unix-filosofie luidt als volgt:

Write programs that do one thing and do it well.

Kort en vrij vertaald betekent het dat elk programma duidelijk afgebakende functionaliteit moet bieden, en dat programma's onderling op een gestandaardiseerde manier moeten kunnen communiceren. Zo kan de output van het ene programma rechtstreeks aan het volgende programma doorgegeven worden, die output weer aan de volgende, etc.

Je kan dan pipelines bouwen die pakweg vertrekken van een Excel-bestand en eindigen met een gepersonaliseerd Word-document per klant. Met 1 commando.

Een simpele pipeline van drie programma's

Als je wat bekend bent met Word en Excel zal je waarschijnlijk opmerken dat je dat al met de "Mail merge"-functionaliteit in Word kan doen. Exact!

Stel je nu voor dat je op een gelijkaardige manier de output van andere programma's dan Excel als input kan gebruiken voor een ander programma dan Word. Dat het publiceren van je bijgewerkte prijslijst als pdf- én xlsx-bestanden kan gebeuren met een enkel commando.

Het principe geldt nog steeds

Het waren andere tijden en ze hadden allerlei extra beperkingen om zich zorgen om te maken, maar het principe, de filosofie, van de grondleggers van moderne computersystemen blijft overeind.

Misschien ben je het oneens. Je intuïtie zegt wellicht dat alles in 1 softwaretoepassing kunnen doen altijd een stuk efficiënter is dan switchen. Aanmelden, openen, opslaan, sluiten. Dat is waar. Als, en enkel als, die ene toepassing werkelijk alles doet wat je nodig hebt op de manier die jij vooropstelt. Als het de perfecte applicatie is voor jouw organisatie.

Aangezien je een artikel over frictie leest, neem ik aan dat dat niet het geval is.

Je intuïtie heeft geen rekening gehouden met deze voorwaarde: programma's moeten samenwerken, met een standaardmanier om gegevens onderling uit te wisselen.

Integraties kunnen eenvoudig zijn

Logisch dat je dat over het hoofd ziet. Programma's laten communiceren is an sich al een miljardenbusiness.

Integratieprojecten lopen vaak op in kosten vanwege gebrekkige documentatie, ontbrekende of complexe standaarden, beperkte mogelijkheden en continue churn. Want er komt een nieuwe versie van toepassing A aan en de integratie met toepassing B moet aangepast worden. In plaats van twee losse toepassingen heb je nu plots drie toepassingen waar je je om moet bekommeren.

Maar wat als die integraties, die schakels, niet zo complex en duur zouden moeten zijn? Wat als je elk softwarepakket enkel en alleen zou gebruiken voor wat het het beste kan en de frictie, om van toepassing A naar B te gaan, naar praktisch nul zou kunnen herleiden?

De schakels

Ons uitgangspunt is simpel: elk stukje van je proces, van je ketting, moet naar best vermogen afgestemd zijn op die stap in het proces. Als dat goed zit, blijft er slechts 1 punt van frictie over. Dat is het schakelen. Dat is het switchen. Dat is:

Een concreet voorbeeld

Bij een klant (een bedrijf dat software as a service of SaaS aanbiedt) zag het offerteproces er oorspronkelijk als volgt uit:

  1. Er wordt een kopie gemaakt van een eerdere offerte (docx).
  2. De verkoper opent het document en past de variabelen aan naar de gegevens van de nieuwe prospect. Die gegevens komen uit notities, e-mails en/of het KBO.
  3. Alle velden worden daarna bijgewerkt met een klik op de knop. Behalve in de footers, want Word heeft zo zijn eigenaardigheden.
  4. Het document wordt omgezet naar pdf, via e-mail doorgestuurd naar de prospect en in een gedeeld bestandssysteem gearchiveerd.
Word document properties
Custom properties in Word

De grootste overlast schuilt in stappen 2 en 3. Het wijzigen en toepassen van properties in Word is op zijn zachtst gezegd omslachtig en foutgevoelig.

De regel intern was bovendien dat alle relevante bedrijfsgegevens sowieso in het CRM geregistreerd moesten worden. Het CRM bevatte geen offertemodule en op zich werkte de flow met de bestanden best goed.

Maar het kon wel geoptimaliseerd worden.

De aanpak

  1. Er werd een beheerscherm toegevoegd aan het SaaS-product dat toeliet de relevante gegevens van de prospect uit het CRM te halen. Dit kwam sowieso ook van pas om de onboarding van nieuwe klanten te versnellen.
  2. Er werd een custom desktopapplicatie ontwikkeld die die gegevens in een bestaand Word-bestand kan verwerken en zo een gloednieuw Word-bestand genereert.

Het nieuwe proces had deze vorm:

  1. De verkoper registreert de relevante gegevens in het CRM.
  2. De link naar de prospect in het CRM wordt ingevoerd in het beheerscherm (copy-paste) en met een druk op de knop wordt meteen een bestand gegenereerd. Dat bestandstype is gekoppeld aan de custom applicatie, die zo automatisch opent en de verkoper vraagt een offertesjabloon te selecteren.
  3. Na bevestiging wordt de offerte in docx-formaat op het bureaublad geplaatst.
  4. Is identiek aan punt 4 uit het originele proces: omzetten naar pdf, doorsturen via e-mail en archiveren.

Op het eerste zicht zal je denken:

Dat ziet er eigenlijk exact hetzelfde uit. Dat zijn nog steeds vier stappen!

Het is niet het aantal stappen dat telt. Het is de frictie die elk van die stappen oplevert en die ligt beduidend lager in het nieuwe proces.

De werkelijke vooruitgang

De eerste stap is sowieso een win-win. Zoals aangehaald was de verwachting intern dat de verkopers de gegevens van hun prospects en klanten up-to-date hielden in het CRM.

In de nieuwe aanpak wordt dat stap 1, want je geeft de verkoper ook een incentive: sneller een offerte maken! Software is er immers niet alleen om je workflows te automatiseren. Het is er ook om de interne werking te uniformiseren.

Stap 2 bestaat uit:

  1. De URL kopiëren van de relevante pagina in het CRM, die je hebt openstaan.
  2. Op de bookmark voor het offerteformulier in het product klikken; eventueel aanmelden als dat nog niet gebeurd is (via SSO, gedeeld met het CRM).
  3. De URL in het enige invulveld plakken en op Enter of de knop duwen.

Dat is alles. Versus het eerder drie niveaus diep graven om het juiste scherm van Word naar boven te halen en daar veld per veld aan te passen. Je moet je ook niets meer aantrekken van het updaten van die velden in het document en de footer.

Het proces had er ook anders kunnen uitzien. Of verder worden geoptimaliseerd. Dit was op basis van alle parameters exact wat het moet zijn: goed genoeg.

En bij jouw organisatie?

In het voorbeeld werd een kleine desktopapplicatie op maat gemaakt voor de verkopers. Dat kan snel en had in deze situatie enkele praktische voordelen t.o.v. een webtoepassing.

Dit is niet per se nodig om de frictie in jouw processen te verlagen. Het illustreert wel dat niet elke integratie moet bestaan uit obscure, interfaceloze software die ergens op een server draait. Die "magisch" zijn ding doet, tot het plots niet meer werkt en er niemand is die begrijpt waarom alles stropt.

Als je vaak dezelfde stappen herhaalt, bestaat er ongetwijfeld een manier om dat te herleiden tot minder stappen, snellere acties of minder cognitieve overhead. Dat soort ingrepen verlaagt de frictie. De uitdrukking "het loopt als gesmeerd" is geen toeval. Soms moet je wat smeersel toevoegen om alles soepel te laten lopen.

Het moet geen complex maandenlang project zijn. Het moet zelfs geen team vereisen.

Smeren

Niet overtuigd? We ronden af met enkele concrete, herkenbare en behapbare voorbeelden. De focus ligt daarom op kleine verbeteringen die je, als je dat zou willen, meteen zou kunnen doorvoeren zonder software te moeten aankopen.

Er zijn immers tal van "geheime" applicaties in en voor de populaire besturingssystemen te vinden die je processen kunnen versnellen. Ook je dagelijkse werk kan hiermee vaak vereenvoudigd worden.

Repetitieve teksten inkorten

Je kan vast wat gegevens bedenken die je dikwijls moet invoeren in formulieren, berichten of documenten. Denk aan bankrekeningnummers, BTW-nummers en adressen.

Bespaar jezelf wat tijd en moeite door tekst automatisch te laten vervangen. Zo kan je pakweg de tekst !btw koppelen aan jouw BTW-nummer: typ daarna !btw in een tekstvak en het wordt meteen vervangen door het BTW-nummer.

Dit is veruit de makkelijkste boost voor je productiviteit, want het zit ingebakken op praktisch elke smartphone en op macOS. Voor Windows kan je (gratis) Autohotkey gebruiken.

De voordelen:

De nadelen? Wel, de enige die ik kan bedenken is dat je na verloop van tijd de gegevens misschien niet meer uit je hoofd kent. Toegegeven: op Windows is het opzetten een tikkeltje stroever, maar dat doe je maar 1 keer.

Simpele stappen automatiseren

Stel dat je regelmatig een document voorgeschoteld krijgt dat je moet:

Het nakijken vereist waarschijnlijk jouw aandacht, maar de andere stappen kunnen snel en secuur geautomatiseerd worden.

Shortcuts, Automator en Autohotkey icons

Gebruik je macOS, dan kan je kiezen uit Shortcuts (Opdrachten in het Nederlands; ook beschikbaar op je iPhone en iPad) of Automator. Je combineert hierin acties van verschillende apps tot een workflow, zodat je zelf die stappen niet meer moet doorlopen. Gewoon de shortcut runnen, of de workflow triggeren vanuit de gewenste app of door rechts te klikken op het bestand.

Op Windows kan je opnieuw Autohotkey gebruiken. Het kan zelfs muisklikken simuleren; je kan het dus voor jou op knoppen laten duwen!

Gegevens uit een website halen

Je zal misschien wel eens de inkoopprijs van een specifiek product bij je leverancier moeten opzoeken in hun online portaal. Typisch ga je:

Indien "wel eens" uitgegroeid is tot "erg vaak": dit kan geautomatiseerd worden, onafhankelijk van je leverancier!

Bijvoorbeeld met een browserextensie. Die kunnen naast het stroomlijnen van processen eveneens een heleboel online frustraties wegnemen. In een vroegere post zie je hoe ik een browserextensie ontwikkelde om eindelijk een onderscheid te kunnen maken tussen verschillende Gmail tabs.

Voor het geschetste scenario is zo'n extensie waarschijnlijk overkill; je kan hetzelfde resultaat behalen met de reeds aangehaalde tooling en programma's die je vandaag al gebruikt.

"Marginal gains"

Misschien lijken de voorgestelde scenario's wat te min om te automatiseren. Ze kosten niet echt veel tijd. En, ach, je moet er niet echt zo hard bij nadenken. Ga je het echter allemaal optellen, dan kan de impact wel significant zijn.

Dat is het principe van marginal gains. Kleine schakels in je processen aanpakken zorgt voor kleine verbeteringen als je ze geïsoleerd bekijkt. Het totaalbeeld: alles loopt net wat vlotter en meer uniform. De seconden en minuten die je links en rechts bespaart, resulteren in uren extra tijd.

Het enige dat je nodig hebt is wat smeersel. Dit soort verbeteringen ligt tegenwoordig binnen handbereik van iedereen die een beetje onderlegd is. Bedenk wel dat de helft van de oplossing zit in weten dat die bestaat, en de andere helft in de (juiste) implementatie en het testen. Of je kan een beroep doen op Roam en we bekijken het samen.