Derde partij: Een Microsoft Support Show – Hoe DSE's Microsoft Support Services versnellen (aflevering 6).

Dat is een goede vraag. Als manager enterprise architectuur heeft mijn team gekeken naar aanbiedingen die al een tijdje bestaan bij verschillende organisaties, en we zijn gekomen met de DSE in de "DSE" voor een "designated support engineer" (aangewezen ondersteuningsingenieur). Het zijn enterprise architecten, maar ze vervullen een ondersteunende rol – in feite een eersteklas behandeling voor onze klanten. Een van onze doelen is het opbouwen van een relatie met de klant.

Dat is belangrijk voor ons, omdat je bijvoorbeeld wel eens hebt meegemaakt dat je je mobiele provider belt, ondersteuning krijgt en met wie je dan ook aan de lijn komt. Soms zijn ze goed, maar soms moet je je situatie steeds opnieuw uitleggen. En als je de volgende dag terugbelt, wat denk je dan? Je krijgt iemand anders aan de lijn. Je moet het hele verhaal opnieuw beginnen.

We wilden onze klanten die ervaring niet bezorgen als we dat konden vermijden. Hoe doen we dat? We worden onderdeel van hun organisatie. Dat is de rol van de DSE: zij zijn eigenaar van die technologie voor hun klant en weten er alles van.

Een deel van die verantwoordelijkheid bestaat uit het plaatsen van interne notities op tickets, zodat wanneer technici een break/fix-ticket openen met een ernstniveau van één, twee, drie of vier, het duidelijk is dat we een DSE hebben die bekend is met die technologie en er alles van weet, zodat ze waarschijnlijk een groot deel van dat inleidende voorbereidende werk kunnen overslaan. Dat kunnen vragen zijn als: "Hoe ziet de achtergrond eruit? Wat is de historische context? Wat gebeurt er in de omgeving dat hiertoe zou kunnen hebben geleid?"

Het is fijn dat onze technici op deze verantwoordelijkheid kunnen vertrouwen om die hiaten te overbruggen en een helpende hand te bieden, want soms zijn ze erg vertrouwd met technologie en hebben ze aanvullende ideeën. Dat zijn puur reactieve diensten die worden ondersteund door proactieve diensten: leren van een andere expert die die omgeving al kent en voorkomen dat klanten hun verhaal steeds opnieuw moeten vertellen.

Het andere belangrijke doel dat we hebben, houdt verband met het feit dat technologie tegenwoordig zo sterk is geconvergeerd. Ik ben zo blij dat Microsoft geen snelwegen bouwt, want er zijn geen rijstroken – alle auto's zouden op elkaar botsen. Als al deze 'auto's' botsen en je hebt technologen die SQL kennen, kunnen problemen met dat systeem overslaan naar Intune, en die kunnen weer overslaan naar Azure of M365. Daarna raakt het probleem helemaal verweven. Met andere woorden, 80% van het probleem, de technologie, de upgrade of de proactieve service die wordt aangepakt, kan SQL zijn. De andere 20% kan van alles zijn.

Voor US Coud is dit heel gewoon, maar voor andere organisaties – en ik ben al 40 jaar actief in de consultancy – is dit niet erg gebruikelijk. En wat echt leuk is, is dat we, zoals ik al zei, reactieve en proactieve diensten samenvoegen om onze klanten een compleet aanbod te bieden. We schakelen ook andere technologen in als klanten die nodig hebben om die andere 20% van hun Microsoft-problemen op te lossen. Dat kan SQL, SharePoint, Power BI of wat dan ook zijn dat nodig is om die tickets op te lossen. We doen het allemaal.

We hadden er vorige week nog een. De CEO van een zeer grote onderneming in de Fortune 100 – waarschijnlijk een lager nummer dan 100 – gaf een presentatie tijdens een Teams-vergadering. Er waren 80 of meer mensen aan de lijn, allemaal C-level executives. Onze klant werd echter tijdens de presentatie uit de vergadering gezet. Dat is geen goede zaak; het betekent dat iemand in de Teams-vergadering de mogelijkheid had om de presentator uit de vergadering te zetten.

