Eine Frage der Schuld

Ich durfte eine Zeitlang in meinem Berufsleben als Eskalations-Projektleiter in Projekte gehen, die eine erhebliche Schieflage hatten. Meist wurde ich dort extrem kurzfristig eingeflogen und musste mir in wenigen Tagen ein Bild vom Projekt und der aktuellen Lage verschaffen. Dabei hat es mich oft in meiner Arbeit gestört, wenn meine Zeit in diesen ersten Meetings mit gegenseitigen Schuldzuweisungen verschwendet wurde. Weitergebracht hat mich das Thema „Schuld“ nämlich nie. Es ist für die Projekte eher verlustbringend – und ja ich rede über Euro.

Der herausragendste Fall war ein Projekt in dem drei Provider für einen Kunden eine längst überfällige Umstellung umsetzen mussten. Wir waren einer der Provider. Es waren einige Milestones gerissen worden, wir mussten schon Vertragsstrafen zahlen und der Go-Live-Termin schien aussichtslos, da fast nichts fertig war.

Das Projekt wurde von einem externen Projektmanager ausgesteuert, der mir lang und breit erklärte, dass die drei Provider nicht zusammen arbeiten würden und erzählte mir viele Anekdoten. Nach der dritten oder vierten Anekdote fragte ich ihn, was er denn zur Lösung dieser Situation versucht hat, darauf bekam ich keine überzeugende Antwort. Das war schon mal kein gutes Zeichen.

Mit den Vertretern des eigenen Teams und der anderen beiden Provider kam es zu massiven Schuldzuweisungen. Sowohl innerhalb, als auch Außerhalb der Teams. Es wurde lang und breit immer wieder in diese Diskussionen verfallen. Es gelang mir kaum, mit den Beteiligten die wichtigsten nächsten Schritte zu besprechen oder gar einen Schlachtplan für die nächsten Wochen aufzustellen. Immer wieder ging es um Schuld. Irgendwann kam mir der Gedanke, den ich auch laut ausgesprochen habe „Okay, ich stelle mich als Sündenbock zur Verfügung, ich nehme alle Schuld auf mich!“.

Die nächsten 4-5 Schuldzuweisungen – die natürlich aufkamen – nahm ich an und sagte: „Stopp, ich habe die Schuld daran, das hatten wir doch vereinbart“ und diese Diskussionen endeten. Das tat ich auch bei Mitarbeitern der anderen Provider, die in anderen Projekten unsere Mitbewerber waren. Das sorgte für ein wenig mehr Konzentration in der großen Runde. So das wir genug Material hatten um die wichtigsten Themen in einer verkleinerten Runde am nächsten Tag zu besprechen.

In dem Projekt selbst war ein entscheidendes Hemmnis anscheinend nicht angegangen worden, es fehlten allenthalben die Zuarbeit des Kunden. Deshalb stockte es sogar bei den Teams, die durchaus eigenständig hätten arbeiten können. Auch kam es mir komisch vor, dass Vertragsstrafen gezahlt werden, obwohl auf Kundenseite fast keine Ansprechpartner benannt waren.

Der Projektleiter sagte mir, dass er dafür nicht zuständig sei, er erklärte mir mit vielen Worten warum dies nicht in seinem Auftrag abgedeckt ist. Mir war das an der Stelle schon lange zu bunt, also traf ich mich mit den anderen beiden Providern und ging zum Kunden. Mithilfe des Vertriebs hatten wir hochrangige Ansprechpartner, die sich entsetzt zeigten und sowohl für eine (etwas) bessere Unterstützung sorgten, als auch die Pönaleforderungen sofort stoppten. Das war tatsächlich etwas Glück, Überraschungsmoment und vor allem dem gut vernetzten Vertrieb zu verdanken.

