IT Governance

Ich habe in den letzten Tagen das Thema IT Governance recherchiert und dabei eine ganze Menge Artikel zu dem Thema gelesen. Einer dieser Artikel, die das Thema meiner Meinung nach recht gut auf den Punkt bringen ist unter: http://www.cio.com/article/111700/IT_Governance_Definition_and_Solutions zu finden.

Einige der Kernaussagen aus dem Artikel möchte ich dennoch zusammenfassen:

  • IT Governance ist ein MUST für jedes Unternehmen – KEIN Nice-to-Have
  • IT Governance muss mindestens die folgenden Punkte adressieren
    • Strategische Abstimmung mit dem Geschäftsmodell des Unternehmens
      • Die Geschäftsarchitektur wird von der IT Architektur unterstützt
    • Sicherstellung des Mehrwertes der IT
    • Ressourcen Management
    • Risiko Management – im Projekt-Kontext und im laufenden Betrieb (z.B.: Datensicherheit)
    • Leistungsmessung (z.B.: in Form von Balances Scorcards)
  • IT Governance kann nicht von der IT alleine an die Unternehmensführung verkauft werden. Ein Team aus Vertretern unterschiedlicher Bereiche (Marketing, Service, IT, Finance, etc.) kann den Nutzen viel schlagkräftiger verkaufen.
  • Es gibt unterschidliche Modelle (ITIL, CMMI, etc.) die man (auch kombiniert) benutzen kann. Es sollten jene gewählt werden, die zur Unternehmenskultur passen.

Was kann schief gehen?

  • Die Wichtigkeit für IT Governance wird von der Unternehmensführung nicht erkannt und somit gibt es keine Unterstützung.
    • In diesem Fall kann Beratung helfen, das Bewusstsein für die Notwendigkeit zu schaffen
  • Das gewählte Governance-Modell passt nicht zur Unternehmenskultur
    • Vor der Implementierung die vorhandenen Frameworks auf Kompatibilität prüfen. Dazu ein Projekt ins Leben rufen mit einem klaren Ziel, eine Empfehlung zu erarbeiten. Zukünftige Stakeholder einbinden.
  • Es wird nicht das gemessen, was zur Steuerung dient und die Stakeholder werden unzufrieden
    • Die Balanced Scorecard so aufbauen, dass auch qualitative KPIs definiert sind (z.B.: Kunden- und Stakeholder-Zufriedeheit)

Projekt-Reviews – eigentlich ein Must

Heute wurde ich gefragt, ob ich einige Projekte einem Friendly-Audit unterziehen möchte. Dieser Bitte komme ich gerne nach und habe den damit verbundenen Auftrag mit Freude angenommen. Als erfahrener Projektleiter kann ich nicht nur meine Erfahrung in den Review einbringen, sondern auch selbst eine Menge lernen.

Ich habe selbst eine große Anzahl von Reviews meiner Projekte durchführen lassen und habe die Diskussionen mit den Reviewern, so anstrengend sie zum Teil auch waren, immer extrem wertvoll gefunden. Als Projektleiter konnte ich jedesmal etwas dazulernen. Außerdem ist ein Review für einen Projektleiter immer eine Möglichkeit Risiken, oder andere Issues im Projekt in einer strukturierten Weise aufzuzeigen. Der resultierende Review-Report ist auch für das Management eine gute Grundlage etwaige notwendige Entscheidungen abzuleiten.

Unternehmen sollten meiner Meinung nach jedes Projekt ab einer bestimmten Größe (die natürlich vom Unternehmen abhängig ist) regelmäßigen Reviews unterziehen. Erstens um deren Erfolg zu sichern und zweitens (und das ist vielleicht noch wichtiger) um durch die im Review inhärente Feedback-Schleife als Unternehmen zu lernen und so einen hohen Grad von Reife im Projektmanagement zu erzielen.

Ich freue mich darauf …

Sicherung von Kernkompetenzen in Outsourcing-Partnerschaften

Geht man als Unternehmen eine längerfristige Partnerschaft mit einem Outsourcing-Partner im Bereich der Softwareentwicklung ein, so muss man sich im Klaren sein, dass damit ein gewisser Gran an Abhängigkeit zu diesem Partner entsteht. Will man Kernkompetenzen im Unternehmen behalten, die von strategischer Wichtigkeit sind, so muss dafür auch Sorge getragen werden.

Aus meiner Sicht ist es wichtig, jedenfalls das Anforderungsmanagement im Unternehmen zu lassen, da dies direkt mit den Geschäftsprozessen des Unternehmens zusammen hängt. Unabhängig davon ist es aber natürlich auch wichtig im Rahmen der Softwareentwicklung die Arbeitsergebnisse zu sichern und diese explizit in Form von Dokumentation zu speichern und zu managen.

Schafft man das gut, so ergibt sich damit auch eine Reduktion der potentiellen Abhängigkeit, da auf Basis der vollständigen Dokumentation im Extremfall ein Wechsel des Outsourcing-Partners stattfinden kann. Das ist natürlich auch nicht über Nacht möglich und erfordert Planung. In der Summe ist dieses Vorgehen jedoch sinnvoll, da damit in jedem Fall die Möglichkeit steigt für das eigene Unternehmen eine größere Menge an Handlungsoptionen zu erzeugen.

