Die ewige Frage, ob man seine Software kauft oder baut (James Monaghan)

Glückwunsch. Sie haben ein Problem, ein Projekt, ein Budget und eine Frist. Anstatt Leute darauf zu werfen, ist Software die Lösung, aber jetzt müssen Sie sich entscheiden, ob Sie bauen oder kaufen, das ist die Frage. Oder ist es? Ich bin mir nicht mehr so ​​sicher, ob es eine eindeutige Entscheidung ist.
Der Begriff „Build“ bezieht sich auf die Einstellung interner Programmierer, die das erforderliche System programmieren und kaufen, und bezieht sich auf handelsübliche Produkte, die gekauft und ausgeführt werden können. Das machte Sinn, als wir über Buchhaltungssysteme, Handelssysteme, CRM, Reporting usw. sprachen.
Ausleihe, Sammlungen, CLM usw. Wir leben jetzt in der Low-Code-Umgebung, in der für die Erstellung von etwas keine Programmiererfahrung erforderlich ist. Es kann per Drag & Drop erfolgen. Kombinieren Sie das mit dem Kauf von Standardlösungen, die am Ende so individuell sind, dass Sie es sich wünschen
Nun, ich habe es gebaut. Wo bleibt uns also die Entscheidung, ob wir bauen oder kaufen? Schauen wir uns an, was wir tatsächlich brauchen.

Kein modernes System kann sich mehr auf einen einzigen Einstiegspunkt verlassen. Die Kundenerwartungen erfordern die Notwendigkeit verschiedener Kanäle. Persönlich, direkt per Telefon oder Callcenter, E-Mail, soziale Medien, SMS, Web, Mobilgerät, Tablet – sowohl mobil als auch nativ
Apps, die alle austauschbar sein müssen, ohne dass Inhalt oder Kontext verloren gehen. Ein Kunde, der in der Filiale/im Geschäft oder persönlich anfängt, aber zu einem Termin gehen muss, möchte dort weitermachen können, wo er aufgehört hat, wenn er sich später am Tag online anmeldet. Oder
Wenn sie online anfangen, aber frustriert sind und um Hilfe bitten, möchten sie den Prozess nicht von vorne beginnen müssen. Dies gilt auch für interne Stakeholder. Die Informationskette innerhalb einer Organisation muss genauso flexibel sein wie der Kunde
Optionen. 

Was kommt also als nächstes für unsere Start-Irgendwo-Dateneingaben? Nun, es gibt einen Grund, warum wir diese Daten überhaupt brauchen. Ganz gleich, ob ein neuer Kunde mit der Organisation zusammenarbeiten möchte, ein bestehender Kunde ein neues Produkt oder eine neue Dienstleistung möchte oder einfach nur alltägliche Fragen oder Beschwerden hat
oder Informationsanfragen. All dies sollte mit definierten, aber flexiblen Prozessen beginnen, um die Anfrage so effizient und einfach wie möglich zu bearbeiten. Der Prozess ist allgemein definiert und in der Regel werden die Mitarbeiter darin geschult, eine Abfolge von Aufgaben zu befolgen, um den Prozess mit vorgegebenen Vorgaben abzuschließen
Aktionen basierend auf bestimmten Dateneingaben. 

Weder Endkunden noch Systembenutzer sollten Informationen irgendwo erneut eingeben müssen, wenn sie bereits irgendwo erfasst wurden. Wenn Informationen tatsächlich irgendwo innerhalb der Organisation oder aus Drittquellen wie Datenanbietern, Kreditauskunfteien usw. verfügbar sind,
Screening-Anbieter usw. Es sollte während des gesamten Prozesses für alle Benutzer zugänglich sein, die es benötigen. Der Prozess ist definiert, aber die Berührungspunkte sollten durchgehend austauschbar sein und die gesammelten Daten sollten nach Möglichkeit integriert und nach Möglichkeit strukturiert werden.
Dropdown-Menüs, Suchwerte, Datumsfelder und kontrollierte Freitextwerte sorgen dafür, dass möglichst viel Datenqualität im Vorfeld erfasst wird. Dies ermöglicht eine wesentlich stärkere Automatisierung des gesamten Prozesses und eine geringere Ausnahmebehandlung.

