IT Unternehmensberatung

Aufgaben der IT-Beratung

Eine IT-Unternehmensberatung unterstützt dabei, IT-Vorhaben an den Zielen und Abläufen eines Unternehmens auszurichten. Dazu gehören Entscheidungen über Eigenentwicklung oder externe Lösungen, die Auswahl passender Software und die Steuerung ihrer Einführung. Bei der Digitalen Transformation müssen Anforderungen, verfügbare Fähigkeiten und die Folgen für bestehende Systeme gemeinsam betrachtet werden. Klare Kriterien und nachvollziehbare Entscheidungen erleichtern es, Investitionen zu priorisieren und Projekte kontrolliert umzusetzen.

IT-Strategie und Architektur

Bei einer IT-Strategieberatung ist Make-or-buy die Entscheidung, ob eine Leistung selbst entwickelt oder betrieben oder als externe Lösung bezogen wird. Maßgeblich ist zunächst das Unternehmensziel: Unterstützt eine Anwendung ein Alleinstellungsmerkmal, kann die eigene Entwicklung mehr Gestaltungsspielraum bieten. Für standardisierte Abläufe wie die Lohnabrechnung ist eine erprobte externe Lösung häufig naheliegender, sofern sie die fachlichen Anforderungen erfüllt.

Auch interne Fähigkeiten zählen. Für eine Eigenentwicklung braucht es nicht nur Entwicklerinnen und Entwickler, sondern je nach System auch Produktverantwortung, Wartung und ausreichend Kapazität für Störungen und Weiterentwicklungen. Beim Fremdbezug verschiebt sich der Aufwand auf Anbieterauswahl, Vertragssteuerung, Integration und den laufenden Betrieb der Schnittstellen. Eine Lösung, für die internes Wissen fehlt, kann trotz niedriger Einführungskosten langfristig schwer steuerbar sein.

Verglichen werden sollten die Gesamtkosten über einen festgelegten Zeitraum, etwa drei bis fünf Jahre. Neben Entwicklung oder Lizenz fallen Implementierung, Schulung, Wartung, interne Arbeitszeit und gegebenenfalls spätere Ablöse- oder Wechselkosten an. Auf Architekturebene ist zu prüfen, welche Daten und Anwendungen angebunden werden, ob offene Schnittstellen verfügbar sind und wie stark Prozesse von einem Anbieter abhängig werden. Eine externe Anwendung kann etwa Folgeaufwand verursachen, wenn sie proprietäre Datenformate nutzt oder Änderungen an anderen Systemen erzwingt.

Als Entscheidungshilfe eignen sich drei Fragen: Ist die Funktion strategisch differenzierend? Sind dauerhaft passende Fähigkeiten und Kapazitäten vorhanden? Bleiben Kosten und Abhängigkeiten über den Lebenszyklus vertretbar? Überwiegen strategischer Nutzen und interne Kompetenz, spricht mehr für Eigenentwicklung oder Eigenbetrieb. Bei einer standardisierten Funktion und tragfähiger externer Lösung ist der Bezug meist einfacher zu begründen; entscheidend ist der dokumentierte Vergleich der Gesamtfolgen.

Softwareauswahl und Ausschreibung

Eine Softwareauswahl beginnt mit einer nachvollziehbaren Beschreibung des Bedarfs. Das Lastenheft hält fest, was der Auftraggeber benötigt: betroffene Geschäftsabläufe, Nutzergruppen, Muss- und Wunschfunktionen sowie Rahmenbedingungen wie Schnittstellen und Datenformate. Das Pflichtenheft beschreibt dagegen, wie ein Anbieter die Anforderungen technisch und organisatorisch umsetzen will. Es konkretisiert beispielsweise Module, Integrationen, Zuständigkeiten und Liefergegenstände. Werden beide Dokumente verwechselt, bleiben Angebote schwer vergleichbar und Abweichungen im Projekt leichter unentdeckt.

Im Lastenheft sollten Anforderungen eindeutig und prüfbar formuliert werden. Statt „schnelle Suche“ kann etwa verlangt werden, dass berechtigte Beschäftigte Datensätze anhand festgelegter Felder filtern können. Jede Anforderung erhält eine Kennung, eine Priorität und ein Verfahren zur Abnahme. In der Ausschreibung kann der Anbieter dann angeben, ob sie standardmäßig erfüllt, durch Konfiguration abgedeckt oder individuell entwickelt wird. Diese Zuordnung macht Zusatzaufwand sichtbar, bevor eine Entscheidung getroffen wird.