Outsourcing von Teilen der Wertschöpfungskette in der Softwareentwicklung

Entscheidet sich ein Unternehmen Teile der Softwareentwicklung von Partnern übernehmen zu lassen, so hat das weitreichende Implikationen darauf, wie Prozesse gestaltet werden, die nun über Unternehmensgrenzen hinweg funktionieren müssen. Auf was kommt es dabei an?

Aus meiner Sicht ist Vorbereitung der Schlüssel zum Erfolg. Diese Vorbereitung muss vor dem Start der operativen Zusammenarbeit abgeschlossen sein. Diese Vorbereitung muss mindestens folgende Themen abdecken:

  • Definition der gemeinsamen Ziele
  • Rollen und Verantwortlichkeiten der beteiligten Partner – wer ist für welchen Teil der Value-Chain verantwortlich?
  • Definition der Abläufe und der beteiligten Rollen
  • Definition der benutzen Artefakte(strukturell und inhaltlich) und Softwareentwicklungsmethoden
  • Definition von Kennzahlen, die den Erfolg der Zusammenarbeit anzeigen (z.B. Messgrößen für die Durchsatzmessung, Qualitätsmaßzahlen)

Jeder dieser Punkte muss vor dem Start der Zusammenarbeit auf dieser Basis detailliert genug Vereinbart sein, um spätere Kommunikationsprobleme zu minimieren. Damit schafft man eine gute Ausgangsbasis, um an den Unternehmensgrenzen und darüber hinaus erfolgreich zusammenzuarbeiten.

Organisation

Die Aufbauorganisation ist ein Hilfsmittel zur Gliederung und Ordnung von Arbeit in Gemeinschaften und Unternehmen. Im Falle einer IT Organisation stellt sich die Frage, wie man die Funktionen gliedern soll.

  • Sollen die Organisationseinheiten (OE) nach den betreuten Systemen gegliedert werden?
  • Sollen die OE nach Rollen gegliedert werden?
  • Soll nach den unterstützten Geschäftsprozessen gegliedert werden?
  • Soll nach Technologien gegliedert werden?
  • Ist ein Mix der Gliederungsmöglichkeiten sinnvoll?

Wie auch immer die Gliederung erfolgt es ist wichtig, dass die Aufbauorganisation ein Funktionieren der Abläufe in einem Unternehmen nicht behindert.  Das kann dadurch erreicht werden, dass nach der Analyse der Aufgaben diese so gebündelt werden, dass hochgradig voneinander abhängige Aufgaben (bezogen auf die Art der Tätigkeit, die Art der unterstützten Prozesse oder die Systembeziehung) in Abteilungen zusammengefasst werden.

Softwareentwicklung Offshore

Ich habe 2005 erstmals mit Offshore-Softwareentwicklung direkt als Projektleiter Erfahrung sammeln dürfen.  Dieses Vergnügen habe ich bis Mitte 2008 gehabt. Folgende Ding habe ich dabei gelernt:

  • Die Strukturen für Kommunikation zwischen den über tausende Kilometer verteilten Entwicklungszentren muss klar und formell organisiert sein.
  • Die Nutzung von Echtzeit-Collaboration-Tools ist äußerst sinnvoll und nutzbringend.
  • Die Verwendung von standardisierten Prozessen und Defacto-Standards erleichtert die Zusammenarbeit und die Wiedererkennbarkeit der Arbeitsergebnisse.
  • Es gibt keinen Ersatz für persönliches Kennenlernen.

Diese Fakten halte ich generell für gültig, egal, ob es um die gleiche Firma geht oder um Partnerschaften in einer Auftraggeber/Auftragnehmer-Konstellation.

Erkenntnisgewinn

Nehmen wir nur mal hypothetisch an ein Unternehmen ist seit Jahren in einem Geschäftsfeld tätig, in dem sich diese eines einzelnen Dienstleisters für Softwareentwicklung bedient. Nun nehmen wir zusätzlich an, dass die Priorität immer war, schnelle Lösungen zu produzieren, um am Markt erfolgreich zu sein. Gute und ausreichende Dokumentation wurde nicht geschaffen. Mit jeder neuen Anforderung wächst und gedeiht das System. Die Bindung zum Anbieter wird größer.

Was passiert aber wenn man einen zweiten Dienstleister einsetzten will? Welches Wissen wird der benötigen? Ist dieses Wissen explizit vorhanden und dokumentiert, oder ist das hauptsächlich in Form von Fakten und Erfahrungswissen in den Köpfen des ersten Dienstleisters vorhanden?

Der Leser möge sich seine eigene Theorie bilden.

Entscheidet sich die Firma nun für einen zweiten Dienstleister ist das ein Risiko und eine Chance gleichzeitig. Chance deswegen, weil im Verlauf des Projektes zu erwarten ist, dass jenes implizit vorhandene Wissen, dass nun dem neuen Dienstleister nicht zur Verfügung steht benötigt wird. Dieses gilt es zu sichern, um dem Unternehmen, das den Auftrag erteilt die Möglichkeit zu geben, wieder explizit in den Besitz dieses Wissens zu kommen. Dieser Erkenntnisgewinn schafft Freiheit.

