Wenn ein Tool alles kann, kann es nichts richtig. Ob Monday, Atlassian, Zoho oder Notion \u2013 kein Tool kann alles. Es ist wirklich ein M\u00e4rchen. Salesforce, SAP und Dynamics k\u00f6nnen das, weil sie keine Tools, sondern ganze Landschaften darstellen, mit ihren eigenen formalen Sprachen, f\u00fcr die man eigene Experten braucht.<\/p>\n
Die Punchline: Jedes Universaltool m\u00fcsste den Weg von SAP und Co ab einem gewissen Punkt gehen um mit der Komplexit\u00e4t Schritt halten zu k\u00f6nnen, die ein ernsthaftes Unternehmenswachstum eben mit sich bringt. Wenn es das nicht tut, ignoriert es Anforderungen und das riskiert das gesamte Gesch\u00e4ft.<\/p>\n
Wir richten ein CRM ein, um Kunden zu gewinnen. Um zu liefern brauchen wir eine Funktion f\u00fcr die Abwicklung: Kanbanboards oder Ticketsysteme. Abgeschlossene Auftr\u00e4ge sollen im Servicedesk landen.<\/p>\n
Alles in einem Tool. Das wirkt effizient. <\/p>\n
Wir werden im Folgenden sehen, dass es verschiedene Gr\u00fcnde gibt, warum das nicht so einfach ist. <\/p>\n
Mehr Kunden, mehr Prozesse, mehr Abteilungen, mehr Entscheidungen. Sobald ein Unternehmen w\u00e4chst, wachsen nicht nur die Prozesse.<\/p>\n
\u201eGenau\u201c, k\u00f6nnte man jetzt sagen, \u201edeswegen ist es doch besser, alles in einem Tool zu lassen.\u201c\nDoch an dem Punkt besteht ein Prozess nicht mehr aus 3 Schritten, sondern aus 30.\nEs gibt nicht mehr 7 Prozesse, sondern 24. Es gibt Ausnahmen, Sonderf\u00e4lle von Ausnahmen und Abh\u00e4ngigkeiten.<\/p>\n
Der Anbieter versucht nun das alles innerhalb einer Anwendung abzubilden. Um das zu k\u00f6nnen, braucht das Tool Mechanismen zur Beherrschung der Komplexit\u00e4t und das f\u00fchrt automatisch zu irgendeiner Form von Regeln, Logiken, Abl\u00e4ufen. Sie nennen es dann Workflows oder \u00e4hnlich, um zu suggerieren damit die Komplexit\u00e4t beherrschen zu k\u00f6nnen ohne sich mit Technik, mit Programmierung besch\u00e4ftigen zu m\u00fcssen. Und doch sind es immer noch Abl\u00e4ufe. Entscheidungsb\u00e4ume. Eben eine Programmiersprache nur in visueller Form und l\u00e4ngst nicht so m\u00e4chtig. Daher scheinen sie einfacher. Der CEO findet sich nun wieder, wie er komplizierte Abl\u00e4ufe zusammenst\u00f6pselt und mit Herausforderungen konfrontiert wird, mit denen sich sonst Softwareentwickler besch\u00e4ftigen und dar\u00fcber hinaus: Mit in diesen kastrierten visuellen Programmablaufpl\u00e4nen unl\u00f6sbaren Anforderungen. Margenoptimierte Angebotskalkulation? Regelbasierte Angebotserstellung? Keine Chance.<\/p>\n
F\u00fcr so eine All-Purpose-Anwendung gibt es zwei Wege sich zu entwickeln: Erstens bleibt sie auf diesem Weg und l\u00e4sst 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\u00f6nnen. Zweitens: Die All-Purpose-Anwendung schl\u00e4gt den Weg von SAP und Microsoft Dynamics ein und stellt eine Schicht zur Verf\u00fcgung, in der das Unternehmen die Komplexit\u00e4t nun formal bew\u00e4ltigt.<\/p>\n
Leugnen ist keine L\u00f6sung. 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\u00dferhalb der Universalanwendung durchgef\u00fchrt und damit hat man bereits die Pr\u00e4misse gebrochen: Es ist in dem Moment keine Universalanwendung mehr.<\/p>\n
Und wenn die All-Purpose-Anwendung den SAP-Weg geht: Es f\u00fchrt sich selbst automatisch ad absurdum, denn man wollte eine Universalanwendung damit man nicht programmieren muss und bekommt eine Universalanwendung, f\u00fcr die man eigens spezialisierte Entwickler (ABAP-Entwickler, kurz f\u00fcr \u201eAdvanced Business Application Programming\u201c) finden muss. Gleiches gilt f\u00fcr Dynamics von Microsoft und alle anderen.<\/p>\n
Ganz einfach: SAP und Co l\u00f6sen das Problem – das ist nicht das Schlechteste. Sie kommen auch mit einem Vendor-Lock-In. Wer einmal im \u00d6kosiystem 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\u00e4ngt dann nochmal von dem Entwickler ab, der es umsetzt.<\/p>\n
Und der Knackpunkt den ich pers\u00f6nlich 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\u00e4ftigt. Das ist sicher nicht der Typ, der mal schnell mit einer L\u00f6sung durch die T\u00fcr kommt um ein Problem zu l\u00f6sen. Aber den braucht es. Denn auch der muss wieder von SAP zertifiziert sein und die Kosten daf\u00fcr gibt er nat\u00fcrlich auch an den Kunden weiter.<\/p>\n
Es kann auch sein, dass eine der All-Purpose-L\u00f6sungen, die wir oben hatten, f\u00fcr 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\u00f6glicht. So kann in dem Moment, in dem die integrierte Ticketl\u00f6sung nicht mehr ausreicht, eine spezialisierte Ticketl\u00f6sung an den Orchestrator angeschlossen werden und die interne L\u00f6sung ab diesem Zeitpunkt \u00fcberbr\u00fcckt werden.<\/p>\n
Der Tausch ist damit in der IT-Strategie des wachsenden Unternehmens eingeplant und ohne gro\u00dfen Aufwand m\u00f6glich. Modular. Plug and Play.<\/p>\n
Nach dem selben Prinzip kann auch vollst\u00e4ndig mit verschiedenen, passgenauen Tools je Dom\u00e4ne des Unternehmens gearbeitet werden: Recruitment, Marketing, Sales, Fulfillment, Delivery, Entwicklung, Rechnungswesen etc.<\/p>\n
V\u00f6llig unabh\u00e4ngig vom Anbieter. Au\u00dferdem bleibt jedes Modul austauschbar und die Abh\u00e4ngigkeit des Unternehmens von einem Anbieter verschwindet vollst\u00e4ndig.<\/p>\n
Sobald ganz spezifische Anforderungen an Prozesse kommen, k\u00f6nnen auch Individualanwendungen integriert werden. <\/p>\n
Es kann also sein, dass alle Steuerberater die gleiche Anwendungen nutzen k\u00f6nnen, 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\u00e4ftsmodell konzipierte Prozessen geben. Dann braucht es Erweiterbarkeit, Individualit\u00e4t, Skalierbarkeit.<\/p>","protected":false},"excerpt":{"rendered":"
Wenn ein Tool alles kann, kann es nichts richtig. Ob Monday, Atlassian, Zoho oder Notion \u2013 kein Tool kann alles. Es ist wirklich ein M\u00e4rchen. Salesforce, SAP und Dynamics k\u00f6nnen das, weil sie keine Tools, sondern ganze Landschaften darstellen, mit ihren eigenen formalen Sprachen, f\u00fcr die man eigene Experten braucht. Die Punchline: Jedes Universaltool m\u00fcsste […]<\/p>","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[207],"tags":[],"class_list":["post-1026","post","type-post","status-publish","format-standard","hentry","category-analysen"],"yoast_head":"\n