Eine gewichtete Scorecard ordnet den Kriterien eine Bedeutung zu und bewertet Angebote auf einer einheitlichen Skala von 1 bis 5. Die folgende Beispielrechnung ist hypothetisch: Die Punktzahl je Kriterium wird mit seinem Gewicht multipliziert; die Summe der gewichteten Werte ergibt die Gesamtwertung auf derselben Skala.

Beispiel einer gewichteten Scorecard für zwei Lösungsansätze

Kriterium	Gewicht	Standardsoftware	Eigenentwicklung
Funktionalität	35 Prozent	4 von 5	5 von 5
Sicherheit	25 Prozent	4 von 5	3 von 5
Integration	25 Prozent	3 von 5	4 von 5
Betriebsaufwand	15 Prozent	5 von 5	2 von 5
Gesamtwert	100 Prozent	3,9 von 5	3,8 von 5

Die Gewichte spiegeln die Prioritäten des Unternehmens wider; die Bewertungen müssen durch konkrete Nachweise gestützt werden, etwa eine Produktvorführung, ein Schnittstellenkonzept oder Angaben zum Betriebsmodell. Im Beispiel ergibt sich für die Standardsoftware 3,9 und für die Eigenentwicklung 3,8 Punkte. Die Gesamtzahl ersetzt keine fachliche Prüfung: Ein nicht verhandelbares Muss-Kriterium darf nicht durch gute Werte in anderen Kategorien ausgeglichen werden. Für eine belastbare Auswahl werden deshalb Scorecard, Einzelbegründungen und Abweichungen gemeinsam dokumentiert.

Projektsteuerung und Vorgehensmodelle

Scrum, Kanban und Wasserfall unterscheiden sich darin, wann geplant, angepasst und dokumentiert wird. Scrum organisiert die Arbeit in zeitlich begrenzten Sprints von höchstens einem Monat. Zu Beginn wird ein Sprint-Ziel festgelegt, am Ende werden Ergebnisse überprüft und nächste Schritte angepasst. Die regelmäßigen Prüfzeitpunkte machen Fortschritt und offene Fragen sichtbar; Änderungen am Arbeitsumfang werden typischerweise für die weitere Planung berücksichtigt.

Kanban steuert dagegen einen fortlaufenden Arbeitsfluss. Aufgaben werden auf einem sichtbaren Board durch definierte Zustände geführt, zum Beispiel „offen“, „in Bearbeitung“ und „erledigt“. Begrenzungen für gleichzeitig begonnene Aufgaben, sogenannte Arbeitslimitierungen, helfen dabei, Engpässe zu erkennen. Anders als bei Scrum sind feste Iterationen nicht zwingend erforderlich: Prioritäten und Ablauf können laufend angepasst werden, während Durchlaufzeiten und blockierte Aufgaben beobachtet werden.

Das Wasserfallmodell legt stärker vorab fest, welche Phasen aufeinander folgen, etwa Anforderungsdefinition, Entwurf, Umsetzung, Test und Einführung. Übergänge werden häufig durch Freigaben und umfangreiche Dokumentation abgesichert. Das erleichtert die Kontrolle von Meilensteinen und vereinbarten Liefergegenständen, macht spätere Änderungen aber aufwendiger, wenn sie bereits abgeschlossene Phasen berühren. Scrum und Kanban ermöglichen häufigere Anpassungen, verlangen dafür regelmäßige Abstimmung und eine klare Priorisierung des Arbeitsbestands.

Das V-Modell XT ist ein Projektstandard der deutschen Bundesverwaltung. Es strukturiert Rollen, Ergebnisse und Vorgehensbausteine und stellt Anforderungen sowie Entwurfsschritte passenden Prüf- und Testaktivitäten gegenüber. Der Umfang kann an das jeweilige Vorhaben angepasst werden; ein Projekt erhält damit definierte Nachweise und Verantwortlichkeiten, ohne dass jedes Vorhaben denselben Umfang an Arbeitspaketen benötigt.

Für die Projektkontrolle sollte das Vorgehensmodell zur Unsicherheit der Anforderungen und zu den benötigten Nachweisen passen. Bei häufig wechselnden Prioritäten bieten Scrum oder Kanban kurze Rückkopplungsschleifen; bei fest vereinbarten Phasen und formalen Freigaben passt ein stärker dokumentierter Ablauf eher. Praktisch bewährt sich, vor dem Start Prüfpunkte, Zuständigkeiten und Änderungswege festzulegen und sie im gewählten Modell konsequent nachzuhalten.

