Das Herzstück unserer Lösung ist ein leistungsfähiges Baukastensystem mit dem Sie viele Möglichkeiten zur Gestaltung Ihrer Angebote erhalten.
Im zweiten Teil unserer kleinen Serie tauchen wir etwas in die Möglichkeiten der Produktgestaltung mit pSuite OSS/BSS ein.
Wir haben bei der Entwicklung von pSuite OSS/BSS von Anfang an darauf geachtet, dass man neue Angebote möglichst schnell auf den Markt bringen kann. Dabei haben wir die Software im Kern so gebaut, dass man zentral die kaufmännischen und aber auch die technischen Parameter festlegen kann, die für einen Dienst zur Anwendung kommen sollen. Wir steuern also im Endeffekt Verkauf, Billing und den Lebenszyklus des Dienstes aus dem Produkt- oder Service-Katalog heraus.
Artikel, Dienst, Produkt… Wieso sprechen wir nicht einfach von Diensten in diesem Beitrag? Nicht alle Produkte sind ein Dienst. Sie können in unserem System auch HDMI-Kabel oder Zusatzartikel für den Verkauf in Ihrem „Laufkundschafts-Shop“ führen.
Die nachstehenden Konzepte im Design von Artikeln und Angeboten ermöglichen es uns, die Bestellprozesse in den webbasierten Bestellwizards für Endkunden automatisch anzupassen. Es braucht dazu keine regelmässigen Entwicklungsarbeiten unsererseits. Ebenso richten sich natürlich die manuelle, interne Auftragsbearbeitung im Rich-Client nach den definierten Regeln und reduziert somit die Falscherfassung von Aufträgen deutlich.
Aus Gründen der Einfachheit werde ich einige Aspekte weglassen. Wichtig ist mir zu betonen, dass unsere Kunden – nach erfolgter Schulung – das Product Management innerhalb pSuite OSS/BSS selbständig vornehmen können und somit zügig Anpassungen an bestehenden Produkten vornehmen und neue Produkte lancieren können. Sollten neue Konzepte eingearbeitet werden, stehen wir dann beratend zur Verfügung.
Die Artikel sind in unserer Software die Legosteine, aus denen Sie ihre Angebote zusammen bauen können. Von der Rufnummer über den Internetanschluss bis hin zum umfassenden Bundle-Angebot: in pSuite OSS/BSS sind dies immer Artikel, welche über Relationen miteinander verbunden werden können.
Für physisch vorhandene Artikel wie zum Beispiel Modem/Router, Set-Top-Boxen und SIM-Karten bieten wir eine integrierte Lagerverwaltung, welche auch verschiedene Lagerplätze unterstützt. Somit ist jederzeit ersichtlich, was sich wo befindet. Der Lagerbezug und die Rücknahme von Mietgeräten sind ebenfalls in den Auf-/Abschaltprozess integriert.
Die technischen Parameter sind so etwas wie der Bauplan für den Dienst, der sich hinter dem Artikel verbirgt. Im Falle eines VoIP-Telefonanschlusses sind dies unter anderem Informationen wie:
Die technischen Parameter werden getrennt vom Artikel geführt und lediglich referenziert. Das bedeutet, dass die Person, die für das Assemblieren der Artikel zuständig ist kein tiefes technisches Verständnis für dessen Konfiguration benötigt. Da die Konfigurationen nur Referenziert werden, können Sie im Bedarfsfall bei mehreren Artikeln wiederverwendet werden.
Die kaufmännischen Parameter umfassen alles, was mit der Preisfindung, Lagerführung und Verbuchung zusammenhängt. Es handelt sich dabei unter anderem um:
Die kaufmännischen Daten werden direkt auf dem Artikel geführt. Die Preisfindung ist somit immer ersichtlich und nicht in irgendwelchen Regelwerken tief in der Software versteckt.
Über Relationen zwischen den Artikeln können Sie nun Ihre Angebote aufbauen. Was ist aber mit diesen Relationen gemeint? Die Relationen funktionieren im Prinzip wie eine Stückliste. Man teilt dem System so mit, dass ein Artikel sich aus anderen Artikeln zusammensetzt. Eine solche Relation kann sich auf einen einzelnen untergeordneten Artikel beziehen oder aber eine definierte Auswahl von Unterartikeln zulassen.
Auf den Relationen gibt es zahlreiche Einstellungsmöglichkeiten:
Dies ist nur eine Auswahl der Möglichkeiten. Sehen wir uns das an einem Beispiel an:
Wir bauen ein einfaches Telefonie-Angebot. Es soll aus einem Account mit mindestens einer Rufnummer bestehen. Optional kann man 2 weitere Rufnummern hinzufügen. Ebenfalls optional kann der Kunde noch eine Flatrate dazu buchen.
Um dies im System abzubilden sind 3 Artikel notwendig:
Nun werden für den Artikel „VoIP-Telefonie“ die Relationen zu den beiden anderen Artikeln entsprechend festgelegt und die Arbeit ist erledigt.
Natürlich, jemand musste noch die technischen Konfigurationen für die drei Artikel bereitstellen. Dies ist in der Regel keine grosse Sache und oft kann eine bestehende Konfiguration wiederverwendet oder zumindest kopiert werden.
In der Realität ist ein VoIP-Telefon aber oftmals nur ein Bestandteil eines grösseren Angebotes. Was müssen wir nun tun, damit wir in einem anderen Angebot die Telefonie inkludieren können? Nur eine weitere Relation einfügen.
Gesetzt den Fall wir hätten schon das Angebot „Abo X“ mit Internet und TV und wollen nun ebenfalls noch Festnetz-Telefonie als Option für dieses Abonnement ermöglichen, dann reicht es aus das bereits bestehende Angebot „VoIP-Telefonie“ über einen Relation dazu zu konfigurieren.
Auch die möglichen Produktwechsel werden im Product Management als Relationen zwischen Artikeln modelliert. So kann pSuite OSS/BSS die Möglichkeiten für Produktwechsel einschränken und zum Beispiel einen Wechsel von einem älteren auf ein neueres Produkt zulassen, während es die umgekehrte Richtung vom neueren auf das ältere Produkt unterbindet.
Weshalb legen wir die Regeln auf den Relationen zwischen den Artikeln so genau fest? Könnte man nicht einfach eine flache Liste von Artikeln im System führen und die Bestellungen so zusammenstellen, wie es halt grad kommt?
Dieses hierarchische System hat sich in den letzten Jahren immer wieder bewährt. Es ermöglicht uns unter anderem folgende Dinge:
Unsere webbasierten Bestellprozesse basieren direkt auf diesem Produktekatalog. Sei es für Endkunden- oder Reseller-Bestellungen, es geht nur was das Product Management erlaubt. In dem die Regeln klar definiert sind – und durch den Bestellprozess auslesbar – ersparen wir Ihnen ein ständiges Anpassen des Bestellprozesses an ein geändertes Angebot.
Bei der manuellen Erfassung von Bestellungen im Rich-Client von pSuite OSS/BSS greifen diese Regeln ebenfalls. Ein Mitarbeiter im Service Desk kann einem Kunden auch nur die Dienstleistungen aufschalten, die in dem betreffenden Kontext möglich sind. Dasselbe gilt für Up-/Downgrade-Möglichkeiten, die zuvor festgelegt worden sind.
Jeder einzelne Artikel „kennt“ seinen Lebenszyklus komplett. Es ist bekannt, was das System für Aktivierung und Abschaltung machen muss. Dadurch kann man gleichartige Bausteine mit wenig Aufwand neu erstellen oder einfach bestehende wiederverwenden – was immer dem Zweck besser dient.
Die Dienste werden in einer hohen Verlässlichkeit und mit gleichbleibender Struktur und Qualität aufgeschaltet. Dies vereinfacht die Problemlösung bei Supportfällen und ist auch bei immer Mal wieder notwendigen Migrationen auf neue Generationen von Systemen sehr praktisch.
MHM & Partner AG
Birkenstrasse 43a
CH-6343 Rotkreuz
Schweiz
+41 43 521 80 80
Billing – mit uns können Sie (ab)rechnen 