Salesforce Prozessanalyse und Lösungskonzeption, Entwicklungsleitung, Umsetzung von komplexen technischen Anforderungen

Das Ziel des Projektes war es, eine prototypische App für den Fachbereich weiterzuentwickeln, mit weiteren Features anzureichern und eventuell vorhandene Bugs zu beheben. Am Ende sollte die App im gesamten Fachbereich für alle Studierenden ausgerollt werden. Der Wunsch des Kunden war es, dass am Ende eine Android- und eine deckungsgleiche iOS-App im App Store vorhanden sind, mit denen man unter anderem Prüfungsanmeldungen durchführen und die aktuellen Mensapläne für alle für einen wichtigen Kantinen anzeigen kann. Meine Rolle war es, in einem sechsköpfigen Team an dieser App zu arbeiten und sie zum Release zu begleiten. Ich spezifisch kümmerte mich um Weiterentwicklungen an der Android-App und Fehleranalyse im zuständigen Server-Backend. Zum Ende des Projekts wurden alle wichtigen Funktionalitäten vollständig implementiert und die App für alle Studierenden verfügbar gemacht. Die Ergebnisse waren zur vollen Zufriedenheit der Stakeholder.

Im Rahmen des Projekts sollte die Usability auf verschiedene Arten und Weisen verbessert werden. Durch neue GUI-Elemente sollte für die Mitarbeiter Formulare vorbefüllt werden. Ferner sollten die Mitarbeiter in der Lage sein, ihre Preisaufstellungen zukünftig in Eigenregie pflegen zu können. Für ersteres konzeptionierten ein Kollege und ich eine Lösung und setzten sie in einer Testumgebung um. Kurz darauf wurde diese Lösung in den Produktivbetrieb geschaltet. Für die zweite Anforderung fertigte ich Dokumentationen und Arbeitsvorschläge an, um dem Kunden den Prozess und die dafür notwendigen Datenstrukturen zu erklären.

Im Rahmen meiner Abschlussarbeit untersuchte ich die Salesforce Best Practices für Softwareeinführungen unter Zuhilfenahme von Literaturgrundlagen für Anforderungsanalyse und Datenqualitätsanalyse. Hierfür verglich ich ein Kundenprojekt in der Chemie mit den in der Literatur angegebenen Best Practices und schloss hieraus Folgerungen für die Umsetzbarkeit von diesen Vorgehensweisen als externer Berater in Softwareeinführungsprojekten.

Im Rahmen dieses Projektes sollte die Migration von SAP-Umsatzbelegen in das Salesforce-System teilweise automatisiert werden. Hierbei besteht die Herausforderung darin, dass unter dem Dachnamen zwei Firmen stecken, die getrennte Abrechnungen machen müssen und deren Belege daher auch voneinander getrennt werden müssen. Darüber hinaus ist eine weitere Herausforderung die Anpassung der Belege an ein Format, welches vom Salesforce Data Loader akzeptiert wird. In meiner Rolle in dem Projekt war ich der erste Ansprechpartner für den Projektleiter des Kunden und für die Implementierung der Lösung zuständig. Zunächst wurde hierfür ein neues Objekt angelegt, anschließend eine neue Umsatzübersicht für die importierten Belege eingeführt.

Im Rahmen dieses AMS-Projektes stellte ich den Level 1 Support für die Salesforce-Instanz des Kunden. Wenn Kunden ein Problem mit der Bedienung des Systems hatten, stand ich mit Rede und Antwort zur Seite und leitete Probleme technischer Natur an die zuständigen Bereiche weiter. Zu den Tätigkeiten in meiner Rolle gehörten das Erteilen von Berechtigungen, Beantwortung von Fragen zum Vertriebsprozess des Kunden und generelle Administrationstätigkeiten.

Im Rahmen einer Salesforce-Datenmigration sollen in diesem Projekt ebenfalls alle zugehörigen Chatter-Posts der Benutzer zu ihren Vertriebsdaten migriert werden. Hierbei besteht die Herausforderung darin, die Posts der einen Plattform mit den neuen Daten der anderen Plattform in Zusammenhang zu bringen. Hierzu konzeptioniere ich einen Weg, die Chatter-Posts zwischen zwei unterschiedlichen Organisationen zu übertragen und setze ihn dann für die Produktivsituation um. Dazu gehören die jeweiligen Posts sowie die zugehörigen Gruppen und Dateianhänge. Zum Abschluss des Projektes führte ich diese Migration ebenfalls durch, indem ich die bis dahin angehäuften Dateien exportierte, die Nachschlagetabellen anlegte und die ganzen Daten mit ihren neuen Nachschlagebeziehungen auf die neue Salesforce-Instanz lud.