Da die Daten nun aktiv erfasst oder aktualisiert werden, kann die künstliche Intelligenz eingesetzt werden. Die Mitarbeiter müssen nicht alle Details kennen und selbst neue Mitglieder können an komplexeren Fällen arbeiten, da das System richtliniencodierte Regeln verwendet
Logik, um automatisch Entscheidungen zu treffen, für deren Handhabung das Personal zuvor umfangreiche Schulung und Erfahrung benötigte. Keine Fehler mehr und ermöglicht gleichzeitig die Überwachung und sogar Qualitätskontrollprüfungen oder regelrechte Ausnahmewarteschlangen für manuelle Eingriffe, wenn nötig.

Dies alles erfordert einen systematischen Ansatz. Die alte Idee eines Manila-Ordners, der in der Schublade eines Mitarbeiters für sein Kundenportfolio liegt, ist veraltet und stellt ein unnötiges Risiko dar. Isoliert verarbeitete Clients können sowohl einschränkend als auch überflüssig sein
gleichzeitig. Wenn ein Firmenkunde Direktoren hat, die mehreren anderen Kunden gegenüberstehen, warum sollte dann jede einzelne Bewertung das Gesamtbild außer Acht lassen? Werden Sie denselben Regisseur in jeder Beziehung mehrmals überprüfen, oder könnten Sie das?
Machen Sie es einmal und verwenden Sie diese Informationen im gesamten Unternehmen wieder?

Sie müssen nicht einmal gemeinsame nahestehende Parteien haben, damit der Nutzen offensichtlich ist. Ähnliche Branchen, ähnliche Kunden – was wäre, wenn Ihre Kunden, Lieferanten/Lieferanten auch selbst Kunden wären? Dies bringt uns dazu, wie Sie die Informationen verarbeiten müssen
und warum Unternehmen heutzutage das gesamte Unternehmen im Blick haben müssen, wenn sie über Software nachdenken. Wenn Sie ein Problem isoliert betrachten und es als solches behandeln, Budgets festlegen und RFPs für jede CRM-, Fincrime- und Client Outreach-Komponente ausstellen, werden Sie am Ende am Ende davonkommen
Es wurden mehr Ressourcen aufgewendet, um alles zu integrieren, als ursprünglich erhofft wurde. Wenden Sie dies nun auf jede Region oder jeden Geschäftsbereich an, der möglicherweise separate Budgets und Aufsicht erhält, und am Ende erhalten Sie 8 Versionen
derselben Software, die aufgrund der starken Anpassung pro Bereich in sich selbst integriert werden muss, wodurch jegliche Skaleneffekte vermieden werden, die sie erzielen könnten.

Ein Ordner in einer Schublade, der jährlich oder anderweitig überprüft werden muss, wobei das Personal geschult werden muss, was zu tun ist und wann es zu tun ist. Die gesamte Bewertung (oder das neue Onboarding/zusätzliche Produkt/Dienstleistung usw.) kann in zusammengesetzte Teile unterteilt werden, die ggf
dürfen nicht von anderen Personen/Teams bearbeitet werden. Das System kann dann feststellen, wann eine Aufgabe abgeschlossen ist oder wann genügend Daten erfasst wurden, um sie zur Eingabe an die nächste Person zu senden. All dies ist als Fälle und Unterfälle strukturiert. Auf diese Weise jedes Element von
Der Fall kann eine eigene Frist, einen eigenen Eskalationspfad, einen eigenen Beauftragten und eigene Genehmiger haben. Anstelle einer großen Aufgabe, bei der ein Mitarbeiter ausreichend Erfahrung haben muss, um zu wissen, wie er sie erledigt und an wen er sich für verschiedene Elemente wenden muss, weist das System die Arbeit nun zu
und stellt die termingerechte Erledigung unternehmensweit sicher, indem möglichst viele Aufgaben automatisiert werden, damit sich die Entscheidungsträger auf das Wesentliche konzentrieren können.

