Auf dieser Seite möchte ich Ihnen gerne einige Gedanken zu Themenfeldern des IT-nahen Managements vermitteln, die mich in meinem beruflichen Leben stark umgetrieben haben, und natürlich auch noch umtreiben. Vielleicht sind diese für den einen oder anderen wertvolle Gedankenanstöße, oder inspirieren auch zur Kontaktaufnahme mit Vertiefung im persönlichen Gespräch.

Die Menschen im Team:

Erfolgreiche IT-Projekte sind nach meiner Meinung kein Zufall, sondern als ein ganz wesentlicher Baustein das Ergebnis einer echten und wirklichen Teamarbeit. Heutige Projekte im IT-nahen Umfeld haben häufig eine Komplexität, die es für einzelne Menschen schwierig bis unmöglich macht, diese im Alleingang beherrschen oder bewältigen zu wollen. Dabei tritt zum einen der Effekt ein, dass immer mehr Spezialwissen in Teildisziplinen benötigt wird, wo es also jeweils richtige Crack's und Experten benötigt um erfolgreich zu sein. Zum anderen ist es aber auch so, dass die schiere Größe von IT-nahen Projekten einen häufig vor die Herausforderung stellt, dass viele helfende Hände benötigt werden, um große Aufgaben kleinzugliedern, und dem Erfolg zuzuführen.

Man hat also schnell große Teams, wo wie in einem Zahnradwerk alles ineinander greifen muss, um quasi ein digitales Klanggebilde zu erzeugen, bei welchem am Ende alles zusammenpasst, so dass die betriebswirtschaftlichen Zielsetzungen erreicht werden. Ich finde an solchen Gedankenbildern lässt sich auch schön verdeutlichen, wo der Begriff der digitalen Orchestrierung herkommt. Letzlich ist es wie in einem Orchester, wo der geneigte Zuhörer auch die Harmonie eines Orchester-Teams am Klangergebnis wird spüren können.

Klar lässt sich im IT-Umfeld auch viel über Gewerke und die Zulieferung von Teilgewerken steuern und einkaufen, aber ich bin fest davon überzeugt, dass ein richtig gutes Kernteam dann am erfolgreichsten ist, wenn eine Teamkultur besteht, die auf Vertrauen aufbaut. Ein Team, welches sich gemeinsamen Zielen verpflichtet fühlt, bei welchem der Teamplay im Vordergrund steht, und wo eine von Vertrauen geprägte Arbeitsatmosphäre herrscht. Sicherlich hört sich das idealistisch an, aber ich finde es ist auch real machbar.

Außerdem: Fachwissen ist lernbar, Persönlichkeit ist Trumpf.

Serviceorientierung:

Alle reden von Serviceorientierung, aber wie bekommt man das in der Praxis auch nachhaltig umgesetzt, damit es sich für externe und interne Kunden nicht wie eine Servicewüste anfühlt.

Neben dem Leben eines kontinuierlichen Servicegedankens, ist natürlich auch das diesbezügliche Erwartungsmanagement ein wichtiger Erfolgsfaktor. Man wird es dauerhaft kaum hinbekommen, beziehungsweise es wird im Normalfall kaum finanzierbar sein, immer jeden aufkommenden Wunsch quasi "von den Lippen abzulesen" und zu erfüllen. Es hilft daher natürlich allen Beteiligten ungemein, wenn zu erbringende Service-Level klar definiert sind (SLA = Service Level Agreement). Dann ist es ergänzend naturgemäß auch einfacher mal zur Vollendung der Kundenzufriedenheit das kleine und entscheidende Quentchen mehr zu tun, was dann in der subjektiven Wahrnehmung des Empfängers auch eher als solches verstanden werden wird.

Ein aus der IT kommender, aber nicht nur für IT-Themen geeigneter Ansatz mit best practices der Serviceorientierung ist ITIL - die IT Infrastructure Library (Definition von itSMF). Im Kern geht es darum, ein vollumfängliches Servicemanagement aufzubauen. Das sind nicht unbedingt nur die klassischen Servicethemen, wie bspw. ein Kundenservice. Nahezu jede Abteilung einer Unternehmung kann serviceorientiert denken und strukturiert sein. Nach dem iterativen und mehrdimensionalen ITIL Service-Lebenszyklus gehören dazu die Servicestrategie, das Servicedesign, die Serviceüberführung, der Servicebetrieb und die kontinuierliche Serviceverbesserung. Zahlreiche best practices gebeten konkrete Handlungsempfehlungen, so z.B. eine RACI-Matrix für Rollen und Verantwortlichkeiten um nur mal ein Beispiel heraus zugreifen.