Dit was een verkeerde configuratie binnen de organisatie, en het kwam door de timing en de boodschap die op dat moment naar deze organisatie werd gestuurd, waardoor de CEO uit de Teams-vergadering werd gezet – en dat zag er niet erg goed uit.

Daarom hebben ze een Sev. 1-zaak geopend. Ze hadden een DSE rond Teams. De DSE van het team werd dus op de hoogte gebracht door de break/fix-afdeling vanwege die interne notitie met de tekst: "Hé Rob, is onze DSE op de hoogte van deze technologie? Misschien kun je contact met hem opnemen."

Hij nam het gesprek over en binnen een half uur had hij de situatie geanalyseerd, precies uitgezocht wat er mis was gegaan en hen geholpen een beleid te implementeren om te voorkomen dat dit in de toekomst nog eens zou gebeuren. Nu is er geen enkele reden meer waarom iemand anders de CEO uit een gesprek zou kunnen gooien terwijl hij een presentatie geeft.

Dat hele proces verliep erg snel vanwege de complexiteit van de omgeving, de aard van het probleem en de deelnemers die het probleem oplosten.

De klant besloot ook dat Microsoft dit probleem moest bekijken.

Microsoft kwam binnen tien minuten terug met onze analyse (die al klaar was), ons projectplan en hoe we verder moesten gaan met de oplossing, en experts van Microsoft zelf zeiden: "We zouden niets anders doen. Dit is precies hoe je dit moet aanpakken."

We konden dat probleem zeer snel oplossen, de klant weer aan de lijn krijgen, het hele probleem oplossen en ervoor zorgen dat het in de toekomst niet meer zou voorkomen. Deze flexibele reactie en oplossing zouden niet mogelijk zijn geweest zonder de toewijding van onze DSE.

Ja, dit gebeurt dagelijks, dus het is geen zeldzame gebeurtenis! Er wordt veel informatie verzameld wanneer een ticket binnenkomt en een technicus voor het eerst met een klant aan de telefoon komt. Ze stellen vragen als: "Ik wil graag uw verhaal horen. Waarom belt u mij? Wat is er aan de hand? Hoe ziet de omgeving eruit? Hoeveel gebruikers worden hierdoor getroffen?" Ze doorlopen dat hele proces.

Wat er gebeurt, is dat er opnieuw, vanwege die interne notitie, een DSE wordt gebeld en zij kunnen de technicus wat achtergrondinformatie geven. Vaak helpt dit echt om het oplossen van het probleem te versnellen, waardoor de tijd die nodig is om een ticket in behandeling te nemen, wordt verkort.

Dat is net als een situatie waarin jij en ik elkaar nog niet zo lang kennen, maar we plannen om onze gezinnen samen tijd te laten doorbrengen. Ik weet niet hoeveel kinderen je hebt en ik weet niet wat we samen gaan doen, maar ik moet je toch dat soort vragen stellen.

Nou, laten we zeggen dat ik al van een vriend die je al langer kent weet dat je geen dochter hebt, dus ik hoef je geen vragen te stellen over wat dochters graag doen. Ik heb zojuist de vragenlijst gehalveerd om ons te helpen beslissen hoe we een speelafspraak voor de kinderen kunnen regelen.

Ik hoef je dan ook geen heleboel domme vragen te stellen, zoals hoe oud je dochter is of wat ze graag doet. Die oude vriend van je is als een DSE voor een klant: een expert die meer weet over de digitale context en IT-infrastructuur van de klant en nieuwkomers kan ondersteunen in het gesprek over hoe de klant succesvol kan zijn.

