Musings on IT Management

Mal wieder ein eher Philosophischer Post und auch ein bisschen mehr zum Lesen.

Seit etwas mehr als zwei Jahren darf ich ja als IT Leiter bei einem gesunden Maschinenbauer respektabler Größe wirken. Die Stelle wurde mir angeboten, bzw. ich habe auch angenommen um tatsächlich IT Management ein zu führen und das Unternehmen IT- seitig auf kontinuierliches Wachstum und robusten Betrieb zu trimmen. Es war ein großer Reiz, hier einmal moderne IT Management Verfahren an zu wenden und tatsächlich all die Dinge auch voll- umfänglich selbst um zu setzen, die mir als Consultant im täglichen Leben unter gekommen sind und die vielerorts verpuffen oder nicht gehört werden wollen.

Vorweg – Natürlich ist alles super – sonst würde ich vielleicht nicht posten. Sollte ich eine Schlüssel- Aussage treffen, wäre es vermutlich diese:

Der wesentliche Erfolgsfaktor für technische Erneuerung und Innovation in einer operativen IT Umgebung, ist die Organisation und keinesfalls die Technik.

Oder mit anderen Worten, wenn Innovationsprojekte scheitern, nicht fristgerecht fertig oder zu teuer werden oder keinen Effekt bringen hat das in der Regel organisatorische Gründe. Hierfür finden sich nach meiner eigenen Beobachtung in meinem aktuellen und ehemaligen Arbeitsumfeld, im Bekanntenkreis und nicht zuletzt in der einschlägigen Fachpresse, bei nüchterner Betrachtung sicher auch für jeden anderen IT-Schaffenden im eigenen Umfeld, unzählige Beispiele. Dabei zeigen die meisten Fälle auf wie es nicht geht und nur sehr wenige, wie es tatsächlich funktioniert.

Warum ist das so?

