The Trusted Advisor

Univ.-Prof. Dr.-Ing. habil. Norbert Gronau ist Inhaber des Lehrstuhls für Prozesse und Systeme an der Universität Potsdam. Er ist häufiger Key- note Speaker und Gründer der auf Trusted Advisory spezialisierten Potsdam Consulting Advisory GmbH. Zu seinen Kunden zählen Familienunternehmen wie Bahlsen und die Meyer Werft, Konzerne wie Universal Music, Daimler und Lufthansa Technik sowie öffentliche Einrichtungen wie die Landeshauptstadt München und das Land Niedersachsen. Er hat Bücher zu Geschäftsprozessmanagement, ERP und Wissensmanagement verfasst und ist Mitglied der Deutschen Akademie der Technikwissenschaften ACATECH.

E-Mail advisor@potsdam-consulting.de

Folge 1: Verträge mit Lieferanten verhandeln
Große Reorganisations- und IT-Projekte sind meist nur mit Hilfe externer Dienstleister zu bewältigen. Die meisten Unternehmen verfügen über exzellente Expertise, um Verträge für alle Dienstleistungen in ihren wertschöpfenden Geschäftsprozessen auszuhandeln.

Eine Übertragung dieser Prinzipien auf den „Einkauf“ von Produkten und Dienstleistungen in großen Reorganisations- und IT-Projekten scheitert aber meist. Das hat mehrere Gründe. Zum einen besteht keine Kenntnis über branchenübliche Gepflogenheiten hinsichtlich der Vertragsbedingungen. Die Marktmacht ist häufig exakt umgekehrt verteilt als bei den sonst beschafften Produkten und Dienstleistungen, das macht andere Verhandlungsstrategien erforderlich. Schließlich bestehen keine Erfahrungen, welche Preisuntergrenzen z. B. für Entwickler, Projektleiter und Berater als  marktüblich herangezogen werden können. Hier wird häufig viel Geld verschenkt, während auf der anderen Seite an eigentlich unnötig harten Bedingungen zu lange festgehalten wird.

Ein Trusted Advisor bespricht diese Aspekte in einem Briefing mit dem verhandelnden Vorstand oder Geschäftsführer vor der Verhandlung und ermöglicht so das Erzielen optimaler Ergebnisse.

Ein Wort sei noch zu den Feinheiten juristischer Formulierungskünste verloren: Bei der Lieferung von Software z. B. müssen alle vertraglichen Klauseln lediglich angemessen sein. Es kommt nicht darauf an, auch noch so unwahrscheinliche Ereignisse vertraglich im Vorhinein zu regeln, sondern faire und transparente Verfahrensweisen für solche Fälle zu vereinbaren. Ich pflege solche Vertragswerke vor Beginn der eigentlichen Verhandlung von unseren Spezialisten für IT-Recht prüfen zu lassen, gehe jedoch in entsprechende Verhandlungen stets ohne ausdrückliche anwaltliche Begleitung. Das spart Kosten, ermöglicht der Gegenseite, ebenfalls auf einen Anwalt zu verzichten und gestattet eine deutlich schnellere Einigung. Die wichtigen Verfahrensregeln werden übrigens von den selbst ernannten Spezialisten im IT-recht gern vergessen. Diese prüfen häufig nur den Vertrag der Gegenseite, in dem solche Regeln aus verständlichen Gründen gar nicht enthalten sind - man würde sich ja nur unnötig selbst binden.

Allerdings habe ich auch schon das andere Extrem erlebt, in dem ein sogenannter Fachanwalt für IT-Recht nicht den vom Dienstleister vorgelegten Vertragsentwurf prüfte, sondern kurzerhand einen von ihm selbst entwickelten Vertrag aus der Schublade zog selbstverständlich für eine fünfstellige Summe extra. Da bei solchen Anwälten im Wortsinne jede Stunde zählt, müssten in so einem Fall mühsamst alle für das Projekt relevanten Verfahrensregeln erneut in den Vertrag hineinformuliert werden. Ein Trusted Advisor hätte seinen Kunden frühzeitig auf den sehr hohen Zeitbedarf für dieses Vorgehen hingewiesen.

 

Folge 2: Qualitätssicherung im Projekt
Ein komplexes IT- oder Reorganisationsprojekt umfasst mehrere Beteiligte in einer projektspezifischen Organisationsform. Entscheidungen und Informationen wie Anforderungen etc. werden in der Regel in Dokumenten festgehalten und für andere Beteiligte verfügbar gemacht.

Der Trusted Advisor sorgt nun dafür, dass ein angemessener Qualitätsstandard für die zu erstellenden Dokumente eingehalten wird. Dazu gehört zunächst, dass eine passende Umgebung für die Aufbewahrung und den Austausch von Dokumenten, auch mit Dienstleistern, gefunden wird. Geeignete Lösungen dafür sind der Teamroom von IBM oder Confluence von Atlassian. Einige Anbieter stellen auch auf Sharepoint basierende Lösungen zur Verfügung. Trotz der unzureichenden Usability dieses Produktes kann eine derartige Lösung verwendet werden, wenn einige Rahmenbedingungen wie Vorkonfiguriertheit und Sicherung des Zugriffs für alle Beteiligten gewahrt bleiben. 