Alles was man tun muss, ist für Vorgaben zu sorgen, dass dieses Wissen dokumentiert wird und im Rahmen des Projektes auch wiederverwendbar abgespeichert wird.

So sieht es aus.

Zieldilemma bei Fusionen

Firmenfusionen bringen mit sich, dass Effizienz gesteigert werden kann. Vor allem dann, wenn es Systeme und Funktionen nach der Firmenfusion doppelt oder mehrfach gibt. Will man diese Effizienz nutzen macht es Sinn Systeme, die es doppelt gibt zusammenzulegen.

Um das zu bewerkstelligen darf nicht nur technisch an die Sache heran gegangen werden, sondern es muss auch die Fachlichkeit, die vom System unterstützt wird einbezogen werden – das ist ein kritischer Erfolgsfaktor. Das gemeinsame oder das neue System wird die Fachabteilungen schließlich nicht genau so unterstützen, wie es die alten Systeme getan haben.

Um Systemzusammenführungen kostengünstig und effizient zu bewerkstelligen wäre es natürlich sinnvoll das schnell und ohne äußere Einflüsse zu machen, die sich auf Grund von Marktgegebenheiten ergeben. Realistisch ist das allerdings nicht.

Das Dilemma ist, dass während die Integration der Systeme läuft, gleichzeitig den Markt weiter optimal zu bedienen. Jegliche Änderung, die durch Markteinflüsse entstehen müssen in das neue System und wahrscheinlich auch in den alten Systemen eingebaut werden, was kurzfristig zu erhöhten Kosten führt.

Ein Ansatz kann sein, die Systemintegration bzw. den Neubau von einem eigenständigen Team durchführen zu lassen, während die Betreuung der bestehenden System unverändert bleibt. Dabei muss natürlich sichergestellt sein, dass neue Anforderungen, wenn sie im Altsystem realisiert werden sollen auch ihren Weg in das neue System finden.

Eine Governance-Struktur, die sicherstellt dass Vertreter der IT und der Fachbereiche gemeinschaftlich und straff organisiert  die Systemintegration begleiten ist ein Muss um das Ziel der Systemintegration auch oder gerade trotz dynamischen Markteinflüssen schnell zu erreichen.

Defect Prevention statt Defect Detection

Je später ein Fehler im Softwareentwicklungsprozess entdeckt wird umso teurer ist seine Behebung bzw. der dadurch verursachte Schaden. Das Ziel muss daher sein, Fehler möglichst früh im Softwareentwicklungsprozess zu erkennen, um diese zu beheben.

Ein Beispiel: Bei der Analyse der Anforderungen wurde vergessen Leistungskriterien für die Software zu definieren. Beim Test stellt sich heraus, dass der Kunde mit den Antwortzeiten nicht zufrieden ist und die Abnahme verweigert. Um die Leistung zu erhöhen sind an der Datenbank und an den Abfragen Änderungen vorzunehmen. Auch der Code muss angepasst werden und erneut getestet werden. Wäre die Anforderung von vorneherein klar gewesen hätte man die Lösung gleich so gebaut, dass sie den Kriterien entspricht. Doppelter Aufwand wäre vermieden worden.

Der Trick an der Vermeidung von Fehlern ist möglichst viele Informationen früh im Software Life Cycle zu erheben und gleichzeitig bei den Arbeitsergebnissen früh Feedback zu erhalten. Am besten geht das durch Reviews der Arbeitsergebnisse durch Kollegen aber auch durch den Kunden, um Fehler zu entdecken und diese zu beheben, bevor teure Ressourcen mit der Codierung beauftragt werden.

Anforderungsanalyse

Während die Business Analyse Geschäftsfelder analysiert ist die Anforderungsanalyse die Teildisziplin, die sich um die Identifikation der funktionalen und nichtfunktionalen Anforderungen dreht.

Die Kunst in dieser Disziplin ist herauszufinden, was der Kunde benötigt. Das kann in vielen Fällen vom augenscheinlichen Wunsch, den der Kunde äußert dramatisch abweichen. Das kann sich so darstellen, dass eine Kunde mit dem sehr konkreten Wusch, auf Maske XY ein zusätzliches Feld zu erhalten an die IT herantritt. Klingt simpel. Doch löst diese Anforderung das Problem des Kunden?

Genau mit diese Frage beschäftigt sich die Anforderungsanalyse. Dabei ist immer im Fokus, was der Nutzen für den Kunden sein soll, welches Problem mit einer Anforderung gelöst werden soll und welche zukünftigen Probleme wahrscheinlich zu lösen sind.

Durch geschicktes Hinterfragen der Kundenanforderungen ist es möglich nicht nur das zu erfassen, was der Kunde glaubt zu brauchen, sondern gemeinsam mit dem Kunden eine Lösung zu erarbeiten, die nachhaltig seine Probleme löst bzw. ihn bei seiner Arbeit unterstützt.