none
Verwaltung von Vertriebsgebieten und Teams RRS feed

  • Frage

  • Hallo zusammen,

    wir haben nun zwei CRM-Piloten in zwei kleinen Teilprojekten realisiert und planen momentan die Implementierung für unser über 100 Personen starkes Vertriebsteam. In unserer Unternehmensgruppe gibt es aber im bisherigen CRM (wenn man das so nennen kann) eine klare Strukturierung der Vertriebsgebiete mit klaren Sicherheitsrichtlinien, die die Kunden in den Gebieten dem Zugriff einzelner Vertriebsmitarbeiter zuuordnen. Das Einsatzgebiet Deutschland ist in 5 Gebiete unterteilt. Diese Gebiete sind nach Postleitzahlen abgegrenzt und werden von einem Teamleiter koordiniert, dem mehrere Vertriebsmitarbeiter unterstellt sind. Jeder Vertriebsmitarbeiter hat aber nur Zugriff auf bestimmte Kunden innerhalb seines Gebietes (wiederum Aufteilung über PLZ). Der Teamleiter hat Zugriff auf alle Kunden in seinem Gebiet und der Vertriebsleiter Germany auf alle Kunden im Großraum Deutschland.

     

    Das ganze würde sich sicherlich über Workflows regeln lassen, die aufwändig zu kreieren wären. Doch leider haben wir, wie die Vergangenheit zeigt jährlich einmal bis zu zweimal eine Gebietsreform. Diese Gebietsreform wird ebenso im SAP aber momentan noch nicht ins CRM übergeben.

    Somit bin ich auf der Suche nach einer professionellen Lösung solche Gebietsverteilungen ins CRM zu integrieren, die auch eine Gebietsreform auf Basis der PLZ in angemessenem Aufwand zulassen. Auch verstehe ich den Microsoft Gedanke bezüglich der Attribute Gebiet nicht wirklich. Ich hoffe ich kann etwas aus Eurem Erfahrungsschatz erfahren, was uns in dieser Angelegenheit nach vorne treibt.

    Vielen Dank

     

    Daniel Rexer

    Mittwoch, 7. April 2010 07:43