Informationssicherheit und Compliance

Informationen und IT-Systeme sind für Unternehmen wichtige Werte, deren Schutz klare Zuständigkeiten und nachvollziehbare Abläufe erfordert. Ein Informationssicherheits-Managementsystem bündelt diese Abläufe und macht Risiken sowie Schutzmaßnahmen überprüfbar. Standards und Methoden bieten dafür unterschiedliche Rahmen: Die IT-Sicherheitsberatung kann bei der Einordnung helfen, welches Vorgehen zu Größe, Schutzbedarf und Zielen eines Unternehmens passt. Datenschutz und Informationssicherheit greifen bei personenbezogenen Daten ineinander, verfolgen aber nicht denselben Zweck.

ISO/IEC 27001 und BSI IT-Grundschutz

Ein Informationssicherheits-Managementsystem, kurz ISMS, beschreibt strukturierte Prozesse, mit denen ein Unternehmen Risiken für Informationen erfasst, bewertet, behandelt und regelmäßig überprüft. Dazu gehören ein festgelegter Geltungsbereich, Verantwortlichkeiten, Risikobewertungen und die Kontrolle vereinbarter Maßnahmen. Ein ISMS ist kein einzelnes IT-Produkt: Es verbindet organisatorische Vorgaben mit technischen und betrieblichen Abläufen.

ISO/IEC 27001 und der IT-Grundschutz des Bundesamts für Sicherheit in der Informationstechnik verfolgen dieses Ziel mit unterschiedlichen Rahmen und Arbeitsweisen.

Vergleich von ISO/IEC 27001 und BSI IT-Grundschutz

Merkmal	ISO/IEC 27001	BSI IT-Grundschutz
Rahmen	Internationaler Standard für Anforderungen an ein ISMS; aktuelle Ausgabe ISO/IEC 27001:2022.	Deutsche Methode des Bundesamts für Sicherheit in der Informationstechnik mit dem IT-Grundschutz-Kompendium.
Aufbau	Die Organisation legt ihr ISMS und die Risikobehandlung fest. Anhang A enthält 93 Referenzmaßnahmen in vier Themenbereichen.	Das Kompendium ordnet Anforderungen in Bausteinen. Die BSI-Standards 200-1 und 200-2 beschreiben Anforderungen und Vorgehensweise.
Risikobearbeitung	Maßnahmen werden anhand der eigenen Risiken ausgewählt und ihre Anwendbarkeit dokumentiert.	Bausteine unterstützen die Modellierung; Schutzbedarf wird in die Kategorien normal, hoch und sehr hoch eingeordnet.
Nachweis und Einsatz	Eine Zertifizierung kann durch eine akkreditierte Zertifizierungsstelle erfolgen; sie ist für die meisten Unternehmen freiwillig.	Die Bausteine bieten eine methodische Grundlage für die Umsetzung. Ein Zertifikat ist nicht automatisch mit der Anwendung des Kompendiums verbunden.

ISO/IEC 27001 setzt damit Anforderungen an das Managementsystem, während der BSI IT-Grundschutz eine konkrete, bausteinbasierte Methode zur systematischen Umsetzung bereitstellt. Unternehmen können den Grundschutz als Vorgehensmodell nutzen und zugleich prüfen, ob eine Zertifizierung nach ISO/IEC 27001 für ihre Kundenanforderungen oder Geschäftsbeziehungen relevant ist.

Datenschutz und IT-Sicherheit

Die Datenschutz-Grundverordnung (DSGVO) schützt personenbezogene Daten, also Informationen, die sich auf eine identifizierte oder identifizierbare natürliche Person beziehen. IT-Sicherheit richtet sich dagegen auf sämtliche Informationswerte eines Unternehmens. Dazu zählen personenbezogene Daten ebenso wie Konstruktionspläne, Zugangsdaten, Produktionsinformationen und technische Betriebsdaten.

Die Bereiche überschneiden sich beispielsweise, wenn Beschäftigtendaten in einem Personalverwaltungssystem verarbeitet werden. Zugriffsrechte, Verschlüsselung und Protokollierung können dann sowohl zum Schutz der Daten als auch zur Absicherung des Systems beitragen. Artikel 32 der DSGVO verlangt geeignete technische und organisatorische Maßnahmen für die Sicherheit der Verarbeitung; welche Maßnahmen angemessen sind, hängt unter anderem von Risiko und Art der Verarbeitung ab.