Doch mit der Verfügbarmachung der Plattform ist es nicht getan. Der Trusted Advisor berät dabei, wie diese Plattform sinnvollerweise strukturiert wird und welche Dokumente unbedingt darin aufbewahrt werden müssen. Als Faustregel verwende ich stets die Anforderung, dass ein Dokument auf die Plattform gestellt werden muss, sobald es einer zweiten Person zugänglich gemacht wird oder gemacht werden müsste. Für den Verlauf des Projektes hat es sich bewährt, nur solchen Dokumenten Gültigkeit zuzubilligen, die im Teamroom verfügbar sind. Auch die Versionierung wird durch eine Plattform wesentlich erleichtert.

Noch wichtiger als die Organisation der Dokumentation ist jedoch die inhaltliche Prüfung der erstellten Dokumente durch den Trusted Advisor. Häufig passiert es, dass "in der Hitze des Gefechtes" übergeordnete Zielsetzungen des Projektes aus dem Blickfeld geraten. Der Trusted Advisor weist dann darauf hin und schlägt Prioritäten und Dringlichkeiten vor. So ist z. B. die von der IT vorgeschlagene Umstellung der Datenbank auf die neueste Serverversion weder wichtig noch dringend, wenn in zwei Jahren ein Großteil der darauf laufenden Software ohnehin abgelöst wird. 

Gerade in stark arbeitsteilig organisierten Projekten muss jemand den Überblick über die inhaltlichen und finanziellen Gesamtprojektziele bewahren. Geschäftsführung oder Vorstände sind häufig so mit dem Tagesgeschäft belastet, dass sie für derartige Aufgaben keine Zeit haben. Im Lenkungsausschuss berichtet der Trusted Advisor regelmäßig über den Stand der Dokumentenprüfung, sinnvollerweise als eigener Tagesordnungspunkt. Dabei wird auf Vollständigkeit, Struktur und Qualität der Ergebnisse geachtet. Der Trusted Advisor gibt konkrete Hinweise für das Projekt, wie die Dokumente zu verbessern sind. Ein Status erleichtert die monatliche Verfolgung der Dokumentenqualität.

Weitere Unterlagen, die der Trusted Advisor regelmäßig prüft, sind z. B. Anforderungsspezifikationen, die ggf. von der internen IT oder von externen Dienstleistern erstellt werden. Beiden fehlt nach meiner Erfahrung regelmäßig die Sicht auf die für die Wertschöpfung wesentlichen Aspekte. Die interne IT ist meist mehr an einer aufwandsarmen Wartung von Software interessiert als an ihrer Funktionalität. Ein Dienstleister gerät schon mal in die Versuchung, eine für einen anderen Kunden entwickelte Lösung zu kopieren, ohne eine gewissenhafte Anpassung vorzunehmen. Beide Autorengruppen schweigen zumeist zu organisatorischen Festlegungen, etwa zur Verantwortlichkeit für Datenqualität und Durchführung der Aufgabe. So kann der Trusted Advisor durch seine begleitende Qualitätssicherung mithelfen, Fehler und Unzulänglichkeiten nicht erst entstehen zu lassen oder frühzeitig auszumerzen, um die Projektziele ohne unnötigen Mehraufwand, ohne Abschweifungen und zum gesetzten Termin zu erreichen.

 

Folge 3: Staffing im Einführungsprojekt
Eine der wesentlichen Entscheidungen zu Beginn eines IT-Einführungsprojektes ist es, die Projektorganisation personell zu besetzen. Fehler, die hier gemacht werden, wirken sich auf die gesamte Laufzeit des Einführungsprojektes aus und sind nur mit erheblichem Aufwand und teilweisem Verlust persönlicher Reputation wieder zu reparieren.

Die mit Abstand wichtigste Rolle in der Projektorganisation kommt dem Projektleiter (bei mehreren Projekten gleichzeitig dem Programmleiter) zu. Er muss über umfassende Kenntnisse der wertschöpfenden Geschäftsprozesse verfügen, denn um die Umstellung dieser auf ein neues ERP-System geht es ja bei der Einführung. Grundlegende Fähigkeiten im Change Management sind hilfreich.

Nach meiner Erfahrung sind IT-Leiter nur sehr selten für diese Rolle qualifiziert. Zum einen verfügen sie nur selten über gute Kenntnisse der wertschöpfenden Geschäftsprozesse, zum anderen liegt ihr Hauptaugenmerk auf dem aufwandsarmen Betrieb der vorhandenen Systeme. Es ist nicht auszuschließen, dass zu treffende Entscheidungen dann insbesondere unter diesem Gesichtspunkt getroffen werden. Kein wesentliches Argument ist es hingegen, dass sich der IT-Leiter in der IT gut auskennt. Dieses Wissen ist häufig veraltet oder auf wenige Technologien einzelner bereits im Einsatz befindlicher Anbieter bezogen.

Daher suche ich stets nach engagierten Projektleitern, die ein Ziel vor Augen haben und sich auch durch Einwände nicht davon abbringen lassen. Häufig finde ich diese Personen in der Leitung von Teilorganisationen (Werke, Filialen, Geschäftsbereiche).

Um das Projekt zügig voranzubringen, ist eine Entlastung dieser Personen zu 50-70% ihrer Linienaufgabe zwingend erforderlich. Andernfalls erhält man entweder einen heillos überlasteten Projektleiter, der sich nicht ausreichend um zu eskalierende Sachverhalte kümmern kann, oder einen ausgebrannten Linienmanager. Gegenüber Eigentümern und Unternehmensleitung muss ich doch gelegentlich auf die Einhaltung dieser Entlastungszusagen pochen und Ausflüchte oder Aufschiebeversuchen begegnen.

