Im Rahmen der Förderinitiative "Mittelstand-Digital - IKT-Anwendungen in der Wirtschaft" des BMWi wurde 2012 unter anderem das Verbundprojekt FLEXS ("Flexibel-integrierbare wertschöpfungsorientierte Collaboration im Servicebereich auf der Basis von eStandards") aufgesetzt. Ziel von FLEXS ist es, existierende eStandards auf die Eignung für technische Serviceleistungen, wie Installation, Wartung und Instandhaltung zu untersuchen, gegebenenfalls Erweiterungsvorschläge zu erarbeiten und diese prototypisch umzusetzen.

Technische Servicedienstleister bekommen durch FLEXS die Möglichkeit, reibungslos an den digitalen Geschäftsprozessen ihrer meist größeren Auftraggeber teilzuhaben und zugleich über eine größtmögliche Autonomie bei der Steuerung der eigenen Prozesse zu verfügen. Die Beauftragung erfolgt medienbruchfrei, das heißt, ohne einen Wechsel des informationstragenden Mediums innerhalb des Prozesses. Somit werden Übertragungsaufwand und Fehlerquellen verringert. Das Auftragsgeschehen gewinnt dadurch insgesamt an Effizienz und Transparenz.

Wertschöpfung wird im Dienstleistungsbereich oft durch ein ganzes Netzwerk von meist eher kleinen und mittleren Unternehmen bzw. entsprechenden Servicepartnern erbracht. Im Rahmen des Projekts FLEXS wird eine Plattform für Dienstleister im technischen Servicebereich entwickelt, über welche die Dienstleister mit ihren Auftraggebern bestimmte Leistungspakete vereinbaren und Serviceaufträge austauschen sowie Servicepartner einbeziehen können. Die Plattform dient als Produktinformationssystem, in dem Leistungen abgebildet und verhandelt werden können. So können zum Beispiel regional ansässige Dienstleister ihr Portfolio darstellen und mit potentiellen überregionalen Auftraggebern in Kontakt kommen.

An FLEXS sind je ein Anwenderunternehmen aus dem Bereich der Installation und Instandhaltung von Bürogeräten (KAUTBULLINGER Büro-Systemhaus) als auch aus dem Bereich der Installation und Instandhaltung von Kabelnetzen (IMT Medientechnik Betriebs- und Service GmbH) beteiligt. Der Lösungsansatz von FLEXS soll jedoch grundsätzlich branchenunabhängig sein. Es wird von Dienstleistungen ausgegangen, die in gewissem Rahmen als standardisiert und typisch für technische Dienstleister bezeichnet werden können, so wie die Installation und Wartung von technischen Geräten. Das soll ermöglichen, dass sowohl die Dienstleistungsprodukte als auch die Konditionen zugehöriger Serviceverträge als bereits zwischen Auftraggeber und Auftragnehmer verhandelt angenommen werden können. Dadurch wird der Auftragsprozess stark vereinfacht.

Das Projekt FLEXS beinhaltet die prototypische Realisierung eines Servicemanagementsystems, die Erweiterung einer Plattform zur Darstellung von Leistungsverzeichnissen und die Analyse und Bewertung von Serviceprozessen in Hinblick auf eine verschwendungsarme Gestaltung sowie eine Prüfung, ob und wie sich auf Basis der Ergebnisse neue Geschäftsmodelle im Service realisieren lassen. Auf diese Teilaspekte des Vorhabens wird hier jedoch nicht näher eingegangen.

Woraus ergibt sich der wachsende Bedarf, technische Serviceleistungen mit eStandards abzubilden?

eStandards werden häufig für die Bestellung und Lieferung von Waren oder von relativ einfachen Dienstleistungen eingesetzt. Bei technischen Dienstleistungen kommt jedoch noch hinzu, dass eine Leistung an einem technischen Objekt ausgeführt werden muss, dass Service- und Garantieverträge die Konditionen und Leistungen festlegen und dass die Kunden integriert werden müssen, wie etwa bei einer Terminvereinbarung vor Ort. Dennoch gibt es einen zunehmenden Bedarf, eStandards im Geschäftsbereich des technischen Service einzusetzen. Dieser resultiert aus mehreren Umständen:

