Am Anfang der ALM-Integration steht die Anforderungsanalyse, schrieben wir im letzten Beitrag. Und am Anfang der Anforderungsanalyse steht die Istaufnahme der Lösungen, Abläufe, Stellen und Personen, die sich heute schon mit ALM beschäftigen, meistens natürlich unter einem anderen Titel.

Es ist gefährlich, sich diesen Schritt ersparen zu wollen, den viele für altmodisch und überflüssig halten. Die bestehenden Anwendungen mögen zwar nicht mehr auf dem neuesten technischen Stand sein, was aber ihre Funktionen keineswegs obsolet macht.

ALM gibt’s überall seit langem

Seit es Informatikanwendungen gibt, gibt es ALM. Anwendungen müssen seit jeher geplant, entwickelt, eingeführt, betrieben, verwaltet, gepflegt, angepasst, erneuert, ersetzt und ausgemustert werden. Deshalb gibt es auch in jedem Betrieb Personen, die sich damit beschäftigen und unterschiedlichste Werkzeuge (meistens nebeneinander) anwenden: Papier und Bleistift, ein Tohuwabohu von Excel-Tabellen, mehrere IT-Anwendungen. Wo sucht man und was kommt dabei zu Tage?

Die naheliegenden Stellen sind die Informatikabteilung, die Gremien, die sich mit IT befassen, wie etwa das Informatikstrategie-Organ und die Informatikkommission, IT-Steuerungsausschuss; dann Personen wie CIO, Entwicklungsleiter, Anwendungsverantwortliche usw. Sie alle erfüllen Management-Aufgaben im Lebenszyklus der Anwendungen: planen, anordnen, kontrollieren, steuern.

Sie nutzen dazu Anwendungen, die Metadaten über die Anwendungen speichern:

• Software-Verwaltungssysteme. Die Praxis zeigt, dass jede Programmierergruppe mit einem besnderen Know-how (etwa die Java-, die C#-, die Mainframe-, die Weiss-ich-was-Gruppe) meistens je ihre eigene Softwareverwaltung haben.
• Planungs- und Verwaltungssysteme für das Architektur- und Projektmanagement (Enterprise Architecture Management und Project Portfolio Management)
• CMDB — Change and Configuation Management Database
• usw.

Die Namensvielfalt ist endlos, die Namen verstecken oft mehr als sie verraten, oder locken einem auf eine falsche Fährte. Also aufgepasst: Nicht immer steckt drin, was draufsteht; vermeintlich falsche Fährten können sich als Wege zu Fundgruben erweisen.

Die Prozesse verbinden Gremien, Personen, Aufgaben, Sachen und Anwendungen zur dynamischen Produktionsvorrichtung, die Ergebnisse hervorbringt. Die Prozesse zu ermitteln ist meistens das Schwierigste, weil sie nicht greifbar sind wie eine Anwendung oder ein Gremium, und auch eine Prozessdokumentation ist nicht der Prozess selbst. Dieser manifestiert sich nur in den Ergebnissen und Dokumentationen, wie etwa Protokollen und Plänen.

Warum schneiden wir das Thema Istaufnahme überhaupt an? Was soll da Besonderes dran sein? Die Gründe: In jeder Firma ist viel mehr an ALM vorhanden, als gemeinhin angenommen wird. Wegen dieser falschen Annahme, ist die Gefahr gross, dass man sagt: «Weil wir ja nichts haben, können wir einfach Paket X einführen.» — Das ist zu schnell geschossen. Schnellschüsse gehen leicht daneben.

Weitere Beiträge in dieser Reihe

(1) Fehler darf man machen — aber nicht zwei Mal dieselben
(2) Anwender- und prozessorientiert zum Erfolg
(3) Manuelle Arbeit — und wie man sie besser los wird
(4) Am Anfang steht die Anforderungsanalyse
(5) ITIL und ALM
(7) Verzicht, Vereinfachung und Automatisierung
(8) Ein Projekt
(9) Prozessautomation
(10) Zukunftsaufgabe Metadaten-Integration

Tags: ALM-Integration, Best Practices

Trackback URI | Kommentare als RSS