05.05.2026 / in ICM
Die Pilotierung ist erfolgreich abgeschlossen und der Rollout der aktuellen
ICM Version 3.5 wurde gestartet.
Bis 1.6.2026 sollen alle 240+ ICM Sparkassen die neue Version bekommen.
Jetzt ist ein guter Zeitpunkt, um einmal zu betrachten, was in den letzten Monaten alles passiert ist und wie der Entwicklungsprozess einer neuen Version eigentlich abläuft.
Der Rollout von ICM 3.4 wurde im August 2025 abgeschlossen, die Entwicklung von Version 3.5 wurde aber bereits Anfang Mai 2025 gestartet.
Die Entwicklung einer neuen Version läuft somit parallel zu den letzten Tests der Vorgängerversion, der Pilotphase und dem anschließenden Rollout.
Ab Beginn des Rollout arbeitet das ganze Entwicklungsteam bereits an der nächsten Version .
Die Qualitätssicherung (QS) bleibt zunächst noch bei der Vorgängerversion, um offene Tests abzuschließen. Teilweise erfolgt auch eine Übergabe an den Support, da während der Pilotphase die QS noch für die Version zuständig ist. Mit dem Rollout übernimmt der Support, während die QS bzw. das Qualitätsmanagement bereits mit der Planung der Testfälle und Testabläufe für die nächste Version beginnt.
Unser Entwicklungsprozess ist organisatorisch bewusst einfach gehalten.
Anforderungen von Produkt-Management und Kunden werden intern analysiert und in konkrete Anforderungen für die nächste Release überführt. Wir sammeln alle Anforderungen im Wiki des Projekt-Workspaces der nächsten Release.
Für das Projektmanagement nutzen wir unser eigenes Workspace-Modul im Intranet. Damit folgen wir nicht nur dem Prinzip „eat your own dogfood“, sondern profitieren auch von der einfachen Bedienung und der für unsere Projektgrößen völlig ausreichenden Funktionalität.
In den einzelnen Wiki-Seiten werden die Funktionen der kommenden Release beschrieben. Da die Beschreibungen anfangs oft noch knapp sind, aber alle Projektmitarbeiter (Entwickler, QA usw…) mitarbeiten können, entstehen im Zuge der Umsetzung zunehmend detailliertere Ausarbeitungen. Diese dienen später als Grundlage für die Dokumentation und die Online-Hilfe.
Dieser iterative Ansatz ermöglicht es uns, während der Entwicklung schnell Entscheidungen zu treffen.
Natürlich ist nicht jedes Feature, das man zunächst für unbedingt notwendig hält, tatsächlich eine gute Idee. Ebenso können vermeintlich einfache Funktionen deutlich komplexer sein oder weitreichende Auswirkungen haben.
Alle daraus resultierenden Entscheidungen werden im Wiki dokumentiert und sind dadurch für spätere, weiterführende Projekte nachvollziehbar.
Wenn sich herausstellt, dass ein Feature im gegebenen Zeitrahmen zu aufwendig ist, kann es problemlos in eine spätere Version, inklusive aller bereits gesammelten Informationen, verschoben werden. Dazu wird die entsprechende Wiki-Seite einfach in den Workspace der nächsten Version übernommen.
So bleiben alle Entwicklungsinformationen stets im richtigen Kontext, und Zusammenhänge zwischen Ideen (Version X) und deren Umsetzung (Version Y) sind jederzeit nachvollziehbar.
In unseren an Scrum angelehnten Montagsmeetings definieren wir die primären Entwicklungsziele für die Woche, d. h. die konkreten Features, an denen gearbeitet wird.
Da, wie beschrieben, nicht immer alle Anforderungen vollständig definiert sind, werden auch kleinere Research-Projekte gestartet, um dann im darauffolgenden Meeting, wenn die notwendigen Informationen vorliegen, die finale Entscheidung bezüglich der weiteren Vorgangsweise treffen zu können.
Selbstverständlich gibt es auch Funktionen deren Entwicklung sich über mehrere Wochen erstrecken oder die von verschiedenen Teams (z. B. Server und Applikation) gemeinsam umgesetzt werden.
Das Montagsmeeting dient dann auch dazu, um relevante Informationen weiterzugeben.
Die Qualitätssicherung ist von Anfang an in diese Meetings eingebunden. Dadurch können fertige Funktionen frühzeitig an die QS zum Modultest übergeben werden, und gleichzeitig ist sichergestellt, dass die QS stets über den aktuellen Entwicklungsstand informiert ist, was deren Planung erleichtert.
Je näher man dem Liefertermin rückt, umso restriktiver wird die Planung der Wochensprints. Research-Projekte werden dann nicht mehr gestartet, der Fokus liegt ausschließlich auf der Fertigstellung.
Das bedeutet auch, dass nicht alle ursprünglich geplanten Features umgesetzt werden können. Da unsere Liefertermine aufgrund der Rollout-Zyklen unserer Kunden in der Regel fix sind, ist diese Priorisierung notwendig.
Parallel dazu gibt es Entwicklungen, die von vornherein über mehrere Release-Zyklen hinweg geplant sind.
Ein wesentlicher Bestandteil unseres Entwicklungsprozesses ist die Sicherstellung der Upgradefähigkeit. In den letzten 30 Jahren haben wir keinen Kunden verloren, weil ein Upgrade auf die aktuelle Version nicht möglich gewesen wäre.
Viele Kunden nutzen zudem unseren Premiumservice, bei dem wir sie aktiv bei der Migration ihrer kundenspezifischen Anpassungen unterstützen.
Aus diesem Grund ist unsere Testphase etwas länger als üblich, da wir auch Migrationen mit kundenspezifischer Anpassungen testen.
So ist es in den letzten über 30 Jahren zu keinem Rollback gekommen.
Trotz sorgfältiger Planung gibt es, wie in jedem Projekt, unvorhersehbare Ereignisse. Die einzige Vorbereitung darauf ist das Bewusstsein, dass sie eintreten werden.
Deshalb bleiben Teile des Entwicklungs- und QS-Teams auch nach dem Rollout noch eine Zeit lang im Projekt eingebunden. So können wir bei unerwarteten Problemen schnell mit Hotfixes oder Service Packs reagieren.
Zwischen Support und Entwicklung besteht ein kontinuierlicher, direkter Austausch.
Das ist notwendig, da es während des Einsatzes unseres Produkts immer wieder zu außerplanmäßigen, von uns nicht beeinflussbaren Veränderungen kommt. Auch in solchen Fällen unterstützen wir unsere Kunden so schnell wie möglich.
Wir sind uns bewusst, dass wir nicht im Zentrum der IT-Welt stehen, und legen großen Wert darauf, uns bestmöglich in bestehende IT-Umgebungen zu integrieren.
Welche Auswirkungen haben Updates von Betriebssystemen, Browsern, Datenbanken oder iOS auf die Anwendung oder die (iPad)App?
Für Probleme, die durch solche Änderungen entstehen, stellen wir so schnell wie möglich Lösungen bereit, ohne auf das nächste Release zu warten. So gewährleisten wir einen stabilen und kontinuierlichen Betrieb des Intranets.
Die Startseite in den Arbeitsalltag, der zentrale Ort für alle Unternehmensinformationen, muss jederzeit zuverlässig funktionieren.
Soviel zum Entwicklungsprozess. In den nächsten Blogbeiträgen werde ich einige der neuen Features vorstellen.
Fragen und Anmerkungen bitte per E-Mail!
Weitere Beiträge zu diesem Thema: