Volker Gruhn, Lothar Schöpe

Universität Dortmund

Die Entwicklung von Electronic-Commerce-Systemen (ECS) ist eine neue Herausforderung sowohl an DV- und IT-Abteilungen von Unternehmen verschiedener Branchen als auch an Softwarehäuser selbst.

In den DV- und IT-Abteilungen der Unternehmen werden bisher konventionelle branchenspezifische Anwendungssoftwaresysteme entwickelt, weiterentwickelt oder angepasst. Hierzu werden konventionelle Methoden, Werkzeuge und Programmiersprachen während eines Softwareentwicklungsprozesses eingesetzt. Auch dieser Softwareentwicklungsprozess folgt einer konventionellen Aufgabenteilung von den beteiligten Rollen, z.B. iteratives und inkrementelles Vorgehen bei der Durchführung von Tätigkeiten in verschiedenen Phasen durch den Systemdesigner, den Entwickler und den Programmierer oder anderen Rollen.

Da sich die Gegebenheiten des Marktes laufend ändern, müssen in Unternehmen die bestehenden Anwendungssoftwaresysteme angepasst oder neue zusätzliche Anwendungssoftwaresysteme entwickelt werden. Electronic-Commerce-Systeme bilden eine Klasse dieser neuen Softwaresysteme. Die DV- und IT-Abteilungen müssen sich diesen neuen Herausforderungen mit neuen Methoden, Konzepten und Verfahren auf der Basis eines angepassten Softwareentwicklungsprozess stellen.

Als Electronic Commerce wird jede Art von geschäftlichen Transaktionen (Marktvorgängen) bezeichnet, bei denen Geschäftspartner (Anbieter und Kunden) auf elektronischem Weg über ein Datenkommunikationsnetz miteinander verkehren. Sie umfassen die Verkaufsförderung, Verkaufsdurchführung, Distribution und Verkaufsnachbereitung für Produkte und Dienstleistungen. Produkte und Dienstleistungen im Sinne des Electronic Commerce (die auch elektronisch distributiert werden können) sind Finanzdienstleistungen (Versicherungen, Aktien, Fonds, etc.), Computerprogramme (Software, Shareware), Kulturgüter (Eintrittskarten, Zeitschriften, Magazine, Bücher, Videofilme, Musik-CD‘s) und Reisen (Fahr-, Flug- und Fährkarten, Hotels, Ferienhäuser).

Je nach Art des Geschäftspartners wird Electronic Commerce in "Business-to-Consumer (B2C) Electronic Commerce" und "Business-to-Business (B2B) Electronic Commerce" unterschieden. Der Unterschied liegt darin, dass bei B2C der Kunde einer geschäftlichen Transaktion ein Endverbraucher ist, während bei B2B der Kunde ein Unternehmen oder eine Behörde ist.. In beiden Fällen wird davon ausgegangen, dass ein Unternehmen als Anbieter agiert. Electronic-Commerce-Systeme unterstützen die jeweiligen Geschäftspartner bei der elektronischen Abwicklung ihrer geschäftlichen Transaktionen. Die Electronic-Commerce-Systeme, die zur elektronischen Unterstützung von geschäftlichen Transaktionen eingesetzt werden sollen, unterscheiden sich technisch hinsichtlich

• ihrer Client/Serverarchitektur (n-Tier),
• ihres Kommunikationsnetzes (Telefon, GSM, LAN, WAN, VPN),
• ihrer Netztopologie (Stern, Netz, Bus),
• ihrer Netzdistribution (zentral, dezentral),
• ihres Kommunikationsprotokolls (EDI, HTTP, SMTP),
• ihres Kommunikationsdienstes (WWW, FTP, MAIL),
• ihres Sicherheitskonzepts (einfache oder hybride Kryptografie).

