Wie man zusammenarbeitet: Aufbau einer echten Allianz zwischen Fach- und Technikberatern

(Teil 2 von 5 der Serie „Der menschliche Code der ERP“)

Seien wir ehrlich. Wenn Sie schon einmal an der Implementierung von Unternehmenssoftware beteiligt waren, ist Ihnen wahrscheinlich aufgefallen, dass es oft Spannungen zwischen funktionalen und technischen Beratern gibt.

Zwischen ihnen klafft eine Kluft voller Missverständnisse, passiv-aggressiver E-Mails und verzögerter Projektzeitpläne.

Der einfache Integrationsvorfall

Ich habe schon erlebt, wie Projekte wochenlang zum Stillstand kamen, nur weil zwei Fachleute völlig unterschiedliche Sprachen sprachen.

Stellen Sie sich ein typisches Abstimmungsgespräch vor. Der Fachberater, der gerade von einem Workshop mit dem Kunden kommt, beugt sich vor und sagt: „ Der Kunde muss die Fertigungssoftware mit dem ERP-System synchronisieren. Das ist ganz einfach. Wir müssen lediglich eine einfache Integration mit seinem bestehenden MES erstellen, um die Daten zu übertragen.“

Das Problem besteht darin, dass der Fachberater die Lösung als „einfach“ verkauft, hauptsächlich weil er den Code nicht selbst schreiben muss. Er liefert nur wenige Details und nimmt die technische Umsetzung auf die leichte Schulter, wobei er die damit verbundenen komplexen technischen Herausforderungen völlig unterschätzt.

Für den Berater ist eine Integration lediglich eine konzeptionelle Brücke. Für den Entwickler hingegen stellt dieselbe „einfache Integration“ einen Albtraum aus Payload-Strukturen, Timeout-Fehlern, Sicherheitstoken und fehlenden Datenvalidierungen dar.

Wenn der Entwickler diese Komplexitäten unweigerlich anspricht, entstehen unnötige Reibungspunkte. Der Fachberater wirft dem Entwickler vor, eine Geschäftsanforderung unnötig zu verkomplizieren. Der Entwickler wiederum empfindet die Arbeit des Fachberaters als trivialisiert und dessen Versprechen an den Kunden als unrealistisch.

Tatsächlich birgt die Arbeit als funktionaler Berater Schwierigkeiten, die Entwickler nicht nachvollziehen können, und umgekehrt. Entwickler müssen sich nicht mit den irrationalen Forderungen eines panischen Kunden auseinandersetzen, und funktionale Berater müssen sich nicht in der unerbittlichen Logik der Systemarchitektur zurechtfinden. Beide Berufe sind weder weniger wichtig noch einfacher. Sie stehen lediglich vor einzigartigen Herausforderungen, die der jeweils andere selten zu Gesicht bekommt.

Der wahre Feind in diesem Raum ist das Ego und das fehlende gegenseitige Verständnis.

Willkommen zum zweiten Teil von „Der menschliche Code im ERP-System“. Heute überwinden wir die Silos zwischen denjenigen, die Geschäftsprozesse entwerfen, und denjenigen, die sie tatsächlich umsetzen müssen.

Wir sprechen darüber, wie man eine wasserdichte Allianz zwischen funktionalen und technischen Teams schmiedet.

Zwei Welten, zwei Sprachen

Um diesen Konflikt zu lösen, müssen wir zunächst die Ursache verstehen. Funktionale und technische Berater bewegen sich in zwei völlig unterschiedlichen Welten.

Der funktionale Berater bewegt sich in der unübersichtlichen, unberechenbaren Welt des Geschäftslebens. Er ist in den Produktionshallen präsent. Er sieht den Schweiß der Maschinenbediener. Er muss sich mit den Sorgen des Finanzchefs und den chaotischen, oft unlogischen Arbeitsweisen der Mitarbeiter auseinandersetzen. Sein Ziel ist es, einen reibungslosen Geschäftsablauf zu gewährleisten.

