Blog

ICM 3.6 ist ausgerollt

27.10.2026 / in ICM

Rechtzeitig zum FI-Forum (03.–05.11.2026 in Frankfurt) haben wir wieder eine neue Version von Intranet Content Management (ICM) ausgerollt: ICM 3.6.

ICM 3.6 Rollout

Direktes Feedback beim FI-Forum

Der Rollout von ICM 3.6 gibt uns die Gelegenheit, beim FI-Forum direktes Feedback von Anwendern zu erhalten, die Neuerungen vorzuführen und über ihre Anwendung zu diskutieren.

Dieser persönliche Austausch ist für uns hilfreich, weil wir sehen, welche Funktionen sofort verständlich sind, wo noch nachgebessert werden muss und an welchen Stellen eine zusätzliche Erklärung sinnvoll ist. Vieles lässt sich in einem Gespräch oder einer Live-Demo schneller klären als über Support-Tickets.

Das FI-Forum ist außerdem ein guter Ort, um über zukünftige Entwicklungen zu sprechen. Dabei geht es sowohl um Funktionen auf unserer Roadmap als auch um Vorschläge unserer Kunden.

Natürlich haben wir auch etablierte Prozesse, um Kundenwünsche und Verbesserungsvorschläge zu erfassen und zu bewerten. Ein persönliches Gespräch hilft jedoch, das konkrete Anwendungsszenario besser zu verstehen, und nimmt so direkten Einfluss auf die Umsetzung.

Unvorhergesehenes im Rollout einplanen

Zum Abschluss noch ein paar Worte zum Rollout-Prozess, der dieses Mal glücklicherweise reibungslos verlaufen ist.

Natürlich soll immer alles funktionieren. Deshalb haben wir eine umfangreiche Qualitätskontrolle: Die Fachabteilung prüft das Produkt, und die Finanz Informatik kontrolliert das Einsatzszenario in der Sparkassen-IT-Infrastruktur. Trotzdem ist es schlicht nicht möglich, alle Situationen vorherzusehen.

Irgendetwas Unerwartetes kann immer auftreten. Möglich sind etwa eine uns unbekannte Modifikation am Zielsystem, eine Veränderung der Lastverteilung oder eine Anpassung an einer Schnittstelle zu einem anderen System. Vergleichbar ist das mit der Grippeimpfung: Sie schützt gegen bekannte Varianten, während sich gleichzeitig neue Mutationen entwickeln können, gegen die der aktuelle Wirkstoff nicht hilft.

Was kann man dagegen tun? Noch genauer prüfen und noch mehr testen?

Aus unserer Sicht lässt sich das Problem dadurch nicht lösen. Unbekanntes bleibt unbekannt. Den Zufall kann man nur schwer vorhersehen, aber man kann sich auf ihn vorbereiten.

Was wirklich hilft, ist eine Rollout-Planung, in der festgelegt wird, wie bei einem Problem vorzugehen ist. Abhängig vom Schweregrad kann der Entscheidungspfad bereits im Vorfeld definiert werden. Dadurch lässt sich im Problemfall rasch reagieren, statt erst dann überlegen zu müssen, was zu tun ist.

Bei der Apollo-11-Landung hat dieses Prinzip funktioniert, Stichwort Fehlercode 1202 (Apollo Guidance Computer – Apollo 11). Auch im „normalen“ Projektalltag ist eine vorbereitete Einschätzung von Problemklassen hilfreich.

Entscheidungen in der Pilotphase des Rollouts

Besonders wichtig ist eine rasche Entscheidung bei Problemen, die während der Pilotphase auftreten:

  • Kann das Problem jetzt noch behoben werden?
  • Kann der Fehler vorerst akzeptiert und erst mit einem Service Pack korrigiert werden?
  • Muss der Rollout abgebrochen werden?

Bei uns gibt es klare Kriterien, die festlegen, wann ein Rollout abgebrochen werden muss und wann ein Problem während des Rollout-Prozesses behoben werden kann.

Wesentlich ist außerdem, das verfügbare Zeitfenster zu berücksichtigen. Wenn ein Upgrade durch einen zusätzlichen Schritt nicht mehr in das vorgesehene Zeitfenster passt, muss entschieden werden, ob dieser Schritt auf einen späteren Zeitpunkt verschoben werden kann, z. B. auf ein „Wochenend-Fenster“, oder ob der gesamte Rollout abgebrochen werden muss, weil dieser Schritt zwingend zum Zeitpunkt des Upgrades durchgeführt werden muss.

Für Problembehebungen gilt Folgendes: Ist nur eine einzelne Funktion betroffen, kann noch eine „schnelle“ Behebung erfolgen. Ist dagegen eine Fehlerbehebung in einem zentralen Bereich notwendig, auf den viele Funktionen aufbauen, ist das Risiko zu groß für einen „Schnellschuss“, der eine Funktion korrigiert, aber möglicherweise Fehler in anderen Bereichen verursacht.

Migrationsschritte im Wochenend-Wartungsfenster

Beim Rollout von ICM 3.6 gab es einige geplante Migrationsschritte, die wir in Abstimmung mit der Finanz Informatik in einem „Wochenend-Wartungsfenster“ nach dem eigentlichen Rollout durchgeführt haben. Für diese Schritte war ein Neuaufbau des Suchindex notwendig. Bei großen Sparkassen hätte dieser Vorgang nicht mehr in das normale Upgrade-Zeitfenster gepasst. Die Aufteilung war möglich, da ein Normalbetrieb mit dem alten Index möglich war und eine spätere Durchführung somit kein Problem darstellte.

Welche Neuerungen ICM 3.6 mitbringt, werde ich im nächsten Beitrag vorstellen und beim FI-Forum vorführen.

Fragen und Anmerkungen bitte per E-Mail!

« Zurück