Referenzwertige Referenzen

Qualitätssicherung einer Ausschreibung ist eine Investition in Arbeitszeit. Referenzen eines Anbieters werden dort gerne als Qualitätscheck genutzt. Lohnt sich der Aufwand nach Referenzen zu fragen? Oder geht es um den Wohlfühlaspekt vor dem Kauf? Wie immer lautet die Antwort: Es kommt darauf an.

Auf jeder IT Messe oder Produktbroschüre finden sich die unabdingbaren bunt bedruckten DIN-A4-Seitenmit nahezu allen Firmenlogos der DAX-Unternehmen. Die Aussage ist, dieses Produkt oder dieser Service ist so begehrt, schau Dir einmal an wer das alles einsetzt. Viele zufriedene Kunden können nicht irren. Referenzen schaffen ein Wohlgefühl. Das ist absolut in Ordnung, so lange Wohlgefühl nicht mit Absicherung verwechselt wird.

Anderes Szenario: Soll ein brandneuer Service beschafft werden, so sind die wenigen Referenzen die ein Anbieter aufzeigen kann, eine gute Absicherung. Die Referenz bestätigt, dass wir nicht die Versuchskaninchen sind zumindest nicht die absolut Ersten. Selbstverständlich sollte mit einer der Referenzen ein intensiver Austausch angestrebt werden, um sicherzustellen, dass auch Gleiches mit Ähnlichem verglichen wird.

Mir ist irgendwann einmal aufgefallen, dass bei fast jedem Anbieter eines gewissen Service auf jeder dieser Referenz-Sammel-Folien immer wieder das Logo eines Automobilherstellers prangte. Fortan habe ich stets auf dieses Logo gezeigt, gesagt das mir dies bei allen Mitbewerbern auch aufgefallen ist und bat um Erklärung. Dabei stellte sich dann heraus, dass dieser Service bei dem Automobilhersteller nur von sehr kleinen Abteilungen eingekauft wurde. Also nichts mit der schönen Suggestion: Dieser Service wird von uns für ein 110-tausend Leute Unternehmen erbracht, sondern eher für die 110 Mann Abteilung. Im Prinzip dieselbe Aussage wie: Dieser Service wird von uns für ein kleines aber feines 110 Leute Unternehmen erbracht, was kein Firmenlogo Wert hätte.

Nun verlassen wir mal den Marketing-Teil dieses Thema hin zu Referenzen, die explizit angefragt werden. Bitte nennen sie drei Kunden derselben Branche, Größe, Sprachvielfalt und noch vieles mehr. Die Antworten darauf lassen Schlüsse über die Erfahrungen des Anbieters zu. Diese Information – an sich – ist meiner Erkenntnis nach nur bei kleineren Anbietern interessant, um festzustellen ob dieser dort überhaupt hinreichend oft in meinem Umfeld und meiner Größe unterwegs ist. Globale Anbieter werden weltweit genug Referenzen auftreiben können. Wie es um Erfahrungen und Einbindung der lokalen Dependance steht, bleibt offen.

Auch werden die vom Anbieter genannten Referenzen genau die Kunden sein, die gute Erfahrungen gemacht haben. Warum alles zu einem guten Zustand geführt hat, der nun Referenzwertig ist, hängt von vielen Faktoren ab. Mein Bereich hatte einmal maximalen Ärger mit einem amerikanischen Softwareanbieter. In dieser Situation wandte ich mich an einen Freund, der beruflich auch Software von diesem Anbieter einsetzte. Der war recht zufrieden mit dem Anbieter. Schon nach kurzer Diskussion stellte sich heraus, dass auch sie unter ganz ähnlichen Problemen litten, jedoch kümmerte sich der Hersteller in seinem Fall aktiv und nachweisbar schnell, während ich nur vertröstet wurde. Dies lag schlicht und ergreifend an der Abnahmemenge, die Firma meines Freundes war um Faktor 10 größer und nahm entsprechend mehr Lizenzen ab. Mein Arbeitgeber war (und blieb) ein unwichtigerer Kunde, der übrigens auf mein betreiben den Vertrag hat auslaufen lassen :-)

