3rd Party: Eine Microsoft Support Show – Wie DSEs die Microsoft Support Services beschleunigen (Folge 6).

Das ist eine gute Frage. Als Enterprise Architect Manager hat mein Team Angebote verschiedener Organisationen geprüft, die es schon seit einiger Zeit gibt, und wir haben uns für den DSE entschieden, also den „Designated Support Engineer“ (designierter Support-Techniker). Das sind Enterprise Architekten, die aber die Rolle eines Support-Technikers übernehmen – im Grunde genommen bieten sie unseren Kunden einen erstklassigen Service. Eines unserer Ziele ist es, eine Beziehung zum Kunden aufzubauen.

Das ist für uns wichtig, weil Sie beispielsweise schon einmal die Erfahrung gemacht haben, dass Sie Ihren Mobilfunkanbieter anrufen, Support erhalten und mit einem beliebigen Mitarbeiter verbunden werden. Manchmal sind diese Mitarbeiter kompetent, aber manchmal müssen Sie Ihre Situation immer wieder neu erklären. Und wenn Sie am nächsten Tag erneut anrufen, was passiert dann? Sie sprechen mit einer anderen Person. Sie müssen die ganze Geschichte noch einmal von vorne erzählen.

Wir wollten unseren Kunden diese Erfahrung nicht zumuten, wenn wir das vermeiden konnten. Wie machen wir das? Wir werden Teil ihrer Organisation. Das ist die Aufgabe des DSE: Er ist für diese Technologie für seinen Kunden verantwortlich und weiß alles darüber.

Ein Teil dieser Verantwortung besteht darin, interne Notizen auf Tickets zu vermerken, sodass Ingenieure, wenn sie ein Break/Fix-Ticket mit einem Schweregrad von eins, zwei, drei oder vier öffnen, sofort erkennen, dass wir einen DSE haben, der mit dieser Technologie bestens vertraut ist und alles darüber weiß, sodass sie wahrscheinlich einen Großteil der einführenden Vorbereitungsarbeit überspringen können. Dazu könnten Fragen gehören wie: „Wie sieht der Hintergrund aus? Was ist der historische Kontext? Was ist in der Umgebung passiert, das dazu geführt haben könnte?“

Das ist gut für unsere Ingenieure, die sich auf diese Eigenverantwortung verlassen können, um diese Lücken zu schließen und Hilfe zu leisten, denn manchmal sind sie sehr vertraut mit der Technologie und haben zusätzliche Ideen. Das sind reine reaktive Dienstleistungen, die durch proaktive Dienstleistungen unterstützt werden: Man lernt von einem anderen Experten, der diese Umgebung bereits kennengelernt hat, und verhindert, dass Kunden ihre Geschichte immer wieder erzählen müssen.

Unser anderes Hauptziel hängt mit der Tatsache zusammen, dass die Technologie derzeit so stark konvergiert ist. Ich bin sehr froh, dass Microsoft keine Autobahnen baut, denn es gibt keine Fahrspuren – alle Autos würden zusammenstoßen. Wenn all diese „Autos” zusammenstoßen und Sie Technologen haben, die sich mit SQL auskennen, könnten Probleme mit diesem System auf Intune übergreifen und von dort auf Azure oder M365. Danach verschmelzen alle Probleme miteinander. Mit anderen Worten: 80 % der Probleme, Technologien, Upgrades oder proaktiven Services, die angegangen werden, könnten SQL betreffen. Die anderen 20 % könnten alles Mögliche sein.

Für US Coud ist das ganz normal, aber für andere Unternehmen – und ich bin seit 40 Jahren in der Beratung tätig – ist das nicht so üblich. Und das Schöne daran ist, wie ich schon sagte, dass wir reaktive und proaktive Services zusammenführen, um unseren Kunden ein Komplettangebot zu bieten. Wir ziehen auch andere Technologen hinzu, wenn Kunden diese benötigen, um die restlichen 20 % ihrer Microsoft-Probleme zu lösen. Dazu können SQL, SharePoint, Power BI oder alles andere gehören, was zur Lösung dieser Tickets erforderlich ist. Wir kümmern uns um alles.

Wir hatten gerade letzte Woche einen solchen Fall. Der CEO eines sehr großen Unternehmens aus den Fortune 100 – wahrscheinlich eher unterhalb der 100 – hielt eine Präsentation in einem Teams-Meeting. An dem Meeting nahmen 80 oder mehr Personen teil, allesamt Führungskräfte der obersten Ebene. Unser Kunde wurde jedoch während seiner Präsentation aus dem Meeting geworfen. Das ist natürlich kein guter Eindruck, denn es bedeutet, dass jemand im Teams-Meeting die Möglichkeit hatte, den Präsentierenden aus dem Meeting zu werfen.