Stel dat je oude vriend (in dit scenario de DSE) me heeft verteld dat je een 12-jarige zoon hebt die van honkbal houdt. Als ik het gesprek met je aangaat, hebben we die vragen alweer een stuk beperkt. Op die manier hoef ik niet meer te praten over of je zoon van voetbal of honkbal houdt. Ik kan meteen naar wat hij nodig heeft gaan.

Dat zijn allemaal dingen die ik uit de DSE kan halen, en we kunnen meteen verdergaan met het gesprek over wat ze echt nodig hebben. Hebben ze een coach nodig om hun slaggemiddelde te verbeteren? Als dat zo is, dan neem ik de slagtee niet mee naar de speelafspraak, want dan heeft hij die niet eens nodig.

Dankzij de DSE komen we meteen tot de kern van het probleem, in plaats van een heel gesprek te voeren dat beperkt blijft tot uw achtergrond. Hoewel de achtergrondinformatie interessant is, lost deze het huidige probleem niet op. Omdat DSE's een grondige kennis hebben van de omgeving, kunnen ze het break/fix-team helpen een heleboel zaken uit te sluiten.

Als je ooit problemen hebt opgelost, weet je dat experts veel tijd moeten besteden aan het inperken van een probleem om de oplossing te vinden. De DSE helpt ons dat veel sneller in te perken.

De manier waarop Microsoft momenteel escalatieondersteuning biedt, omvat het gebruik van meerdere organisaties, en vanwege privacywetgeving is het vaak niet toegestaan om die informatie te delen.

Als een ondersteuningsmedewerker zijn dienst heeft beëindigd en het is bijvoorbeeld 17.00 uur, kan het zijn dat hij dat escalatieticket naar een andere leverancier stuurt die bepaalde gegevens van de eerste leverancier niet kan krijgen vanwege privacykwesties, omdat geen van hen Microsoft-medewerkers zijn.

Ze zijn allemaal'V-Dash', wat staat voor 'vendor' (leverancier) en geeft die werknemers alleen toegang tot het ticket op leveranciersniveau.

Al onze medewerkers werken met US Cloud, dus het proces aan onze kant is vrij eenvoudig. Wanneer u een ticket opent via US Cloud, krijgt u te maken met een DSE of een break/fix-medewerker.

En ze zullen allemaal met elkaar kunnen communiceren en gegevens kunnen delen op een veilige manier, versleuteld en van eindpunt tot eindpunt. Onze technici kunnen open en vrij communiceren.

En als we dan iemand moeten inschakelen om te helpen bij het oplossen van het ticket, dan kunnen zij een expert inschakelen die op het niveau van een enterprise-architect werkt en die het totaalplaatje kan bekijken om alle stukjes in elkaar te passen. Soms is het erg complex en zijn er meerdere ogen uit verschillende disciplines nodig om tot een oplossing te komen. Break/fix-tickets zijn bijna nooit meer eenduidig – het gaat om meerdere technologieën en problemen. Wij hebben de mogelijkheid om die teams in te schakelen.

Andere escalaties kosten veel tijd bij andere leveranciers omdat zij die disciplines niet kunnen inzetten. Ze zitten een beetje vast in hokjes en silo's. De SQL-medewerker doet zijn deel, geeft het ticket vervolgens door aan de SharePoint-medewerker, die zijn deel doet en het doorgeeft aan de Power BI-medewerker, enzovoort.

Ondertussen tikt de klok door en is er nog steeds een probleem, toch? De zaken worden niet opgelost. Dat is erg frustrerend. Het is geen prettige ervaring en het is erg moeilijk voor engineers om bij te houden wanneer ze moeten overschakelen. Ze moeten zich afvragen: "Wanneer ga ik van SQL naar SharePoint naar Power BI? Wanneer zijn we klaar?"

En dan wordt er veel met de vinger gewezen (onbedoeld, maar toch) naar degene die waarschijnlijk de fout heeft gemaakt. En ze gebruiken het woord 'waarschijnlijk', wat niet bevorderlijk is voor het oplossen van problemen wanneer je te maken hebt met storingsmeldingen.