Denkt man eine Weile darüber nach, kommen mir tatsächlich und ausschließlich die folgenden sieben Aspekte einer modernen IT- Organisation in den Sinn:

  1. Prozessorientierung:Auch wenn es von vielen belächelt und von anderen übertrieben wird, es geht nicht ohne. ITIL – Die IT Information Library ist ein mächtiges Werkzeug. Dabei ist es egal wie groß oder klein man daran geht – Wichtig sind die dort definierten Kategorien.

    Die Kunst ist es, diese Kategorien mit Augenmaß auf die jeweilige Organisations- Größe an zu passen und eine Auslegung zu finden, die sich mit den jeweiligen Mitarbeitern auch mit Leben füllen lässt. Hat man hier ein Arbeitsmodell optimiert, ergibt sich daraus zwangsweise eine Lösungs- orientierte Organisationsstruktur.

    Egal wann ich wo wieder zu meiner persönlichen Meinung gefragt werde, meine Empfehlung wäre dieses Thema zuallererst an zu gehen. Welche Standard Prozesse finden statt, welche Relevanz haben sie, welche Informationen sind notwendig und liefern Mehrwerte und wie groß ist der Aufwand diese Informationen auch zu erzeugen.

    Ein IT- Prozess- Werkzeug ist immer nur so gut, wie die Informationen die in ihm gepflegt werden. Dieser Pflegeaufwand muss in einem allgemein akzeptierten Verhältnis zu den operativen Tätigkeiten stehen. Und ausnahmslos alle Mitarbeiter müssen diese Vorgehensweise mit tragen, sonst ist absehbar, dass in diesem Umfeld Datenmüllhalden geboren werden, die alle positiven Effekte solcher Prozessarbeit eliminieren.

    Sollten einzelne hier nicht zu überzeugen sein, hat das oft schon mit dem nächsten Punkt zu tun, der…

  2. Transparenz:Sie hat im wesentlichen zwei Folgen:Erstens ermöglicht erst Transparenz eine vernünftige Planung, und das in jeder Hinsicht. Nur wenn nicht andauernd durch Überraschungen Sachzwänge entstehen die mit Aktivismus das Schlimmste zu verhindern die Mannschaft beschäftigen, kann ich vernünftig planen. Zum Beispiel den Einsatz von Mitarbeitern, den Ausbau von Infrastruktur, Evolution oder Migration von Anwendungen … alles das, was zu einem rund funktionierenden IT- Betrieb bei trägt, sollte man hier als Planungs- Horizont unbedingt auf dem Schirm behalten. Last but not least, kann ich auch erst in einem derart vohersagbaren Betrieb neue Projekte sinnvoll einplanen.

    Zweitens lässt Transparenz erst zu, zu beurteilen welche Aufgaben mit welchen Mitteln gelöst werden können. Budget und Budget-Treue, tatsächlicher Bedarf, tatsächliche Kosten sind alles verschiedene Aspekte von Transparenz. Nur wenn einem tatsächlichen Bedarf mit realistischen Budgets abgeglichen wird, vielleicht auch noch angereichert um strategische Wachstumsoptionen, kann man in einer internen Betrachtung die Relevanz an andere Menschen in der Unternehmensführung vermitteln. Neudeutsch spricht man auch gerne vom Business- Case.  Transparenz ist die Voraussetzung für eine Bedarfsgerechte Planung.

    Also Systemanalyse, Verbrauchsanalyse, Bedarfsanalyse, Trending aus Kapazitäts- Monitoring, Kosten- Monitoring und dessen Auswertung und einen eigenen realistischen Budgetplan sind hier zu entwickeln. Wenn solche Pläne nicht genehmigt werden, war es schon immer eine gute Idee diese auch gut auf zu heben.

  3. Projekt- Fähigkeit:Die  Projekt- Fähigkeit einer Organisation – also wie viele Projekttage kann das Team selbst leisten, wie viele interne Zuarbeit braucht ein Projekt, wie viel kann man extern vergeben, welchen Zeitraum kann das Team zur Steuerung externer Projektressourcen verwenden – also diese Projekt- Fähigkeit einer Organisation ist natürlich und immer nach oben begrenzt. Die Grenze mag je nach Organisation hoch oder niedrig sein, aber sie existiert und man ist gut beraten auszuloten, wo diese etwa liegt. Typischerweise lernt man es recht schnell wenn man darüber liegt.Meine subjektive Einschätzung ist, dass sie normalerweise niedriger ist als vermutet und dass der Einsatz weiterer externer Ressourcen nur zu mehr Komplexität und Kosten führt und – ist man erst einmal jenseits der Tragfähigkeit dieser organisatorischen Grenzen – mitnichten zu größerem Projektfortschritt.

    Nicht dass sich danach nicht doch auch normalerweise alle im Kreis aufstellen und gegenseitig auf die Schulter klopfen. Es ist ja auch eine Win-Win Situation. Die einen haben super Geld verdient und die anderen ein tolles Projekt gemacht – mangels Transparenz weiß halt niemand, dass es netto nichts gebracht hat.

    Ganz dringend sind hier also Lessons- Learned Betrachtungen und Projekt Reviews immer und konsequent durch zu führen. Ich persönlich tendiere auch bei der Projektvergabe vorab zu einer Arbeitspakete- Planung, die schon zwischen internen und externen Ressourcen unterscheidet und mir einen realistischen Korridor zur Bewertung eingehender Angebote aufzeigt. Man kann sich sicher Abweichungen erklären lassen und vielleicht auch als Projekt- Vergebender hinzu lernen. Auf jeden Fall hat man aber eine Gesprächsgrundlage und eventuelle Anbieter können einem nicht vorab schon ein X für ein U vor machen.

    De Facto kann ich aktuell nach zwei Jahren mit zum Teil intensiven Projekt- Phasen belastbar sagen, wie viele externe Consulting Tage mein Team effektiv pro Jahr betreuen kann ohne die täglichen Aufgaben eklatant zu vernachlässigen. Alle Projekte darüber hinaus, sind verschwendetes Geld und können eigentlich nicht zu einem erfolgreichen Abschluss geführt werden.

    Will man mehr Projekte realisieren, muss man diese auch mit internem, eigenem Personal untermauern. Verallgemeinert ist mein bescheidener Erfahrungswert, dass nicht mehr als 25% der intern geleisteten Mannstunden extern vergeben werden sollten.

  4. Bereinigung von Altlasten:Mit Sicherheit im traditionell verorteten deutschen IT- Establishment das kontroversest diskutierte Thema, sobald man als Berater nur langsam in die Richtung steuert. In jedem Umfeld, in dem ich bisher tätig war, der Überaufreger.Es findet sich immer jemand, der einem erklärt was alles gar nicht geht. Das beruht IMHO auf zwei Gründen, der “Angst vor Veränderung” und der “Angst vor Neuem”, was nicht das gleiche ist. Tatsächlich wird in den seltensten Fällen wirklich der Aufwand betrachtet eine Landschaft irgendwie komplett rund zu erneuern. Wie auch. Ohne Transparenz ist der Betrieb der Altlasten oft vermeintlich günstig. Ohne geeignete Organisationsstrukturen und Prozesse gibt es normalerweise keine realistische Chance solche technischen Veränderungen ohne eine Betriebsgefährdung zu realisieren. Betriebsgefährdung oder nur Störung des Betriebs wiederum ist die größte Angst in einer IT- Organisation überhaupt, schließlich tritt man an um einen möglichst Störungsfreien Betrieb zu gewährleisten. Das Feedback aus dem “Business” ist meistens ziemlich drastisch, wenn es hier zu nennenswerten operativen Einschränkungen kommt.

    Fakt ist aber auch, dass dies der größte Hemmschuh für die Weiterentwicklung jeder IT- Landschaft ist. Gründe gibt es viele: alt her gebrachte Konzepte, alte Software Architekturen, nicht zu wartender Code oder ähnliche Hardware, nicht mehr existente Lieferanten, verkorkste Systemstrukturen, Software- Alterung (Ja das gibt es !!), fehlende System- Isolation nur um mal ein paar Themen zu nennen, die sich im Laufe der Jahre anhäufen. All diese Themen binden administrative Zeit und Geld, beides Dinge die bei dem Aufbau und dem Betrieb moderner, teils erheblich leistungsfähigerer Infrastruktur fehlen. Darüber hinaus sind diese Gründe doch eigentlich der Grund warum man tatsächlich auf räumen sollte, weil auch wenn das System noch läuft, sind dies alles inhärente Betriebsrisiken.

    Grundsätzlich ist neben der reinen Bereinigung der Altlasten, das Erstellen einer Business Impact Analyse sehr hilfreich. Hierbei löst man sich etwas von der reinen IT Sicht und prüft welche Anwendungen wie im Geschäftsablauf verankert sind. Danach klärt man auch welchen operativen Schaden das Unternehmen bei Ausfall jedes dieser Abläufe nehmen kann und man hat eine Szenario welche Unternehmerischen Risiken hier getragen werden. Ergänzt man dieses Szenario um die zu Grunde liegenden Systeme und deren Abhängigkeiten erhält man eine Landkarte der größten Baustellen und im besten Fall sogar eine finanzielle Argumentationshilfe.

    Sicher gibt es tatsächlich hier und da die eine Anwendung ohne die tatsächlich nichts geht und die völlig resistent gegenüber Modernisierungs- Versuchen ist, oder bei der das Ende des Lebenszyklus auf Grund auslaufender Verpflichtungen absehbar ist . Das ist dann die Ausnahme im Unternehmen! Aber auch genau das muss es bleiben, eine Ausnahme. Alles was nicht Niet- und Nagel- fest ist wird bereinigt.

  5. Standardisierung:Der Heilige Gral der IT- Reorganisation. Wir standardisieren alles. Clients, Softwareausstattung, System- Layouts, Standort- Konzepte, Hard- und Software- Konfigurationen … was auch immer möglich wird standardisiert.

    Dafür gibt es tatsächlich zwei sehr wesentliche Gründe:

    Erstens bedeutet Standardisierung beim Einsatz von “irgendetwas”, größere Stückzahlen des selben. Das bedeutet die Reduktion von administrativem Arbeitsaufwand, da nicht bei jedem Laptop oder bei jeder Server- Installation das Rad neu erfunden werden muss. Gleich organisierte Systeme oder Standorte erlauben den Administratoren sich in völlig anderen, vielleicht nicht täglich administrierten Umgebungen in kürzester Zeit zurecht zu finden. Die Betriebssicherheit geht hoch, da die Anzahl möglicher Fehlerquellen meistens reduziert wird. “Meistens” daher, da die Komplexität der jeweiligen Lösungen und der Support Infrastruktur sowie deren Management- Aufwand meistens etwas zu nehmen. Alleine die Skalen- Effekte sprechen jedoch normalerweise  für sich. Typischerweise schlägt diese Effizienzsteigerung sich auch im Beschaffungsprozess wieder, da Rahmenverträge über größere Stückzahlen mit Hard- und Software Herstellern ausgehandelt werden können und dadurch weit günstigere Rabattstaffeln ziehen können.

    Zweitens, und das ist im Zeitalter von Cloud, VDI und co. vielleicht der weit wichtigere Punkt, ist Standardisierung die Grundvoraussetzung zur IT- Automatisierung. Diese wiederum ist kein Science- Fiktion, sondern eigentlich das Fundament all dessen, was heute unter der Cloud verstanden wird. Ohne automatisierte Installations- oder Konfigurations- Prozesse keine Cloud. Ohne standardisierte Komponenten und deren Monitoring und Reporting keine Service Preise im Rechenzentrum und keine Provider, usw..

    Dabei sind die Standardisierungs- Effekte schon in relativ kleinen Umfeldern von zwei- bis drei- hundert Clients erheblich spürbar. Die Entlastung der Administratoren bei stagnierendem Personalstamm ist unabdingbare Voraussetzung für Wachstum, und die Einführung neuer Anwendungen.Teilweise ist Standardisierung die Voraussetzung überhaupt vernünftige, zeitgemäße oder gar moderne Anwendungen und Infrastrukturen zu realisieren.

  6. Innovation:Innovation sollte den Nummer eins Treiber in der IT darstellen. Alleine weil diese permanent Einzug in unser aller tägliches Leben hält und selbst die abgehängtesten Zielgruppen sich hier permanent unter Anpassungsdruck befinden. Das Anwender- Erlebnis eines Arbeitnehmers, sollte nicht substanziell unter seinen privaten Erfahrungen liegen – zumindest solange man keine Übergeeks als Maßstab nimmt und da geben heute die Familien mit Whatsapp, Wunderlist und Netflixx den Ton an.

    Innovation versetzt einen aber auch in die Lage neue und moderne Anwendungen zu realisieren, Skalen und Synergie- Effekte zu heben, Sicherheit und Zuverlässigkeit zu steigern. Vielleicht der wesentliche, zumindest der kontinuierlichste Treiber sind die Steigerung von System- Kapazitäten, da zunehmend mehr Daten anfallen, diese in ihrer Struktur größer werden, der Wunsch nach längerer Verfügbarkeit im Raum steht, die Zugriffszeiten aus dem Ruder laufen und vieles mehr. Egal in welchem Datenbestand man eine Bestandsaufnahme macht, wie diese Daten und in welcher Qualität vorgehalten werden müssen, ob es Ablage oder Transaktions- Geschäft ist, wie lange sie regulatorisch vor gehalten werden müssen … man steht immer vor über linear wachsenden Szenarien und auch einschlägige Marktforscher reden hier von Explosion. Gartner und Intel prognostizieren zwischen 40% und 63% Daten Wachstum pro Jahr bei gleichbleibenden Aufgaben.

    Legt man an diese Szenarien die typischen – vielleicht etwas moderaten Anforderungen von Zuverlässigkeit und Verfügbarkeit an, sind diese Datenmengen immer häufiger nicht mehr mit konventionellen Mitteln zu bewältigen. Innovation ist daher alleine schon im Plattform und Infrastruktur Geschäft eine Notwendigkeit. Spätestens die Wiederherstellungs- Szenarien von mehreren Terrabyte großen Datenbanken und die Zeitvorgabe innerhalb eines Arbeitstages wieder funktional zu sein, definieren für viele klassische Systemlandschaften das Ende, nur um einmal ein konkretes Beispiel zu bemühen.

    Auch in anderen Bereichen wie Visualisierung, Änderung von Anwender- Verhalten, Modernisierung der Arbeitsweisen, Verschiebungen in der Endgeräte- Welt hin zu mehr Mobilität und intuitiveren Arbeitsweisen erzeugen Ähnliche Herausforderungen an die Innovationsfähigkeit einer IT- Organisation.

    Die Beispiele zur Notwendigkeit von Innovation ließen sich sicher beliebig fort setzen.

    Grundsätzlich treffen dabei die Innovations- Projekte auf Hürden in der vorhandenen Unternehmens- Organisation, scheinbar unüberwindliche Hürden. Selbst wenn diese Hürden nicht aus der IT kommen, finden sich immer Fachabteilungen die gewissen Veränderungen in Architektur und System- Landschaft skeptisch bis feindselig gegenüber stehen. Diesen Hürden kann man erfahrungsgemäß nur mit einer ausgesprochen Strukturierten Planung und Vorgehensweise begegnen.

    Aus meiner Sicht sind Innovationsprojekte darauf angewiesen dass, die vorherigen fünf Punkte ausnahmslos alle geklärt sind. Man muss wissen in welchem Mikrokosmos ein Innovations- Projekt landen muss, wo es quasi andocken kann. Man muss die Anforderungen bedarfsgerecht und strategisch dimensionieren und definieren können um die richtige und passende Lösung aus zu arbeiten. Man muss die Organisation haben, die solche neuen Technologien auch aufnehmen und betreiben kann.

    Während der Einführung müssen die Mitarbeiter die notwendigen Freiräume haben, sich mit den neuen Themen auseinander zu setzen, um die Innovation auch ordentlich umsetzen zu können und die Integration ins Unternehmen auch Qualitativ hochwertig und in Time realisieren zu können. Und last but not least muss auch das Budget passen.

    Dabei muss Innovation in der IT nicht teuer sein. Jedenfalls nicht teurer, als das was ohnehin an Budget angefasst werden muss. Investiert werden muss in jedem IT- Regelbetrieb alleine um den Support und Betrieb alternder Systeme aufrecht zu erhalten. Nach dem “End of Sale” gehen die Kosten für diese IT- Systeme typischerweise zügig nach oben. Den Status Quo zu erhalten kostet Geld. Ich wage zu behaupten, dass moderne Technologien gerade vor dem Hintergrund aktueller Trends zur Virtualisierung und Software- Definition bei gleichem Finanzaufwand immer Verbesserungen in der Performanz und Kapazität von mindestens Faktor vier auf drei Jahre Sicht bringen. Auch hier Tendenz stark steigend.

    Die zuvor geforderte Transparenz schafft Klarheit über Bedarf, Budget und in letzter Konsequenz auch über den Rahmen der Möglichkeiten, die für ein Innovationsprojekt zur Verfügung stehen.

    All das Vorausgesetzt, wie geht man an die Implementierung heran?

    Das Effektivste für die Einführung neuer komplexer Systeme ist nach wie vor der “Greenfield” Ansatz. Der Bedarf ist geklärt und das Ziel ist neben einer möglichst eleganten und Kosten- effektiven Lösung, auch die weitere Reduktion der Altlasten, und eine Bessere Gelegenheit dafür gibt es kaum. Umgekehrt kann man die modernste Lösung dadurch ruinieren, dass auf System- Befindlichkeiten und Einschränkungen Rücksicht genommen wird, die sich nicht ins aktuelle Jahrtausend transportieren lassen.

    Im Greenfield baue man das was geht vom Reißbrett weg, auf einer optimierten Basis. Der im Rahmen größt mögliche Innovations- Hub wird damit geborgen.

    Systeme, Anwendungen und deren Integration werden komplett neu aufgesetzt. Wenn die neue Umgebung funktioniert, werden Daten und Anwender aus der “alten Welt” sachte herüber migriert und die alten Systeme nach einer angemessenen Wartezeit einfach abgeschaltet und entsorgt. Der Ansatz hat immer und grundsätzlich den Vorteil, dass zumindest zu diesem Zeitpunkt die neuen Systeme nach “best practice” Gesichtspunkten aufgesetzt wurden. Dass keine Installations- Residuen von Jahrelangem Systembetrieb im System verbleiben und dass die Effekte von Software- Alterung zumindest für diesen Zeitpunkt auf Null gesetzt wurden.

    Das Motto hier ist für mich immer:

    Abreißen, neu bauen und Daten migrieren statt ewig an alten Systemen herum zu basteln.

    Wohlgemerkt, in etwas anderer Reihenfolge, aber ich finde es klingt so prägnanter.

  7. Qualifikation:All das geht natürlich nur mit einem motivierten, eingespielten Team, das sich mehr oder weniger alle vorherigen Punkte zueigen gemacht hat und auch vorbehaltlos an einem Strang zieht. Dass das Prozess- Modell lebt ist die Voraussetzung für alle folgenden Punkte. Die Transparenz muss mit getragen werden und das dazu notwendige Reporting verlässliche Informationen liefern. In den Projekten muss mit internen wie externen Kollegen aktiv zusammen gearbeitet werden. Altlasten müssen erkannt, kommuniziert und die notwendigen Zusammenhänge und Ideen für deren Bereinigung konstruktiv diskutiert werden, so wie nur das gesamte vorhandene Know How auch die Grundlage für eine erfolgreiche Standardisierung sein kann.

    Dann kann man auch nahezu beliebig innovative Lösungen besprechen und gegebenenfalls durchsetzen. Die Kollegen brauchen Vertrauen, dass sie nicht abgehängt werden und dass die “schöne neue Welt” sie auch mit ihren Fähigkeiten benötigt und fordert. Die zuvor beschriebenen Effizienzgewinne dürfen nicht als Bedrohung empfunden werden.

    Erfahrungsgemäß sorgt die steigende Komplexität der Lösungen dafür, dass durchaus genau so viel Arbeit wie vorher vorhanden ist. Es ändert sich jedoch die Qualität der Aufgaben. Nahezu allen derzeit in der IT vorhandenen Innovations- Treibern ist gemein, dass sie  zunehmend komplex und auch interdisziplinär sind. Die Trennung klassischer IT Säulen wie Windows, UNIX, Storage, Netz lässt sich in der hochgradig virtualisierten Welt nicht länger aufrecht erhalten. Das Plattform Konzept (Server, Client, Anwendung – sobald man Architektonisch von Plattform spricht) hat nahezu immer interdisziplinäre Verschränkungen zur Folge. Die Trennung zwischen diesen Disziplinen muss aufgehoben werden, will man das volle Potenzial zeitgemäßer IT- Konzepte entfalten.

    Für die Mitarbeiter bedeutet dies tatsächlich, immer eine Aufwertung ihrer Rollen. Damit einher geht nahezu immer Schulung und Weiterbildung um notwendigerweise entstandene Wissens- Lücken zu schließen. Dabei entsteht die Anforderung immer weiter rechts und links neben den ursprünglichen Kernkompetenzen verschiedenste Themen im Blick zu behalten. Gefordert sind Menschen mit sogenannten T-Profilen, die sich zwar einzelne Themen in einer respektablen Tiefe erschlossen haben und beherrschen, die aber verschiedenste andere Themen abseits ihrer Kernaufgaben zumindest oberflächlich oder ambitioniert, aber nicht spezialisiert, beherrschen, im Blick haben und weitere Zusammenhänge erfassen und bearbeiten können. Dieses Selbstverständnis widerspricht in vielen etablierten IT- Organisationen lange geprägtem Selbstverständnis der Spezialisierung auf ein Thema.

    Daher muss man alle Kollegen wirklich auch konsequent auf diesen Weg der kontinuierlichen IT Erneuerung mit nehmen. Mit Teams, die eine solche Bildungs- Kultur leben und etabliert haben, kann man im Umkehrschluss auch nahezu jedes beliebige Innovationsprojekt in Angriff nehmen, so lange es mit Computern zu tun hat, wird man das Kind schon schaukeln.