Dies war eine Fehlkonfiguration innerhalb der Organisation, die auf den Zeitpunkt und die Botschaft zurückzuführen war, die zu diesem Zeitpunkt an diese Organisation gesendet wurde, sodass der CEO aus dem Teams-Meeting ausgeschlossen wurde – und das sah nicht besonders gut aus.

Sie eröffneten daher einen Sev. 1-Fall. Sie hatten einen DSE rund um Teams. Der DSE des Teams wurde also aufgrund dieser internen Notiz, in der stand: „Hey Rob, ist unser DSE für diese Technologie zuständig? Du solltest dich vielleicht an ihn wenden“, von der Break/Fix-Seite benachrichtigt.

Er nahm den Anruf entgegen und innerhalb der ersten halben Stunde analysierte er die Situation, fand heraus, was genau schiefgelaufen war, und half ihnen dabei, eine Richtlinie zu implementieren, um zu verhindern, dass so etwas in Zukunft noch einmal passiert. Jetzt gibt es keinen Grund mehr, warum jemand anderes den CEO während einer Präsentation aus einem Anruf werfen könnte.

Dieser gesamte Prozess verlief aufgrund der Komplexität der Umgebung, der Art des Problems und der an der Lösung des Problems beteiligten Personen sehr schnell.

Der Kunde entschied sich außerdem, dass Microsoft sich ebenfalls mit diesem Problem befassen sollte.

Microsoft meldete sich innerhalb von zehn Minuten, nachdem sie unsere Analyse (die bereits fertig war), unseren Projektplan und die Vorgehensweise zur Lösung des Problems geprüft hatten, und Experten direkt von Microsoft sagten: „Wir würden nichts anders machen. Genau so sollte man damit umgehen.“

Wir konnten dieses Problem sehr zeitnah lösen, den Kunden wieder ans Telefon holen, das gesamte Problem beheben und dann sicherstellen, dass es in Zukunft nicht mehr auftritt. Diese agile Reaktion und Lösung wäre ohne das Engagement unseres DSE nicht möglich gewesen.

Ja, das passiert täglich, es ist also nichts Ungewöhnliches! Wenn ein Ticket eingeht und ein Techniker zum ersten Mal mit einem Kunden telefoniert, werden viele Daten erfasst. Er stellt Fragen wie: „Ich möchte Ihren Fall genauer verstehen. Warum rufen Sie mich an? Was ist passiert? Wie sieht die Umgebung aus? Wie viele Benutzer sind betroffen?“ Dieser gesamte Prozess wird durchlaufen.

Was passiert, ist, dass aufgrund dieser internen Notiz ein DSE gerufen wird, der dem Techniker einige Hintergrundinformationen geben kann. Oftmals hilft dies wirklich dabei, die Fehlersuche einzugrenzen und die Zeit zu verkürzen, die benötigt wird, bis ein Ticket den Lösungsprozess durchläuft.

Das ist so, als würden Sie und ich uns zum ersten Mal unterhalten, aber wir planen, dass unsere Familien etwas Zeit miteinander verbringen. Ich weiß nicht, wie viele Kinder Sie haben, und ich weiß nicht, was wir gemeinsam unternehmen werden – aber ich muss Ihnen trotzdem diese Fragen stellen.

Nun, sagen wir mal, ich weiß bereits von einem Freund, der dich schon länger kennt, dass du keine Tochter hast, also muss ich dir keine Fragen darüber stellen, was Töchter gerne machen. Ich habe gerade die Fragehalbe gekürzt, um uns bei der Entscheidung zu helfen, wie wir ein Spieltreffen für die Kinder organisieren können.

Dann muss ich Ihnen auch keine lauter dumme Fragen stellen, wie zum Beispiel, wie alt Ihre Tochter ist oder was sie gerne macht. Ihr langjähriger Freund ist wie ein DSE für einen Kunden: ein Experte, der mehr über den digitalen Kontext und die IT-Infrastruktur des Kunden weiß und Neulinge dabei unterstützen kann, mitzureden, wie man dem Kunden zum Erfolg verhelfen kann.