Die Mitglieder des Projektteam sind ähnlich auszuwählen. Auch hier ist für eine partielle Freistellung Sorge zu tragen. Gemischte Teams sind übrigens rein männlichen Teams von der Leistung her überlegen. 

Was ist mit dem IT-Leiter zu tun, der zusehen soll, wie in „seiner“ IT ein neues ERP-System eingeführt wird? Hier gibt es nur zwei Möglichkeiten: er wird für die seine Kompetenzen betreffenden Themen aktiv und verantwortlich eingebunden oder er wird aus dem Projekt weitmöglichst herausgehalten. In letzterem Fall muss sichergestellt werden, dass es nicht aus gekränktem Stolz zu negativer Kommunikation im Unternehmen kommt. Professionell agierende IT-Leiter sehen das ein, von den anderen sollte man sich trennen.

Eine Projektorganisation so aufzustellen, ist keine einfache Aufgabe. Meist sind mehrere Gespräche mit potenziell infrage kommenden Personen erforderlich und auch Gesellschafter bzw. andere Aufsichtsgremien wollen überzeugt werden. Häufig werde ich gefragt, ob es auch ein externer Projektleiter sein könne. Wenn er die oben skizzierten Anforderungen erfüllt, dann spricht nichts dagegen. Es muss dann allerdings ein Mechanismus geschaffen werden, seine Entscheidungen in der Linie umzusetzen, da er in der Regel keine Führungsfunktion für die Linie ausübt. Ein externer Projektleiter bedeutet daher mehr (Durchsetzungs-)Aufwand für die Geschäftsführer oder den Vorstand.

In regelmäßigen Abständen muss die Projektorganisation überprüft werden. Bei internationalen Projekten und solchen an mehreren Standorten muss zudem der Wissenstransfer zwischen den Teams sichergestellt werden. Auch wenn Dokumentationswerkzeuge wie Teamrooms oder Confluence eingesetzt werden, geht dies überwiegend über direkten Informationsaustausch. Dazu wird ein standortübergreifendes Kernteam installiert, das alle Teilprojekte betreut. In die Workshops sind dann immer Mitarbeiter des Standortes und Kernteammitglieder einbezogen.

 

Folge 4: Architekturfragen lösen
Bei großen Reorganisations- und IT-Projekten werden häufig auch Fragen der Software und Anwendungssystemarchitektur entschieden. Diese Kolumne benennt einige davon und schildert Lösungsverfahren unter Zuhilfenahme eines Trusted Advisors.

Architekturfragen treten häufig erst während eines Projektes auf und müssen dann relativ schnell geklärt werden, um den Zeitplan der Zielerreichung nicht zu gefährden. Ein Beispiel dafür ist die zusätzliche Einführung einer „Add-on-Software“, weil mit dem ursprünglich ausgewählten Informationssystem die funktionalen Anforderungen nicht vollständig erfüllt werden können. Ein weiteres Beispiel ist die notwendige Datenablage einer Eigenentwicklung.

Entscheidungen über die Architektur sind wohlüberlegt zu treffen. Keinesfalls darf nur das schnelle Weiterkommen im Projekt im Vordergrund stehen. Relevant erscheinen mir vor allem diese Aspekte: 

  • Was ist überhaupt eine Architekturfrage?
  • Wo wird über Architekturfragen entschieden?
  • Welche Richtlinien sollten bei der Entscheidung zugrunde gelegt werden?
  • Die Entscheidung betrifft mehrere Projekte und deren Systeme. Dabei kann es um Funktionen, Daten oder Prozesse gehen. 
  • Auswahlentscheidungen über Software mit verbleibender technologischer Unsicherheit sowie Entscheidungen über außerplanmäßige Technologien, die als Zwischenlösungen vorgesehen sind, berühren Architekturfragen.
  • Ebenso sind ein hybrider Betrieb von alter und neuer Software, der Einsatz einer nicht mehr offiziell vom Hersteller unterstützten Technologie oder ein Querschnittsthema mit übergreifenden Auswirkungen auf Prozesse oder Projekte ein Architekturthema.

Über diese Architekturfragen sollte ein Gremium entscheiden, das speziell mit Kompetenzen für dieses Thema ausgerüstet ist. Neben dem Business, der IT, einem Vertreter des Projektes (Projektleiter oder Programmmanager) sollte ein Architekturspezialist dabei sein. In meinen Projekten begleite ich das sogenannte Architectural Review Board (ARB) ebenfalls mit meiner Erfahrung. Entscheidungen in Architekturfragen sollten getroffen werden, wenn folgende Fragestellungen aufkommen:

In welche Richtung sollte nun entschieden werden? Dies ist pauschal sehr schwer zu beantworten. Dennoch möchte ich hier einige Leitlinien aus meiner Erfahrung einbringen:

  • Es ist auf strukturelle Analogien zwischen der Organisation und dem eingesetzten Informationssystem zu achten.
  • Dezentrale Funktionen können mit dezentralen Systemen bedient werden, zentrale Funktionen benötigen zentrale Systeme.
  • Schnittstellen sind nicht um jeden Preis zu vermeiden. Gelingt es, die Schnittstellen zwischen zwei Systemen konstant zu halten, können sich rechts oder links der Schnittstelle Anforderungen ändern und die Schnittstelle wirkt als Komplexitätsbegrenzer.
  • Gerade bei Add-ons ist es nicht nur erforderlich, auf die zusätzlich gewonnene Funktionalität zu achten, sondern auch auf Fragen der Pflege und Anpassung. 

