Digitaler Akt
Branche: Finanzdienstleister
Interne Prozesse wie Registrierung neuer Vertriebsmitarbeiter, Stukturwechsel und Beförderungen werden durch komplexe Formulare im Bestandssystem gestartet. Die daraus generierten Formulare, Verträge und Anlagen werden vom Sachbearbeiter gebündelt in das System eingespeist.
Das System führt eine Dokumententrennung und -kategorisierung durch, entfernt Leerseiten und erkennt anhand der auf den Dokumenten gedruckten QR-Codes welcher spezifische Antrag vorliegt. Die Verarbeitung erfolgt unter Zuhilfenahme von Open Source Software wie Ghostscript und ImageMagick und wird von einer Jobqueue abgearbeitet.
Vorgänge werden - verknüpft mit den hinterlegten Eingaben - in ihrer Gesamtheit dargestellt. Dh. es ist immer ersichtlich, welche Unterlagen in welcher Version und mit welchen Anforderungen vorliegen müssen. Jede Unterlage muss vom Sachbearbeiter gesichtet und freigegeben werden.
Wenn bei Vorgängen eine Bonitätsprüfung oder eine bestimmte Gewerbeberechtigung notwendig ist, wird sie automatisch durchgeführt bzw. abgefragt und die resultierenden Dokumente dem Vorgang hinzugefügt. Die Abfragen werden durch eine Jobqueue asynchron im Hintergrund abgearbeitet, die entsprechenden Anbindungen (Bonitätsprüfung, GISA Abfrage) sind mittels Webscrapern realisiert.
Nach vollständiger Prüfung wird der Vorgang intern durchgeführt und archiviert. Die Archivierung findet allerdings erst statt, wenn das Hostsystem des Kunden die Änderung auch technisch abgebildet hat.
Die archivierten Vorgänge sind im digitalen Akt des Mitarbeiters einsehbar, die Dokumente werden in der Azure Cloud revisionssicher abgelegt. Zugriff auf den Akt ist nur mit entsprechenden Rechten im System möglich, alle Zugriffe werden geloggt. Gesetzliche Löschfristen werden automatisch berücksichtigt.
Zyklische Überprüfungen der aufrechten Gewerbeberechtigungen unterstützen in weiterer Folge den Innendienst bei der Einhaltung der internen und gesetzlichen Vorgaben.
Elektronischer Einreichprozess von Verträgen
Branche: Versicherungsdienstleister
Der Einreich- und Freigabeprozess von Lebens- und Sachversicherungen des Kunden wurde digitalisiert. Vertriebsmitarbeiter berechnen nach dem Beratungsgespräch auf die Bedürfnisse der Kunden zugeschnittene Vorschläge, die mittels SOAP Schnittstelle in ein Vertriebsfrontend übermittelt werden.
Über dieses Frontend kann der elektronische Unterschriftsprozess gestartet werden. Nach Abschluss können die Anträge eingereicht werden, wodurch sie den Sachbearbeitern des Innendienstes vorgelegt werden. In diesem Schritt werden automatisch unterschiedliche Kriterien erkannt, entsprechende Markierungen und Warnungen gesetzt, die verschiedene Geschäftsprozesse anstossen.
Abschließend werden die Anträge durch den Innendienst freigegeben oder abgewiesen. Nach der Freigabe wird der Antrag polizziert und taucht letztendlich im Bestandssystem als Vertrag auf.
Seit Einführung des Systems im Jahr 2017 werden mittlerweile über 95% der Anträge elektronisch eingereicht.
Wesentliche Details des Projekts sind - neben der Integration von unterschiedlichen Systemen der Produktpartner - die Echtzeitnotifizierung von geleisteten Unterschriften und Statusänderungen via Websockets, als Messagebus dient PostgreSQL. Die Vertriebs- und Bestandssysteme sind mittels Single Sign-On (SSO) integriert.
Webscraping, Datenaufbereitung und Auslieferung in bestimmten Formaten
Branche: Medienhaus, Jobportal
Unser Kunde bietet über mehrere Jobbörsen/Karriereportale Stellenausschreibungen für Unternehmen an. Die Ausschreibungen werden über unterschiedlichste Wege geschaltet (Print, online, einzelne Dateien, Bilder). Ein Großteil dieser Unternehmen bietet zudem ihrerseits Webseiten an, auf denen sie ihre Stellen direkt ausschreiben, oder sie verwenden diverse Standardlösungen.
Wir ziehen die Ausschreibungen über unterschiedliche Schnittstellen wie XML Feeds, SOAP- und REST API, aber auch mittels individuellem Webscraping ab und führen diese in einer Datenbank zusammen.
Die Ausschreibungen werden gefiltert, aufbereitet, bereinigt, getaggt und den jeweiligen Jobportalen zugewiesen. In Folge werden sie nach Freigabe durch den Kunden bzw. auch automatisch, unter Berücksichtigung von Buchungskontingenten, ausgeliefert.
Die Aufbereitung ist ein umfangreicher Prozess und behandelt unter anderem Themen wie Encodings, invalides HTML/CSS, Entfernung von Zählpixeln und sich laufend ändernden technischen Hinweisen, Vereinfachung der Web-Ansicht, sowie Erweiterungen um weitere Ansichten (mobile). Oftmals werden abgeholte Daten in eigens geschriebene HTML-Templates gegossen. Sämtliche Änderungen an Stellenausschreibungen und deren Assets werden erkannt, historisch ausgewiesen und als Aktualisierung, Neubuchung oder Löschung klassifiziert.
Zudem wurde im Laufe des Projekts ein Kundenportal entwickelt, das die Verwaltung der Kunden an sich, ihrer Stellenausschreibungen, sowie der Möglichkeit der Freigabe von Buchungen und der Überlagerung diverser Daten, Eigenschaften und Taggings einzelner Stellenausschreibungen durch den Kunden selbst, bietet.
Zero Downtime Datenbankmigration
Branche: Suchmaschine
Daten der Suchmaschine unseres Kunden waren je nach Größe der gTLD auf mehrere - von uns betreute - physische Datenbankserver verteilt (Sharding).
Aufgabe war es, nahtlos eine der Shards (PostgreSQL 8.2) unter Produktionslast auf ein zu diesem Zeitpunkt neues Major Release (PostgreSQL 9.0) zu bringen.
Da Logical Replication damals noch kein Ansatz war und von Lösungen wie Slony abgesehen wurde, wählten wir einen individuellen, auf das Projekt zugeschnittenen Ansatz.
Auf dem neuen System wurde das letzte logische Backup eingespielt und dann ein Prozess gestartet, der die geänderten Suchprofile zyklisch synchronisiert hat. Um maximalen Durchsatz zu erreichen, wurde die Abfrage am alten System mittels PostgreSQL Features wie Cursor und asynchroner Queries durchgeführt. Dadurch konnte am Zielsystem laufend geschrieben werden, während das Produktivsystem das nächste Set an Daten auslesen konnte.
Nach ausreichendem Aufsynchronisieren der Datenbanken wurden die Frontendsysteme schrittweise auf die neue Datenbank umgestellt.
Das resultierende Script wurde in Folge auch bei anderen Shards zum Upgrade verwendet.