Am nächsten Tag kam der Projektleiter mit einem kleinen Stapel Papier in das Büro – seinem Vertrag – und wollte mir schriftlich Darlegen, dass er nicht zuständig sei. Ihm schwante, glaube ich schon nichts Gutes. Ich fragte ihn, ob er mir jetzt wirklich erklären will, dass er für eine monatliche Einsparung eines unteren 5-stelligen Betrages für seiner Auftraggeber nicht zuständig sei.

Das Projekt haben wir drei Provider dann gemeinsam noch einigermaßen retten können. Es hat sich irgendwie schnell ein guter  Kampfgeist im Projekt entwickelt. Den Projektleiter haben wir einstimmig aus seinen Verträgen entlassen und – jeder in seiner Organisation – einige Teammitglieder so gut es ging ausgetauscht oder mit Freelancern ergänzt. Wir haben dann gegenseitig Aufgaben übernommen, Testsysteme bereitgestellt und es fast pünktlich geschafft. Die notwendigen Abnahmen konnten gerade noch rechtzeitig meist auf Beta-Ständen eingeholt werden, Version 1.0 konnte nur allerwichtigste Funktionen und die finale Version kam 6 Wochen zu spät.

Ein anfangs sehr erboster Fachbereichsleiter des Kunden hat zum Schluss sogar geholfen, das die 6 Wochen Verzug vermutlich nur wenigen Endkunden aufgefallen sind. Es waren alle stolz auf die Arbeit und Mitbewerber fanden es schade nun zu Projektende auseinander gehen zu müssen.

Aber ich wollte ja über Schuld schreiben. Die Schuldzuschreibungen haben uns gar nichts geholfen. Wobei wenn ich so recht bedenke, die am lautesten über Schuld gestritten haben, waren die Personen, die wir austauschen mussten. Nicht zu schuldig sein und andere zu beschuldigen, bedeutet nämlich ganz oft, keine Verantwortung übernehmen zu wollen.

Ich habe diesen Satz „Okay, ich nehme alle Schuld auf mich!“ noch oft eingesetzt. Denn ich habe in keinem dieser angebrannten Projekte jemals erlebt, dass es wirklich diesen einen Schuldigen gab. Das dichteste was ich an „Schuld“ erlebt habe war Inkompetenz. Wenn Firmen Personen in Projekte schicken, die nicht die notwendige fachliche Kompetenz haben und dann Mist bauen, dann reden wir auch hier nicht über Schuld, sondern einen Mangel an Professionalität.

Schuldzuweisungen führen fast immer zu einer Verantwortungslosigkeit, die oft mit finanziellem Schaden einhergeht. Es gibt tatsächlich einen Schlag von Mitarbeitern, denen nicht wichtig ist, dass ihre Firma Geld verliert. Sie sind ja nicht Schuld an dem Problem, sondern ein anderer.

Projekte und Organisationen, die als Teil ihrer Kultur Schuldzuweisungen pflegen, sind in den meisten Reifegrad-Modellen tatsächlich Reifegrad Null. Das hat auch einen guten Grund, nicht nur das es nervt dort zu arbeiten, sondern Schuldzuweisungen wirken wie Betäubungsmittel in der eigenen Entwicklung. Ein Streben nach Effizienz oder gar Innovation ist in solchen Organisationen nicht in der Mehrheit, weil Exploration immer Gefahr, Fehler und Stolpern mit sich bringt.

Man findet in Projekten diese Art von Kultur tatsächlich öfter als man denkt. Meist in einer Art sinnfreiem Sündenbock-Prinzip, die Schuldigen haben eigentlich keine Konsequenzen zu erwarten, beim nächsten Projekt sitzen sie auf der anderen Seite und dann bestimmen sie den nächsten Sündenbock.

Wenn Menschen einen Sündenbock brauchen, so ist das zwar verständlich aber schlichtweg ein Mangel an Kultur.

