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.