Nicht jedes Projektumfeld eignet sich gleichermaßen für rein agile Frameworks – zumindest nicht ohne gezielte Adaption. Besonders deutlich wird dies bei der Implementierung von Plattformlösungen wie Ivalua. Auch wenn agile Prinzipien hier ihre Berechtigung haben und eingesetzt werden, unterscheidet sich die Projektrealität doch in mehreren grundlegenden Punkten von einem typischen, inkrementell entwickelten Softwareprodukt.

Kurze Planungszyklen (Sprints) und eine iterative Entwicklung stehen auch bei Ivalua Projekten meist im Fokus. Das übergreifende Ziel dabei ist es, unter enger Einbindung der relevanten Stakeholder schnell, transparent und adaptiv einen Mehrwert zu generieren. In einigen Aspekten verlangen Ivalua Projekte jedoch eine besondere Herangehensweise:

Konfiguration statt Entwicklung – der systemimmanente Rahmen

Der zentrale Unterschied liegt in der Natur des Produkts. Während agile Softwareprojekte auf eine Greenfield-Entwicklung ausgerichtet sind – mit vollständiger Kontrolle über Architektur, Codebasis und Releases –, bewegen sich Ivalua-Projekte innerhalb einer hochstandardisierten, vorgegebenen Systemarchitektur. Dabei liegt die Projektleistung primär in der Konfiguration bestehender Funktionalitäten, der Modellierung von Workflows und der Anpassung von UI-Komponenten über die plattform-eigenen Werkzeuge.

Der Fokus liegt auf “Configure, not Code”. So lassen sich z.B. über das Page Design-Modul Formulare, Abschnitte und Felder per Drag & Drop konfigurieren. Sichtbarkeit, Pflichtfelder und Validierungen lassen sich regelbasiert per über die grafische Benutzeroberfläche (GUI) einstellen. Es ist keine individuelle Programmierung per Frontend-Code erforderlich. Des Weiteren erleichtert ein visueller Workflow-Editor die Konfiguration von Genehmigungs- und Geschäftsprozessen über Zustände, Bedingungen, Übergänge und Aufgaben. Berechtigungen wie Feldzugriffe, Tab-Sichtbarkeit oder Aktionsbuttons werden über Profile, Rollen und Sichtbarkeitsregeln konfiguriert, was die Zuweisung ohne Code durch Administratoren steuerbar macht. Kurz: Es wird ein bestehendes, sehr umfangreiches SaaS-Produkt konfiguriert und parametrisiert, aber nicht entwickelt.

Diese Einschränkung ist keineswegs negativ zu bewerten – sie ermöglicht Skalierbarkeit, Governance und Security-by-Design. Sie bringt aber methodische Herausforderungen mit sich: Viele Anforderungen lassen sich nur innerhalb enger technischer Leitplanken umsetzen. Klassische Entwicklungspfade – etwa das Erweitern durch individuelle Microservices – stehen in der Regel nicht zur Verfügung oder sind mit hohen Aufwänden verbunden.

Funktionale Fragmentierung – Fortschritt ohne Nutzbarkeit?

In agilen Entwicklungsprojekten steht am Ende jedes Sprints idealerweise ein lauffähiges, getestetes Feature mit unmittelbarem Mehrwert. Bei Ivalua-Projekten gestaltet sich dies anders:

Konfigurationsfortschritte, wie etwa eine angelegte Datenstruktur, eine Regel oder ein Workflow-Segment, sind für sich genommen oft noch nicht produktiv nutzbar. Releases sind stärker auf Use-Case-Bundles oder End-to-End-Szenarien ausgerichtet. Die volle Funktionalität ergibt sich daher erst im Zusammenspiel mehrerer Komponenten.

Dies führt zu einer gewissen Entkopplung von Fortschritt und Nutzenwahrnehmung, was insbesondere im Stakeholder-Management berücksichtigt werden muss. Es bedarf einer transparenten Kommunikationsstrategie, um Projektfortschritte plausibel und nachvollziehbar darzustellen – ohne die Erwartung zu wecken, jede Iteration bringe ein vollständig produktiv einsetzbares Ergebnis.

Agilität im Spannungsfeld konservativer Prozesslogik

Ein weiterer kritischer Unterschied liegt in der Zusammensetzung und Erwartungshaltung der Stakeholder. Während agile Softwareprojekte häufig IT-nah organisiert sind, prägen in Ivalua-Implementierungen vor allem Einkaufs-, Finance- und Compliance-Funktionen die Anforderungen. Diese Fachbereiche agieren in der Regel prozessorientiert, mit einem hohen Maß an Standardisierungsanspruch und regulatorischen Rahmenbedingungen.