Werden diese Hinweise befolgt, wird die Architekturgestaltung zum strategischen Werkzeug im Projekt.
 

Folge 5: Auswahl von Software, Beratern, Dienstleistern
In jedem großen Reorganisations- und IT-Projekt kommt es über den gesamten Projektverlauf immer wieder zu der Notwendigkeit, Software, Berater oder andere Dienstleister auszuwählen. Während zu Beginn des Projektes der Auswahl noch eine gewisse Systematik zugrundegelegt wird, neigen viele Projekte dazu, später den einfachsten Weg zu gehen und irgendeinen gerade verfügbaren Dienstleister oder Berater auszuwählen bzw. blindlings auf das Software-Produkt, das ihnen der ausgewählte Anbieter empfiehlt, zu setzen.

Solche Entscheidungen rächen sich fast immer und ich rate daher dringend davon ab.

In einem mir bekannten Projekt wurde ein „beliebiger“ Berater damit beauftragt, ein komplexes Finanzsystem auszuwählen. Irgendeine Form der Qualifizierung dieses Beraters fand nicht statt. Auf mein Betreiben hin wurde der Berater dann unverzüglich freigestellt, nachdem bekannt wurde, dass er 138.000 EUR Beratungsaufwand verbraucht hatte, um die Zahl der infrage kommenden Anbieter auf nur noch zehn „zu reduzieren“. Der Aufwand war also aus Sicht des Projektes völlig vergebens.

Unabhängig, ob Software, Berater oder Dienstleister, am Anfang sollten lösungsneutral formulierte Anforderungen an das Projekt oder die Dienstleistung stehen. Leider wird im Projekt aus vermeintlichem Zeitdruck häufig darauf verzichtet. Die kurzfristige Entlastung beim Zeitdruck führt aber häufig zu ungeklärter Vertragslage, hohem Anlaufaufwand, Missverständnissen in der Projektorganisation und anderen Problemen.

Die wesentliche Rolle eines Trusted Advisors an dieser Stelle ist es, die langfristige gedeihliche Entwicklung des Projektes im Auge zu behalten und sich deutlich gegen solche „Abkürzungen“ auszusprechen.

Nachdem entscheidungsrelevante Anforderungen aufgestellt wurden, sind ausreichende Alternativen zu suchen und zu bewerten. Dabei ist darauf zu achten, dass es sich um echte Alternativen handelt. Mehrere Systemhäuser desselben ERP-Anbieters kommen nur dann in Frage, wenn das ERP-Produkt selbst bereits feststeht. Regionale Nähe kann hilfreich sein, ist aber bei Spezialfragen z. B. der Datenbank-Performance kein Kriterium für die Auswahl.

Die Alternativen sollten geprüft werden, bevor ein Auswahlvorschlag unterbreitet wird. Bei Produkten oder Dienstleistungen mit hoher Bedeutung für das Erreichen des Projektzieles nimmt der Trusted Advisor an der Prüfung der Alternativen teil. Die Entscheidung für ein Produkt oder eine Dienstleistung sollte mit der Erfüllung der zuvor vereinbarten Anforderungen begründet werden. Den abzuschließenden Vertrag prüft der Trusted Advisor ebenfalls, um eine einseitige Risikoabwälzung auf den Auftraggeber zu vermeiden.
 

Folge 6: Muss der Starttermin verschoben werden?
Komplexe Reorganisations- oder IT-Projekte werden auf einen bestimmten Starttermin hin geplant. Ab diesem Termin soll die Reorganisation wirksam werden oder das neue Informationssystem produktiv gehen. Im Zuge der Projektplanung werden interne und externe Ressourcen so eingeplant, dass der Starttermin gehalten werden kann. In gut betreuten Projekten gibt es regelmäßige Besprechungen eines Lenkungsausschusses, in denen über die noch ausstehenden Schritte zur Zielerreichung informiert wird und auch über potenzielle Risiken gesprochen wird. In allen Projekten gibt es derartige Risiken. Als Trusted Advisor stelle ich sicher, dass diese Informationen den Lenkungsausschuss stets ungefiltert erreichen (Manchmal hat der Projektleiter ein Interesse daran, das Projekt in einem besseren oder schlechteren Licht erscheinen zu lassen als es der Realität entspricht).

Der angestrebte und kommunizierte Zieltermin hat dabei eine erhebliche Bindungswirkung. Nur weil der neue Berliner Hauptbahnhof zur Fußball-WM 2006 fertig werden musste, wurde er fertig, wenn auch mit unvollständigem Dach. Für den Berliner Flughafen, ein vergleichsweise anspruchsloses Projekt, steht auch sechs Jahre (!) nach der angestrebten Eröffnung noch immer kein neuer Termin fest. Daher weiß jeder Projektbeteiligte, dass er sich beliebig viel Zeit lassen kann.