1. Die Leistungserbringung im technischen Service erfolgt oft in einem Wertschöpfungsnetzwerk, an dem zahlreiche Geschäftspartner beteiligt sind. Bei Arbeiten an Telekommunikationsnetzen ist es beispielsweise aus Sicht des Dienstleisters der Normalfall, dass Auftraggeber und Leistungsempfänger unterschiedliche Geschäftspartner darstellen, Logistikaufgaben an andere, dedizierte Geschäftspartner vergeben sind und für die Garantiefallabwicklung direkter Kontakt mit den Herstellern als weiteren beteiligten Geschäftspartnern aufzunehmen ist. Ein beteiligter Dienstleister sollte nicht nur seine beauftragte Leistung ausführen können, sondern sollte im Idealfall auch über vertragliche Vereinbarungen informiert sein, die an anderer Stelle der Prozesskette geschlossen wurden, die aber dennoch für ihn von Bedeutung sind. Hat der End-Kunde Anspruch auf ein höheres Service-Level mit kürzeren Antrittszeiten oder erhält er bei Bedarf ein kostenloses Ersatzgerät? Eine auftraggeberspezifische Automatisierung ist für viele Dienstleister nicht möglich. Bestehen größere Auftraggeber jedoch auf eine Automatisierung (d.h. ohne Einhaltung von Standards), ist ansonsten zu beobachten, dass diese entweder separate Systeme in separaten Teams betreiben oder gar die Servicemanagementsysteme ihrer Auftraggeber mitbenutzen.

2. In zunehmendem Maße wird von den Serviceanbietern erwartet, dass sie die im Rahmen der Servicedurchführung anfallenden Geräte- und Anlagendaten (beispielsweise. Konfigurationsdaten, Betriebsparameter) zur automatisierten Pflege von Bestandsinformationen in einer verwertbaren Form an den Auftraggeber zurückmelden. Die Rückmeldung auftragsbezogener Ist-Daten dient als Nachweis für die Einhaltung von vertraglich vereinbarten Ziel-Größen (Key Performance Index, Service Level Agreement). Die Menge und Differenziertheit der zu erfassenden Daten führt bei einer entsprechenden Zahl von Geschäftspartnern zu einem erheblichen Mehraufwand, wenn sie ohne Automatisation bzw. Standardisierung durchgeführt werden muss. Zudem wachsen auch die Ansprüche an die Aktualität dieser Rückmeldedaten.

3. Nicht zuletzt fehlt bisher auch eine praktikable Handlungsanweisung, wie technische Serviceleistungen zu beschreiben und zu klassifizieren sind, so dass dahingehend überbetriebliche Transaktionen einheitlich gestaltet werden können. Die betriebliche Praxis dürfte heute bei kleineren Serviceanbietern vielmehr noch so aussehen, dass die Konditionen in preislicher und zeitlicher Hinsicht sowie auch der Bezug zu Geräten oder Gerätegruppen im Artikelstammsatz für die Dienstleistung formuliert sind. Damit geht eine klare Struktur verloren, und dies erschwert oder verhindert die elektronische Abwicklung von Geschäftsprozessen zwischen den Geschäftspartnern. Besser wäre es, zwischen den Produkten (Dienstleistungen oder Geräte) und den Konditionssätzen sowie zwischen Gerätedaten und dienstleistungsbezogenen Daten zu trennen und diese Elemente wieder zuordenbar zu machen. Der erfolgreiche Einsatz von Standards wird nicht nur damit erreicht, dass bestimmte Schnittstellenformate unterstützt werden. Entscheidend ist, dass tatsächlich wiederverwendbare Datenelemente und Prozessschritte eingesetzt werden können. Die Datenpflege wird damit erheblich vereinfacht.

