Zurück zu allen Fallstudien

Ein Black-Box-Legacy-System in ein unternehmensweites Delivery- und Support-Betriebssystem überführen (Jira Cloud)

Kurzprofil

Liefermodell: Principal-geführtes Engagement (Stefan, Gründer und Principal Consultant). Kunde: Ironbridge ERP (deutscher ERP-Anbieter für Maschinenhandel und Vermietung). Ein mittelständischer Anbieter modernisierte sein internes Projekt- und Servicefall-Management nach Jahren ad-hoc-gesteuerter, interruptionsgetriebener Arbeit bei geringer organisatorischer IT-Reife. Vionix führte ein fünfmonatiges Engagement durch (2 Monate Entwicklungs-Pilot plus 3 Monate unternehmensweiter Rollout) mit einer Organisation von etwa 35 Personen und übergab die vollständige Administration am Ende.

Die Herausforderung

Der Kunde arbeitete für Projekte und Servicefälle mit einem internen Managementsystem, das unrealistische 15-Minuten-Zeiterfassung erzwang und Schattenprozesse wie Papiernotizen oder nachträgliches Blockbuchen begünstigte. Die gemeldeten Aufwände entsprachen dadurch oft nicht der tatsächlichen Arbeit.

Änderungsdokumentation war faktisch manuell und wurde häufig übersprungen. Entwickler hatten kaum Sicht auf die Arbeit anderer. Es entstand ein isoliertes Black-Box-Arbeitsmodell.

Supportannahme und Zuweisung waren ohne konsistente Triage oder Transparenz organisiert. Tickets konnten beliebig klassifiziert und verteilt werden, danach aus dem Blick geraten. Kunden mussten Sachverhalte wiederholt erklären, interne Blocker wurden manuell hinterhergetragen.

Rahmenbedingungen

Die Unternehmenskultur war stark vertriebsgetrieben. Führung hatte begrenzte Engineering- und Projektmanagementkompetenz, wodurch Governance und Priorisierung schwer stabil zu halten waren.

Das Startmandat zielte formal nur auf Entwicklungsmodernisierung, obwohl die Probleme den gesamten Betriebsmodus über Entwicklung, Support und Beratung betrafen.

Das Legacy-System war manipulationsanfällig, weil Historie bearbeitet oder gelöscht werden konnte. Daraus war eine Druck-und-Archiv-Kultur als Schutz gegen Streitfälle entstanden.

Vorgehen

1. Echtes Betriebsmodell diagnostizieren: Über Interviews und Teamgespräche wurde bestätigt, dass das Kernproblem nicht nur Coding-Praktiken waren, sondern Projekt- und Service-Steuerung übergreifend.
2. Kontrollierten Entwicklungs-Pilot fahren: Jira Cloud wurde als Single Source of Truth eingeführt. Das Legacy-System lief im Pilot nur noch für Intake und Abschlussmarkierung parallel.
3. Reibung senken und Nachvollziehbarkeit erhöhen: Entwickler wurden trainiert, Commits direkt mit Jira-Issues zu verknüpfen. Manuelle Änderungsprosa wurde durch auditierbaren Workflow ersetzt.
4. Priorisierung täglich explizit machen: Kurze tägliche Abstimmungen zur Neuordnung der Prioritäten ermöglichten planbarere Arbeit mit weniger Unterbrechungen.
5. Drive-by-Tasking beenden: Strikte Routing-Regeln wurden eingeführt. Support, Vertrieb und Beratung durften Entwickler nicht mehr direkt beauftragen. Anforderungen liefen über Entwicklungsleitung und Jira.
6. Business und Engineering täglich synchronisieren: Ein tägliches Alignment zwischen Entwicklungsleitung und Vertriebs- sowie Beratungsleitung stellte Abgleich von Kundenrealität und Lieferkapazität sicher.
7. Jira an die Realität anpassen: Workflows wurden im Pilot iterativ so nachgeschärft, dass sie tatsächliche Arbeitsflüsse abbilden.

Gelieferte Artefakte umfassten die Jira-Cloud-Konfiguration und Trainingsunterlagen, die in internen Enablement-Sessions eingesetzt wurden.

Lieferumfang

• Jira-Cloud-Betriebsmodell: unternehmensweiter End-to-End-Rollout als Ersatz des internen Legacy-Managementsystems
• Workflow-Governance: Routing- und Priorisierungsregeln, die direkte Entwicklerunterbrechungen systematisch entfernten
• Nachvollziehbarer Delivery-Prozess: Commit-zu-Ticket-Verknüpfung und auditierbare Arbeitshistorie für Entwicklung und Service
• Enablement-Artefakte: Trainings, Präsentationen und Admin-Übergabe für nachhaltigen internen Betrieb

Ergebnisse

Bereits im Pilot stieg die Entwicklermoral deutlich. Beschwerden über ständige Unterbrechungen und unstrukturierte Arbeit gingen stark zurück, weil tägliche Erwartungen planbar wurden.

Die Organisation reduzierte ihre Papierabhängigkeit erheblich und sparte geschätzt 500 bis 1000 Ausdrucke pro Monat, weil Jira verlässlichere Historie und Transparenz bot als das editierbare Legacy-System.

Support und Beratung erhielten genügend Sichtbarkeit, um Kunden konkret über Status und Blocker zu informieren. Das erhöhte Kundenzufriedenheit, insbesondere durch klarere Antworten und besseres Service-Reporting, etwa zu monatlichem Ticketvolumen und Trends.

Ein wichtiger organisatorischer Effekt war stabilisierte Fluktuation. Neue Entwickler verließen das Unternehmen seltener frühzeitig, sobald Arbeit nicht mehr chaotisch und intransparent erlebt wurde.

Die letzte Adoptionshürde war Widerstand in der Supportführung aus Sorge vor Kontrollverlust und zusätzlichem Tooling. Durch gezieltes Eins-zu-eins-Coaching wurde dieser Blocker innerhalb von etwa zwei Wochen in tragfähige Zustimmung überführt.

Nach weiteren drei Monaten arbeitete das gesamte Unternehmen in Jira Cloud. Das rund 20 Jahre alte Legacy-System auf früherer NET-Basis wurde abgeschaltet, und der Kunde übernahm Administration sowie laufendes Management vollständig selbst.

Warum es funktioniert hat

Ganzsystem-Diagnose statt enger Tool-Fixierung Der Engpass lag nicht nur im Entwicklungswerkzeug, sondern im Betriebsmodell über Entwicklung, Support und Beratung hinweg.

Pilot-first-De-Risking Der kontrollierte Entwicklungs-Pilot zeigte früh Wert, blieb gleichzeitig rückrollbar und machte dadurch den breiten Rollout umsetzbar.

Verhaltensregeln statt reiner Softwarekonfiguration Routing-Regeln, tägliche Priorisierung und Führungsausrichtung beseitigten strukturelle Unterbrechungsmuster, die durch Tool-Setup allein nicht lösbar gewesen wären.

Gezielte Adoptionsarbeit Fokussiertes Coaching der letzten widerständigen Stakeholdergruppe wandelte blockierenden Widerstand in operativen Buy-in.

So hat Vionix gearbeitet

Vionix führte ein fünfmonatiges Solo-Engagement durch, beginnend mit einem zweimonatigen Entwicklungs-Pilot und anschließendem dreimonatigem Rollout über die gesamte Organisation. Die Arbeit kombinierte Moderation, Prozessdesign, Konfiguration und Teamcoaching. Administration und laufende Governance wurden am Ende vollständig intern übergeben.