Deswegen muss ein Starttermin kommuniziert werden und es sollte soweit irgend möglich auch an ihm festgehalten werden. Verheerend für die Stimmung im Projekt wäre eine langfristige Vorankündigung, dass der Starttermin "sowieso" verschoben wird. Prompt wird sich niemand mehr beeilen, kritische Fragen zu entscheiden, die erforderlichen Konzepte abzuschließen und das notwendige zusätzliche Engagement zu entfalten. Falls es kritisch wird, sollte in angemessener Zeit vor dem geplanten Starttermin durch den Projektleiter zusammengetragen werden, was zwingend erforderlich ist, um den Starttermin noch halten zu können. Teilweise kann mit Workarounds gearbeitet werden, gelegentlich sind auch Teilinbetriebnahmen möglich. Vorab muß eine klare Einschätzung erfolgen, ob die unabdingbaren Voraussetzungen zum Start geschaffen werden können oder nicht. Nur wenn feststeht, dass wesentliche Bedingungen in der verbleibenden Zeit nicht mehr zu erfüllen sind, dann ist der Starttermin um eine genau definierte Zeit zu verschieben. Die Verschiebung und die Gründe dafür sind umfassend zu kommunizieren.

Häufig jedoch gelingt es, den Starttermin zu halten. Auch wenn der Start gelegentlich holprig erfolgt, hat dies einen unschätzbaren Vorteil: Alle noch verbliebenen Unzulänglichkeiten zeigen sich jetzt und können bearbeitet werden. Bis zum Produktivstart kann niemand diese Unzulänglichkeiten wirklich gut einschätzen. Daher lautet mein Rat, wenn irgend möglich, den geplanten Starttermin auch zu realisieren und unmittelbar danach in eine sehr intensive Phase der Optimierung des Produktivbetriebs einzutreten, um die Workarounds möglichst schnell eliminieren zu können.


Folge 7: Make-or-buy-Entscheidungen
In einem großen Reorganisations- oder IT-Projekt stehen nicht nur am Anfang, sondern auch während der Projektlaufzeit eine Vielzahl von Entscheidungen an, bei denen die Alternative „make or buy“ heißt. Damit verbindet sich die Frage, ob eine Leistung von den Mitarbeitern im eigenen Haus erbracht oder am Markt eingekauft werden sollte.

Wenn die Frage schnell und eindeutig zu entscheiden ist, ist das kein Thema für den Trusted Advisor. In der Praxis ist die Gemengelage jedoch häufig komplizierter. Hilfreich ist es daher, die verschiedenen Alternativen (gelegentlich gibt es auch mehrere „make“ oder „buy“-Alternativen) nach einheitlichen Kriterien zu bewerten. Für eine Entscheidung in Richtung „make“ gehört dazu, dass im Haus genügend Kapazität und Wissen verfügbar sind, um die Leistung termingerecht erstellen zu können. Auch muss über die gesamte Nutzungsdauer der erstellten Leistung hinweg entweder intern Wartung erbracht oder extern Service eingekauft werden. Diesen Punkt können externe Anbieter oft leichter sicherstellen.

Für eine „buy“-Entscheidung spricht zunächst, wenn bereits eine vollständige Konzeption der zu erbringenden Leistung vorliegt, die auch von Externen verstanden wird. Die zu beauftragenden Externen müssen ebenfalls zeitnah Kapazitäten zur Verfügung stellen. Intern verbleibt in jedem Fall die Verpflichtung zur Abnahme der Leistung, für die stets Zeit eingeplant werden muss. Ich betone dies, weil in den von mir betreuten Projekten bei der Kapazitätsplanung durch den Projektleiter gelegentlich solche Verpflichtungen „vergessen“ werden.

Das Geltendmachung von Mängeln setzt die vollständige Beschreibung des Werkes voraus; von pauschalen Beauftragungen nach dem Motto „Macht mal und schreibt die Tage auf“ kann der Trusted Advisor nur abraten. Dies führt mit Sicherheit zu einer drastischen Überschreitung der geplanten Kosten. 

Ein aktueller Fall: Dieses Beispiel betrifft den Aufbau eines Data Warehouses. Dieses wurde in einigen (nicht allen) Dimensionen bisher vom Anbieter der Software erstellt. Nun liegen einige Standardberichte vor; weitere fehlen, ebenso wie einige für das Kerngeschäft des Kunden wichtige Auswertungsdimensionen. Diskutiert werden die Übernahme dieser Arbeiten durch die IT des Auftraggebers, die Übergabe an einen weiteren Data Warehouse-Dienstleister oder die weitere Bearbeitung durch den bisherigen Anbieter.

Entzündet hatte sich diese Diskussion an der äußerst unkomfortablen Wartungsmöglichkeit des Data Warehouses, die auf kryptischen Textdateien basiert, für die kein angemessenes Pflegewerkzeug zur Verfügung steht. Auch wurden des öfteren die Mitarbeiter des Softwareanbieters dabei beobachtet, wie sie verschiedene Wege durch Editieren der Textdateien ausprobierten - und dabei gelegentlich das Data Warehouse lahmlegten. Grundsätzlich ist hier nach Ansicht des Trusted Advisors die Eignung der Data Warehouse Software als solche in Frage zu stellen. Ein Vergleich der drei oben geschilderten Alternativen zeigte dann, dass der weitere Aufbau des Data Warehouses durch den Softwareanbieter und die anschließende Übergabe der Pflege in die Hände der Kunden-IT den richtigen Weg darstellt. Das Abfragen der angelegten Dimensionen unter Berücksichtigung historischer Daten ist damit durch die Endanwender selbst problemlos möglich.

 

Folge 8: Wie wird die IT betrieben?
Bei komplexen Projekten kommt es häufig auch zu wesentlichen Änderungen der eingesetzten Informationssysteme. Spätestens, wenn wesentliche Erweiterungen der Hardware anstehen, stellt sich die Frage nach dem Betriebsort der IT. 