Angemerkt sei, dass mit der Nutzung von eStandards noch keine Standardisierung der Dienstleistungen selbst einhergeht. Jedoch ist zu erwarten, dass sich aufgrund der stärker formalisierten Darstellung die Vergleichbarkeit von Dienstleistungen erhöhen wird.

Ansätze und Erweiterungen zur Abbildung von Dienstleistungen mit existierenden eStandards

Aufgrund des allgemeingültigen Ansatzes und der weitgehenden Kompatibilität zum Katalogstandard BMECat und dem Klassifizierungsstandard eCl@ss fiel die Wahl zur Referenzimplementierung auf den XML-basierten und kompatiblen Transaktionsstandard openTRANS. Bei diesem Standard, der auf Initiative deutscher Unternehmen zustande kam und durch das IAO Fraunhofer Institut Stuttgart herausgegeben wird, ist die Möglichkeiten zur Mitwirkung an künftigen Versionen am größten. Zudem beinhaltet dieser Standard auch bereits die Option spezifischer Erweiterungsmöglichkeiten. In folgender Hinsicht wird bereits heute die Abwicklung von Dienstleistungsprozessen durch openTRANS/BMECat unterstützt:

Durch das Element AGREEMENT, welches für Rahmen- und Lieferverträge vorgesehen ist, lassen sich einem Serviceauftrag Vertragsdaten mitgeben. Die Verträge sind dort nicht umfassend abgebildet, sondern stellen im Wesentlichen nur Bezüge mit einer Vertragsnummer, einer Vertragsbezeichnung sowie dem Gültigkeitszeitraum dar. In der Regel reichen diese Angaben jedoch aus, damit ein Dienstleister daraus auch eine Servicevertragsart und die damit verbundenen preislichen und zeitlichen Konditionen bestimmen kann. Dem Auftrag wie auch den Auftragspositionen können mehrere solcher Vertragsreferenzen zugeordnet werden, so dass beispielsweise neben einen Servicevertrag, der zwischen Auftraggeber und Dienstleister vereinbart ist, ein zusätzlicher Vertragsbezug zum Servicelevel eines Endkunden treten kann. Dieser zweite Vertragsbezug kann Ansprüche des Endkunden z. B. in zeitlicher Hinsicht festlegen, die vom Dienstleister als letztem Glied der Beauftragungskette zu erfüllen sind.

Produkte können neben den produkttypbezogenen Identifizierungsmerkmalen wie einer Artikelnummer auch anhand der Seriennummer als alleiniges oder kombiniertes Merkmal identifiziert werden. Somit lassen sich auch Einzelgeräte in einem Auftrag darstellen, und zwar einheitlich, unabhängig davon, ob sie bereits beim Kunden ist oder noch geliefert wird. Die Abbildung als reine "Bezugsposition" für eine Dienstleistungsposition wird durch die Zulässigkeit des Wertes 0 für die Bestellmenge möglich. Diese Darstellung unterstützt auch die zuvor geforderte Trennung von geräte- und dienstleistungsbezogenen PRODUCT_FEATURES zur Beschreibung von Produktmerkmalen.

Alle Standards enthalten heute Elemente zur Übertragung von frei definierbaren Produktmerkmalen, wobei im Fall von openTRANS und BMECat die Definition eines Merkmals auch aus einem Produktklassifizierungssystem wie eCl@ss abgeleitet werden kann. Damit ist die Aussage und der Aufbau eines Merkmals (nicht sein Wert, den es erst durch Verwendung für ein Produkt erhält) unternehmensübergreifend definiert. Beispielsweise Füllmenge, Farbe oder Abmessung einer Toner-Kartusche. Für den technischen Service wäre es wichtig, in gleicher Weise auch Betriebsmerkmale übergeordnet definieren zu können. Diese unterscheiden sich von anderen Merkmalen primär dadurch, dass sie seriennummernbezogen sind, im Lebenszyklus veränderlich und daher mit einem Erhebungsdatum zu erweitern sind. Beispiele sind die verschiedenen Zählerstände bei Bürogeräten oder ein Inbetriebnahmedatum, die mit einer solchen Maßnahme in die automatisierte Auftragsabwicklung einbezogen werden können. In anderen Zusammenhängen werden auch Vorgabewerte benötigt, generell aber sind die Unterschiede von Betriebsmerkmalen zu Produktmerkmalen nicht so groß, als dass man sie nicht mit dem Element PRODUCT_FEATURE übertragen könnte. Wesentlich ist dabei, dass dies in einer Form geschieht, die den wahren Zusammenhängen entspricht: Betriebsmerkmale bleiben eine mit dem Gerät verknüpfte Information, für das eine Dienstleistung beauftragt oder rückgemeldet wird, und sie werden nicht heimlich zu einer dienstleistungsbezogenen Information, welche nicht oder nur durch spezifische Transformationen in die Gerätebestandsdaten zurückübertragen werden kann.

