IT im Handel

Open Buying: Lösungen und Konzepte

19.09.1997

Während im Business-to-Consumer-Segment nach anfänglicher Euphorie zunehmend eine gesunde Ernüchterung einkehrt, gewinnt das Web im zwischenbetrieblichen Bereich zunehmend an Dynamik. Unter dem Kürzel "OBI" (Open Buying on the Internet) wurde im Mai dieses Jahres im Internet ein Framework für die zwischenbetriebliche Bestellabwicklung auf Basis von WWW und EDI veröffentlicht.

Noch vor gut einem Jahr existierten so gut wie keine Standardlösungen für den Online-Vertrieb am Markt, wodurch dieser Vertriebskanal überwiegend finanzstarken Unternehmen vorbehalten blieb. Heute tummelt sich eine Vielzahl mehr oder minder leistungsfähiger Shopping-Systeme auf einem zunehmend undurchschaubaren Markt. Das Produktspektrum reicht von einfachen Produktkatalogen für unter 200 Mark über Shopping-Systeme zwischen 2000 und 100 000 Mark bis zu Entwicklungsumgebungen zum Erstellen von Individuallösungen. Hinter vielen Angeboten stecken Produkte, die sich noch in der Entwicklung befinden, oder die Offerte für eine Individuallösung.

Generell sind verschiedene Realisationsformen zu unterscheiden. Individuallösungen lohnen nur noch für Unternehmen mit speziellen Anforderungen, die sich nicht von Standardprodukten abdecken oder nachträglich implementieren lassen. Bei Betrieb im eigenen Haus sind eine Standleitung zum Internet-Provider sowie das Kow-how zur Pflege und Wartung nötig. Läßt man das Shopping-System von einem Provider gegen Entgelt betreiben, genügt meist eine Wählverbindung für die Angebotspflege. In beiden Fällen muß der Anbieter ein Shopping-System erwerben und sich die Publicity seiner Produkte kümmern.

Mall-Systeme wie My World (Karstadt) oder World Avenue (IBM) offerieren eine funktionsreiche und komfortable Vertriebsplattform für viele Anbieter. Aufgrund der höheren Attraktivität durch die Angebotsvielfalt steigt die Wahrscheinlichkeit, von Kunden gefunden zu werden. Hier benötigt der Anbieter nur noch einen Zugang über Internet, Modem oder ISDN. Zur Zeit schießen Mails wie Pilze aus dem Boden, so daß es nicht wundert, wenn sich angesichts dieser Splitterung in all diesen Malls nur relativ wenige "Shop-Inhaber" finden. Erste Konsequenzen zieht IBM, die den Betrieb ihrer Mall einstellt.

Standardprodukte meist die beste Wahl

Neu ist der Ansatz, die betrieblichen Anwendungssysteme direkt ans Web anzubinden. Hierzu offerieren etwa SAP, People Soft oder Baan zunehmend Schnittstellen, oder die Datenbasis wird über Drittprodukte, die Web-Gateways, angezapft; sowohl die Datenaktualität als auch die Interaktionsmöglichkeiten (zum Beispiel Produktverfügbarkeit, Reservierungen) sind unschlagbar. Doch wer läßt schon gerne x-beliebige Fremde an seine kritischen Systeme?

Für die meisten der potentiellen Online-Shop-Betreiber sind Standardprodukte die beste Wahl. Am Markt gibt es funktionale Systeme mit gutem bis sehr gutem Preis-Leistungs-Verhältnis. Selbst für eher ausgefallenere Anforderungen wie Stücklistendarstellung oder kundenindividuelle Preise beziehungsweise Informationsangebote finden sich Produkte.

Lange Listen über Shopping-Systeme, wie sie in diversen Medien publiziert werden, sollten nicht darüber hinwegtäuschen, daß sich hierzulande nur wenige sinnvoll nutzen lassen. Dies gilt insbesondere für Produkte aus den USA, die mit deutschen Standards nicht kompatibel sind und die weder einen lokalen Vertrieb noch Support besitzen.