In diesem Projekt agiere ich als der Entwicklungsleiter für alle Entwicklungen unserer eigenen Salesforce-Instanz. Es gilt hier, alte Entwicklungen entweder zu modernisieren oder gegen neue Komponenten auszutauschen. Da unsere Instanz historisch gewachsen war, haben wir zudem das gesamte Backend refactored und Frameworks sowie Entwicklungsrichtlinien eingeführt. Nun konzipiere ich Lösungen für neue Features und Lösungen, entwickle diese entweder in Eigenregie oder durch Delegation und Kontrolle an Kollegen.

Das Ziel von Phase 1 im betriebsweiten Salesforce-Projekt war die Vorbereitung für weitere Entwicklung und eine Vereinfachung einer zukünftigen Einführung von Lightning. Hierfür waren folgende Tätigkeiten im Scope: - Entkopplung von den Einflüssen von Fremdcode - Erhöhung der allgemeinen Testabdeckung - Einführung von automatisierten Tests - Rollout eines neuen Development Lifecycle - Erarbeitung eines Workflows mit der neuen Salesforce Developer Experience (DX) - Refactoring von altem Code auf heutige Coding-Standards Die Arbeiten an diesem Projekt waren dadurch bedingt überwiegend auf das Backend fokussiert, wo technische Schulden aufgearbeitet werden mussten. In meiner Rolle arbeitete ich zusammen mit dem Entwicklungsleiter, den mindsquare-Entwicklern und dem internen Salesforce-Team daran, diese Anforderungen umzusetzen. Besonderen Fokus legte ich dabei auf Continuous Integration mit Jenkins und die Erarbeitung eines funktionierenden Workflows mit Salesforce DX, welcher an die Anforderungen der Instanz des Kunden angepasst ist (Beispielswiese durch automatisierten Import von Datensatztypen). Darüber hinaus wurde ich in die Prozesse des Unternehmens eingeweiht und testete bei Codeänderungen diese auf fortbestehende Funktionalität.

In dem Projekt soll ein altes System abgelöst werden, in welchem Genehmigungsprozesse für die Priorisierung von Akquisitionen angestoßen und durchgeführt werden. Die Herausforderung ist, dass dies nicht mit Standard-Prozessen in Salesforce abgebildet werden kann, da die Anforderungen des Kunden erfordern, diese Genehmigungen asynchron und von einer Rollenzuweisung abhängig durchführbar zu machen. Hierfür habe ich dementsprechend einen neuen auf Triggern und Custom Objects basierenden Prozess konzipiert, und diesen mit einer auf Lightning basierenden Benutzeroberfläche für die Vertriebsmitarbeiter zugänglich gemacht. Mit den Ergebnissen ist der PO sehr zufrieden. In meiner Rolle als Entwicklungsleiter war ich dafür verantwortlich, für alle fortwährenden Entwicklungen an dem Salesforce-System des Kunden (sowohl von intern als auch von extern) Git einzuführen, um die Entwicklungen vieler Entwickler auf einmal unter Kontrolle zu halten, Überschreibungen zu vermeiden und einen geregelten Deployment-Prozess einzuführen.

In diesem Projekt liegt der Fokus auf der fortwährenden Weiterentwicklung einer großen Salesforce-Instanz mit vielen Zwischenabhängigkeiten und Objekte, die zu einer Produktionsabsatzplanung dienen sollen. Meine Rolle im Projekt ist die eines Entwicklungsleiters. Ich steuere alle Deployments auf die Testinstanz und auf Produktion und führe regelmäßig Code Reviews für die Ergebnisse der internen Entwickler durch. Neben der Entwicklung als solcher stehe ich in dem Projekt auch in regelmäßigem Diskurs mit einem Team aus Projektmanagern, welche sich die Verantwortlichkeiten einzelner Module im System untereinander aufteilen. Durch die Gespräche werden Anforderungen besser definiert, abgewandelt oder teilweise durch Hinfälligkeit auch verworfen. Der Wert wir klar auf eine stabil laufende Salesforce-Instanz gelegt.