Nehmen wir an, Ihr langjähriger Freund (in diesem Szenario der DSE) hat mir erzählt, dass Sie einen 12-jährigen Sohn haben, der Baseball liebt. Wenn ich mich mit Ihnen unterhalte, haben wir diese Fragen bereits wieder eingegrenzt. Auf diese Weise kann ich noch mehr Gespräche darüber vermeiden, ob Ihr Sohn Fußball oder Baseball mag. Ich kann mich direkt auf das konzentrieren, was er braucht.

All diese Dinge kann ich vom DSE bekommen, und wir können direkt zur Frage übergehen, was sie wirklich brauchen. Brauchen sie einen Trainer, der ihnen hilft, ihre RBIs beim Schlagen zu verbessern? Wenn das stimmt, dann werde ich das Schlag-T-Shirt nicht zum Spieltreffen mitbringen, weil er es gar nicht brauchen wird.

Dank des DSE kommen wir direkt zum Kern des Problems, anstatt uns in einem Gespräch ausschließlich auf Ihren Hintergrund zu konzentrieren. Die Hintergrundgeschichte ist zwar interessant, hilft aber nicht bei der Lösung der aktuellen Aufgabe. Da DSEs über fundierte Kenntnisse der Umgebung verfügen, können sie dem Break/Fix-Team dabei helfen, eine Reihe von Faktoren auszuschließen.

Wenn Sie schon einmal Fehlerbehebung betrieben haben, wissen Sie, dass Experten viel Zeit damit verbringen müssen, ein Problem einzugrenzen, um eine Lösung zu finden. Mit dem DSE können wir das viel schneller eingrenzen.

Die Eskalationsunterstützung von Microsoft umfasst heute die Einbeziehung mehrerer Organisationen, und aufgrund von Datenschutzgesetzen ist es ihnen häufig nicht gestattet, diese Informationen weiterzugeben.

Wenn ein Support-Mitarbeiter seine Schicht beendet und es beispielsweise 17:00 Uhr ist, kann es sein, dass er dieses Eskalationsticket an einen anderen Anbieter weiterleitet, der aufgrund von Datenschutzbestimmungen nicht alle Daten vom ersten Anbieter erhalten kann, da keiner von ihnen Microsoft-Mitarbeiter ist.

Sie sind alle„V-Dash“, was für „Vendor“ (Anbieter) steht und diesen Mitarbeitern nur Zugriff auf das Ticket auf Anbieterebene gewährt.

Alle unsere Mitarbeiter sind US Cloud, daher ist der Prozess auf unserer Seite ziemlich einfach. Wenn Sie über US Cloud ein Ticket eröffnen, sprechen Sie mit einem DSE oder einem Mitarbeiter des Break/Fix-Teams.

Und sie werden alle miteinander kommunizieren und Daten auf sichere Weise austauschen können, verschlüsselt und von Endpunkt zu Endpunkt. Unsere Techniker können offen und frei kommunizieren.

Und wenn wir dann jemanden hinzuziehen müssen, um die Lösung des Tickets zu unterstützen, kann dieser einen Experten auf Enterprise-Architekt-Ebene hinzuziehen, der das Gesamtbild betrachten und die einzelnen Teile zusammenfügen kann. Manchmal ist es sehr komplex und es bedarf der Zusammenarbeit mehrerer Fachleute aus verschiedenen Disziplinen, um eine Lösung zu finden. Break/Fix-Tickets sind fast nie mehr eindeutig – es handelt sich um mehrere Technologien und Probleme. Wir haben die Möglichkeit, diese Teams hinzuzuziehen.

Andere Eskalationen nehmen bei anderen Anbietern viel Zeit in Anspruch, da sie diese Disziplinen nicht einbringen können. Sie sind gewissermaßen in Schubladen gesteckt und isoliert. Der SQL-Mitarbeiter erledigt seinen Teil, leitet das Ticket dann an den SharePoint-Mitarbeiter weiter, der seinen kleinen Teil erledigt und es an den Power BI-Mitarbeiter weiterleitet, und so weiter.

In der Zwischenzeit tickt die Uhr weiter und das Problem besteht weiterhin, richtig? Die Dinge werden nicht gelöst. Das ist sehr frustrierend. Es ist keine tolle Erfahrung und für Ingenieure ist es sehr schwierig, den Überblick darüber zu behalten, wann sie wechseln sollen. Sie müssen sich fragen: „Wann wechsle ich von SQL zu SharePoint zu Power BI? Wann sind wir fertig?“

Und dann gibt es jede Menge Schuldzuweisungen (unbeabsichtigt, aber dennoch Schuldzuweisungen), wer wahrscheinlich den Ball fallen gelassen hat. Und sie verwenden tatsächlich das Wort „wahrscheinlich“, was für die Lösung und Problembeseitigung bei Störungsmeldungen nicht gerade förderlich ist.