Antworten

  • Bei der Thematik würde ich mir mal die Organisationsstruktur im CRM vornehmen.


    Die Organisationseinheiten im CRM müssen ja nicht der tatsächlichen Organisation im CRM entsprechen. Ich könnte mir durchaus vorstellen, dass man dieses Problem prinzipiell folgendermaßen anpacken kann:

    Sechs Organisationseinheiten. Eine namens "FIRMA" und fünf andere "VERTRIEBSREGION 1-5", die als "Töchter" an der "FIRMA" hängen.. Die Vertriebsmitarbeiter kommen in ihre jeweilige Vertriebsregions-Orga und erhalten eine Sicherheitsrolle, die es ihnen nur erlaubt, Kunden ihrer Organisationseinheit zu sehen. Der Teamleiter kommt in die Organisationseinheit "FIRMA" und erhält das Recht, systemweit Kunden zu sehen.

    Voila. Dieses System erlaubt es den Vertriebsmitarbeitern nur noch die Kunden zu sehen, die ihrer Organisation bzw. Usern ihrer Organisation zugewiesen sind, während der Teamleiter alles sieht.

    Was hier noch nicht abgebildet ist:

    - Abgrenzungen innerhalb einer Organisationseinheit

    - Konzept, wie man bei Änderungen vorgeht

     

    Aber eventuell ist das ja schonmal ein Ansatz, mit dem ihr was anfangen könnt.

    • Als Antwort markiert rexible Freitag, 9. April 2010 12:21
    Mittwoch, 7. April 2010 08:12
  • Hallo Daniel,

     ich würde für die Zugriffsberechtigungen der Außendienstmitarbeiter / Teamleiter / Vertriebsleiter auf die Kunden (Firmen) über Organisationseinheiten regeln. Diesen Weg hat   bereits AZiegler oben beschrieben.  Jeder Kunde hat dann einen CRM-Benutzer / ADM als Besitzer. Darüber werden die Zugriffsrechte gesteuert.

    Meine Idee für die initiale Bearbeitung und Aktualisierung: Die CRM-Standardfunktion Gebiete würde ich nicht nutzen.  Wir setzen bei Kunden eine externe Geomarketing-Software (RegioGraph) ein, die dann für jede PLZ (oder Gemeinde oder Landkreis etc) einen zuständigen Vertriebsmitarbeiter ermittelt. Die Daten kann man dann als Entität im CRM importieren und damit über Workflow / Plugin für Neukunden den zuständigen ADM suchen. Aus RegioGraph kann ich mir nach einer Gebietsumplanung in RegioGraph eine Datei mit Kundennummer / Vertriebsmitarbeiter erstellen. Über einen Import / Plugin / Workflow kann man dann den Besitzer beim Kunden ändern.

    Mit Geomarketing-Software visualisiert man z. B. die Standorte von Kunden und die Wohnorte   von AD-Mitarbeitern auf digitalen Landkarten. Damit kann man über die Software z. B. Entfernungen vom Kunden zum zugeordneten AD im Vergleich zum nächstgelegenen AD berechnen. Gibt manchmal schon Aha-Erlebnisse.  

    „Macken in der Vertriebsstruktur“ kann man über eine Kartendarstellung einfacher erkennen und verbessern. Es trägt auch zur Akzeptanz beim Außendienst bei, wenn jeder AD eine Landkarten mit seinen alten und neuen Kunden erhält. Eine Landkarte gibt da einen einfacheren Überblick.

    Weiße Flecken (z.B. PLZ-Bereich   ohne zugeordnete Kunden) kann man dann „automatisch“ mit dem nächstbesten AD füllen lassen.  Wenn man Gebiete gebildet hat, dann kann man auch weitere Daten wie Umsätze, Kundenanzahl,   Potential (z.B.  Anzahl Ärzte je PLZ)  in einem Vertriebsgebiet addieren lassen. Wenn dann der Vertriebsleiter an den Gebietsdefinitionen arbeitet, dann werden die Summen automatisch aktualisiert.   Es gibt ferner noch eine Vielzahl von Spezialfunktionen, die für die gerechte Gebietsplanung oder Gebietsoptimierung sinnvoll sind.   Nach Abschluß der Gebietsänderung erfolgt ein Export der neuen Zuordnung von Kunde zu  ADM bzw. von PLZ zu ADM.

    Ich habe auch einen konkreten Vorschlag für die Software: Für die Gebietsplanung setzen wir   die Geomarketing-Software RegioGraph ein. Über Excel –Export / Import oder eine verfügbare Schnittstelle von MS CRM zu RegioGraph kann man die Daten austauschen.  (Wir sind sowohl für Microsoft CRM als auch für RegioGraph zertifiziert, weil wir diese Kombination sehr spannend finden)

    Weil die Datei über eine Software erstellt wird, kann man ohne Probleme alle 8200 Zustell-PLZ verwalten. Auch Postfach-PLZ stellen kein Problem dar, weil man da einfach die nächstgrößere Zustell-PLZ nehmen kann.   Kunden mit einer Key-Account-Betreuung kann man schützen, indem Sie aus der Transferdatei ausgeschlossen werden. Über die Geomarketing-Software gibt es auch jedes Jahr eine Aktualisierung der PLZ / Gemeinde-Daten, weil sich da jedes Jahr irgend etwas (und manchmal viel) ändert.


    Herzliche Grüße Markus Müller
    Mittwoch, 7. April 2010 13:13
  • Hierzu gibt es zwei Möglichkeiten:

    A) An der PLZ Gruppen-Entität müsste natürlich der kleinste PLZ-Wert und der größte PLZ-Wert gelistet werden, um dann innerhalb des Arrays darauf zu schließen, ob eine PLZ aus z.B. Kontakt innerhalb der Gruppe A oder B liegt. Wenn die PLZs "wild" sortiert wären, dann müsste man in einem NTEXT-Feld alle der PLZ-Gruppe zugehörigen PLZ eintragen. Dieses Feld dann in ein Array konvertieren (String to Array) und dann die einzelnen PLZs aus z.B. einem Kontakt gen Array abgeleichen

     

    B) Neben der PLZ Gruppen Entität gibt es eine einzelne PLZ-Entität. Da die über öffentlich zugängliche PLZ-Register oder WebServices erhältlich sind, ist das mit der Pflege schnell erledigt. Nun könnten man einer PLZ Gruppe die einzelnen PLZs zuweisen. Dem entsprechend hätte ich natürlich auch eine Möglichkeit von der Gruppe auf einzeln zugewiesene PLZs zu schließen und könnte diese dann einzeln mit den PLZs aus Firmen, Kontakten, Leads abgleichen. Ebenso hätte ich den Vorteil, dass ich bei PLZ Verschiebungen innerhalb von Gruppen dies sehr schnell umsetzen könnte durch deaktivieren bzw. "umbuchen" einer PLZ in eine andere Gruppe

     

    Vorteil A: Du brauchst nur eine Entität zur Verwaltung Deiner PLZ-Gruppen

    Nachteil A: Du musst ein Gesamtstring in ein Array aufteilen und musst die PLZs in einen großen NTEXT Feld pflegen. Das ist für manchen unübersichtlich.

     

    Vorteil B: Du kannst x-beliebig viele PLZ unterschiedlichen Gruppen zuweisen

    Nachteil B: Du musst einmalig oder bei PLZ-Änderungen entsprechende Datensätze pflegen bzw. per Massenimport up-to-date halten (was jedoch nicht all zu häufig vorkommen dürfte)

     

    In beiden Fällen arbeitet es sich mit RetrieveMultiple (einmal mit LINQ, einmal ohne (im Fall A))

    Verständlich genug?

     


    Gruß Carsten Groth http://carstengroth.spaces.live.com
    • Als Antwort markiert rexible Freitag, 9. April 2010 12:20
    Donnerstag, 8. April 2010 07:54
  • Hallo Daniel,

    wenn es bei der Zuordnung nicht nur um Firmen, sondern auch um Leads bzw. Freiberufler (Einzelpersonen ohne Firma) geht, dann wandelt sich der Ansatz etwas. Bei der Geomarketing-Software arbeitet man mit sogenannten Schichten (Layern). Damit kann aus dem CRM die Standorte von Firmen, von Leads oder von Privatpersonen jeweils in einem Layer importieren.  Über eine Verschneidung mit dem Layer "AD-Gebiet" erhält man jeweils die Zuordnung von AD-Mitarbeiter zum Kunden, Lead bzw. Freiberufler.  Man kann auch mit verschiedenen Gebietsstrukturen arbeiten. Manchmal arbeiten zwei AD in einer Region  (z.B. Firmenkundenbetreuer  vs. Freiberuflerbetreuer) oder es gibt eine parallele Innendienst / Telefonmarketing-Struktur für kleinere Kunden

    Sofern Ihr eine reine PLZ-orientierte AD-Einteilung nutzt, dann geht es auch einfacher. Man kann aus dem RegioGraph Planung (so heißt "GfK District") eine Datei mit den Werte PLZ und AD-Mitarbeiter aufbauen.

    Wenn diese Datei als Entität im CRM importiert wurde, dann kann man diese Informationen über Plugin etc. für die Aktualisierung der Datensatz-Besitzer bei Account, Contact, Lead nutzen. Das macht man einmal für alle Datensätze direkt nach einer Umstrukturierung oder sonst bei Neuanlage eines Account, Leads oder Contacts automatisch.

    Die Zuweisung des Datensatzbesitzer sorgt auch für die Berechtigungssteuerung. Grundsätzlich sieht jeder Außendienstler seine Datensätze. Gruppenleiter oder Vertriebsleiter erhalten Lese- bzw. Änderungsrechte auf die einzelnen Kunden, Leads oder Kontakte über die Organisationseinstellungen.

    Gruß Markus

    P.S.:  Für Detailanfragen kann man mich auch anrufen. Concepta und MS CRM gibt eindeutige Ergebnisse beim Bingen oder Googeln.



    Herzliche Grüße Markus Müller
    • Als Antwort markiert rexible Freitag, 9. April 2010 12:20
    Donnerstag, 8. April 2010 11:26

