Gebrauchsanweisung für einen Trusted Advisor

Stellen Sie sich vor, Sie hätten einen Organisations- und IT-Experten mit mehr als 20 Jahren C-Level-Advisory-Erfahrung. Wie Sie sein Wissen, seine Erfahrung und seine Expertise am besten nutzen können, beschreibt dieser Beitrag.

Die wichtigsten Beiträge kann ein Trusted Advisor liefern, wenn Entscheidungen anstehen und Sie zwischen unterschiedlichen Alternativen mit Vor- und Nachteilen wählen müssen. Dann sollten Sie immer Ihren Trusted Advisor fragen und um eine Stellungnahme bitten. Da der Trusted Advisor meistens für die Dauer des Projektes oder für ein ganzes Jahr engagiert wird, ist er deshalb mit Ihrer Situation sehr gut vertraut und kann sein Fachwissen und seine Erfahrung voll zu Ihren Gunsten einsetzen. So wurde neulich diskutiert, ob ein Systemupgrade noch in der Projektlaufzeit erfolgen sollte. Vorteil wäre unter anderem, dass das Projekt mit einem aktuellen System endet, Nachteil wäre, dass ein geringer Teil an Key-User-Ressourcen zusätzlich benötigt würde. Ich wies darauf hin, dass jetzt ein geringer Aufwand, nach Produktivsetzung des Gesamtsystems jedoch ein sehr hoher Aufwand erforderlich wäre, der von – erst nach Produktivsetzung möglichen – Optimierungen abhalten würde.

Auch bei Planungen sollten Sie Ihren Trusted Advisor um Rat fragen. Seien es ein Projekt- oder Terminplan, ein größeres Investitionsvorhaben oder andere strategische Überlegungen, die Auswirkungen auf Organisation und IT haben – er wird dazu eine Meinung haben und Sie beraten können.

Vor einigen Monaten wurde ich gefragt, ob mit den internen Ressourcen der vorgelegte Projektplan des IT-Dienstleisters machbar sei. Ich wies auf einige Bedingungen hin, die im Hause erfüllt sein müssten, damit der Projektplan gelingen könne. Könnten diese Bedingungen (unter anderem Freistellung der Key User für mindestens drei Arbeitstage je Woche) erfüllt werden, sähe ich kein Problem.

Meinungsverschiedenheiten im Haus sind ein weiterer Anlass, den Trusted Advisor um Rat zu fragen. Hat die IT recht oder der Fachbereich? Lassen Sie beide Seiten ihre Argumente vortragen und durch den Trusted Advisor bewerten. Der Vorteil für Sie: Sie können sich ihre eigene Meinung bilden und haben zusätzlich noch jemanden, der Ihnen sachliche Argumente liefern kann.

So bat die IT eines Unternehmens um die Besetzung weiterer Stellen, und ich konnte der Unternehmensleitung verdeutlichen, dass sich die Freigabe dieser Stellen sehr positiv auf die Wettbewerbssituation des Unternehmens auswirken würde.

Verträge, insbesondere mit Softwareunternehmen und IT-Dienstleistern, sind eine weitere Einsatzmöglichkeit für Ihren Trusted Advisor: Lassen Sie ihn die Verträge auf für Sie nachteilige Formulierungen durchsehen. Meist sind die geldwerten Vorteile aus einem verhandelten Vertrag schon höher als die komplette Investition in den Trusted Advisor.

Bei einem Vertrag zur SAP-Einführung konnte ich Bonus-/Malus-Regelungen in erheblicher Höhe durchsetzen, die gleichzeitig Anwender und Dienstleister motivieren.

Die Bewertung von Leistungen in einem Projekt oder einem Programm kann ebenfalls durch Ihren Trusted Adviser erfolgen. Geldabflüsse und das Erreichen von Kalenderdaten lassen sich schnell erkennen, aber der Gegenwert in Gestalt des Projektfortschritts ist erheblich schwerer einzuschätzen.

In einem Projekt gab es erhebliche Differenzen zwischen dem Software entwickelnden IT-Bereich und dem Fachbereich, der diese Software nutzen sollte. Ein von mir angesetztes Projektreview deckte diese Haltungen auf und führte zu einer konstruktiven Fortsetzung der gemeinsamen Arbeit.

Schließlich ist der Trusted Advisor eine äußerst wertvolle Hilfestellung bei Personalfragen. Ist ein Mitarbeiter „reif“ für eine höhere Führungsposition, kann Ihr Trusted Advisor dazu eine Einschätzung geben. Dabei kommt es allerdings vor, dass ich von der Beförderung abraten muss, weil gleichzeitig ein guter Fachexperte verloren geht und ein schlechter Manager (der nicht mit Mitarbeiterinnen und Mitarbeitern umgehen kann) hinzukommen würde.