Bei Electronic-Commerce-Systemen, die B2C unterstützen, werden Katalogsysteme, Shopsysteme, Auktionssysteme, Ausschreibungssysteme, etc. unterschieden. Einige der genannten Systeme können weiterhin in aktive und passive Systeme klassifiziert werden. In aktiven Systemen wird z.B. durch sog. Softwareagenten versucht, das entsprechende Ziel zu erreichen, z.B. das preisgünstigste Produkt, welches in verschiedenen Shopsystemen angeboten wird, zu finden. Bei den passiven Shopsystemen übernimmt der Kunde diese Aufgabe. Zu den passiven Systemen zählen die Electronic-Commerce-Portale, durch die eine Menge von einzelnen Electronic-Commerce-Anwendungen und Internet-Anwendungen kundenspezifisch zusammengestellt werden. Wenn als Kunde ein Unternehmen (B2B) agiert, dann werden EDI-Systeme, Warenwirtschaftssysteme (WWS) etc. unterschieden. Electronic Commerce Systeme, die bzgl. der Art eines Kunden nicht unterscheiden sind z.B. Home-Banking-Systeme oder Tracking-Tracing-Systeme.

Nicht alle der genannten Electronic-Commerce-Systeme unterstützen alle Marktvorgänge elektronisch, so wird z.B. vorrangig die Verkaufsförderung und die Verkaufsdurchführung durch die verschiedenen Arten von Katalogsystemen und Shopsystemen unterstützt. Bei EDI-Systemen oder gekoppelten WWS steht nicht die Verkaufsförderung oder die Verkaufsnachbereitung im Vordergrund, sondern im engeren Sinne die Verkaufsdurchführung. Electronic-Commerce-Systeme, die sich ausschließlich mit der Verkaufsförderung und der Verkaufsnachbereitung befassen, ohne selbst Produkte oder Dienstleistungen anbieten, sind Systeme, die ausschließlich Informationen, z.B. Nachrichten, Börseninformationen, Wetterdaten, etc., anbieten. Bei diesen Systemen erfolgt die Verkaufsförderung und Verkaufsnachbereitung durch Werbung mittels E-Mails, Diskussionsforen, Newsletter oder Banner. Home-Banking-Systeme unterstützen ausschliesslich die Zahlungsdurchführung während der Verkaufsdurchführung.

Ebenso wie die Entwicklung von konventionellen Anwendungssoftwaresystemen entsprechend eines Softwareentwicklungsprozesses erfolgt, wird ein Entwicklungsprozess benötigt, der die Entwicklung von Electronic-Commerce-Systemen beschreibt. Ein einfacher konventioneller Softwareentwicklungsprozess umfaßt mindestens die Phasen Anforderungsanalyse, Systemdesign, Systementwurf, Implementierung, Test und Betrieb/Wartung.

Die Softwareentwicklungsprozesse für Electronic-Commerce-Systeme unterscheiden sich von den Softwareentwicklungsprozessen für konventionelle Anwendungssoftwaresysteme partiell hinsichtlich

• der Rollen, die Tätigkeiten durchführen,
• der Softwarewerkzeuge, die von Rollen verwendet werden,
• der Art der Tätigkeiten, die durch Rollen durchgeführt werden.

Beispielsweise hat die Rolle Vertrieb hat bei Softwareentwicklungsprojekten, in denen ein konventionelles Anwendungssoftwaresystem entwickelt wird, in der Regel nur die Aufgabe eine Dienstleistung (Erstellung eines Softwaresystems) zu verkaufen und damit das Projekt zu initiieren. Während konventionelle Anwendungssoftwaresysteme in der Regel kein Marketinginstrument darstellen, sondern lediglich dem Vertrieb zur Akquirierung neuer Kunden dienen, stellt ein Electronic-Commerce-System in Teilbereichen ein Marketinginstrument dar. Aus diesem Grund ist die Rolle Marketing in der Phase Anforderungsanalyse an der Zielbestimmung erheblich beteiligt. Während konventionelle Anwendungssoftwaresysteme ihre Akzeptanz im wesentlichen über die Funktionalität bei einem Benutzer erreichen und sich so im Wettbewerb am Markt positionieren lassen, kann eine spezielle Klasse von Electronic-Commerce-Systemen (in diesem Beispiel Shopsysteme) ihre Akzeptanz bei einem Benutzer (Kunden) nur über die Benutzungsoberfläche erreichen. Zur Benutzungsoberfläche zählt neben dem Layout ebenso die Benutzerführung und die Benutzerunterstützung. Die Akzeptanz eines Shopsystems wird auch wesentlich über die Aktualität geprägt. Die Aktualität umfasst nicht nur die Inhalte selbst, sondern im wesentlichen auch die Darstellung der Inhalte.