Um die richtige Auswahl treffen zu können, nimmt neben Preis und Funktionsumfang auch die Handhabbarkeit für die Einrichtung und Pflege des Online-Angebots einen hohen Stellenwert ein. Hinzu kommen besondere Anforderungen wie Mehrsprachigkeit, Anbindung an bestehende Anwendungssysteme, geschlossene Benutzergruppen und betriebswirtschaftliche Funktionen wie Lagerbestands-, Auftrags-, Lieferantenverwaltung oder Nachbevorratung. Basisfunktionen wie Warenkorb, Bestellfunktion, Bestellbestätigungen per Mail und Fax, individuelle Rabattierung und Steuersatzfindung sowie Produktdarstellung in Listen- und Detailform gehören zum Standard. Markante Unterschiede zwischen den Systemen ergeben sich in puncto Sonder-Features und Komfort.

Dies beginnt bereits beim Lieferumfang. Während etwa der Internet Sales Server (Compu Team GmbH) inklusive leistungsfähiger Datenbank, Web-Server, E-Mail und zahlreichen Verwaltungsfunktionen ausgeliefert wird, sind diese bei manch anderen Produkten nicht oder nur in rudimentärer Form im Lieferumfang enthalten. Zusatzkosten durch Zukauf und Implementierung sind dann unvermeidlich.

Analoges gilt für die Einrichtung und Administration. Sind im Lieferumfang Beispiel-Stores oder vorgefertigte Seiten (Templates) für diverse Einsatzfelder wie Produktpräsentation oder Store-Fronts enthalten, läßt sich vielfach bereits durch einfache Anpassungen wie das Einbinden von Logos und anderen Seitenhintergründen das eigene Angebot erstellen. Von Individualisten ist solide Handarbeit bei der Seitenerstellung gefordert sowie ein System, das die flexible Einbindung von Java, Bild- und Grafikinformationen (etwa eine Explosionszeichnung als sensitive Map) erlaubt. Auch die Verwaltung von Sonderangeboten auf der Home-Page ist keineswegs Standard bei den marktgängigen Produkten.

Detaillierte Auswertungen über Produktzugriffe, Warenkorbzusammensetzung bis zu einem echten Kunden-Profiling lassen die Herzen der Marketiers höher schlagen. In Abhängigkeit vom Einkaufsverhalten unterbreiten Agenten dem Kunden "geeignete" Special Offers oder beschränken das Gesamtangebot auf die für den Kunden relevanten Teilbereiche (kundenindividuelle Store-Fronts). Während vernünftige statistische Auswertungen als Gütezeichen für gute Systeme gelten können, steht man beim "intelligenten" One-to-one-Marketing mit Agenten bislang noch am Anfang.

Anbieter warten auf Standardisierung

Die Bereitstellung von (einfachen) Warenwirtschaftsfunktionen, wie sie insbesondere Intershop von Intershop Communications bereithält, eröffnet kleinen und mittleren Unternehmen eine interessante Möglichkeit, den Abwicklungsanforderungen des Online-Vertriebs Herr zu werden, ohne eine aufwendige Integration in das Inhouse-System vornehmen zu müssen.

Deutlich an Bedeutung gewinnen Schnittstellen zu Datenbanken oder betrieblichen Anwendungssystemen. Redundante Produkt- und Kundenpflege sowie die Nacherfassung von Bestellungen im Anwendungssystem sind hierdurch vermeidbar. Läßt sich die Datenübernahme aus verschiedenen Datenquellen wie Datenbanken oder Export-Files noch relativ einfach realisieren, ist der direkte Zugriff auf Datenbasen durch das Shopping-System mittels ODBC oder SQL mit viel Bedacht vorzunehmen. Realisationsaufwand, die zusätzliche Performance-Belastung und die entstehenden Sicherheitsanforderungen sollten im Vorfeld berücksichtigt werden.

Eine Alternative bietet die Einrichtung von "Schattendatenbanken" mit den aktuellen Anwendungsdaten, die jedoch logisch und physikalisch getrennt von den kritischen Anwendungen sind. Das Zurückschreiben von Daten in das Inhouse-System (zum Beispiel Aufträge), das heißt die volle Interaktion zwischen Shopping- und Anwendungssystem, bildet eine echte Herausforderung für Experten. Für R/3 werden jedoch bereits Schnittstellen angeboten. Nicht unähnlich der Integrationsproblematik bei EDI genügt es nicht, einfach in die Datenbasis des Anwendungssystems zu schreiben. Es müssen die internen Verarbeitungsschritte nachvollzogen oder die Daten an die Vorgangsbearbeitung übergeben werden.

