Der Umsetzungspartner hinter der Beratung

Eine IT-Beratung verkauft Urteilsvermögen. Welches System abgelöst wird, was integriert werden muss, wie die Architektur aussehen soll, was das kostet.

Danach muss es jemand bauen.

Oft ist dieser Jemand nicht die Beratung selbst. Sie gewinnt über Rat und Branchenkenntnis und holt für die Umsetzung einen Partner dazu. Das funktioniert gut und kommt häufiger vor, als der Markt zugibt. Es hat aber eine eigene Form — anders als Agenturarbeit, anders als Arbeit für Softwarehersteller.

Sie kommen nach den Entscheidungen

Eine Agentur holt einen Partner meist mit einem Briefing dazu. Eine Beratung holt ihn mit einer Zusage dazu.

Wenn wir im Raum sind, weiß der Kunde bereits, was gebaut wird, was es ungefähr kostet und wann es kommt. Die Architektur steht womöglich schon in einer Präsentation mit dem Logo der Beratung.

Das verändert die Aufgabe. Sie wählen keinen Ansatz, Sie liefern einen — innerhalb von Randbedingungen, die jemand anderes gesetzt hat, gegen ein Versprechen, das jemand anderes gegeben hat. Die nützlichen Fragen am ersten Tag lauten nicht “was sollte das werden”, sondern “was genau wurde wem zugesagt, und welche Teile davon sind tragend”.

Es steht ihr Name darauf

Die Glaubwürdigkeit der Beratung ist über Rat entstanden. Läuft die Umsetzung schlecht, trifft der Schaden den Rat: Der Kunde schließt nicht auf einen schwachen Umsetzer, er schließt auf eine falsche Empfehlung.

Diese Schieflage ist der eigentliche Grund, Unsichtbarkeit ernst zu nehmen — und Unsichtbarkeit ist wörtlicher gemeint, als man denkt. Ihre Marke in der Auslieferung, ihr Vorgehen, ihr Berichtsrhythmus. Fragen des Kunden beantwortet die Beratung, in ihrer Stimme, in ihrer Beziehung. Und man taucht an Stellen nicht auf, an die niemand denkt, bis es zu spät ist: in einer Commit-Signatur, in einer Dokumentfußzeile, in einer automatischen Mail vom Buildserver.

Für einen IT-Servicepartner der Deutschen Telekom haben wir ein Werkzeug gebaut und gepflegt, das Lexware mit der Beschaffungsplattform D!VE verbindet und Auftrags- und Angebotsdaten in genau das XML überführt, das die Schnittstelle akzeptiert. Die Kundenbeziehung zur Telekom lag durchgehend beim Partner. Unsere Aufgabe war, dass seine Zusage weiter trägt — nicht, dabei sichtbar zu sein.

Wenn Sie die Architektur für falsch halten

Das ist der Punkt, der einen guten Umsetzungspartner von einem bloß folgsamen unterscheidet. Und über den fast niemand schreibt.

Manchmal ist der Entwurf, den Sie erben, falsch. Nicht geschmacklich, sondern tatsächlich falsch — auf eine Weise, die im fünften Monat sichtbar wird.

Zu schweigen ist die feige Variante und schadet allen. Es vor dem Kunden zu sagen, ist schlimmer: Es untergräbt die Beratung in genau der Beziehung, die sie nicht verlieren darf, und es sieht so aus, als wollte man selbst auf den Beraterstuhl.

Die brauchbare Variante ist eng geschnitten. Früh ansprechen, unter vier Augen, gegenüber der Beratung. Eine durchgerechnete Alternative mitbringen statt eines Einwands. Klar sagen, was passiert, wenn nichts geändert wird — in Zeit und Geld, nicht in Adjektiven. Und dann ihre Entscheidung akzeptieren: Sie tragen die Zusage gegenüber dem Kunden und kennen womöglich Zusammenhänge, die nirgends aufgeschrieben sind, auch kaufmännische.

Ein Partner, der das nicht kann, ist auf andere Weise ein Risiko als einer, der nicht programmieren kann.

Die Zusage hat einen Nachlauf

Zusagen einer Beratung enden selten mit dem Livegang, weil die Systeme, an die sie anschließen, sich weiterbewegen.

Diese Telekom-Brücke ist ein kleines Werkzeug mit einer langen Verpflichtung: Das D!VE-Format entwickelte sich weiter, und das Werkzeug musste mitziehen, sonst konnte der Partner keine Angebote mehr einreichen. Der Bau war endlich. Die Verpflichtung nicht.

Jeder Umsetzungspartner hinter einer Beratung erbt diesen Nachlauf. Er gehört ausdrücklich in die Vereinbarung — wer beobachtet die Änderung, wer bezahlt das Mithalten, wie schnell wird ein Bruch behoben — statt erst aufzufallen, wenn ein fremdes Format sich zum ersten Mal verschiebt.

Was eine Beratung fragen sollte

Wenn Sie jemanden auswählen, der hinter Ihrem Namen baut, sind die technischen Fragen die leichtere Hälfte. Das hier sind die anderen:

Arbeiten Sie unter unserer Marke, in unserem Prozess, auch in Artefakten, die niemand ansieht? Was tun Sie, wenn Sie unsere Architektur für falsch halten — und wem sagen Sie es? Wer pflegt das nach dem Livegang, wenn der Dritte sein Format ändert? Können wir Sie vor den Kunden stellen, wenn wir wollen, und bleiben Sie dann in Ihrer Rolle?

Die letzte Frage wiegt schwerer, als sie klingt. White-Label-Umsetzung heißt nicht, sich zu verstecken. Sie heißt, dass die Beziehung dort bleibt, wo sie hingehört.

Wenn Sie als Beratung eine Umsetzung tragen, die Sie nicht intern besetzen wollen, sprechen wir darüber.