Wenn ein Tool alles kann, kann es nichts richtig. Ob Monday, Atlassian, Zoho oder Notion – kein Tool kann alles. Es ist wirklich ein Märchen. Salesforce, SAP und Dynamics können das, weil sie keine Tools, sondern ganze Landschaften darstellen, mit ihren eigenen formalen Sprachen, für die man eigene Experten braucht.

Die Punchline: Jedes Universaltool müsste den Weg von SAP und Co ab einem gewissen Punkt gehen um mit der Komplexität Schritt halten zu können, die ein ernsthaftes Unternehmenswachstum eben mit sich bringt. Wenn es das nicht tut, ignoriert es Anforderungen und das riskiert das gesamte Geschäft.

Am Anfang funktioniert alles

Wir richten ein CRM ein, um Kunden zu gewinnen. Um zu liefern brauchen wir eine Funktion für die Abwicklung: Kanbanboards oder Ticketsysteme. Abgeschlossene Aufträge sollen im Servicedesk landen.

Alles in einem Tool. Das wirkt effizient.

Wir werden im Folgenden sehen, dass es verschiedene Gründe gibt, warum das nicht so einfach ist.

Dann wächst das Unternehmen richtig

Mehr Kunden, mehr Prozesse, mehr Abteilungen, mehr Entscheidungen. Sobald ein Unternehmen wächst, wachsen nicht nur die Prozesse.

„Genau“, könnte man jetzt sagen, „deswegen ist es doch besser, alles in einem Tool zu lassen.“ Doch an dem Punkt besteht ein Prozess nicht mehr aus 3 Schritten, sondern aus 30. Es gibt nicht mehr 7 Prozesse, sondern 24. Es gibt Ausnahmen, Sonderfälle von Ausnahmen und Abhängigkeiten.

Der Anbieter versucht nun das alles innerhalb einer Anwendung abzubilden. Um das zu können, braucht das Tool Mechanismen zur Beherrschung der Komplexität und das führt automatisch zu irgendeiner Form von Regeln, Logiken, Abläufen. Sie nennen es dann Workflows oder ähnlich, um zu suggerieren damit die Komplexität beherrschen zu können ohne sich mit Technik, mit Programmierung beschäftigen zu müssen. Und doch sind es immer noch Abläufe. Entscheidungsbäume. Eben eine Programmiersprache nur in visueller Form und längst nicht so mächtig. Daher scheinen sie einfacher. Der CEO findet sich nun wieder, wie er komplizierte Abläufe zusammenstöpselt und mit Herausforderungen konfrontiert wird, mit denen sich sonst Softwareentwickler beschäftigen und darüber hinaus: Mit in diesen kastrierten visuellen Programmablaufplänen unlösbaren Anforderungen. Margenoptimierte Angebotskalkulation? Regelbasierte Angebotserstellung? Keine Chance.

Der kritische Punkt: Komplexität lösen oder leugnen

Für so eine All-Purpose-Anwendung gibt es zwei Wege sich zu entwickeln: Erstens bleibt sie auf diesem Weg und lässt den Unternehmer, mit dem unzureichenden Instrumentarium allein. Hier liegt das unternehmerisch Risiko. In diesem Punkt entscheidet sich, ob die Unternehmensprozesse beherrschbar werden und abgearbeitet können. Zweitens: Die All-Purpose-Anwendung schlägt den Weg von SAP und Microsoft Dynamics ein und stellt eine Schicht zur Verfügung, in der das Unternehmen die Komplexität nun formal bewältigt.

Leugnen ist keine Lösung. Man kann in Workflows, also in vereinfachten Wenn-Dann-Maschinen, keine smarten Logiken realisieren. D.h. man muss sie irgendwie an einen Prozess auslagern, den doch wieder irgendjemand programmieren muss. Diese Berechnungen und Entscheidungen werden dann in einem Service außerhalb der Universalanwendung durchgeführt und damit hat man bereits die Prämisse gebrochen: Es ist in dem Moment keine Universalanwendung mehr.

Und wenn die All-Purpose-Anwendung den SAP-Weg geht: Es führt sich selbst automatisch ad absurdum, denn man wollte eine Universalanwendung damit man nicht programmieren muss und bekommt eine Universalanwendung, für die man eigens spezialisierte Entwickler (ABAP-Entwickler, kurz für „Advanced Business Application Programming“) finden muss. Gleiches gilt für Dynamics von Microsoft und alle anderen.

Die Lösung: Es braucht einen Orchestrator

Ganz einfach: SAP und Co lösen das Problem – das ist nicht das Schlechteste. Sie kommen auch mit einem Vendor-Lock-In. Wer einmal im Ökosiystem ist, kommt nicht leicht wieder raus. Und wer SAP dann werden sehr teure Lizenzen immer teuerer, bekommt letztlich aber nur vorgefertigte Masken. Ob das Zusammenspiel funktioniert, hängt dann nochmal von dem Entwickler ab, der es umsetzt.

Und der Knackpunkt den ich persönlich als entscheidendes Gegenargument gegen SAP sehe: Es muss schon ein ganz spezieller Charakter sein, der sich mit etwas, das als Advanced Business Application Programming bezeichnet wird, beschäftigt. Das ist sicher nicht der Typ, der mal schnell mit einer Lösung durch die Tür kommt um ein Problem zu lösen. Aber den braucht es. Denn auch der muss wieder von SAP zertifiziert sein und die Kosten dafür gibt er natürlich auch an den Kunden weiter.

Es kann auch sein, dass eine der All-Purpose-Lösungen, die wir oben hatten, für die aktuellen Zwecke bis auf wenige Anforderung ausreicht. Dann muss man mit einem Orchestrator vorgehen. Nehmen wir das Beispiel mit der Buchhaltungssoftware, die keine All-Purposeanwendung eingebaut haben kann: Dann ist es wichtig hier bereits zwischen diesen beiden Anwendungen einen Orchestrator zwischenzuschalten, der dann im weiteren Wachstum des Unternehmens die Skalierung einfach, sogar ohne Downtimes wenn man es richtig macht, ermöglicht. So kann in dem Moment, in dem die integrierte Ticketlösung nicht mehr ausreicht, eine spezialisierte Ticketlösung an den Orchestrator angeschlossen werden und die interne Lösung ab diesem Zeitpunkt überbrückt werden.

Der Tausch ist damit in der IT-Strategie des wachsenden Unternehmens eingeplant und ohne großen Aufwand möglich. Modular. Plug and Play.

Nach dem selben Prinzip kann auch vollständig mit verschiedenen, passgenauen Tools je Domäne des Unternehmens gearbeitet werden: Recruitment, Marketing, Sales, Fulfillment, Delivery, Entwicklung, Rechnungswesen etc.

Völlig unabhängig vom Anbieter. Außerdem bleibt jedes Modul austauschbar und die Abhängigkeit des Unternehmens von einem Anbieter verschwindet vollständig.

Sobald ganz spezifische Anforderungen an Prozesse kommen, können auch Individualanwendungen integriert werden.

Fazit

Es kann also sein, dass alle Steuerberater die gleiche Anwendungen nutzen können, aber sobald ein Unternehmen in irgendeiner Form einen USP anstrebt, also macht, was sonst niemand macht, schlicht sich eine Position erarbeitet, wird es individuell auf das Geschäftsmodell konzipierte Prozessen geben. Dann braucht es Erweiterbarkeit, Individualität, Skalierbarkeit.