Beschwerden lassen sich nie ganz vermeiden. Aber auch wenn das Management der mit diesen Kundenanliegen zusammenhängenden Prozesse nicht einfach ist, gibt es zur Unterstützung Softwarelösungen. Nur muss man die richtige wählen. Es gilt, die wichtigsten Selektionskriterien im Auswahlprozess und die besonderen Herausforderungen bei der Implementierung eines Beschwerdemanagementsystems zu kennen.
Praxisbeispiele: CRM-Suite; Best of Breed; Individualprogrammierung
Einführung einer CRM-Suite (Mineralölkonzern)
Bei einem weltweit führenden Mineralölkonzern hat man sich für die Einführung eines umfassenden Siebel-Systems entschieden. Die Begründung für diese Produktstrategie war nach einer detaillierten Voruntersuchung insbesondere darin zu sehen, dass die Funktionalitäten der Suite für alle betroffenen CRM-Bereiche ausreichend waren. Dabei war es entscheidend, dass diese Bereiche alle bereits in die Voruntersuchung eingebunden waren und ihre Anforderungen an der Software abgleichen konnten und dass ein umfangreicher Business Case im Vorfeld berechnet und während und nach Projektablauf nachkalkuliert worden ist.
Best of Breed (Touristikunternehmen)
Für einen der führenden Touristikkonzerne in Europa stellte dieser Architekturansatz die beste Lösung dar. Große Datenvolumina in einer relativ hohen Zahl von maßgeschneiderten Reservierungssystemen erforderten eine zentrale Integrationsebene, die in einer individual entwickelten Datenbank realisiert wurde. Diese wiederum dient als zentrale Schicht für die Anbindung von Speziallösungen in den verschiedenen CRM-Bereichen des Unternehmens. So auch für das Beschwerdemanagement, in dem die Standardlösung eines im Beschwerdemanagement führenden Softwareherstellers implementiert und an die zentrale Datenbank angebunden wurde. Dieses Projekt konnte im Vergleich zur alternativen Einführungen einer umfangreichen CRM-Suite sehr fokussiert und vor allem mit geringem Risiko durchgeführt werden.
Individualprogrammierung (Softwarehersteller)
Bei einem führenden deutschen Softwarehersteller und IT-Dienstleister wurden die gängigen CRM Packages gegen eine individuell angefertigte Lösung abgewogen. Ausschlaggebend für die Entscheidung für eine individuelle Lösung waren die folgenden Gründe:
– Die Integration der Kundendaten war bereits in früheren Projekten durch das Unternehmen geleistet worden. Da die betrachteten CRM-Systeme alle eine eigene Datenhaltung benötigen, hätten hier erhebliche (und architektonisch kritikwürdige) Integrationsleistungen stattfinden müssen.
– Die Funktionalität der CRM-Suiten war nur im Bereich Sales bei einem Abdeckungsgrad > 80 Prozent, in den anderen Bereichen Marketing und Service (inkl. Beschwerdemanagement) hätte weiterhin erheblicher Customizingaufwand bestanden.
Insgesamt ergab sich für eine CRM-Suite einfach kein positiver Business Case. Die von den Softwareherstellern selbst durchgeführte Berechnung ergab astronomische Gesamtkosten im zweistelligen Millionenbereich, die zirka doppelt so hoch waren wie die Individuallösung mit gleichem Funktonalitätsumfang.
Ziele der Softwareauswahl
Ziel der Auswahl eines BMS ist die Entscheidung für eine Softwarelösung, die die Anforderungen des Unternehmens im weiteren Sinne und die Bedürfnisse des Beschwerdemanagements im engeren Sinne bestmöglich unterstützt. Da die Anforderungen an die Lösung sehr unterschiedlich sein können, mündet eine solche Auswahl häufig in Zielkonflikten, die sorgfältig bewertet und abgewogen werden müssen. Insofern ist es höchst unwahrscheinlich, dass die getroffene Wahl alle Anforderungen gleichermaßen erfüllt. Vielmehr wird diese einen Kompromiss darstellen, der den ursprünglichen Zielvorstellung möglichst nahe kommt. Die Abbildung zeigt typische Fragestellungen bei der Auswahl eines BMS.
Die hinter diesen Fragen liegenden Anforderungen sind zu detaillieren, konkretisieren, in Auswahlkriterien zu übersetzen und messbar zu machen. Gleichzeitig müssen abgrenzbare Kriteriengruppen gebildet werden, um eine gewichtete Konsolidierung der Ergebnisse zu erlauben und damit die Auswahlentscheidung auf jeder Ebene transparent zu machen.
Kriterien der Bewertung
Wir unterscheiden bei der Auswahl von Softwaresystemen fünf Kriteriengruppen, die wir im Folgenden näher erläutern wollen:
– Funktionalität,
– Technologie und Architektur,
– anbieterspezifische Kriterien,
– kundenspezifische Kriterien,
– Preis/Kosten.
Eine der wichtigsten Kriteriengruppen beinhaltet die erforderliche Funktionalität der gesuchten Softwarelösung. Diese lässt sich aus den Anforderungen der zu unterstützenden Geschäftsprozesse gewinnen. Zu unterscheiden sind hierbei:
– operative Funktionen wie Datenerfassung und -präsentation,Workflowunterstützung, Dokumentenmanagement etc. sowie
– dispositive Funktionalität im Hinblick auf Auswertungen, Reporting, Controlling etc.
Neben der Funktionalität, die vornehmlich aus Sicht des Fachbereichs beschrieben wird, spielen Technologie und Architektur als weitere Kriteriengruppe ebenfalls eine bedeutende Rolle. Aufgrund der besonderen Bedeutung des Datenaustauschs für BMS kommen der Integration und der Unterstützung von Schnittstellen eine herausragende Stellung zu. Notwendige integrative Eigenschaften der geplanten Softwarelösung werden durch zwei Anforderungen getrieben. Einerseits definiert der fachliche Informationsbedarf inner- und außerhalb des Beschwerdemanagements, welche Daten zwischen den Systemen ausgetauscht werden müssen. Andererseits gibt es bestimmte technische Standards und Restriktionen – zumeist getrieben durch die existierende IT-Architektur –, die berücksichtigt werden müssen. Darüber hinaus sind natürlich Datensicherheit, Performanz, Verfügbarkeit, Flexibilität etc. zu berücksichtigen. Die Architektur des BMS selbst ist hier auch zu bewerten. Dies ist deshalb in diesem Umfeld besonders interessant, da sich einige Best-of-Breed-Anbieter noch mit veralteten Architekturkonzepten (Zwei-Schichten-Architektur, Vermischung Präsentation & Applikationslayer etc.) begnügen.
Eine gesonderte Betrachtung der anbieterspezifischen Kriterien sollte ebenfalls berücksichtigt werden. Hierbei sind dessen finanzielle Situation, Marktstellung, Marktabdeckung, geographische Verteilung, geschäftliche Beziehungen etc. ebenso zu berücksichtigen wie das verfügbare Personal im Hinblick auf Service, Beratung und Support. Berücksichtigt werden muss hier auch die Produkt- und Releasestrategie des Anbieters. Bei der Auswahl eines BMS wird man sehr unterschiedliche Anbieter vergleichen müssen, da der Markt für reine BMS relativ klein beziehungsweise der Markt für Servicesoftwaresysteme relativ groß ist. Demnach ist hier gründlich zu überlegen, welches die wirklich wichtigen Anforderungen an den Anbieter sind.
Die kundenspezifischen Kriterien sind diejenigen, die Besonderheiten im Kundenumfeld mit Bezug auf den Anbieter und sein Produkt darstellen. Hier wird zum Beispiel bewertet, ob sich der Anbieter bereits im „Warenkorb“ des IT-Einkaufs befindet, ob es Erfahrungen aus der Vergangenheit mit dem Anbieter beziehungsweise mit dem Produkt (zum Beispiel in anderen Unternehmenseinheiten) gibt, ob der Kunde für den Anbieter ein strategisch wichtiger Kunde oder nur ein Kunde von vielen ist etc. Diese Kriteriengruppe ist mit Sicherheit die am meisten unterschätzte.
Monetäre Aspekte, das heißt Preis/Kosten des BMS, stellen eine weitere wichtige Kriteriengruppe dar. Im Rahmen der Investitionen sollten alle erforderlichen Einmalausgaben betrachtet werden (zum Beispiel Implementierungskosten, Hardware, Lizenzen etc.). Die Betrachtung der laufenden Kosten schließt Betriebs- und Wartungskosten, regelmäßige Lizenzabgaben, gegebenenfalls zusätzliche Personal- beziehungsweise fortlaufende Ausbildungskosten ein. In dieser Kriteriengruppe sind K.O.-Kriterien naturgemäß am einfachsten zu identifizieren.
Praxisbeispiel: Kriteriengruppe Kunde
Die Autoren haben einmal eine Softwareauswahl für einen Kunden im Konsumgüterbereich durchgeführt, bei der sich herausstellte, dass eins der untersuchten Pakete bereits in einer anderen Division des Konzerns eingesetzt wurde. Entgegen der ersten Annahme, dass dies ein Pluspunkt in der Bewertung sein könnte, stellte sich heraus, dass diese Tatsache im Gegenteil ein K.O.-Kriterium gegen das Produkt war. Die Divisionen wollten sich gegeneinander so weit differenzieren wie möglich, und damit war der Anbieter in diesem Fall ausgeschieden.
Vorgehen bei der Softwareauswahl
Das Vorgehen zur Auswahl eines BMS entspricht grundsätzlich dem Vorgehen, wie es bei jeder anderen Softwareauswahl angewendet werden kann. Um eine angemessene Entscheidung zu treffen, sind hierzu erforderliche Experten – sowohl aus dem Fachbereich als auch aus den technischen Abteilungen für Implementierung und späteren Betrieb – zu involvieren. Sowohl Vertreter späteren Anwender und Betreiber sind einzubeziehen, um deren operatives Detailwissen zu nutzen, als auch Vertreter aus den entsprechenden Führungskreisen, um eine fundierte Entscheidungsfindung sicherzustellen.
Im Folgenden werden die Einzelschritte bei der Auswahl dargestellt, deren Ziel es ist, die Liste der betrachteten Alternativen sukzessive zu reduzieren und gleichzeitig den Detaillierungsgrad in der Auswahl zu verfeinern (vgl. Abb. 4).
Phase 1: Validierung & Scoping
Wie jedes Projekt erfordert auch die Auswahl eines BMS einen ordentlichen Start. Im Rahmen des Kick-off werden alle beteiligten Mitarbeiter und Ressourcen in Ziele, Vorgehen, Rahmenbedingungen etc. eingeführt, um danach mit der Sichtung der existierenden Informationen – wie Vorstudien, Beschreibung von möglichen Alternativen und so weiter zu beginnen. Hierbei kommt der Untersuchung des Beschwerdeprozesses eine zentrale Bedeutung zu, da sich hieraus die Kernanforderungen praxisnah ableiten lassen. Die Eigenschaften der denkbaren Alternativen werden gegen diese gespiegelt, nach dem Ausschlussprinzip wird eine Longlist definiert. Insbesondere die Anwendung von K.O.-Kriterien hilft hierbei.
Phase 2: Analyse und Anforderungsdefinition
Im Rahmen einer Tiefenanalyse werden dann die funktionalen und Integrationsanforderungen untersucht. Ziel ist es, möglichst gut die spezifischen Bedingungen zu verstehen, unter denen die Alternative der Wahl zum Einsatz kommen wird, und damit die erforderlichen Leistungsmerkmale zu bestimmten.
Diese werden im Rahmen der Anforderungsdefinition in einem detaillierten Kriterienkatalog formuliert, der die relevanten Kriterien beinhaltet (vgl. Abschnitt „Kriteriengruppen“). Der Kriterienkatalog muss detailliert und gleichzeitig praktikabel sein, vor allem aber eine einfache, transparente und quantitative Bewertung der Alternativen ermöglichen. Durch Gewichtung der Kriterien oder Kriteriengruppen wird der Bedeutung bestimmter Anforderungen Rechnung getragen. Die Gewichtung sollte durch die Personen getroffen werden, die später die endgültige Auswahlentscheidung treffen, um deren volle Unterstützung sicherzustellen.
Durch Bewertung der Alternativen auf der Longlist (zum Beispiel auf Basis von Anbieterpräsentationen, Anbieterselbstbewertung oder Produktbroschüren) und Auswahl der am besten Bewerteten wird als Abschluss dieser Phase die Shortlist definiert.
Phase 3: Entscheidungsvorbereitung
Die Alternativen auf der Shortlist werden anschließend einer weiteren intensiven Untersuchung unterzogen. Unter dem Begriff des „Show Case“ subsummierte Ansätze hierzu können sein:
– Live-Demonstration der Softwarelösungen durch die Anbieter, gegebenenfalls bereits mit unternehmensspezifischen Daten und Einstellungen. Die Qualität der Live Demo sollte gegebenfalls in die Bewertungsmatrix mit aufgenommen werden. Hier muss darauf geachtet werden, dass die Gewichtung nicht zu hoch angesetzt wird.
– Proof of Concept, eine Minimal-Implementierung als Bewertungsmuster.
– Erarbeitung einer Machbarkeitsstudie durch die jeweiligen Anbieter.
Die Detaillierung des Investitionsrahmens für die untersuchten Alternativen sowie ein Implementierungsausblick durch eine grobe Projekt- und Aufwandsplanung liefern die Basis für eine fundierte Systemauswahl. Häufig wird diese durch das Projekt in Form einer Empfehlung den Entscheidungsträgern vorgestellt, die dann durch Auswahl einer Alternative das Auswahlprojekt abschließen.
Top 5 möglicher Fehler bei der Softwareselektion
Hier ist die „Top 5“ der Fehler, die aus unserer Sicht bei Softwareselektionen begangen werden:
Unterschätzung der politischen Gegebenheiten
Häufig werden Bewertungen durchgeführt, die die politischen Rahmenbedingungen des Einkaufs, des Fachbereiches oder der IT einfach nicht berücksichtigen. So werden zum Beispiel Warenkörbe des Einkaufs nicht beachtet, die von vornherein die Liste begrenzt hätten, oder es werden langjährige Beziehungen zwischen Softwarehersteller und Entscheidern des Unternehmens unterschätzt beziehungsweise schlichtweg vergessen.
Es ist klar, dass es politische Einflüsse in jedem Unternehmen gibt. Diese Faktoren müssen ausreichend berücksichtigt werden, sonst bekommen die Bewertungen Alibi-Charakter und sind im Wesentlichen wertlos.
Mangelhafter Cost Case
Nur wenn die Darstellung der erwarteten Kosten in detaillierter und nachvollziehbarer Form vorliegt, können die Entscheider der Auswahl und dem Projekt zustimmen. Hier ist zu bemerken, dass beide Teilaspekte eines Business Cases – sowohl Kosten als auch Nutzen – oftmals zu optimistisch gerechnet werden. Dabei ist die Nutzenbetrachtung nicht typischerweise Teil der Softwareauswahl, sondern sollte bereits früher im Prozess angestellt worden sein. Wir gehen davon aus, dass der Anteil an Business Cases, deren Vorkalkulation bessere Ergebnisse lieferte als die Nachkalkulation, bei 70 bis 80 Prozent liegt.
Verwissenschaftlichung der Bewertungsmatrix
Die Bewertungsmatrix über die fünf Kriteriengruppen (siehe oben) wird oft in zu viele Unterkriterien aufgeteilt, die dann alle mit einem winzigen Gewicht belegt und je Anbieter bewertet werden. Damit wird eine sachliche Exaktheit vorgegaukelt, die in der Praxis meist doch nicht zu erreichen ist. Den Preis, den man für solche Bewertungen zahlt, ist die praktische Unbrauchbarkeit des Modells. Aus unserer Erfahrung sollte es innerhalb einer Kriteriengruppe maximal zwei darunterliegende Hierarchiestufen geben.
Übersehen von K.O.-Kriterien
Wenn K.O.-Kriterien in der Bewertung nicht als solche identifiziert, sondern innerhalb der Bewertungsmatrix einfach nur etwas höher als andere gewichtet werden, kann dies zu falschen Entscheidungen führen. Dies gilt insbesondere, wenn die Matrix, wie oben geschildert, ohnehin schon zu komplex geraten ist. Beispiel: Die Offline-Fähigkeit eines BMS kann bei bestimmten Unternehmen ein Ausschlusskriterium sein, dementsprechend sollte es auch behandelt werden.
Zu hohe Bewertung der Verkaufsdemonstration
Die Live-Demo ist wichtig: Sie gibt neben den sachlichen Informationen auch das Gefühl für das Produkt und die Menschen, die für dieses Produkt einstehen.
Oft jedoch kann die Entscheidung für eine bestimmte Lösung ausschließlich auf die Klasse der Vertriebsmannschaft zurückgeführt werden. Dies bedeutet wiederum, dass es für die Auswahl entscheidend ist, ob der Vendor sein A-, B- oder C-Team zur Verfügung stellt beziehungsweise diese zum Zeitpunkt der Präsentation verfügbar waren. Bei diesen Gegebenheiten fällt die Abstraktion von der vertrieblichen Leistung auf die Fähigkeiten des Produktes schwer beziehungsweise wird nicht unternommen. Damit gewinnt der Show Case übermäßig an Einfluss auf die Bewertung. Wir empfehlen, gegebenenfalls nach Durchführung der Präsentation die sachlichen Themen der Bewertung anzupassen und die allgemeine Ausführung des Cases mit nicht mehr als fünf bis zehn Prozent zu gewichten.
Herausforderungen bei der Implementierung
An die Auswahl eines BMS schließt sich die Umsetzung an. Hierbei sind die für eine IT-Implementierung üblichen Herausforderungen und Risiken zu beachten. Die Einführung eines BMS erfordert darüber hinaus in einigen Punkten jedoch besondere Aufmerksamkeit. Wie bereits erläutert kann die Einführung eines BMS eine besondere technische Herausforderung darstellen, für die technisches Spezialwissen erforderlich ist:
– Bei einer CRM-Suite sind gegebenenfalls umfangreiche Parametrisierungen erforderlich,
– Schnittstellen zwischen einer Best-of-Breed-Lösung und der bestehenden Systemlandschaft müssen realisiert werden und/oder
– bei Individualprogrammierung muss erforderliche Funktionalität angemessen designed und realisiert werden.
Kern eines BMS stellt die Beschwerdekategorisierung dar, die auf Basis eines vordefinierten Kategorienkatalogs erfolgt. Hier ergibt sich der Zielkonflikt, diese Kategorisierung so detailliert wie möglich zu gestalten, um jegliche Form der Auswertung zu unterstützen, gleichzeitig aber den Eingabeaufwand für den Systembenutzer so gering wie möglich zu halten, um eine hohe Effizienz zu gewährleisten. Darüber hinaus muss der Kategorienkatalog wohlstrukturiert definiert werden, um aussagekräftiges und flexibles Reporting zu erlauben. Insbesondere in Unternehmen mit einem hohen Beschwerdeaufkommen ist dem Dokumentenmanagement ein entsprechender Stellenwert beizumessen. Dokumente aus mehreren hunderttausend Beschwerden pro Jahr – durchaus üblich in großen Konzernen – müssen effizient digitalisiert, archiviert und bearbeitet werden können.
Eine Workflowunterstützung durch das Beschwerdemanagementsystem erlaubt eine effektive und effiziente Bearbeitung der einzelnen Beschwerden. Einerseits sollte dies entlang eines vordefinierten Standardprozesses erfolgen, was sich zudem positiv auf die Bearbeitungsqualität auswirkt. Andererseits ist jede Beschwerde anders gelagert und damit eine gewisse Flexibilität im Bearbeitungsablauf unerlässlich.
Praxisbeispiel: Anzahl der Kategorien (Personenbeförderung)
Bei einem deutschen Unternehmen aus der Personenbeförderungsbranche ist die Anzahl der im System hinterlegten Beschwerdekategorien über die Jahre historisch gewachsen und liegt mittlerweile bei über 2000! Dies ist dadurch entstanden, dass jedweder fachlichen Anforderung (meist zu einem isolierten Bereich des Berichtswesens) stattgegeben wurde und ein Gesamtüberblick nicht vorhanden war. Die hohe Anzahl der jetzigen Beschwerdekategorien führt zu verschiedensten Problemen:
– Frustration bei der Beschwerdeeingabe,
– niedriger Befüllungsgrad bei den meisten Kategorien,
– nicht aussagefähiges Gesamtreporting und am wichtigsten:
– mangelhafte Operationalisierbarkeit. Dies bedeutet, dass es auf Grund der hohen Anzahl an Kategorien praktisch unmöglich ist, je Kategorie sinnvolle Maßnahmen zur standardisierten Behandlung der entsprechenden Beschwerden aufzusetzen.
Oft wird dem Beschwerdemanagement im Unternehmen ein eher untergeordneter Stellenwert beigemessen. Dies kann sich im Wettbewerb um erfolgskritische Ressourcen auch auf die Implementierung des BMS auswirken. Durch geeignetes Change Management ist zu gewährleisten, dass das Implementierungsprojekt hier die notwendige Unterstützung erfährt.
Praxisbeispiel: Workflows (Reiseunternehmen)
Während der BMS-Implementierung bei einem Reiseunternehmen wurde beispielsweise darauf geachtet, dass im System typische Standardprozesse im Rahmen von Workflows abgebildet wurden. Dies war erforderlich, um eine effiziente Bearbeitung vieler ähnlich gelagerter Beschwerden in der Hauptreisesaison zu ermöglichen. Gleichzeitig hat jeder Anwender jedoch die Möglichkeit, die Workflows durch Hinzufügen oder Überspringen von Arbeitsschritten an die Besonderheiten spezieller Vorgänge anzupassen.
Ist-Situation
Mittlerweile ist der Einsatz von Tools zur Automatisierung des Beschwerdeprozesses in den meisten Unternehmen üblich. Auffällig ist allerdings, dass in den seltensten Fällen dem BMS die Aufmerksamkeit zuteil wird, die aus geschäftlicher Sicht notwendig wäre. In den Beispielen umfassender Implementierungen von CRM-Suiten, die uns bekannt sind, genießt das Beschwerdemanagement eine eher geringe Priorität im Gesamtprojekt. Bei Best-of-Breed-Implementierungen gestaltet sich dies üblicherweise anders, was verständlich ist, da hier das BM das alleinige Ziel der geplanten Aktivitäten ist.
Bis dato sind herausragende Lösungen, die sowohl fachlich als auch technisch Marktführer sind, nicht zu identifizieren. Vielmehr erscheint der Markt stark segmentiert mit Nischenprodukten, die ihre Stärke in genau abgegrenzten Teilbereichen aufweisen.
Inhaltlich findet eine starke Konzentration auf das Beschwerdemanagement im engeren Sinne statt. Dies bedeutet, dass BMS zur Automatisierung der BM-Prozesse, zur Vorgangsverwaltung und zu themenbezogenen Auswertungen verwendet werden. Im Fokus stehen dabei offensichtliche Effizienzsteigerungen (zum Beispiel Steigerung des Automatisierungsgrads) und Verbesserung der Effektivität (zum Beispiel bessere Informationsnutzung zum BM-Vorgang). In diesem Sinne dienen BMS hier als klassische Instrumente zur Prozesskostenreduktion.
Ausblick
Wie bereits dargestellt, wird Beschwerdemanagement derzeit noch in zu vielen Unternehmen als mehr oder weniger letzte Möglichkeit verstanden, Kunden an der Abwanderung zu hindern. Häufig verkommt das Beschwerdemanagement dann zur Beschwerdeadministration. Zukünftig wird das Beschwerdemanagement jedoch viel intensiver mit den anderen Kernelementen des CRM verbunden werden. Dabei ist insbesondere die Verbindung von Beschwerdemanagement mit den Systemen und Methoden des analytischen CRMs als Thema mit dem größten Nutzenzuwachs zu sehen. Im Folgenden werden zwei Beispiele mit großem Potenzial genannt, die bis jetzt nur in wenigen Unternehmen vorzufinden sind.
BMS zur Unterstützung des Marketing
Beschwerdekategorisierung wird zukünftig noch stärker als Basis für Churn-Rate-Prognosen und somit als Trigger für Gegenmaßnahmen/Prozessketten eingesetzt werden. Über bestimmte Kennzahlen auf Basis der Beschwerdekategorisierung werden Schwellenwertberechnungen durchgeführt, die in Abwanderungsprognosemodellen berücksichtigt werden können und somit als Auslöser für Gegenmaßnahmen (zum Beispiel eine Kampagne) oder bestimmte Prozesse (zum Beispiel proaktiver Kundenservice) dienen, was wiederum leistungsfähige Softwareunterstützung erfordert.
Kundenwertbasierte Beschwerdebearbeitung und Kompensation
Strategisch wichtige Größen wie „Kundenwert“ oder „Customer Lifetime Value (CLV)“ können im Beschwerdemanagement eine sinnvolle Operationalisierung finden. So wird zum Beispiel in Abhängigkeit vom Kundenwert und gegebenenfalls der Schwere des Kundenproblems gesteuert, wie individuell und interaktiv der Beschwerdeprozess abläuft. Damit werden bedeutsame Kunden eine individuelle Betreuung mit intensiver Kommunikation (zum Beispiel Eingangsbescheid, Zwischeninformationen etc.) erfahren, während Beschwerden von Kunden mit vergleichsweise geringem Kundenwert nach einem Standardprozess behandelt werden. Dies hat neben der vornehmlichen Erhaltung der wichtigen Kunden natürlich auch eine Innenwirkung in Form von differenzierten Prozesskosten.
Noch wichtiger scheint uns der Zusammenhang zwischen Kundenwert und Höhe der Kompensation einer Beschwerde. Durch die Integration von BMS und analytischem CRM wird zukünftig die Regulierung der aus der Beschwerde resultierenden Kompensation gesteuert werden. Eine Kompensation aus einer Beschwerde hat typischerweise einen festen (zum Beispiel gesetzlich vorgeschriebenen beziehungsweise durch den Kunden einklagbaren) und einen variablen, auf Kulanz basierenden, Anteil. Untersuchungen von Capgemini haben ergeben, dass hier eine konsequente Steuerung des Kulanzanteils, abhängig vom Kundenwert beziehungsweise CLV, eine Kostenersparnis von über zehn Prozent der gesamten Kompensationskosten bei ansonsten gleichen Parametern (gleicher Umsatz, gleiche Kundenbindung, gleiche Personalstruktur) hat.
Diese Beispiele belegen, dass die Integrationsfähigkeit von BMS in Zukunft eine noch wichtigere Rolle spielen wird, insbesondere im Hinblick auf die Systeme des analytischen CRM. Reine Best-of-Breed-Lösungen mit guten Funktionalitäten aber unflexibler und nichtintegrativer Architektur sind damit zukünftig noch mehr gefährdet als jetzt schon.
Dies sind auch die Gründe dafür, dass aus unserer Sicht bei BMS und vor allen Dingen bei Best-of-Breed-Produkten die Qualität der IT-Architektur und die Integrationsfähigkeit in die restliche Systemlandschaft die entscheidenden Differentiatoren bei der Auswahl eines solchen Systems sein sollten. Ein BMS ohne hochintegrative Einbettung in die anderen Bereiche des CRMs ist zukünftig nicht mehr vorstellbar.