Ein direkter Kontakt in die Firma kann auch mal den gegenteiligen Effekt haben, das heißt vernebeln, statt Transparenz schaffen. Ein arg gebeutelter Bekannter machte mich auf eine ärgerliche permanente Schlechtleistung aufmerksam. Da ich ohnehin in dem Nachbarbereich zu tun hatte, konnte ich die Ursache recherchieren. Das Ende vom Lied war: Sein Arbeitgeber hatte die Leistung extrem gekürzt und diese gekürzten Leistungen ausgeschrieben. Im Ergebnis waren alle Endanwender unzufrieden, da sie die erwartete Leistung nicht erhielten, sondern nur die definierte Leistung. Eine offene Kommunikation, dass dies von der Geschäftsleitung so gewollt ist und der Dienstleister alles wie gewünscht liefert, fand nicht statt. Nach ein bis zwei Jahren war dies allgemein bekannt und die Endanwender haben sich an den Zustand gewöhnt bzw. kannten die Verursacher der Probleme.

Der Mittelweg zwischen dem maximal Gut oder Schlecht muss bei Referenzen vorab festgelegt werden. Wozu dient die Frage nach einer Referenz? Wie Zeit viel bin ich bereit zu investieren? Welchen Grad der Absicherung kann ich erzielen?

  • Überprüfen der Leistungsfähigkeit des Anbieters
    10 Minuten pro Anbieter
    Schriftliche Aussage über real existierende Projekte
  • Effektivitätsvergleich verschiedener Anbieter
    60 Minuten pro Anbieter
    Telefoninterview mit einem Projektteilnehmer der Referenz, diese ist vom Anbieter mehr oder weniger ausgewählt

Eine Vergleichbarkeit also am liebsten so etwas wie eine Vorwegnahme eines Projektverlaufs, ist auf diesem Weg nicht herzustellen. Mit etwas Taktik kann durchaus ein Vorbild gefunden werden. Die entscheidenden Fragen in so einem Projekt werden ähnlich sein, in etwa: Wo war Beistelleistung nötig? Wo musste ich als Kunde Dinge gerade-ziehen? Was konnte sinnvoll als Paket definiert und zum Festpreis vergeben werden? Wie hat sich der Serviceanbieter bei Veränderungswünschen verhalten? Und viele ähnliche Fragen.

Diese Fragen gehören zu der Geschichte einer Referenz. Nur aus ihrem Umfeld können diese tiefschürfend beantwortet werden. Vielleicht hatte die Referenz viel mehr Erfahrung als ich oder aufgrund einer neuen IT Leitung ein freies Spielfeld. All das ist nicht in einem Telefonat zu erfahren.

Mein Rat ist: Sollen Referenzen einer soliden Absicherung dienen, dann ist die beste Lösung eine Kooperation mit einem Referenzkunden, der gut zu einem passt. Mindestens aber einige gemeinsame Workshops. Hört sich schwieriger an, als es ist. Die Ausgangssituation ist zwar eine Bitte um Auskunft, kann jedoch schnell in eine Gegenseitigkeit gewandelt werden. Interne IT Organisationen haben ähnliche Herausforderungen: Wie stellst Du dein internes Projektmanagement auf? Musst Du OLAs einhalten und wie detailliert sind diese? Hast Du schon eine Lizenzmanagment im Einsatz?

Und schon wird aus einer Referenz ein Kollege, den man auch langfristig zu einer neuen Entwicklung als Sparringspartner ansprechen kann. Damit die Kooperation nicht mit gegenseitigem Misstrauen starten muss, rate ich dazu Referenzen nicht unbedingt aus der gleichen Branche anzufordern.

Egal ob die Frage nach Referenz auf eine Kooperation abzielt oder als einfache Bestätigung dient, bitte vorher den erwarteten Nutzen und die erforderliche Investition in Zeit festlegen. Die schönste Referenzliste nutzt nichts, wenn man aus Zeitgründen nur kurz drüber schauen kann.

SSD für einen Esprimo Q9000

Bei uns dient ein Q9000 als XBMC-Medienzuspieler für den Fernseher. Mit dem Erscheinen von Kubuntu 14.04 stelle ich alle Geräte auf einen längeren wartungsfreien Betrieb um. Außerdem lag noch eine alte 64 GB SSD rum. Also Schraubenzieher raus und die eingebaute Festplatte gegen ein schnelleres, geräuschloses Pendant getauscht. Weiterlesen

Windows 8 Black Screen nach Virtualbox Update

Nach dem Update von VirtualBox 4.2.x auf 4.3.x, wie es mit Kubuntu 14.04 kommt, booteten alle meine virtuellen Maschinen nur mein Windows 8 Gast,  den ich zum TomTom-Update nutze, zeigte einen schwarzen Bildschirm mit totem Cursorbalken. Ich vermute mal der Grafikkartentreiber ist die Ursache. Weiterlesen

Kubuntu 14.04 ist da!

