Unser Ansatz
Bevor wir eine Änderung vorschlagen, klären wir, wie die Anwendung die tägliche Arbeit des Unternehmens unterstützt.
Bevor wir eine Technologie auswählen, klären wir, wie die Anwendung die tägliche Arbeit des Unternehmens unterstützt. Was erschwert den Kundenservice? Welche Abläufe müssen durchgehend funktionieren, und was soll die Änderung bewirken? Ein neues Framework, eine Neuentwicklung oder KI können helfen. Ob sie sinnvoll sind, hängt vom festgestellten Problem ab.
Wir fragen nach dem Anlass: langsame Bestellbearbeitung, schwierige Deployments, manuelle Korrekturen oder ein Bericht, dem das Team nicht vertraut. Ein konkretes Problem hilft zu beurteilen, ob ein Symfony-Upgrade etwas löst oder eine andere Maßnahme nötig ist. Auch Rahmenbedingungen zählen, etwa Abrechnungstermine oder eine Verkaufskampagne, während der Änderungen am Zahlungsablauf besondere Vorsicht verlangen.
Anschließend verfolgen wir den gewählten Ablauf von Anfang bis Ende. Wer startet ihn, wo fallen Entscheidungen, und woran erkennt das Team, dass ein Vorgang abgeschlossen ist? Arbeit außerhalb der Anwendung gehört ebenfalls dazu.
Geschäftsprozess
├── Anwendung
│ ├── Daten
│ ├── Integrationen
│ └── Hintergrundjobs
└── Entscheidungen und manuelle SchritteWir sprechen mit Prozessverantwortlichen, Kundenservice, Buchhaltung und dem Team, das die Anwendung betreut. Ihre Beobachtungen vergleichen wir mit Dokumentation, Code, Daten und Logs. Beschriebene Abläufe, heutige Praxis und künftige Anforderungen können voneinander abweichen. Nicht jede Abweichung ist ein Fehler.
Wir suchen nach undokumentierten Regeln. Ein scheinbar ungenutzter Status kann eine Rechnung markieren, die vor dem Buchhaltungsexport geprüft werden muss. Bevor wir ihn entfernen oder Daten migrieren, klären wir seinen Zweck mit der Buchhaltung. Eine Migration muss die Bedeutung der Informationen erhalten, nicht nur ihre gespeicherten Werte.
Auch Berechtigungen prüfen wir: Wer darf Daten lesen, ändern oder einen Vorgang freigeben? Dabei berücksichtigen wir Organisationsgrenzen und Freigaben außerhalb der Oberfläche. Ein sichtbarer Button ersetzt keine serverseitige Zugriffskontrolle.
Die technische Prüfung umfasst die für den Ablauf relevanten Teile: Modulabhängigkeiten, Tests, Konfiguration, Deployments und Hintergrundjobs. Bei einem einzelnen Fehler kann es genügen, eine Operation nachzuverfolgen. Eine größere Modernisierung erfordert eine breitere Untersuchung. Der Umfang richtet sich nach der Entscheidung des Kunden.
Nehmen wir eine hypothetische ältere Symfony-Anwendung. Aus Kundensicht ist der Ablauf einfach: Zahlung, Rechnung und Bestätigung. Im Hintergrund kann die Bestätigung des Zahlungsanbieters jedoch später eintreffen. Ein Worker erzeugt die Rechnung, und der Buchhaltungsexport läuft nach einem Zeitplan.
Bestellung
↓
Zahlungsbestätigung
↓
Bestellstatus aktualisieren
↓
Aufgabe in der Rechnungs-Queue
├── Erfolg → Rechnung und Benachrichtigung
└── Fehler → Wiederholung oder manuelle PrüfungBei einem Anbieterwechsel prüfen wir diesen gesamten Weg. Eine wiederholte Zahlungsnachricht darf keine zweite Rechnung erzeugen, und Fehler in der Warteschlange müssen für das Team sichtbar sein. Wir klären, wer offene Fälle prüft und ihren Abschluss vor dem Export bestätigt. Ein funktionierendes Bestellformular allein gibt darüber keine Auskunft.
Bei Verbindungen zu CRM, ERP, E-Mail- oder Zahlungsdiensten klären wir den Datenaustausch und welches System die verbindliche Fassung führt. Wir prüfen auch, was passiert, wenn der Anbieter nicht antwortet. Bei unklarer Datenverantwortung können zwei Systeme gegenseitig ihre Korrekturen überschreiben.
Uns interessiert der Zustand nach einem Fehler: Was wurde gespeichert, kann die Operation wiederholt werden und wer darf das tun? Ein erneuter Import oder geänderte Kundendaten nach einer Bestellung müssen bereits ausgeführte Aktionen berücksichtigen. Das Team braucht genügend Informationen, um die Arbeit fortzusetzen, ohne Dokumente doppelt anzulegen oder notwendige Prüfungen zu überspringen.
Manuelle Schritte können wichtige Kontrollen sein. Ein hoher Betrag braucht vielleicht eine Freigabe, unklare Daten eine persönliche Prüfung. Wir klären Zweck und Verantwortung, bevor wir eine Automatisierung vorschlagen.
Wir betrachten auch die Bereitstellung neuer Versionen. Nach einem Update kann ein Worker noch mit altem Code oder alter Konfiguration laufen. Dann entstehen Bestellungen nach neuen Regeln, während Rechnungen nach alten Vorgaben verarbeitet werden.
Ein langsames Portal muss nicht neu geschrieben werden. Möglicherweise lädt nur ein Bildschirm die gesamte Bestellhistorie und wartet auf eine CRM-Antwort, während der Rest zuverlässig arbeitet. Eine bessere Abfrage oder eine angepasste Kommunikation mit dem CRM kann dann ausreichen.
Wir bewerten auch die Folgen für das Unternehmen. Eine angehaltene Warteschlange kann dazu führen, dass bezahlte Bestellungen auf Rechnungen warten und das Team erst durch Kundenbeschwerden davon erfährt. Das begründet eine Priorität deutlicher als eine reine Liste technischer Fehler.
Ein zuverlässiges, gut verstandenes Modul sollte erhalten bleiben, solange es benötigte Änderungen nicht blockiert. Das Alter allein rechtfertigt keinen Ersatz. Vorrang haben Störungen und Einschränkungen, die tägliche Arbeit oder Weiterentwicklung behindern.
Die Empfehlung beschreibt die Arbeit und die Bereiche, die unverändert bleiben sollen, etwa Preisregeln, Berechtigungen oder historische Auswertungen. Wir vergleichen Kosten, Risiken und die Möglichkeit, Änderungen rückgängig zu machen. Bei schrittweisem Vorgehen benennen wir den ersten Schritt und die Bedingungen für den nächsten.
Beobachtetes Problem
↓
Bestätigte Ursache
↓
Auswirkung auf das Unternehmen
↓
Bewahren / stabilisieren / verbessern / ersetzenDas Ziel soll ein überprüfbares Ergebnis beschreiben. „Den Zahlungsanbieter wechseln können, ohne Bestellungen, Rechnungen oder Kundenkonten anzupassen“ sagt mehr als „eine neue Architektur einführen“. Zugleich legt es fest, wann die Arbeit abgeschlossen ist.
Welche Unterlagen entstehen, vereinbaren wir vor der Analyse. Je nach Problem erstellen wir:
Wir nutzen die Zugänge, die für das vereinbarte Ziel nötig sind. Fehlen Unterlagen oder lässt sich eine frühere Entscheidung nicht mehr nachvollziehen, benennen wir die Lücke und ihre Folgen für die Empfehlung. Der Kunde kann dann entscheiden, ob die Arbeit beginnen soll oder zunächst die offene Frage geklärt werden muss.