Standard, Custom oder lieber beides?
Bei der Einführung eines CRMs haben Sie, wie so oft im Leben, generell zwei Möglichkeiten: Den Standard oder eigene Custom-Prozesse nutzen. Doch wie sieht der Standard aus, was beinhaltet dieser? Wie viel Anpassung ist sinnvoll und welche Folgen ergeben sich dadurch? Wir möchten Ihnen hier aufzeigen, warum sich Standardnähe lohnt und was es beim Customizing zu beachten gilt.
Als Unternehmen erwarten Sie von Ihrem CRM-System, dass es Sie bei allen wesentlichen Arbeitsabläufen unterstützt. Damit das gelingt, muss die Struktur dieser Abläufe im System möglichst genau abgebildet sein. Da wahrscheinlich kein zweites Unternehmen auf der Welt genau dieselben Leistungen bietet, genau dieselben Abläufe hat, wird es auch kein identisches CRM-System geben. Also alles selbst bauen (lassen)? Oder auf vorhandenes zurückgreifen? Standard oder Custom?
Der Sinn von Standards
Bei jedem Problem, dass Sie in Ihrem System abbilden, können Sie sich sicher sein: Jemand anderes stand vor Ihnen schon vor einer ähnlichen Aufgabe. Viele Abläufe in der Wirtschaft sind standardisiert, sei es durch die Wirtschaftswissenschaften, als Best Practice oder aus gesetzlichen Gründen. Es ergibt also wenig Sinn, alle Prozesse noch einmal selbst erfinden zu wollen.
Ein CRM-System wie Salesforce können Sie sich wie eine Art Baukasten vorstellen: Es gibt vorgefertigte Prozesse und Prozess-Bausteine. Welche sie davon nutzen und wie Sie das tun, bleibt am Ende Ihnen überlassen. Ihr System muss auch nicht zwingend alle Prozesse Ihres Unternehmens abbilden (wenngleich doch die vernetzte Nutzung der vorhandenen Daten einige Vorteile bieten kann). Denkbar ist auch, dass z.B. der Kundenservice ein eigenes System benutzt, das mit dem Marketing nur über einige Schnittstellen verbunden ist. Dann ist dieses System auch nicht auf die Marketing-spezifischen Lösungen angewiesen. Zudem benötigen Sie für manche Features besondere Lizenzen.
Salesforce bietet standardmäßig eine übersichtliche Darstellung des Datenmodells.
Allen Salesforce-Systemen (oder Organisationen, kurz Orgs) liegt ein Datensystem zugrunde, das zunächst zahlreiche Standardobjekte enthält. Denken Sie dabei z.B. an Accounts, Contacts, Leads und Opportunities, aber auch an die User, die später das System benutzen sollen. Zu diesen Objekten gesellt sich eine Reihe von Standardprozessen – beispielsweise die Umwandlung von Lead zu Opp oder das Hinzufügen eines Kontakts zu einem vorhandenen Account. Die eigentlichen Datensätze werden dann als Records bezeichnet; das Objekt stellt quasi eine Art Schablone für die Records dar.
Die Möglichkeiten des Customizing
Natürlich kann Salesforce von Haus aus nicht alle nötigen Strukturen abbilden. Beispielsweise kann es für einen Automobilhändler sinnvoll sein, die angebotenen Modelle und Konfigurationen in Salesforce abzubilden. Dafür wird er typischerweise ein eigenes Custom Object benutzen, das die relevanten Eigenschaften enthält – denkbar sind die Motorleistung, die Unterscheidung Diesel oder Benziner, Anzahl der Türen, der Preis und alles mögliche weitere.
Aber der Händler kann auch Standardobjekte um eigene Datenfelder erweitern: Er möchte vielleicht seine Kontaktfirmen in Zulieferer, Werkstätten, Firmenkunden und Privatkunden einteilen. Dazu fügt er dem Account-Objekt ein Custom Field hinzu, etwa eine Auswahlliste mit vordefinierten Werten. Das garantiert eine schnelle und konsistente Einordnung der Firmen in die verschiedenen Kategorien. Die Standardprozesse funktionieren natürlich auch für Standardobjekte, die auf diese Weise um eigene Felder erweitert wurden.
Standardnahes Customizing
Eine Best Practice im CRM- und insbesondere im Salesforce-Bereich ist das standardnahe Customizing. Wahrscheinlich haben auch Sie schon einmal davon gehört: “Wir müssen nahe am Standard bleiben.” oder “Wie wollen standardnah entwickeln.” Was verbirgt sich hinter diesem Schlüsselwort?
Salesforce ermöglicht das Erstellen eigener Prozesse nach dem “Point-and-Click”-Prinzip. Das bedeutet ganz einfach, dass z.B. für die Erstellung eines Workflows, einer Validierungregel oder auch einer eigenen Detailseite keine einzige Codezeile nötig ist. Alle diese Aufgaben können in grafischen Menüs durch reine Mausklicks erledigt werden. Dieses Verfahren nennt man “standardnah”, weil die Resultate von jedem Standardnutzer angesehen und verstanden werden können (wenn er denn Administratorrechte hat). Im Salesforce-Setup ist auch recht leicht ersichtlich, welche Prozesse gerade aktiv sind. Anpassungen können häufig dadurch realisiert werden, dass der vorhandene Prozess geklont wird. Die so entstandene Kopie wird weiter bearbeitet, und zu guter Letzt kann jederzeit eine der beiden Varianten aktiviert werden.
Demgegenüber wollen erfahrene Programmierer häufig lieber ein paar Zeilen Code schreiben, anstatt sich dieser Menüs zu bedienen. Der Vorteil größerer Freiheit in der Prozessgestaltung wird dabei durch den Nachteil geringerer Übersichtlichkeit erkauft. Ein anderer Admin kann nicht mehr so einfach sehen, was in diesen Prozessen genau passiert, und spätere Anpassungen erfordern ein hohes Maß an Einarbeitung und Erfahrung. Da Programmierung in mehrstufigen Systemlandschaften nur in den Entwicklungsumgebungen erlaubt ist, müssen eventuelle Probleme oft aufwendig durch mehrmaliges Transportieren behoben werden.
Komplettes Customizing
Das soll nicht heißen, dass es keinen Platz für komplett selbst erstellte Prozesse gibt. Nicht umsonst werden häufig Lightning Components mit eingebundener Apex-Logik erstellt. Dadurch hat der Entwickler Zugriff auf alle Salesforce-Features. Er kann Änderungen vornehmen, ohne sie in die vorgegebene Struktur z.B. eines Workflows zu pressen. Und auch für das Entwickeln von Code gibt es Best Practices, also quasi-Standardprozesse für das “standardferne” Entwickeln.
Beispiel Trigger
Ohne allzu technisch zu werden, möchten wir Ihnen diese Möglichkeiten kurz an einem Beispiel erläutern: In Salesforce-Systemen werden häufig sogenannte Trigger eingesetzt. Stellen Sie sich als simples Beispiel vor, Sie passen die Adresse eines Accounts an und möchten, dass diese Adresse auch auf allen angehängten Kontakten geändert wird. Das könnte über einen Account-Trigger geschehen, der nach jeder Änderung automatisch ein paar Zeilen Code ausführt.
Der Prozessgenerator erlaubt das einfache Anlegen von Prozessen.
Standardnah wäre hingegen, über den grafischen Prozessgenerator (engl. Process Builder) einen Prozess zu erstellen, der z.B. für die Postanschrift der Kontakte die Lieferanschrift des Accounts übernimmt. Allerdings “kann” der Prozessgenerator sehr viel mehr, deshalb sieht dieser einfache Ablauf verhältnismäßig kompliziert aus. So bietet er an, die Änderung nur unter bestimmten Kriterien auszuführen – hinter dem blauen Quadrat in der Grafik ist darum “Keine Kriterien – Aktionen ausführen!” hinterlegt. Auch zeitversetzte Aktionen sind möglich, etwa das Versenden einer Erinnerung nach einer Woche. Häufig sind jedoch die Bedingungen stark verzweigt oder die geplanten Aktionen sehr viel komplexer. Dann bietet sich eher ein Trigger an.
Für diesen Trigger gibt es die Best Practice, ein Trigger Framework zu implementieren. Das ist quasi eine Verteilerlogik, die alle verschiedenen Trigger nacheinander delegiert. Zum einen wird so eine feste Reihenfolge definiert, wenn mehrere Trigger auf einem Object aktiv sind (beispielsweise für weitere Änderungen neben der Adresse). Des weiteren wird die Logik (der eigentliche Code, der in unserem Beispiel die Contact-Adressen ändert) in eine Hilfsmethode ausgelagert. Dadurch ist sie vom eigentlichen Triggeraufruf getrennt und kann beispielsweise auch in anderen Methoden genutzt werden.
Gerade in länger bestehenden, großen Salesforce-Orgs kommt es oft vor, dass mehrere Entwicklerteams nacheinander Trigger für ein Objekt erstellen. Es passiert durchaus häufig, dass dann ein Trigger unerwartet “querschlägt”, also ein zuvor entwickelter Trigger ein unerwartetes Verhalten an den Tag legt. Mit einem Trigger Framework ist es wesentlich einfacher, dieses Verhalten zu isolieren und nachzuvollziehen. Bei Bedarf lässt sich auch die Reihenfolge, in der die einzelnen Trigger ausgeführt werden, leicht anpassen.
Resumee: Standard oder Custom?
Die Nutzung des Salesforce-Standards bzw. eine standardnahe Entwicklung hat einige Vorteile:
- Das grafische Menü erlaubt ein einfaches Nachvollziehen und Anpassen der einzelnen Prozessbestandteile.
- Die Prozesse können auch auf einem Produktivsystem angepasst, ersetzt oder kurzzeitig ausgesetzt werden.
- Im Setup der Salesforce-Org sind die Prozesse an wenigen Stellen abgelegt und somit gut auffindbar.
Doch auch der Einsatz komplexen Programmcodes bringt seine Vorteile mit sich:
- Der Entwickler hat einfachen Zugriff auf alle Salesforce-Features.
- Die Entwicklung richtet sich nicht nach einem vorgegebenen Schema, sondern kann individuell auf das Problem angepasst werden.
- Mehrere Aufgaben können gebündelt werden, statt für jede einen einzelnen Prozess aufzusetzen.
Wie so oft im Leben müssen Sie sich nicht auf eine dieser beiden Möglichkeiten festlegen: Sie können Standard- und Custom-Prozesse kombinieren. Wo immer möglich, nutzen Sie dann den Salesforce-Standard bzw. die standardnahe Entwicklung. Sollte dies nicht praktikabel sein, kommen Eigenentwicklungen zur Anwendung – so einfach wie möglich, so komplex wie nötig.