Wenn ihr Trusty Tahr unbedingt sofort saugen wollt, nutzt bitte die Torrent-Links, d. h. die Images werden im Peer-to-Peer-Netzwerk verteilt.

Die erhaltenen .ISO-Images sollten per md5-Prüfsumme auf Korrektheit überprüft werden:

Die obigen Images (ca. 1.000 MB) können via UNetbootin auf einen USB-Strick transferiert werden oder auf eine DVD gebrannt werden. Ein bestehendes System lässt sich z. B. mit der Softwareverwaltung auf 14.04 bringen.

Viel Spaß!

Priorität ohne CMDB

Priorität errechnet sich aus Impact und Urgency, so steht es in jedem ITIL®-Buch und ist auch absolut prima. Dumm ist, wenn die IT losgelöst vom Geschäft arbeitet und den geschäftlichen Wert eines Ausfalls gar nicht einschätzen kann.

Ist der Ausfall eines Logistikstandortes mit 300 Mitarbeitern schneller zu lösen, als der gleichzeitige Ausfall eines Produktionsstandortes mit ähnlich vielen Beschäftigten?

Genauso können viele interne IT Organisationen die Auswirkung nicht sicher bestimmen. Wie viele Anwendungen nutzen die ausgefallene Datenbank und was bedeutet das in Summe für die Anwender? Ohne eine CMDB (bzw. CMS) ist da nichts zu holen.

Die Behelfslösung ist meist eine – wie auch immer geartete – inhaltliche Umschreibung der einzelnen Prioritätstufen. Unten-stehende Tabelle ist dazu gedacht diesen Wahnsinn etwas plakativer darzustellen. In der Praxis finden sich manchmal wahre Zeilen-Monster, die wie wir sehen werden Niemandem helfen, auch nicht bei Erhöhung von Detailtiefe .

Prio 1 Sehr kritische Störung von erheblichem Umfang, ohne Umgehungslösung, Produktionsgefährdend
Prio 2 Kritische Störung von großem Umfang, es existiert eine Umgehungslösung mit deutlichem Mehraufwand
Prio 3 Deutliche Störung, mindestens ein Mitarbeiter kann nicht mehr arbeiten.
Prio 4 Geringere Störung, Lösung kann einen Tag warten.
Prio 5 Unbegründete Störung oder Benutzer versucht etwas zu nutzen, was er gar nicht braucht.

Ihr kennt diese Systematik sicher aus der Praxis in unterschiedlichsten Ausbaustufen. Diese gibt es von knackig-kurzer Tabelle bis hin zu zwei DIN-A4-Seiten Prosa.

Wenn ich solch ein System sehe drängt sich sofort die Frage auf: Wie genau kann der Service Desk Agent die Priorität einschätzen? Immerhin ist am anderen Ende der Leitung ein aufgebrachter Endanwender, der nahezu nie sagen wird “hat einen Tag Zeit” sondern eher auch mal bei Kleinkram “Ahrg, hier kann keiner mehr arbeiten, ihr müsst sofort was tun!”. Vom dem betroffenen IT Service haben Endanwender keine Ahnung: “Ich muss hier Rechnungen archivieren, gestern ging es noch! Macht was!”.

Die Antwort eines Service Desk Teamleiters auf meine Frage lautet fast nie: “Dann klickt der Agent in das Impact-Analyse-Modul der CMDB…”, wie man das immer so schön auf ITSM Messen sehen kann. Sondern meist: “Meine Leute haben eine Menge Erfahrung”. Das Vertrauen des Teamleiters in die Kompetenz seiner Leute in allen Ehren, eine Analyse des Ticket-Abzuges eines Monats ergibt fast immer, das dem nicht so ist. Gleiche Vorfälle werden unterschiedlich eingeschätzt, die statistische Analyse sagt dann eher etwas über die IT Organisation aus, also über Wiederholbarkeit.

Die anzustrebende Normalverteilung “Ticketanzahl nach Priorität” findet sich bei diesen “Priorität via Umschreibung”-Systemen so gut wie nie.
normalverteilung

Eine nach Links verschobene Verteilung, die sich auf Prio 1 und 2 konzentriert ist die häufigste Krankheit.

links

Ein nach rechts verschobener Berg kommt fast nie vor. Einige IT Organisationen halten sich für besonders clever und haben die Eigenheit “bei uns gibt es keine Major Incidents”. Ja toller Trick, dann nennen wir es eben “Prio 2″.

rechts