In diesem Projekt gilt es, aus einer globalen, durch Governance und Genehmigungsprozesse schwer ausbaubaren Salesforce-Instanz eine eigene, nur für den deutschen Zweig des Konzerns zu erstellen. Dies bedeutet, in Zusammenarbeit mit dem internationalen Team die Metadaten zu extrahieren, Abhängigkeiten zu entfernen und das ganze fertig für einen Transport vorzubereiten. Darüber hinaus werden Prozessoptimierungen und neue Features mit der Lightning-Oberfläche entwickelt und bei Rollout direkt veröffentlicht. Hier ist vor allem Dynamik in der Konfiguration von Eingabemasken wichtig, was durch ein angepasstes umfangreiches Datenmodell ermöglicht wird.

In diesem Projekt geht es um die Vorbereitung einer Salesforce-seitigen Integration zu SAP. Hierzu gehört eine Überarbeitung der Datenaggregation, ein Prozess der die fehlenden Daten anfordert, und das Ansprechen einer Schnittstelle in der Integrationsplattform SAP PI Die Herausforderung hierbei besteht darin, dass viele Bestandsdaten von diesem Prozess und den Anpassungen betroffen sind und diese umfassend mit behandelt werden müssen. Dies wird erledigt indem täglich asynchron laufende Prozesse für ein frühestmögliches Vorhandensein der Daten in synchrone Prozesse migriert werden.

In diesem Projekt ging es darum, einen alten, auf Custom Objects basierenden Sales-Prozess in Standardobjekte zu übersetzen und dabei auf die neuen Sales Agreements, welche durch die Manufacturing Cloud eingeführt worden ist. Die Herausforderung lag darin, dass der Prozess für Besuchsberichte ebenfalls in Angebote übergeht und daher als Opportunity behandelt werden müssen. Darüber hinaus bestehen technische Schwierigkeiten im Umgang mit den Begebenheiten der Manufacturing Cloud. Unsere Lösung besteht aus Ablöse von Eingabemasken durch eigens entwickelte Umgebungen und sinnvolle Verwendung von Standardfeldern zur Abbildung der Besuchsberichte. Darüber hinaus wurden insbesondere Migrationsskripte und Automatisierungen geschrieben, die hinsichtlich des Datenschemas den Prozess weiterführen.

Der Kunde benutzt Salesforce für eine Vermittlungsplattform, welche Mieter und Vermieter zusammenbringt und auf Basis von Produktdaten nur die richtigen Anbieter anspricht. Nach der ersten Einführung dieses Prozesses galt es nun, die Möglichkeiten zu erweitern. Dazu gehört vorwiegend die Einführung einer Angebot-Versandfunktion, die zeitgleich das Ändern und Einbetten von Email-Vorlagen unterstützt, und die Verknüpfung von Zusatzprodukten an ein bestehendes Produkt, welches in einer Anfrage mit erwähnt werden soll. Da die Produkthierarchie zu Beginn recht starr gewählt wurde, war die große Herausforderung hier diese Zusatzprodukte entsprechend abzubilden und in den notwendigen Komponenten anzeigbar und auswählbar zu machen. Dies wurde durch die Einführung einer Pseudo-Produkthierarchie gelöst.

Nachdem der Kunde bereits auf einer "kleineren" Version des Salesforce-Systems aufbauend bereits einen Teil der Prozesse abgebildet hatte, wuchs der Bedarf nach einer allumfassenden Plattform, welche den Vertriebsprozess abbildet und den Alltag erleichtert. Da der Kunde stark mit SAP verzahnt arbeitet, ist ein großer Bestandteil dieses Projekts der Austausch von Daten zwischen SAP und Salesforce. Vordergründig gibt es hier die Ausleitung von in SAP erstellten Datensätzen zur weiteren Bearbeitung und Einsicht in Salesforce, sowie ein beidseitiger Austausch von Daten zwischen SAP und Salesforce bei der Bearbeitung von Angeboten. Hierfür sprechen sowohl SAP als auch Salesforce eine Middleware an, während für die Einwege-Übertragung Jitterbit verwendet wird. In meiner Rolle als Projektmanager und zeitgleich Entwickler war ich federführend für die Integration der REST-Schnittstellen und Callouts, die die Kommunikation zwischen Salesforce und SAP ermöglichen. Darüber hinaus bestand der Bedarf nach weiteren Automatisierungen, die es bei einem Import ermöglichen, auf Basis von verschiedenen Externen IDs im Code die richtigen Zuordnungen zu finden. Das Ergebnis ist ein stark integriertes Salesforce-System, welches in Sachen Vertrieb, Absatzplanung, Support und Marketing verwendet werden kann und an allen notwendigen Stellen mit SAP spricht. Der Kunde ist nun in der Lage, die Software in voller Gänze an sowohl den Innendienst als auch den Außendienst auszurollen.

