Leistungen+
EN DEKontakt
In der Beratung werden diese Entscheidungen im Zusammenhang getroffen, auch die Strategie. Plattformstrategie, KI-Strategie und die Frage, wie sich Vertrieb, Service und Delivery-Organisation für eine neue Arbeitsweise aufstellen müssen, gehören in dasselbe Gespräch und nicht in ein zusätzliches.
Schlechte Entscheidungen über Veränderung treffen die wenigsten Unternehmen. Meist sind es fünf vernünftige Entscheidungen, nur fallen sie in fünf getrennten Räumen.
Es geht um das angestrebte Ergebnis, um die Verantwortung dafür, um den Ablauf der Arbeit, um die Frage, welches System wofür führend ist, und um das, was die Regeln verlangen. Jede dieser Entscheidungen ist für sich gut begründet. Zusammen passen sie aber oft nicht. Das fällt erst in der Umsetzung auf, und zwar denen, die es nicht beheben können.
Wählen Sie den Satz, der Ihre Lage am besten beschreibt. Jeder führt zu dem Angebot, mit dem sich diese Frage klären lässt. Eine frühere Zusammenarbeit mit uns setzt keiner davon voraus.
„Die Strategie steht noch nicht fest. Oder sie ist beschlossen, aber das Unternehmen verändert sich nicht. Mehrere Arbeitsstränge laufen, und niemand kann sagen, ob sie zusammen noch zum angestrebten Ergebnis führen“
Wie die Strategie lautet und wer die Veränderung zusammenhält
„Ein neues System wird verändern, wie ein Team arbeitet, aber niemand hat festgelegt, wie sich das Unternehmen darauf einstellt. Oder das System läuft schon, niemand ist dafür verantwortlich, und Entscheidungen bleiben liegen oder werden einen Monat später wieder aufgerollt“
Wie Verantwortung, Entscheidungen und Verbesserungen im Unternehmen organisiert sind
„Die Arbeit reißt zwischen Teams und Systemen ab: Jeder erledigt seinen Schritt korrekt, und trotzdem stimmt am Ende das Ergebnis nicht. Oder KI und neuere Systeme könnten die Arbeit inzwischen anders erledigen, aber das heutige Prozessdesign kann das nicht nutzen“
Wie die Arbeit laufen soll und wo KI sie verändert
„Zwei Systeme gelten beide als führend für denselben Datensatz, zwei andere müssen miteinander verbunden werden. Und jedes Projekt beginnt wieder mit der Diskussion über dieselben Systemgrenzen und dieselben Datengrundlagen“
Welches System was führt, wie die Systeme verbunden sind und warum
„Im Unternehmen wird bereits KI eingesetzt, aber niemand hat festgehalten, wo das geschieht und was die Regeln dafür verlangen“
Welche Pflichten gelten könnten und was sich ändern muss
Häufig kommen Ihnen zwei oder drei dieser Sätze gleichzeitig vertraut vor. Das ist normal. Genau deshalb ist die Beratung ein eigener Servicebereich und keine Sammlung von fünf unabhängigen Services.
Nennen Sie uns die beiden, die auf Sie zutreffen. Wir sagen Ihnen, womit Sie beginnen sollten.
Zu jeder gibt es eine eigene Seite mit Vorgehen, Ergebnissen und Abgrenzung. Hier lesen Sie, wofür sie jeweils gedacht ist.
Transformation Partner
Explore Transformation Partner →Solange die Veränderung läuft, braucht es eine verantwortliche Rolle, die dafür sorgt, dass Ergebnis, Organisationsdesign, Architektur, Umsetzung und Adoption aufeinander ausgerichtet bleiben. Gemeint ist kein Projektbüro, das den Plan nachverfolgt. Diese Rolle setzt sich mit den Zielkonflikten auseinander und spricht es aus, wenn eine Entscheidung in einem Arbeitsstrang das Ergebnis unbemerkt untergraben hat. Diese Arbeit beginnt früher, als die meisten erwarten: Ist die Plattform- oder KI-Strategie noch offen, wird sie hier festgelegt. So richtet sich alles andere auf ein Ergebnis aus, für das sich das Unternehmen bewusst entschieden hat.
Operating Model Design
Explore Operating Model Design →Hier geht es darum, wie sich das Unternehmen aufstellt, um das zu betreiben, was es bereits hat: wer verantwortlich ist, wer was entscheidet, ab welcher Schwelle und auf welcher Grundlage, und was dann geschieht. Eine einzelne Plattform ist dabei nur ein Teil. Gestaltet werden auch Vertriebsorganisation, Kundenservice und Delivery-Organisation, und zwar für die Zeit, bevor ein System ihre Arbeitsweise verändert, und für die Zeit danach. Diese Kompetenz bleibt dem Unternehmen, wenn das Programm endet. Dazu gehört auch die Frage, ob ein Center of Excellence überhaupt sinnvoll ist. Für die meisten mittelständischen Unternehmen lautet die Antwort: nein.
Business Process Consulting and Design
Explore Business Process Consulting and Design →Wir gestalten die Abläufe neu, statt sie nur zu dokumentieren, und zwar so konkret, dass ein Umsetzungsteam darauf aufbauen kann. Festgelegt werden die Verantwortung je Prozess, Entscheidungspunkte, Ausnahmen, die Datenhoheit und die Nahtstellen, an denen Übergaben heute scheitern. Mit KI und moderner Automatisierung sieht gutes Prozessdesign anders aus. Bisher gab es Schritte, weil ein Mensch etwas lesen musste, Freigaben, weil niemand den Daten traute, und Übergaben, weil zwei Systeme nicht miteinander kommunizierten. Wir gestalten für das, was heute möglich ist, nicht für das, was möglich war, als der Prozess entstand.
Hier wird festgelegt, wie die Anwendungs- und Informationslandschaft aussehen soll: welches System für welches Geschäftsobjekt führend ist, wo die Systemgrenzen verlaufen und was abgelöst wird. Ebenso geht es darum, wie zwei Systeme integriert werden, wie ein Geschäftsprozess in den beteiligten Systemen abgebildet wird und auf welchen Datengrundlagen alles andere aufbaut. Jeder künftige Prozess übernimmt diese Entscheidungen, ob sie dokumentiert sind oder nicht.
Für die KI, die Ihr Unternehmen tatsächlich nutzt, klären wir, welche Rollen und Pflichten gelten könnten, welche Nachweise nötig wären und was sich ändern muss. Es geht um Readiness- und Governance-Design, nicht um Rechtsberatung.
Dass eine Transformation an einer einzigen unsinnigen Entscheidung scheitert, haben wir noch in keinem Unternehmen erlebt. Wir sehen stattdessen fünf vernünftige Entscheidungen, die sich nicht miteinander vereinbaren lassen.
Das Operating Model setzt einen Prozess voraus, den niemand gestaltet hat.
Fünf Räume. Niemand hat entschieden.
Das Prozessdesign setzt eine Systemgrenze voraus, auf die sich die Architektur nicht geeinigt hat.
Die Architektur setzt eine verantwortliche Rolle voraus, die das Operating Model nicht benannt hat.
Der KI-Anwendungsfall setzt eine Datenhoheit voraus, die niemand geklärt hat.
Jede dieser Entscheidungen haben kompetente Menschen sorgfältig getroffen. Nur waren sie bei den anderen vier nicht mit im Raum.
Sobald die Umsetzung beginnt, zeigen sich die Unstimmigkeiten als Fragen, auf die ein Konfigurationsteam keine Antwort hat.
Wer gibt das frei? Welches System hat recht, wenn die beiden sich widersprechen? Ist diese Ausnahme inzwischen die Regel? Meistens lautet die ehrliche Antwort: Das hat niemand entschieden. Und so entscheidet es gleich jemand, der dafür nicht zuständig sein sollte.
Deshalb ist die Beratung bei uns so aufgebaut, wie sie ist. Der Grund ist nicht, dass Unternehmen fünf Arten von Beratung bräuchten, sondern dass sich diese fünf Entscheidungen gegenseitig einschränken und fast immer getrennt voneinander fallen. In der Beratung führen wir sie zusammen, solange sich noch etwas ändern lässt, ohne dass es teuer wird.
KI und moderne Plattformen beschleunigen nicht nur die bestehende Arbeit, sondern stellen infrage, welche Arbeit es überhaupt noch geben sollte. Damit wird aus einer Technologiefrage eine Designfrage. Lässt sich eine Entscheidung heute treffen, sobald die Daten vorliegen, müssen auch der Prozess, die verantwortliche Rolle und das System, in dem die Entscheidung liegt, anders aussehen. Wer das Design an den alten Abläufen ausrichtet und KI einfach obendrauf setzt, automatisiert am Ende Arbeit, die er besser abgeschafft hätte.
Naheliegend ist es, mit der größten Entscheidung zu beginnen. Der richtige erste Schritt ist aber meist der, auf den alles andere wartet. Er ist oft kleiner und weniger spannend als das Anliegen, mit dem Sie zu uns gekommen sind.
Die fünf überschneiden sich. Würden wir das verschweigen, wäre für Sie schwerer zu erkennen, was Sie beauftragen. Hier sehen Sie genau, wo jede endet.
Hält die Veränderung stimmig, solange sie läuft.
Gestaltet die Verantwortung, die das Unternehmen danach behält.
Das eine wirkt im Programm und endet mit ihm. Das andere verändert die Organisation dauerhaft.
Entscheidet, wie Arbeit laufen soll und welche Systeme sie unterstützen.
Entscheidet, wer sie verantwortet, steuert und verbessert.
Beide sprechen vom Process Owner, meinen aber Verschiedenes. In der Prozessarbeit ist das die Rolle, die einen einzelnen Prozess verantwortet. Im Operating Model ist es das Muster, mit dem Verantwortung über alle Prozesse hinweg dauerhaft verankert wird.
Gestaltet, wie ein einzelner Prozess laufen soll und welche Systeme ihn unterstützen.
Gestaltet die Geschäftslandschaft, auf der diese Prozesse laufen.
Und hält die gemeinsam getroffenen Entscheidungen fest, die für alle gelten.
Entscheidet, wie die Landschaft aussehen soll und warum.
Entscheidet, wer sie verantwortet, steuert und verändert.
Die Architektur trifft die Entscheidung. Das Operating Model sorgt dafür, dass das Unternehmen die nächste treffen kann.
Macht Ihr Unternehmen bereit.
Hilft, die Governance danach zu betreiben.
Governance as a Service gehört zu Managed Services, nicht zur Beratung. Readiness plant Zielzustand und Übergang, Governance as a Service übernimmt anschließend Reviews, Inventar und Nachweise im laufenden Betrieb.
Die Beratung klärt, wohin sich Ihr Unternehmen entwickeln soll. Discovery klärt, an welchen Anwendungsfällen Sie arbeiten und in welcher Reihenfolge.
Brauchen Sie eine Designentscheidung für einen künftigen Zustand, sind Sie in der Beratung richtig. Haben Sie mehrere mögliche Anwendungsfälle und konkurrierende Investitionen und müssen wissen, was zuerst kommt, was danach und was sich in diesem Jahr nicht lohnt, ist Discovery der passende Service. Discovery baut auf den Ergebnissen der Beratung auf, ersetzt die Designarbeit aber nicht.
Zwei der fünf klingen vertraut?
Nennen Sie uns die beiden, und wir sagen Ihnen, womit Sie beginnen sollten.
Jedes Beratungsmandat hat eine eigene Vereinbarung mit eigenen Ergebnissen und eigener Abnahme. Diese Trennung ist kaufmännisch begründet und hat eine praktische Folge: Unsere Empfehlung kann auch lauten, dass die Lösung kleiner ausfällt als erwartet, dass es die Funktion, die Sie gerade kaufen wollten, in Ihrer Systemlandschaft schon gibt, oder dass zuerst ein Datenproblem gelöst werden muss, damit sich alles Weitere lohnt.
Für jede wesentliche Funktion dokumentieren wir im Design das empfohlene führende System und die Integrationsgrenze samt Begründung, auch wenn ein bestehendes System oder das Produkt eines anderen Anbieters die bessere Lösung ist. Nicht jede Funktion gehört auf die Plattform, die wir implementieren. Ein Designdokument, das das nirgends sagt, verdient seinen Namen nicht.
Am Design arbeiten die erfahrenen Spezialisten mit, die auch beim Go-live dabei wären. Denn wer mit einem Design nicht selbst leben muss, entwirft es meist eleganter, als es sich umsetzen lässt.
Die Beratung braucht einen Verantwortlichen im Fachbereich, der für eine der betroffenen Kennzahlen zuständig ist.
Ein Sponsor aus der IT ist uns durchaus willkommen. Diese fünf Entscheidungen betreffen aber Vertrieb, Service, Delivery, Finanzen und Technologie. Solange nur die IT zugestimmt hat, ist eine Entscheidung noch keine Entscheidung.
Jedes Beratungsmandat liefert Ergebnisse, die bei Ihnen bleiben und mit denen Sie ohne uns weiterarbeiten können.
Wir halten fest, was entschieden wurde, welche Alternativen es gab und warum die Wahl darauf fiel. Schlägt in achtzehn Monaten jemand eine Ausnahme vor, beginnt die Diskussion bei der Begründung statt bei null.
Für jede Entscheidung, jeden Prozess, jedes Objekt und jedes System ist eine verantwortliche Rolle festgelegt, samt Entscheidungsschwelle und Grundlage. Wir benennen Rollen statt Personen, damit die Regelung auch Personalwechsel übersteht.
Wir dokumentieren, was wohin gehört, und vor allem, was außerhalb der Plattform bleibt. Oft ist die wertvollste Zeile eines Architekturdokuments diejenige, die Nein sagt.
Wir benennen, was noch ungeklärt ist, wer es klären muss und was dadurch blockiert ist. Ein Beratungsergebnis, das vollständig wirken will, verschweigt meist den interessanten Teil.
Beschreiben Sie uns die Entscheidung, die in Ihrem Unternehmen gerade nicht zustande kommt oder ständig neu verhandelt wird. Wir sagen Ihnen, welche der fünf sie klärt, wovon sie abhängt und ob Sie damit beginnen sollten.
Advisory entscheidet, was sich ändern soll und warum. Implementation sorgt dafür, dass die Veränderung Wirklichkeit wird. Der Unterschied ist kaufmännisch relevant: Ein Partner, dessen Umsatz vollständig vom Bauen abhängt, hat auf fast jede Frage nur eine ehrliche Antwort, und die lautet: bauen. Wenn die Beratung getrennt beauftragt und bezahlt wird, kann die Empfehlung legitim lauten, weniger zu tun, etwas wiederzuverwenden, das Sie bereits besitzen, zuerst ein Datenproblem zu lösen oder zu warten. Beide Arten von Arbeit sind nötig. Schwierig wird es meist dort, wo man sie als eine einzige Entscheidung einkauft.
Nicht immer, und der Test ist konkret. Wenn der Umfang klar ist, der Prozess abgestimmt, die Verantwortung benannt und die Systemgrenzen geklärt sind, dann bauen Sie. Advisory lohnt sich, wenn mindestens einer dieser vier Punkte fehlt, denn jeder davon wird zur Annahme in der Umsetzung, wenn ihn niemand bewusst entscheidet. Ein hilfreiches Signal: Wenn zwei Abteilungen dieselbe Frage zum Umfang unterschiedlich beantworten würden, ist die Entscheidung noch nicht gefallen, und ein Konfigurationsteam ist kurz davor, sie für Sie zu treffen.
Wir können sie festlegen. Eine Plattformstrategie oder KI-Strategie ist eine Designentscheidung wie jede andere: was das Unternehmen können soll, in welcher Reihenfolge, auf welcher Grundlage und was dadurch ausgeschlossen ist. Wir klären, wo Sie stehen, vereinbaren, was in zwei oder drei Jahren gelten soll, und halten Begründung und Verantwortung fest. Wo eine Strategie bereits existiert und abgestimmt ist, öffnen wir sie nicht erneut. Stattdessen prüfen wir, ob die laufenden Arbeitsstränge noch auf sie einzahlen. Das ist eine andere und meist kürzere Aufgabe.
Nein. Gegenstand ist meist eine Organisation: wie der Vertrieb aufgestellt ist, um zu verkaufen, Angebote zu erstellen und Aufträge abzuwickeln, wie der Kundenservice strukturiert ist, um Anfragen zu beantworten, und wie die Delivery-Organisation aufgebaut ist, um zu liefern und die eigene Marge zu sehen. Systeme spielen hinein, weil sie die Arbeit tragen und die Daten führen. Ein Design, das sie ignoriert, übersteht die Umsetzung nicht. Und ein Systemdesign, das eine Organisation voraussetzt, die niemand aufgestellt hat, ist ein Plan, die Lücke beim Go-live zu entdecken.
Ein Operating Model beschreibt, wie ein Unternehmen arbeiten will: wer welche Ergebnisse verantwortet, wer was entscheidet, ab welcher Schwelle, auf welcher Grundlage und wie Arbeit zu den Menschen gelangt, die sie erledigen. Ein Organigramm zeigt Berichtslinien, und das ist eine viel kleinere Aussage. Der praktische Unterschied: Das Organigramm sagt Ihnen, wer die Führungskraft einer Person ist. Das Operating Model sagt Ihnen, wer eine Änderung an einem gemeinsamen Prozess freigeben darf, ohne zu eskalieren. Der meiste Frust über Governance entsteht, weil das Erste existiert und das Zweite nicht.
Prozessdesign hat die Arbeit zum Gegenstand und reicht nur so weit in die Systeme, wie dieser Prozess es verlangt: welches System welchen Datensatz führt, wo die Grenzen verlaufen, was integriert werden muss. Architekturarbeit hat die Landschaft zum Gegenstand und trifft Entscheidungen, die für jeden heutigen und künftigen Prozess gelten: Zuordnung von Fähigkeiten, führende Systeme je Geschäftsobjekt, Identität, Integrationsmuster und was abgelöst wird. Das eine entscheidet, wie etwas fließen soll. Das andere entscheidet, was existieren muss, damit es fließen kann.
Jemand im Business, der eine Kennzahl verantwortet, auf die die Plattform wirkt, unterstützt von einer benannten verantwortlichen Person für die Plattform, die echte Entscheidungsbefugnis hat und nicht nur eine Warteschlange von Anfragen. Der häufige Fehler: Die Administration wird als Verantwortung behandelt. Sie kann Änderungen umsetzen, aber nicht zwischen zwei Abteilungen schlichten, die beide unvereinbare Änderungen wollen. Ob daraus ein formales Center of Excellence wird, hängt von der Größe ab. Wo die Plattform einer Funktion dient und ein Team baut, leistet eine benannte verantwortliche Person mit einer Entscheidungsliste und einem festen Review-Termin dasselbe, mit deutlich weniger Aufwand.
Wenn der Schritt wirklich nötig ist, die Regeln klar und stabil sind, die Eingaben einheitlich sind und das Volumen den Aufwand rechtfertigt. Automatisierung ist die falsche Antwort, wenn der Schritt ganz entfallen sollte, wenn Entscheidungsrechte unklar sind, wenn Ausnahmen zum Normalfall geworden sind oder wenn menschliches Urteil genau der Wert ist, der geliefert wird. Eine Falle verdient es, benannt zu werden: Manuelle Arbeit, die ein fehlerhaftes vorgelagertes System ausgleicht, gehört an der Quelle behoben und nicht an Ort und Stelle automatisiert.
Möglicherweise. Entscheidend ist die Rolle, die Sie einnehmen, nicht ob Sie selbst etwas entwickelt haben. Die Pflichten unterscheiden sich für Organisationen, die KI-Systeme entwickeln, und solche, die sie betreiben, und auch KI-Funktionen in gekaufter Software können Sie in die zweite Gruppe bringen. Ihre Position hängt vom konkreten Anwendungsfall ab, von seinem Kontext und davon, wer wofür verantwortlich ist. Das erfordert eine Bewertung Ihres tatsächlichen KI-Einsatzes. Wo eine formale rechtliche Einordnung nötig ist, ist das eine Frage für Ihre Rechtsberatung, und das sagen wir Ihnen, statt zu raten.
Ja, und das ist ein häufiger Ausgangspunkt. Zuerst klären wir, was tatsächlich konfiguriert ist, wie weit es vom Standardverhalten abweicht, ob es noch Releases des Herstellers aufnehmen kann und wozu Ihre bestehenden Verträge Sie bereits berechtigen. Diese vier Antworten verändern regelmäßig den Plan, und es lohnt sich, sie zu kennen, bevor jemand das Nächste darauf gestaltet.
Bei einer Entscheidung, auf deren Grundlage Ihr Unternehmen handeln kann, mit festgehaltener Begründung und benannter Verantwortung. Was danach passiert, hängt von der Entscheidung ab: umsetzen, über Discovery gegen andere Investitionen priorisieren oder in einer ganzen Reihe von Fällen vorerst nichts tun und neu prüfen, wenn sich eine Bedingung ändert. Wir übergeben Ergebnisse, die Ihnen bleiben. Dass Sie das Design ohne uns umsetzen können, ist der Zweck und kein Zugeständnis.