Empfehlenswert ist es, diese Frage nicht spontan und aus dem Bauch heraus zu entscheiden. In den allermeisten Fällen sind die Daten beim professionellen Dienstleister im Rechenzentrum in Deutschland sicherer als bei der heimischen IT. Letztere muss sich häufig um viele andere Dinge mitkümmern und hat meist wenig Zeit für den aktuellen Stand des Wissens zum Betrieb eines Data Center. Um das Thema angemessen zu entscheiden, sind drei Fragen zu klären:

  • Wie wird sich das Business, insbesondere die dort entstehende Datenmenge entwickeln?
  • Wie stark ist der Einfluss der IT auf die eigene Wettbewerbsfähigkeit?        
  • Wie professionell soll in Zukunft die eigene IT-Mannschaft aufgestellt sein?

In vielen Fällen weisen die Antworten auf diese Fragen in Richtung externer Betrieb der IT-Infrastruktur, ob als Co-Location oder als echtes Outsourcing. 

Hier möchte ich genauer auf den Fall eingehen, dass der Betrieb der Infrastruktur in eigener Hand bleiben soll. Auch dafür kann es gute Gründe geben, dennoch muss Vorsorge für die Zukunft getroffen werden. Das betrifft Fragen der Anpassungsfähigkeit genauso wie die Qualifizierung des eigenen Personals. Leider kommt es immer wieder vor, dass Unternehmerinnen und Unternehmer hier nicht weit genug denken. Der Fachkräftemangel ist in der IT besonders groß, denn beim Betrieb der IT-Infrastruktur können Angelernte oder Umgeschulte meist keinen wertvollen Beitrag liefern.

Daher sollten Unternehmen, die auch in Zukunft ihre eigene IT betreiben wollen, schon jetzt die Fachkräfte dafür allokieren, die sie in einigen Jahren dringend brauchen werden.

 

Folge 9: Schnittstellen oder integriertes System
Die Vereinheitlichung, Vereinfachung und Standardisierung der betrieblichen Anwendungssysteme ist eine Herkulesaufgabe. Die steigende Komplexität von Prozessen und Produkten, veränderte und immer stärker differenzierte Anforderungen von Märkten und Kunden erzeugen in den meisten Unternehmen eine tief differenzierte Landschaft aus unterschiedlichen Systemen mit unterschiedlichen Technologien, Funktionsumfängen und Prozessabdeckungen. Diese, häufig einem Flickenteppich gleichende Menge von Anwendungssystemen, wird durch eine große Zahl ebenso heterogener und zumeist nur unzureichend dokumentierter Schnittstellen zusammengehalten.

Da wirkt der von Anbietern gern vorgetragene Hinweis, durch ein integriertes System könne man die ganzen Probleme gewissermaßen unsichtbar machen und damit zum Verschwinden bringen, sehr verheißungsvoll. Meine Aufgabe als Trusted Advisor ist es hier meistens, die schöne Illusion erst als solche zu entlarven und anschließend zu zerstören. Meine Argumentation basiert dabei zumeist auf folgenden beiden Säulen:

Zum einen sind nicht alle Schnittstellen gleich. Wenn die IT ein Systemdiagramm zeichnet, sind alle "Kästchen" (=Systeme) mit "Linien" (=Schnittstellen) verbunden, die zwar gleich aussehen, aber sehr unterschiedlich ausgeprägt sein können, u.a. im Hinblick auf Frequenz, Strukturtiefe der übertragenen Daten, Richtung und Volumen. So muss z. B. eine Schnittstelle zwischen Webshop und ERP kaufmännische Auftragsdaten an das ERP übermitteln und Bestandsdaten abgleichen. Jedoch muss nur der Austausch von Bestandsdaten sehr schnell gehen, die Zuordnung der Umsätze zu Warengruppen und Kundensegmenten hingegen kann auch mal bis zum Feierabend warten. Wenn jetzt in einem integrierten System Performanceprobleme auftreten, dann ist die Ursache dafür nicht auf den ersten Blick zu erkennen. Bei einer Schnittstelle hingegen bestehen Eingriffsmöglichkeiten, ohne die beiden verbundenen Systeme überhaupt auch nur anzurühren. Von daher plädiere ich für eine systematische Bestandsaufnahme, Strukturierung und Differenzierung von Schnittstellen. Nur diejenigen, die sehr zeitnah in beide Richtungen Daten übertragen müssen, sind überhaupt als Kandidaten für eine Ablösung durch ein integriertes System geeignet.

Für alle Schnittstellen hingegen gilt mein zweites Argument: Schnittstellen helfen bei der Komplexitätsbewältigung. Liegt eine gut dokumentierte und belastbare Schnittstelle vor, können Änderungen im Ziel- und Quellsystem unabhängig voneinander und zu verschiedenen Zeitpunkten vorgenommen werden, solange die Schnittstelle gleich bleibt. Von daher kann der Änderungsaufwand und -zeitumfang durch Schnittstellen deutlich reduziert werden. Dies führt unmittelbar zu schnelleren Änderungszyklen - weil es ja nicht so aufwendig ist - und damit zu aktuelleren Systemen.

Von daher empfehle ich in denen von mir als Trusted Advisor betreuten Produkten stets, Schnittstellen als bewusste Gestaltungselemente beim Umbau der Informationssystemarchitektur anzusehen und nicht den verlockenden Versprechungen der Anbieter zu erliegen, die Schnittstellen überflüssig machen wollen. Die vermutliche Erleichterung macht sich nämlich sofort in einer sehr deutlichen Komplexitätssteigerung des integrierten Systems bemerkbar - mit dem Ergebnis, dass selbst kleine Änderungen sehr lange dauern und sehr teuer sind. Hinzu kommt, dass die meisten "integrierten" Systeme der Anbieter häufig gar keine integrierten Systeme sind, sondern ebenfalls aus einer Menge durch interne Schnittstellen verbundenen Systemen bestehen - mit dem Unterschied, dass der Anwender an diese Schnittstellen nicht so leicht herankommt.

 