Unser Kunde stand vor der Herausforderung, dass seine Mitarbeiter nach einer Unternehmensfusion mit einem Partnerunternehmen ihre Prozesse auf Salesforce umstellen mussten. Da bisher keine Erfahrung mit Salesforce im Haus bestand und das Partnerunternehmen ausschließlich externe Dienstleister für die Administration und Weiterentwicklung von Salesforce beauftragt hatte, hat uns der Kunde für eine mehrmonatige Reihe an Schulungen beauftragt, um die verschiedenen IT- und Fachabteilungen Schrittweise in die neue Systemlandschaft einzuführen. Da die Wartung der alten Systeme unseres Kunden komplett intern gehandhabt wurde, besteht der Anspruch, dass die Entwickler sich ebenfalls mit den neuen Technologien von Salesforce auseinander setzen. Die Annäherung der internen Entwickler an Entwicklung mit Salesforce lag im Fokus dieser Schulungsreihe. In dieser Schulungsreihe ging es vor allem um die Vermittlung von Know How rund um die verschiedenen aktuell von Salesforce angebotenen Technologien für die Entwicklung von Automatisierungen und eigenen User Interfaces, sowie den Transport dieser Ergebnisse auf die Produktionsinstanz. Meine Aufgabe bestand in der Vorbereitung der Themen, der Ausarbeitung der Schulungsunterlagen, der Durchführung und Moderation, sowie der regelmäßigen Anpassung auf aktuelle Use Cases des Kunden, um die bestmögliche Schulung zu gewährleisten. Das Ergebnis war eine sehr umfassende Menge an individuell geschulten Nutzern mit unterschiedlichsten Sichten auf das System. Vor allem waren die Anwender nun in der Lage, bestehende Entwicklungen in Frage zu stellen und eigenständig zu optimieren.

In diesem Projekt wird die zuvor eingeführte Lösung für das Verwalten und Automatisieren von Anfragenmanagement auf Vermieterseite durch ein neues User-Interface und damit einherkommend neue Funktionalitäten erweitert. Hierfür wurde von Seiten des Kunden ein Design vorgegeben, welches wir in dem Aura Framework nachgebaut haben, um es für den Kunden zugänglich zu machen. Darüber hinaus standen wir in Korrespondenz zu dem internen Data Intelligence Team, um zwischen Salesforce und einer Produktstammdatensoftware eine Verbindung herzustellen. Hierfür mussten eigene REST-Schnittstellen geschrieben werden, welche die Produktdaten vor einer Übertragung oder einem Update validieren. In der Rolle als Projektmanager und Architekt bin ich der Hauptansprechpartner für die Anlegung von User Stories und steuere die internen Entwickler sowohl aus Management-Sicht als auch fachlich. Darüber hinaus führe ich Code Reviews durch, um die Qualität der Arbeit aufrecht zu erhalten und nur qualitativ hochwertigen Code auf die Produktionsinstanz zu releasen.

In dem Projekt galt es, eine Verbindung zwischen Salesforce und dem SAP PPM System des Kunden herzustellen. Das Projektportfolio möchte Daten über die Produkte, die in Salesforce angelegt werden, bekommen, und das SAP-System gibt Daten über die Projektverknüpfung bestimmter Produkte an Salesforce weiter. In meiner Rolle als technischer Ansprechpartner konzipierte ich die Integration zwischen den beiden Systemen und übernahm die Kommunikation mit den internen Ansprechpartnern auf der Salesforce- und SAP-Seite.