Kommt all dies zusammen, sollte einem konkurrenzfähigen IT- Betrieb nichts mehr im Wege stehen. In meinen persönlichen Benchmarks, habe ich eigentlich immer ein Szenario darstellen können, in dem Markt- gängiges Selbstverständnis von Service- Level, Kosten und Aufwänden völlig ausgehebelt werden konnte. Allgemeinplätze wie “Cloud ist billig” oder “Outsourcing steigert Qualität” haben in den von mir geprägten Umgebungen tatsächlich keinen Bestand mehr. Meine wesentliche Erkenntnis ist dabei:

Ein gut aufgestellter qualifizierter Eigenbetrieb ist immer und unter allen Umständen billiger als eine einschlägige Cloud Lösung bei egal welchem Service Provider. 

Das muss sie auch sein, da ein Serviceprovider immer erhebliche Strukturen schaffen muss um seinen vielen Mandanten gerecht zu werden. Strukturen an die man als Kunde auch erst einmal  organisatorisch angeschlossen werden muss. Darunter kocht auch der Provider nur mit Wasser und folgt diversen technischen Grundprinzipien, die sich nur weil Cloud auf der Broschüre steht nicht in Luft auf lösen. Das gilt sicher nicht unbedingt für Peak Workloads – eine dedizierte Leerstands- Betrachtung gehört auf jeden Fall in die zu schaffende Transparenz – und es gilt auch nicht für spezifische Geschäftsmodelle im Internet. Auch hier haben wieder einzelne Ausnahmen mehr als nur eine reine Existenzberechtigung.

