Details zu einen komplexen Projekt

Details zu einem komplexen Projekt

Vorwort:

Das nachstehende System ist leider nicht mehr im Einsatz, da es aufgrund eines strategischen Konzern-Entscheids durch eine Konzernlösung (welche auch für andere Mandate eingesetzt wird) ersetzt werden musste.

Die einzelnen Module und das Gesamtkonzept lassen sich aber gut auf ähnliche Aufgabenstellungen anpassen.

Wenn Sie also ähnliche Anforderungen zu einem Projekt haben, kommen Sie unverbindlich auf uns zu!

Wir wurden von einem grossen Facility Management (FM) Dienstleister angefragt, ob wir zu einem Kundensystem (Schweizer Grossbank) eine Lösung für seinen Innen- und Aussendienst zur optimalen Abwicklung des Mandats (Wartungs- und Support-Dienstleistungen zu ca. 70 Kunden-Gebäuden in der Schweiz, nachstehend Tasks genannt) entwickeln könnten.

Ausgangslage:

Als erstes wurde ein Projektteam mit den key players des FM Dienstleisters (Leiter Innen- und Aussendienst, Innen- und Aussendienstmitarbeiter) gebildet und gemeinsam im Team ein Pflichtenheft erstellt.
Die Mitarbeiter des FM Dienstleister beschrieben, welche Funktionen sie benötigen und wie diese in der Praxis optimalerweise zu bedienen sein sollten. MATRIX hat daraus dann eine "IT-gerechte" Beschreibung im Pflichtenheft erstellt.
Die gemeinsame Erstellung eines Pflichtenhefts hat den (grossen) Vorteil, dass die beschrieben Funktionen bereits bei der Erstellung durch die IT "vor validiert" werden und dann auch wirklich - wie beschrieben - in der Praxis umsetzbar sind.

Das fertige Pflichtenheft wurde dann an einem externen Workshop des FM Dienstleisters (Teilnehmer aus dem Team und Management ohne MATRIX) abschliessend besprochen, verabschiedet und dann MATRIX in Auftrag gegeben.

Dann wurden die Funktionen im Team priorisiert (wichtigste Funktionen = Prio1) und die Software entsprechend den Prioritäten umgesetzt.

Während der Umsetzung fanden bei MATRIX laufend Projektsitzungen statt, an welchen MATRIX aktuelle Zwischenversionen der Software live gezeigt hat und bereits erste Anpassungs-/Erweiterungswünsche aufgenommen wurden.

Projektablauf:

Der Kunde des FM Dienstleisters (Schweizer Grossbank) setzte intern bereits eine FM Software (Maximo) ein, welche über xml-Schnittstellen für den Datenaustausch verfügte. Die neu zu erstellende Software musste für den Datenaustausch zwingend genau auf dieser (xml-) Schnittstelle aufsetzen. Vom Kunden wurden also Daten in .xml-Dateien (neue Supportanfragen, Wartungen, nachstehend Tasks genannt) gesandt. Diese mussten in eine Datenbank geladen werden und dann gemäss klaren Regeln und Zeitvorgaben korrekt bearbeitet werden. Der Status zu den einzelnen Arbeiten musste - ebenfalls gemäss klaren Vorgaben des Kunden - in Form von xml-Dateien an das System des Kunden (Maximo) zurückgesandt werden. Wie genau die Daten "dazwischen" bearbeiten werden, wurde dem FM Dienstleister überlassen.

Rahmenbedingungen:

Daraus ist dann folgendes, technisch sehr komplexe System entstanden (Darstellung stark vereinfacht):

Siemens-Projekte

Kurzbeschreibung zur Grafik:

Ein Teil der IT des Kunden des FM Dienstleisters (Schweizer Grossbank) wird von einem externen IT-Diensteister betrieben. Wie bereits erwähnt, setzt der Kunde Maximo ( 1 ) als internes FM-System ein.

Maximo verfügt über Import und Export-Schnittstellen (xml-Dateien). Ein Prozess ( 2 ) beim IT-Provider kopiert Daten zwischen Maximo und einem sFTP-Server ( 3 ) hin und her.

Die ganze von MATRIX erstellte Lösung wird bei einem Cloud Provider ( 4 ) betrieben:

Zentraler Dreh- und Angelpunkt ist ein MS SQL-Server ( 5 )

Alle Dienstprogramme sind auf einem "Robo-Server" ( 6 ) installiert:

Ein (selbst erstellter) sFTP-Client ( 7 ) übernimmt die Kommunikation mit dem sFTP-Server ( 3 ) des
IT-Providers des Kunden
Ein Import-/Export-Client ( 9 ) bildet die Schnittstelle zwischen dem SQL-Server ( 5 ) und
dem sFTP-Client ( 7 ). Sobald z. Bsp. neue Tasks angefordert werden, werden die Daten dazu automatisch vom Import-/Export Client in die Datenbank geladen. Sobald sich der Status zu einem Task ändert, exportiert der Import-/Export-Client eine xml-Datei, welche dann vom sFTP-Client auf den sFTP-Server übertragen wird.
Ein Alarm-Client ( 10 ) überwacht die technische Umgebung (laufen alle Dienstprogramme?), sowie Tasks, welche kurz vor Ablauf des Zieltermins stehen und versendet Alarme per Email und/oder per SMS

Der Innendienst des FM-Dienstleisters arbeitet mit einem sehr komfortablen Windows-Client ( 11 ), welcher von einem RDS-Server ( 11 ) bezogen wird, welcher ebenfalls beim Cloud-Provider ( 4 ) betrieben wird.