Der Kunde betreibt eine Plattform für die Vermittlung von Hostessen und anderem Eventpersonal. Diese Plattform basiert im Backend auf Ruby on Rails und soll gestützt durch einen Kundenstamm, gepflegt in Salesforce, ihre Daten beziehen. Der Scope dieser Integration bezieht sich derzeit auf Firmendaten und Kundendaten. Diese werden nun dynamisch auf einer beliebig anpassbaren Feld-Abfolge basierend bei Änderungen an die Plattform übertragen, wo sie schlussendlich entweder neu erstellt oder aktualisiert werden. Dies passiert über einen REST-Webservice auf der Seite der Plattform Meine Aufgabe bestand darin, das Konzept für die Integration auszuarbeiten und in Zusammenarbeit mit dem internen Team die Integration zu implementieren und Massen-Übertragungen für eine initiale Population der Datenbank sowie für Validierungen anzustoßen. Das Ergebnis ist eine stark verzahnte Systemlandschaft, in der die Plattform und das Kundenmanagementsystem stets den gleichen Informationsstand haben.

Im Rahmen dieses Projektes ist die Anforderung, das Salesforce-System, welches als führendes System für den Abschluss eines Mietvertrages gilt, mit dem Rechnungssystem Billomat zu integrieren. Die Herausforderung: Billomat unterstützt zwar Abonnement-Rechnungen, helfen diese nicht bei Einmal-Zahlungen, temporären Rabatten und Upsells. Die Anzahl dieser Randfälle lassen uns die Integration per Apex umsetzen. Für diese Anbindung und nachträgliches Umsatzreporting in Salesforce überprüfen wir die Validität von einzelnen Verträgen, Rabatten und Positionen, erstellen die Rechnungen dann zunächst in Salesforce und verwenden dies als Grundlage für Billomat.

Der Kunde führte für seinen Außendienst Field Service Lightning ein und benötigte zusätzliche Unterstützung bei der Einführung von Anforderungen, die vom Standard abweichen und über Code gehandhabt werden müssen. Hierbei unterstützte ich als Entwickler bei der Ausgestaltung einer nach Corporate Design gestalteten Visualforce-PDF für den Service-Bericht. Darüber hinaus unterstützte ich bei der Erstellung von Work Order Line Items dann, wenn benötigte Produkte erstellt wurden. Diese Sachen waren bei dem Kunden synchron zu halten. Der Kunde war durch diese Unterstützung in der Lage, seine Prozesse mit Field Service Lightning abzudecken, ohne unnötige zusätzliche Arbeitsschritte zu begehen.

Der Kunde benutzt wiederverwendbare Textbausteine in Kombination mit Platzhaltern und Unterteilung in mehrere kleinere Untersektionen zur Erstellung von Produktspezifikationen mit Versionierung und PDF-Druck. Um die pure Machbarkeit dieses dynamischen Aufbaus zu beweisen, wurde ein Proof of Concept eingeleitet, der mit einem rudimentären User Interface ein PDF konfigurierbar gemacht hat. Um die Integration mit dem Content Management System des Kunden zu prüfen und einen klaren Integrationsweg zu definieren, wurde daraufhin ebenfalls ein Schnittstellenvertrag verfasst, welcher die Datenstrukturen gegenüberstellt und die genauen Services aufnimmt, welche für eine erfolgreiche Integration notwendig sind.

Der Kunde betreibt eine hochkomplexe und mit mehreren externen Systemen integrierte Salesforce-Instanz zum Abschluss von Energielieferverträgen. Über meine Zeit dort konnte ich Prozesswissen aufbauen und dieses auf einer Systemebene widerspiegeln, um damit unter anderem anderen Landesgesellschaften den Kunden mit Vorschlägen zu dienen. Darüber hinaus half ich mit Best Practices dabei, veraltete und nicht mehr skalierbare Technologien nach und nach durch neue Frameworks und Apps abzulösen. Kommuniziert wurde sowohl innerhalb des Teams, welches die Applikation wartet, als auch mit Stakeholdern, bei denen ich Workshops geführt und Schaubilder zur Veranschaulichung von Prozessen verwendet habe. Darüber hinaus habe ich entwickelte Prozesse anschaulich für Administration und Product Owner dokumentiert.

Der Kunde hatte historisch mehrere Produkte gleichzeitig vermietet, diese jedoch zu unterschiedlichen Zeitpunkten zurück erhalten, was systemseitig nicht berücksichtigt werden konnte. Dieses Projekt passte den Prozess dahingehend an, um die Vermietungszeiträume, Freimeldungen und alle weiteren Prozesse die Vermietung betreffend auf einem Produkt statt auf einem gesamtheitlichen Projekt abzubilden. Die Herausforderungen hierbei waren grundlegende Bearbeitungen an den Kernprozessen des Kunden und damit einhergehendes intensives Testing. Darüber hinaus wird durch Parent-Child Hierarchien mit großen Datenmengen gleichzeitig gearbeitet. Die gezielte Verwendung von Plattform Events und Change Data Capture hat uns jedoch hierbei geholfen, keine Probleme mit Rechenlasten und Laufzeiten zu bekommen. Meine Rolle war die des Architekten. In meiner Verantwortung stand die Konzeption des Prozesses sowie die Erarbeitung der notwendigen Bearbeitungen im System, um den neuen Prozess funktionieren zu lassen. Letztendlich habe ich ebenfalls bei Testing, Fixes und dem GoLive unterstützt.