Mehr Kolumnen des Trusted Advisors lesen Sie HIER.

Das könnte Sie auch interessieren

Adaptive Service Level Agreements Wie flexible Verträge Innovation ermöglichen und welche Risiken sie bergen

Klassische SLAs sichern Stabilität –doch genau das macht sie oft zur Innovationsbremse. Anpassungen werden aufgeschoben, Chancen bleiben ungenutzt. Wie lassen sich Verträge so gestalten, dass Veränderung nicht stört, sondern systematisch ermöglicht wird? Der Beitrag zeigt, wie adaptive SLAs als „Living Contract“funktionieren und Innovation schon während der Laufzeit fördern –praxisnah und direkt umsetzbar für IT- und ERP-Verantwortliche.

Zehn ERP-Praktiker über Projekterfolg Was in Auswahl, Implementierung und Betrieb wirklich zählt

ERP-Projekte scheitern selten an der Software selbst, sondern an unklaren Prozessen, fehlender Vorbereitung und mangelnder organisatorischer Einbindung. Zehn erfahrene ERP-Praktiker aus Deutschland und der Schweiz berichten aus ihrer Projektpraxis und zeigen, welche Faktoren bei Auswahl, Einführung und Betrieb von ERP-Systemen wirklich entscheidend sind – von der oft unterschätzten Phase Null bis zur realistischen Einordnung von KI.

Prozessmanagement in ERP-Projekten Warum ERP-Projekte an Prozessen scheitern – nicht an Software

In vielen Unternehmen existieren Prozesshandbücher, Verfahrensanweisungen oder ISO-konforme Dokumentationen. Sie erfüllen Audit-Anforderungen und beschreiben Abläufe formal korrekt. Doch im ERP-Projekt zeigt sich häufig eine unbequeme Wahrheit: Diese Dokumente bilden die gelebte Realität nur unzureichend ab. Wie lässt sich diese Kluft zwischen dokumentiertem Prozess und operativer Praxis überwinden?

Requirements-Engineering bei „lebenden“ ERP-Systemen Ein Framework zur Unterstützung des Requirements-Engineerings durch Fachabteilungen

Das grundlegende Problem: mehr Pflege als Neuentwicklung Wertet man Pressemitteilungen als Indikator, so kann man den Eindruck bekommen, dass Start-Ups, technische Innovationen und große Projekte mit wegweisenden Weichenstellungen den Alltag beherrschen, begleitet von neuen IT-Systemen und innovativen Cloud-Anwendungen, die man einfach nur herunterladen müsse, um eine neue Stufe der „Digitalisierung“ zu erreichen. Auch in der Informatikausbildung ist die Ausrichtung auf neue Systeme vorherrschend: Das „Requirements Engineering“ (RE), also die Erhebung, die Analyse und das Management von Anforderungen, wird oft anhand von kleinen Projekten in der Neuentwicklung geschult.  Dieser Fokus auf neue Systeme ist aus Sicht der Medien und Technikanbieter zwar nachvollziehbar,  verstellt allerdings den Blick darauf, dass die meisten Unternehmen eben doch schon einige Jahre oder Jahrzehnte auf dem Markt sind und die grundlegenden betriebswirtschaftlichen Prozesse mit vorhandener ...

Gefährliche Stille: Wenn S/4HANA-Projekte aus dem Ruder laufen  Warum viele Unternehmen strategisch falsch entscheiden – und es erst Jahre später merken

Die S/4HANA-Transformation gilt für viele Vorstände und IT-Leitungen als eines der wichtigsten strategischen Projekte der letzten Jahre. Sie steht für Zukunftsfähigkeit, Innovationsfähigkeit und nicht zuletzt für die technologische Grundlage kommender Geschäftsmodelle. Umso erstaunlicher ist eine Beobachtung, die sich in zahlreichen Transformationsprojekten wiederholt: Die Transformation scheitert –ohne dass es jemand zur Kenntnis nimmt.

Produktivität neu gedacht Warum Automatisierung der stille Held der KI-Debatte ist

Während KI die Schlagzeilen dominiert, erzielen viele Unternehmen ihre größten Effizienzgewinne durch intelligente Automatisierung bestehender ERP-gestützter Prozesse. Der Gastbeitrag von Dr. Willms Buhse zeigt auf, wie Automatisierung als Fundament wirkt, auf dem KI sinnvoll aufbauen kann –und warum ein zu früher KI-Fokus häufig mehr Komplexität als Nutzen erzeugen kann.