In einer Beratung wird Geld auf der Ebene eines einzelnen Mandats verdient und nicht im Jahresabschluss. Ein Partner weiß meist intuitiv, welche Projekte das Ergebnis tragen und welche daran zehren, nur lebt dieses Wissen in Köpfen und Tabellen und nicht in einer zusammenhängenden Sicht. Analytik für Beratungen beginnt deshalb nicht mit Diagrammen, sondern mit einer Frage: Wissen wir tatsächlich, was ein bestimmtes Mandat wirklich kostet und wirklich einbringt.
Nach unserer Erfahrung liegt die Schwierigkeit nicht darin, ein Dashboard zu zeichnen, sondern darin, Projekt-, Personal- und Vertragsdaten in einen Zustand zu bringen, in dem die Zahlen aufgehen. Wir haben hier keine fertige Referenz zu zeigen, wohl aber das, was in einem solchen Projekt am meisten zählt: Data Engineers, BI-Architekten und ML-Spezialisten, die wir in das Team des Kunden einbinden, damit dieses Fundament entsteht und gepflegt wird.
Warum braucht eine Beratung eine eigene Projektanalytik?
Weil das Geschäftsmodell der Beratung auf mehrere Variablen zugleich empfindlich reagiert: den Satz, die Auslastung der Berater, die Lieferung gegen das Stundenbudget und die zeitliche Verteilung der Umsatzrealisierung. Rutscht eine davon ab, verschwindet die Projektmarge - oft bevor es jemandem im Monatsabschluss auffällt.
Standardsysteme zeigen das nicht als Ganzes. Das ERP kennt Rechnungen, die Zeiterfassung kennt Stunden, das CRM kennt die Pipeline und HR kennt die Personalkosten, aber keines fügt das zu einem Bild der Profitabilität eines einzelnen Mandats zusammen. Eine eigene Analytikschicht ist der Ort, an dem diese Welten zusammentreffen und an dem ein Managing Partner aufhört, nach Gefühl zu steuern.
Wie entwerfen Sie ein Data Warehouse für Beratungsprojekte?
Das Fundament ist ein Datenmodell, das beschreibt, wie die Firma tatsächlich arbeitet, und nicht, wie es in der Theorie aussieht. Wir bauen es meist um einige Schlüsselobjekte herum:
- das Mandat / Projekt als zentrale Einheit, mit seinem Vertragstyp (Festpreis, Time & Material, Retainer),
- den Berater und seine Rolle, mit Kosten, Verkaufssatz und Verfügbarkeit,
- den Zeiterfassungseintrag, gebunden an ein Projekt und eine Aufgabe,
- den Vertrag und das Budget, mit geplantem Umsatz und geplanten Kosten,
- den Kunden und die Branche, für Portfolioanalyse und Benchmarking.
Darüber legen wir ein klassisches dimensionales Modell (Fakten und Dimensionen), denn es erlaubt, dieselben Kennzahlen über verschiedene Schnitte hinweg zu berechnen, vom einzelnen Berater bis zu einer ganzen Geschäftslinie, ohne die Logik für jede neue Frage neu zu schreiben.
Wie bauen Sie Dashboards zu Marge und Auslastung?
Das ist das Herz der Lösung, denn hierhin schauen COO und Partner täglich. Dashboards zu Marge und Auslastung sollten operative Fragen schneller beantworten, als man sie von Hand zusammenstellen könnte:
- die Marge nach Projekt und Kunde, aufgeteilt in geplant und realisiert,
- die Auslastung je Berater, Team und Practice, getrennt nach abrechenbaren und nicht abrechenbaren Stunden,
- den Budgetverbrauch an Stunden und Kosten gegen den Zeitplan (ähnlich einer Burn-/EAC-Kennzahl),
- den effektiven Satz im Vergleich zur Preisliste,
- die Umsatzrealisierung und die unfertigen Leistungen (WIP) bei Projekten mit Teilabrechnung.
Entscheidend ist, dass diese Kennzahlen einmal, an einer Stelle und mit einer einzigen Definition berechnet werden. Sonst bringen zwei Abteilungen zwei verschiedene Margen in die Besprechung, und die Diskussion dreht sich darum, wessen Excel das richtige ist.
Wie legen Sie Bibliotheken von Benchmarks und Schätzungen an?
Benchmarking ist der Moment, in dem vergangene Daten beginnen, in künftigen Angeboten Geld zu verdienen. Aus der Projekthistorie bauen wir Bibliotheken von Benchmarks und Schätzungen, also strukturiertes Wissen darüber, wie lange wiederkehrende Arbeitstypen tatsächlich dauern und was sie kosten.
In der Praxis heißt das, Projekte nach Typ, Branche, Größe und Teamzusammensetzung zu parametrisieren und dann Verteilungen des tatsächlichen Aufwands gegen die ursprünglichen Schätzungen zu berechnen. Der Vertrieb hört auf, „nach Gefühl” zu kalkulieren, und eine neue Führungskraft bekommt einen Bezugspunkt statt einer leeren Seite. Es ist zugleich der ehrlichste Weg, die Projekte zu benennen, die sich regelmäßig nicht sauber abschließen lassen, und zu verstehen, warum.
Wie prognostizieren Sie Pipeline und Kapazität?
Eine Beratung verkauft die Zeit von Menschen, deshalb ist die Prognose von Pipeline und Kapazität im Kern der Abgleich zweier Kurven: Nachfrage aus der Pipeline und Angebot aus den Plänen des Teams. Betrachtet man sie getrennt, bekommt man immer entweder Überhitzung oder eine Bank.
Wir verbinden deshalb die gewichtete Pipeline aus dem CRM mit der geplanten Zuordnung und der Verfügbarkeit der Berater, um künftige Kapazitätslücken und -überschüsse Wochen oder Monate im Voraus sichtbar zu machen. Diese Sicht verwandelt Gespräche in der Geschäftsleitung von reaktiv zu planend: Statt im nächsten Quartal einen Personalmangel zu löschen, können Sie früher rekrutieren, ein Team verschieben oder den Vertrieb in einem überlasteten Bereich bewusst drosseln.
Wie sichern Sie Qualität und Konsistenz der Quelldaten?
Das schönste Dashboard verliert gegen einen falsch zugeordneten Zeiteintrag, deshalb behandeln wir Qualität und Konsistenz der Quelldaten als eigenen Teil des Projekts und nicht als Nachgedanken. Die typischen Probleme sind vorhersehbar:
- zu spät erfasste Stunden oder solche auf dem falschen Projekt,
- unterschiedliche Definitionen desselben Begriffs (was als abrechenbar gilt) zwischen Abteilungen,
- eine Diskrepanz zwischen dem Vertrag im CRM und dem tatsächlichen Arbeitsumfang,
- Lücken in den Kostendaten zu Beratern und Subunternehmern.
Wir bauen deshalb Datenvalidierungen und Tests in die Ladepipelines ein, Alarme für Lücken und ein klares Kennzahlenglossar. Es geht nicht um perfekte Daten ab dem ersten Tag, sondern um Fehler, die sichtbar sind und an der Quelle behoben werden, bevor sie auf dem Bildschirm eines Partners landen.
Wann lohnt sich der Griff zu ML-Prognosen?
Dann, wenn einfache Regeln und Durchschnitte nicht mehr reichen und bereits genug Historie vorliegt, damit Muster sichtbar werden. ML-Prognosen ersetzen keine Dashboards; sie ergänzen eine Vorhersageschicht dort, wo ein Mensch nicht alle Abhängigkeiten abwägen kann.
In der Beratung ist das meist sinnvoll für die Vorhersage der Abschlusswahrscheinlichkeit einer Opportunity in der Pipeline, die Vorhersage einer Budgetüberschreitung aus frühen Signalen und die Prognose der Teamauslastung in den kommenden Perioden. Das ist eine echte Kompetenz, die wir bereitstellen, auch wenn wir es klar sagen: ML ergibt nur auf sauberen Daten Sinn und ist deshalb meist eine spätere Stufe und nicht die erste.
Welche Kompetenzen stellen wir für ein solches Projekt bereit?
Wir stellen das Team rund um die konkrete Arbeit zusammen, nicht „auf Vorrat”. In Analytikprojekten für Professional-Services-Firmen sind das meist:
- ein Data Engineer, der Pipelines und Warehouse baut (ELT/ETL, Modellierung),
- ein BI-Architekt / Analyst, der das Kennzahlenmodell und die Dashboard-Schicht verantwortet,
- ein Analytics Engineer, der Definitionen und Transformationen bewacht,
- ein ML-Spezialist dort, wo Prognosen ins Spiel kommen,
- ein DevOps- / Data-Platform-Spezialist für Inbetriebnahme, Sicherheit und Wartung.
Dieses Vorgehen erlaubt es einem Team, die Datenschicht wirklich zu verantworten und nicht nur einen einzelnen Bericht zu liefern und zu verschwinden.
Wie machen wir das bei RITS?
Wir tun es als Nearshore-Partner aus Polen, der Daten-, BI- und ML-Kompetenzen in das Projekt einbringt, auch wenn Ihr Team die Richtung vorgibt:
- wir verstärken das Team mit konkreten Spezialisten, deren Kompetenzen wir vor dem Start prüfen,
- wir entwerfen das Datenmodell der Beratung, bevor das erste Diagramm existiert,
- wir verbinden die Quellen (ERP, Zeiterfassung, CRM, HR) zu einem wartbaren Warehouse,
- wir ergänzen die ML-Schicht nur dort, wo die Daten dafür bereit sind, ohne Versprechen, die wir nicht halten können.
Wir tun nicht so, als hätten wir in diesem Feld eine abgeschlossene Einführung zu zeigen; wir bringen die Menschen und den Ansatz mit, durch die eine solche Einführung in Ihrer Firma entsteht und gepflegt bleibt.
Wo beginnen Sie mit der Analytik für Beratungsprojekte?
Beginnen Sie mit einer Entscheidung, die Sie besser treffen wollen, zum Beispiel „sollen wir dieses Projekt mit diesem Team annehmen”, und mit der Frage, welche Daten das braucht. Das legt den Umfang der ersten Warehouse-Iteration, den Satz an Kennzahlen und die nötigen Rollen fest. Ein glaubwürdiges Margen-Dashboard schlägt zehn, denen niemand traut. Die Unterschiede zwischen den Kooperationsmodellen haben wir in unserem Artikel zu IT-Kooperationsmodellen beschrieben.
Sie bauen Analytik und Benchmarking für Beratungsprojekte auf? Sprechen wir darüber - wir finden ein Data/BI/ML-Team und eine Architektur passend zu Ihrer Firma.
Analytik und Benchmarking für Beratungsprojekte mit uns aufbauen