Wir haben unseren Technologieanbietern Macht \u00fcber unsere Organisationen gegeben. Sehen Sie, was passiert, wenn ein gesch\u00e4ftskritisches System ausf\u00e4llt \u2013 das Unternehmen bekommt einen Herzinfarkt. F\u00e4llt das ERP-System aus, steht unsere Produktionslinie still. Versagt das Abrechnungssystem, k\u00f6nnen wir unseren Kunden nichts berechnen. St\u00fcrzt die Datenbank ab, wissen wir nicht einmal, wer unsere Kunden sind. <\/p>\n
Dieses Machtungleichgewicht zieht sich durch die gesamte Anbieter-\/Kundenbeziehung. Wir sehen es in Projekten, wenn wir darauf warten, dass unsere Anbieter uns sagen, wann unsere neuen Systeme live gehen k\u00f6nnen. Bei Menschen, wenn wir technische Fachkr\u00e4fte nach ihren Skills statt nach ihrer Passung zu unserem Gesch\u00e4ft einstellen. Beim Geld, wenn wir in Preisvereinbarungen feststecken, die selbst Scrooge vor Neid gr\u00fcn werden lie\u00dfen. <\/p>\n
Wir werden zu Opfern unserer Anbieter. Und je mehr wir uns auf IT verlassen, desto schlimmer wird es \u2013 es sei denn, wir tun etwas dagegen. <\/p>\n
Was k\u00f6nnen wir tun? Beginnen Sie damit anzuerkennen, dass die meisten IT-Anbieterbeziehungen erst nach dem Verkauf wirklich entstehen \u2013 wenn der Anbieter die von ihm verkauften Systeme unterst\u00fctzt. Doch wer legt die Bedingungen der Support-Beziehung fest? Viel zu oft ist es der Anbieter. <\/p>\n
Es geht hier nicht um Service-Level-Agreements oder Vertr\u00e4ge \u2013 auch wenn diese Dinge entscheidend sind. Das Schl\u00fcsselwort ist Beziehung. Es geht darum, Erwartungen an das Verhalten festzulegen und nichts Geringeres zu akzeptieren. Es geht darum, von unseren Anbietern Professionalit\u00e4t zu erwarten \u2013 ihnen aber zu erkl\u00e4ren, was das bedeutet. <\/p>\n
Sieben Regeln bestimmen wirksame Support-Beziehungen f\u00fcr gesch\u00e4ftskritische Systeme. Wir haben diese Regeln durch genaue Beobachtung von Support-Beziehungen aus Kunden- und Anbietersicht identifiziert. Kunden eskalieren, weil der Anbieter gegen eine oder mehrere dieser Regeln verst\u00f6\u00dft. <\/p>\n
Jeder Kunde mit gesch\u00e4ftskritischen Systemen sollte von seinem Technologieanbieter vern\u00fcnftigerweise erwarten k\u00f6nnen, dass er:<\/p>\n
Zusammen bilden die sieben Regeln ein Kundenmanifest \u2013 eine Blaupause, mit der der Kunde die Beziehung wieder in die Hand nimmt und das Machtgleichgewicht wiederherstellt. Wie? <\/p>\n
In der Welt gesch\u00e4ftskritischer Systeme unterst\u00fctzt der Anbieter Ihr Gesch\u00e4ft \u2013 nicht nur Ihre Systeme. Wenn ein System ausf\u00e4llt, brauchen Sie den Anbieter, der alles Notwendige tut \u2013 nicht nur, um Ihre Systeme wiederherzustellen, sondern um auch das Gesch\u00e4ft wieder zum Laufen zu bringen. <\/p>\n
Beispielsweise st\u00fcrzte ein Lager-Server in einem Vertriebsunternehmen sporadisch ab. Jeder Absturz kostete das Unternehmen Zehntausende Pfund an entgangenem Gesch\u00e4ft. Der Hardwareanbieter konnte nachweisen, dass weder die Hardware noch die Anwendung das Problem verursachten. Trotzdem unterst\u00fctzte der Anbieter den Kunden weiterhin bei dem Problem \u2013 und half, die tats\u00e4chliche Ursache zu belegen: Sabotage. <\/p>\n
Lassen Sie den Anbieter Ihr Gesch\u00e4ft unterst\u00fctzen. Gute Fragen an Ihren Anbieter: <\/strong><\/p>\n Es m\u00f6gen ihre Systeme sein, aber es ist Ihr Gesch\u00e4ft. Erinnern Sie sie daran. <\/p>\n Wenn ich einen Herzinfarkt habe, sollte mein \u00dcberleben nicht davon abh\u00e4ngen, ob mich Dr. Smith statt Dr. Jones behandelt. Ich erwarte von jedem Arzt, dass er mich zuverl\u00e4ssig und gut behandelt. Wenn unsere Organisation einen Herzinfarkt hat, sollten wir von unserem Anbieter weniger erwarten? Insbesondere: Welche konkreten, klaren und wirksamen Prozesse haben sie etabliert, um unser Gesch\u00e4ft wieder zum Laufen zu bringen \u2013 unabh\u00e4ngig davon, wer den Fall bearbeitet? <\/p>\n Ein Systemlieferant richtet beispielsweise immer dann einen \u201eWar Room\u201c ein, wenn es bei einem gesch\u00e4ftskritischen Kunden zu einem Absturz kommt. Jede Person im Raum hat eine spezifische Rolle, und sie arbeiten systematisch in diesen Rollen, um das Problem zu diagnostizieren und den Service wiederherzustellen. Unabh\u00e4ngig davon, wer welche Rolle \u00fcbernimmt, funktioniert der War Room immer gleich \u2013 nach Plan. <\/p>\n Heben Sie den Standard an. Fragen Sie:<\/strong><\/p>\n Es ist Ihr Gesch\u00e4ft. Sie sollten die Standards setzen. <\/p>\n Im Fernsehen: Wenn die Polizei bei einem Verh\u00f6r den Angstpegel eines Verd\u00e4chtigen erh\u00f6hen will, stellt sie eine Frage, bekommt eine Antwort, sagt nichts und verl\u00e4sst den Raum. W\u00e4hrend die Stille w\u00e4chst, macht sich der Verd\u00e4chtige \u00fcber vieles Sorgen, vor allem aber: \u201eWas noch? Was als N\u00e4chstes?\u201c Wenn die Polizei zur\u00fcckkommt, geht der Verd\u00e4chtige vor Sorge die W\u00e4nde hoch und ist verzweifelt bereit zu gestehen. <\/p>\n Erstaunlich viele Anbieter \u00fcbernehmen eine \u00e4hnliche \u201eFrage\/Stille\u201c-Routine. Sie stellen Fragen zu einem schweren Absturz und gehen dann offline, um \u201eam Problem zu arbeiten\u201c. Sie wissen nicht, warum sie gefragt haben, was sie gefragt haben, was sie mit den Antworten tun oder was als N\u00e4chstes passiert. Kein Wunder, dass Sie eskalieren! <\/p>\n Einige Anbieter leiten ihre Kunden jedoch sehr gut. Ein Softwareanbieter nutzt einen konsistenten Troubleshooting-Prozess, um die Diagnose gesch\u00e4ftskritischer Abst\u00fcrze zu strukturieren, und teilt diesen mit dem Kunden. Das bedeutet: Bei jedem Kundenkontakt erkl\u00e4ren sie, welche Informationen sie ben\u00f6tigen, warum sie sie ben\u00f6tigen, was sie damit tun und wohin der n\u00e4chste Schritt f\u00fchrt. <\/p>\n Reduzieren Sie die Unsicherheit. Verbessern Sie, wie Ihre Anbieter Sie bei Major Incidents anleiten. Fragen Sie sie: <\/strong><\/p>\n Sie m\u00f6chten, dass jeder Schritt ihrer Diagnose transparent ist. Keine \u00dcberraschungen. <\/p>\n Viele gesch\u00e4ftskritische Probleme werden eskaliert, weil das Wissen des Anbieters an seine Grenzen st\u00f6\u00dft. Vielleicht hat er ein Problem wie unseres noch nie gesehen, oder das Problem ist ungew\u00f6hnlich komplex. Klassischerweise werfen Anbieter dann eine Reihe von Fixes auf das Problem \u2013 in der Hoffnung, dass einer davon greift. Die meisten Fixes scheitern. Schlimmer noch: Sie k\u00f6nnen mehr Schaden anrichten als das urspr\u00fcngliche Problem. <\/p>\n Gesch\u00e4ftskritische Probleme lassen sich konsistent analysieren. Ein Finanzdienstleister hatte ein System, das w\u00e4hrend des n\u00e4chtlichen Tagesabschluss-Abgleichs sporadisch abst\u00fcrzte. Der Absturz zwang das Unternehmen, jede Nacht Hunderte Aushilfskr\u00e4fte einzusetzen, um die Arbeit manuell zu erledigen, damit es am n\u00e4chsten Tag legal handeln konnte. Das war ein gro\u00dfer Aufwand, den man nicht wiederholen wollte. Das Problem war komplex, daher nutzte der Anbieter ein Diagnoseprotokoll, das er mit dem Kunden teilte. Das Protokoll half, unn\u00f6tige System\u00e4nderungen zu minimieren, und das Problem wurde effizient behoben. <\/p>\n Leiten Sie den Kunden an. Helfen Sie Ihrem Anbieter, das Problem zu l\u00f6sen. Fragen Sie ihn: <\/strong><\/p>\n Wird jeder Incident mit \u00e4hnlichen Fragen auf konsistente Weise gemanagt? Nein? Dann haben sie noch einen Weg vor sich. <\/p>\n Rettungsdienste retten Leben gegen die Uhr \u2013 aber sie k\u00f6nnen es sich nicht leisten, Fehler zu machen. Diese beiden widerspr\u00fcchlichen Anforderungen f\u00fchren dazu, dass sie f\u00fcr die meisten Standardsituationen konsistente Prozesse nutzen und diese strikt befolgen. Die Zeit ist zu knapp und der Einsatz zu hoch, um zu improvisieren. Ihren Prozessen zu folgen ist der schnellste Weg, die Aufgabe zu erledigen. <\/p>\n Dieselbe Disziplin brauchen wir von unseren Anbietern. Wenn das Problem kritisch ist, k\u00f6nnen wir es uns nicht leisten, dass sie es falsch machen. <\/p>\n Beispielsweise gibt es einen Hardwareanbieter, der verlangt, dass gesch\u00e4ftskritische Kundenprobleme, die \u00e4lter als zwei Stunden sind, an seine erfahrensten Ingenieure eskaliert werden. Damit diese sofort loslegen k\u00f6nnen und m\u00f6glichst wenig Zeit damit verbringen, bereits Bekanntes erneut durchzugehen, besteht das Unternehmen auf einem Standardsatz an Probleminformationen, der an sie \u00fcbergeben wird. Dieser Schritt hat die durchschnittliche Zeit bis zur L\u00f6sung von Kundenproblemen um 52 % verbessert. <\/p>\n Bringen Sie Ihre Anbieter auf die \u00dcberholspur. Fragen Sie sie: <\/strong><\/p>\n Verfolgen Sie die durchschnittliche Dauer gesch\u00e4ftskritischer Incidents. Wenn sie nicht sinkt, beantworten sie diese Fragen nicht. <\/p>\n Mit Entschuldigung an Oscar Wilde: \u201eEinmal abzust\u00fcrzen mag ein Ungl\u00fcck sein, zweimal abzust\u00fcrzen ist Fahrl\u00e4ssigkeit.\u201c Wenn unser Gesch\u00e4ft Schaden genommen hat, sollten wir erwarten, dass unser Anbieter belegt, warum es passiert ist \u2013 und warum es nicht wieder passieren wird. Viele Anbieter nehmen den Fu\u00df vom Gas, sobald das akute Problem gel\u00f6st ist. <\/p>\n Einige Anbieter machen es jedoch richtig. Nach jedem Major Incident liefert ein Systemanbieter seinen Kunden einen standardisierten Analysebericht, der nicht nur die Ursache beschreibt, sondern auch, wie sie nachgewiesen wurde, und was getan wird, damit es nicht wieder passiert. <\/p>\n Geben Sie Ihren Anbietern die Beweislast. Fragen Sie sie: <\/strong><\/p>\n Verfolgen Sie die Anzahl Ihrer Probleme, die im Laufe der Zeit wiederkehren. Wenn diese Zahl nicht sinkt, dann sind diese Ursachen keine Ursachen. <\/p>\n Viele Probleme sind vermeidbar: Vielleicht m\u00fcssen wir etwas anders machen; vielleicht k\u00f6nnen wir aus den Problemen anderer lernen. Wir brauchen die Hilfe unserer Anbieter, um Probleme zu vermeiden \u2013 m\u00f6glicherweise sogar mehr, als wir ihre Hilfe brauchen, um sie zu beheben. Umso bedauerlicher ist es, dass Support-Organisationen von Anbietern tendenziell nur sehr wenig proaktive Hilfe anbieten. <\/p>\n Es gibt Ausnahmen. Ein Serverunternehmen hat beispielsweise einen Kreis technischer Spezialisten aufgebaut, deren einzige Aufgabe darin besteht, dabei zu helfen, Probleme bei Kunden zu verhindern. Diese Kunden haben weniger Probleme, es gibt weniger Eskalationen. <\/p>\n Vorbeugen ist besser als heilen. Fragen Sie sie: <\/strong><\/p>\n Anbieter-Support ist notorisch reaktiv. Sie m\u00fcssen vorausdenken. Scheuen Sie sich nicht, ihnen dabei zu helfen. <\/p>\n Die sieben Regeln f\u00fcr Kundensupport l\u00f6sen nicht alle Support-Probleme, und sie sind auch nicht leicht umzusetzen. Wenn wir uns jedoch nicht mit Anbietern engagieren, um ihre Leistung zu verbessern, m\u00fcssen wir die Dinge so akzeptieren, wie sie sind \u2013 inklusive Ausfallzeiten und gesch\u00e4ftlicher Auswirkungen. <\/p>\n Viele Anbieter schneiden bei einigen dieser Grunds\u00e4tze gut ab. Nur wenige jedoch erf\u00fcllen alle sieben. Das ist nicht gut genug. Wir haben das Leben unserer Unternehmen unseren Technologieanbietern anvertraut. Wir haben ihre Regeln f\u00fcr den Support akzeptiert. Nicht l\u00e4nger. Unsere Unternehmen sind daf\u00fcr zu wichtig. Es ist Zeit, die Regeln zu \u00e4ndern. <\/p>\n","protected":false},"excerpt":{"rendered":" Die Bedingungen einer IT-Beziehung werden klassischerweise vom Anbieter diktiert \u2013 dabei sind unsere IT-Systeme gesch\u00e4ftskritisch. Es ist Zeit, die Beziehung zu revolutionieren \u2013 das Kundenmanifest zeigt Ihnen, wie … Wir haben unseren Technologieanbietern Macht \u00fcber unsere Organisationen gegeben. Sehen Sie, was passiert, wenn ein gesch\u00e4ftskritisches System ausf\u00e4llt \u2013 das Unternehmen bekommt einen Herzinfarkt. F\u00e4llt das […]<\/p>\n","protected":false},"author":8,"featured_media":33336,"template":"","white-paper-type":[],"class_list":["post-63695","white-paper","type-white-paper","status-publish","has-post-thumbnail","hentry"],"acf":[],"yoast_head":"\n\n
2. Zuverl\u00e4ssig liefern.<\/h4>\n
\n
3. Den Kunden anleiten.<\/h4>\n
\n
4. Probleme treffsicher analysieren.<\/h4>\n
\n
5. Schnell sein.<\/h4>\n
\n
6. Es belegen.<\/h4>\n
\n
7. Vorausschauend handeln.<\/h4>\n
\n