CRM – Projekterfahrungsberichte Teil #2
Mit der mehrteiligen Reihe “CRM – Projekterfahrungsberichte” sollen abwechselnd drei fachliche, technische und zwischenmenschliche Erfahrungen aus aktuellen und bisherigen CRM Projekten dokumentiert werden.
Ziel der Artikelreihe ist es, dass Entscheider und Projektleiter aus mittelständischen Unternehmen, die sich aktuell im Auswahlprozess von CRM-Dienstleistern und -Software befinden, objektive Informationen erhalten, um gewisse Herausforderungen vorherzusehen oder lösen zu können.
#1 “Das CRM soll nur erstmal vom Marketing genutzt werden”
CRM ist kein Solo- bzw. Abteilungsprojekt. CRM muss von Anfang an als eine ganzheitliche Unternehmensstrategie gesehen werden. Eine CRM Strategie kann nur die volle Wirkung erzielen, wenn alle notwendigen Abteilungen (Vertrieb, Service, Support, Marketing) involviert sind und diese auch einen Teil dazu beitragen können.
In dieser kritischen Projektphase ist Beteiligungsmanagement mehr als Change Management gefragt. Zuerst sollten Fürsprecher (Influencer / Power People) in jeder Abteilung erkannt und ernannt werden. Jede Abteilung braucht mindestens einen Mitarbeiter, um die Ziele des Projektes zu verteidigen und die Wünsche der Kollegen pro Abteilung zu verstehen.
Ein CRM Projekt betrifft sehr viele Prozesse, Menschen und Meinungen, sodass von Anfang an sicherzustellen ist, dass es einen grundlegenden “Roll-Out-Plan” gibt, der nicht nur die Wünsche der Geschäftsführung berücksichtigt, sondern auch die der Mitarbeiter.
Die Wünsche können pro Abteilung stark abweichen. Das ist auch der Hauptgrund warum ein CRM Projekt von Anfang an ganzheitlich gesehen werden muss. Wenn eine Abteilung startet, wie z.B. das Marketing, dann muss in der 2. Projektphase das gesamte Projekt wieder neu aufgerollt werden, um die Vertriebsprozesse dort einzubinden. Das ist weder zielführend noch budgeteffizient.
Zusammenfassend: Es empfiehlt sich ein “Pilot-Team” aus mehreren Abteilungen und Hierarchiestufen zusammenzustellen. Dieses Team trägt die Verantwortung und die kümmert sich auch um die emotionalen Parameter. Es ist allerdings zu empfehlen das Team nicht größer als zehn Personen werden zu lassen.
#2 “Technik vs. Business”
Ein erfolgreiches CRM-Projekt ist die perfekte Synergie aus Business-, Technik und Marketing. In der Praxis wird jedoch häufig der Faktor “Technik” als höchste Priorität gesehen, sodass teilweise Anforderungen in der auserkorenen Software umgesetzt werden, die aus “Business-Sicht” wenig erfolgsversprechend sind.
Zu allererst steht die Strategie im Vordergrund. Danach folgen Dinge wie Mitarbeiteranforderungen, Abteilungsprozesse und Integration.
Die Mitarbeiteranforderungen sind ein zentraler Punkt und dürfen in der Softwarephase der Strategie nicht fehlen. Jedoch gilt es bei Dienstleistern zwischen Business- und IT-Consultants zu unterscheiden.
Der Unterschied ist folgender:
IT bzw. Technical Consultants sind eher problemorientiert.
- Direkte Lösung für ein zugrunde liegendes Problem
- Eher technisch orientiert
- Prozess- und Businesssicht i.d.R. nicht Teil der Betrachtung
Management bzw. Business Consultants sind prozessorientiert
- Weniger Verständnis für IT, aber dafür Weitsicht
- Fokus: Businessprobleme lösen
- Markt- und Branchenverständnis
Beide Consultants haben ihre Daseinsberechtigung, aber müssen richtig eingesetzt werden. Oft übernehmen ähnliche Consultants aus dem selben Spezialgebiet die gesamte Projektberatung. Das ist wenig förderlich, da immer beide Seiten (Business und Technik) betrachtet werden müssen.
#3 “Change Requests”
In jedem technischen Projekt gibt es immer zwei Seiten: Der Dienstleister und der Kunde. Diese beiden Seiten haben desöfteren unterschiedliche Sichtweisen und Vorstellungen, sodass es in der Umsetzung manchmal zu Diskussionen kommt. Das ist üblich und lässt sich mit dem richtigen Vorgehen schnell lösen.
Vor dem Projektstart sollte deshalb eine einheitliche Form der Korrektur- bzw. Anforderungsdefinition festgelegt werden, mit der beide Seiten einverstanden sind. Wichtig ist, dass das Dokument zur Dokumentation der Korrekturen vom Dienstleister nahtlos in den Änderungsprozess aufgenommen werden kann.
Wenn möglich, sollten die gewünschten Korrekturen / Anforderungen stets mit einem Screenshot versehen werden, um sicherzustellen, dass das Endergebniss exakt wie gewünscht aussieht.
Darüber hinaus sollten vor dem Projektstart etwaige Korrekturschleifen besprochen werden und dahingehend mit eingepreist werden. Diese Schleifen gibt es in fast allen Projekten und wenn von vornherein keine Arbeitsstunden dafür reserviert sind, kann es später zu Preisdiskussionen kommen – die zu vermeiden sind.
In folgender Abbildung ist ein einfaches, aber wirksames “Change Request” Formular zu sehen (Klicken zum Vergrößern):
Definieren Sie diese Muster am Besten direkt mit der jeweiligen Gegenpartei, um alle möglichen Szenarien abzudecken. Gerade die “Änderungs- und Fehlerphase” nach einer Softwareimplementation ist sehr kritisch.
Nicht umsonst heisst es: “CRM ist keine Software, sondern ein fortwährendes Projekt, dass nach Abschluss der Einführung nicht abgeschlossen ist.” Den #1, dass ein CRM Projekt als Gesamtunternehmerisches Projekt gesehen werden muss, um am Ende einen ROI zu erzielen, kann ich nur beipflichten.
Leider hat die Praxis eine Vielzahl an gegenteiligen Beispielen. Meist entsteht der Wunsch nach einem CRM bzw. einem NEUEN in einer Abteilung. Wenn dies der Fall ist, empfiehlt es sich den Workshop für die Anforderungsaufnahme zwei zu teilen. Im ersten Teil werden alle Prozesse und Anforderungen der Abteilung aufgenommen. Im 2. Teil werden, dann die wichtigsten Mehrwerte für andere Abteilungen eruiert. Daraus läßt sich schnelle eine Argumentation finden, andere Abteilungen und die Führungsebene mit ins Boot zu holen.
Hallo Herr Panser,
da können wir nur voll und ganz zustimmen. Wenn dies jeder so sehen würde wie Sie, dann wären CRM Projekte gleich um ein
vielfaches einfacher!
Viel Spaß weiterhin mit unseren Beiträgen.
Beste Grüße aus der migital Redaktion
Eric
Das ist sicher richtig. Aber um ganz ehrlich zu sein: “Mir würde dann aber auch etwas fehlen”. Immerhin sind es die Fails aus denen sich reichlich Wissen ziehen läßt. Das gilt sicher für alle IT-Projekte. Wobei der Begriff schon fast falsch ist. Kein IT-Projekt sollte mehr nur die IT allein etwas angehen. Und dann haben wir schon den Einstieg für einen wunderbaren neuen Beitrag.
Vielen Dank und Grüße nach an die migital Redaktion.
Ich habe beide Beiträge der Serie mit viel Interesse gelesen. Es ist spannend zu sehen welche Aspekte es zu berücksichtigen gilt. Einige sind offensichtlich, z.B. das stets mehrer Abteilungen einbezogen werden sollten. Das ist für mich logisch, aber jede Mensch hat ein anderes Verständnis bzw. eine andere Auffassung von Logik. Herr Panser hat recht, dass man doch aus Fehlern am meisten lernt. Nur können einfache Fehler schnell durch Absprachen zwischen Abteilungen vermieden werden. Dass CRM mehr ein Projekt als eine Software ist finde ich einen sehr guten Gedanken. Wir haben unsere Call Center Software von pascom erneuert und gleichzeitig ein CRM System integriert. Hierbei wurde der Aspekt des Projektes klar. Deshalb erarbeiten wir momentan einen Leitfaden für alle Abteilungen.