Prozesse versus Technologie in Unternehmen

Um jedoch konkret programmieren zu können, müssen alle Funktionen sehr exakt beschrieben werden. Daten können nur genauso und nicht „irgendwie“ manipuliert werden. Ein klassisches Spannungsverhältnis zwischen konkreten Prozessen und theoretischen Möglichkeiten. Ein weiteres Mal begegnet uns diese Herausforderung bei der Einführung von bereits programmierten Lösungen — warum eigentlich?

Es vergeht kein Tag an dem nicht ein neues Tool, meist in Form einer SaaS-Anwendung, das Licht der Welt erblickt. Programme, die den Arbeitsalltag oder sogar das Leben verändern bzw. erleichtern sollen. Und je nachdem welcher Hype gerade durch die digitalen Dörfer getrieben wird, springen Firmen und Privatpersonen aus den unterschiedlichsten Gründen auf die fahrenden Züge. Egal ob Cloudspeicher, virtueller Datenraum, Projektmanagement-Tools, Collaboration-Lösungen, Time-Tracker, Marketing-Automatisierung, RPA-Lösung, ERP- oder CRM-Systeme. Leider werden bei der Einführung oder dem Wechsel auf eine neue Lösung immer öfter die wirklichen Anforderungen der Mitarbeiter außer Acht gelassen und stattdessen auf einen Feature-Wettlauf, Gartners Magic Quadrant¹, den Forrester Wave² Report oder auch ganz neu auf CBInsights’ NExTT³ gesetzt. Oft mit dem Ergebnis neu=nicht unbedingt besser. Dass sich all die zuvor genannten Bewertungsmethoden der Marktanalysten bei der 2x2 Eisenhower Matrix⁴ zumindest inspirieren ließen, erklärt die Ähnlichkeit der Systeme.

—

In einer anderen Beobachtung sichern innerhalb von modernen Unternehmen vor allem zwei Aspekte den Erfolg: hoch-motivierte Mitarbeiter und ihr individueller Einsatz sowie sehr gute, etablierte Prozesse. Ohne in die wissenschaftliche Tiefen von Prozessen einsteigen zu wollen, bedeuten eingeführte und gelebte Prozesse fixierte Abläufe bei bestimmten Ereignissen, ohne wenn — wie beispielsweise personenabhängiges Herrschaftswissen — und aber in Form von zahllosen Ausnahmeregelungen, die keinen nachvollziehbaren Schemata mehr folgen. Gleichzeitig kennen wir alle Unternehmen, in denen scheinbar das Chaos dominiert und die Rufe nach mehr Struktur mal lauter, mal leiser zu hören sind. Das gilt im Besonderen für Organisationen, die massives Wachstum erfahren. Und so entsteht oft die Versuchung (und oft auch der tatsächliche Versuch) mit mehr Technologie die aufkommenden Prozess-Löcher zu stopfen. Ein weiteres Tool für Aufgabe X und Y soll die Wende bringen. Andere Unternehmen kommen mit weniger aus. Warum? Die magischen Zauberworte heißen schriftlich definierte Prozesse für alle wiederkehrenden Situationen. Für wachsende Unternehmen ist es jedoch mitunter schwer zu erkennen, welche Situationen sich wiederholen werden und welche nicht wieder passieren sollten.

In der Zwischenzeit sollen agile Unternehmensstrukturen die Lösung bringen — egal, ob in den Geschmacksrichtungen Leanes Startup, Agile in den Formen von Scrum, Kanban oder einem Mix der inzwischen hinreichend bekannten Methoden. Ganz gewagt greifen Unternehmen zu einer Holacracy und versuchen in der Zusammenarbeit ausschließlich auf cross-funktionale Teams auf jeder Ebene zu setzen.

Für einen Teil der geschäftlichen Herausforderungen können diese Ansätze durchaus sinnvoll sein. Vor allem im Rahmen von Innovationsthemen, bei denen das Ziel noch nicht wirklich klar ist oder der Aufwand das endgültige Ergebnis zu bestimmen definitiv zu groß wäre. Aber in einem M&A Vorgang? In der Buchhaltung? Oder auch beim Erstellen einer Preiskalkulation?