Pauschal gilt diese Aussage jedoch explizit für jeden Mischbetrieb.

Jetzt könnte man auf die Idee kommen, nur einzelne Workloads nach außen zu vergeben und ein gemischtes Sourcing- Konzept zu betreiben. Das wiederum widerspricht normalerweise den Optimierungs- Gedanken und Anforderungen an die eigene Infrastruktur und dem dafür gewünschten Innovationsgeist. Man kann den Eigenbetrieb nur dann in aktuelle Effizienz- Szenarien führen, wenn man die modernen IT- Plattform- Gedanken auch in kleine und mittlere Unternehmen trägt. Baut man dort eine Plattform braucht auch diese eine möglichst hohe Auslastung und eine granulare, feine Skalierbarkeit. Nur das ermöglicht Leerstände effektiv zu minimieren. Anderenfalls kanibalisiert sich die IT-Organisation ihr eigenen Deckungsbeiträge zum Aufbau moderner Lösungen.

IT Eigenbetriebe, die bei einem Wechsel zum Cloud Provider viel Geld sparen, sind meinen Auswertungen nach immer diejenigen, die entweder veraltete Betriebs- Modelle oder beachtliche Leerstände in ihren Kapazitäten haben, oft eine Mischung aus beidem.

Hat man diese IT Management Themen konsequent abgearbeitet, darf man langsam auch solche Schlagwörter wie “Operational Excellence” oder “Private Cloud” im internen Selbstmarketing verwenden. Der Erfolg kann eigentlich hinsichtlich Kosteneffizienz, Performance und  Flexibilität nicht aus bleiben.