Es besteht Erweitungsbedarf

Die angesprochenen Beispiele zeigen, dass insbesondere für einigermaßen standardisierbare Serviceleistungen vielversprechende Ansätze in den Standards enthalten sind. Es besteht in einigen Punkten aber auch Erweiterungsbedarf.

Zu den wichtigsten Maßnahmen, die sich FLEXS zum Ziel gesetzt hat, gehört die Konzeption und Umsetzung einer Transaktion zur Rückmeldung von Aufträgen vom Dienstleister an den Auftraggeber. Die bestehenden Transaktionsarten des openTRANS, die dafür in Frage kämen, nämlich die der Auftragsbestätigung (ORDER_RESPONSE) und der Lieferavis (DISPATCH_NOTIFICATION) haben eine anderslautende Semantik für die Auftragsabwicklung. Eine neue Transaktion mit dem Namen ORDER_STATUS soll daher von Bearbeitungsbeginn bis Auftragsabschluss dem Auftraggeber aktuelle Informationen über Auftragsstand, erbrachte Leistungspositionen und Geräte- bzw. Anlagenkonfiguration übermitteln. Auch Zwischenzustände wie etwa eine temporäre Nicht-Ausführbarkeit aufgrund fehlender Informationen oder das Warten auf einen Kundentermin sollen übermittelt werden können, damit der Auftraggeber diese per ORDER_CHANGE nachreichen kann. Welche Zustandswechsel im Einzelnen eine Rückmeldung auslösen und welche Daten dabei geschickt werden, muss natürlich konfigurierbar sein.

Verschiedene Erweiterungen mit weniger großem Umfang betreffen die bereits bestehenden Transaktionsarten. Damit diese konform mit der openTRANS-Spezifikation bleiben, können diese aller Voraussicht nach auch mit den existierenden Elementen und den "user defined extensions" realisiert werden.

Zur besseren Unterstützung ortsgebundener Serviceleistungen soll eine dokumenteninterne Verlinkung zwischen den PRODUCT_FEATURES und den zum Geschäftspartner vorliegenden Adressdaten hergestellt werden. Damit können Geräte auf diese Adressen referenzieren und sie als ihren Standort oder eine andere Form der Serviceadresse ausweisen.

Serviceeinsätze benötigen gegebenenfalls einen oder mehrere Termine vor Ort, die mit dem Auftraggeber und/ oder dem Kunden zu vereinbaren sind und welche zeitlich vor dem vereinbarten Liefertermin liegen können. Daher ist vorgesehen, die Transaktionsarten durch die Darstellung einer allgemeinen Terminfolge zu erweitern, welche einerseits Bezug zu den Leistungspositionen und andererseits zu den Adressen und Kontaktangaben der openTRANSDokumente erhält. Der Ansatz, die bestehenden Transaktionsarten um wünschenswerte Elemente zu erweitern (lediglich ORDER_STATUS kommt neu hinzu), wird als wesentlicher Vorteil für ein Umfeld mit mehreren Geschäftspartnern und insbesondere für klein- und mittelständische Unternehmen (KMU) gesehen; denn der Ansatz erlaubt es, sich auf die datentechnische Unterstützung einer überschaubaren Anzahl von Transaktionsarten zu konzentrieren. (mje)