Als ik de klant ben, wil ik duidelijke antwoorden. Ik wil een antwoord en ik wil aan de slag kunnen.

We richten ons dus op drie verschillende gebieden. Een daarvan is projectadvies. Klanten kunnen bij ons terecht met vragen over hun Microsoft-producten en krijgen deskundige hulp. Vragen kunnen gaan over alles waarvoor ze professioneel advies willen, zoals een nieuwe knop die net in de interface is verschenen, of een nieuw voorschrift van Microsoft dat iets gaat verdwijnen, of iets dat binnen een bepaalde termijn moet worden geüpgraded.

We zijn niet de eigenaar van de cloud, we huren hem alleen. Omdat we hem huren, kan de 'verhuurder' op elk moment zeggen: 'Ik ga volgende week de muren paars schilderen. Zorg dat je daar klaar voor bent.'

En wij zeggen dan: "Ik ben er nog niet klaar voor! Ik heb nog schilderijen aan de muur hangen, dus ik kan het niet paars maken." Klanten komen dan naar ons toe en vragen: "Moet ik me hier zorgen over maken? Als ze het paars maken, heeft dat dan gevolgen voor mij? Wat gaat er gebeuren?"

Dat noemen we een projectadvieskaart. Klanten willen misschien gewoon wat vragen stellen, of ze hebben een plan. Wij kunnen hen helpen bij de voorbereiding: "Dit gaan we doen. We verwijderen de spijkers en plamuren de gaten. Daarna kan Microsoft langskomen om het paars te schilderen."

Maar hoe bereiden we ons daarop voor? Hebben we iets over het hoofd gezien? Als er bijvoorbeeld geen zeil op de vloer ligt tijdens het schilderen, wordt de muur paars, maar ook een deel van de vloer, omdat er verf zal worden gemorst en druppels zullen vallen. Dat zijn het soort processen waarbij we hen helpen via projectadvies.

Het volgende wat we doen in de adviesdiensten is een volledige projectimplementatie. We beschouwen alles wat meer dan 15 uur in beslag neemt als een project. Het kan bijvoorbeeld gaan om het upgraden van 300 servers. Het kan ook gaan om migraties of een fusie en overname, waarbij we het daadwerkelijke fusiegedeelte uitvoeren en e-mailadressen wijzigen en gegevens heen en weer verplaatsen.

Voor projecten die 15 uur of meer in beslag nemen, kan het om duizenden euro's gaan. Het hangt echt af van hoe groot de organisatie is en hoeveel hulp ze nodig hebben van US Cloud.

Bij projecten mogen we hands-on werken voor volledige ondersteuning. We houden geen personeelslogboeken bij, maar advieslogboeken.

We hebben intelligente professionals die kunnen helpen bij het uitvoeren van een proces, omdat je vaak tijd tekort komt. Als je tegen je manager hebt gezegd: "We hebben dat vrijdag klaar", en je krijgt het niet voor vrijdag af omdat je geen tijd hebt of geen professionals die het kunnen doen. Je hebt meer handen nodig, want soms is er een heel dorp nodig om sommige van deze projecten uit te voeren, omdat ze zo groot zijn. Wij hebben technologieconsultants en enterprise-architecten die dat kunnen doen.

Ze kunnen letterlijk de handen uit de mouwen steken en voor uw team aan de slag gaan. En de reden waarom ik zeg dat het om consultancy gaat, is omdat we veel testen en pilots uitvoeren en zo, maar soms komt er een curveball. We weten dat er iets anders is in de account of dat er iets gaande is in de organisatie waar niemand iets aan heeft gedaan totdat we een nieuw proces starten. We kunnen dan snel schakelen en die zaken direct oplossen.

Het laatste wat onze adviesdienst doet, is DSE, zoals we al hebben vermeld. DSE is dus ons derde aanbod, waarmee we de organisatie een eersteklas ervaring bieden en ons echt integreren als een verlengstuk van het team, wat prettig is voor klanten.