Agilität bedeutet in diesem Kontext weniger radikalen Wandel als vielmehr kontrollierte Adaption. Methodische Elemente wie Backlog-Priorisierung, Sprint-Demos oder iterative Feedbackzyklen sind weiterhin sinnvoll – sie müssen jedoch in ein Stakeholder-verständliches Format übersetzt und in die Systemlogik der Plattform eingebettet werden.

Da der Ivalua-Implementierungsansatz eine rein agile Umsetzung schwierig macht, fokussiert sich jupitos als spezialisierter Implementierungspartner auf einen hybriden, praxisorientierten Projektansatz, der systemische Rahmenbedingungen respektiert und gleichzeitig große Nähe zum Business schafft.

1. Ivalua verlangt hybride Methoden – Mit agilen Teamstrukturen

Der Ivalua-Implementierungsansatz basiert auf einem festen Projektmodell (Design – Build – Validate – Deploy), das nicht einfach durch klassische Scrum-Logik ersetzt werden sollte. Projekte werden typischerweise in Phasen oder “Wellen” modular umgesetzt, z. B. Lieferantenstammdaten, Sourcing, Verträge, Rechnungen. Das erfordert klare Roadmaps, um Business-Prioritäten mit Systemabhängigkeiten in Einklang bringen, die so geplant werden müssen, dass Abhängigkeiten und Mehrwerte sauber aufeinander aufbauen. Die Herausforderung besteht darin, diesen strukturellen Rahmen mit agilen Elementen zu verbinden, ohne Komplexität und Steuerbarkeit zu verlieren.

Jupitos etabliert von Beginn an ein hybrides Projektmodell: Wir verbinden diszipliniertes Phasenmanagement mit agilen Arbeitsweisen wie Daily Check-Ins, Review-Zyklen und iterativen Konfigurationseinheiten. Dabei definieren wir früh klare Rollout-Roadmaps, die sowohl fachliche Relevanz als auch technologische Abhängigkeiten abbilden. So entsteht eine planbare, aber anpassungsfähige Projektdynamik.

In vielen Ivalua-Projekten gibt es keinen dedizierten Product Owner mit klarer Entscheidungshoheit. Stattdessen sehen wir oft Rollenmischungen. Eine Konfiguratorin kann so ebenfalls Analystin, Testerin und PM werden. In matrixartig aufgestellten Projektteams mit wenig agiler Schulung lässt sich das klassische Scrum-Ideal in der Realität daher kaum durchsetzen.

Bei jupitos bringen wir vollumfängliche Methodenkompetenz mit – und leben Agilität so, wie sie im Ivalua-Kontext funktioniert: mit angepassten Rollenbildern, strukturiertem Backlog-Management, regelmäßigen Reviews und klarer Iterationslogik. Ohne Dogmatismus, aber mit hoher Disziplin – um Orientierung zu schaffen.

2. Fachbereiche fordern Individualisierung statt Standardisierung

Viele Fachbereiche neigen dazu, bestehende Prozesse 1:1 in Ivalua übertragen zu wollen. Das führt jedoch schnell zu überkonfigurierten, wartungsintensiven Lösungen und schwächt die Skalierbarkeit. Gleichzeitig widerspricht es dem Plattformprinzip, das auf Wiederverwendbarkeit und Standards ausgelegt ist.

Noch vor Projektstart durchlaufen wir daher bei jupitos intensive Vorbereitungsphasen mit dem Ziel, ein vorkonfiguriertes System bereitzustellen, das den späteren Scope bereits bestmöglich abdeckt, um mit unseren Kunden von Beginn an in einer auf sie abgestimmten Umgebung zu arbeiten. In unseren Bootcamps vor dem Kick-Off machen wir das System greifbar, validieren es, soweit möglich, gemeinsam mit dem Kunden und leiten daraus gezielt die notwendigen Gaps ab. Statt sofortigem Customizing setzen wir zunächst auf eine fundierte Gap-Analyse – mit dem Ziel, nur dort zu individualisieren, wo es echten Mehrwert bringt. So verhindern wir Scope Creep und sichern langfristige Wartbarkeit. Ob Industrie, Handel oder Finanzdienstleister – wir kennen die spezifischen Anforderungen und wir wissen, was sich übertragen lässt.

3. Workshops ohne Output – zu weit vom System

Zu oft verlaufen Anforderungsworkshops in der Theorie und ohne Systembezug oder greifbare Ergebnisse. Das führt zu Missverständnissen, überhöhten Erwartungen und fehlender Verbindlichkeit.

jupitos Workshops finden daher ausschließlich systemnah statt – in einer vorkonfigurierten Umgebung, die auf den Kunden zugeschnitten ist. Wir kommen vorbereitet, zeigen konkrete Lösungsvorschläge in Systemdemos und machen das Produkt direkt erlebbar. So entsteht nicht nur Akzeptanz, sondern auch unmittelbares Feedback.