In konventionellen Anwendungssoftwaresystemen werden Daten verschiedener Typen und Strukturen in unterschiedlicher Art und Weise verwaltet und verarbeitet. Die Aktualität des Systems steigt mit der Menge der Daten, die durch das Anwendungssoftwaresystem verwaltet werden.

Im Gegensatz dazu muß die Aktualität eines Shopsystems durch die Darstellung der Inhalte realisiert werden. Das bedeutet, daß der Datenbestand in der Regel unverändert bleibt, lediglich die Darstellung und Präsentation unterliegt im Laufe der Zeit einer Veränderung. Die Funktionalität eines Shopsystems bleibt in der Phase Betrieb/Wartung weitgehend unverändert, während durch Spezialisten für Softwareergonomie, Didaktik, Grafikdesign und Psychologie in regelmäßigen zeitlichen Abständen die Darstellung der Inhalte angepasst und modifiziert wird. Durch eine Vielzahl von Statistiken kann ein Akzeptanzgrad seitens des Kunden (i.d.S. ein Endverbraucher) ermittelt und über die Zeit verfolgt werden. Aus diesen Statistiken kann abgeleitet werden, welche Darstellungen angepasst werden sollten.

Auf der Basis einer Entscheidung wie ein Electronic-Commerce-System erworben und durch einen Anbieter eingesetzt wird ("Make-Buy-or-Rent"), werden die Rollen bestimmt, die in der Anforderungsanalyse innerhalb des Softwareentwicklungsprozesses beteiligt sind. Hier werden die Rollen Hersteller, Anbieter, Betreiber und Kunde unterschieden. Ein Hersteller entwickelt und vertreibt (direkt oder indirekt) ein Softwaresystem mit dem ein Betreiber ein Electronic-Commerce-System realisieren kann. Ein Anbieter nutzt ein Softwaresystem mit dessen vorgegebenen Funktionalitäten, um ein Electronic-Commerce-System entsprechend seiner definierten Zielbestimmung zu realisieren. Ein Anbieter kann sich auch entscheiden, ein individuelles Electronic-Commerce-System durch eigene Softwareentwicklung zu erstellen. Ein Betreiber stellt die soft- und hardwaretechnische Infrastruktur zum Betrieb des Electronic-Commerce-Systems zur Verfügung. Ein Betreiber kann z.B. für Shopsysteme ein Internet-Service-Provider (ISP) oder für EDI-Systeme ein Clearingcenter (CC) sein. Ein Betreiber kann ebenfalls ein Anbieter sein. Der Kunde nutzt das Electronic-Commerce-System, um im Rahmen der Möglichkeiten des Electronic-Commerce-Systems Markvorgänge mit einem Anbieter elektronisch durchzuführen. Je nach Art des Vorgehens werden innerhalb des Softwareentwicklungsprozesses von den verschiedenen Rollen unterschiedliche Softwarewerkzeuge eingesetzt, z.B. komplexe Softwaresysteme wie Intershop, Openshop oder Pirobase, etc. oder Softwareentwicklungs-/Programmierumgebungen, wie JDK, etc.

Durch die Vielzahl von Softwaresystemen, die die Realisierung von Electronic-Commerce-Systemen ermöglichen, bekommt die Tätigkeit der zielorientierten Systemanalyse, -bewertung und -auswahl während der Phase Anforderungsanalyse eine entscheidende Bedeutung. Während bei einem gekauften Shopsystem sowohl die Inhalte als auch die Art der Darstellung der Inhalte durch den Anbieter (der dann auch als Betreiber fungiert) erfolgen muß, erfolgt bei einem gemieteten System lediglich die Zusammenstellung der Inhalte durch einen Anbieter. Bei gemieteten Electronic-Commerce-Systemen stellt der Betreiber die Hardware und die Netzinfrastruktur für den Betrieb des Electronic-Commerce-Systems zur Verfügung und auch das Software-Werkzeug, mit dem das Electronic-Commerce-Systems realisiert wird. Da es in dieser Konstellation Ziel eines Betreibers ist, seine Infrastruktur (Hardware, Netzwerk, Software-Werkzeug) einer Menge von Anbietern zur Verfügung zu stellen, um seine Rentabilität zu steigern, wird in der Regel auch nur ein Softwarewerkzeug eingesetzt, um für die Menge der Anbieter Electronic-Commerce-Systeme zu realisieren. Die Konsequenz daraus, dass der Aufwand für die Realisierung eines Electronic-Commerce-Systems für den Anbieter und den Betreiber reduziert werden kann, geht jedoch zu Lasten der Individualität in der Darstellung der Inhalte der einzelnen Anbieter.

