In den Hype-Zeiten vor dem grossen Dotcom-Crash waren Application Service Provider (ASP) in aller Marketing-Munde. Software-Dienste als jederzeit und nach Bedarf verfügbare Ressource - analog zu Strom und Wasser - sei die Business-IT der nahen Zukunft, wurde damals gepredigt. Auch die Analysten und die «unabhängigen» IT-Berater hauten damals in diese Kerbe. So prognostizierten die Unternehmensberater von Booz Allen & Hamilton im Jahr 2000 ein weltweites Wachstum der ASP-Umsätze von 2,7 Milliarden Dollar 1999 auf 22,7 Milliarden 2003.
Nach der geplatzten Dotcom-Blase mag heute niemand mehr so recht von ASP reden. Das aktuelle Zauberkürzel lautet SaaS (Software as a Service). Gemeint ist damit allerdings dasselbe. Und wieder errechnen Marktforschungsfirmen emsig Wachstumszahlen. So kommt IDC zum Schluss, dass 2004 weltweit 4,2 Milliarden Dollar mit SaaS umgesetzt wurden - und dass dieses Volumen bis 2009 auf 10,7 Milliarden anwachsen soll.
Wie immer man die genannten Zahlen beurteilen will, klar ist, dass Booz Allen & Hamilton im Jahr 2000, vom Hype geblendet, völlig daneben lagen. Der Grund: Unzählige ASP haben den Crash nicht überlebt - und all die potentiellen Anwender hatten offenbar zu wenig Vertrauen in deren Geschäftsmodelle. Dass mit ASP und SaaS dasselbe gemeint ist - was die Verwirrung auf Seiten der Anwender nicht gerade mildert - beweist die Tatsache, dass IBM unlängst das kalifornische Unternehmen Corio für immerhin 182 Millionen Dollar übernommen hat. Corio hat das ASP-Debakel überlebt - und gilt heute als einer der wichtigsten SaaS-Anbieter.
Kostenaufteilung bei einem reinen ASP
Es stellt sich also die Frage, was die ASP falsch gemacht haben - und was die SaaS-Anbieter unbedingt besser machen müssen, um erfolgreich sein zu können. In einem ersten Schritt geht es sicher darum, den potentiellen Anwendern die verschiedenen (ASP-) - oder eben (SaaS-) - Ansätze detailliert klar zu machen. Entscheidend ist in diesem Zusammenhang das Pricing, genauer die verschiedenen Pricing-Modelle und -Stufen. Damit Unternehmen auf ASP-Dienste aufspringen, müssen ihnen klar erkennbare Preisvorteile geboten werden.
Auf der anderen Seite ist es für einen ASP von existenzieller Bedeutung, dass er selber genau weiss, welche seiner SaaS-Dienste profitabel sind - und welche eben nicht. Dass die ASP-Pioniere der Hype-Zeiten in dieser Hinsicht zu optimistisch waren und ihre Pricing-Modelle zu wenig detailliert ausgearbeitet hatten, ist mit ein Grund für ihr Massensterben.
Wie kompliziert und heikel es für einen ASP ist, die richtigen Berechnungen sowohl für sich als auch für seine Klientel anzustellen, belegt schon die ASP-Analyse von Booz Allen & Hamilton. Zum einen werden darin die Provider in drei Kategorien unterteilt. Die erste bilden Softwarehersteller, die ihre Ware als ASP-Angebote direkt an die Endkunden liefern. Die zweite setzt sich aus den sogenannten Infrastruktur-ASP zusammen, die über eigene Rechenzentren verfügen und diese neben dem herkömmlichen Applikations-Hosting auch für ASP-Zwecke nutzen wollen. Die dritte Kategorie bilden die «Pure Play ASP», die weder Applikationen noch Infrastruktur besitzen und als rein vermittelnde ASP operieren. Die erwähnte Corio, die jetzt von IBM übernommen wurde, gehört in diese Kategorie.
Sodann gruppieren die Analysten von Booz Allen & Hamilton die ASP gemäss ihrer Kundenfokussierung in KMU-, Grossfirmen- und vertikal orientierte Anbieter. Für die Berechnung seiner Kosten, Umsätze und Gewinnchancen muss jeder einzelne ASP genau eruieren, wie seine Wertschöpfungskette aussieht und wie die einzelnen Glieder dieser Kette gewichtet werden müssen.
Booz Allen & Hamilton unterscheiden dabei zwischen den folgenden Ausgaben-Typen:
•
Solutions-Provisioning-Ausgaben: die Kosten für die Rechte an den Applikationen, die angeboten werden sollen;
•
Solutions-Distribution-Ausgaben: die Gebühren für den Betrieb der Applikationen in einem Rechenzentrum und für deren Lieferung über ein Netzwerk;
•
Service-Integration-Ausgaben: die Gebühren für professionelle Dienstleistungen wie die Integration, Anpassung und Konfiguration der Applikationen;
•
Ausgaben für die Benutzerschnittstelle und die Verwaltung, also die Kosten für Kundendienst, -support und –ausbildung sowie für Verkauf und Marketing, Forschung und Entwicklung sowie Administration.
Bezogen auf die erwähnten «Pure Play ASP», also die reinen ASP, kommt Booz Allen & Hamilton zum Schluss, dass diese auf der Kostenseite 43 Prozent für Benutzerschnittstelle und Verwaltung, 26 Prozent für Service-Integration, 24 Prozent für Solutions Distribution und 7 Prozent für Solutions Provisioning ausgeben sollten (siehe Grafik). In ihrem Resüme gelangten die Berater damals zur Erkenntnis, dass die wenigsten ASP wirklich profitabel operieren konnten.
Auf theoretischer Ebene noch tiefer zielt die Untersuchung «Pricing in the Service-Oriented IT World», die Michael R. Werder 2004 als Master's Thesis in Computerwissenschaften am Institut für Informatik der Universität Zürich eingereicht hat. Im Kapitel zum ASP-Pricing schickt er gleich voraus, dass diesbezüglich nur sehr wenige wissenschaftliche Publikationen verfasst wurden. Neben der Studie «Optimal Pricing Policies of Web-Enabled Application Services» von Hsing Kenneth Cheng und Gary
J. Koehler aus dem Jahr 2002 erwähnt Werder ebenfalls das oben aufgezeigte Kostenstruktur-Modell von Booz Allen & Hamilton.
Er kommt in seiner Arbeit zum eher ernüchternden Schluss, dass sich beim ASP-Pricing eine riesige Diskrepanz zwischen der Komplexität von theoretischen Modellen - etwa demjenigen von Cheng - und den Preis-Schemata in der Praxis auftut. Hier dominieren vergleichsweise simple Einheitsgebühren-Abrechnungen pro Monat (Fixed-fee model). Des weiteren konstatiert Werder pro-Benutzer-, pro-Transaktion- und umsatzabhängige Modelle. Alle diese Methoden sind einigermassen hemdsärmlig und möglicherweise zu wenig flexibel, um ASP-Dienste im grossen Rahmen attraktiv zu machen. Werder fragt sich deshalb, ob der eklatante Mangel an theoretischen ASP-Pricing-Modellen der gesamten Branche geschadet hat – und weiter schadet. Man darf getrost davon ausgehen, dass dem so ist - auch dann, wenn sich die Anbieter heute nicht mehr ASP, sondern SaaS-Spezialisten nennen.
Die Architektur einer ASP-Applikation
