|
ISSN 1436-3011 |
 |
 |
|
|
09.02.2010 |
|
 |
|
                          
|
|
|
|
|
|
|
||
|
|
|
|
||||
|
|||||||
 |
|
 |
|||||
Ach, elektronische Märkte! Erst gefiel ihnen die Unterstützung von Preisfindungsmechanismen nicht (zu transparent, zu fortgeschritten, zu wenig standardisiert, ...), dann behagte ihre "Besteuerung" von Transaktionen nicht (warum überhaupt Geld ausgeben?) und jetzt ist wieder alles zu experimentell (Collaborative Commerce, Prozessportale etc.). Dabei waren doch alle Rahmenbedingungen einer gesunden Evolution gegeben, die zu erfolgreichen Systemen hätte führen müssen: Oracle, Microsoft, IBM usw. sorgten für die nötige Biomasse an Dienstleistungen und Produkten und Venture-Capitalists für Mutationen der Business-Modelle. Und was für herrliche Monster wurden aus dieser Mischung geboren! Vom allumfassenden Marktplatz-Framework bis hin zum Mapping-Tool für den Austausch von Katalogdaten. Aber dennoch - unsere Träume des (im Gegensatz zum vorherigen, eher euphorischen) "Fin de Siecle" haben sich kaum erfüllt: Wovon träumten wir damals noch? Erinnern wir uns: Onlineverzeichnisse dienen Softwareagenten zur Ermittlung von Anbietern, die ein erforderliches Produkt online anbieten. Hierbei lassen sich verschiedene Märkte durchforsten - es ist ja schließlich auch zwischen diesen Wettbewerb zugelassen! Wenn unser Agent ein paar Anbieter gefunden hat, beginnt er zu verhandeln und feilscht so lange, bis er bei irgendeinem Anbieter die besten Konditionen erreichen konnte. Dann kommt es zum Kauf und zur Lieferung. So weit - so visionär ... Aber es klappte bis jetzt nicht so richtig in der Praxis! Und es wird wohl auch ein paar Jahre noch nicht klappen. Warum? Weil sich die Welt des B2B nicht aus den Definitionen der Ingenieure in Gang setzen und am Leben erhalten lässt, sie ist eben doch wie Quecksilber: Anstatt auf eine ECO-Architektur oder eine Marktplatz-Architektur von Commerce One, Ariba, SAP etc. abgebildet zu werden, verändern sich die Parameter des kommerziellen Miteinander permanent. Soweit die technische Argumentation. Dazu sind Marktplätze häufig schlichtweg zu teuer. Traue keinem über 30 (Millionen Euro Kapitalbedarf), könnte man sagen. Marktplätze waren zu oft der Probelauf von Einzelfertigungen der Softwarehersteller und IT- Berater. Nicht nur einmal hatte ich hierbei das Vergnügen, als "Bad Cop" in einer Präsentationsrunde zu sitzen, bei der mir die Rolle zugedacht wurde, das Insistieren der Consultants, ein geplanter Messaging Hub müsse einige zehn Mio. Euro kosten, durch sachliche, technische Argumente in realistische Bahnen zu lenken. Es zeichnet sich dabei immer wieder das gleiche Bild ab: Die Business Consultants raten (vulgo: berechnen aufgrund einer eingehenden Analyse) den Return-on-Investment der Investition und die IT-Berater setzen dann den Preis des Projekts bei, sagen wir, ungefähr 50% an. Damit ist doch eigentlich eine Win-Win- Situation erreicht? Eigentlich schon, würde nicht der Kunde aus dem Spiel ausscheren und sein Risiko einer Fehlinvestition konservativer einschätzen: Bei ihm darf die Investition in das Marktplatzsystem nur maximal bei 10% der erwarteten Kostensenkung liegen. Das ärgert und enttäuscht den Consultant natürlich. Am Ende ist jedoch wieder ein Marktplatzsystem weniger in den Roll-out gegangen. Was also tun? Können wir überhaupt das Quecksilber mit der grobmaschigen Aalreuse unserer Softwaresysteme einfangen? Am Anfang all dieser Überlegungen steht der Standard. Mal sind diese Überlegungen aggressiv-darwinistisch (z.B. xCBL vs. cXML), mal kooperativ-bürokratisch (z.B. ebXML), jedoch ist das Ziel das Gleiche: Weltherrschaft des einen und einzigen Standards xyzXML, oder der xyz- Marktplatzsoftware oder dem xyz-Prozessmodell oder, oder, oder. Wo man am Ende landet, ist dabei fast egal, der Weg ist vielmehr das Ziel, ganz wie beim Malefiz-Spiel: Wer kurz vor dem Ziel steht, wird durch Koalitionen der anderen abgeblockt und rausgehauen. Am Ende gewinnt jedoch auch beim Malefiz immer einer, jedoch kann der Prozess des Abblockens oder der Bildung immer wieder neuer Koalitionen erheblich an den Kräften zehren. Haben wir nicht alle schon mal nachts um zwei gesagt: "Wer bis um drei die meisten Figuren im Ziel hat, der hat gewonnen", um wenigstens noch einen Teil der Nacht schlafen zu können? Bei E-Marktplätzen geht das nicht so richtig. Was nützt uns xCBL, wenn wir noch keinen Standard für die "Envelopes" haben - d.h. für die "XML- Umschläge", in die eine Geschäftsnachricht als Nutzlast eingebettet ist? Was nützt uns die Standardisierung von Austauschformaten, wenn die Geschäftsprozesse zwischen Anbietern und Kunden zweier Branchen uneinheitlich sind? Was nützt die Standardisierung von Zahlungsverfahren, wenn die Synchronisation von Zahlungs- und Fulfillment-Transaktionen nicht gegeben ist? Überspitzt formuliert liegt das Dilemma der Marktplätze darin, dass erst ALLES standardisiert werden muss, bevor ein alle befriedigender ROI erreicht werden kann. Alles standardisieren? Da sträuben sich dem Marketingleiter die Nackenhaare! Er fragt nach dem noch verbleibenden Differenziator seines Unternehmens und seiner Produkte. "Qualität", "Lieferzeiten", "Vendor-managed Inventory" kommt ihm der Berater zu Hilfe. Aber die Geschäftsleitung ist schon überzeugt: "Wir warten erst mal ab!". Wie also diesen gordischen Knoten auflösen? Der Berater der Berater (Forrester Research) prognostiziert noch bis 2004 zwei parallele Entwicklungen - den der öffentlichen Marktplätze und den der "privaten Hubs". Die Ersten (z.B. eBay) standardisieren relativ einfache horizontale Prozesse und Schnittstellen für die Massen, die Zweiten (Covisint, Elemica etc.) wagen sich an komplexe vertikale Aufgaben im Supply-Chain-Bereich eines limitierten Teilnehmerkreises heran, häufig aber ohne über horizontale Standards zu verfügen. Bei diesen Halblösungen geht man davon aus, dass sie in ihren jeweiligen Kernbereichen ROI- verdächtig sind. Damit sind wir jedoch noch Meilen entfernt von der allumfassenden Marktplatz-Lösung Was für die Hardcore-Vertreter der Künstlichen Intelligenz in den sechziger und siebziger Jahren der "General Problem Solver" war, ist also heute für den engagierten Marktplatz-Ingenieur das alle Branchen, Prozesse und Informationen umfassende Super-Marktplatzsystem. Man kann einmal mehr nur konstatieren, dass wir erst am Anfang einer noch sehr langen Entwicklung stehen - dies ist attraktiv für die Wissenschaft und unbefriedigend für den Praktiker. Verglichen mit dem Malefiz-Spiel haben wir unsere ersten Steine gesetzt und Koalitionsversprechen ausgetauscht. Noch spannender wird es jedoch erst in etwa zwei bis drei Stunden, wenn der Endkampf um die horizontale Plattform entschieden ist und wir uns nicht mehr den Kopf über "xCBL vs. cXML" zerbrechen müssen. Beim "Marktplatz-Malefiz" kann diese Stunde jedoch Jahrzehnte dauern ...
Michael Merz HMD, Heft 223, Februar 2002 |
|||||||
 |
|
 |
|||||
|
|||||||
![- Feedback an den Herausgeber]](/grafiken/feedback.png "Feedback an den Herausgeber senden"){kind=small}
