Integratie front­ en back­office is mengen van olie en water

Echte front­officeprocessen zijn in principe vanuit de klant vormgegeven. De processen en de systemen zijn zo ontwikkeld dat de klant de bediening of zelfbediening als passend of prettig ervaart. ‘Usefulness’ heet dat in internationaal geaccepteerde termen. Als dat niet het geval is, bestaat de kans dat de klant de systemen gaat mijden met alle negatieve commerciële gevolgen van dien. Dat ‘rekening houden met de klant’ heeft een aantal consequenties, die de procesarchitectuur in de front­office sterk beïnvloeden. De klant bepaalt in feite wat in welke volgorde en in welk tempo wordt gedaan. Verder zijn de systemen gedimensioneerd op piekbelasting, die meestal maar gedurende korte periodes bestaat. Er komen ook vele uren voor dat de systemen minder te doen hebben en zelfs staan te niksen. Daar maakt echter niemand een probleem van. De processen en systemen zijn: ‘klant­efficiënt’. Echte back­officeprocessen zijn in principe vanuit de gebruikte resources (mensen, systemen) vormgegeven. De processen zijn zo ontwikkeld dat deze resources vol of in ieder geval zo vol mogelijk worden benut. Dat heeft een aantal consequenties, die diametraal staan tegenover die van de front­office. De klant kan geen of weinig invloed uitoefenen op de volgorde of het tempo van de werkzaamheden. In de back­officeprocessen is de klantorder vaak niet meer eenvoudig te traceren voordat alle deeltaken zijn verricht. De nadruk ligt op het bezetten van de resources, men zou deze processen en systemen ‘resource­efficiënt’ kunnen noemen. Kort gezegd komt dit back­officeparadigma neer op de slogan: ‘Don’t waste my resources’. Dit verschil tussen front­ en back­ officeprocessen heeft grote gevolgen voor de potentiële prestaties van beide typen processen. Bijvoorbeeld een bedrijfsproces voor de levering van een hypothecaire lening in de back­officestijl, heeft een doorlooptijd van minimaal drie weken, terwijl zo’n lening in de front­officestijl vormgegeven in ongeveer 1,8 uur kan worden afgehandeld. In de back­officestijl sleept de case zich voort van bewerking tot bewerking en is er veel dode tijd in het proces. Dat is het offer (in het nadeel van de klantbediening) dat de organisatie betaalt voor de hoge bezettingsgraad. In de front­officestijl kan de hypotheekadviseur de klant maximaal bedienen in de tijd die de klant daarvoor over heeft. Geheel in stijl, zou de slogan kunnen luiden: ‘Don’t waste my customer’s time’. Om tevredenheid over de bediening bij de klant te bereiken, betaalt de organisatie een offer in de vorm van leegloop, maar dat kun je er soms voor over hebben. Samengevat komt het verschil tussen beide inrichtingsprincipes neer op de vraag of een leverancier het zich kan permitteren zijn resources te verkwisten. In dat geval kan hij zijn processen in front­officestijl inrichten. Zo niet, dan moet hij de tijd van zijn klant verkwisten. Moeilijk Het grote verschil tussen ‘zuinig zijn met resources’ en ‘zuinig zijn met de tijd van de klant’ geeft precies aan waarom het zo moeilijk en soms onmogelijk is om front­ en back­officesystemen met elkaar te verbinden. In de praktijk zien we dat ook aan de soms totaal van elkaar verschillende tagsystemen in productieketens. Retailers willen barcodes die zij aan de kassa kunnen lezen en waarmee zij kunnen vaststellen wanneer welke klant wat koopt, terwijl ze voor de bewaking van de voorraad, gekoppeld aan de groothandel, weer andere systemen gebruiken. Groothandelsbedrijven willen immers inzicht in hun voorraden (resources) en die van hun afnemers en gebruiken daarvoor andere systemen. De gebruikte entiteittypen, de tijdbasis, de beschikbaarheid en de belastbaarheid van de systemen kunnen van een heel andere orde zijn en koppeling is dan soms gewoon onmogelijk. Dit probleem ­ zo constateerde HotOrange.com indertijd ­ maakte het onmogelijk om bijvoorbeeld uitverkochte items automatisch en binnen een redelijke tijd van de website te halen, waardoor de orders bleven binnenstromen terwijl de magazijnschappen leeg waren en de aflevering van de goederen dus een (fataal) rommeltje werd. Maar om direct te kunnen signaleren wanneer een item uitverkocht is, moet je een veel sneller opererend magazijnsysteem hebben (inclusief het menselijk signaleren en handelen) en een directe link hebben met de database achter de website. En dat kost geld. De problematiek van front­ en back­office­integratie is niet nieuw. Vergelijkbare problemen deden zich jaren geleden al voor toen de toenmalige minister van Verkeer, mevrouw May­Weggen, besloot dat automobilisten bij de derde aanhouding wegens te hard rijden hun auto zouden moeten inleveren. Het probleem is natuurlijk: hoe kan een agent staande aan de snelweg binnen redelijke tijd ­ enkele minuten kun je iemand nog wel aanhouden ­ te weten komen hoeveel zaken er al lopen tegen de automobilist. Zat hij of zij wel alle keren zelf achter het stuur? Lopen er nog bezwaarschriften? Zijn er nog voorvallen onder de rechter? Kortom: een onmogelijke zaak, hoe slim ook bedacht. De benodigde informatie is er wel, maar kan niet eenvoudig beschikbaar worden gemaakt. De verschillen tussen front­ en back­office zijn ook te herkennen aan andere dan alleen technische en logistieke verschillen. In resource­efficiënte bedrijven hebben medewerkers die dicht bij die resources staan, hoog aanzien en vaak ook hogere salarissen. Piloten bijvoorbeeld zijn cruciaal voor de efficiënte omloop van het materieel, evenals treinmachinisten bij de spoorwegen. Hun werk bepaalt vaak ook de cultuur van de onderneming. Grote organisaties van het resource­efficiënte type hebben er altijd moeite mee stappen te maken in de richting van het andere paradigma. Treintaxi Het probleem van veel bedrijven is dat ze door front­ en back­office­integratie ‘stuck­in­the­middle’ raken als ze proberen de kaasschaaf te hanteren en beide paradigma’s gedeeltelijk te verwezenlijken. Zoiets als de treintaxi, die het midden wil houden tussen groeps­ en individueel vervoer. In het openbaar vervoer probeer je zoveel mogelijk passagiers mee te nemen op één motor: je minimaliseert motorkracht, of ‘tractie’ in spoorwegtaal. In particulier vervoer speelt dat niet. Auto’s maken maar weinig bedrijfsuren en ook taxi’s moeten soms lang wachten op nieuwe klanten. Het gaat erom dat de klant volledig zelf kan bepalen wanneer en waarheen wordt gereden. De treintaxi is geen nieuw paradigma, maar zit er tussenin. Het is treintje spelen in een auto en dat kan maar op een beperkt aantal plekken in het land en met duidelijke grenzen aan het te bestrijken gebied. Zoiets doet zich bijvoorbeeld voor in het gemiddelde callcenter, ooit bedoeld om de klant altijd, sneller en beter te woord te kunnen staan (don’t waste my customer’s time), maar dat daar zelden in lijkt te slagen. De allerbelangrijkste reden daarvan is dat bedrijven op den duur kennelijk toch weer gaan letten op de inzet en bezettingsgraad van de mensen. Daardoor moeten zij het bandje ‘helaas zijn al onze medewerkers in gesprek, wij zullen u zo spoedig mogelijk te woord staan’ veel te vaak en veel te lang afspelen. Ik heb zelf eens bijna drie kwartier aan de telefoon moeten wachten voordat ik aan de beurt kwam voor een ordernummer voor een printerstoring. Dat is totaal in tegenspraak met de bedoeling van callcenters (de telefoon mag maximaal vier keer overgaan) en het is dus ook niet veel meer dan resource­efficiëntie in een modern jasje. Soms gaan bedrijven om redenen van kostenbesparing over tot outsourcing van hun callcenter en zij delen dan de telefonisten met een aantal andere bedrijven, maar het probleem is dat ze daarmee volledig in het verkeerde paradigma zijn beland, omdat nu ook de kwaliteit van de bediening terug gaat lopen. Hoe je ook probeert die telefonisten te instrueren, je bent maar één van de opdrachtgevers. Om dat kwaliteitsverlies wat te verminderen, richten sommige bedrijven dan weer een eigen ­ tweedelijns ­ callcenter in, waar de moeilijkere vragen kunnen worden beantwoord. Kortom: men meandert een beetje tussen de paradigma’s: de treintaxi. Piekbelasting Veel dotcomwinkels zijn slechte compromissen van beide paradigma’s. De website is duidelijk vanuit het principe van klant­efficiëntie opgezet. De computers zijn 7 x 24 uur beschikbaar en kunnen een groot aantal klanten tegelijk bedienen, zonder dat die dat merken. De functionaliteit is optimaal voor de klant ingericht en de systemen zijn op piekbelasting gedimensioneerd en draaien dus ook als er even geen klanten zijn. Maar zodra een klant iets besteld heeft, moeten medewerkers van het bedrijf het magazijn in om de order af te werken. En daar knelt de schoen. Magazijnen zijn gemaakt op het principe van resource­efficiëntie. Ze zijn erop ingericht om goederen in batches van toeleveranciers aangeleverd te krijgen, die efficiënt op te slaan en meestal in andere samenstellingen weer batchgewijs uit te leveren aan afnemers. Assembleren van zeer kleine orders is duur en wordt exponentieel duurder met de omvang en vooral de diversiteit van het assortiment. Als een klant in één order bij Amazon bijvoorbeeld een boek, een overhemd, een snelkookpan en een kettingzaag bestelt, dan is de kans honderd tegen een dat daarvoor minstens drie medewerkers ‘op stap’ moeten in drie verschillende distributiecentra. De kosten van de order schieten naar boven als de klant de bestelde artikelen in één keer wil ontvangen. Natuurlijk kan een dotcomwinkel een volledig geautomatiseerd order­pickingsysteem in het magazijn installeren, maar dat is op de eerste plaats duur en bovendien werkt dat alleen als de artikelen qua maten en gewichten een beetje op elkaar lijken. De combinatie boek, cd, snelkookpan en kettingzaag leent zich daar in ieder geval nog niet voor. Het is niet gemakkelijk een back­officesysteem (resource­efficiëntie) als een front­officesysteem (klant­efficiëntie) in te richten. Beter is het om domeinen binnen een organisatie aan te wijzen waar de verschillende paradigma’s dominant gelden en erop toe te zien dat in die domeinen ook echt gestuurd wordt volgens dat paradigma en dat er geen dure compromissen worden gesloten. Dat vereist keuzes, zoals in het geval van die hypotheek, en die keuzes beginnen dus bij de bepaling van het niveau van dienstverlening aan de klant en de inrichting van de bedrijfsprocessen wordt daar dan van afgeleid. Heel illustratief hiervoor is de snelle en succesvolle opkomst van de goedkope luchtvaartmaatschappijen. Hun dure concurrenten zijn in de loop der jaren ‘stuck­in­the­middle’ geraakt door te proberen de klantgerichtheid te verbeteren, maar de prijzen daarvan zijn navenant hoog gebleken. Tot een echt ‘don’t waste my customer’s time’ is het bij lange na niet gekomen. Een business­classlounge geeft wel comfort en maakt werken en zelfs vergaderen mogelijk, maar in de kern verandert het proces niet: het verkort de wachttijd niet en het voorkomt ook geen vertragingen. De nieuwe maatschappijen schroeven hun dienstenniveau juist naar beneden en komen daardoor op zulk een laag kostenniveau uit dat de klant dat aantrekkelijk vindt. Het vliegverkeer zal toenemen met zulke lage prijzen en de bezettingsgraad is hiermee gediend. Deze maatschappijen zijn dus scherper op hun paradigma gaan zitten en met succes. De websites van die maatschappijen hoeven dus ook niet meer te zijn dan een simpel ordermechanisme, iets wat zich gemakkelijk laat combineren met de back­office. Eigen methode Het spreekt vanzelf, dat elk paradigma zijn eigen methode voor procesverbetering vergt. Hoe processen binnen een resource­efficiënt domein kunnen worden verbeterd, is al minstens twee eeuwen bekend. Wel hebben bedrijven er zichtbaar moeite mee om dat paradigma vast te houden. Henry Ford was een manager die dat uitstekend kon. Ook goedkope luchtvaartmaatschappijen hebben dat heel goed door. Het gaat om (1) sturen op zo hoog mogelijke bezettingsgraad, (2) draaien van zo groot mogelijke series en (3) uitgekiende logistieke systemen, gericht op massale verwerking. Hoe processen binnen klant­efficiënte domeinen verbeterd kunnen worden is nog wat minder bekend. Bedrijven die dit willen doen, moeten beginnen met op te schrijven wanneer klanten iets vragen tegen condities waar het bedrijf niet aan kan voldoen. Noem dat maar ‘onredelijke verzoeken’. Dit soort verzoeken kunnen meestal niet worden ingewilligd, omdat de processen en systemen van de aanbieder dat niet toelaten. Het aanleggen van een administratie van deze onredelijke verzoeken geeft een heel mooi zicht op bestaande imperfecties, waarvoor oplossingen gezocht zouden kunnen worden. Daarbij kan de bekende ‘five why’s’­methode uit de wereld van Kaizen goed gebruikt worden, al moet die iets worden aangepast. Als een organisatie een verzoek van een klant niet kan inwilligen, moet zij zich afvragen waarom dat niet kan. Als dan de oorzaak benoemd wordt, moet ook daarvan de oorzaak worden vastgesteld. Na vijf keer is men dan meestal wel aangeland bij de kern van het probleem. Vaak blijkt uit dit soort exercities dat er problemen zijn met betrekking tot tijd (te langzaam, verkeerde tijdstip), plaats (verkeerde locatie, grote afstand) en informatie (te weinig, verkeerd). Het wegwerken van die problemen is de ultieme uitdaging voor het bedrijf dat klantefficiëntie nastreeft. In de wetenschap dat front­ en back­officeprocessen zo verschillend zijn als water en olie, mag niemand optimistisch zijn over de integreerbaarheid ervan. Hoezeer wij ook anders zouden willen. Beter is het te kiezen voor het een of het ander, of ­ als dat niet kan ­ de overgang tussen beide domeinen verstandig te plaatsen. Marcel Creemers is zelfstandig adviseur elektronisch zakendoen en deeltijd hoogleraar aan de Vrije Universiteit Amsterdam en Universiteit Nyenrode (marcel@transacsysconsult.com). Hij is de auteur van het boek ‘Van Productiviteit naar Transactiviteit, 8 memo’s voor de e­conomie’.