Im Wesentlichen folge ich in meinem aktuellen Wirkungskreis seit zwei Jahren diesem Fahrplan. Reflektiere ich all diese Punkte, komme ich bei den derzeit abgeschlossenen Referenz- Kalkulationen für einzelne dedizierte IT Services im Eigenbetrieb, auf interne Betriebskosten, die durchweg zwischen 12% und 40% des günstigsten Markt- Begleiters im Outsourcing liegen. Stichprobenartig wurden hierzu Dienste auch angefragt und gegenüber Angeboten Verglichen. Auf interner Seite sin alle relevanten Kosten umgelegt und es unterliegt auch ein Kostenmodell zur Service- Verrechnung, das Umlage- bezogen, fair und vollständig ist und die Kalkulation für nahezu alle intern erbrachten IT- Services erlaubt.

Diese Effizienz muss ein externer Anbieter erst einmal aufzeigen, bzw. Kosten- seitig treffen. Sollte ich in einem einzelnen Service unwirtschaftlicher im Eigenbetrieb sein, reduziert mir diese eine Service noch immer den eigenen Leerstand und nicht den des Providers.

Alles in allem spricht also sehr viel für die konsequente Modernisierung von IT Abteilungen. Jeder IT- Betrieb hat diese Potentiale und sollte sie konsequent heben. Dann wären auch die gefühlten intellektuellen Abstände auf das, was im angloamerikanischen Ausland so IT- mäßig angestellt wird, nicht mehr so gigantisch.

Wohl gemerkt, da alles liest sich so vielleicht etwas allgemein, da ich hier keine spezifischen Einzelheiten wiedergeben möchte bzw. darf. Nichts Desto trotz basiert jeder einzelne Punkt auf konkreten, selbst erlebten und gemachten Erfahrungen und ist die Summe meiner Beobachtungen in der operativen IT- Branche aus den letzten fünfzehn Jahren. Zusammen mit einigen vorherigen – und auch den in Arbeit befindlichen Postings, ergibt sich jedoch sicher für jeden Kenner der Materie ein klar ersichtlicher Trend am Beispiel IT- Infrastruktur.

Insofern … denkt mal drauf rum. Kyp. F.