Was habe ich aus dieser Zeit mitgenommen:

  • Schuldzuweisungen sind weder produktiv, noch lösen diese Probleme
  • Eine Sündenbock-Kultur fördert verantwortungsloses Verhalten, das kostet immer Geld. Auch fehlende Effizienz ist bares Geld.
  • Ungerechte Schuldzuweisungen sind gigantische Demotivatoren für Projektmitarbeiter
  • Eine Vorgeschichte des Ignorierens oder killen der Messenger ist eine große Hypothek für Projekte. Probleme verschwinden nie, aber die Überbringer der schlechten Nachrichten werden still. Probleme in der Endphase kosten eine Menge Geld. Hier muss versucht werden Vertrauen zurückzugewinnen.
  • In komplexen Projekten oder in empirisch fortschreitenden Projekten sind Fehler unvermeidlich und müssen als Antrieb genutzt werden. Schuld hat da nichts zu suchen.
  • Wenn es gelingt den Blick aufs Ganze zu lenken, wird auch aus manchem „nicht zuständigen“ ein ganz passabler Projektmitarbeiter.
  • Gewonnenes Vertrauen kann sogar einen von seinem Management als Sündenbock geschlagenen und getretenen Mitarbeiter motivieren. Ist mir einmal gelungen, dieser gute Mensch war 15 Monate vor Rente, das hat mich sehr gefreut.

Manno, ist IT kompliziert! Ist es wirklich die IT?

Ich „mache ja IT“ oder zumindest so ähnliche Gesprächsanfänge kenne ich nun seit Jahren und dann erzählen mir Bekannte und Freunde von ihren Abenteuern mit IT. Wie kompliziert das alles ist und das IT doch eigentlich das Leben erleichtern soll, uvm. Eine Geschichte geht ungefähr so, Namen und Rollen wurden absichtsvoll weggelassen.

Benutzer: „Ich wechsele zum 1.12. in die Abteilung Einkauf und soll einen User im System EiKaSys42 beantragen“
IT: „Das machen sie im UserPortal, ich kopiere ihnen den Link in den Chat“
Benutzer: „Dort habe ich schon gesucht“
IT: „Ah, Okay, ich schaue mal… Den finden sie unter Sonstiges→Extern→Einkauf→Verfahren→Rolle“
Benutzer: „OK, Danke“
…10 Minuten später
Benutzer: „Ich kann ohne den Eintrag in den Feldern AssKeyU, EiRoMan und HerNoMo das Formular nicht abschicken. Auch passt meine Personalnummer nicht in das Feld.“
IT: „Dort tragen sie ja auch ihre internationale Personalnummer ein, die ist 6-stellig. AssKeyU steht für den ihnen zugeordneten Key User und EiRoMan für den Bereich. Was HerNoMo ist weiß ich auch nicht, ich bin nur IT“
Benutzer: „Ich kenne aber weder einen Key User noch einen Bereich, auch habe ich noch nie etwas von einer internationalen Personalnummer gehört“
IT: „Da kann ich ihnen nicht helfen, ich bin nur für IT zuständig“

Kennt ihr bestimmt auch, gerade als neuer Mitarbeiter oder bei neuen Verfahren ein sehr beliebter Stafettenlauf. Manchmal dauert es Tage die Informationen zusammenzutragen oder Benutzer raten Einträge zusammen, was im Nachhinein für eine Menge Ärger sorgt.

Ein anderes beliebtes Szenario ist, eine Fachabteilung gibt einen automatisierten Prozess vor, den Benutzer einmal im Jahr oder seltener befüllen müssen. Diese Maschinerie fragt dann ähnliche kryptische Eingaben ab, Zwischenstände lassen sich nicht abspeichern und Hilfefelder enthalten sehr erhellende Einträge wie etwa „Im Feld HerNoMo müssen sie die HerNoMo ihres Bereichs ohne führende Nullen eingeben“.

