Ist die Sekundärentwicklung von Standardsoftware ausnahmslos dazu gedacht, die selbstgefälligen Anmaßungen des auftraggebenden Unternehmens zu befriedigen?
„Die Weiterentwicklung von Standardsoftware dient immer dazu, die Selbstüberhebung des Auftraggeberunternehmens zu befriedigen.“ Kürzlich hat dieser Satz eines Projektmanagers eines Softwareunternehmens in einer Chatgruppe sofort eine lebhafte Diskussion ausgelöst. Das Thema ist sehr scharf, aber es ist auch eine häufige Tatsache, die oft zu Streitigkeiten führt. In diesem Prozess finden die Softwareunternehmen, dass die Auftraggeber keine Standards einhalten und die Anforderungen willkürlich ändern; während die Auftraggeber finden, dass die Softwareunternehmen nicht praxisnah sind und die sogenannten Prozesse und Standards der Großkonzerne zwangsdurchsetzen. Schließlich wird die Softwareweiterentwicklung zur „Lösung“, bei der beide Seiten ihre Widersprüche schließlich gegenseitig kompromittieren.
Aus der Sicht von Lao Yang ist die Softwareweiterentwicklung an sich kein Problem. Das eigentliche Problem liegt im fehlenden Konsens und der fehlenden Steuerung hinter der Weiterentwicklung. Wenn man nach der Ursache der „Selbstüberhebung“ fragt, tragen eigentlich beide Seiten, Auftraggeber und Auftragnehmer, Verantwortung – es stammt aus der „Arroganz“ beider Seiten, was schließlich zu gegenseitigen Vorurteilen führt.
1. Die „Selbstüberhebung“ von Softwareunternehmen: Standardisierung bedeutet nicht allgemeingültige Richtigkeit
Eine gute Standardsoftware sammelt in der Regel bewährte Verfahren der Branche, Compliance-Anforderungen und ausgereifte Prozesse, die Unternehmen helfen, Umwege zu vermeiden und die Implementierungs- sowie Wartungskosten zu senken. Dass Softwareanbieter auf Standards bestehen, hat auch seine geschäftliche Rationalität: Je mehr Weiterentwicklungen es gibt, desto umfangreicher werden die Funktionen, desto höher sind die Lieferkosten, desto schwieriger gestalten sich nachfolgende Aktualisierungen und desto weniger kann das Produkt repliziert werden.
Aber das Problem liegt darin, dass viele Entwickler und Implementierungsberater den „Standardprozess im System“ direkt mit dem „richtigen Prozess im Geschäftsbetrieb“ gleichsetzen. Sie entwerfen Funktionen im Büro, waren nie in Werkshallen, Lagern oder Filialen und haben auch keinen Mitarbeitern an der Front bei der Erledigung einer vollständigen Aufgabe begleitet, sind aber überzeugt, dass „die Großkonzerne das so machen, also solltest du das auch so machen“. Diese „Großkonzern-Philosophie“ führt zu drei typischen Irrtümern.
Erstens: Unterschiede in Unternehmensgröße und Ressourcen ignorieren.
Die bewährten Verfahren von Großkonzernen bauen auf Organisationen mit hoher Standardisierung, starker Durchsetzungsfähigkeit und hoher digitaler Kompetenz auf. Wenn ein Fertigungsunternehmen mit mehreren hundert Mitarbeitern die Prozesse von Huawei oder Alibaba übernimmt, kann es leicht dazu kommen, dass „die dreistufige Genehmigung zur Formalität wird“ oder „eine einzelne Bestellung fünf Prüfstufen durchlaufen muss“. Die Prozesse wirken standardisiert, aber die tatsächliche Effizienz sinkt am Ende.
Zweitens: „Das System kann ausgeführt werden“ mit „Der Geschäftsbetrieb kann funktionieren“ gleichsetzen.
Dass das System in Betrieb geht, bedeutet nur, dass Daten fließen können, nicht aber, dass die Mitarbeiter an der Front es gerne und reibungslos nutzen. Standard-ERP-Systeme verlangen, dass jeder Arbeitsauftrag bei Beginn, Meldung und Abschluss per Scan erfasst wird – aber die Arbeiter in der Werkshalle haben ölverschmierte Hände und der Rhythmus der Produktionslinie ist eng getaktet, sodass die Standardschnittstelle möglicherweise überhaupt nicht praktikabel ist. Wenn ein Softwareentwickler diese Szenarien nicht versteht, neigt er dazu, den Widerstand der Frontmitarbeiter auf „ihr Unvermögen, das System zu bedienen“ zurückzuführen. Deshalb hat Lao Yang, als er einst das interne Technologieunternehmen leitete, die Programmierer oft an die Produktionsfront mitgenommen, damit sie die Situation vor Ort selbst erleben und so Systeme mit Empathie und „Seele“ entwickeln können.
Drittens: Die fehlende Managementumwandlung durch technische Richtigkeit verdecken.
Im Verlauf von Projektimplementierungen hören wir Softwareunternehmen oft sagen: „Ihr müsst euch an das System anpassen, nicht das System an euch“. Das stimmt manchmal, aber wenn das Unternehmen keine begleitenden Schulungen, Anpassungen von Regelungen und Leistungsmechanismen hat und einseitig von den Mitarbeitern verlangt, sich an das System anzupassen, ist das letztendlich eine Form von Faulheit im Management.
2. Die „Selbstüberhebung“ der Fachabteilungen: Flexibilität bedeutet nicht unbedingt Angemessenheit, und sie ist auch nicht grundsätzlich unbegründet
Bei der Umsetzung digitaler Projekte begegnen Softwareunternehmen oft solchen Szenarien: Offensichtlich sind die Anforderungen der Fachabteilungen des Unternehmens unscharf und die Verwaltung willkürlich – heute eine Idee, morgen eine Forderung. Die Standardfunktionen könnten bereits 80 % der Bedürfnisse erfüllen, aber für die restlichen 20 % besonderer Szenarien verlangen sie umfassende Änderungen, sonst bezeichnen sie die Software als „nicht brauchbar“. Das führt zu zahlreichen ineffizienten Softwareweiterentwicklungen und sogar zum Kontrollverlust über das Projekt. Warum ist das so? Lao Yang hat dies in früheren Artikeln mehrfach analysiert, heute fassen wir es kurz zusammen:
Erstens: Der Geschäftsbetrieb selbst ist komplex und unstrukturiert.
Für die Verwaltung einiger traditioneller Unternehmen weisen Prozesse und Management von Natur aus eine hohe Unsicherheit auf. Zum Beispiel kann eine Rabattrichtlinie für Verkäufe heute nach Kundengruppe, morgen nach Projektgewinn und übermorgen nach Zahlungszyklus festgelegt werden. Dass die Fachabteilungen die Regeln nicht klar formulieren können, liegt nicht an mangelnder Intelligenz, sondern daran, dass dieser Geschäftsbetrieb an sich schwer zu standardisieren ist.
Zweitens: Fehlender Konsens im Management und widersprüchliche Anforderungen.
Der Verkauf verlangt Flexibilität, die Finanzabteilung verlangt Kontrolle, die Produktion verlangt Stabilität und die Unternehmensleitung verlangt Transparenz. Diese Ansprüche stehen von Natur aus im Widerspruch zueinander, und Standardsoftware kann sie kaum erfüllen. Was tun? Am Ende werden alle zu Anforderungen für die Softwareweiterentwicklung.
Drittens: Abteilungsinteressen und Widerstand gegen Gewohnheitsänderungen.
Digitalisierung bedeutet oft transparente Prozesse und eine Neuregelung von Befugnissen. Einige Abteilungen wollen nicht, dass ihre ursprünglichen Graubereiche und Ermessensspielräume durch das System festgelegt werden, und widersetzen sich der Umwandlung mit der Begründung, die Software sei „nicht brauchbar“. Wie löst man das? Wieder übernimmt die Softwareweiterentwicklung die ganze Last. Man muss wissen, dass diese Art von „Nicht-Brauchbarkeit“ ein Problem der Organisationspolitik ist, kein technisches Problem.
Viertens: Fehlende Fähigkeit, Anforderungen zu abstrahieren und zu übersetzen.
Die Mitarbeiter an der Front kennen den Geschäftsbetrieb gut, sind aber nicht in der Lage, diesen in Systemregeln zu abstrahieren. Sie sagen nur „Ich will die Flexibilität wie in Excel“, können aber nicht klar formulieren, welche Regeln, Ausnahmen und Genehmigungen mit dieser „Flexibilität“ genau gemeint sind. Wenn die Implementierungspartei keine Anleitung gibt, geraten beide Seiten in gegenseitige Vorwürfe und halten einander schließlich für „selbstüberheblich“.
Aus dem Vorstehenden geht leicht hervor, dass die willkürliche Flexibilität der Fachabteilungen Projekte durcheinanderbringen kann, aber dahinter stehen sowohl unangemessene Gewohnheiten als auch echte Geschäfts Komplexität und angemessene individuelle Anforderungen. Wenn Softwareunternehmen alle ihre Beschwerden als „Unkenntnis des Managements“ abtun, ist das an sich auch eine Form von Arroganz.
3. Die Weiterentwicklung ist das Ergebnis fehlenden Konsenses im Management
Lao Yang ist der Ansicht, dass die starke Zunahme von Weiterentwicklungsanforderungen meist kein rein technisches Problem ist, sondern ein Managementproblem.
Viele Unternehmen behandeln bei der Digitalisierung ERP, MES und CRM als reine IT-Projekte: Sie wählen eine Software, beauftragen einen Implementierungspartner, lassen die IT-Abteilung die Leitung übernehmen und die Fachabteilungen Anforderungen stellen. Das Ergebnis ist: Die Auswahl ist ungeeignet, sie kaufen eine Software, die nicht zu ihrem Unternehmen passt, und wollen sie durch Weiterentwicklung zu der brauchbaren Software machen, die sie sich vorstellen. Viele Unternehmen versäumen es, die Prozesse zu ordnen, führen keine Standardisierung des Managements durch und übertragen die unübersichtlichen Offline-Prozesse unverändert in das System. Die Unterstützung durch die Führungsebene ist unzureichend, alle Abteilungen handeln für sich, es gibt keine Priorisierung der Anforderungen, und die lauteste Stimme entscheidet. Die Implementierungsmethoden sind falsch, es fehlt an Pilotprojekten, Schulungen und Veränderungsmanagement, und man erwartet, dass sich das Verhalten der Mitarbeiter nach Inbetriebnahme des Systems automatisch ändert.
Das gemeinsame Ergebnis all dieser Vorgehensweisen ist: Die Weiterentwicklung wird zu einem Puffer für Kompromisse zwischen allen Seiten. Die Softwareseite will keine Änderungen durchführen, die Unternehmensseite verlangt sie unbedingt. Die Fachabteilungen können ihre Anforderungen nicht klar formulieren, die Implementierungsseite macht sich nicht die Mühe, nachzufragen, und am Ende muss die Weiterentwicklung als „Notlösung“ dienen. Das ist nicht die Selbstüberhebung einer einzelnen Seite, sondern das Fehlen eines Mechanismus zur Projektsteuerung im gesamten Projekt.
Dahinter steckt noch ein tieferer Grund: Die Anbieter wollen in der Anfangsphase der Implementierung möglichst wenige Weiterentwicklungen durchführen, weil die Grenzkosten standardisierter Produkte niedrig und die Gewinne hoch sind. Die Unternehmen wollen mehr Weiterentwicklungen, um sich an ihren eigenen Geschäftsbetrieb anzupassen. Aber nach der Inbetriebnahme des Systems wünschen sich einige Softwareunternehmen, dass die Unternehmen mehr Weiterentwicklungen durchführen, weil sie damit höhere Gewinne erzielen können – während die Unternehmen zu diesem Zeitpunkt hoffen, die Anforderungen zu niedrigeren Kosten zu erfüllen. Die Interessen beider Seiten stehen also von Natur aus im Widerspruch, sodass Weiterentwicklungsanforderungen zu Verhandlungsmitteln werden, die die jeweilige „Selbstüberhebung“ weiter verstärken.
4. Mehrere Kriterien zur Beurteilung, ob eine Weiterentwicklung angemessen ist
Weiterentwicklung ist weder ein Unheil noch ein Zeichen für Rückständigkeit des Unternehmens. Entscheidend ist, zu unterscheiden, welche Weiterentwicklungen notwendig und wertvoll sind, und welche ineffizient sind und vermieden werden sollten.
Weiterentwicklungen für Compliance und Integration sind in der Regel notwendig. Zum Beispiel spezielle chinesische Formate für Finanzbelege, Schnittstellen für Steuersysteme, Anbindungen an Banken und Anforderungen an die Datensicherheit – das sind zwingende Vorgaben, ohne die das System nicht funktionieren kann.
Kernunterscheidende Fähigkeiten sind Weiterentwicklungen wert. Wenn eine Funktion ein echter Wettbewerbsvorteil des Unternehmens ist – wie eine spezielle Preisengine, das Management von Forschungsprozessen oder individuelle Kundenprozesse – und von Standardsoftware nicht abgedeckt wird, ist die Weiterentwicklung eine strategische Investition und keine Verschwendung.
Man sollte sehr vorsichtig sein, wenn alte Prozesse unverändert in das System übertragen werden. Früher gab es „mündliche Genehmigungen durch die Leitung“, jetzt soll im System ein „beliebig verlaufender“ Genehmigungsworkflow eingerichtet werden; früher gab es manuell geführte Excel-Register, jetzt soll das System die freie Bearbeitbarkeit von Excel vollständig nachbilden. Diese Art von Weiterentwicklung bedeutet, alte Gewohnheiten mit einem neuen System festzuschreiben, und macht den Sinn der Managementverbesserung durch Digitalisierung zunichte.
Was durch Konfiguration gelöst werden kann, erfordert keine Code-Entwicklung. Viele Anforderungen lassen sich durch Parametereinstellungen, Workflows, Berechtigungen, Berichte und Low-Code-Plattformen realisieren, ohne dass eine Code-Weiterentwicklung nötig ist. Die Implementierungspartei hat die Verantwortung, alle Konfigurationsmöglichkeiten auszuschöpfen, bevor sie über Entwicklungen spricht.
Man sollte langfristige Kosten und Aktualisierungsrisiken bewerten. Jede einzelne Weiterentwicklung erhöht den Schwierigkeitsgrad von Systemaktualisierungen. Unternehmen müssen sich bewusst machen: Die Anpassungskosten, die man heute spart, müssen man in Zukunft mit dem Mehrfachen an Aktualisierungskosten zurückzahlen.
5. Wie man aus der „gegenseitigen Arroganz“ herauskommt
Der Streit um die Weiterentwicklung von Standardsoftware lässt sich nicht lösen, indem man Weiterentwicklungen vollständig abschafft oder eine Seite vollständig nachgibt. Stattdessen muss ein Steuerungsmechanismus aufgebaut werden, der angemessene von unangemessenen Anforderungen unterscheidet und Umwandlung sowie Implementierung koordiniert.
Für Software- und Implementierungsparteien: Sie müssen an die Front gehen, die tatsächlichen Geschäftsszenarien verstehen, den Fachabteilungen bei der Übersetzung ihrer Anforderungen helfen und unklare Geschäftssprache in klare Systemregeln umwandeln – das ist genau der Wert von Implementierungsberatern.
Für die Unternehmensseite: Zuerst führt man die Standardisierung des Managements durch, dann geht man zum System über. Wenn die Offline-Prozesse an sich unübersichtlich sind, wird das System nur diese Unübersichtlichkeit automatisieren. Man muss einen Mechanismus zur Steuerung von Anforderungen aufbauen: Für jede Weiterentwicklungsanforderung muss es einen eindeutigen Antragsteller, Bewertungskriterien, Prioritäten und Entscheidungsprozesse geben – es darf nicht die lauteste Stimme entscheiden.
6. Abschließende Zusammenfassung
Aus dem Vorstehenden geht leicht hervor, dass der Satz „Die Weiterentwicklung von Standardsoftware dient immer dazu, die Selbstüberhebung des Auftraggeberunternehmens zu befriedigen“ die Schwachstellen vieler fehlgeschlagener Projekte trifft – aber das Wort „immer“ ist zu absolut. In der Realität gibt es bei der Softwareweiterentwicklung viele kompromisshafte Lösungen mit geringem Wert, aber auch viele notwendige Anforderungen in den Bereichen Compliance, Integration und individuelle Unterscheidung.
Die digitale Umwandlung ist eine organisatorische Veränderung. Die Spannung zwischen Standardisierung und Individualität, Kontrolle und Flexibilität, Technik und Management bricht sich zwangsläufig in den Weiterentwicklungsanforderungen Bahn. Wenn beide Seiten die Arroganz ablegen, „ich habe immer die richtige Antwort zu haben“, und die Weiterentwicklung von einem „gegenseitigen Kompromiss“ zu einer „disziplinierten gemeinsamen Gestaltung“ machen, dann ist die Weiterentwicklung nicht mehr das Ergebnis von Selbstüberhebung, sondern der unvermeidbare Weg für das Wachstum der digitalen Fähigkeiten des Unternehmens.