Der Kunde betreibt eigenständige Konfiguration in seinem Salesforce-System und wird zusätzlich von einem mehrköpfigen Service-Team für Entwicklung unterstützt. Durch sehr stark zentralisierte Anforderungen auf einem bestimmten Teil des Systems kam es desöfteren zu Regressionen und unverhofften Fehlern im Testen und auf Produktion. Der Entwicklungsprozess, welcher in Kooperation mit der internen Administration auf einem eigenen Git-Repository vom Kunden konzipiert wurde, bekämpft diese Probleme durch eine klare Entwicklungslinie, die die Integration der Entwicklung anderer vor einem endgültigen Deployment vorsieht. Seit Einführung des Prozesses funktionieren die Entwicklungsbemühung mit wesentlich weniger Problemen im Nachgang.

Der Kunde betreibt ein Webportal, über welches die Einwilligung zum Versenden von Marketing-Kommunikation eingeholt wird. Da diese Information von sehr vielen Systemen gleichermaßen benötigt wird, soll nun eine Cloud-Lösung die Daten speichern. Der Kunde hat sich für die Lightning Plattform und das mitgelieferte Datenmodell entschieden. Ich führte in der Rolle als Architekt ihr die Konzeption von Automatisierungen, Datenmodell-Anpassungen und Schnittstellenkommunikation mit Apache Kafka und anderen Tools, welche direkt auf die Plattform zugreifen. Darüber hinaus führte ich einen automatisiserten Release-Prozess ein, welcher von der Entwicklung eines Features bis zur Produktion jeden Schritt auf Knopfdruck durchläuft.

Der Kunde benutzt wiederverwendbare Textbausteine in Kombination mit Platzhaltern und Unterteilung in mehrere kleinere Untersektionen zur Erstellung von Produktspezifikationen mit Versionierung und PDF-Druck. Die Herausforderungen in diesem Projekt kamen vor allem durch die Multinationalität der Platzhalter auf, weswegen wir mit unter anderem slawischen Sonderzeichen zu kämpfen hatten. Dies konnten wir durch die korrekte Schriftart zum richtigen Zeitpunkt jedoch lösen. Nach der Realisierung eines Proof of Concept wurde die Implementierung im vollen angegangen. In meiner Rolle als Solution Architect im Projekt gab ich Input für die Spezfikation der Arbeitspakete und verantwortete Release Management und Qualitätssicherung. In manchen Fällen griff ich auch operativ ein und vervollständigte Funktionen von höherer Komplexität. Um den Entwicklern eine Orientierung zu geben, entwarf ich darüber hinaus Diagramme für die Release-Prozesse und die zugrunde liegende technische Lösung des Projektes.

Die Herausforderung des Kunden bestand darin, sowohl bei Änderungen von Kontaktdaten, als auch bei Ansammlungen von mehreren Kontakten, mit einem separaten System für den Emailversand zu sprechen, welches Daten in einem völlig anderen Schema erwartet. Die erforderlichen Daten verändern sich mit jeder neuen Email, weswegen es hier darum ging, die Anwendung konfigurierbar zu gestalten. Die Lösung funktioniert nun über in den Einstellungen erstellbare Daten-Mappings, welche bei Änderung oder auf Abruf die erforderlichen Daten sammeln und als Datensatz ablegen. Der Proof of Concept wurde allgemein für ausreichend für den weiteren Gebrauch befunden und wurde mit Dokumentation und Anwendungshinweisen übergeben.