Folge 10: Standardsoftware oder Eigenentwicklung
Nicht nur einmal taucht in komplexen IT- und Reorganisationsprojekten die Frage auf, ob die Abbildung eines Prozesses oder einer Leistungserstellung besser durch eine marktverfügbare Standardsoftware oder durch eine Eigenentwicklung erfolgen sollte. Wenn Sie jetzt konkrete Fälle im Kopf haben und denken das ist doch klar, dann lesen Sie bitte auf jeden Fall weiter; Sie könnten sich irren.

Was sind die Argumente für Standardsoftware? Ihr Einsatz verkürzt die Projektdauer, da bereits fertig definierte Lösungsbausteine zur Verfügung stehen, die nur noch angepasst werden müssen. Wenn dieses Argument eingehalten werden kann und passende marktverfügbare Software identifiziert und zum Beispiel im Rahmen eines systematischen Auswahlverfahrens ermittelt wird, dann ist die Entscheidung für Standardsoftware richtig.

Individualsoftware zeichnet sich dadurch aus, dass nur das entwickelt wird, was auch tatsächlich benötigt wird. Typischerweise sind Individualentwicklungen daher softwaretechnisch deutlich schlanker als bei Realisierung mit einer umfassend durchkonfigurierten Standardsoftware. Wenn die Anforderungen auf lange Sicht konstant bleiben und geeignete Entwicklungsteams gefunden werden (aber bitte SCRUM-zertifiziert und auf modularer interoperabler Technologiebasis), dann ist Individualentwicklung die richtige Entscheidung.

Anhand einiger Beispiele aus meiner Praxis als Trusted Advisor möchte ich Ihnen aufzeigen, dass jedes Thema als Einzelfall behandelt werden muss:

Da ist zunächst ein Finanzdienstleister, der ein komplexes Modell mit Regeln aufgestellt hat, um erzielte Einnahmen an seine Stakeholder zu verteilen. Hier wurde eine Individualentwicklung favorisiert, wobei der Regeleditor zur Anpassung der Regeln so ausgelegt wurde, dass diese ohne weitere Entwicklung durch Benutzer angepasst werden können. Damit ist eine langjährige Verwendbarkeit sichergestellt. Im gleichen Unternehmen wurde darüber hinaus ein Verfahren benötigt, welches mehrere 1000 Erlösquellen auf mehrere 100.000 Empfänger verteilt. Das klingt auf den ersten Blick nach mühsamer Individualentwicklung, konnte aber mittels Standardsoftware realisiert werden! Verwendet wurde eine so genannte Billing-Lösung, die zum Beispiel bei Telefongesellschaften im Einsatz ist. Das Vorzeichen ist in diesem Fall unwichtig, ss geht um das Datenmodell und die notwendigen Algorithmen. Das Projekt konnte vollständig mit Standardsoftware realisiert werden, deren Reporting angepasst wurde.

Nicht so glücklich verlief die Einführung einer Standardsoftware eines marktführenden ERP-Anbieters bei einem anderen Finanzdienstleister. Dieses Projekt habe ich forensisch evaluiert, war aber an der Auswahlentscheidung nicht beteiligt. Für eine ähnliche Aufgabe wie oben hatte der Dienstleister für die Anpassung der Software mehr als 13.000 Personentage verbrannt, ohne dass ein Ende absehbar war. Hier war der Griff zur Standardsoftware die falsche Entscheidung.

Grundsätzlich ist zu erheben, ob marktverfügbare Standard-Software an den vorliegenden Anwendungsfall angepasst werden kann. Gelegentlich sind auch Einsatzbereiche möglich, die sich nicht auf den ersten Blick erschließen. So kann der Verkauf von Eintrittskarten durchaus auch mit einem ERP-System abgewickelt werden, wenn Restriktionen in zeitlicher und personeller Art berücksichtigt werden müssen. Es ist in jedem Fall hilfreich, vor der Freigabe eines entsprechenden Projektes einen unabhängigen Dritten auf die Entscheidung schauen zu lassen.
 

Folge 11: Wer passt sich an, der Prozess oder das System?
Viele Projekte der ERP-Auswahl werden anfänglich getrieben durch den Wunsch der Auftraggeber, „möglichst im Standard zu bleiben“. Zu Beginn eines Projektes fürchten Entscheider nichts mehr als Anpassungen an Softwarelösungen.

Nach meiner Erfahrung aus einer Vielzahl von Einführungsprojekten, die ich als Trusted Advisor begleitet habe, erlischt dieser Elan sehr schnell im Verlauf des Projektes. Plötzlich müssen alle liebgewonnenen Abläufe unbedingt in die Funktionalität der neuen Software überführt werden - koste es was es wolle.