Auch ein Gebirge mit ausgeprägtem Tal kommt vor. Hier bedeutet der Prio 2 Gipfel zum Beispiel ERP, MES und Co. der Prio 4 Gipfel sind dann die Endanwender.

mitte

Noch einmal zurück auf Anfang: Wozu wird eine Priorisierungs-Systematik eigentlich benötigt? Im Kern stehen sicherlich nicht statistische Analysen wie gut die IT ist, im Kern geht es darum die Support-Teams in heißen Phasen zu lenken. Wenn alle Mitarbeiter engagiert Störungen beseitigen, welche Störungen sind dann zuerst dran?

Mit obigem System kann der Service Desk dies nicht sinnvoll entscheiden. Je nach Störung kann dies eventuelle ein 2nd-Line-Team, die nämlich feststellen, dass eine Zentralkomponente ausgefallen, demnach 300 Anwender betroffen sein müssten. Der Service Desk hat keine Chance, anhand von munter definierten Schachtelsätzen dies abzuschätzen.

Professionelles Schätzen

Die Aufgabenstellung ist: Wie schätzt der Service Desk professionell eine Priorität, wenn es keine technische Unterstützung sondern nur den Endanwender am Telefon gibt?

Impact: Gut unterscheiden lässt sich, ob ein oder mehrere Anwender betroffen sind.
“Wie viele Anwender sind betroffen?”
“Alle hier!”
“Auch ihr Schreibtischnachbar?”
“Ich sagte doch alle!”
“Darf ich ihren Schreibtischnachbar mit in das Ticket eintragen? Wie heißt er denn?”
Anwender rufend “Sach mal Karl, funktioniert Dein ERP auch nicht?”

Ja nach Firmenstruktur kann solch ein System auch auf Gebäude bzw. Ebenen ausgedehnt werden. Damit es Sinn ergibt, muss eine Übersicht der Anwender pro Gebäude vorliegen und eine Überprüfungsmöglichkeit wie ein Anruf durch einem Key User geben.

Organisatorische Strukturen wie Abteilung, Hauptabteilung können auch herangezogen werden, wenn deren Daten geordnet als Übersicht mit Ansprechpartner vorliegen. Firmen ohne CMDB, haben meist auch hier Lücken.

Urgency: Zur Einschätzung der Dringlichkeit kann sozusagen eine Minimalversion einer CMDB genutzt werden. Die wichtigsten 10 Services bekommen eine Dringlichkeitsstufe zugeordnet. Häufen sich Tickets zu einem System, prüft Service Desk mit dem 2nd-Line-Team, ob der Service betroffen ist. Dies geht zum Beispiel wunderbar per Chat.

Diese Mini-CMDB kann prima als Tabelle auf einem Share abgelegt werden. In großen Service Desk Teams ergibt es auch Sinn diese Tabelle als Strichliste zu nutzen. Übrigens, wer nun auf die Idee kommt 20 oder 50 Services in die Tabelle einzutragen, der hat diesen Artikel nicht verstanden, darf mich gerne um Rat fragen, oder zu eśeinem alten System zurückgehen.

Das ist nicht Professionell!

Wie gesagt, es gibt Zeitgenossen, deren Antwort auf Herausforderungen wie diese Stereotyp lautet, muss man alles bis auf die letzte Schraube definieren, CMS, SMKS, etc. muss da sein.

Meine Antwort ist: Mache aus den verfügbaren Mitteln das Beste und richtet sich an Teamleiter die konkret und ohne Budget Verbesserungen schaffen müssen. Veraltete oder ohne Sachverstand einführte ITSM Tools, liefern oft keine sinnvolle Unterstützung vom simplen festhalten der Vorfälle mal abgesehen.

Was mir auch Wichtig ist: Eine kompakte kleine von Services ausgehende CMDB (CMS) ist kein Hexenwerk, leicht zu pflegen und liefert auch auf dem Niveau von Services eine tolle Unterstützung für den Service Desk. Leider konzentrieren sich manche IT Organisationen auf andere Schlachtfelder. Eine ordentliches Top-Down eingerichtetes CMS ist wie eine sauber Strukturierte Produktionshalle. Die hat nicht jeder.

P.S.: Warum funktionieren Service Desks mit solchen Prosa-Prioritäten eigentlich? Die Antwort lautet: Sie tun es nicht. So lange genug Kapazität vorhanden ist, können die Vorfälle einigermaßen Zeitgerecht verarbeitet werden. Erst wenn die Hütte brennt, bekommt das Priorisieren seinen eigentlichen Sinn. Dann unterscheiden sich Profis, von guten Teams, von Hühnerhaufen.