Für die sichere Geschäftsabwicklung lassen nahezu alle Produkte den Einsatz von Secure-Web-Servern (SSL, S/HTTP) zu. Gleiches gilt für elektronisches Bezahlen, das Schnittstellen zu den einzelnen Verfahren vorsieht. Die Anbieter warten jedoch noch auf die Standardisierung einzelner Verfahren.

Generell ist anzumerken, daß es bislang keine Plug-and-play-Lösungen für den Online-Vertrieb gibt, die ohne fundierte Betriebssystem- und HTML-Kenntnisse auskommen. Im Verlauf der Untersuchung verschiedener Verkaufssysteme waren bereits bei der Installation langwierige Telefonate mit dem Support keine Seltenheit, und selbst dann war der Erfolg nicht garantiert. Ebenfalls als kritisch erwies sich die Anbindung an "beliebige" Web-Server, Datenbanken und sonstige Produkte von Drittanbietern, die zum Betrieb des Systems erforderlich sind. Kleinere Unternehmen kommen somit nicht umhin, sich ihr Vertriebssystem zumindest einrichten zu lassen.

Während sich die beschriebenen Online-Shopping-Systeme auf den Business-to-Consumer-Bereich konzentrieren, wurde OBI (Open Buying on the Internet) für den zwischenbetrieblichen Einsatz entworfen. OBI zielt auf geringpreisige, häufig auftretende Geschäftstransaktionen, die insgesamt 80 Prozent des Vertriebsumsatzes ausmachen.

Unternehmen (Buying Organizations) unterhalten für ihre Mitarbeiter Web-basierte Link-Listen zu den elektronischen Produktkatalogen von Zulieferanten oder spiegeln deren Angebot. Beim Auftreten eines Bedarfs wählt der Mitarbeiter (Requisitioner) einen Lieferanten (Selling Organization) aus und bestellt nach einer Authentifikation entsprechend den Firmenkonditionen. Ferner läßt sich der Status einer bereits erfolgten Bestellung abfragen. Der Lieferant generiert auf Basis dieser "Web-Bestellung" eine EDI-Auftragsanfrage (Order Request) und übermittelt sie an das bestellende Unternehmen, das nach Prüfung eine verbindliche EDI-Bestellung (Order) zurücksendet. Auftretender Bedarf wird somit direkt, dezentral und unbürokratisch von den Verantwortlichen manuell initiiert. Der eigentliche Bestellvorgang sowie die Bezahlabwicklung geschieht jedoch automatisiert per EDI zwischen den Anwendungssystemen der Beteiligten.

OBI nicht als Produkt mißverstehen

OBI ist nicht als Produkt, MWD oder als verabschiedeter Standard mißzuverstehen. Auf knapp 200 Seiten werden vielmehr strukturierte technische und organisatorische Rahmenbedingungen dargestellt. Das "Framework" umfaßt anschaulich die wesentlichen zu lösenden Aspekte wie Nachrichtentransport, Verschlüsselung, Interfacing oder Abwicklungsprozeß und schreibt die Nutzung von Standards für die garantierte Operabilität vor.

Leider sind die Aussagen sehr allgemein gehalten und spiegeln viel Wunschdenken wider. Hinzu kommt, daß der OBI-Ansatz bislang lediglich ein denkbares Abwicklungsmodell beschreibt und nur zwei EDI-Nachrichtentypen (Order, Order Request) basierend auf ANSI X12 (850) enthält.

Edifact soll miteinbezogen werden, sobald die geplante Zusammenführung von Edifact und ANSI X12 erfolgt ist. Offen bleiben auch organisatorische Faktoren wie Mindestbestellmengen, Prüfung von Auftragsanfragen oder innerbetriebliche Anpassungen in der Bestellabwicklung.

Das OBI-Framework haben Unternehmen mit dem Ziel entworfen, Abläufe zu verbessern und realen Nutzen zu erzielen. OBI ist eine gute Checkliste für alle Interessierten mit dem erforderlichen technischen und betriebswirtschaftlichen Know-how. Es ist aber weder ein Bauplan für EC-Lösungen noch ein Standard, der sich durch seinen Einsatz in der Industrie oder durch Gremien legitimiert hat.

* Dr. Rainer Scheckenbach ist Geschäftsführer der Integratio, Gesellschaft für zwischenbetriebliche Integration und Electronic Commerce mbH in Würzburg.