De traditionele ontwikkelmethode sluit niet aan bij informatiseringsvraagstukken binnen de klantenservice, waarbij eindgebruikers een belangrijke rol spelen en waar veranderingen aan de orde van de dag zijn. Consultant Kees Augustein propageert daarom zijn ‘Quick & Clever’-methode. Hierbij worden de bij de eindgebruikers aanwezige praktische kennis en ervaring optimaal benut. Testen en bouwen vinden parallel plaats en de afstemming gebeurt iteratief. Daardoor kan de effectieve bouwtijd wel 80 procent van de totale doorlooptijd van het project beslaan.
De praktijk heeft inmiddels aangetoond dat dit idee voor een aantal situaties onwerkbaar is. Klanten willen nog steeds met individuen communiceren en individuen kunnen veel flexibeler omgaan met allerlei praktijksituaties. Het resultaat is dat klantenservices als paddestoelen uit de grond schieten en een steeds belangrijkere positie in de organisatie bekleden.
Binnen de moderne klantenservice zijn twee typen taken te onderscheiden. Het bijhouden van administratieve zaken rondom producten en diensten die worden geleverd aan de klant, plus het afhandelen van contacten die te maken hebben met verkoop, service of klachten. Deze taken vragen om een brede inzet van informatietechnologie, waarmee obstakels rondom klant-interactie (‘communicatie’) of systeem-interactie (‘administratie’) geëlimineerd worden.
Automatisering binnen de genoemde sector zou tegenwoordig dan ook voornamelijk gericht moeten zijn op het elimineren van tijdrovende en bewerkelijke handelingen en niet langer op het elimineren van het individu zelf. Daarbij wil het individu ook nog eens effectief ondersteund worden op het communicatieve vlak. Adequaat en klantspecifiek kunnen handelen en communiceren door het effectieve toepassen van informatiesystemen noemt men tegenwoordig wel ‘empowerment’.
Tot slot is de inzet van informatietechnologie binnen de klantenservice ook vanuit bedrijfseconomisch perspectief onontbeerlijk. Zonder informatietechnologie is de grote hoeveelheid producten, diensten en klantgegevens financieel niet rendabel te beheren.
Vijf basiseisen
Uitgaande van de genoemde taken, het belang van de individuele medewerker en de bedrijfseconomische motieven, zijn enkele ’tegenstrijdige’ eisen te formuleren waaraan informatiesystemen voor het beheer van klantenbestanden moeten voldoen:
1 Tijdrovende taken met betrekking tot controle van gegevens, of het verzamelen, zoeken en tonen van informatie, dan wel het verwerken van informatie in andere omgevingen, moet het systeem volledig en snel kunnen uitvoeren, waarbij het systeem de eindgebruiker dient te informeren over het verloop van deze processen.
2 De functionaliteit van het systeem moet zo gedetailleerd mogelijk afgestemd zijn op de praktijk. Details en uitzonderingen afdekken voorkomt dat eindgebruikers zich genoodzaakt voelen tot het verzinnen van bewerkelijke ‘work arounds‘. Daarnaast zijn het juist de details die de acceptatiegraad en effectiviteit van een systeem aanmerkelijk kunnen verhogen.
3 De bouwtijd en het implementatietraject moeten zo kort mogelijk zijn om de functionaliteit zo snel mogelijk ten dienste van de organisatie te kunnen stellen.
4 De toegevoegde waarde van het systeem moet de kosten voor ontwikkeling, implementatie en beheer rechtvaardigen.
5 Nieuwe releases van het systeem die tegemoet komen aan veranderende of nieuwe processen, dienen snel en tegen aanvaardbare kosten te kunnen worden uitgeleverd. De moderne klantenservice is namelijk een turbulente omgeving.
De ontwikkelmethode Quick & Clever houdt rekening met deze vijf eisen; met als karakteristieke kenmerken iteratief/parallel. Zij onderkent het belang van de eindgebruiker als probleem-‘eigenaar’ en probleem-‘oplosser’ in de dagelijkse praktijk en betrekt deze daarom intensief bij het ontwikkelproces. De Q&C-methode is geboren uit de analyse van enkele succesvol verlopen quick & dirty-trajecten. Deze werden vaak opgestart om de problemen op te lossen die ontstaan waren uit een traditioneel ontwikkeltraject, of in situaties waar er onvoldoende tijd of geld was om traditioneel te ontwikkelen.
‘Traditioneel’ niet effectief
De Q&C-methode wordt gespiegeld aan de ’traditionele’ ontwikkelmethode, die vanwege haar kenmerken bureaucratisch/lineair genoemd wordt. De traditionele methode kent een groot aantal elkaar opvolgende fasen, die elk hun strikte documentatie-eisen kennen. Veel tijd en energie gaat zitten in het opleveren van een gedetailleerd Functioneel Ontwerp (FO), waarmee de ontwikkelaars aan de slag gaan. Historisch gezien kent deze methode een sterk ‘automatiseringsdogma’, gericht op het elimineren van de eindgebruiker. De basiseisen 1 en 2 worden daarbij snel ondergeschikt gemaakt aan basiseisen 3 en 4. Daarnaast krijgt het eenmalig opleveren de grootst mogelijke aandacht van een ‘perfect’ systeem en wordt punt 5 het liefst genegeerd. Deels uit gewoonte en deels uit het ontbreken van serieuze alternatieven, hanteren veel bedrijven deze methode in diverse gedaanten nog steeds als standaard.
De noodzaak om nieuwe systemen te implementeren komt vaak voort uit groeiende problemen binnen de organisatie. ‘Service levels‘ worden niet meer gehaald, klanten lopen massaal weg, doorlooptijden van processen zijn dusdanig lang dat de kosten de pan uitrijzen enzovoorts. Als besloten is dat de problemen opgelost moeten worden met een nieuw informatiesysteem, dan worden er duidelijk kwantificeerbare eisen gesteld, die het probleem rigoureus uit de wereld kunnen helpen. Kwantificeerbare eisen hebben vaak het volgende karakter:
Proces X moet binnen Y minuten kunnen worden afgerond, waarbij de kosten niet hoger mogen uitvallen dan Z.
Vervolgens wordt er een project opgetuigd dat gezien de acuutheid van de problemen zo doelgericht mogelijk moet verlopen en zo snel mogelijk een oplossing moet bieden. Maar nu gebeurt er iets vreemds: wat de aard, organisatie of achtergrond van het probleem ook is, men doet een greep in de gereedschapskist en haalt daar weer hetzelfde werktuig uit: de traditionele bureaucratisch/lineaire ontwikkelingsmethode.
Organisaties die niet anders gewend zijn dan met de traditionele methode te werken, gaan ervan uit dat een aantal voordelen onlosmakelijk aan deze methode verbonden is. Zo is er een rotsvaste procedure neergelegd met de mogelijkheid tot controle op iedere stap vanaf de diverse analysefases, bouwfases, testfases tot en met de implementatie fase. Iedere stap wordt zorgvuldig geëvalueerd voor de volgende stap gezet wordt. En door deze vaste gecontroleerde fasering vormt het een gedegen, eenduidige methode die moet leiden tot een voorspelbare, hoge kwaliteit van het eindproduct.
Binnen de deelnemersgroep vinden we strak functioneel gescheiden rollen waaronder diverse typen analisten, procestechnologen, ontwikkelaars en testspecialisten. Gezien het acute karakter van het op te lossen probleem, de hoge projectkosten en de eindigheid van de besteedbare budgetten, wordt middels hooguit enkele bondige interview-sessies met een enkele eindgebruiker het minimaal noodzakelijke zoals de kleur en indeling van het scherm afgedekt in het FO. De procesmodellen worden over de hoofden van de eindgebruikers heen opgesteld door de processpecialisten en vertonen daardoor heel vaak gaten. Het vooraf dichten hiervan is onmogelijk, omdat anders te veel tijd in het vervolmaken van het FO zou gaan zitten en er nog minder bouwtijd overblijft. Want iedere verdere detaillering in een procesmodel binnen de traditionele methode moet uiteindelijk ook weer door het analyseteam worden gedocumenteerd in het functioneel ontwerp, zonder dat er ook nog maar iets gebouwd is.
Slikken of stikken
De bouwactiviteiten die uiteindelijk plaatsvinden maken slechts een klein onderdeel uit van de totale projectinspanning. Daarbij wordt er veel plaats ingeruimd voor aparte technische testfases, die elk hun eigen specialisten kennen, waardoor doorlooptijd en kosten weer navenant stijgen. Hierna volgt uiteindelijk een zeer korte acceptatietest voor de eindgebruikers en is het vaak slikken of stikken. Eenmaal in productie worden de kwantificeerbare eisen vaak niet gehaald, mede vanwege het ontbreken van de voor de eindgebruiker noodzakelijke detaillering. Het als noodoplossing voor de bouw laten controleren van de procesmodellen en het FO door enkele eindgebruikers, is het paard achter de wagen spannen. Het introduceert weer een nieuwe kostbare stap en vergroot dikwijls de verwarring. Het enige zinvolle wat een eindgebruiker namelijk kan controleren is het informatiesysteem zelf.
De traditionele methode gaat dus gebukt onder interpretatieproblemen, die ontstaan door de schriftelijke en bureaucratische wijze van communiceren en door de uiteindelijke interpretatie van het FO zelf. De totale samenhang van de tot in detail uitgewerkte functionaliteit valt niet eenduidig te interpreteren door een ontwikkelaar, terwijl dat wel uiteindelijk bepalend is voor de kwaliteit van het eindproduct. En alsof dit alles nog niet genoeg is, hebben projecten die volgens de bureaucratisch/lineaire methode ontwikkeld worden ook nog te kampen met de volgende drie problemen:
- Controle van stappen en documentatie wordt binnen de projectgroep een doel op zich, zonder dat dit effectief bijdraagt aan een goed systeem voor de eindgebruikers.
- Budgetoverschrijdingen vinden plaats, doordat bepaalde stappen in het lineaire proces onvoorzien uitlopen, terwijl de complete deelnemersgroep op het budget blijft drukken.
- De kosten voor het uitbreiden van de functionaliteit in nieuwe releases blijken na oplevering vanwege het op analyse en documentatie gerichte karakter dusdanig hoog te liggen, dat er nauwelijks nieuwe releases kunnen worden uitgebracht.
Pientere benadering
Het stellen van heldere, kwantificeerbare eisen aan een informatiesysteem staat op zich los van de gekozen methode van ontwikkelen. Ook binnen de Quick & Clever-methode spelen deze harde uitgangspunten een belangrijke rol om überhaupt te kunnen beginnen met een project. Bij Q&C stopt het daar echter niet mee.
Binnen processen bij de klantenservice bestaan namelijk talloze niet of veel moeizamer kwantificeerbare eisen die veel verder gaan dan de kleur en indeling van het scherm. Deze niet-kwantificeerbare eisen komen bij de Q&C-methode uitgebreid aan bod. Verder hebben dit type eisen alles te maken met ‘empowerment’ van de eindgebruiker. Hoe de eindgebruiker in zijn dagelijks werk ondersteund wordt, is net zo belangrijk als welk acuut probleem er wordt opgelost.
Een project volgens de Q&C-methode verloopt op de volgende wijze. De klantenservice voor wie het systeem bedoeld is, stelt op locatie allereerst test-, ontwikkel- en projectruimte ter beschikking; met het doel de fysieke afstand tussen alle leden van de projectgroep zo klein mogelijk te houden en directe verbale communicatie niet in de weg te staan. Daarbij wordt iedere projectdeelnemer op deze wijze continu herinnerd aan het doel van het project: een goed systeem opleveren ten behoeve van de medewerkers van de klantenservice.
Gedeelde verantwoordelijkheid
Binnen de deelnemersgroep zijn dezelfde disciplines vertegenwoordigd als bij de traditionele methode (proces, analyse, test, bouw, implementatie), maar juist niet bij gescheiden personen. Tevens treffen we enkele geselecteerde eindgebruikers aan als vaste leden van de deelnemersgroep, en zij gaan zich bezighouden met het testen, en spuien hun kritiek en ideeën omtrent de inrichting van de processen. Het streven is de complete deelnemersgroep zo klein mogelijk te houden en rollen binnen één en dezelfde persoon te combineren. Een ontwikkelaar is ook een beetje analist. Een eindgebruiker is tester, maar ook procesdeskundige, enzovoorts. Hoewel iedere deelnemer wel een sterke en een zwakke kant heeft, weegt de totale gedeelde kennis – op basis van intensieve verbale communicatie – zwaarder dan de geconcentreerde kennis van de ‘alwetende’ specialist van de traditionele methode.
Bovendien is de héle groep verantwoordelijk voor het eindresultaat in plaats van het kleine stukje van hun specialisme. Door het maximaal en effectieve inzetten van personen met ‘gedeelde rollen’, bedraagt het totale aantal deelnemers misschien maar een kwart van de groep die volgens de traditionele methode aan de slag zou gaan. Dit scheelt enorm in budget en afstemmingstijd.
De Q&C-methode wil daarbij niets weten van de ‘domme’ eindgebruiker, vergelijkbaar met de ‘domme’ terminal uit het mainframe-tijdperk. De bij de eindgebruikers aanwezige praktische kennis en ervaring, gekoppeld aan een talent om ‘doelmatig te kunnen testen en de verdere ontwikkeling te sturen’, vormt een van de belangrijkste pijlers van deze methode.
In de startfase van het project discussiëren alle groepsleden over de eerste opzet. Op basis van de kwantitatieve eisen worden de juiste IT-middelen gekozen (systemen en software) en er wordt een aantal ongedetailleerde procesmodellen met een globale functionaliteitbeschrijving opgesteld aan de hand waarvan de ontwikkelaars zo snel mogelijk aan de slag kunnen. Dit document zou een uitgangsdocument genoemd kunnen worden. Het opstellen ervan zou niet meer dan 5 tot 10 procent van de totale doorlooptijd van het project in beslag moeten nemen. Op basis van de gekozen IT-middelen wordt de testomgeving ingericht, waarbij eventueel ook de latere productieomgeving alvast besteld kan worden.
Parallel test- en bouwtraject
Terwijl de ontwikkelaars de eerste oplevering van een zeer globaal systeem of prototype voorbereiden, stemt de testcoördinator met de eindgebruikers en de procesmedewerker een aantal globale testcases op, gebaseerd op deelprocessen, die de toekomstige functionaliteit moeten gaan afdekken. Bij de eerste oplevering van het prototype in de testomgeving, begint vervolgens een intensief traject, waarbij alle bevindingen die tijdens de tests naar boven komen, waaronder allerlei systeemfouten, procesfouten, cosmetische fouten, ontbrekende functionaliteit, maar ook nieuwe ideeën, kort en bondig worden vertaald in een bevindingenlijst, gecategoriseerd naar testcase en deelproces. Deze lijst wordt dagelijks doorgenomen met het bouwteam, dat rechtstreeks verbaal kan communiceren met de eindgebruikers over mogelijke onduidelijkheden. De ontwikkelaars plannen vervolgens een nieuwe release en geven aan welke bevindingen zijn opgelost en hergetest kunnen worden. Met de inzet van moderne ontwikkeltools en de vakkennis van de ontwikkelaars, kunnen op deze wijze zeker twee zinvolle nieuwe releases per week opgeleverd worden.
Bij de Q&C-methode ontbreekt dus elke fasering in het testen, behalve als daar een absolute noodzaak voor bestaat! Alleen als de deelnemersgroep op een bepaald probleem vastloopt, kan er besloten worden om met inzet van professionele testers en methoden een aparte testronde te organiseren. Het meeste test- en herstelwerk wordt echter ongefaseerd door de eindgebruikers in samenwerking met de ontwikkelaars verricht tijdens de ontwikkeling van het systeem.
Tijdens deze intensieve test- en ontwikkelperiode komen nagenoeg alle uitzonderingen en details in de processen uit de praktijk boven water. Er komen ook allerlei uiterst slimme ideeën naar boven die alles te maken hebben met ‘empowerment’. De geaccepteerde functionaliteit wordt bijgehouden in een werkinstructie, die uitmondt in de toekomstige handleiding. Procesmodellen worden eveneens dynamisch bijgewerkt.
‘Testen’ gaat dus binnen de Q&C-methode veel verder dan het controleren van de specificaties die door een analist zijn opgesteld en door een ontwikkelaar zijn gebouwd. Het testen en het bouwen vinden volledig parallel plaats en de afstemming is iteratief. Daarom kan de effectieve bouwtijd binnen een Q&C-traject wel 80 procent van de totale doorlooptijd van het project beslaan. Bij de traditionele methode liggen deze percentages ongeveer tussen de 10 en 20 procent.
Iteratief verbale communicatie
Mede doordat de deelnemersgroep zo klein mogelijk is opgezet, komt het iteratieve karakter in verbale communicatie volledig tot zijn recht. De hoeveelheid tussentijdse documentatie wordt tot een minimum beperkt en de ontwikkelaar is vrij in het vertalen van functionaliteit in een oplossing. Bouwt hij echter zonder te communiceren iets ‘onwerkbaars’, dan volgt hier meteen een bevinding op door de eindgebruiker die dit tijdens het testen voorgeschoteld krijgt. Anderzijds, wanneer een eindgebruiker met een irrationele bevinding komt, dan kan een ontwikkelaar, of ieder willekeurig ander persoon binnen de groep, aangeven waarom de bevinding niet deugt binnen de totale oplossing.
Omdat een aantal eindgebruikers vanaf het begin betrokken is geweest bij de ontwikkeling, verloopt de implementatie zonder grote problemen en bestaat er een hoge acceptatiegraad. De projectgroep houdt daarna op te bestaan en in alle rust, terwijl het systeem al volledig operationeel is, kunnen de ontwikkelaars ten slotte hun Functioneel – en Technisch Naslagwerk opleveren ten behoeve van de beheerorganisatie, of toekomstige releases.
De relevante eindproducten waaronder het systeem zelf, de systeemdocumentatie, de werkinstructie en de procesmodellen vindt men ook terug bij de traditionele methode, maar het systeem, ontwikkeld via de Quick & Clever-methode, is veel geavanceerder en heeft heel wat minder tijd en geld gekost. Daarbij kan het uitbrengen van een eventuele nieuwe release ook geen bottleneck meer vormen, omdat er zo’n evaring is met het enorme aantal deel-releases tijdens het gehele ontwikkeltraject.
Kees Augustijn Consultant Bij Csc Computer Sciences
‘Maximale functionaliteit’ in de praktijk
Met een aan Quick & Clever verwante methode werd in vijf maanden tijd binnen de klantenservice van een grote mobiele operator voor minder dan 3 miljoen gulden een maatwerkoplossing geïmplementeerd, waarvan het aantal functiepunten achteraf werd geschat op ongeveer 750 stuks. De complete deelnemersgroep bedroeg over de looptijd gemiddeld zestien personen. Het systeem was behoorlijk complex, omdat het met twee bedrijfskritische applicaties werd gekoppeld, de complete werkstroom- en procesbewaking voor zijn rekening nam en ook nog een gebruikersvriendelijk interface bood aan de medewerkers van de klantenservice. Het systeem was gericht op het uitwisselen van mobiele telefoonnummers (porteren) tussen de verschillende operators; een door de Opta opgelegde eis aan alle mobiele service-providers in Nederland.
Zouden er via de traditionele methode 750 functiepunten toegevoegd worden aan de reeds ontwikkelde applicatie, die door het noodzakelijk zijn van een groot aantal eindgebruikers veel te hoge verwerkingskosten kende, dan volgde naar opgaaf van de leverancier een doorlooptijd van tien tot twaalf maanden met een kostenpost van ongeveer 10 miljoen gulden. De totale deelnemersgroep binnen het project besloeg in dat geval zo’n veertig personen. De ontwikkeling van deze applicatie zelf via de traditionele methode had inmiddels zo’n twee jaar in beslag genomen en reeds meer dan 15 miljoen gulden gekost. Met de verwachte groei in het aantal ‘porteringen’, ontstond er zo een acuut probleem dat vroeg om een snellere oplossing.
De maatwerkoplossing in kwestie werd op locatie bij de klantenservice ontwikkeld. Tijdens het hele ontwikkelproces werden er in totaal zo’n driehonderd bevindingen door de eindgebruikers genoteerd en werden er zo’n vijftien deel-releases uitgebracht om tot het eindproduct te komen. Het opgeleverde systeem voldeed uitstekend, ging zonder grote problemen in productie en werd door alle eindgebruikers als zeer bevredigend ervaren. De directe ‘return on investment’ was daarbij zeer groot, omdat met de helft van het aantal medewerkers de verwachte groei in het aantal ‘porteringen’ ruimschoots kon worden opgevangen.
Maximale functionaliteit dus – met een besparing van 70 procent in kosten en doorlooptijd.