Die Tätigkeiten, die die Auswahl der Inhalte als auch die Art der Darstellung der Inhalte betreffen, werden der Phase Systemdesign zugeordnet. Diese Tätigkeiten sind in einem konventionellen Softwareentwicklungsprozess nicht enthalten. Die Rollen, die diese Tätigkeiten durchführen sind Spezialisten für Softwareergonomie, Didaktik und Grafikdesign sowie Psychologen.

Für den Fall einer Integration in eine bestehende Infrastruktur müssen Methoden, Konzepte und Softwarewerkzeuge zur Integration bereitgestellt und verwendet werden. Ebenso ist zu unterscheiden, ob Marktvorgänge für Produkte oder Dienstleistungen durch ein Electronic Commerce System elektronisch unterstützt werden sollen. Bei der Unterstützung für Produkte muss das Electronic Commerce System mit einem geschlossenen oder offenen Warenwirtschaftssystems eines Anbieters integriert werden. Eine Integration mit konventionellen branchenspezifischen, hochgradig individuellen Anwendungssoftwaresystemen muß in der Regel bei der Unterstützung von Marktvorgängen für Dienstleistungen erfolgen.

Diese individuellen Anwendungssoftwaresysteme befinden sich bei Versicherungen, Banken, etc. im Einsatz. Dagegen werden Warenwirtschaftssysteme oft durch ERP-Systeme verschiedener Softwarehersteller (SAP, ORACLE, BAAN, SAGE, PeopleSoft, etc) angeboten. Diese ERP-Lösungen bieten Schnittstellen (API's) zur Integration mit anderen Softwaresystemen an. So werden z.B. integrierte Lösungen zwischen Intershop und SAP, Openshop und SAGE bzw. ORACLE angeboten.

Unter Umständen ist sogar eine Integration von mehreren verschiedenen WWS oder individuellen Anwendungssoftwaresystemen erforderlich. Dies tritt der Regel bei der Implementierung von Electronic-Commerce-Malls oder Electronic-Commerce-Portalen auf. Eine Integration von Systemen kann jedoch ganz oder teilweise entfallen, wenn das Konzept der Lieferung "Just-in-Time" verfolgt wird. Dann erfolgt die Integration nicht auf der Ebene der Systeme oder Softwarewerkzeuge, sondern durch die Ebene der Benutzungsoberfläche eines Electronic-Commerce-Systems.

Die Methoden, Konzepte und Softwarewerkzeuge zur Integration sowie die beteiligten Rollen sind je nach Art und Weise der Integration unterschiedlich, z.B. können Sicherheitsaspekte (Firewall, Kryptographie, etc.) zu berücksichtigen sein. Diese Sicherheitsaspekte müssen nicht nur während der Implementierung u.U. berücksichtigt werden, sondern auch bei dem Systementwurf und Systemdesign eines Electronic-Commerce-Systems. Insbesondere bei der Verkaufsförderung und der Verkaufsnachbereitung gilt es dynamische Kundenprofile zu verwalten. Es bieten sich hierfür verschiedene Techniken an (Cookies, URL-Enkoding, serverbasierte Profile, etc.), die es rechtzeitig unter Berücksichtigung gesetzlicher Vorgaben und technischen Gründen auszuwählen gilt.

Allein aus diesen exemplarischen Betrachtungen kann man erkennen, dass Softwareentwicklungsprozesse für Electronic-Commerce-Systeme sich inhaltlich und strukturell von traditionellen Softwareentwicklungsprozessen unterscheiden. Dies veranlasst zu der Vermutung, dass für die Entwicklung von Electronic-Commerce-Systemen, neue oder angepasste Entwicklungsprozesse, Projektmanagementverfahren und Methoden, Konzepte und Werkzeuge erforderlich und zu verwenden sind.