Wer ist da eigentlich das Problem? Aus Sicht des Benutzers ist das Problem ganz oft „die IT“ sonst würden die mir diese Stories nicht erzählen. Das ist so aber nicht ganz richtig. Ja, es eine ideale IT würde hier beratend tätig werden. Es wäre sehr schön, wenn in der IT ein Projektteam nicht jeden Unsinn in Portale und Workflows gießen würde, ohne betroffene Endanwender und umfängliche Anwendungsbeispiele zu bemühen. Oft wird so etwas in aller Hast als letzte Aktion, bevor ein neue Fachanwendung eingeführt wird, ohne viel Fehlerlesen eingebaut.

Es ist aber auch die Verantwortung der Fachbereiche, Eingaben auf ein Minimum reduzieren. Einen Laufzettel und einen Ansprechpartner für neue Mitarbeiter bereitzustellen. Auch ist es meiner Ansicht – zumindest aus der Sicht des Gesamtunternehmens – gar nicht sinnvoll, fachfremde Mitarbeiter in Fachprozesse zu schmeißen. Die Arbeitszeit die dort durch Unkenntnis der Prozesse, der (nicht intuitiven) Bedienung von Fachanwendungen und falsche, geratene Einträge verschwendet wird, könnte man gut in ein Backoffice stecken, dass den Anwender passende Fragen stellt und ihn höflichst bedient.

Also, tu mir einen Gefallen und baut System und Portale, die Anwenderfreundlich sind, auch wenn es um nicht IT Verfahren geht.

Gute Beleuchtung bei Videokonferenzen improvisieren

Nun durfte ich schon einige Videokonferenzen erleben, bei denen die Teilnehmer im gleißenden Gegenlicht eines Sommertages saßen oder wunderschön nur das Kinn und die Nase zu erkennen waren. Nicht schön, auch wenn ungekämmte Video-Snapshots gerade in Mode kommen…

Aktuell stehen nun mal keine professionell ausgeleuchtete Videokonferenzräume zur Verfügung, deshalb von mir einige Ideen zur Improvisation.Viel diffuses Licht ist schon mal ein Anfang. Eine helle Vollspektrum-Gesundheitslampe in Richtung weißer Wand leuchtend ist super für den Einsatz.

Weiße Vorhänge sind nicht schlecht, vor allem wenn Sonnenlicht in Richtung Webcam strahlen könnte. Buntes Licht, durch einen gefärbten Vorhang oder einer angestrahlten farbigen Wand, ist zu vermeiden. Bei manchen Webcams kann zwar der Weißabgleich eingestellt werden, aber so richtig gut wird das nicht.

Die Lichtquelle sollte hinter dem Monitor bzw. hinter der Webcam sein. Eine Arbeitsleuchte, Schreibtischlampe oder Tischleuchten hinter dem Monitor eignen sich gut. LED-Leuchtmittel sind vor allem wegen der geringen Hitzeentwicklung bei großer Lichtausbeute geeignet. Achtet bitte darauf, dass die LEDs flimmerfrei sind. Entweder neu beschaffen oder einzeln mit der Webcam bzw. Handykamera die Eignung prüfen.

Zum Schluss noch ein Hinweis zur Nasenposition der Kamera. Wenn Ihr die im Laptop eingebaute Kamera nutzen müsst, dann stellt für die Dauer der Konferenz einen Bücherstapel, Kochtopf, Karton, o.ä. unter das Laptop. Für Handys und Tablets gilt dasselbe. Baut eine stabile Unterlage je nach Sitzposition 30 bis 40 cm hoch, damit die Kamera auf Augenhöhe kommt.

Lean Management für Consultants

Bei Fujitsu wird in vielen Bereichen für die Service Erbringung eine Lean Managment Methodik Namens Sense&Respond® eingesetzt, um Verbesserungen im IT Betrieb zu erzielen. Diese hat mich vor einiger Zeit interessiert, dann fasziniert und vor ca. 2,5 Jahren kam die Idee auf dies auch in meinem Bereich das heißt für Presales Consultants einzusetzen.

