Wie Shift-Left-Entwicklungspraktiken erfolgreich auf Ihre Kundenservice- und Supportorganisation angewendet werden können
In der Landschaft von Entwicklung, Entwickler-Tools und Methoden hat sich in den letzten zehn Jahren viel verändert. Immer mehr Organisationen wechseln vom „Wasserfall“ zu einem agilen Entwicklungsframework sowie zu DevOps-Prinzipien für die Entwicklung und den Support von Unternehmensanwendungen. Ziel ist es, schnellere Release-Zyklen zu erreichen, die Qualität zu verbessern und Ihren Kunden – den Nutzern Ihrer Systeme und Anwendungen – insgesamt ein besseres Erlebnis zu bieten.
Insbesondere hat sich eine Philosophie namens „Shift Left“ als neuer Ansatz etabliert, um die Qualität von Anwendungen zu verbessern, indem Testzyklen näher an die Entwicklungsaktivitäten herangerückt werden. Das hat nachweislich die Zahl der in der Produktion gefundenen Fehler reduziert – und Organisationen, die dies umgesetzt haben, Zehntausende Dollar eingespart.
In diesem Whitepaper untersuchen wir, wie die Konzepte, die den Trend hin zu Shift-Left-Entwicklungsframeworks beschleunigen, auf Ihre Service- und Supportorganisation angewendet werden können. Wir nennen dies „Shifting Down“, weil es bedeutet, mehr Verantwortung „weiter unten“ in der Organisation bzw. am Frontend zu verankern – indem Sie Ihre Tier-1-Mitarbeitenden so weit wie möglich befähigen und zugleich Self-Service-Automatisierung dort einsetzen, wo es sinnvoll ist. Wir geben Ihnen sieben Best Practices, wie Sie das umsetzen – und zeigen, warum es teuer werden kann, wenn Sie es nicht tun.
Shift-Left-Testing: eine Einführung
Beginnen wir mit der Erklärung der Shift-Left-Philosophie im Software-Testing. Shift Left bedeutet, früher im Software-Delivery-Lifecycle mit dem Testen zu beginnen. Das steht im Gegensatz zum traditionellen Ansatz, bei dem Tests am Ende des Entwicklungsprozesses an ein dediziertes QA-Team übergeben werden. Die Logik ist einfach: Je früher im Entwicklungsprozess Sie Bugs und Defekte finden, desto schneller können Sie Ihren Entwicklern Feedback geben – und desto produktiver können sie arbeiten. Derzeit haben mehr als vier von zehn Entwicklungsorganisationen Shift Left beim Application Testing offiziell eingeführt.
Derzeit stützt sich die Mehrheit der Organisationen weiterhin weitgehend auf das „Wasserfallmodell“, das sowohl im Projektmanagement als auch in der Softwareentwicklung eingesetzt wird und bei dem Anforderungsaufnahme, Design, Coding und Testing überwiegend sequenziell erfolgen (siehe Abbildung 1).
Die größte Herausforderung der Wasserfallmethode besteht darin, dass Bugs oder Defekte – ob groß oder klein – erst identifiziert werden, nachdem die Entwicklung abgeschlossen ist. Kleinere Defekte sind nicht zwingend ein Showstopper – Entwickler können sie oft schnell beheben, ohne Lieferpläne durcheinanderzubringen oder zu hohe Kosten zu verursachen –, aber bei größeren Bugs sieht die Sache ganz anders aus.
In solchen Fällen kann sich die Auslieferung des Produkts an den Kunden verzögern, und die Kosten können steigen, weil mehr Personen hinzugezogen werden, um das Problem zu beheben. Ideal ist eine Testphase ganz am Ende des Softwareentwicklungszyklus nur dann, wenn Ihr Produkt fehlerfrei ist – aber träumen Sie weiter, wenn Sie zu Beginn jeder Produktentwicklungsinitiative noch hoffen, dass das tatsächlich der Fall sein wird.
Als flexiblere Softwareentwicklungsmodelle wie Agile aufkamen, erkannten Unternehmen, dass es sehr riskant ist, Tests als einmalige Aktivität an ein isoliertes QA-Team zu übergeben. In dieser Phase gefundene Defekte waren der Hauptgrund für Release-Verzögerungen und Kostenüberschreitungen.
Shift Left entstand: Tests werden in jeder Entwicklungsphase durchgeführt
(siehe Abbildung 2).
Shifting Left bedeutet im Kern, Tests so früh wie möglich (auf der Lebenszyklusachse nach links) zu verlagern und sie kontinuierlich durchzuführen. Shift-Left-Praktiken beinhalten, Tests in Ihren Softwareentwicklungsprozess zu integrieren und Bugs früher aufzudecken, wenn sie leichter und kostengünstiger zu beheben sind.
Obwohl die Praxis Ende der 1990er-Jahre entstand, wurde das Konzept „Shift Left“ 2001 von Larry Smith im Dr. Dobbs Journal offiziell benannt. Dort erläuterte Smith, wie integrierte Entwicklung mit QA auf niedrigeren Managementebenen das Testprogramm ausweiten und zugleich Personal- und Ausrüstungsbedarf reduzieren kann. Testing, Feedback und Anpassungen erfolgen bei Shift Left täglich. Das fördert Agilität und ermöglicht es dem Projektteam, seine Anstrengungen zu skalieren, um die Produktivität zu steigern
(siehe Abbildung 3).
Als DevOps 2007 aufkam, war Shift Left ein integraler Bestandteil davon. DevOps bedeutet, Softwareentwicklung und IT-Betrieb zu verbinden und so eine gemeinsame End-to-End-Verantwortung für den Prozess, den Produktlebenszyklus und das Kundenerlebnis zu schaffen. Das Ziel von DevOps – den Softwareentwicklungszyklus zu verkürzen und eine kontinuierliche, hochwertige Code-Auslieferung zu ermöglichen – trägt die Shift-Left-Philosophie in sich.
Die ganz realen Vorteile von Shift Left
Eine umfangreiche Forschungslage hat die Vorteile von Shift Left aufgezeigt. Eine Studie des mit dem Pulitzer-Preis ausgezeichneten IT-Beraters und Autors James Martin ergab, dass die Ursache von 56 % aller in Softwareprojekten identifizierten Defekte in der Phase der Anforderungsanalyse und -definition entsteht, 27 % in der Designphase und nur 7 % in der Entwicklungsphase. S. A. Kelkar vom Indian Institute of Technology bestätigte diese Zahlen in Structured Systems Analysis and Design ; weitere Bestätigung lieferte STBC in The Economics of Testing. (Siehe Abbildung 4).
Untersuchungen des IBM System Science Institute ergaben, dass Probleme, wenn sie früh in der Entwicklung identifiziert werden, etwa 80 $ kosten, um sie zu beheben. Dieselben Probleme kosten jedoch 8.000 $, wenn sie erst in der Produktion entdeckt werden – also das 100-Fache. (siehe Abbildung 5).
Abbildung 5: Kosten für das Erkennen von Defekten in verschiedenen Phasen des Softwareentwicklungszyklus.
Quelle: IBM System Science Institute
Shift Left auf Kundenservice- und Supportorganisationen anwenden
Nachdem wir das Konzept von Shift Left verstanden haben, können wir seine Prinzipien auf unsere IT-Kundenservice- und Supportorganisationen anwenden – und davon profitieren.
Heute priorisieren IT-Support-Teams die Modernisierung ihrer traditionellen Frameworks zur Kundenunterstützung durch neue Prozesse auf Basis etablierter und neuer IT-Management-Frameworks wie der IT Infrastructure Library (ITIL®) oder Control Objectives for Information and Related Technology (COBIT). Hauptgrund für diese Priorisierung im IT-Kundensupport? Kunden konzentrieren sich zunehmend auf die tatsächliche Verfügbarkeit und Performance immer stärker cloudbasierter Plattformen und Softwareanwendungen, die vollständig unter der Kontrolle des Anbieters stehen.
Die Herausforderung für Supportorganisationen besteht darin, dass ein steigendes Incident-Volumen sie in einen permanenten Firefighting-Modus versetzt. Proaktive Methoden wie Trendanalysen, Präventivmaßnahmen und Post-Mortems bei größeren Problemen sind wirksame Wege, die Zahl der Supportanfragen zu reduzieren. Leider konzentrieren sich IT-Funktionen häufig auf reaktive Aktivitäten und ignorieren proaktive Ansätze trotz der offensichtlichen Vorteile. In der Folge führen wiederkehrende Incidents zu Kundenfrustration und unnötigen Ausfallzeiten.
Viele Parallelen zwischen Service Support und Softwareentwicklung
So wie Shift Left eingeführt wurde, weil Coding-Probleme umso teurer zu beheben sind, je später sie entdeckt werden, befinden sich Service Operations in einer ähnlichen Situation. Nehmen Sie zum Beispiel einen Incident, der zunächst von einem Tier-1-Techniker bearbeitet wird, dann an Tier 2 eskaliert und nach einiger Zeit schließlich eine Telefonkonferenz mit Tier-3-Fachexperten (SMEs) erfordert, bevor er gelöst werden kann. Die daraus entstehenden Kosten für jede zusätzliche n+1-Ressource können sich leicht auf fünf- oder sechsstellige Beträge summieren.
Die Idee, Probleme am Anfang des Prozesses zu diagnostizieren und zu lösen, statt auf einen größeren Incident zu warten, spiegelt die Erkenntnisse wider, die zur Shift-Left-Revolution in der Entwicklung geführt haben. Wenn sich die Ponemon-Studie zu Kosten auf Service Operations übertragen lässt, könnten durch eine frühere Lösung im Prozess bis zu 100-mal so hohe Kosten eingespart werden.
Wir nennen das „Shifting Down“.
Warum „Down“? Weil Sie faktisch Verantwortung in der Organisationsstruktur nach unten verlagern, sodass Tier-1- und Tier-2-Supportkräfte mehr Wissen, mehr Fähigkeiten und mehr Verantwortung haben und befähigt werden, im Sinne des Kunden zu handeln.
Aktuelle Service-Support-Praktiken
Wenn ein Kunde (oder Mitarbeitender oder ein anderer Nutzertyp) den Support anruft, erreicht er einen Tier-1-Engineer mit nur minimalen Fähigkeiten und Kenntnissen. Bei etwas komplexeren Themen – „Ich habe Probleme, auf unser Vertriebssystem zuzugreifen“ – erfassen viele Tier-1-Supportorganisationen nur Basisinformationen, versuchen die Priorität einzuschätzen und eskalieren an Tier 2. Der Tier-2-Engineer stellt in einem zweiten Anruf mehr technische Fragen (oft produktzentriert) und kann das Problem (hoffentlich) lösen. Andernfalls wird erneut eskaliert – an Tier 3, wo die eigentlichen Produktexperten sitzen.
Schon kleine Änderungen können diesen Prozess effizienter machen. Indem Sie Verantwortung nach unten verlagern – indem Sie Tier-1-Mitarbeitende darin schulen, einige kritische Diagnosefragen zu Symptomen, Auswirkungen und der tatsächlichen Leistungsabweichung zu stellen, auch wenn sie keine Produktexperten sind – können Sie mehr Fälle direkt beim ersten Kontakt lösen oder zumindest deutlich bessere Informationen an Tier 2 liefern: für schnellere Lösungen, weniger „Customer-Support-Pingpong“ und letztlich weniger Eskalationen.
Wenn Sie Ihre Tier-1-Mitarbeitenden so schulen, dass sie tatsächlich anspruchsvollere Themen als z. B. Passwort- oder Router-Resets lösen und grundlegende Triage-Funktionen übernehmen können, bringt das erhebliche Vorteile.
Die Shift-Down-Philosophie
Ziel von Shifting Down ist es, weniger technisch erfahrene Ressourcen zu befähigen und zu ermächtigen, mehr Probleme früher im Lifecycle zu lösen – kombiniert mit proaktivem Problemmanagement, um Wiederholungen zu vermeiden. Insgesamt werden Interaktionspunkte näher an den Kunden verlagert, um Eskalationen zu reduzieren, die First-Time-Fix-Rate zu erhöhen, die Servicekosten zu senken und das Kundenerlebnis insgesamt zu verbessern.
Ein Beispiel für Shifting Down ist, zentrale Diagnosefragen in Ihr Self-Help-Portal zu integrieren. Bei einem Kunden haben wir gesehen, dass dieser Ansatz die Case Deflection um 35 % erhöht hat. Das ermöglicht Ihrer Tier-1-Organisation zudem, auf einem besser informierten Niveau zu arbeiten und früher im Prozess mit der eigentlichen Fehleranalyse zu beginnen.
Wenn Sie ein Shift-Down-Programm starten, müssen Sie sicherstellen, dass Sie Workflows, Rollen und Verantwortlichkeiten entsprechend ausrichten – ebenso wie Ihr Performance-System dafür, wie diese Engineers unterstützt und belohnt werden, einschließlich Kennzahlen.
Eine neue Ära für IT Service Management
Die IT-Service-Management-(ITSM)-Funktion befindet sich tatsächlich mitten in einer Transformation.
Eine Studie von Forbes Insight und BMC ergab, dass sich die meisten IT-Serviceorganisationen über den reinen Fokus auf IT-zentrierte Services hinaus weiterentwickeln. Stattdessen werden sie heute als geschäftskritische Teams gesehen, die an vorderster Front sicherstellen, dass das Kundenerlebnis im neuen digitalen Zeitalter so ist, wie es sein sollte.
Zu den weiteren zentralen Ergebnissen dieser Studie gehören:
• 56 % sagen, dass sich das Tempo des IT-Wandels bzw. der Transformation „deutlich“ beschleunigt
• Nur 13 % sehen, dass ITSM seine traditionelle Organisationshierarchie beibehält
• 36 % nennen den Mangel an ausreichenden IT-Kompetenzen als größte Herausforderung für exzellenten Kundensupport, dicht gefolgt von Budgetrestriktionen
• 37 % berichten, dass der Großteil ihres gesamten IT-Budgets in laufende Wartung und Management fließt
Fazit: 75 % der IT-Führungskräfte stimmen zu, dass der Zeit-, Geld- und Ressourcenaufwand für laufende IT-Wartung und -Management – einschließlich IT-Service-Support – die Wettbewerbsfähigkeit ihrer Unternehmen beeinträchtigt.
Die Verbesserung von Qualität und Kosteneffizienz im IT-Support ist daher eine strategische IT-Initiative – auf einer Ebene mit Cloud, Big Data und Mobility. Tatsächlich geben 56 % der Führungskräfte an, dass IT Service Management in den Cloud-Computing- und Big-Data-Initiativen ihrer Unternehmen „äußerst wichtig“ ist. 54 % geben außerdem an, dass ITSM „äußerst wichtig“ ist, um ihre Mobile-Computing-Aktivitäten zu unterstützen.
Sieben Best Practices in einem Shift-Down-Programm
Für alle, die Shifting Down ausprobieren möchten, finden Sie hier sieben Best Practices, die wir aus unserer Erfahrung in der Zusammenarbeit mit IT-Serviceorganisationen zusammengestellt haben.
1. Daten erfassen
Zu Beginn ist es entscheidend, eine Baseline zu etablieren. Wer kontaktiert Ihr Frontline-Team? Welche Arten von Themen werden gemeldet? Welche Fragen werden gestellt? Sie müssen Daten zu Ihrem eingehenden Anrufvolumen erfassen, z. B. Anruftyp (Incident, Problem, Frage, Anfrage, Follow-up), am häufigsten eskalierter Anruftyp und Asset-Kategorien, die Kosten für die Bearbeitung dieser Anrufe (inklusive Arbeitsaufwand und Zeit) und schließlich das Skill-Level der Techniker, die jeden Anruf bearbeiten.
Sie könnten zum Beispiel feststellen, dass von tausend Anrufen pro Monat fünfhundert einen Passwort-Reset betreffen, zweihundertfünfzig relativ niedrig komplexe Lösungen wie das Gewähren von VPN-Zugriff anfragen und die letzten zweihundertfünfzig hochkomplexe Lösungen benötigen, etwa herauszufinden, warum eine Datenbank ausgefallen sein könnte. Das wird Ihre Strategie für das weitere Vorgehen beeinflussen.
2. Ziele mit hohem Nutzen auswählen
Auf Basis Ihrer Datenanalysen suchen Sie anschließend nach Zielen mit hohem Nutzen für Shifting Down. Welche Systeme oder Assets werden häufig eskaliert, haben lange Lösungszeiten und verursachen daher sehr hohe Kosten? Welche werden eskaliert, sind aber leicht zu lösen? Welche scheinen nur geringe Auswirkungen auf Kundenzufriedenheit oder Kosten zu haben?
All das sind Kandidaten für Shifting Down.
Nehmen Sie das vorherige Beispiel mit einem hohen Anteil an Passwort-Reset-Anrufen. Das würde unter anderem bedeuten, dass die Hälfte aller Supportanrufe durch Automatisierung leicht gelöst werden könnte – das ist der ultimative Shift-Down-Schritt.
Und vielleicht können Sie noch weiter ins Detail gehen. Wenn Sie zum Beispiel feststellen, dass die meisten Ihrer hochkomplexen Anrufe aus Europa kommen, könnten Sie Ihren europäischen Kunden eine Supportnummer geben, die direkt zu Tier 2 führt. So verschwenden Sie weder Ihre noch die Zeit – und das Geld – des Kunden, indem Sie einen Tier-1-Techniker einschalten. Tier 1 kann sich auf das konzentrieren, was sie am besten können. Und je mehr Sie über die anderen Anrufarten wissen, desto genauer können Sie diese ebenfalls routen. Das übergeordnete Thema hier (wieder) ist: Sie müssen Ihre Kunden verstehen und Ihre Anrufmuster verstehen.
3. Mitarbeitende auf niedrigeren Ebenen befähigen
Kepner-Tregoe setzt darauf, Mitarbeitende und Führungskräfte in den Grundlagen effektiver Problemlösung und Entscheidungsfindung zu befähigen. Wir nennen das Critical Thinking bzw. „Rational Process“.
Der Kepner-Tregoe-Ansatz für Critical Thinking leistet seit über sechs Jahrzehnten nachhaltige Beiträge zum Business Management.
Tatsächlich hat der Begriff Critical Thinking für Kepner-Tregoe eine sehr spezifische Bedeutung. Es handelt sich um ein Muster logischen, iterativen Denkens, das durch eine Reihe von Fragen gesteuert wird und darauf abzielt, Informationen zu gewinnen, zu strukturieren und zu analysieren, um zu einer fundierten Schlussfolgerung zu gelangen.
Kepner-Tregoe ist überzeugt, dass gute Teamarbeit daraus entsteht, Mitarbeitende darin zu schulen, bewusst dieselbe Denkweise zu nutzen, die viele von ihnen bereits unbewusst anwenden.
Das gelingt, indem vier grundlegende Fragen adressiert werden:
• Was passiert gerade?
• Warum ist das passiert?
• Welche Vorgehensweise sollten wir wählen?
• Was liegt vor uns?
Mehr technisches Know-how weiter unten in der Organisation zu verankern, reicht nur bis zu einem gewissen Punkt. Gerade weil die Halbwertszeit technischen Wissens immer kürzer wird, ist das schlicht kein skalierbarer Ansatz. Daher müssen Sie Ihre Engineers – insbesondere an der Frontline – auch in geeigneten Fragetechniken, den Grundlagen der Formulierung einer Problemstellung, grundlegender Datenerhebung, Troubleshooting und Critical Thinking schulen.
Sie bringen Mitarbeitenden auf niedrigeren Ebenen nicht nur bei, die Fragen zu stellen, die ein erfahrenerer Techniker stellen würde, sondern befähigen sie auch, in solchen Situationen zu verstehen, wie sie Kundenanliegen klären, verifizieren und darauf reagieren.
4. Eskalations-Trigger festlegen
Eskalation bleibt beim Shifting Down sehr wichtig. Auf Basis der von Ihnen erhobenen und analysierten Daten müssen Sie klare Trigger festlegen, wann ein Kundenproblem tatsächlich eskaliert werden muss. Der Grund ist einfach: Es ist das eine, ein Team zu befähigen – es ist etwas anderes, es zu überfordern. Ihr neu geschultes Team muss lernen zu erkennen, wann es Zeit ist loszulassen und um Hilfe zu bitten.
Am häufigsten basieren Trigger auf einem Zeitparameter. Wenn ein Tier-1-Mitarbeitender eine Stunde ohne Erfolg an einem Problem gearbeitet hat, ist es möglicherweise Zeit, an Tier 2 zu eskalieren. Trigger können auch auf Lösungsversuchen basieren: Wenn Sie dreimal versucht haben, ein Problem zu beheben, und alle Versuche fehlgeschlagen sind, ist es wahrscheinlich Zeit zu eskalieren. Eskalation kann auch von der Haltung des Kunden abhängen: Wenn er verärgert wird oder vielleicht eine harte Sprache verwendet, kann das ein Trigger sein.
5. Testen Sie Ihr Shift-Down-Programm
Die nächste Best Practice ist, A/B-Tests in Ihrem Customer Support Center einzurichten. Teilen Sie Ihr Team in zwei Gruppen: Eine Gruppe nutzt ihre neuen Shift-Down-Techniken – typischerweise bei einem sehr spezifischen Thema wie Passwort-Resets –, die andere arbeitet wie bisher. Welche Gruppe erzielt die besten Ergebnisse?
Warum das? Es ist gute Management-Science-Praxis. Für jedes gute Business-Programm, jede gute Initiative – unabhängig von der Art – sollten Sie Six Sigma oder einen ähnlichen Qualitätsplan anwenden und Projekte so behandeln, wie Pharmaunternehmen die von ihnen produzierten Medikamente behandeln. Bevor eine neue Praxis unternehmensweit eingeführt wird, sollte sie getestet und nachweislich die Ergebnisse liefern, die Sie beabsichtigt haben.
In diesem speziellen Fall wirkt sich das, was Sie tun, direkt auf Ihre Kunden aus. Um Kunden wirklich an erste Stelle zu setzen, müssen Sie sicherstellen, dass jede Veränderung die Situation für sie tatsächlich verbessert.
6. Ergebnisse quantifizieren
Nun müssen Sie messen, wie Sie abgeschnitten haben. Hat das Zielteam mehr Anrufe in kürzerer Zeit gelöst? Wie hoch waren die Servicekosten nach Asset, nach Kunde/Client, nach Anfragetyp? An diesem Punkt möchten Sie quantifizieren, wie viel Geld Sie eingespart haben im Verhältnis zu Ihren Ausgaben, um den Return on Investment (ROI) zu berechnen.
Mit diesem Wissen kann sogar ein Manager auf niedriger Ebene, der ein Experiment mit seinem kleinen Supportteam durchgeführt hat, zu seinem Vorgesetzten gehen und sagen: „Sehen Sie, was wir in unserem Team in Kanada erreicht haben. Stellen Sie sich vor, wir würden das in ganz Nordamerika replizieren.“ Plötzlich erbringt das gesamte Unternehmen Customer Service Support auf professionellerem Niveau – und wir haben diesen Manager auf niedriger Ebene für beruflichen Erfolg positioniert.
In dem von uns verwendeten Beispiel, in dem 500 von 1.000 Supportanrufen Passwort-Resets betreffen, hat diese ROI-Analyse den zusätzlichen Vorteil, dass sie Ihnen zeigt, wie viel Sie investieren können, um das Problem zu lösen. Wenn Sie 2 Millionen $ sparen können, indem Sie verhindern, dass 500 Anrufe pro Tag Sie überhaupt erreichen, indem Sie 100.000 $ in ein Passwort-Reset-Tool investieren, ist das gut investiertes Geld.
7. Skalieren Sie Ihr Programm
Wenn Sie mit den Ergebnissen Ihres ersten Shift-Down-Versuchs zufrieden sind, schauen Sie, was die Daten Ihnen über weitere Shift-Down-Möglichkeiten sagen und wo Sie den Prozess noch anwenden können. Beginnen Sie erneut mit Best Practice 1 oder 2, um einen weiteren Bereich Ihres Customer-Services-Support-Geschäfts zu verbessern.
Die beste Services-Support-Kennzahl: Kundenzufriedenheit
Letztlich ist IT-Support vielleicht die wichtigste Unternehmensfunktion des digitalen Zeitalters und cloudbasierter Anwendungen. Da Organisationen zunehmend von Technologie abhängig sind, übertrifft die Notwendigkeit, dass sie wie benötigt und zum benötigten Zeitpunkt funktioniert, nahezu alles andere. Für Unternehmen aller Art und Branchen – Fertigung, Automotive, Handel, Finanzwesen – kann IT Service Management eine entscheidende Rolle spielen. Jede Serviceunterbrechung wirkt sich direkt auf die Unternehmensproduktivität aus und letztlich auf den Erfolg des Unternehmens – unabhängig davon, ob Erfolg als Profitabilität, Effizienz oder schnellerer Service definiert wird. Die in den letzten 20 Jahren in der Softwareentwicklung entwickelten Shift-Left-Techniken können, angewendet auf IT-Serviceorganisationen, einen tiefgreifenden Einfluss haben.
Kepner-Tregoe hat mit einigen der größten und erfolgreichsten Unternehmen der Welt, wie Microsoft, zusammengearbeitet, um Supportgeschwindigkeit, Kosten pro Anruf und das Kundenerlebnis zu verbessern.
Über Shane Chagpar, Head of Kepner-Tregoe Digital
Shane Chagpar nutzt Kepner-Tregoe sowie branchenübliche Best-Practice-Tools, um Lösungen zu entwickeln, die den Anforderungen der Kunden entsprechen. Shane betreut typischerweise mehrere Projekte und ist sowohl für die Teamleistung als auch für die Ergebnisse verantwortlich. Innerhalb von KT liefert er globale Thought Leadership zu IT-Service-Strategie, Digital Transformation sowie Problem- und Incident-Management. Zudem verfügt er über Expertise in Qualitätsverbesserung, Softwareentwicklung und Produktmanagement.
Shane Chagpar lebt in Kanada und setzt Projekte weltweit für Kepner-Tregoe um.