Der Windows-Client ( 12 ) wird dann von den Innendienst-Mitarbeitern des FM-Dienstleister an einem beliebigen Ort aufgerufen und verhält sich wie andere Windows-Programme - nur dass er über rdp gestartet wird und nicht auf dem Gerät des Benutzers (PC / Notebook) läuft, sondern auf dem RDS-Server ( 10 ) beim Cloud Provider (4 )

Diese (Terminalserver-)Architektur hat viele Vorteile:

Der Aussendienst-Mitarbeiter kann den Client grundsätzlich von einem beliebigen Ort "der Erde" aufrufen (also in einer beliebigen Filiale, im Homeoffice, aber auch im Ausland - z. Bsp. in einem Hotel)
Der Client ist sehr schnell (oft schneller als, wenn die ganze Lösung lokal im LAN installiert wäre):
- Da der Client direkt beim Cloud Provider läuft und der SQL-Server im gleichen (hochperformanten) Netz werk betrieben wird, ist der Zugriff auf den SQL-Server sehr schnell
- Da nur die Bildschirmänderungen über das Internet übertragen werden, läuft der Client auch auf älterer Hardware und bei "dünner" Internetverbindung immer noch schnell
Updates können zentral auf dem RDS-Server installiert werden
Da der Client auf dem zentralen RDS-Server läuft, ist eine Virenbefall aus dem lokalen Netz ausgeschlossen
etc.

Es arbeiten ca. 65 Innendienst-Mitarbeiter ( 13 ) mit dem Windows-Client.

Der Windows-Client ( 11 ), ( 12 ) stellt das Highlight der Lösung dar, da er optimal auf die Bedürfnisse der Benutzer und auf die (von der Bank) vorgegebenen Prozesse "zugeschnitten" wurde (nur ein paar Beispiele):

Im Client können Teams von Aussendienst-Mitarbeitern gebildet werden. Wird ein neuer Task auf ein Team zugewiesen, erhalten alle Mitarbeiter im Team den neuen Task gleichzeitig. Sobald ein Teammitglied der Task übernimmt wird er für alle anderen Teammitglieder "unsichtbar"
Alle Wartungs-und Supportanfragen können sehr komfortabel mit Drag&Drop auf die Mitarbeiter / Teams zugewiesen werden und auch Statuswechsel können mit Drag/Drop erledigt werden
Über einen Schnittstelle zur Zeiterfassung des FM-Dienstleisters ist ersichtlich, welche Mitarbeiter aktuell arbeiten und welche nicht (Bsp. Mittagspause) und welche Mitarbeiter von wann bis wann geplant abwesend sind (Ferien, Militär, etc.)
Die aktuell offenen Tasks werden nach Ablauf-Zeit sortiert und "eingefärbt" angezeigt (Bsp. Rot für Tasks, welche demnächst ablaufen)
Bei kurzfristigem Ausfall eines Aussendienstmitarbeiter oder bei geplanten Abwesenheiten, können alle Tasks zu diesem Aussendienstmitarbeiter komfortabel und einfach auf andere Aussendienstmitarbeiter übertragen werden
Im Windows-Client ist ersichtlich, welche der Aussendienstmitarbeiter die App aktuell geladen haben und wie viele Tasks sie bereits zugewiesen haben
Es wurden sehr viele Plausibilitätsprüfungen implementiert (wesentlich mehr als im "Originalsystem" (Maximo)), so dass die (umfangreichen) vorgegebenen Regeln zum Prozess problemlos eingehalten werden
Es sind sehr mächtige und einfach zu bedienende Auswertungsmöglichkeiten implementiert. Natürlich sind auch KPI-Auswertungen (gemäss Vorgaben Kunde) integriert
Der Windows-Client und die Android-App sind mehrsprachig (Deutsch, Französisch, Italienisch und Englisch). Alle Texte werden in allen Sprachen auf dem SQL-Server gespeichert und können sehr komfortabel direkt im Windows-Client übersetzt / angepasst werden
Es ist ein sehr detailliertes Berechtigungskonzept implementiert, mit welchem die Benutzer (durch definierte Supervisoren) auf die enthaltenen Funktionen berechtigt werden können
Natürlich ist auch eine vollständige Test-Umgebung (alle Systeme) integriert (diese wurde aber auf der Grafik bewusst weggelassen;-)
etc. etc.

Eine vollständige Beschreibung ist hier nicht möglich (würde den Rahmen sprengen und Screenshots können aus Vertraulichkeitsgründen nicht ergänzt werden).

Der Aussendienst des FM-Dienstleisters arbeitet mit einer Android-App ( 15 ), welche über
einen Web Service ( 14 ) (welcher auf einem Webserver in der DMZ läuft) auf den zentralen SQL-Server ( 5 ) zugreift.

Alle ca. 60 Aussendienst-Mtarbeiter verfügen also über eine Android Mobile.

Bei neuen Supportfällen oder Wartungen, welche im Windows-Client einem Aussendienst-Mitarbeiter zugewiesen werden, wird automatisch ein "Vibra-Alarm" auf dem Gerät erzeugt. Sobald ein Aussendienst-Mitarbeiter den Status anpasst, wird der neue Status ein paar Sekunden später im Windows-Client angezeigt.

Die App "pollt" periodisch so dass im Windows-Client ersichtlich ist, welche Mitarbeiter die App aktuell geladen haben und welche nicht