Nach meiner Einschätzung müssen Unternehmen und auch Manager, die vor Herausforderungen dieser Art stehen, besser erkennen, dass nicht jede Herausforderung ein Nagel ist, der mit einem Agile-Hammer versenkt werden kann. Gleiches gilt für die Einführung von Software. Nur weil in CIO Kreisen eine weitere SaaS-Lösung als must have diskutiert wird, löst deren Einführung in den seltensten Fällen die zugrunde liegende Fragestellung bzw. Herausforderung.

Aber wie können wir in Zukunft in solchen Situationen effektiver zu einer Lösung kommen? Nach meiner Ansicht ist es wichtig zu erkennen, was für eine Herausforderung überhaupt adressiert werden soll. Wenn davon ausgegangen werden kann, dass ein Unternehmen dieses Problem bereits gelöst hat — warum nicht einfach mal fragen? Auch wenn dies bezahltes Consulting in Form von ein paar Tagessätzen bedeutet, wird der Know-How Transfer von Best Practices meistens schneller und somit günstiger sein als das eigene Trial & Error Vorgehen.

Zusätzlich lohnt es sich genauer zu verstehen, ob die zu lösende Aufgabe in einer der vier Gruppen einfach, kompliziert, komplex oder chaotisch kategorisiert werden kann. Leser, die schon ein wenig länger im IT- und Beratungsgeschäft unterwegs sind, wissen worauf ich abziele: die Cynefin Framework⁵. Entwickelt von Dave Snowden im Rahmen seiner Tätigkeit bei IBM Global Services in den 1990ern. Inzwischen vermarket er das Gedankenmodell selbst⁶ und auch Axelos sieht in seinem PRINCE2 Agile Kursen⁷ eine gewinnbringende Unterstützung durch dieses Framework.

Um die im Mittelpunkt stehende Aufgabe („Disorder“) zu verstehen, soll erkannt werden, ob diese mit Best Practices gelöst werden kann. Nach diesem Modell würde es sich um eine „einfache“ Aufgabe handeln. Bei komplizierten Aufgaben wird hingegen auf good Practices, nicht zu verwechseln mit den Best Practices bei einfachen Aufgaben, gesetzt. Das Ziel ist nicht von Anfang vollständig zu überblicken, aber eine konkretes Abarbeiten von bereits bekannten Schritten macht die Lösung sichtbar. Hingegen erfordern komplexe Aufgaben, die uns immer häufiger begegnen, ein sachverständiges Probieren, um die Aufgabe zu bewältigen. Chaotische Aufgaben, die letzte Kategorie, haben keinen leicht erkennbaren sinnvollen Ansatz. Hier führt reines Handeln und anschließendes Neubewerten zu einer Lösung. Ziel der Cynefin Matrix ist es, Aufgaben und Herausforderung auf das nächst leichtere Level zu bringen. Anschließend kann das Zielvorgehen dokumentiert und in einen weiteren Prozess gegossen werden.

Die große Herausforderung im Rahmen solcher Frameworks ist oft, dass das individuelle Fähigkeitenlevel über die Einstufung entscheidet. Aufgaben, die für einen Senior Consultant mit 10 Jahren Erfahrung im Höchstfall kompliziert sind, dürften bei Neulingen zu chaotischen Angstgefühlen führen. Auch hier gilt der Hinweis von zuvor: Abstand nehmen und sich hinterfragen, ob diese Aufgabe nicht schon mal gelöst worden ist.