Umgekehrt kann ein Unternehmen IT-Sicherheitsmaßnahmen für Informationen benötigen, die keinen Personenbezug haben, etwa für vertrauliche Produktentwürfe oder den Zugriff auf ein Produktionsnetzwerk. Solche Maßnahmen fallen in den Bereich der Informationssicherheit, auch wenn die DSGVO dafür nicht der maßgebliche Rechtsrahmen ist. Datenschutz und IT-Sicherheit sollten deshalb aufeinander abgestimmt, aber anhand ihrer jeweiligen Schutzziele bewertet werden. Praktisch bewährt sich eine gemeinsame Betrachtung der betroffenen Systeme und Daten: So lassen sich Datenschutzpflichten und der Schutz weiterer Unternehmenswerte konsistent berücksichtigen.

Cloud-Migration in Etappen

Eine Cloud-Migration beginnt mit einem belastbaren Überblick über Anwendungen, Daten und technische Verbindungen. Die Bewertung zeigt, welche Systeme zuerst umziehen können und wo Anpassungen oder eine andere Lösung nötig sind. Bei der Wahl des Betriebsmodells zählt vor allem, wer die Infrastruktur betreibt: ein externer Anbieter, die eigene Organisation oder beide gemeinsam. Eine schrittweise Planung macht Aufwand, Abhängigkeiten und mögliche Ausstiegswege früh sichtbar.

Bewertung der Anwendungen

Ein Anwendungsinventar erfasst für jedes System unter anderem Zweck, Nutzergruppen, Daten, Schnittstellen und technische Voraussetzungen. Für die Reihenfolge der Cloud-Migration werden Geschäftswert, technische Eignung und Abhängigkeiten getrennt bewertet: Ein wichtiges System kann geschäftlich relevant, aber wegen enger Kopplung an lokale Datenbanken zunächst ungeeignet sein. Die folgenden Prüfpunkte machen sichtbar, welche Faktoren Aufwand und Priorität beeinflussen.

• Geschäftswert: Erfassen Sie, welche Arbeitsabläufe die Anwendung unterstützt, wie viele Beschäftigte sie nutzen und welche Folgen ein Ausfall für Aufträge oder interne Fristen hätte.
• Technische Eignung: Prüfen Sie Betriebssystem, Laufzeitumgebung, Datenbank und Lizenzmodell; eine Anwendung mit veralteter, nicht unterstützter Software benötigt häufig zuerst technische Anpassungen.
• Abhängigkeiten: Dokumentieren Sie Schnittstellen, gemeinsame Datenbestände und Authentifizierungsdienste, damit verbundene Systeme nicht unabhängig voneinander migriert und dadurch vorübergehend getrennt werden.
• Daten und Übertragung: Erfassen Sie Datenvolumen, Änderungsraten und erforderliche Übertragungsfenster; mehrere Terabyte können die Dauer und den Ablauf einer Datenverlagerung deutlich beeinflussen.
• Betriebsanforderungen: Halten Sie Verfügbarkeitsbedarf, Wartungsfenster und Anforderungen an den Datenstandort fest, bevor Sie ein geeignetes Betriebsmodell auswählen.

Anwendungen mit geringem Vernetzungsgrad und klarer technischer Unterstützung lassen sich oft früher einplanen; gemeinsam genutzte Datenbanken oder viele Schnittstellen erhöhen Koordinationsaufwand und Testbedarf. Public Cloud bedeutet, dass ein externer Anbieter die Infrastruktur betreibt; bei einer Private Cloud liegt der Betrieb bei der Organisation selbst. Eine Hybrid Cloud kombiniert beide Betriebsformen, etwa wenn eine Anwendung extern läuft und ein angebundenes System im eigenen Rechenzentrum verbleibt.

Gängige Migrationsstrategien

Die passende Migrationsstrategie richtet sich danach, ob eine Anwendung unverändert weiterlaufen kann, technische Anpassungen benötigt oder durch eine andere Lösung ersetzt werden sollte. Die fünf gängigen Ansätze unterscheiden sich vor allem in Eingriffstiefe, Aufwand und dem Umfang, in dem vorhandene Systeme weitergenutzt werden.