Wer sich dem Thema Serviceorientierung nachhaltig stellen möchte, dem kann ich eine solche Basis von sauber strukturierten und gelebten Serviceprozessen nur empfehlen.

Agile Projekte:

Die heutige wirtschaftliche Welt verändert sich teilweise in einer sehr hohen Geschwindigkeit, und die Rahmenparameter zum Beispiel im Umfeld des eCommerce sind so volatil, dass eine eher klassische Projektvorgehensweise mit Konzeptionsphasen, Umsetzungsphasen und Live-Setzung zu starr wirkt. Man geht das Risiko ein, am Ende am Markt vorbeigearbeitet zu haben. In einem solchen Umfeld finde ich agile Ansätze und Vorgehensweisen sehr hilfreich.

Bei agilen Methoden, wie beispielsweise dem Vorgehensmodell Scrum, wird aus einem Backlog an Aufgaben immer eine Auswahl getroffen, die im jetzt anstehenden Sprint umgesetzt werden sollen. Dabei umfasst ein solcher Sprint typischerweise recht kurze Zeiträume (z.B. 3 Wochen), und am Ende eines Sprints soll ein fertiges Produkt zur Verfügung stehen, welches bereits einsatzfähig ist. Eine Methode wie Scrum kommt aus der agilen Softwareentwicklung, ist aber auch in anderen agilen Projekten einsetzbar.

Für viele Anwender, Projektmitglieder oder Stakeholder ist es häufig wichtig, in frühen Projektphasen etwas Greifbares praxisnah und konkret in die Hand zu bekommen. Das schafft Vertrauen und visualisiert Lösungsansätze frühzeitig, zum Beispiel zur Verifikation am Markt. Solche Anforderungen lassen sich mit agilen Vorgehensmodellen tendenziell gut realisieren, denn hier entstehen auf der Zeitachse schon früh die sichtbaren Teilergebnisse.

Wie bei so vielen Dingen im Leben, muss man sich natürlich auch der Risiken bewusst sein. Es besteht mitunter die Gefahr, dass die Gesamtarchitektur (betriebswirtschaftlich oder technisch gesehen) nicht abstrakt genug oder nicht ausreichend genug bedacht wird. Das kann zu "Insellösungen", Medienbrüchen oder auf der langfristigen Zeitachse zu fragilen Lösungsergebnissen führen. So sollte es natürlich vermieden werden, dass in einem Sprint die Ergebnisse aus dem vorangegangenen Sprint wieder komplett umgebaut werden müssen, und im nächsten Sprint müssten die Ergebnisse von beiden vorangegangenen Sprints wieder komplett über den Haufen geworfen werden, usw., weil sich bestimmte Strukturen als nicht nachhaltig genug erwiesen hätten. Tendenziell ist eine solche Gefahr im Kontext der Schaffung von Master-Data-Strukturen nochmal etwas größer gegeben, als wenn es "nur" um abfragende Logikelemente geht, bei denen man sehr schön iterativ und evolutionär vorgehen kann, ohne dass strukturbildende Fundamente gebildet werden müssten. Die angedeutete Gefahr ist bei Agilität aber auch nicht zwangsläufig gegeben, das Thema bedarf nur einen gewissen Aufmerksamkeit durch Profis.

Business Process Modeling:

Ein immer wieder wichtiges wie erfolgsentscheidendes Thema ist die Dokumentation von fachlich-funktionalen Anforderungen an Softwaresysteme sowie Geschäftsprozessen (BPM Business Process Modeling, Use Cases). Wie sagt man so schön, wer keine Ziele hat, der wird auch keine erreichen, und wer Ziele, Anforderungen und Prozesse nicht konkret, strukturiert und widerspruchsfrei beschreiben kann, wird häufig auch ein Umsetzungsproblem bekommen, zumindest im IT-nahen Kontext. Die gute Message daran, es ist eigentlich gar nicht so schwierig, und es gibt zahlreiche Vorgehensmodelle deren Berücksichtigung einem das diesbezügliche Leben wirklich erleichtern.

Während nicht-funktionale Anforderungen (z.B. Antwort- bzw. Verarbeitungszeiten oder grafische Design-Aspekte) noch relativ griffig und mit überschaubarem Aufwand beschreibbar sind, wird es bei den funktionalen Anforderungen schnell komplex. Der Grund dafür ist einfach, denn beispielsweise kaufmännische Zusammenhänge und Geschäftsabläufe werden mehr und mehr mit IT automatisiert. Die Anforderungen aus der Vergangenheit sind heutzutage typischerweise bereits automatisiert und verrichten jeden Tag ihren korrekten Dienst, sind vielen Mitarbeitern aber mitunter auch gar nicht mehr in allen Logikpunkten transparent (z.B. durch Mitarbeiterwechsel oder naturgemäß allein deshalb, weil der Ablauf IT-automatisierter Logiken nach und nach aus dem Bewusstsein von Mitarbeitern verdrängt wird). Dieser eigentliche Vorteil der Automation mutiert dann zur Herausforderung, wenn genau in diesem Logikumfeld Änderungen oder Erweiterungen erforderlich werden.