4. No-/Low-Code statt Greenfield-Entwicklung

Die konfigurierbare No-/Low-Code-Plattform macht die Umsetzung von Ivalua-Implementierungen nicht automatisch einfacher. Hier entstehen neue Herausforderungen. Die technische Umsetzung wandert näher an den Fachbereich, der wiederum selten über die methodischen oder strukturellen Fähigkeiten verfügt, um Konfiguration, Regellogik, UI-Design und Testbarkeit effizient zu verzahnen. Ohne klare Verantwortung, enge Abstimmung und methodisches Vorgehen entsteht schnell Chaos statt Fortschritt.

jupitos versteht die No-/Low-Code-Logik nicht als Vereinfachung, sondern als Verschiebung der Verantwortung – und steuert diese gezielt. Wir bringen erfahrene Konfigurations-Spezialisten mit, die Business-Logik und Systemverhalten sauber aufeinander abstimmen. Gleichzeitig fördern wir kollaboratives Arbeiten mit dem Fachbereich, z. B. durch gezielte Reviews und ein strukturiertes Testmanagement. Unsere Projektmethodik priorisiert Scope-Klarheit, Testbarkeit und Nutzerakzeptanz.

5. Datenabhängigkeit & ERP-Schnittstellen – der kritische Pfad im Projekt

Eines der größten Risiken für den Projekterfolg liegt außerhalb von Ivalua selbst: Fragmentierte ERP-Landschaften, schlechte Stammdaten und fehlende Schnittstellenkonzepte verzögern nicht nur den Go-Live, sondern können diesen auch strukturell gefährden.

jupitos integriert von Beginn an ein Data Readiness Assessment. Gemeinsam mit den ERP- und Datenverantwortlichen auf Kundenseite analysieren wir Datenqualität, Mappings, Integrationslogiken und Lücken. Die frühzeitige Zusammenarbeit mit IT-Teams stellt sicher, dass Ivalua auf einem stabilen Fundament aufsetzen kann.

6. IT und Fachbereich mit unterschiedlichen Zielbildern

In vielen Projekten kommt es vor, dass IT und Fachbereich nicht abgestimmt sind. Die einen denken in Systemgrenzen, die anderen in Prozessketten. Ohne aktives Alignment droht das Projekt zwischen technischen Limitierungen und fachlichen Wunschlisten zerrieben zu werden.

Wir moderieren aktiv zwischen beiden Welten – durch modulweise Reviews und das gezielte Einbinden von Key Usern aus allen Bereichen. Durch kollaboratives Testen, gemeinsame Story-Validierung und enge Kommunikation entsteht ein echtes Projektverständnis auf beiden Seiten.

7. Komplexität steigt auch im Change Management

Ivalua ist leistungsstark, aber nicht selbsterklärend. Nutzerakzeptanz entscheidet maßgeblich über den Projekterfolg. Unser letzter Blogartikel geht detailliert auf die sechs zentralen Faktoren für erfolgreiches Change Management ein: Stakeholder-Analyse, Change-Analyse, Kommunikation, Multiplikatoren, Kontinuierliche Verbesserung und Training & Support.

jupitos erkennt die Relevanz des Change Management für Ivalua-Implementierungsprojekte an und arbeitet mit spezialisierten Change-Partnern zusammen, die Kommunikation, Stakeholder-Engagement und Adoption professionell begleiten.

Die Implementierung von Ivalua ist kein rein agiles Softwareprojekt – und genau darin liegt die Komplexität. Der Plattformansatz, das No-/Low-Code-Paradigma, die feste Phasenstruktur und die starke Nähe zu fachlich regulierten Bereichen wie Einkauf, Finanzen und Compliance verlangen ein methodisches Vorgehen, das sich weder vollständig in bekannte Scrum-Strukturen noch in rein wasserfallartige Modelle pressen lässt. Funktionale Fragmentierung, Rollenunschärfe, technische Abhängigkeiten und kulturelle Unterschiede zwischen IT und Fachbereich gehören zur Projektrealität.

jupitos begegnet diesen Herausforderungen mit einem bewährten hybriden Projektansatz, der agile Prinzipien mit strukturierter Implementierungslogik verbindet. Wir arbeiten systemnah, nutzen vorab konfigurierte Best Practices, priorisieren Standardisierung vor Individualisierung und binden Fachbereiche gemeinsam mit IT von Anfang an aktiv ein. Unsere Stärke liegt darin, komplexe Projekte pragmatisch, transparent und kollaborativ zum Erfolg zu führen – mit Fokus auf Business Value, Nutzerakzeptanz und langfristiger Skalierbarkeit. Wer Ivalua erfolgreich einführen will, braucht kein dogmatisches Framework, sondern einen Partner, der beides beherrscht: Plattform und Projektmethodik.