Im Idealfall ist die Herausforderung nun bekannt und es wurde gegebenenfalls erkannt, dass diese gar nicht so neuartig ist und professionelle Hilfe schnell Klarheit bringen kann. Anschließend wurde ein kleiner Prozess definiert, gelebt und verbessert. Ab jetzt kann es sich lohnen, einen Blick in die Technik-Wunderkiste zu werfen: Gibt es hilfreiche Lösungen wie Projektmanagement-Tools, die diesen Prozess zumindest unterstützen können? Interessant könnten auch Tools wie Box Relay⁸ sein, um event-gesteuerte Prozessabläufe auf Dateiebene direkt vorzugeben. Wenn es um technische Lösungen, wie dem Übertrag von Daten aus zweite Systemen geht, lohnt auch ein blick auf die lange Liste der sogenannten API Broker bzw. iPaaS Lösungen (Integration Platform as a Service).

Anbieter von diesen API Services wie beispielsweise Zapier oder aus dem heimischen Bereich bekannte Lösungen wie IFTTT nutzen die Public REST APIs der zu verbindenden Dienste und bieten mal mehr und mal weniger die Möglichkeit, die aus den Diensten gezogen Daten zu manipulieren und dann an ein anderen Dienst weiter zu geben. In der Regel arbeiten die Automatisierer mit sogenannten Webhooks. Diese rufen die API Broker automatisch auf, sobald ein Trigger-Event im ersten Dienst ausgelöst wird und stellen dann die entsprechenden Abfragen an alle in der jeweiligen Automatisierung hinterlegten Dienste.

Im Gegensatz zu eigenen Entwicklungen muss sich um den Betrieb der Automatisierung keine Gedanken gemacht werden. Auf der anderen Seite fehlt es bei den Lösungen meist um granulare Einstellungsmöglichkeiten für Frequenz oder Monitoring.

Auch große Unternehmen wie die aus Deutschland stammende Software AG oder Apple haben den Wert von diesen Lösungen erkannt. So kaufte die Software AG bereits im letzten Jahr built.io⁹ und der italienische API Broker Stamplay ging vor wenigen Wochen an Apple¹⁰.

Der Erfahrung nach lassen sich mit API Brokern sehr schnell und gute Prototypen von technischen Automatisierungen bauen. Sobald jedoch tiefer in Details wie Geschwindigkeit und Frequenz der Datenabgleiche mit Taskmanagern, Message Brokern, Queing und Monitoring eingestiegen werden muss, landet man doch bei der eigenen Lösung. Gleiches gilt, wenn die zu verschaltenden Systeme nicht im Verhältnis 1:1 miteinander verbunden und Zwischendatenbanken notwendig werden. Wenn die geplante Automatisierung aber diesen Grad an „Komplexität“ angenommen hat, ist die eigene Entwicklung für genau diesen Use Case nicht mehr weit.

—

Es liegt auf der Hand, dass die perfekte Kombination aus rock solid Prozessen und bester Technologie — am besten hoch individualisiert — den wünschenswerten Idealzustand bedeutet. In der Zwischenzeit kann den meisten Unternehmen allerdings mit einem Fokus auf die zu Grunde liegenden Prozesse geholfen werden. Denn gute und vor allem definierte & dokumentierte Prozesse sind die Grundlage für jede Automatisierung. Erst manuell mit Checklisten, die aus einer herausfordernden, komplexen Aufgabe eine Angelegenheit für den mentalen Autopiloten werden lässt, später Tool-begleitet mit einer der vielen SaaS-Lösungen, die nach dem Pareto-Prinzip¹¹ 80 Prozent der Aufgabe abdecken und schlussendlich full fledged automatisiert mit einer im DevSecOps Modus betriebenen und entwickelten individuellen Software Lösung. Das Entwickler-Team wird sich über die erste Checkliste extrem freuen, denn diese wird das Gros der Requirements, User Stories oder die Inhalte für die etwas angestaubten Lasten- und Pflichtenhefte bereits enthalten. Am Anfang war vielleicht das Chaos, dann folgt hoffentlich der Prozess, welcher das Chaos ordnet. Am Ende darf eine passende Software-Lösung den Ablauf perfektionieren.

This content is only available in German

Prozesse versus Technologie in Unternehmen