Wann braucht ein Unternehmen individuelle Software und wann reichen die vorhandenen Werkzeuge?

Beginnen Sie beim letzten schwierigen Vorgang, nicht bei einer Funktionsliste.

Wählen Sie einen Auftrag, Bericht oder eine Meldung, bei der etwas schiefgelaufen ist. Rekonstruieren Sie die Schritte: Wo entstand die Information, wer änderte sie und wann bemerkte jemand das Problem? Halten Sie auch fest, was das Team zur Behebung unternehmen musste.

Lag die Ursache in ungeklärter Verantwortung, stellt ein neues Programm diese nicht von selbst her. Bearbeiteten zwei Personen verschiedene Dateiversionen und kann niemand die richtige benennen, kann tatsächlich das Werkzeug den Ablauf begrenzen. Diese Unterscheidung verhindert, dass dasselbe Durcheinander nur digital nachgebaut wird.

• Was genau ist passiert?
• Wie oft kehrt eine ähnliche Situation wieder?
• Welche Information oder Regel hätte sie verhindern können?

Erstes Signal: Die Antwort hängt davon ab, wen Sie fragen.

Der Vertrieb nennt einen anderen Termin als die Planung. Das Lager hat einen anderen Bestand als die Tabelle der Kundenbetreuung. Die Leitung wartet auf die einzige Person, die weiß, wo die aktuelle Datei liegt. Dann geht es nicht um das Aussehen der Tabelle, sondern um eine fehlende gemeinsame Informationsquelle.

Prüfen Sie, ob sich für jede wichtige Angabe ein verantwortliches System bestimmen lässt. Manchmal genügt es, vorhandene Werkzeuge zu ordnen. Ein individuelles Modul wird sinnvoll, wenn Informationen mehrere Rollen durchlaufen müssen und bestehende Lösungen die benötigten Änderungen und Bestätigungen nicht unterstützen.

• Bestimmen Sie die Verantwortlichen für Status, Termin und Kundendaten.
• Klären Sie, wer diese Informationen ändern darf und wo dies geschehen soll.

Zweites Signal: Regeln funktionieren nur dank des Gedächtnisses der Mitarbeitenden.

Vor dem Versand muss eine Charge geprüft werden, nach einer Mengenänderung braucht das Angebot eine erneute Freigabe und bei bestimmten Aufträgen ist ein zusätzliches Dokument nötig. Existieren diese Regeln nur in den Köpfen weniger Personen, offenbart jede Vertretung oder Einarbeitung das Risiko.

Schreiben Sie die Bedingungen als „Wenn X eintritt, benötigen wir Y“ auf. Ergänzen Sie zu jeder Regel eine Ausnahme. Erst so lässt sich beurteilen, ob Standardkonfiguration, eine einfache Automatisierung oder ein System mit eigenem Workflow benötigt wird. Nicht jede Ausnahme braucht sofort eine eigene Funktion; manche kann eine berechtigte Person bearbeiten.

Vergleichen Sie drei Wege anhand desselben Szenarios.

Vergleichen Sie kein Standardprodukt mit einer Wunschliste für eine eigene Anwendung. Bereiten Sie einen repräsentativen Prozess vor und prüfen Sie ihn in jeder Variante: mit geordneten vorhandenen Werkzeugen, mit einem verfügbaren Produkt und mit einer individuellen Lösung. Achten Sie auf manuelle Umwege, Datenexport, Integrationen und den Schulungsbedarf.

Ein eigenes System erlaubt Anpassungen, verlangt aber Projektentscheidungen, Betrieb und Weiterentwicklung. Ein Standardprodukt kann schneller einsatzbereit sein; seine Regeln, Zugangskosten und Grenzen müssen jedoch vor der Auswahl bekannt sein. Eine Kombination lässt oft bewahren, was bereits funktioniert, und ergänzt nur den fehlenden Ablauf.

• Lässt sich der Prozess von Anfang bis Ende ausführen?
• Was bleibt außerhalb des Werkzeugs zu erledigen?
• Wie erhalten wir unsere Daten zurück und wer betreibt die Lösung?

Betrachten Sie die Kosten der heutigen Arbeit und der künftigen Veränderung.

Sammeln Sie Beispiele aus einem repräsentativen Zeitraum. Trennen Sie aktive Bearbeitungszeit von Wartezeit auf Entscheidungen. Eine Viertelstunde Übertragen von Daten und mehrere Tage Warten sind unterschiedliche Probleme, auch wenn beide den Kunden aufhalten. Notieren Sie außerdem Korrekturen, Duplikate und Vorgänge, die mehrere Personen beschäftigen.

Auf der Seite der neuen Lösung gehören Analyse, Entwicklung, Integrationen, Migration, Einführung der Nutzer und Betrieb in die Rechnung. Ein Teil des Nutzens kann bessere Kontrolle statt unmittelbarer Personaleinsparung sein. Benennen Sie diesen Nutzen, statt jeder Funktion einen scheinbar präzisen Kapitalrückfluss zuzuschreiben.

Die erste Version sollte einen vollständigen Ablauf abschließen.

Im Angebotsprozess könnten das Anfrageannahme, Erstellung einer Angebotsversion, Entscheidung und Übergabe des akzeptierten Vorgangs an die Ausführung sein. Diese Gesamtheit lässt sich praktisch beurteilen. Kunden-, Dokument- und Einstellungsansichten ohne Verbindung beweisen die Nützlichkeit eines Systems noch nicht.

Legen Sie fest, was außerhalb der ersten Phase bleibt. Erweiterte Analysen können warten, eine fehlende Behandlung abgelehnter Angebote würde dagegen vermutlich die tägliche Arbeit behindern. Wählen Sie den Umfang nach Vollständigkeit des Ablaufs, nicht nach der Wirkung einzelner Funktionen in einer Präsentation.

• Anfang: Was löst den Vorgang aus?
• Verlauf: Wer handelt und wer entscheidet?
• Abschluss: Welches Ergebnis kennzeichnet das Ende?

Klären Sie vor der Entscheidung, wer für das System verantwortlich sein wird.

Es braucht eine Person, die Fragen zum Prozess und zu Prioritäten entscheiden kann. Ohne sie kann jeder neue Vorschlag die Projektrichtung verändern. Beziehen Sie auch die späteren Nutzer ein: Ihre täglichen Ausnahmen fehlen häufig in einer Beschreibung, die allein die Leitung erstellt hat.

Vereinbaren Sie die Abnahme anhand konkreter Szenarien, erwarteter Ergebnisse, Testpersonen und Beispieldaten. Besprechen Sie Aktualisierungen, Backups, Dokumentationszugang und Weiterentwicklung. Die Entscheidung für Software betrifft die gesamte Nutzungszeit, nicht nur den Einführungstag.