Wir sind ein Team von Presales Beratern für End User Services, das heißt vielfach sind wir in unterschiedlichsten Projekten unterwegs, um Kunden zu beraten, Geschäftswert von Workplace zu beleuchten, Lösungen gemeinsam zu entwickeln, Angebote zu schreiben oder Probleme zu lösen.

Lean Managment dort anzuwenden stieß auf zwei typische Antworten. Erstens „Lean ist doch alt und out, warum machst Du nicht Agil?“ oder zweitens „Lean ist doch was für die Produktion, nicht für Beratung“.

Falls Ihr auch dieser Meinung seit kann ich Euch vielleicht mit folgenden Stichworten zum weiter lesen (und nachmachen) animieren:

  • In dem zentralen Bereich „Blueprints“ sind wir doppelt so Produktiv geworden
  • Wir haben unsere Weiterbildung zu 100% im Griff, was bei den aktuellen schnellen Entwicklungen im Workplace Bereich ein echter Vorteil ist
  • Bei Überstunden und Reisezeiten (ca. 30% der Zeit) sind wir weit besser als der Marktdurchschnitt und
  • Wir kennen tatsächlich unseren Wert als Berater für den Kunden, das heißt, was wir tun sollen und was Müll ist

Das Problem war tatsächlich sämtliche Lean Managment Methodiken und Erfahrungsberichte drehen sich um Produkte oder Services. Meist eine  laufende Fabrikation bei dem das gesamte Team eine gemeinsame Aufgabe hat. Bei uns ist nur die Arbeitsweise „Beratung“ ähnlich, die aktuellen Produkte „Schaffung von Geschäftswerten“ äußerst unterschiedlich. Es war demnach eine ganz schöne Reise Lean Methodiken bei uns Beratern anzuwenden. Von dieser Reise möchte ich Euch gerne in diesem Artikel und folgenden berichten, aber eine wichtige Warnung zuerst.

So ein Denkprinzip wie Lean entfaltet seinen Wert, in dem Teammitglieder selbst Verbesserungspotential heben und man gemeinsam darauf reagiert, daher auch der Name der Methode Sense&Respond: Nehme Dinge wahr und reagiere geeignet darauf.

Wenn Ihr Euch unsere Methoden anschaut, nehmt sie nur als Beispiel. Es kann sein das sie für Euren Bereich gar nichts taugen (aber natürlich auch sensationell sind :-). Tools und Methoden sind ein Baukasten der angepasst werden muss. Methoden dürfen keine sinnfreie extra Arbeit bedeuten, sondern sie müssen einen Wert haben.

Lean Management ist eine Reise mit Irrungen und Erkenntnissen, ich kann es nicht mit einem Schalter einschalten oder an ein Qualitätsteam delegieren. Ihr seid also gewarnt.

Mein Team ist in ganz Deutschland verteilt, das funktionierte in der Vergangenheit tatsächlich schon ziemlich gut, die räumliche Verteilung ist jedoch für die Einführung von Lean Sense&Respond nicht gerade förderlich. Wir haben für die ersten Schritte wie Definition der Mission sehr lange gebraucht auch die ersten Problem Solving Sessons zogen sich ewig. Für mehr Geschwindigkeit sorgen tatsächlich kleine Teilgruppen, die eine Maßnahme größtenteils vorbereiten und gemeinsam abstimmen. Die vorbereitenden Schritte muten zwar wie Pflichterfüllung an, schaffen aber ein gesichertes gemeinsames Verständnis.