Aus geschäftlicher Sicht ist das alles schön und gut. Die Arbeit ist bekannt und was getan werden muss. Aber welchen Einfluss hat das auf die Entscheidung, ob wir die Software kaufen oder selbst entwickeln sollen? Nehmen wir an, es gibt mehrere Quellen
von Daten über mehrere Systeme hinweg. Von jedem modernen System wird erwartet, dass es API-gesteuert ist und über Low-Code-/No-Code-Funktionen verfügt. Eine vernünftige Annahme für schnellere und flexiblere Software. Heutzutage muss alles als eine Art Mikrodienst behandelt werden, den es zu vermeiden gilt
die Software-Monolithen im alten Stil. Software sollte installiert und verwendet werden, da sie die beste verfügbare und zukunftssichere Software ist, die sich bei Bedarf an Veränderungen anpassen kann. Zu viele Angebote sind fest verankert und werden nur aufrechterhalten, weil sie zu schwierig und zeitaufwändig sind
ersetzen. Der größte Teil davon ist darauf zurückzuführen, dass Regeln fest codiert sind und wahrscheinlich mit den Daten selbst verknüpft sind. Daten werden nicht nur integriert, sondern für jedes einzelne Softwareteil in der Informationskette mehrfach repliziert
Das gesamte System könnte kaputt gehen. Zu viel vom alten Denkprozess. Wenn er nicht kaputt ist, reparieren Sie ihn nicht. Was wirklich benötigt wird, ist, dass alle diese Komponenten Microservices sind, die benötigten Daten erfassen, automatisierte Regeln oder Benutzereingaben/-überprüfungen anwenden und
Weitergabe an den nächsten Microservice. Daten sollten nicht an mehr als einem Ort gespeichert werden. Es kann föderiert, aber nicht außerhalb von Backups repliziert werden. Ihre CRM-, Onboarding-, KYC-, Client Outreach-Systeme usw. sollten nur auf die Daten zugreifen, die sie benötigen, und nicht
selbst Datenrepositorys sein, es sei denn, Sie haben eines ausgewählt. Die Replikation derselben Daten über mehrere Standorte hinweg und die Regeln, die sie regeln, ist eine sinnlose Übung, da jedes zusätzliche System, das hinzugefügt wird, die damit verbundene Komplexität vervielfacht.

Dies bringt uns zur letzten Überlegung. Ganz gleich, ob Sie über eine einzige Quelle der Wahrheit/Golden Copy oder über mehrere redundante und konkurrierende Datensätze und Systeme verfügen, die diese aktualisieren können, Sie werden sich immer noch in einer anderen Anforderungsebene wiederfinden, die auf der jeweiligen Linie basiert
Geschäft, Gerichtsbarkeit, Kundentypen und Produkte/Dienstleistungen. Eine Einzelperson wird anders behandelt als ein Unternehmen oder eine Stiftung und unterscheidet sich je nach Verbraucher-/Einzelhandels-, Handels- oder Firmengeschäftsbereich hinsichtlich Anforderungen und Eignung. Im einfachsten Fall, wenn
Wir haben 10 Arten von Kunden (Einzelpersonen – Singles, Verheiratete usw., Privatunternehmen, öffentliche Unternehmen, Trusts, Wohltätigkeitsorganisationen usw.) und Sie können in 10 Regionen tätig sein und möglicherweise 10 Arten von Produkten/Dienstleistungen anbieten, bei denen wir bereits vertreten sind potenziell mehr als 1000 Regeln, die das könnten
angewendet werden. Wäre es nicht viel einfacher, Regeln für eine Region, einen Geschäftsbereich, einen Kundentyp und Produkte oder Dienstleistungen zu definieren und stattdessen das System die Anforderungen lösen zu lassen? Entfernen von Duplikaten und Wiederverwenden zuvor vorhandener Datenpunkte
bereitgestellt. Dies ist der Vorteil der Abstraktion Ihrer Prozesse und Regeln von Ihrer Datenschicht. 

Wenn wir uns nun mit der alten Frage des Kaufs oder Erstellens von Software befassen, wissen wir, dass wir Omni-Channel-Orchestrierung, Prozessautomatisierung, wo möglich, flexible Regellogik, Fallmanagement zur Überwachung und Überprüfbarkeit, Low-Code und API-gesteuert benötigen – eine Zusammenfassung
Datenschicht und eine intelligente Regel-Engine, die von verschiedenen Logikschichten erben kann. Der Technologiemarkt ist voll von Innovatoren, die gerne jedes erdenkliche Nischenproblem lösen, aber ab wann macht es keinen Sinn mehr, „von der Stange“ zu haben?
Produkte, die alle individuell angepasst und miteinander integriert werden müssen, anstatt sie selbst zu erstellen. Mit Low-Code-Plattformen stehen Ihnen 80 % Ihrer Anforderungen zur Verfügung und Sie müssen nur dieses Delta von 20 % konfigurieren. Das Beste aus beiden Welten ist ein Tief
Code-Plattform, für die auch andere wiederverwendbare Komponenten entwickelt haben, sodass Sie die Produkte „von der Stange“ als Beschleuniger für Ihr Unternehmen erhalten können und gleichzeitig Ihren Mitarbeitern oder zertifizierten Dritten die Möglichkeit geben, den Rest der Anforderungen spezifisch zu erstellen
an Ihre Organisation. Kaufen oder bauen? Eigentlich sollte es beides sein.