Wenn ich der Kunde bin, möchte ich eindeutige Antworten. Ich möchte eine Antwort und ich möchte loslegen können.

Wir haben also drei verschiedene Bereiche ins Visier genommen. Einer davon ist die Projektberatung. Kunden können sich mit Fragen zu ihren Microsoft-Produkten an uns wenden und erhalten fachkundige Hilfe. Die Fragen können sich auf alles beziehen, wofür sie professionelle Beratung benötigen, beispielsweise auf eine neue Schaltfläche, die gerade in der Benutzeroberfläche hinzugefügt wurde, oder auf eine neue Vorgabe von Microsoft, dass etwas eingestellt wird oder innerhalb eines bestimmten Zeitraums aktualisiert werden muss.

Die Cloud gehört uns nicht, wir mieten sie nur. Da wir sie mieten, kann der „Vermieter“ jederzeit sagen: „Ich werde nächste Woche die Wände lila streichen. Sie müssen darauf vorbereitet sein.“

Und wir sagen: „Ich bin noch nicht bereit! Ich habe noch Bilder an der Wand, deshalb kann ich sie nicht lila streichen.“ Also kommen Kunden zu uns und fragen: „Muss ich mir darüber Gedanken machen? Wenn sie sie lila streichen, hat das Auswirkungen auf mich? Was wird passieren?“

Das nennen wir ein Projektberatungsticket. Kunden möchten vielleicht nur ein paar Fragen klären oder haben bereits einen Plan. Wir können ihnen bei der Vorbereitung helfen: „Wir werden Folgendes tun: Wir entfernen die Nägel und spachteln die Löcher zu. Dann kann Microsoft kommen und alles lila streichen.“

Aber wie bereiten wir uns darauf vor? Haben wir etwas übersehen? Wenn beispielsweise beim Streichen keine Plane für den Boden vorhanden ist, wird die Wand lila, aber auch ein Teil des Bodens, da Farbe verschüttet wird und tropft. Bei solchen Prozessen unterstützen wir sie im Rahmen einer Projektberatung.

Der nächste Schritt unserer Beratungsdienstleistungen ist die vollständige Projektumsetzung. Als Projekt betrachten wir alles, was mehr als 15 Stunden in Anspruch nimmt. Das kann beispielsweise die Aufrüstung von 300 Servern sein. Es kann sich auch um Migrationen oder Fusionen und Übernahmen handeln, bei denen wir den eigentlichen Fusionsprozess durchführen, E-Mail-Adressen ändern und Daten hin und her verschieben.

Bei Projekten, die 15 Stunden und mehr in Anspruch nehmen, kann der Aufwand in die Tausende gehen. Das hängt wirklich davon ab, wie groß die Organisation ist und wie viel Unterstützung sie von US Cloud benötigt.

Bei Projekten dürfen wir praxisnah arbeiten und bieten umfassende Unterstützung. Wir führen keine Mitarbeiterprotokolle, sondern Beratungsprotokolle.

Wir haben intelligente Fachleute, die Ihnen bei der Durchführung eines Prozesses helfen können, denn oft läuft Ihnen die Zeit davon. Wenn Sie Ihrem Vorgesetzten gesagt haben: „Wir werden das bis Freitag erledigen“, und Sie es bis Freitag nicht schaffen werden, weil Ihnen die Zeit oder die Fachleute dafür fehlen. Sie brauchen mehr Hände, denn manchmal braucht es ein ganzes Dorf, um einige dieser Projekte zu realisieren, weil sie so groß sind. Wir haben Technologieberater und Unternehmensarchitekten, die einspringen und das übernehmen können.

Sie können buchstäblich mit anpacken und für Ihr Team arbeiten. Und der Grund, warum ich es als Beratungsprotokoll bezeichne, ist, dass wir zwar viele Tests und Pilotprojekte durchführen, aber manchmal gibt es Überraschungen. Wir wissen, dass es etwas Besonderes in dem Konto gibt oder dass in der Organisation etwas vor sich geht, das niemand angesprochen hat, bis wir mit einem neuen Prozess beginnen. Dann können wir uns darauf einstellen und diese Probleme spontan lösen.

Das letzte Angebot unseres Beratungsdienstes ist, wie bereits erwähnt, DSE. DSE ist also unser drittes Angebot, mit dem wir dem Unternehmen ein erstklassiges Familienerlebnis bieten, um uns wirklich als Teil des Teams zu integrieren, was für die Kunden sehr angenehm ist.