Rehosting verlagert eine Anwendung weitgehend unverändert auf eine andere Infrastruktur, häufig auf virtuelle Maschinen in einer Cloud. Das eignet sich beispielsweise für einen älteren internen Webserver, dessen Betriebssystem noch unterstützt wird, wenn ein schneller Umzug wichtiger ist als eine grundlegende Modernisierung. Die Anwendung selbst wird dabei kaum verändert; ihre bestehenden Betriebsanforderungen bleiben daher weitgehend erhalten.

Replatforming übernimmt die Anwendung mit begrenzten Anpassungen auf eine verwaltete Plattform. Ein Unternehmen könnte etwa einen selbst betriebenen Datenbankserver zu einem verwalteten Datenbankdienst eines Anbieters verlagern, ohne die Anwendung neu zu entwickeln. Das kann den Aufwand für einzelne Betriebsaufgaben verändern, verlangt aber Tests für unterstützte Datenbankversionen, Erweiterungen und Verbindungen.

Refactoring verändert die Architektur oder den Programmcode gezielt, damit die Anwendung Cloud-Funktionen besser nutzen kann. Ein Beispiel ist ein Warenwirtschaftsportal, dessen einzelne Verarbeitungsschritte für den Betrieb in getrennten, skalierbaren Diensten neu gestaltet werden. Der Ansatz bietet mehr Gestaltungsspielraum als ein unveränderter Umzug, erfordert jedoch Entwicklungszeit, Funktionsprüfungen und einen klar geplanten Übergang zwischen alter und neuer Version.

Replace bedeutet, eine bestehende Anwendung durch ein anderes Produkt oder einen Dienst zu ersetzen. Das kann sinnvoll sein, wenn ein selbst entwickeltes Reisekostenprogramm durch eine verfügbare SaaS-Lösung abgelöst wird und deren Funktionen die Anforderungen abdecken. Vor der Entscheidung sind Datenübernahme, Schnittstellen, Anpassungsmöglichkeiten und die Vertragsbedingungen des neuen Produkts zu prüfen.

Retain lässt eine Anwendung zunächst am bisherigen Standort, statt sie in die Cloud zu verlagern. Ein Beispiel ist eine Produktionsanwendung, die eng mit einer lokalen Maschine verbunden ist und deren Betrieb bei einer Verlagerung zusätzliche technische Umbauten erfordern würde. Der Verbleib sollte als bewusste Entscheidung dokumentiert und bei Änderungen an unterstützter Hardware, Software oder Schnittstellen erneut bewertet werden.

Bei allen fünf Ansätzen gehört Anbieterbindung (Lock-in) zur Abwägung: Proprietäre Datenformate, herstellerspezifische Schnittstellen oder stark angepasste Dienste können einen späteren Wechsel erschweren. Prüfen Sie deshalb vor der Auswahl, ob Daten in nutzbaren Formaten exportiert werden können, welche Übertragungswege verfügbar sind und welche technischen Abhängigkeiten für einen Wechsel neu aufgebaut werden müssten. Eine Exit-Planung hält außerdem fest, wer den Export verantwortet, wie Daten nach dem Wechsel geprüft werden und welche Fristen oder Kosten vertraglich gelten.

Für die Praxis empfiehlt sich, jede Anwendung einzeln zuzuordnen: erst Abhängigkeiten und Exportmöglichkeiten klären, dann die Strategie mit passendem Aufwand wählen und einen möglichen Ausstieg von Anfang an mitplanen.

IT-Beratung abgrenzen

Bei der Auswahl externer Unterstützung zählt nicht allein die Bezeichnung des Anbieters, sondern welche Leistung tatsächlich vereinbart wird. Eine IT-Unternehmensberatung kann Konzepte entwerfen und deren Umsetzung prüfen, ohne den laufenden Betrieb zu übernehmen. Ein Systemhaus verbindet häufig Beratung oder technische Umsetzung mit dem Verkauf von Produkten; der genaue Leistungsumfang hängt vom Vertrag ab. Managed Services sind dagegen auf den fortlaufenden Betrieb festgelegter Systeme oder Dienste ausgerichtet. Auch die Vergütung und mögliche wirtschaftliche Interessen sollten zur angebotenen Rolle passen.

Beratung und IT-Betrieb

