Telephony Management
Spezifikation und Umsetzung mit der «Codeless Business Application Technology (CBAT)»
Mit der «Codeless Business Application Technology (CBAT)» lassen sich Business- Applikationen schnell und flexibel umsetzen. Die leistungsfähige Technologie allein verspricht jedoch noch keine Erfolgsgarantie. Erst die Kombination mit einer professionellen Vorgehensweise führt zum gewünschten Ziel. Am Beispiel der Business-Applikation «Telephony Management» zeigen wir die notwendigen Schritte auf.
Welche Firma kennt die folgende Situation nicht? «Ein Mitarbeiter ist unterwegs auf Kundenbesuch und sollte dringend über eine Aktualisierung der Preisliste informiert werden. Doch im Firmentelefonbuch ist nur seine interne Nummer vermerkt. Ein Hinweis auf die Handynummer ist nirgends auffindbar.» Das Management von Kontaktinformationen – speziell von Telefonnummern – ist in der Praxis oft ein leidiges Thema. Obschon in der Regel praktisch alle Mitarbeitenden auf einem Handy erreichbar wären, sind die entsprechenden Telefonnummern nicht bekannt. Dazu kommt, dass viele Mitarbeitenden – zu Recht – eine Veröffentlichung ihrer privaten Handynummern für geschäftliche Zwecke ablehnen. Im Gegensatz zu internen Telefonnummern und E-Mail- Adressen steht für Handynummern keine zentrale Infrastruktur zur Verfügung, die zur automatisierten Erstellung von Telefonbüchern verwendet werden kann. Die Daten müssen also manuell erfasst und gepflegt werden.
Die Ersterfassung privater Kontaktinformationen (inkl. Telefonnummern) erfolgt nicht selten durch die Personalabteilung. Diese werden im Lohnbuchhaltungssystem erfasst, stehen aber aus Datenschutzgründen nicht frei zur Verfügung. Als Umgehungslösung wird irgendwann durch den Lehrling der IT-Abteilung eine eigene Software für die interne Kontaktverwaltung programmiert. Spätestens beim nächsten Änderungswunsch steht dieser jedoch nicht mehr zur Verfügung – seine Ausbildung ist abgeschlossen –, und eine Dokumentation ist nirgends auffindbar. Keiner der anderen Mitarbeitenden verfügt über das nötige Know-how für die Analyse des Software-Codes und so bleibt nichts anderes übrig, als eine komplett neue Lösung zu suchen.
Das soeben beschriebene Beispiel ist sicher nicht aus der Luft gegriffen. Oft entstehen im Laufe der Zeit kleine Business-Applikationen und Datenbanken (Stichwort «Access-DB»), mit denen gezielt bestimmte Anforderungen abgedeckt werden. Eine gesamtheitliche Betrachtungsweise und die Umsetzung mit einer standardisierten Technologie finden selten statt. Prozesse und die involvierten Rollen bzw. Verantwortlichkeiten werden nicht dokumentiert. Der hohe Zeitaufwand und die daraus entstehenden Kosten innerhalb der IT Organisation stehen in keinem Verhältnis zum Nutzen, den diese Kleinstlösungen dem Unternehmen bringen.
Immer häufiger wird nach Möglichkeiten gesucht, kleine Business-Applikationen auf eine einheitliche Technologie abzubilden. Diese sollte folgende Anforderungen erfüllen:
- Einfaches Benutzer-Interface, welches den Anwender zum richtigen Zeitpunkt mit den richtigen Informationen beliefert.
- Kurze Realisierungszeiten, um neue Businessanforderungen schnell umzusetzen.
- Flexible Möglichkeiten zur Umsetzung von Workflows und zur Speicherung der benötigten Daten.
- Unkomplizierte Anbindungen von Umsystemen mit Schnittstellen zur Vermeidung redundanter Datenhaltung.
- Technische Umsetzung ohne Softwareentwicklung (Codeless).
- Betrieb auf Standard-Plattformen (Microsoft Windows) und Standard- Datenbanken (Microsoft SQL-Server).
Alle genannten Anforderungen werden mit der Lösung «Cherwell® Service Management» der Firma «Cherwell Software, LLC.» abgedeckt. Diese basiert auf der «Codeless Business Application Technology (CBAT)» und ermöglicht die Entwicklung von Business-Applikationen ohne Kenntnisse einer Programmiersprache wie Java, C# etc. Damit eignet sie sich ausgezeichnet für die Umsetzung der Business-Applikation «Telephony Management».
Der Entwicklungsprozess einer Business Application erfolgt in mehreren Schritten:
- Schritt 1: Ziele definieren
- Schritt 2: Anforderungen erfassen
- Schritt 3: Anwendungsfälle modellieren
- Schritt 4: Objektmodell definieren
- Schritt 5: Umsetzung (CBAT)
- Schritt 6: Test und Abnahme
Schritt 1: Ziele definieren
Die Zieldefinition durch den Auftraggeber ist eine wichtige Basis für alle nachfolgenden Schritte. Jede formulierte Anforderung (Schritt 2) kann später gegenüber den Zielen beurteilt, akzeptiert oder wenn nötig abgelehnt werden.
Folgende Ziele werden für die Verwaltung von Telefonnummern erreicht (Beispiele, nicht abschliessend):
- Die Verwaltung erfolgt prozessgesteuert in einem zentralen System.
- Rollen und Verantwortlichkeiten sind klar definiert.
- Alle Änderungen sind dokumentiert und nachvollziehbar.
- Die Abfrage von Telefonnummern muss jederzeit und möglichst von jedem Standort aus möglich sein.
Schritt 2: Anforderungen erfassen
Die Erfassung von Anforderungen erfolgt in der Regel unterteilt nach nichtfunktionalen und funktionalen Anforderungen. Eine nichtfunktionale Anforderung legt fest, welche Eigenschaften das Produkt haben soll. Ein Beispiel: «Das Produkt soll dem Anwender innerhalb von einer Sekunde antworten.»
Die nachfolgende Liste zeigt typische Arten von nichtfunktionalen Anforderungen:
- Zuverlässigkeit (Systemreife, Wiederherstellbarkeit, Fehlertoleranz)
- Aussehen und Handhabung (Look and Feel)
- Benutzbarkeit (Verständlichkeit, Erlernbarkeit, Bedienbarkeit)
- Leistung und Effizienz (Antwortzeiten, Ressourcenbedarf, Wirtschaftlichkeit)
- Betrieb und Umgebungsbedingungen
- Wartbarkeit, Änderbarkeit (Analysierbarkeit, Stabilität, Prüfbarkeit, Erweiterbarkeit)
- Portierbarkeit und Übertragbarkeit (Anpassbarkeit, Installierbarkeit, Konformität, Austauschbarkeit)
- Sicherheitsanforderungen (Vertraulichkeit, Informationssicherheit, Datenintegrität, Verfügbarkeit)
- Korrektheit (Ergebnisse fehlerfrei)
- Flexibilität (Unterstützung von Standards)
- Skalierbarkeit (Änderungen des Problemumfangs bewältigen)
- Rahmenbedingungen
Eine funktionale Anforderung legt fest, was das Produkt tun soll. Ein Beispiel: «Das Produkt soll den Saldo eines Kontos zu einem Stichtag berechnen.» Oft ist die Verlockung gross, bereits zu diesem Zeitpunkt genaue Vorgaben für das Aussehen von Eingabemasken etc. zu formulieren. Von einem solchen Vorgehen wird klar abgeraten. Es handelt sich dabei nicht um funktionale Anforderungen.
Funktionale Anforderungen (Beispiele, nicht abschliessend):
- Erfassung von Telefonnummern mit Status (frei, reserviert, zugewiesen etc.), Typ (DDI, Trunk, Mobile etc.) und Verwendungszweck
- Verbindung von Telefonnummer und Personen mit Angabe des Verwendungszwecks (z.B. Hauptnummer, direkte Nummer etc.)
- Verbindung von Telefonnummer und Vertrag (z.B. Fixnet- oder Mobile Provider)
- Erfassung von SIM-Cards mit Status, Seriennummer, PIN/PUK, Provider
- Verbindung SIM-Card mit Endgerät (Mobile Device, Notebook etc.)
- Wenn Telefonnummer Verwendungszweck = Mobile, dann Verbindung mit SIM-Card
- Wenn Telefonnummer Verwendungszweck = Fax, dann Verbindung mit Faxgerät oder Multifunktionsdrucker
Schritt 3: Anwendungsfälle modellieren
Die definierten Anforderungen werden im nächsten Schritt weiter detailliert und in einzelnen Anwendungsfällen dokumentiert. Der Versuch, einen komplexen Prozess in einem Durchgang vollständig zu beschreiben, ist in der Regel nicht zielführend.
Der Prozess «Telephony Management» ist mit den Prozessen «Identity Management» und «Service Asset & Configuration Management» verbunden. Für jeden Prozess gibt es eine Reihe von Anwendungsfällen (engl. Use Case), die wir beschreiben können (Beispiele, nicht abschliessend):
Identity Management
- Benutzereintritt
- Benutzermutation
- Benutzeraustritt
Service Asset & Configuration Management
- Neues Asset erfassen
- Bestehendes Asset aktualisieren
Telephony Management
- Telefonnummern verwalten
- Telefonnummern zuweisen
Für die Modellierung von Anwendungsfällen und BusinessProzessen eignet sich die «Business Process Management Notification (BPMN)». Bereits mit Microsoft Visio™ lassen sich BPMN Zeichnungen erstellen. Nimmt man noch den «Process Modeler for Microsoft Visio™» der Berner ITpearls AG hinzu, so lassen sich komplette Modelle abbilden.
Schritt 4: Objektmodell definieren:
Im Objektmodell werden die zu erstellenden Objekte, die dazugehörigen Attribute und die Verbindungen (Assoziationen) spezifiziert. Das CBAT Framework kennt verschiedene Arten von Objekten (Major Object, Supporting Object, Lookup Table etc.) mit unterschiedlichen Eigenschaften. Mithilfe eines ML Klassendiagramms wird nun das Objektmodell modelliert. Für jedes benötigte CBAT Objekt wird eine entsprechende UML Klasse (Abb. 4 Objektmodell) angelegt und die benötigten Attribute (Abb. 5 Attribute) werden definiert.
Schritt 5: Umsetzung mit der «Codeless Business Application Technology (CBAT)»
Im Gegensatz zu früheren Generationen von Service Management Werkzeugen unterstützt Cherwell® Service Management die Umsetzung von Business Applikationen ohne Kenntnis einer Programmiersprache. Um dies zu ermöglichen, wird die «Codeless Business Application Technology (CBAT)» eingesetzt. Basierend auf dieser Technologie, werden mit der «Cherwell Development Plattform™» bestehende «Blueprints» an die Bedürfnisse angepasst oder neue erstellt. Dabei bleibt das zugrundeliegende Framework immer upgradefähig und die getätigten Investitionen in die Business Applikationen bleiben erhalten.
Die Umsetzungsdauer hängt letztlich stark von der Qualität der Spezifikation (Anwendungsfälle und Objektmodelle) ab. Die Erstellung von Objekten, den dazugehörigen Attributen (Abb. 6 Objektmodell) und den grundlegenden Eingabemasken (Abb. 7 Maskendefinition) braucht wenig Zeit und lässt so Spielraum für die Perfektionierung der Anwenderfreundlichkeit. Die Businesslogik gemäss den zuvor definierten Anwendungsfällen kann mit der One Step Technologie (Abb. 8 One Steps) und den «Out of the box» Businessfunktionen rasch und effektiv umgesetzt werden. Dabei handelt es sich um mehrfach verwendbare Elemente zur Abbildung von Mini Workflows. One Steps haben Zugriff auf alle Objekte und deren Attribute und lassen sich beliebig verschachteln. Zudem sind sie in der Lage, neue Instanzen von Objekten zu erzeugen. Mit One Steps steht ein mächtiges Werkzeug zur Automatisierung von Workflows zur Verfügung, welches der Kreativität praktisch keine Grenzen setzt.
Schritt 6: Test und Abnahme
Im letzten Schritt wird die umgesetzte Lösung getestet und abgenommen. Dabei wird das System auf die Ziele und Anforderungen geprüft. Die zuvor definierten Anwendungsfälle stehen sogleich als Prüffälle zur Verfügung.
Ergänzungen / Quellen
Wikipedia – die freie Enzyklopädie, online im Internet
CBAT – «Codeless Business Application Technology», Arlen Feldmann, Cherwell Software, Inc., 2009
Autor
Stefan Beyeler, Leiter Consulting & Integration Services
Mitglied der Geschäftsleitung (2010)
