Hoe shift-linkse ontwikkelingspraktijken met succes kunnen worden toegepast op uw klantendiensten en ondersteuningsorganisatie.
Er is veel veranderd in het landschap van ontwikkeling, ontwikkelaarstools en methodologieën in de afgelopen tien jaar. Meer organisaties verschuiven van "waterval" naar een Agile ontwikkelingsraamwerk, evenals DevOps principes voor het ontwikkelen en ondersteunen van bedrijfsapplicaties. Het doel is om snellere release-cycli te realiseren, de kwaliteit te verbeteren en een algehele betere ervaring te leveren aan uw klanten - de gebruikers van uw systemen en applicaties.
Met name een filosofie die "shift left" wordt genoemd, is naar voren gekomen als een nieuwe manier om de kwaliteit van toepassingen te verbeteren door de testcycli dichter bij de ontwikkelingsactiviteiten te brengen. Dit heeft bewezen het aantal defecten dat in de productie wordt aangetroffen te verminderen - en tienduizenden dollars te besparen voor organisaties die het hebben toegepast.
In deze white paper onderzoeken we hoe de concepten die de verschuiving naar shift-linkse ontwikkelingsframeworks versnellen, kunnen worden toegepast op uw service- en supportorganisatie. We noemen dit "shifting down" omdat het inhoudt dat u meer verantwoordelijkheid "lager" in de organisatie legt of aan de voorkant, als u dat wilt - door uw Tier 1 medewerkers zoveel mogelijk in staat te stellen, terwijl u ook aan self-service automatisering doet waar nodig. Wij geven u zeven best practices over hoe u dit kunt doen, en laten u zien waarom het kostbaar kan zijn voor uw bottom line als u dit niet doet.
Shift-links testen: een inleiding
Laten we beginnen met het uitleggen van de shift-linkse filosofie bij het testen van software. Links verschuiven betekent eerder in de levenscyclus van software beginnen met testen. Dit in tegenstelling tot de traditionele aanpak waarbij het testen helemaal aan het eind van het ontwikkelproces wordt overgedragen aan een speciaal QA team. De redenering is eenvoudig: hoe vroeger in het ontwikkelingsproces u bugs en defecten kunt vinden, hoe vroeger u feedback kunt geven aan uw ontwikkelaars, zodat zij productiever aan het werk kunnen gaan. Op dit moment zijn meer dan vier op de tien ontwikkelingsorganisaties officieel overgestapt op het testen van applicaties.
Momenteel hangt de meerderheid van de organisaties nog steeds grotendeels af van het "watervalmodel", dat zowel in projectbeheer als in softwareontwikkeling wordt gebruikt en waarbij het verzamelen van de vereisten, het ontwerpen, het coderen en het testen op een meestal opeenvolgende manier gebeuren (zie figuur 1).
Figuur 1: De levenscyclus van softwareontwikkeling.
.png)
De belangrijkste uitdaging van het gebruik van de watervalmethode is dat bugs of defecten - of ze nu groot of klein zijn - pas worden geïdentificeerd nadat de ontwikkeling is voltooid. Kleine defecten zijn niet noodzakelijkerwijs show-stoppers-de ontwikkelaars kunnen ze snel repareren zonder de leveringsschema's in de war te sturen of te veel kosten toe te voegen- maar grote defecten zijn een heel andere zaak.
In dergelijke gevallen kan de vrijgave van het product aan de klant vertraging oplopen, en kunnen de kosten escaleren naarmate meer mensen worden ingeschakeld om het probleem op te lossen. De enige keer dat de testfase helemaal aan het einde van de software ontwikkelingscyclus ideaal is, is wanneer uw product bug-vrij is- maar droom verder als u aan het begin van elk product ontwikkelingsinitiatief nog steeds hoopt dat dit het geval zal zijn.
Naarmate meer flexibele softwareontwikkelingsmodellen zoals Agile opkwamen, begonnen ondernemingen zich te realiseren dat het overdragen van testen aan een silo QA team in een eenmalige activiteit in feite zeer riskant was. Defecten die in dat stadium werden gevonden waren de nummer 1 reden voor vertragingen bij releases en kostenoverschrijdingen.
Shift-links was geboren, waar testen worden gedaan in elke fase van de ontwikkeling
(zie figuur 2).
Figuur 2: Het shift-linkse testmodel.
Verschuiving naar links betekent in feite het testen verschuiven naar een zo vroeg mogelijk tijdstip (naar links op de as van de levenscyclus) en het continu doen. Shifting left houdt in dat u het testen integreert in uw software ontwikkelingsproces en dat u bugs in een vroeger stadium ontdekt, wanneer ze gemakkelijker en goedkoper op te lossen zijn.
Hoewel de praktijk eind jaren negentig opkwam, werd het concept van shift left formeel benoemd door Larry Smith in Dr. Dobbs Journal in 2001, waarin Smith uitlegde hoe geïntegreerde ontwikkeling met QA op lagere managementniveaus uw testprogramma kan uitbreiden en tegelijkertijd de behoefte aan mankracht en apparatuur kan verminderen. Testen, feedback en revisies gebeuren dagelijks in de shift left praktijk. Dit bevordert de wendbaarheid en stelt het projectteam in staat hun inspanningen te schalen om de productiviteit te verhogen
(zie figuur 3).
Figuur 3: Shift-links versus traditioneel QA-model.
Toen DevOps in 2007 zijn intrede deed, was shift-link een integraal onderdeel ervan. DevOps is wanneer je softwareontwikkeling en IT-operaties combineert, waardoor er meer collectief end-to-end eigenaarschap ontstaat van het proces, de productlevenscyclus en de klantervaring. Het doel van DevOps, het verkorten van de levenscyclus van softwareontwikkeling en het bieden van continue levering van code van hoge kwaliteit, heeft in de kern de shift-link filosofie.
De reële voordelen van een verschuiving naar links
Een groot aantal onderzoeken heeft de voordelen van een verschuiving naar links aangetoond. IT consultant James Martin ontdekte dat 56% van alle softwarefouten wordt gevonden tijdens de requirement-fase; 27% in de ontwerpfase; en slechts 7% tijdens de ontwikkelingsfase. S.A. Kelkar van het Indiase Instituut voor Technologie in Gestructureerde systeemanalyse en ontwerp verifieerde deze cijfers, die verder werden bevestigd door STBC in De economie van het testen. (Zie figuur 4).
Figuur 4: Wanneer software defecten ontstaan.
Bron: Rice Consulting
Uit onderzoek van het IBM System Science Institute blijkt dat als problemen vroeg in de ontwikkeling worden ontdekt, het ongeveer $80 kost om ze te verhelpen. Maar dezelfde problemen kosten $8.000 om op te lossen als ze tijdens de productie worden ontdekt - een veelvoud daarvan. (zie figuur 5).
Figuur 5: Kosten van het opsporen van defecten in verschillende fasen van de softwareontwikkelingscyclus.
Bron: IBM Systeem Wetenschappelijk Instituut
Het toepassen van shift-links op klantenservice ondersteunende organisaties
Nu we het concept van shift-left begrijpen, kunnen we de principes ervan toepassen - en er de vruchten van plukken - door ze toe te passen op onze IT-klantenservice en supportorganisaties.
Vandaag de dag zijn de diensten van IT support teams prioriteit geven aan vernieuwing hun traditionele raamwerken voor klantenondersteuning met nieuwe processen op basis van gevestigde en nieuwe raamwerken voor IT-beheer, zoals de IT Infrastructure Library (ITIL®), of Control Objectives for Information and Related Technology (COBIT). Belangrijkste reden om prioriteit te geven aan IT-klantondersteuning? Ze merken dat hun klanten zich steeds meer richten op de feitelijke beschikbaarheid en prestaties van steeds meer cloud-gebaseerde platforms en softwaretoepassingen die volledig onder controle van de leverancier staan.
De uitdaging waarmee ondersteunende organisaties worden geconfronteerd, is dat een toenemend volume aan incidenten hen in een continue brandbestrijdingsmodus brengt. Proactieve methoden, zoals trendanalyses, preventieve acties en post mortems van belangrijke problemen zijn effectieve manieren om het aantal supportverzoeken te verminderen. Helaas richten IT-functies vaak het grootste deel van hun middelen op reactieve activiteiten en negeren ze proactieve benaderingen, ondanks de duidelijke voordelen. Als gevolg daarvan leiden terugkerende incidenten tot frustratie bij de klant en onnodige downtime.
Veel parallellen tussen serviceondersteuning en softwareontwikkeling
Net zoals shift left werd ingevoerd omdat coderingsproblemen duurder op te lossen zijn naarmate ze later worden ontdekt, bevinden serviceactiviteiten zich in een vergelijkbare situatie. Neem bijvoorbeeld een incident dat eerst door een Tier 1-technicus werd afgehandeld, vervolgens naar Tier 2 werd doorverwezen en na verloop van tijd uiteindelijk een telefonische vergadering met Tier 3-onderwijsexperts (KMO's) vereiste voordat het kon worden opgelost. De resulterende kosten van elke toegevoegde n+1 resource kunnen gemakkelijk oplopen tot 5- en 6-cijferige kostencijfers.
Dit idee van het diagnosticeren en oplossen van problemen aan de voorkant van het proces in plaats van te wachten tot zich een groot incident voordoet, lijkt op de bevindingen die hebben geleid tot de shift-linkse revolutie in Development. Als de Ponemon-studie over de kosten kan worden toegepast op Operations, door eerder in het proces op te lossen, kunnen tot 100 keer die kosten worden bespaard.
We noemen dit "terugschuiven".
Waarom naar beneden? Omdat u in feite de verantwoordelijkheid lager in de organisatiestructuur legt, zodat Tier 1- en Tier 2-supportmedewerkers meer kennis, meer mogelijkheden en meer verantwoordelijkheid hebben, en gemachtigd zijn om namens de klant op te treden.
Huidige diensten ondersteunen praktijken
Wanneer een klant (of werknemer, of ander type gebruiker) support belt, krijgen ze een Tier 1 ingenieur die slechts minimale vaardigheden en kennis heeft. Voor iets gecompliceerdere problemen - "Ik heb problemen met de toegang tot ons verkoopsysteem" - vangen veel Tier 1 support organisaties alleen basisinformatie op, proberen de prioriteit te bepalen en escaleren naar Tier 2. De Tier 2 ingenieur, in een tweede oproep, stelt meer technische vragen (vaak product-centric) en kan (hopelijk) het probleem oplossen. Zo niet, dan wordt het opnieuw geëscaleerd, naar Tier 3, waar de echte productexperts zitten.
Zelfs kleine veranderingen kunnen dit proces efficiënter maken. Door de verantwoordelijkheid naar beneden te verschuiven - door Tier 1-medewerkers op te leiden om een paar kritische diagnostische vragen te stellen met betrekking tot symptomen, impact en de werkelijke afwijking in prestaties, zelfs als ze geen productexperts zijn - kunt u meer problemen meteen bij het eerste contactpunt oplossen of, op zijn minst, Tier 2 veel betere informatie geven voor een snellere oplossing, minder "klant-ondersteuningsping-pong" en uiteindelijk minder escalaties.
Als u uw Tier 1-mensen traint om meer geavanceerde problemen op te lossen dan bijvoorbeeld het resetten van wachtwoorden of routers, en elementaire triage-functionaliteit biedt, levert dat aanzienlijke voordelen op.
De shift down filosofie
Het doel van de verschuiving naar beneden is om minder technisch ervaren medewerkers in staat te stellen meer problemen eerder in de levenscyclus op te lossen, in combinatie met proactief probleembeheer om herhaling te voorkomen, en in het algemeen het verplaatsen van interactiepunten dichter bij uw klant om escalaties te verminderen, de first-time fix rate te verbeteren, de kosten van de dienstverlening te verlagen, en de klantervaring in het algemeen te verbeteren.
Een voorbeeld van een verschuiving naar beneden is het inbouwen van een aantal kern diagnostische vragen in uw zelfhulp portaal. Met één klant hebben we gezien dat deze aanpak case deflection verhoogd met 35%. Dit stelt uw Tier 1 organisatie ook in staat om op een beter geïnformeerd niveau te opereren en om eerder in het proces met de eigenlijke troubleshooting te beginnen.
Wanneer u aan een shift-down programma begint, moet u ervoor zorgen dat u workflows, rollen en verantwoordelijkheden daarop afstemt, evenals uw prestatiesysteem voor de manier waarop deze ingenieurs worden ondersteund en beloond, inclusief meetpunten.
Een nieuw tijdperk voor IT-dienstenbeheer
De IT Service Management (ITSM)-functie bevindt zich echt in een overgangsfase.
Een onderzoek door Forbes Insight en BMC blijkt dat de meeste IT-serviceorganisaties zich niet meer alleen richten op IT-centrische diensten. In plaats daarvan worden ze nu gezien als missiekritische teams die in de frontlinie staan om ervoor te zorgen dat de klantervaring is wat deze moet zijn in het nieuwe digitale tijdperk.
Onder andere belangrijke bevindingen van deze studie:
- 56% zeggen dat het tempo van IT-verandering of -transformatie "aanzienlijk" toeneemt
- Slechts 13% ziet ITSM dezelfde traditionele organisatorische hiërarchie behouden
- 36% zegt dat het gebrek aan adequate IT-vaardigheden bovenaan de lijst staat van uitdagingen voor het bereiken van een uitmuntende klantenondersteuning, op de voet gevolgd door budgettaire beperkingen
- 37% melden dat het grootste deel van hun volledige IT-budget naar lopend onderhoud en beheer gaat
Conclusie: 75% van de IT-managers is het ermee eens dat de hoeveelheid tijd, geld en middelen die worden besteed aan doorlopend IT-onderhoud en -beheer - waaronder IT-diensten vallen - van invloed is op het algehele concurrentievermogen van hun bedrijf.
Het verbeteren van zowel de kwaliteit als de kostenefficiëntie van IT-ondersteuning is dan ook een strategisch IT-initiatief, samen met cloud, big data en mobiliteit. Een meerderheid van de executives (56%) geeft aan dat IT-servicemanagement "uitermate belangrijk" is bij de cloud computing- en big data-initiatieven van hun onderneming. Vierenvijftig procent geeft ook aan dat ITSM "uiterst belangrijk" is bij de ondersteuning van hun inspanningen op het gebied van mobile computing.
Zeven beste praktijken in een Shift-Down programma
Voor degenen die het willen proberen, zijn hier zeven beste praktijken die we hebben samengesteld op basis van onze ervaring in het werken met IT-serviceorganisaties.
1. Verzamel gegevens
Om uw reis te beginnen, is het essentieel om een basislijn vast te stellen. Wie neemt contact op met uw frontline? Wat voor problemen melden ze? Wat voor soort vragen hebben ze? U moet gegevens verzamelen over uw inkomende call volume, zoals call type (incident, probleem, vraag, verzoek, follow-up), de meest voorkomende call type en asset categorieën, de kosten van het onderhoud van deze calls (niet te vergeten arbeid en tijd), en ten slotte, het vaardigheidsniveau van de technicus (s) die elke call behandelt (behandelen).
Zo kunt u bijvoorbeeld te weten komen dat van de duizend telefoontjes die u in een maand krijgt, er vijfhonderd vragen om een password reset, tweehonderdvijftig om oplossingen met een vrij lage complexiteit, zoals het verlenen van VPN-toegang, en de laatste tweehonderdvijftig om oplossingen met een hoge complexiteit, zoals het uitzoeken waarom een database down kan zijn. Dat zal van invloed zijn op uw strategie voor de toekomst.
2. Selecteer doelwitten met een hoge waarde
Op basis van uw data-analyses gaat u dan op zoek naar hoogwaardige targets om op te schuiven. Welke systemen of activa worden vaak geëscaleerd, en hebben lange oplostijden en dus zeer hoge kosten die ermee gepaard gaan? Welke worden geëscaleerd, maar zijn gemakkelijk op te lossen? Welke lijken weinig invloed te hebben op klanttevredenheid of kosten?
Dit zijn allemaal kandidaten voor een verschuiving naar beneden.
Neem het vorige voorbeeld van het identificeren van hoge niveaus van password reset calls. Dit zou onder meer betekenen dat de helft van alle support calls gemakkelijk door automatisering zou kunnen worden opgelost, wat de ultieme shift-down zet is.
En misschien kunt u nog een beetje verder gaan. Als u zich bijvoorbeeld realiseert dat de meeste van uw gesprekken met hoge complexiteit uit Europa komen, kunt u uw Europese klanten een ondersteuningsnummer geven dat rechtstreeks naar Tier 2 ondersteuning gaat. Op die manier verspilt u niet de tijd en het geld van de klant om een Tier 1 technicus in te schakelen. Zij kunnen zich concentreren op waar ze goed in zijn. En hoe meer je weet over de andere soorten oproepen, hoe nauwkeuriger je die ook kunt routeren. Het overkoepelende thema hier is (alweer) dat u uw klanten moet begrijpen, en uw belpatronen moet begrijpen.
3. Geef lagere werknemers meer macht
Kepner-Tregoe gelooft in het in staat stellen van werknemers en managers in de grondbeginselen van effectieve probleemoplossing en besluitvorming. Wij noemen dit kritisch denken, of "rationeel proces".
De kritische denkbenadering van Kepner-Tregoe heeft al meer dan zes decennia een blijvende bijdrage geleverd aan het bedrijfsmanagement.
Inderdaad, het woord kritisch denken heeft voor Kepner-Tregoe een zeer specifieke betekenis. Het is een patroon van logisch, iteratief denken, gedreven door een reeks vragen, gericht op het verzamelen, ordenen, en analyseren van informatie met het doel tot een goede conclusie te komen.
Kepner-Tregoe's overtuiging is dat goed teamwerk ontstaat door werknemers te trainen om bewust gebruik te maken van dezelfde manier waarop velen van hen al onbewust denken.
Zij kunnen dit doen door vier fundamentele vragen aan de orde te stellen:
- Wat is er aan de hand?
- Waarom is dit gebeurd?
- Welke koers moeten we volgen?
- Wat ligt er in het verschiet?
Meer technische knowhow lager in de organisatie duwen gaat maar tot op zekere hoogte. Zeker nu de houdbaarheid van technische kennis steeds korter wordt, is het gewoon geen schaalbare aanpak. Daarom moet u uw ingenieurs, vooral in de frontlinie, ook trainen in de juiste vraagtechnieken, de grondbeginselen van het formuleren van een probleemstelling, het verzamelen van basisgegevens, probleemoplossing en kritisch denken.
U leert de mensen op lagere niveaus niet alleen de vragen te stellen die een meer ervaren technicus zou kunnen stellen, maar u stelt hen ook in staat te begrijpen hoe zij klanten in die situaties moeten verduidelijken, controleren en antwoorden.
4. Stel triggers voor escalatie vast
Escalatie is nog steeds erg belangrijk bij het terugschakelen. Op basis van de gegevens die u hebt verzameld en geanalyseerd, moet u duidelijke triggers vaststellen voor wanneer een probleem met een klant moet worden geëscaleerd. De reden hiervoor is eenvoudig: het is één ding om een team te versterken, het is iets anders om hen te overweldigen. Uw pas opgeleide team moet leren bepalen wanneer het tijd is om los te laten en om hulp te vragen.
Meestal zijn triggers gebaseerd op een tijdsparameter. Als een Tier 1 rep een uur bezig is geweest met een probleem zonder succes, kan het tijd zijn om te escaleren naar Tier 2. Triggers kunnen ook gebaseerd zijn op pogingen om een probleem op te lossen: als je drie keer hebt geprobeerd om een probleem op te lossen en ze zijn allemaal mislukt, dan is het waarschijnlijk tijd om te escaleren. Escalatie kan ook gebaseerd zijn op de houding van de klant: als ze boos op je worden, misschien met grof taalgebruik, dan kan dat een trigger zijn.
5. Test uw shift-down programma
De volgende best practice is het opzetten van A/B-testen in uw customer support center. Verdeel uw team in twee groepen: de ene groep gebruikt hun nieuwe shift-down-technieken - meestal voor een heel specifiek probleem, zoals het resetten van wachtwoorden - en de andere groep doet zaken zoals gebruikelijk. Welke groep levert de beste resultaten op?
Waarom doe je dit? Het is een goede management wetenschapspraktijk. Voor elk goed bedrijfsprogramma, elk goed initiatief, ongeacht welk type, zou u Six Sigma moeten volgen, of een gelijkaardig kwaliteitsplan om projecten te behandelen zoals farmaceutische bedrijven de geneesmiddelen behandelen die zij produceren. Alvorens een nieuwe praktijk bedrijfsbreed in te voeren, moet worden getest en bewezen dat deze de beoogde resultaten oplevert.
In dit specifieke geval zal wat u doet een directe impact hebben op uw klanten. Om klanten echt op de eerste plaats te zetten, moet u ervoor zorgen dat alles wat u verandert ook echt iets voor hen verbetert.
6. Kwantificeer de resultaten
U moet nu meten hoe u het hebt gedaan. Heeft het doelteam meer oproepen opgelost in minder tijd? Wat waren de kosten van de service per bedrijfsmiddel, per klant/cliënt, per type verzoek? Op dit punt wilt u kwantificeren hoeveel geld u hebt bespaard ten opzichte van hoeveel u hebt uitgegeven, zodat u de return on investment (ROI) kunt berekenen.
Gewapend met die kennis kan zelfs een manager van een laag niveau die een experiment in zijn kleine supportteam heeft uitgevoerd, naar zijn baas gaan en zeggen: "Kijk eens wat we in ons team in Canada hebben gedaan. Stel je voor dat we dit in heel Noord-Amerika zouden herhalen." Plotseling werkt het hele bedrijf op een professionelere manier aan de klantenservice en hebben we die low-level manager klaargestoomd voor een succesvolle carrière.
In het voorbeeld dat we hebben gebruikt, van de 500 van de 1.000 support calls die voor password resets zijn, heeft deze ROI analyse het extra voordeel dat het u vertelt hoeveel u kunt investeren om het probleem op te lossen. Als u $2 miljoen kunt besparen door te voorkomen dat 500 oproepen per dag u ooit bereiken door $100.000 te investeren in een tool om wachtwoorden te resetten, dan is dat goed besteed geld.
7. Schaal uw programma
Als u tevreden bent met uw resultaten van uw eerste poging tot terugschakelen, kijk dan wat de gegevens u vertellen over andere terugschakelingen die u kunt uitvoeren en waar u het proces nog meer kunt toepassen. Begin opnieuw met Best Practices 1 of 2 om een ander gebied van uw klantenservices ondersteunend bedrijf te verbeteren.
De beste diensten ondersteunende metriek: Klanttevredenheid
Uiteindelijk is IT-ondersteuning misschien wel de belangrijkste bedrijfsfunctie in het digitale tijdperk en de cloudgebaseerde toepassingen. Omdat organisaties steeds afhankelijker worden van technologie, is het belangrijker dat deze werkt zoals nodig, wanneer nodig, dan bijna al het andere. Voor bedrijven van alle soorten en industrieën - productie, automotive, retail, financieel - kan IT service management een cruciale rol spelen. Elke serviceonderbreking heeft een directe invloed op de productiviteit van het bedrijf en uiteindelijk op het succes van de onderneming - of dat succes nu wordt gedefinieerd als winstgevendheid, efficiency of snellere service. De shift-linkstechnieken die de afgelopen 20 jaar in de softwareontwikkelingsarena zijn ontwikkeld, kunnen een diepgaande impact hebben wanneer ze worden toegepast op IT-serviceorganisaties.
Kepner-Tregoe heeft samengewerkt met enkele van de grootste en meest succesvolle bedrijven ter wereld, zoals Microsoft, om de snelheid van de ondersteuning, de kosten van het gesprek en het niveau van de klantervaring te verbeteren.
Shane Chagpar
Consultant projectbeheer
Shane Chagpar maakt gebruik van Kepner-Tregoe en best-practice tools om oplossingen te ontwerpen die voldoen aan de behoeften van de klant. Shane overziet meestal meerdere projecten en is verantwoordelijk voor zowel de prestaties als de resultaten van het team. Binnen KT biedt hij wereldwijd thought leadership op het gebied van IT-servicestrategie, digitale transformatie en zowel probleem- als incidentbeheer. Hij heeft ook expertise in kwaliteitsverbetering, softwareontwikkeling en productmanagement.
Shane Chagpar (schagpar@kepner-tregoe.com) woont in Canada en voert wereldwijd projecten uit voor Kepner-Tregoe.