Klar, die Message ist zu trivial um wahr zu sein, gute Dokumentation hilft. Aber es geht nicht nur um das Ob, sondern auch um das Wie. Nur, wem es gelingt auch hohe Komplexität fachlich-gedanklich zu beherrschen, der wird dauerhaft erfolgreiche Lösungen etablieren können, davon bin ich fest überzeugt. Alles andere sind kleine "Strohfeuer", die je nach unternehmerischer Zielsetzung ja auch nicht per se zu kritisieren sind. Aber es sind dann halt nur kurzfristige (Verkaufs)erfolge, auf denen sich nichts großartig Nachhaltigeres aufbauen lässt. Diese unternehmerische Entscheidung sollte meiner Meinung nach nur bewusst getroffen, dann kann dazu korrepondierend auch die richtige Dokumentationsform ausgewählt werden.

Für den im IT-Umfeld doch eher typischen nachhaltigen Ansatz ist es nach meiner Meinung sehr hilfreich in Sprache und Form recht nah am Menschen zu bleiben, der sich von der Business-Seite her mit den Prozessen auseinandersetzen, und diese fachlich durchdenken muss. So sollte die richtige Dokumentationsform möglichst natürlichsprachend sein, idealerweise stark grafisch, sowie schnell erlernbar. Sie sollte auch strukturiert sein, so dass Fehlerminimierung und Vollständigkeit weitestgehend gewährleistet werden können.

In den letzten Jahren hat die Nutzung von UML, der Unified Modeling Language insbesondere bei Menschen mit großer IT-Affinität diesbezüglich eine hohe Beliebtheit erlangt. Aber auch Prozessdarstellungen in Swimlanes sind häufig zu finden, weil fachlich recht übersichtlich.

Vielfach gute Erfahrungen habe ich zum Beispiel mit BPMN (Business Process Modeling Notation) oder ereignisgesteuerten Prozess-Ketten gemacht, EPK's bzw. eEPK's um präzise zu sein (Definition von IDS Scheer). Eine Methode, die weltweit vermutlich den mit größten Verbreitungsgrad hat. Nicht zwingend, aber mit speziellem Software-Werkzeug geht das natürlich nochmals leichter von der Hand, z.B. mit ARIS von IDS-Scheer bzw. mittlerweile der Software AG.

Häufig ist die Nutzung von EPK's für die Beschreibung von fachlichen Prozessen absolut ausreichend. Jedoch immer dann, wenn die fachlichen Logiken viel mit unterschiedlichen Daten im Zusammenhang stehen (insbesondere beispielsweise bei Logiken mit Stammdaten, z.B. Artikelstammdaten) kommt ein weiterer Aspekt hinzu, die fachliche Sicht auf das Datenmodell bzw Informationsmodell mittels z.B. ERD's (Wiki-Definition). Die mitunter im ersten Moment für Anwender (process owner) abschreckend und zu technisch wirkende Darstellung von Tabellen, Daten und Relationen (Mehrfachbeziehungen zwischen Daten) sind fundamental für das richtige fachliche Verständnis und damit die richtigen fachlichen Logik-Entscheidungen. Um mitunter gefühlte Berührungsängste von nicht-technischen Usern mit solchen Methoden nicht noch unnötig zu steigern, ist meiner Meinung nach wichtig zwischen einem fachlichen Datenmodell (normalisiert) bzw Informationsmodell einerseits, und einem physischen Datenmodell (Performance-optimiert) für die mehr IT'ler andererseits zu differenzieren.

