Eine IT-Strategie entwerfen

Wesentlicher Leitsatz ist: Die IT-Strategie hat sich an der Unternehmensstrategie auszurichten und muss dabei die Produktstrategie tragen. Sie darf dabei die Produktstrategie, in manchen – gar nicht so seltenen – Fällen auch die Unternehmensstrategie, zu neuen Visionen anregen. Keinesfalls darf die IT-Strategie das Unternehmen und die Produkstrategie behindern.

Das klingt im luftleeren Raum schön und einfach, ist es in der Praxis aber nicht: Häufig widersprechen sich die Bedürfnisse des Produktmanagements und der IT-Führung.

Die Kunst besteht gerade darin, einen angemessenen Ausgleich zu schaffen und die IT-Strategie so zu formulieren, dass die IT der Produktentwicklung und dem Vertrieb ausreichend Spielräume verschafft, andererseits aber nicht zum bloßen Befehlsempfänger wird, der reaktiv versucht, die Produktentwicklungen des Vorjahres in die Backendsysteme zu “quetschen”, während längst schon andere Produkte verkauft werden.

Das Zusammenspiel ist hier allein erfolgversprechend und erfordert hochkommunikative Persönlichkeiten auf allen Seiten. Wünschenswert ist daher eine allgemein anerkannte Kommunikationskultur im Unternehmen, etwa basierend auf dem Harvard Principle of Negotiation.

Am Anfang ist das Ist

Nehmen wir nun an, dass die Mitarbeiter aus den betroffenen Abteilungen miteinander nutzbringend kommunizieren können. Wie soll es dann weitergehen? Man könnte, gewissermaßen im luftleeren Raum, eine Strategie ausarbeiten und dann alles tun, dass sie “irgendwie” umgesetzt wird.

Hier würde aber etwas fehlen: Die Einschätzung der aktuellen Lage, die Ermittlung einer zwar unbekannten, aber durchaus vorhandenen IT-Strategie. Ohne diese sind Sie gar nicht in der Lage, Vorgaben zu machen: Ähnlich wie bei einem Navigationssystem müssen Sie zunächst ermitteln (lassen), wo Sie sich gerade befinden.

Wie macht man das?

Die vier P: Personen, Prozesse, Philosophie, Performance

Einen guten Anhaltspunkt bieten vier Kriterien, die aus der Investmentbranche stammen (siehe z.B. hier), und möglicherweise eine Abwandlung des 4P-Prinzips von Toyota darstellen.

Diese vier Prinzipien sind deshalb so gut dafür geeignet, eine strategische Ausrichtung zu entwickeln, weil sie

a) den menschlichen Aspekt der IT berücksichtigen helfen (wenn Sie die Bücher De Marcos/Listers noch nicht kennen, wird es Zeit…);

b) ermöglichen, die Auswirkungen der eingeschlagenen IT-Strategie zu messen (und auf aktuelle Entwicklungen zu reagieren).

Ab Teil 4 werden diese Kriterien genauer betrachtet. Wir werden uns dabei fragen, wie sich das Unternehmen bezüglich dieser Prinzipien aktuell positioniert.

Was ist IT-Strategie?

Als IT-Strategie im weiten Sinn verstehe ich:

Die Antwort auf die Frage, wie durch den Einsatz von Informationstechnologie die Unternehmens- und Produktstrategie unterstützt werden soll.

Die Frage…

“Welche IT-Strategie hat das Unternehmen eigentlich?”

…sollte eigentlich jeder Manager, insbesondere einer aus der IT, unmittelbar beantworten können. Sie/er sollte in der Lage sein, in wenigen Sätzen zu erläutern,

a) was die Unternehmens- und was die Produktstrategie ist;

b) wie der Einsatz von Informationstechnologie diese unterstützen soll.

Die Strategie ist verschwunden!

Häufiger als man denkt, ist die IT-Strategie aber unbekannt. Dies ist in jedem Fall ein ernstzunehmendes Krankheitssymptom für jedes Unternehmen, das IT einsetzt und ohne sie nicht funktionieren kann.

Variante 1: Keine Unternehmensstrategie

Woran kann das liegen? Der übelste Fall wäre, dass die Unternehmensstrategie noch nicht entwickelt wurde. Hier hilft nur, darauf hinzuwirken, dass dies schnellstmöglich erfolgt und die Strategie von der Unternehmensführung an alle Mitarbeiter kommuniziert wird.

Falls man keine Einflussmöglichkeiten in diese Richtung hat, muss man sich ernsthaft mit dem Gedanken auseinandersetzen, wie lange ein Unternehmen existieren kann, ohne über eine (nachhaltige) Unternehmensstrategie zu verfügen.

Variante 2: Keine Produktstrategie