Die Rollen unterscheiden sich vor allem darin, ob ein Anbieter eine Lösung entwirft, sie technisch bereitstellt oder den Betrieb dauerhaft übernimmt. Eine Beratung kann Anforderungen aufnehmen, Optionen bewerten und die Umsetzung anhand vereinbarter Kriterien prüfen. Daraus folgt nicht automatisch, dass sie Störungen behebt oder Systeme rund um die Uhr überwacht. Beim Systemhaus beziehungsweise IT-Dienstleister können Planung, Beschaffung, Einrichtung und Support zusammenkommen; welche davon geschuldet sind, ergibt sich aus dem Auftrag.

Rollen, Verantwortung und typische Vergütung im Vergleich

Anbieterform	Typische Aufgabe	Verantwortung	Zahlungslogik
IT-Beratung	Konzept erstellen, Optionen vergleichen und Umsetzung prüfen	Verantwortung für vereinbarte Beratungsergebnisse und Prüfschritte; kein automatischer Systembetrieb	Abrechnung nach Tagessatz, Stundenaufwand oder festem Projektumfang
Systemhaus oder IT-Dienstleister	Technik liefern, einrichten und je nach Auftrag unterstützen	Verantwortung für konkret beauftragte Liefer-, Einrichtungs- und Supportleistungen	Produkt- oder Lizenzkosten, Projektpreis und gegebenenfalls gesonderte Supportgebühr
Managed Services	Vereinbarte Systeme laufend betreiben und überwachen	Verantwortung für definierte Betriebsleistungen und Servicezeiten laut Vertrag	Wiederkehrende Gebühr, etwa je Nutzer, Gerät oder betreutem Dienst

Die Übergänge sind in der Praxis nicht immer scharf: Ein Systemhaus kann zusätzlich einen laufenden Dienst anbieten, und eine Beratung kann die technische Umsetzung begleiten. Entscheidend ist, einzelne Leistungen und Zuständigkeiten im Vertrag voneinander abzugrenzen. Dazu gehören etwa die Frage, wer Änderungen freigibt, wer bei einer Störung reagiert und welche Betriebszeiten vereinbart sind.

Managed Services bedeuten laufenden Betrieb innerhalb des vereinbarten Umfangs; sie ersetzen nicht automatisch jede interne Zuständigkeit. Auch Reaktionszeiten, ausgeschlossene Systeme und Eskalationswege sollten schriftlich festgehalten sein, statt sie aus der Anbieterbezeichnung abzuleiten. Für eine unabhängige Prüfung eines Vorhabens eignet sich ein klar begrenzter Beratungsauftrag; für den dauerhaft zugewiesenen Betrieb braucht es dagegen ein passendes Betriebs- und Servicepaket.

Herstellerunabhängigkeit und Interessenkonflikte

Herstellerunabhängigkeit bedeutet, dass Empfehlungen an den Anforderungen des Unternehmens ausgerichtet werden können, statt an einem vorab festgelegten Produkt. Für einen belastbaren Vergleich sollten die Kriterien vor der Auswahl feststehen: etwa benötigte Funktionen, technische Kompatibilität, Betriebsaufwand und Gesamtkosten über den vorgesehenen Nutzungszeitraum. So lassen sich mehrere passende Anbieter nach denselben Maßstäben bewerten, ohne ein bestimmtes Produkt allein wegen seiner Verfügbarkeit zu bevorzugen.

Ein Interessenkonflikt kann entstehen, wenn die beratende Stelle zugleich Produkte verkauft oder für vermittelte Aufträge eine Provision von einem Anbieter erhält. Ein solcher finanzieller Anreiz kann die Auswahl beeinflussen oder den Eindruck erwecken, dass eine Empfehlung nicht ausschließlich aus dem Vergleich der Anforderungen hervorgeht. Das macht eine Empfehlung nicht automatisch ungeeignet, schafft aber einen Grund, ihre Entstehung nachvollziehbar zu machen.

Vor der Beauftragung sollte offengelegt werden, ob der Anbieter an einem Produktverkauf verdient, Vermittlungszahlungen erhält oder wirtschaftlich mit einem der verglichenen Hersteller verbunden ist. Hilfreich ist außerdem eine klare Trennung zwischen Beratungshonorar und möglichen Einnahmen aus dem Verkauf sowie die Angabe, welche Anbieter in den Vergleich einbezogen wurden. Eine schriftliche Bewertungsmatrix macht sichtbar, wie die Anforderungen gewichtet wurden und weshalb eine Option besser passt als eine andere. Praktisch bewährt sich ein Auftrag, der Vergütung, mögliche Provisionen und Auswahlkriterien vor der Empfehlung transparent festhält.