FLEXS: eStandards im technischen Service nutzen

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.