Der technische Berater bewegt sich in einer Welt absoluter, binärer Logik. Eine Datenbanktabelle kümmert sich nicht darum, ob der Lagerleiter einen stressigen Tag hat. Eine Systemarchitektur hingegen verlangt strenge Regeln, präzise Definitionen und absolute Eindeutigkeit. Ihr Ziel ist es, ein stabiles, sicheres und leistungsstarkes System zu schaffen.

Wenn diese beiden Welten ohne einen Vermittler aufeinandertreffen, ist das Desaster vorprogrammiert. Man erhält eine Systemintegration, die zwar technisch einwandfrei ist, aber für die Mitarbeiter in der Produktion völlig nutzlos, da sie die physikalischen Verzögerungen beim Palettentransport durch Gabelstapler nicht berücksichtigt.

Der Mythos des technischen Beraters

Es herrscht der weitverbreitete Irrglaube, dass ein funktionaler Berater programmieren lernen müsse, um diese Lücke zu schließen. Das ist völlig falsch. Ein hervorragender funktionaler ERP-Berater muss weder Skripte programmieren noch komplexe SQL-Abfragen schreiben können.

Sie müssen jedoch unbedingt wissen, wie ein System denkt.

Sie müssen nicht wissen, wie man die API-Nutzdaten schreibt. Sie müssen jedoch verstehen, dass ein System beim Senden einer Nachricht eine bestimmte Antwort erwartet und dass Sie einen Geschäftsprozess für den Fall entwerfen müssen, dass diese Antwort ausbleibt. Sie müssen den Unterschied zwischen einer Stammdatentabelle und einer Transaktionstabelle kennen. Sie müssen die grundlegenden Gesetze der Systemarchitektur verstehen.

Ihre eigentliche Aufgabe als funktionaler Berater ist es, als Vermittler zwischen Mensch und Technik zu fungieren. Sie sind die Brücke, kein Programmierer. Sie müssen die oft chaotischen und emotionalen Bedürfnisse des Unternehmens in klare, logische Rahmenbedingungen übersetzen, mit denen Entwickler tatsächlich arbeiten können.

Schutz der Schützengräben

Der schlimmste Typ von Fachberater ist der blinde Ausführende. Dieser Berater kümmert sich nicht wirklich um die tatsächlichen Geschäftsanforderungen. Er führt Befehle wie ein Soldat aus, hört sich unlogische oder völlig unrealistische Anpassungswünsche des Kunden an, notiert sie wortwörtlich und gibt sie direkt an das Entwicklerteam weiter, ohne zu hinterfragen, ob sie überhaupt Sinn ergeben.

Die moderne Architektur von CloudSuite verhindert zwar, dass die Datenbank tatsächlich beschädigt wird, doch Benutzer fordern weiterhin Änderungen, die der Standardlogik des Systems völlig widersprechen. Wenn der Entwickler dann unweigerlich darauf hinweist, dass die Anfrage technisch absurd ist, zuckt dieser Beratertyp nur mit den Achseln und sagt: „Geben Sie mir nicht die Schuld. Das ist der Wunsch des Kunden.“

Dieses Verhalten zerstört mit der Zeit das Vertrauen. Es lässt das technische Team im Stich.

Ein echter Berater fungiert als Schutzschild. Es ist Ihre Aufgabe, zu erkennen, ob eine Anfrage völlig unrealistisch ist, bevor Sie sie an die IT-Abteilung weitergeben. Sie müssen die in Teil 1 besprochenen „Fünf Warum“-Methoden anwenden und den tatsächlichen Geschäftsbedarf ermitteln.