Abgeschwächt könnte zwar eine Unternehmensstrategie vorhanden sein, aber die Produktstrategie fehlen (also die Antwort auf die Frage: mit welchen Produkten möchten wir unsere Unternehmensstrategie wie umsetzen?). Ohne Produktstrategie lässt sich aber keine IT-Strategie entwickeln. Hier sollte jeder IT-Mitarbeiter sehr daran interessiert sein, wie sich die Produkte des eigenen Unternehmens im Wettbewerb plazieren und nötigenfalls mit der Suche bei Monster etc. beginnen.

Variante 3: IT-Strategie vorhanden, aber nicht kommuniziert

Schließlich kann die IT-Strategie unbekannt sein.

Dass eine IT-Strategie unbekannt ist, kann unterschiedliche Ursachen haben. Beliebt ist die Konstellation, dass (irgend)eine IT-Strategie zwar im Kopf der leitenden Manager vorhanden ist (üblicherweise pro Kopf eine unterschiedliche Strategie), diese aber nicht kommuniziert und transparent gemacht wird und deshalb in summa unbekannt bzw. vage und widersprüchlich ist.

Dem kann verhältnismäßig einfach entgegengewirkt werden: Der oberste Chef der IT hat die IT-Strategie zu formulieren und nach unten zu kommunizieren. Dass dies auch erfolgt, ist Sache der Unternehmensleitung. Diese muss die IT-Strategie als Ausprägung der Unternehmensstrategie tragen und (deshalb auch: inhaltlich nachvollziehen können.).

Variante 4: Keine IT-Strategie

Schlimmer ist, wenn die IT-Strategie unbekannt ist, weil sie nicht entwickelt wurde. In diesem Fall muss die IT-Strategie erarbeitet werden (wir sind der Ansicht, dass sich die IT-Strategie von der Unternehmens- und Produktstrategie ableitet, und gehen hier davon aus, dass beide bereits vorhanden sind.) .

Wie man beginnt, eine IT-Strategie zu entwickeln, findet sich in Teil 3.

Immer wieder stoße ich auf die Frage (oder – schlimmer – werde gestoßen) welche IT-Strategie zu konkreten Handlungen oder Handlungsanweisungen in Unternehmen führt.

Die häufig wiederkehrenden Beispiele für konzeptionslosen, von keiner Strategie getragenen Aktionismus sind Legion:

• um Kosten zu reduzieren, wird die Softwareentwicklung der zentralen Transaktions- und Bestandsanwendungen “outgesourced”;

• Vertriebsmitarbeiter eines externen Softwareunternehmens bieten die neueste Version ihres Produkts an – das Management lässt daraufhin prüfen, welche Möglichkeiten es gibt, dieses einzusetzen (anstelle eine Software dann zu evaluieren, wenn sie benötigt wird);

• das von allen Mitarbeitern eingesetzte Helpdesksystem wird fachlich einem externen Mitarbeiter überantwortet; als dieser das Unternehmen verlässt, bleibt die Position vakant und wird einem Programmierer übertragen, der das System auch noch gleich warten soll;

• die technologisch kompetentesten Mitarbeiter aus der Softwareentwicklung müssen die Systeme selbst betreuen, weil kein Maintenance-Konzept vorliegt und Software nicht so entworfen wird, dass sie von Mitarbeitern ohne Programmierkenntnisse gewartet werden kann.

• für Softwareentwickler/Techniker ist kein Karrierekonzept vorhanden – sie können lediglich ins Management wechseln, um sich finanziell zu verbessern oder ihren Verantwortungsbereich zu vergrößern – dies führt dazu, dass sie entweder das Unternehmen verlassen oder sich “arrangieren” i.S.v. innerlich kündigen;

• Jungmanager werden ohne Assessment ausgewählt; am Beginn ihrer Karriere steht ihnen niemand zur Seite, der sie einarbeiten könnte; anstelle Mitarbeiter zu führen, verwalten sie diese und wundern sich, dass der Spaß an der Arbeit abnimmt und sich die Arbeitsergebnisse verschlechtern;

• ohne Rücksprache mit dem Entwicklungsteam wird versucht, die Qualität der Softwareprodukte zu messen, die verwendete Methodik berücksichtigt weder den Kundennutzen noch die Arbeitsweise des Teams.

All dies sind gute Beispiele, die sofort die Frage aufkommen lassen, was IT-Strategie ist und welche IT-Strategie ein Unternehmen hat. Die Antwort darauf findet sich in Teil 2.