Alle Antworten

  • Bei der Thematik würde ich mir mal die Organisationsstruktur im CRM vornehmen.


    Die Organisationseinheiten im CRM müssen ja nicht der tatsächlichen Organisation im CRM entsprechen. Ich könnte mir durchaus vorstellen, dass man dieses Problem prinzipiell folgendermaßen anpacken kann:

    Sechs Organisationseinheiten. Eine namens "FIRMA" und fünf andere "VERTRIEBSREGION 1-5", die als "Töchter" an der "FIRMA" hängen.. Die Vertriebsmitarbeiter kommen in ihre jeweilige Vertriebsregions-Orga und erhalten eine Sicherheitsrolle, die es ihnen nur erlaubt, Kunden ihrer Organisationseinheit zu sehen. Der Teamleiter kommt in die Organisationseinheit "FIRMA" und erhält das Recht, systemweit Kunden zu sehen.

    Voila. Dieses System erlaubt es den Vertriebsmitarbeitern nur noch die Kunden zu sehen, die ihrer Organisation bzw. Usern ihrer Organisation zugewiesen sind, während der Teamleiter alles sieht.

    Was hier noch nicht abgebildet ist:

    - Abgrenzungen innerhalb einer Organisationseinheit

    - Konzept, wie man bei Änderungen vorgeht

     

    Aber eventuell ist das ja schonmal ein Ansatz, mit dem ihr was anfangen könnt.

    • Als Antwort markiert rexible Freitag, 9. April 2010 12:21
    Mittwoch, 7. April 2010 08:12
  • Hallo,

     

    vielen Dank für die rasche Antwort. Dieses Prinzip habe ich in unserem Pilotprojekt in der Schweiz bereits so gelöst.

    Organistationseinheit (OU) Geschäftsleitung, OU Innendienst, OU Vertriebsleitung; OU Gebiete OST, West, Süd, Nord.

    Das funktioniert von der Abgrenzung auch ganz gut. Die Kunden werden vom Innendienst den Vertriebsmitarbeitern manuell als Besitzer zugordnet.

    Die Kundenabgrenzung ist hier aber in einer sehr flachen Hirarchie und auch die Kundenanzahl überschaubar. Im Vertriebsteam Deutschland ist dies einiges komplizierter und nicht so leicht überschaubar. Der Knackpunkt ist die Zuweisung der Benutzer über die PLZ initial und auch bei Gebietsreformen.

     

    Grüße

     

    Daniel

    Mittwoch, 7. April 2010 08:18
  • Ich würde mir auf jeden fall mal den Extended Sales Forecast Accelerator hierzu anschauen und mir auch überlegen, ob ich nicht eine eigene Entität in Relation zu den Systemusern anlege (Zuständigkeit PLZ). Diese Entität kann ich zusätzlich mit den Kontakten und Firmen verknüpfen und dann entsprechende Zuweisungen via Workflows regeln.
    Gruß Carsten Groth http://carstengroth.spaces.live.com
    Mittwoch, 7. April 2010 08:26
  • Hallo Carsten,

     

    den Accelerator habe ich mir schon einmal angeschaut, kann aber keinen Zusammenhang mit der Zuweisung von Gebieten finden.

     

    Wenn ich dich richtig verstehe, dann empfielst du mir eine neue Entität zu generieren, die alle Postleitzahlen abbildet.

    Die einzelnen PLZ würdest du dann den Systemusern zuweisen und die Steuerung der Kontakte und Firmen dann über einen Workflow

    steuern. Soweit habe ich es glaube ich richtig verstanden. Die große Frage ist dann aber, wie ich Postleitzahlen-Bereiche abbilden kann, da ich nicht alle einzelnen PLZ's pflegen kann. Auch habe ich dann noch nicht die Schreib und Lese-Zugriffe der Teamleiter und des Vertriebsleiters gelöst. Kannst du hierauf noch näher eingehen?

     

    Vielen Dank

     

    Daniel

    Mittwoch, 7. April 2010 10:00
  • Hallo Daniel,

    egal wie du es regelst, um die PLZ-Bereiche abbilden zu können wirst du um einen oder mehrere umfangreiche Workflows oder ein PlugIn nicht herumkommen, wenn du dieses automatisieren willst.

    WIe regelt ihr das denn eigentlich mich Firmen oder Kunden, die in mehr als einem PLZ-Bereich vertreten sind, oder gibt es so etwas bei euch nicht?

     

     


    Viele Grüße

    Michael Sulz
    MVP für Microsoft Dynamics CRM
    Mittwoch, 7. April 2010 10:59
  • Hallo Michael,

    egal wie umfangreich oder kostenintensiv die Implementierung sein wird. Sie muss später im Handling leicht von der Hand gehen. Auch spricht nichts gegen kostenpflichtige AddOns oder PlugIns. Die Lösung muss nur später bei Gebietsreformen handlebar sein.

    In unserer Unternehmensstruktur werden Kunden immer über die Rechnungsadresse dem Vertriebsmitarbeiter zugeordnet.
    Würde ein Unternehmen mehrere Rechnungsanschriften haben, werden für diese im SAP mehrere Kundennummern angelegt. So kann es auch sein, dass ein Unternehmen an mehreren Standorten von verschiedenen Vertriebsmitarbeitern betreut werden. Da es sich aber in unserem Unternehmen um Zahnarztpraxen,Implantologen, Labore oder Kliniken handelt kann es durch Gemeinschaftspraxen usw. mal dazu kommen, ist aber nicht die Regel.

    Die Frage die sich mir die ganze Zeit stellt ist, wie machen das andere Unternehmen mit Dynamics CRM. Vertriebsgebiete mit Einschränkungen auf die Sichten der Vertriebsmitarbeiter ist doch nicht ungewöhnlich, sondern habe ich in all meinen bisherigen Unternehmen so gehabt.Wie ist hier der Microsoft Grundgedanke???

     

    Grüße

    Daniel

     

     

     

    Mittwoch, 7. April 2010 11:23
  • Also ich würde nicht jede einzelne PLZ in der Entität hinterlegen, sondern immer die PLZ Gruppe. Die Gruppe wiederum einem Vertriebsmitarbeiter oder auch einem Team zuweisen. Dann die PLZ Entität mit Leads, Kontakten, Firmen verknüpfen und dadurch eine PLZ Struktur innerhalb der Kunden schaffen. 

    Dies dann gestützt durch einige Workflows und ggfs. Plugins sollte den Anforderungen schon sehr nahe kommen.

    Die Schreib-/Lese-Zugriffe der Teamleiter und des Vertriebsleiters sind natürlich von den gewählten Organisationseinheiten abhängig. Aber hier könnte ich mit ein paar WhoAmI-Abfragen herausbekommen, ob z.B. der aktuelle User dem PLZ-Gebiet X zugeordnet ist, dem zur Folge entsprechende rechte hat. Wenn nicht, könnte ich den kompletten Datensatz oder nur Teile zur Bearbeitung sperren.

    Dies als nur einen Denkansatz, innerhalb dessen man eine Lösung entwickeln könnte...


    Gruß Carsten Groth http://carstengroth.spaces.live.com
    Mittwoch, 7. April 2010 12:30
  • Der Grundgedanke von Microsoft ist hier Informationen zu verteilen und Sichten zu ermöglichen, nicht einzuschränken. Das ist hier wohl der Hauptunterschied.

    Nun, die initiale Verteilung der Firmen/Kontakte/Leads etc. lässt sich eigentlich recht simpel über einen Workflow abfackeln, der bei der Objekterstellung losläuft und je nach Wert der Postleitzahl den Datensatz einem User zuweist. Dadurch und durch die von mir vorhin erwähnte Organisationsstruktur könnte man schon eine Menge abwickeln. Man könnte das Ganze dann noch durch spezielle Sicherheitsrollen flankieren, die verhindern, dass gewisse Mitarbeiter Datensätze sehen, die nicht ihnen zugewiesen sind. Wenn man hier und da vielleicht minimal kompromissbereit ist, könnte man sich durch eine ausgereifte Konfiguration einiges an Entwicklungsarbeit sparen.

    Mittwoch, 7. April 2010 13:06
  • Hallo Daniel,

     ich würde für die Zugriffsberechtigungen der Außendienstmitarbeiter / Teamleiter / Vertriebsleiter auf die Kunden (Firmen) über Organisationseinheiten regeln. Diesen Weg hat   bereits AZiegler oben beschrieben.  Jeder Kunde hat dann einen CRM-Benutzer / ADM als Besitzer. Darüber werden die Zugriffsrechte gesteuert.

    Meine Idee für die initiale Bearbeitung und Aktualisierung: Die CRM-Standardfunktion Gebiete würde ich nicht nutzen.  Wir setzen bei Kunden eine externe Geomarketing-Software (RegioGraph) ein, die dann für jede PLZ (oder Gemeinde oder Landkreis etc) einen zuständigen Vertriebsmitarbeiter ermittelt. Die Daten kann man dann als Entität im CRM importieren und damit über Workflow / Plugin für Neukunden den zuständigen ADM suchen. Aus RegioGraph kann ich mir nach einer Gebietsumplanung in RegioGraph eine Datei mit Kundennummer / Vertriebsmitarbeiter erstellen. Über einen Import / Plugin / Workflow kann man dann den Besitzer beim Kunden ändern.

    Mit Geomarketing-Software visualisiert man z. B. die Standorte von Kunden und die Wohnorte   von AD-Mitarbeitern auf digitalen Landkarten. Damit kann man über die Software z. B. Entfernungen vom Kunden zum zugeordneten AD im Vergleich zum nächstgelegenen AD berechnen. Gibt manchmal schon Aha-Erlebnisse.  

    „Macken in der Vertriebsstruktur“ kann man über eine Kartendarstellung einfacher erkennen und verbessern. Es trägt auch zur Akzeptanz beim Außendienst bei, wenn jeder AD eine Landkarten mit seinen alten und neuen Kunden erhält. Eine Landkarte gibt da einen einfacheren Überblick.

    Weiße Flecken (z.B. PLZ-Bereich   ohne zugeordnete Kunden) kann man dann „automatisch“ mit dem nächstbesten AD füllen lassen.  Wenn man Gebiete gebildet hat, dann kann man auch weitere Daten wie Umsätze, Kundenanzahl,   Potential (z.B.  Anzahl Ärzte je PLZ)  in einem Vertriebsgebiet addieren lassen. Wenn dann der Vertriebsleiter an den Gebietsdefinitionen arbeitet, dann werden die Summen automatisch aktualisiert.   Es gibt ferner noch eine Vielzahl von Spezialfunktionen, die für die gerechte Gebietsplanung oder Gebietsoptimierung sinnvoll sind.   Nach Abschluß der Gebietsänderung erfolgt ein Export der neuen Zuordnung von Kunde zu  ADM bzw. von PLZ zu ADM.

    Ich habe auch einen konkreten Vorschlag für die Software: Für die Gebietsplanung setzen wir   die Geomarketing-Software RegioGraph ein. Über Excel –Export / Import oder eine verfügbare Schnittstelle von MS CRM zu RegioGraph kann man die Daten austauschen.  (Wir sind sowohl für Microsoft CRM als auch für RegioGraph zertifiziert, weil wir diese Kombination sehr spannend finden)

    Weil die Datei über eine Software erstellt wird, kann man ohne Probleme alle 8200 Zustell-PLZ verwalten. Auch Postfach-PLZ stellen kein Problem dar, weil man da einfach die nächstgrößere Zustell-PLZ nehmen kann.   Kunden mit einer Key-Account-Betreuung kann man schützen, indem Sie aus der Transferdatei ausgeschlossen werden. Über die Geomarketing-Software gibt es auch jedes Jahr eine Aktualisierung der PLZ / Gemeinde-Daten, weil sich da jedes Jahr irgend etwas (und manchmal viel) ändert.


    Herzliche Grüße Markus Müller
    Mittwoch, 7. April 2010 13:13
  • Hallo Carsten,

     

    danke für die Antwort und die Ideen. Ein Problem oder besser gesagt ein Gedanke bei deiner Idee verstehe ich nicht ganz. Ich muss ja um irgendwelche Automatismen zu generieren innerhalb der Firmen, der Kontakte oder der Leads, die PLZ's mit den PLZ's in der neuen Entität abgleichen und dadurch den Besitzer zuweisen. Hoffe ich habe das von der Logik richtig verstanden. Wie kann ich dies nun mit PLZ-GRuppen machen?

    Das mit den Berechtigungen und den Organisationseinheiten ist einleuchtend und gestern schon konzeptionell skiziert worden. Wäre es eigentlich auch denkbar die
    vorhandenenn Gebiete zu erweitern und dort die PLZ Gruppen zu hinterlegen??

     

    Grüße und vielen Dank noch einmal.

     

    Daniel

    Donnerstag, 8. April 2010 07:31
  • Hallo Carsten,

     

    danke für die Antwort und die Ideen. Ein Problem oder besser gesagt ein Gedanke bei deiner Idee verstehe ich nicht ganz. Ich muss ja um irgendwelche Automatismen zu generieren innerhalb der Firmen, der Kontakte oder der Leads, die PLZ's mit den PLZ's in der neuen Entität abgleichen und dadurch den Besitzer zuweisen. Hoffe ich habe das von der Logik richtig verstanden. Wie kann ich dies nun mit PLZ-GRuppen machen?

    Das mit den Berechtigungen und den Organisationseinheiten ist einleuchtend und gestern schon konzeptionell skiziert worden. Wäre es eigentlich auch denkbar die
    vorhandenenn Gebiete zu erweitern und dort die PLZ Gruppen zu hinterlegen??

     

    Grüße und vielen Dank noch einmal.

     

    Daniel

    Donnerstag, 8. April 2010 07:31
  • Hallo aziegler,

     

    auch dank an dich. Wie meinst du das mit den Sichten "ermöglichen" Die initiale Verteilung der Gebiete und PLZ Zuordnung macht mir eigentlich keine
    Probleme, da wir die Daten aus einem bereits vorhandenen System importieren und wir die Verteilung über einen xREF initial lösen. Die Problematik bezieht sich
    nur auf zukünftige Änderungen. Ich möchte in diesem Projekt aber so sauber wie möglich starten um später nicht mehr nacharbeiten zu müssen.

     

    Grüße
    Daniel

    Donnerstag, 8. April 2010 07:34
  • Hierzu gibt es zwei Möglichkeiten:

    A) An der PLZ Gruppen-Entität müsste natürlich der kleinste PLZ-Wert und der größte PLZ-Wert gelistet werden, um dann innerhalb des Arrays darauf zu schließen, ob eine PLZ aus z.B. Kontakt innerhalb der Gruppe A oder B liegt. Wenn die PLZs "wild" sortiert wären, dann müsste man in einem NTEXT-Feld alle der PLZ-Gruppe zugehörigen PLZ eintragen. Dieses Feld dann in ein Array konvertieren (String to Array) und dann die einzelnen PLZs aus z.B. einem Kontakt gen Array abgeleichen

     

    B) Neben der PLZ Gruppen Entität gibt es eine einzelne PLZ-Entität. Da die über öffentlich zugängliche PLZ-Register oder WebServices erhältlich sind, ist das mit der Pflege schnell erledigt. Nun könnten man einer PLZ Gruppe die einzelnen PLZs zuweisen. Dem entsprechend hätte ich natürlich auch eine Möglichkeit von der Gruppe auf einzeln zugewiesene PLZs zu schließen und könnte diese dann einzeln mit den PLZs aus Firmen, Kontakten, Leads abgleichen. Ebenso hätte ich den Vorteil, dass ich bei PLZ Verschiebungen innerhalb von Gruppen dies sehr schnell umsetzen könnte durch deaktivieren bzw. "umbuchen" einer PLZ in eine andere Gruppe

     

    Vorteil A: Du brauchst nur eine Entität zur Verwaltung Deiner PLZ-Gruppen

    Nachteil A: Du musst ein Gesamtstring in ein Array aufteilen und musst die PLZs in einen großen NTEXT Feld pflegen. Das ist für manchen unübersichtlich.

     

    Vorteil B: Du kannst x-beliebig viele PLZ unterschiedlichen Gruppen zuweisen

    Nachteil B: Du musst einmalig oder bei PLZ-Änderungen entsprechende Datensätze pflegen bzw. per Massenimport up-to-date halten (was jedoch nicht all zu häufig vorkommen dürfte)

     

    In beiden Fällen arbeitet es sich mit RetrieveMultiple (einmal mit LINQ, einmal ohne (im Fall A))

    Verständlich genug?

     


    Gruß Carsten Groth http://carstengroth.spaces.live.com
    • Als Antwort markiert rexible Freitag, 9. April 2010 12:20
    Donnerstag, 8. April 2010 07:54
  • Hallo Herr Müller,

     

    vielen Dank für den Anreiz. Wie ich gerade aus der Vertriebsleitung erfahren habe, wird wohl in Zukunft das GfK Distrikt für die zukünftige Planung von Gebeiten verwendet werden. Somit ist dieser Ansatz für uns der absolut richtige. Somit wären schon einmal alle Firmen und dazugehörigen Kontakte über einen Import aus District verwaltet. Wie realisieren Sie das mit LEADS und Kontakten ohne Zuordnung zu einer Firma bei Ihren Kunden?

    Grüße

    Daniel

    Donnerstag, 8. April 2010 08:11
  • Hallo Daniel,

    wenn es bei der Zuordnung nicht nur um Firmen, sondern auch um Leads bzw. Freiberufler (Einzelpersonen ohne Firma) geht, dann wandelt sich der Ansatz etwas. Bei der Geomarketing-Software arbeitet man mit sogenannten Schichten (Layern). Damit kann aus dem CRM die Standorte von Firmen, von Leads oder von Privatpersonen jeweils in einem Layer importieren.  Über eine Verschneidung mit dem Layer "AD-Gebiet" erhält man jeweils die Zuordnung von AD-Mitarbeiter zum Kunden, Lead bzw. Freiberufler.  Man kann auch mit verschiedenen Gebietsstrukturen arbeiten. Manchmal arbeiten zwei AD in einer Region  (z.B. Firmenkundenbetreuer  vs. Freiberuflerbetreuer) oder es gibt eine parallele Innendienst / Telefonmarketing-Struktur für kleinere Kunden

    Sofern Ihr eine reine PLZ-orientierte AD-Einteilung nutzt, dann geht es auch einfacher. Man kann aus dem RegioGraph Planung (so heißt "GfK District") eine Datei mit den Werte PLZ und AD-Mitarbeiter aufbauen.

    Wenn diese Datei als Entität im CRM importiert wurde, dann kann man diese Informationen über Plugin etc. für die Aktualisierung der Datensatz-Besitzer bei Account, Contact, Lead nutzen. Das macht man einmal für alle Datensätze direkt nach einer Umstrukturierung oder sonst bei Neuanlage eines Account, Leads oder Contacts automatisch.

    Die Zuweisung des Datensatzbesitzer sorgt auch für die Berechtigungssteuerung. Grundsätzlich sieht jeder Außendienstler seine Datensätze. Gruppenleiter oder Vertriebsleiter erhalten Lese- bzw. Änderungsrechte auf die einzelnen Kunden, Leads oder Kontakte über die Organisationseinstellungen.

    Gruß Markus

    P.S.:  Für Detailanfragen kann man mich auch anrufen. Concepta und MS CRM gibt eindeutige Ergebnisse beim Bingen oder Googeln.



    Herzliche Grüße Markus Müller
    Donnerstag, 8. April 2010 11:26
  • Hallo Daniel,

    wenn es bei der Zuordnung nicht nur um Firmen, sondern auch um Leads bzw. Freiberufler (Einzelpersonen ohne Firma) geht, dann wandelt sich der Ansatz etwas. Bei der Geomarketing-Software arbeitet man mit sogenannten Schichten (Layern). Damit kann aus dem CRM die Standorte von Firmen, von Leads oder von Privatpersonen jeweils in einem Layer importieren.  Über eine Verschneidung mit dem Layer "AD-Gebiet" erhält man jeweils die Zuordnung von AD-Mitarbeiter zum Kunden, Lead bzw. Freiberufler.  Man kann auch mit verschiedenen Gebietsstrukturen arbeiten. Manchmal arbeiten zwei AD in einer Region  (z.B. Firmenkundenbetreuer  vs. Freiberuflerbetreuer) oder es gibt eine parallele Innendienst / Telefonmarketing-Struktur für kleinere Kunden

    Sofern Ihr eine reine PLZ-orientierte AD-Einteilung nutzt, dann geht es auch einfacher. Man kann aus dem RegioGraph Planung (so heißt "GfK District") eine Datei mit den Werte PLZ und AD-Mitarbeiter aufbauen.

    Wenn diese Datei als Entität im CRM importiert wurde, dann kann man diese Informationen über Plugin etc. für die Aktualisierung der Datensatz-Besitzer bei Account, Contact, Lead nutzen. Das macht man einmal für alle Datensätze direkt nach einer Umstrukturierung oder sonst bei Neuanlage eines Account, Leads oder Contacts automatisch.

    Die Zuweisung des Datensatzbesitzer sorgt auch für die Berechtigungssteuerung. Grundsätzlich sieht jeder Außendienstler seine Datensätze. Gruppenleiter oder Vertriebsleiter erhalten Lese- bzw. Änderungsrechte auf die einzelnen Kunden, Leads oder Kontakte über die Organisationseinstellungen.

    Gruß Markus

    P.S.:  Für Detailanfragen kann man mich auch anrufen. Concepta und MS CRM gibt eindeutige Ergebnisse beim Bingen oder Googeln.



    Herzliche Grüße Markus Müller
    • Als Antwort markiert rexible Freitag, 9. April 2010 12:20
    Donnerstag, 8. April 2010 11:26
  • Vielen Dank für die Ausführung. Fall B wäre von der Verwaltung meines Erachtens der elegantere Einsatz. Ich werde nun deinen Vorschlag zu Verwaltung der Gebiete innerhalb des CRM mit dem Vorschlag von Markus Müller aufarbeiten und so dem Projektteam präsentieren.

    Dann werden wir uns um dein Aufbau des Systems kümmern.

    Daniel Rexer

    Freitag, 9. April 2010 12:16
  • Danke Markus,

     

    habe auch deine Nachricht auf Xing bekommen. Dein Ansatz ist sehr logisch und wie oben beschrieben werde ich diesen beim Projektteam präsentieren. Falls ich noch einmal Unterstützung benötige, werden wir uns noch einmal bei dir persönlich melden.

     

    Vielen Dank und Grüße

     

    Daniel Rexer

    Freitag, 9. April 2010 12:20