Wenn der Entwickler Schwierigkeiten bei der Umsetzung einer Anforderung hat, genügt es nicht, einfach auf die Spezifikation zu verweisen und Ergebnisse zu fordern. Stattdessen arbeitet man eng mit ihm zusammen. Gemeinsam wird untersucht, ob die technische Einschränkung objektiv begründet ist. Sollte dies der Fall sein, muss man vermitteln und erneut mit dem Kunden verhandeln, um einen Kompromiss zu finden.

Kunden verwenden gern den klassischen Satz: „In der IT ist alles möglich.“ Sie müssen Ihr technisches Team vor dieser Denkweise schützen, denn so funktioniert die Realität nicht. Wir entwickeln keine Kernprozesse von Grund auf neu. Wir erweitern Standardfunktionen.

Wenn Entwickler erkennen, dass Sie als Kontrollinstanz fungieren, unbrauchbare Inhalte aussortieren und sie vor unerfüllbaren Versprechen schützen, werden sie Sie respektieren. Sie werden aufhören, sich gegen Ihre Wünsche zu wehren und stattdessen an Ihren Lösungen mitarbeiten.

Die Hitze aushalten

Funktionale Berater beklagen oft eine ganz bestimmte Dynamik. Wenn ein benutzerdefiniertes Skript fehlschlägt oder ein System abstürzt, sitzt der technische Berater sicher hinter seinem Monitor. Derweil muss der funktionale Berater in einem Besprechungsraum sitzen, einem verärgerten Kunden in die Augen sehen und erklären, warum die neu implementierte Anpassung nicht wie erwartet funktioniert. Es fühlt sich unglaublich unfair an, die Schuld für einen technischen Fehler zu tragen, den man nicht verursacht hat.

Ob es Ihnen gefällt oder nicht: Die Schnittstelle zwischen dem technischen Team und dem Kunden zu sein, ist genau Ihre Aufgabe. Sie sind die Brücke. Sich darüber zu beschweren, mit dem Kunden zu sprechen, ist, als würde man sich mit einem Schutzschild beschweren, getroffen zu werden.

Der Schlüssel zu einem erfolgreichen Projekt liegt in gegenseitiger Unterstützung. Eine starke Partnerschaft bedeutet, dass man sich gegenseitig den Rücken stärkt. Der fachliche Berater fängt die negativen Auswirkungen ab, trägt die Kritik und bewältigt die Frustration des Kunden, um wertvolle Zeit zu gewinnen. Diese Dynamik funktioniert nur, wenn der Entwickler ihn unterstützt.

In einer echten Partnerschaft ist der Entwickler bereits informiert und arbeitet im Hintergrund an einer Lösung, sobald der Berater den angespannten Besprechungsraum betritt. Sie schützen den Entwickler vor der Panik des Kunden, und der Entwickler sichert Ihre Glaubwürdigkeit, indem er den Fehler schnell behebt.

Das Allianz-Handbuch

Wie verwandelt man eine feindselige IT-Abteilung in seinen größten Verbündeten? Hier sind drei praktische Regeln, die Sie in Ihrem nächsten Projekt anwenden sollten, um eine echte Partnerschaft aufzubauen.

1. Schreiben Sie Binärspezifikationen, keine Romane

Entwickler hassen Mehrdeutigkeiten wie nichts anderes. Schreiben Sie niemals eine Funktionsspezifikation, die besagt: „Das System soll den Status automatisch aktualisieren und den Benutzer benachrichtigen.“ Das ist ein Roman, keine Spezifikation. Schreiben Sie stattdessen in Binärlogik. Geben Sie genau an, welcher Auslöser das Ereignis auslöst. Definieren Sie genau, welches Tabellenfeld sich von Status A auf Status B ändern muss.

Klären Sie genau, was die Benachrichtigung beinhalten soll und wer der genaue Empfänger ist. Vermeiden Sie Adjektive und ersetzen Sie sie durch präzise Formulierungen. Wenn Ihre Spezifikation Raum für Interpretationen lässt, ist sie mangelhaft. Selbst kleinste Details müssen in einer formalen Analyse festgehalten und kommuniziert werden. Ein kurzes Abstimmungsgespräch zur Überprüfung dieser Details kann entscheidend dazu beitragen, eine gemeinsame Sprache zu entwickeln.