Selten dürften z.B. native XML-Unterstützung, spezielle Transaktionsfeatures etc. etc. auf einmal eingesetzt werden. Ob diese Annahme zutrifft, ließe sich eigentlich einigermaßen leicht nachvollziehen: Man müsste "nur" die zugrundeliegende Software nach Funktionspunkten aufschlüsseln und überprüfen, wie viele Funktionspunkte im Tagesbetrieb verwendet werden. Sicherlich kommen da auf die Kernmodule die meisten Zugriffe. Was aber interessant zu erfahren wäre, ist die Zahl der Funktionspunkte, für die der meiste Programmieraufwand betrieben wird im Verhältnis zu den Funktionspunkten, die am meisten benutzt werden.

Ich wage zu behaupten, dass der überwiegende Teil (~80%) der Anwender die Funktionalitäten, für die der meiste Programmieraufwand (~80%) betrieben wird, zu einem ganz geringen Teil (~20%) nutzen.

Hier möchte ich bezweifeln, dass dieses Argument wirklich greift: Bei der Überprüfung von Userrequest stellte MS meines Wissens bereits fest, dass der überwiegende Teil der Wünsche bereits implementiert, den Anwendern aber unbekannt war. Aus eigener Praxis weiß ich, dass nur ein ganz kleiner Teil der Anwender in der Lage ist, überhaupt mehr als etwa 10-15% der Funktionalitäten der Anwendungen von MS Office Standard (Word, Excel, Powerpoint) zu nutzen.

Das dürfte daran liegen, dass die meisten Anwender nie in der Benutzung der Office-Anwendungen geschult wurden. Unabhängig davon, dass mit Crossover Office eine gut einsetzbare kommerzielle Lösung vorhanden ist, um Office-Anwendungen auch auf dem Linux-Desktop einzusetzen, die durchaus erschwinglich ist, kann man dem Großteil der normalen Office-Anwender einen Umstieg ohnehin zumuten: Die Grundfunktionalitäten sind bei KWord, Abiword oder OpenOffice so selbsterklärend wie bei MS Office…

Immerhin kann ich für diese aus einem allgemeinen Gerechtigkeitssinn und einer Achtung vor jedem Menschen ein Bibelzitat heranziehen: Jeder, der Böses tut, hasst das Licht und kommt nicht zum Licht, damit seine Taten nicht aufgedeckt werden. (Joh, 3, 20).

Da fielen mir aus meiner Berufserfahrung einige ein, die unter Berücksichtung dieses Textes eindeutig Böses getan haben. Offene Kommunikation bedeutet doch: Vor Veränderungen rechtzeitig informieren, Probleme kommunizieren, die eigenen Absichten/Wünsche/Pläne/Motivationen darlegen.

Unabhängig vom Medium denke ich, dass es nicht alleine das Medium ist, das Probleme bereitet. Es ist die allgemein steigende Komplexität der beruflichen Abläufe und das zu den auf dem Markt angebotenen Produkten (jeder Branche) exponential steigende Fachwissen, was beides immer schlechter beherrscht wird.

Natürlich könnte ein Problem des Mediums “E-Mail” schon die abnehmende textuelle Kommunikationsfähigkeit sein, die hiermit aus eigener Sachkunde postuliert wird. Da wäre eine Lösung vielleicht, anstelle des Textes Sprachnachrichten zu versenden und diese dann zusätzlich über Spracherkennung zu textualisieren.

Eine andere wäre, dass alle Mitarbeiter eines Unternehmens nur noch mit einer einzigen Unternehmensschnittstelle kommunizieren, die sämtliche Informationen aufnimmt, indiziert und ggf. routet, wobei die Mitarbeite sich gleich RSS-Feeds die für sie relevanten Informationen “abonnieren” können und selber entscheiden, wann sie sich informieren.

Hach, wie wäre das spannend, derartiges umzusetzen!

Letztens habe ich von einer gegenteiligen Entscheidung erfahren ("nö, haben wir keine Zeit für"), die nur von einem zeugt: Unkenntnis, Dummheit, Vernachlässigung der Firmeninteressen, keine Interesse an stabiler Software.

Then I read a little bit about the semantic web and I wonder why the bigger Wiki systems still don't support it. I mean think of Wikipedia – there people do all the meta-tagging anyway. Why not using the advantages of the semantic web and create clickable topic maps e.g.?

Also MusicXML is interesting to me. AFAIU this standard is basically a translation of the MIDI format to XML. If so, I think it's as useful as MIDI is. But not further and it does not reflect the needs of modern composers or of non-western musicians. From my opionion, a Lillypond equivalent XML standard is necessary.

Finally I'm fully fascinated by Ruby on Rails (hey, the Pragmatic Programmer's book has been released since some weeks, it's as great as every book published within this series). As I like to work more on End User Development stuff (in my free time), one approach could be to write a rails cartridge fro andromda. If that was finished, it'd be great to develop a rule engine based wizard that queries the customer different questions which result in the UML structure that'd be then processed with the rails cartrigde.
Wish one could buy time and I were rich then…