Das System des Kunden ging von einem anfänglich simplen Prozess aus und hat über mehrere Jahre hinweg ein monolithisches Opportunity-Managementsystem mit einer riesigen Trigger-Klasse entwickelt. Diese war durch sehr teilweise sehr unterschiedliche Prozesse pro Record Type nicht mehr wartbar. In diesem Projekt griffen wir deswegen den Status Quo an und haben Refactoring betrieben: Die monolithische Trigger-Klasse wurde durch das von mir mitentwickelte Framework SFDX Trigger Factory (https://github.com/dschibster/sfdx-trigger-factory) ersetzt. In diesem legten wir Wert darauf, dass jede Funktionalität separat wartbar wird und auch die Prozesse der unterschiedlichen Record Types voneinander abgetrennt behandelt werden können. Die Herausforderungen in diesem Projekt waren vor allem die Bündlung von logischen Einheiten im alten Code, sowie die Reduzierung von Altlasten und unnötigen SOQL Queries. Es erforderte intensives Testing um letzten Endes den Projekterfolg zu gewährleisten. Meine Rolle war die eines Architekten und Lead Developer: Anfangs konzipierte ich die generelle Vorgehensweise und das Zielbild für die neue Trigger-Landschaft. Am Ende leitete ich ebenfalls Entwickler in der Umsetzung dieser Zielvorstellung mit klaren Anweisungen, wie die Klassen aufzubauen sind und was beachtet werden muss. Ich unterstützte ebenfalls bei Testing und GoLive. Das ganze fand mithilfe von Schulungen, Anleitungen und Diagrammen statt.

Der Kunde führt Salesforce neu ein und plant einen gestaffelten Rollout über mehrere Landesgesellschaften. Hierfür soll ein standardisierter Vertriebsprozess in Salesforce geschaffen werden, der harmonisiert zwischen SAP und Salesforce agiert. Da dieses Vorhaben sehr viel Individualentwicklung, Customizing und Integration zwischen Systemen voraussetzt, nahm sich der Kunde zunächst in Form einer Konsolidierungsphase die Zeit, um Richtlinien und Anforderungen mit allen Abteilungen in Einklang zu bringen. Ich und ein weiterer Kollege agierten in diesem Projekt als Architekten, die mit den zugehörigen Ansprechpartnern Anforderungen an die jeweils gegenüberliegenden Systeme diskutierten, Konzepte ausformulierten und Zielskizzen anfertigten. Ebenfalls sprachen wir Handlungsempfehlungen für Datenmanagement an den Stellen aus, wo es noch keine globale Entscheidung gab. Unter anderem wurden von uns Migrationskonzepte, Schnittstellenkonzepte und Ziel-Architekturen anhand von Visualisierung über Strukturdiagramme, Prozessdiagramme und Architekturdiagramme entworfen und diskutiert. Am Ende kann der Kunde nun mit einem guten Gefühl in die nächste Projektphase und in die Implementierung einsteigen, da die notwendigen anfänglichen Absprachen mit allen Stakeholdern besprochen worden sind.

Wir starteten die Entwicklungen auf einer Instanz, dessen Entwicklungsprozess Arbeiten an unterschiedlichen Themen sowie das Einarbeiten von Testfeedback nicht ermöglichte und die Produktivität des Teams beeinträchtigte. Das Ziel war es in diesem Projekt, die bestehenden Entwicklungen der Instanz in ein paketbasiertes Entwicklungsmodell zu migrieren und Deployments über das framework flxbl.io durchzuführen. Ich war hier in der Rolle des Architekten und strukturierte die Metadaten der Instanz leitend, führte Tests durch und schulte die anderen Teammitglieder über die spätere Verwendung des Systems.

Der Kunde migriert von einer auf SAP basierenden Lösung auf Salesforce. Für den Geschäftskundenvertrieb werden unterschiedliche Produkte eingesetzt, die verschieden bepreist werden. Im aktuellen MVP entwickeln wir für eines dieser Produkte (ein Festpreisprodukt) einen End-to-End-Prozess bis zur Vertragserstellung. Herausforderung hierbei ist das Zusammenspiel aller beteiligten Systeme: Salesforce, Kisters BelVis+, SAP und ein MuleSoft-System, welches die Kommunikation zwischen den Systemen übernimmt. Darüber hinaus ist die Einhaltung von Regularien und die Abdeckung von relevanten Randfällen wichtig. In meiner Rolle als Architekt und Lead Developer bearbeite ich selbst Prozessschritte auf technsicher Ebene, führe aber ebenfalls Code Reviews, diene als technischer Ansprechpartner für das System und als Sparringspartner für die anderen Entwickler im Team. Darúber hinaus entwerfe ich Diagramme zur Veranschaulichung von Problemstellungen und Prozessen