2. Erläutern Sie in der Analyse stets das „Warum“

Bei der Erstellung Ihrer funktionalen Spezifikation müssen Sie die geschäftlichen Beweggründe für die Anforderung klar erläutern. Behandeln Sie den Entwickler nicht nur als bloßen Code-Ausführer. Genau wie funktionale Berater benötigen Entwickler den vollständigen Kontext der Anforderung. Sie müssen verstehen, woran sie arbeiten, aber vor allem, warumsie es tun. Geben Sie ihnen nicht einfach nur eine technische Anweisung.

Erläutern Sie das geschäftliche Problem. Sagen Sie beispielsweise: „ Die Lagerarbeiter geben diese Zahl derzeit 500 Mal täglich manuell ein, was zu Lieferverzögerungen führt. Wir müssen dieses Feld automatisieren, um ihnen zwei Stunden pro Schicht zu ersparen.“ Wenn ein Entwickler den Kontext und die Auswirkungen seines Codes auf die Nutzer versteht, wandelt er sich von einem reinen Auftragsbearbeiter zu einem aktiven Partner, der möglicherweise eine deutlich bessere technische Lösung vorschlägt, als Sie ursprünglich geplant hatten.

3. Beziehen Sie sie in die Reise mit ein

In den meisten Projekten reist der Fachberater zum Kunden und nimmt an den wichtigen Meetings teil. Diese Dynamik führt oft dazu, dass die Entwickler im Backoffice isoliert sind. Wer wirklich im Team arbeiten will, muss es richtig angehen. Es reicht nicht, die technischen Kollegen nur dann zu kontaktieren, wenn eine konkrete Programmieraufgabe zu vergeben ist, ohne den größeren Kontext zu erläutern.

Sie müssen ihnen das Gefühl geben, ein integraler Bestandteil des Gesamtprojekts zu sein. Nutzen Sie die Gelegenheit, regelmäßig mit ihnen zu sprechen und sie über aktuelle Entwicklungen beim Kunden, Projektänderungen und die allgemeine Atmosphäre auf dem Laufenden zu halten. Durch diese kontinuierliche Einbindung wird sichergestellt, dass sie sich aktiv einbringen. Wenn Entwickler das Gesamtbild verstehen und sich als Teil des Prozesses fühlen, werden sie nicht länger nur Ausführende, sondern zu echten Projektpartnern. Ein Projekt, in dem ein Fachberater und ein Entwickler Hand in Hand arbeiten, wird zweifellos hervorragende Ergebnisse sowohl für das Projekt als auch für die tägliche Arbeit beider Beteiligten liefern.

Die Allianz in den Schützengräben

Die Entwicklung einer kundenspezifischen Erweiterung oder die Integration externer Software in ein ERP-System ist nie nur eine Frage des Schreibens von Codezeilen. Es ist ein Akt der menschlichen Kommunikation.

Die beste technische Architektur der Welt wird scheitern, wenn die Prozessentwickler und die Entwickler der Logik einander nicht verstehen. Indem wir unser Ego zurückstellen, klar kommunizieren und die Zeit des anderen respektieren, können wir diesen endlosen Streit beenden und endlich Software entwickeln, die wirklich etwas bewirkt.

Ein erfolgreicher Go-Live hängt maßgeblich von der unauflöslichen Zusammenarbeit zwischen einem funktionalen und einem technischen Berater ab. Beide können allein nicht erfolgreich sein.

Als Nächstes: Wie man die am meisten unterschätzte Fähigkeit in der Beratungsbranche entwickelt. Wir werden die Bedeutung von Neugier gegenüber einem enzyklopädischen Gedächtnis untersuchen.

Verfasst von Andrea Guaccio 

7. Mai 2026