Der für mich spürbarste Durchbruch war das Quality-Function-Deployment (QFD). Wir haben unsere internen wie externen Kunden befragt was sie sich von uns wirklich wünschen und warum. Also was wünscht ihr euch von einem Presales Team, nicht etwa was wünscht ihr euch von den Services, die wir helfen zu verkaufen. Viele der gefundenen Punkte kannten wir schon, aber das QFD hat diese in die richtige Priorität gesetzt, auch sind dort Punkte herausgekommen, die zu unserer Weiterentwicklung dienen. Zum Beispiel wünschen Kunden sich verursachungsgerechte Kosten am liebsten 1:1 abgebildet auf deren Kostenstellenstrukturen. Der Nachteil ist jedoch, das so ein Vorgehen die vorgegebenen Preisblätter verändert. Aber diese Anregung ist absolut vailde, denn nur so können wirklich effektiv Kosten vermieden werden. Aus dem QFD haben wir einen Satz Orientierungsregeln und Beratungs-Know-How geschaffen, die uns Vorgehensweisen gut abschätzen lassen und auch einige No-Gos beinhalten.

Unser wöchentliches virtuelles Teammeeting haben wir umgebaut, dies wird nun reihum moderiert und Erfolge, wie Bedenken (Concerns) strukturiert. Aus Concerns die das Team oder die Organisation angehen werden Nachfolgeaktivitäten abgeleitet. Dies kann ganz Lean üblich zum Beispiel eine Problem Solving Session sein. Das Wichtigste, was dabei entstanden ist, ist eine gegenseitige Verantwortung.

Als wir mit Sense&Respond angefangen haben bin ich in Concerns, die mir zugewiesen wurden untergegangen. Zum einen weil wir das erste Presales Team bei Fujitsu überhaupt sind, d.h. unsere Nachbarn in der Organisation kannten das nicht, zum anderen aber auch, weil wir das Mandat, was Lean einem jeden von uns gibt, nicht ganz verstanden haben beziehungsweise die Verantwortung dafür noch nicht verinnerlicht haben.

Ich muss zugeben, dass ich mir auf der ganzen Reise zu unserem eigenen Qualitätssteigerung-Baukasten immer wieder unsicher war. Viele Methoden und Vorgehensweisen, die wir erfunden haben, stellten sich in der Version 1.0 nach einigen Monaten als unbrauchbar heraus. Sie fingen an nach Bürokratie zu riechen, nervten oder waren Informationsgräber. Wir haben in den letzten 2,5 Jahren unsere Methoden nun zum dritten Mal nachgeschärft. Soll heißen manches wurde tatsächlich nur aufpoliert, weil man über die Zeit vergessen hatte, das diese Methode doch wertvoll ist und anderes wurde komplett neu gemacht oder über Bord geschmissen. Im Allgemeinen kann man sagen, wann immer wir eine neue Methodik oder Herangehensweise schaffen: Es dauert typischerweise ein Jahr bzw. ein Redesign bis das zu jedermanns Spaß läuft.

Nach den langen Monaten Erfahrung mit Sense&Respond ist das Hauptergebnis ein eng zusammenarbeitendes Team das mit großem Engagement Missstände angeht, Qualität verbessert und Effizienz fördert. Auch, wenn das in einer Organisation und Kunden immer anstrengende Phasen hat. Mein Team war ohnehin schon ein tolles Team, nun haben wir aber ein tiefes Verständnis unserer Mehrwerte und Macken. Die Mehrwerte fördern wir, helfen uns gegenseitig bei unseren Macken, und zwar viel selbstverständlicher als zuvor.

Ich habe diesen Blog-Beitrag als Beginn einer kleinen Serie gestartet, weil ich mir sicher bin das Lean Methodiken bei uns im Team eine lange Zukunft haben werden und auch andere Berater-Teams befruchten kann. Ich werde Euch hier an dieser Stelle gerne weitere Details berichten, sprecht mich aber auch gerne jederzeit an.

Werft alte Zahlen weg!

Ich war nun ein paar Mal daran beteiligt, wenn IT Organisationen reinen Tisch machen wollten und eine grundsätzliche Neuaufstellung (in Bereichen) anstrebten, sei es durch große Joint-Ventures, Akquisen oder einfach weil das Business in einer Krise steckte.