Beide Extrempositionen halte ich für grundfalsch. Weder ist es sinnvoll auf Anpassungen grundsätzlich zu verzichten noch zahlt es sich aus, das Standardsoftwaresystem praktisch nur als Entwicklungsplattform zu nutzen. Wenn man am Standard festhält, bestehen keine Probleme, jeweils auf die neueste angebotene Version der eingesetzten Software umzusteigen. Angesichts der Vielfalt neuer Funktionen, die jedes Major Release mitbringt, ist das ein klarer Vorteil. Bei starker Anpassung und damit hohen Aufwänden für das „Hochziehen“ der Software besteht die Gefahr, dass auf aktuelle Technologien und Funktionen verzichtet werden muss. Häufig wird nur deshalb auf ein Upgrade auf eine aktuelle Version verzichtet, weil der Anpassungsaufwand zu hoch ist.

Auf der anderen Seite gibt es wettgewerblich relevante Anforderungen, die zwingend umgesetzt werden müssen. Der Einsatz eines neuen Systems darf niemals zu einer Verringerung der Wettbewerbsfähigkeit führen, so dass Leistungen nicht mehr angeboten oder Services nicht mehr differenziert werden können.

Es verbleibt ein Graubereich, in dem die Entscheidung in beide Richtungen fallen könnte. Jede dieser Entscheidungen muss sorgfältig abgewogen werden. Auch die Durchsetzung von Prozessänderungen kann mühsam sein. Der Aufwand für den täglichen Betrieb der Software darf nicht vernachlässigt werden. Gelegentlich ist es sinnvoll, Anpassungen vorzunehmen, um den Prozess hinterher leichter abbilden zu können. Nicht wettbewerbsrelevante Funktionen sollten stets sehr nahe am Standard bleiben. Insbesondere vor Anpassungen, die angeblich dem Controlling dienen sollen, ist zu warnen. Spezielle Kalkulationsschemata oder Excel-Sheets, die exakt wie zuvor abzubilden sind, erzeugen jahrzehntelangen Zusatzaufwand - nur damit sich eine mittlere Führungskraft nicht umstellen muss? 

Wer sollte diese Anpassungen prüfen? Die eigenen Mitarbeiter kennen das neue ERP-System nicht und ERP-Anbieter programmieren immer alles, was der Kunde will. Daher ist es immer eine gute Idee, Anpassungskonzepte von einem neutralen Dritten überprüfen zu lassen, der sowohl auf mögliche Prozessveränderungen als auch auf die Nutzung von Funktionen im Standard-ERP hinweisen kann.
 

Folge 12: Umgang mit schwierigen Führungskräften
Im Verlauf eines komplexen IT- oder Reorganisationsprojektes kommt es unweigerlich zu einem Punkt, an denen der Belegschaft oder einzelnen Führungskräften klargemacht werden muss, dass Veränderungen erforderlich sind und dass die Entscheidung, die Veränderung auch umzusetzen, bereits gefallen ist. Schwierig kann eine Führungskraft dann werden, wenn sie sich weigert, die notwendige Veränderung gegenüber den Mitarbeiterinnen und Mitarbeitern mitzutragen und an der Umsetzung mitzuhelfen. Besonders schwierig wird es, wenn diese Führungskraft dann auch noch zum Kreis von Vorständen, Eigentümern oder Geschäftsführung (VEG) gehört. In meiner Tätigkeit als Trusted Advisor treffe ich gelegentlich auf diese schwierigen Führungskräfte.

Zunächst ist die Motivation dieser Menschen zu erfragen. Nur selten wird aus purer Lust an der Obstruktion eine Verweigerungspolitik betrieben. Also ist zunächst ein Gespräch erforderlich, bei dem dann durchaus Klartext gesprochen werden kann. Bei Nicht-VEG sollte jemand aus dem VEG-Kreis anwesend sein, damit nicht unterschiedliche Kommunikationsinhalte verbreitet werden. Zeigt sich die Führungskraft nachhaltig unbeeindruckt von allen Argumenten, auch von den konkreten Vorteilen für sie selbst bei Umsetzung des Projektes, dann muss überlegt werden, ob diese Führungskraft an anderer Stelle besser eingesetzt werden kann. Sind die Differenzen kaum überbrückbar, wird man sich von dieser Führungskraft auch trennen müssen, wenn der Projekterfolg nicht gefährdet werden soll. Dies muss gegenüber VEG unmissverständlich deutlich gemacht werden!

Besonders schwierig wird es, wenn diese Führungskraft selbst der VEG-Ebene angehört. Hier muss akzeptiert werden, dass es das Vorrecht zumindest des Eigentümers ist, auch törichte und sogar falsche Entscheidungen zu treffen. Mein amerikanischer Beratercoach Dr. Alan Weiss pflegt zu sagen "Berater werden fürs Beraten bezahlt, nicht fürs Umsetzen". Zudem bleibt es dem Trusted Advisor stets unbenommen, sein Engagement zu beenden, wenn das Unternehmen nachhaltig und mehrfach auf seine Ratschläge nicht gehört hat.

Idealerweise werden diese krisenhaften Zuspitzungen aber dadurch vermieden, dass ein partizipativer Kurs im Projekt gefahren wird und stets alle Stakeholder mitgenommen werden. Die Betonung liegt hier auf allen Stakeholdern und nicht nur auf den offensichtlichen! Mir ist es schon passiert, dass ich die Geschäftsführungsebene eines mittelständischen Gruppenunternehmens zwar an Bord hatte, aber die Eigentümer teilweise ganz andere Prioritäten setzen wollten. Niemals ist es möglich, gegen den Willen des echten "Economic Buyers" solche Veränderungen durchzusetzen. Ein guter Trusted Advisor erkennt den echten "Economic Buyer" und holt ihn oder sie mit an Bord.