Auch wichtig: abhängig vom fachlichen Themengebiet erlebt man häufig, dass nur harte, sorgsame und mitunter mühsame Detailarbeit ein wirklich tragfähiges Fundament liefert. Die genannten Methoden EPK und fachliches Datenmodell ERD unterstützen dabei sehr gut. Losgelöst von den Gedanken der Dokumentationsform geht es bei Konzeptionen zu Softwareentwicklungen auch häufig um die Fragestellung, welche Prozesse man alles beschreiben sollte. In den seltensten Fällen wird man auf eine vollständige und aktuelle Prozessdokumentation treffen, die man nur an die aktuellen Belange anzupassen braucht. Theoretisch natürlich toll, aber als Idealszenario in der Praxis wohl nur bedingt anzutreffen. Diesbezüglich sehe ich daher im Delta-Ansatz einen guten Kompromiss. Delta-Ansatz heißt, dass bei einem Projekt nur die Teilprozesse beschrieben werden (ggf. neu), die mit dem konkreten Vorhaben in einem engen Kausalzusammenhang stehen. Teilziel ist dabei der dauerhafte Ansatz, so dass sich wie bei einem Puzzle nach und nach ein vollständigeres Bild der Gesamtprozesse entwickelt. Mit jedem Projekt ein Stückchen mehr. Für nähere Informationen zu dem Thema halte ich den Beitrag "Deltarequirements - Auf den Spuren der Projektrealität" von Chris Rupp, Dirk Schüpferling und Christian Pikalek (Informatik Spektrum 2009, Band 32, Heft 2, S.110-117) für eine sehr gelungene Abhandlung.

Master Data Management:

Das Stammdatenmanagement, oder MDM (Master Data Management) zieht sich als ein wichtiger roter Faden durch meine berufliche Laufbahn, sowohl mit Kundenstammdaten (CRM), mit Lieferantenstammdaten, als auch insbesondere mit Produktstammdaten. Letztgenannte sowohl im Bereich des Material Masters, wie auch im Bereich der typischerweise eher marketingorientierten PIM-Daten (Product Information Management) nebst zugehöriger Themen wie DAM oder MAM (Media Asset Management). Im Enterprise Information Management (EIM) sind Master-Data ein zentraler Anker, quasi das Rückgrat der aufsetzenden Prozesse.

Ich scheine einen Faible für Stammdaten zu haben, denn solche Themen finden mich rückblickend über die Jahre betrachtet irgendwie immer fast automatisch wieder (hier mehr) Vielleicht bin ich ein kleines stückweit auch mit der ordnungsliebende Typ, den es für den Aufbau konsistenter Stammdatenverwaltungen natürlich braucht. Die Bedeutung von MDM / PIM, auch und gerade in Zeiten von Internet und eCommerce, ist vermutlich gar nicht hoch genug einzuschätzen. Qualitätsreiche Master Data haben einen extrem hohen immateriellen Wert. Vermutlich ist dieser immaterielle Wert, und der damit verbundene gigantische mögliche Erfolgshebel auch der Grund, warum mich das Thema stark fasziniert. Ich denke auch, dass man seine Stammdaten irgendwie "gerne haben" muss - im übertragenen Sinne natürlich, aber durchaus mit Hingabe und Leidenschaft. Wer seine Stammdaten nicht wirklich als Asset betrachtet, sie nicht hegt und pflegt, der wird auch keine wirklich effizienten Prozesse darauf aufsetzen können. Stammdaten müssen mit strategischen und operativen Regelwerken umsorgt werden, auch losgelöst einer eventuellen Sichtbarkeit für die nächsten eigenen Karriereschritte, das ist der altruistische Aspekt dabei.

Die Strategien rund um MDM sind eigentlich gar nicht so schwer, Vermeidung beziehungsweise Umgang mit Redundanz zum Beispiel, oder speziell beim PIM-Thema die Medienneutralität. Aber es braucht auch persönliche Stringenz, sowie die Power und das Rückgrat gerade und saubere Wege durchzuhalten. Ein sauberes MDM ist in den falschen Händen binnen kürzester Zeit schnell und fundamental zerstört, und einer Unternehemensführung mag mitunter gar nicht immer transparent sein, wann ein Laie sehr schnell Millionenwerte an Unternehmensvermögen in Form von Stammdaten zerstören kann.

Lieber keine Daten, als falsche Daten von denen man nicht weiß welchen man trauen kann, und welchen nicht. Das Thema MDM und seine Bedeutung ist die vergangenen Jahre vielfach in den Vorstandsetagen der Unternehmen und auf Ebene Top-Level-Management gehört worden. Ich denke auch, dass das wichtig ist, um es für die strategische und operative Weiterentwicklung von dort aus in treusorgende und verantwortungsvolle Hände weiterzugeben.

Verdopplung der Prozessorleistung alle 18 (24) Monate.
(Gordon Moore, 1965)

Ein meiner Meinung nach schöner Vergleich zur Visualisierung dieses Moor'schen Gesetzes: ein VW Käfer von 1971 würde heute 500.000 km/h fahren, und nur noch 4 Cent kosten.
(Wirtschaftswoche, WiWo vom 22.05.2015, Seite 55)


Probleme kann man niemals mit der selben Denkweise lösen, durch die sie entstanden sind.
(Albert Einstein)