Vielfach sind mir dort IT Organisationen begegnet, die durchaus wussten das einige Dinge deutlich in Schieflage waren oder einfach alles nur historisch gewachsen sind und jedwede Struktur zu hinterfragen war.

Was mich allerdings wundert ist, dass vielfach die neue Architektur auf bestehende Reports bzw. Zahlen aufgebaut werden sollte. Damit meine ich, das sehr früh noch bei der grundsätzlichen Planung des Veränderungsprozesses vorhandene Reports als Zahlengrundlage genutzt werden sollten.

Es kommen in solchen Veränderungsprozessen nur ganz wenige Beteiligte auf den Gedanken, dass das die Nutzung bestehender KPIs ein Fehler mit möglicherweise immensen Auswirkungen ist. Es liegt auf der Hand, dass die historische Organisation, also die Organisation die in Schieflage gekommen ist, mit diesen Zahlen und Berichten gesteuert hat.

Nur sehr wenige Zahlen in Reports sind objektiv. Die bisherige Organisation dürfte einige KPIs geschaffen haben, an denen Bereiche gemessen wurden, die jetzt angeschlagen dastehen. Natürlich werden KPIs fast immer interpretiert, getuned oder aufgehübscht. Die Messzahlen in vielen Organisationen müssen von Jahr zu Jahr in die gewünschte Richtung wachsen, also tun sie das auch.

Selbst bei Zahlen die mit guter Absicht designed wurden, sind Messpunkte, Konsolidierungen und Abschätzungen zur Berechnung gesetzt worden, dieses Design und seine Kompromisse sollte man sich stets genau ansehen. Viele Dinge sind gar nicht eindeutig oder gar leicht zu messen, also wird ein Stück interpretiert, das ist ganz normal.

Ich wäre sehr vorsichtig und würde nur überprüft saubere Rohdaten heranziehen. Bestehende Reports können eventuell dazu nützlich sein, die alte Organisation zu verstehen und Fehlerursachen bzw. Fehlleitungen zu ergründen.

  • Die meisten Reports werden Aussagelos sein, die wurden irgendwann mal auf dem grünen Tisch entwickelt und seitdem jeden Monat abgeheftet. Specht mit den Verantwortlichen welche Reports die nutzen, was sie daran nutzen und was sie zur Lenkung eingesetzt haben.
  • Bei manchem unsauberen Report ergibt das Monat zu Monat Delta eine brauchbare Aussage. Steigen die Einnahmen bei virtuellen Servern oder fallen diese, auch wenn die Gesamtsumme in Euro nicht mit dem Financial Reporting übereinstimmt. Bitte mit Vorsicht nutzen, manchmal sind Lücken enthalten die einen auf einem Auge Blind machen.
  • Apropos Übereinstimmung: Versucht doch einmal die selbe Zahl (KPI, PI) über verschiedene Business-Unit-Reports zu ermitteln. Anzahl der virtuellen Server einer BU aus den Daten der BU-Reports, CMDB und dem IT Monatsbericht. In einem der letzten Unternehmen waren die so zu ermittelten Abweichungen oft bei bei 15%-20%!
  • Zahlen die durch Interpolation hochgerechnet werden sind in dieser Form irreführend und lohnen keines Blickes. Fehler finden sich zum Beispiel in der Form, dass Zahlen von Hauptstandorten genutzt werden, um auf das Gesamtunternehmen mit einigen großen und vielen kleinen Standorten hochzurechnen. Kleine Standorte funktionieren aber oftmals anders. Sie haben bestimmte Services nicht, diverse Services mit zusätzlichem Aufwand oder ganz simpel eine Shadow IT.

Kurz und gut: Wenn ihr an Bord kommt, um ein auf Grund gelaufenes Schiff wieder in die Fahrrinne zu bekommen. Schmeißt die alten Karten weg und nutzt eure neuen Seekarten. Die alten Karten lassen sich ganz eventuell hernehmen, um die Ursache der Havarie zu ermitteln.