ecommerce CONTROLLING-SCHWERPUNKT CONTROLLING-WISSEN CONTROLLING-CASE STUDY CONTROLLING-DIALOG

Transkript

1 B /2013 Controlling-Schwerpunkt ecommerce CONTROLLING 6 Juni Herausgegeben von Prof. Dr. Dr. h.c. mult. Péter Horváth, Prof. Dr. Thomas Reichmann, Prof. Dr. Ulrike Baumöl, Prof. Dr. Andreas Hoffjan, Prof. Dr. Klaus Möller, Prof. Dr. Burkhard Pedell +++ Aktuell: Managementkonzepte schlagen Offshoring und Co. +++ ecommerce CONTROLLING-WISSEN CONTROLLING-CASE STUDY CONTROLLING-DIALOG Jahrgang Verlage C.H.Beck Vahlen München Frankfurt a. M. E-Business Geschäftsmodelle und -prozesse in der Net Economy Kollmann Ganzheitliche Betrachtung von Marketingmaßnahmen im E-Commerce Schwinn Agilität als Erfolgsfaktor im Projekt-Controlling von Multichannel-Business n Jene Der Einfluss von Social Media-Anwendungen auf E-Commerce-Auftritte Kruse Corporate Governance und Controlling Ergün/Müller/Panzer Jetzt mit Controlling Archiv auf Mehrwerte und Erfolgsdeterminanten mobiler BI-Lösungen für die Unternehmenssteuerung Wehrum/Heinrich Green Hansgrohe Gänßlen/Frey Betriebswirtschaftliche Steuerung des Bistums Augsburg Heinrich/Donaubauer/Horváth CONTROLLING-COMPACT Interne Verrechnungspreise Funktionen und Gestaltung Steinmann

2 299 Nicolas Jene ist Senior Project Manager und verantwortlich für die Umsetzung von Multichannel n und Programmen bei foryouandyourcustomers AG, Pfäffikon ZH (Schweiz). nij@ foryouandyourcustomers.com Agilität als Erfolgsfaktor im Projekt- Controlling von Multichannel-Business n Nicolas Jene Projekt-Controlling für Multichannel- ist durch den hohen Innovationsgrad sowie Schnelligkeit dieser vor ganz besondere Aufgaben gestellt. So muss ein entsprechendes Projektvorgehen gewählt werden, dass den Anforderungen gerecht wird. Der Beitrag zeigt auf, wie mit dem entsprechenden Vorgehensmodell eine erfolgreiche Projektsteuerung etabliert werden kann. Stichwörter Agilität Funktionales Projektmanagement Multichannel- Projekt-Controlling Scrum 1. Das Berlin-Prinzip rfolg ist auch in Zeiten etablierter Projektmethoden kein Garant. Gerade zurzeit sind die Medien wieder stark mit katastrophal in Schieflage geratenen Großprojekten gefüllt. Auch für deutlich kleinere ist das Projektmanagement zentraler Erfolgsfaktor und das gilt in besonderem Maße auch für im Multichannel-Bereich. Diese, die häufig im Umfeld des E-Commerce zu finden sind, zeichnen sich durch besondere Anforderungen aus: Das Projektziel muss den Anforderungen verschiedener Medien und damit auch durchaus verschiedener Nutzergruppen gerecht werden. Gleichzeitig ist den Spezifika der Produkte im Kontext ihrer Medieneignung Rechnung zu tragen und sind die unterschiedlichen Betriebsformen zu berücksichtigen. Eingebettet sind die in einem sehr schnelllebigen Kontext, der eine hohe Änderungsbereitschaft, d. h. Agilität, in der Steuerung voraussetzt. Also eine Herausforderung für das Projektmanagement und -controlling, die nachfolgend näher untersucht werden soll. Auch wenn Großprojekte in Bezug auf Komplexität und Reichweite einige Besonderheiten haben, können sie doch als Lehrstück für andere dienen. Die Verschiebung des Starttermins für den Flughafen Berlin-Brandenburg ist so ein Lehrstück. In diesem Umfeld wurde der Begriff des Berlin-Prinzips (oder auch Pippi-Langstrumpf-Prinzip) geprägt. Die Begründung für die Verschiebung war der unzureichende Brandschutz im Gebäude. Die Kommunikation fand dazu knapp einen Monat vor dem geplanteneröffnungsterminam3.juni 2012 statt. Und des Weiteren ließ Klaus Wowereit in der Süddeutschen Zeitung verlauten, die pünktliche Inbetriebnahme sei an ein paar Wochen gescheitert, jetzt seien aber noch zehn Monate nötig, weil vieles, was mit Termindruck möglich gewesen wäre, ohne Termindruck nicht möglich ist. (o. V., 2012a). Offenbar liegt hier ein klarer Fall von Versagen im Bereich des Projektmanagements oder genauer, des Projekt-Controllings vor. Planung, Steuerung und Kontrolle des Projekts waren nicht aufeinander abgestimmt, oder aber die entsprechenden Warnungen, welche durch die Projektleitung oder das Kernteam kommuniziert wurden, fanden nicht die notwendige Beachtung. Bei der schieren Größe eines solchen s ist es jedenfalls kaum vorstellbar, dass erst ganz kurz vor Abschluss des Projekts respektive dem Start des Flughafens plötzlich alle Stricke reißen und eine Verschiebung von fast einem Jahr daraus resultiert. Im Forum des deutschen ProjektMagazins wurde diese Aussage intensiv diskutiert (vgl. o. V., 2012b). Unter anderem wurde vorgeschlagen, das Geschehene als Berlin-Prinzip zu benennen, welches sich durch folgende drei Prinzipien auszeichnet: Termine werden verhandelt, nicht berechnet. Verhandelte Terminen werden so lange mit Druck durchgeboxt, bis eine der beteiligten Parteien aufgibt. 25. Jahrgang 2013, Heft 6

3 300 E-COMMERCE Abb. 1: Planung, Steuerung und Kontrolle (in Anlehnung an Litke, 2007, S. 83) Die Verlierer werden aus dem Projekt entlassen und ein neuer Termin wird verhandelt. Die Prinzipien sind nur allzu häufig, vor allem auch in Multichannel-n, zu finden und setzen etablierte und zertifizierte Projektmanagement-Methoden z. T. außer Gefecht; der rfolg ist gefährdet. Der vorliegende Beitrag setzt sich konsequenterweise mit dem Thema des Berlin- Prinzips im Projektmanagement und -Controlling auseinander und hat zum Ziel, erfahrungsbasiert, ein Vorgehen für Multichannel- vorzuschlagen. 2. Der Projektkontext Multichannel Der Begriff Multichannel wird vor allem im Bereich des Retailing oder Marketings genutzt. Als Kanäle werden hierbei nicht nur der gewöhnliche Point-of-Sales (POS) bezeichnet, sondern auch heute sehr stark genutzte Medien wie Fernsehen, Radio, Internet oder z. B. Werbebroschüren. Vor 20 Jahren war der Kaufprozess noch auf wenige Kanäle und damit Berührungspunkte (sogenannte Touchpoints) zwischen Kunde und Anbieter beschränkt. Der Weg von der Intention, ein Produkt zu kaufen bis hin zum Kaufakt selber, spielte sich vor allem in den klassischen Kanälen ab (Besuch einer Filiale, Artikel in Zeitung oder Fachzeitschrift lesen, persönliches Gespräch mit einem Verkäufer etc.). Das Einkaufsverhalten oder eine typische Customer Journey in heutiger Zeit offenbart eine weitaus höhere Anzahl an verwendeten Touchpoints, welche zwischen den klassischen Kanälen und den digitalen Kanälen (Internet, Social Media, Instant Messaging) wechseln. Dieses Verhalten ist nicht nur auf den Businessto-Consumer (B2C)-Bereich (Handelsbeziehung zwischen Unternehmen und Privatpersonen) beschränkt, sondern gilt, wenngleich in etwas eingeschränkterem Maße, auch für den Business-to-Business (B2B)-Bereich (Handelsbeziehungen zwischen Unternehmen). Als Konsequenz kann festgehalten werden, dass Multichannel-Business bedeutet, mit einer außerordentlich hohen Zahl an Möglichkeiten zu jonglieren, um mit dem Kunden zu kommunizieren oder in Kontakt zu treten. Ein Nebeneffekt dabei ist die Beschleunigung der Customer Journey. Diese Beschleunigung führt zwangsläufig auch bei der Umsetzung von Multichannel-n zu einer entsprechenden Beschleunigung. Grundlegend basiert das Multichannel-Business auf dreiteilen(vgl. Möller et al., 2012): Das Benutzerorientierte:Benutzerorientierung schlägt sich in den Kanälen bzw. Touchpoints nieder, welche für den Kunden gebaut werden. Im Generellen ist hier auch das GUI (grafisches Benutzerinterface) eines Multichannel-Systems betroffen. Dieser Bereich ist Veränderungen in weitaus höherem Maße unterworfen als die anderen Bereiche. Das Grundlegende: Hiermit sind die Daten und Strukturen, welche die BasisfürdasGeschäftdarstellen(meistens die Daten eines Warenwirtschaftssystems oder des im Multichannel- Business so wichtigen PIMs Product Information Management Systems) gemeint. Veränderungen in diesem Bereich passieren vielleicht alle 20 Jahre. Das Verbindende: Hierunterfälltvor allem die Steuerung und Planung der Kanäle und damit im eigentlichen Sinne die Verbindung des Benutzerorientierten mit dem Grundlegenden, den Daten. Veränderungen in diesem Bereich sind etwas seltener als im Benutzerorientierten, der Einfluss ist jedoch grundlegend. Ein typisches Projekt im Bereich des Multichannel-Business zielt vor allem auf das Benutzerorientierte wie auch das Verbindende ab. Neue Kanäle wollen erschlossen werden und die Steuerung und Kontrolle der Kanäle und Touchpoints soll mit den bestehenden grundlegenden Daten verknüpft werden. Zumeist bestehen aber schon die grundlegenden Systeme (wie z. B. ein Enterprise Resource Planning (ERP)-System oder ein PIM), undesgehtvorallemumdieumsetzung neuer Kanäle und der dazugehörigen Prozesse, die Daten aus der Basis zu integrieren.immerhäufigerkommtesaber vor, dass die bereits seit Jahren eingesetzte Software-Basis nicht mehr mit den wachsenden Anforderungen der Prozesse undderkanälemithaltenkannundsomit aus einem Multichannel-Business- Projekt sehr schnell zusätzlich auch ein Software-Evaluations- und nachfolgend ein Migrationsprojekt wird (die bisherigen Datenspeicher müssen in neue überführt werden). Das alte Product Information System kann nicht mehr mit den gestiegenen Anforderungen mithalten und muss durch ein neues System ersetzt werden. Neben den einfacheren Frontend- Aufgaben im Projekt, welche sich mit der Umsetzung von Funktionalitäten im Bereich des Benutzerorientierten beschäftigen, gilt es zusätzlich auch, Daten von einem System ins andere zu überführen. CONTROLLING ZEITSCHRIFT FÜR ERFOLGSORIENTIERTE UNTERNEHMENSSTEUERUNG

4 Agilität als Erfolgsfaktor im Projekt-Controlling von Multichannel-Business n Steuerung von Multichannel- n Es ist einleuchtend, dass im Bereich des Multichannel-Business Time to market eine besondere Rolle spielt. Derjenige, der seine Kanäle und damit Touchpoints am schnellsten bedienen kann, hat einen nicht zu unterschätzenden Vorteil. Dies führt zurück zur Ausgangslage des Berlin-Prinzips, bei dem Termine nicht berechnet, sondern verhandelt werden. Dies ist gerade bei Multichannel-n ein gravierendes Problem, da sehr oft marketing- und vertriebsnahe Mitarbeitende in einem Unternehmen die Haupt- Treiber hinter Multichannel-n sind. Aufgrund des Verkaufsdrucks sind diese an schnellen Lösungen interessiert und verhandeln dabei Termine eher, als dass sie diese berechnet haben möchten ( denn am Tag X würde der Launch der neuen E-Commerce-Plattform am meistensinnmachen,dageradezudiesem Zeitpunkt eine spezielle und wichtige Kampagne läuft ). Facetten des Projekt-Controllings Multichannel- sind sehr oft klassische Software-Entwicklungsprojekte und daher bzgl. Planung, Steuerung und Kontrolle dem funktionalen Projektmanagement unterworfen (vgl. Abb. 1). Ein Blick auf verschiedene Studien, die sich mit dem Thema des Scheiterns von nbeschäftigen,allenvoranz.b. die CHAOS-Studie (z. B. o. V., 2010), zeigt, dass immer wieder folgende Punkte erwähnt werden: Unvollständige Anforderungen Wechselnde Anforderungen Politik, Egoismen und Kompetenzstreitigkeiten Unzureichende Projektplanung Schlechte Kommunikation Fehlende Projektmethodik oder fehlendes Risikomanagement Technologie-Überforderung (oder Mangel an qualifizierten Mitarbeitern) Die Themen wechseln sich dabei nicht grundlegend ab, sondern haben von Jahr zu Jahr nur eine unterschiedliche Gewichtung. Die grundlegenden Probleme werden durch die Studien offenbar erkannt und viele davon haben nicht direkt etwas mit Projekt-Controlling zu tun, können aber Einfluss auf die Planung, Steuerung und Kontrolle von n haben. So ergeben sich auf Basis der oben genannten drei Prinzipien des Berlin- Prinzips die folgenden Fragestellungen: Mit welcher Projektmethodik werden einem Unternehmen die entsprechenden Mittel zur Verfügung gestellt, um bei auftretenden Problemen im Projekt schnell und effizient handeln zu können? Welches Projekt-Vorgehensmodell erlaubt dabei die Etablierung eines effizienten Projekt-Controllings? Dabei spielt vor allem das Projekt-Controlling eine wichtige Rolle. Projekt-Controlling wird in vorliegendem Fall nicht nur als bloßes Steuerungsinstrument für die Kontrolle von n gesehen. Projekt-Controlling beinhaltet weitere Facetten, welche durch die gewählte Projekt-Methodik sowie der Art des Projekts besseroderschlechterabgedecktwerden. Die vier wichtigsten Facetten sind: Aufwand- und Kostenschätzung Qualitätsmanagement und -kontrolle Risikomanagement Changemanagement Diese vier Facetten des Projekt-Controllings sollen im Weiteren den entsprechenden Projektvorgehensmodellen gegenübergestellt und die Eignung für Multichannel- soll herauskristallisiert werden. 4. Vorgehensmodell für Multichannel- Bei den zu untersuchenden Vorgehensmodellen lässt sich eine grundlegende Trennung in klassische und agile Vorgehensmodelle vornehmen. Klassische Vorgehensmodelle Klassische Modelle zeichnen sich vor allem durch eine sequentielle Bearbeitung aller Phasen in einem Projekt aus. Die bekanntesten Vertreter solcher Modelle sind etwa das V-Modell (oder V-Modell 97 bzw. XT als neuere Versionen dieses Modells) sowie das Wasserfall-Modell. Gerade beim Wasserfall-Modell wird strikt top-down ein Baustein nach dem anderen abgearbeitet. Eine z. B. lauffähige Software wird erst zu einem späteren Zeitpunkt ausgeliefert und kann somit auch erst zu einem späteren Zeitpunkt im Projekt getestet werden. Dies birgt zwangsläufig einige Gefahren in sich, denn gerade Multichannel-sindeherdemTypPionier-bzw. Potenzialprojekte (vgl. Abb. 2) mit einer offenen Aufgabenstellung und teilweise höheren sozialen Komplexität zuzuordnen. Ein effizientes Projekt-Controlling bei klassischen Vorgehensmodellen im Bereich der Software-Entwicklung zu etablieren, scheint dabei eine vergleichsweise leichte Aufgabe zu sein. In der ersten Phase werden die entsprechenden Analysen vorgenommen und das Konzept des Projekts erarbeitet. Danach tritt das Projekt in die Umsetzungsphase ein, in der die spezifizierten Funktionen entwickelt werden. Am Schluss wird getestet. Eine wesentliche Herausforderung ist, wie bereits angedeutet, dass Multichannel- in der Regel stark durch marketingund vertriebsnahe Personen oder Abteilungen getrieben werden. Die Erwartungen der Zielgruppe an ein solches Projekt sind neben einer hohen Umsetzungsgeschwindigkeit, dass innovative Funktionen schnell zur Verfügung stehen und das look and feel klar wird. Die Machbarkeit von innovativen Funktionen bereits durch die erste Konzeption zu erhärten, ist aber bei einem klassischen Vorgehensmodell nicht immer gegeben oder dann mit hohen Zusatzkosten verbunden. Das Resultat des Projekts wird oft erst weit am Ende des s sichtbar. Dadurch steigt das Risiko, dass das Projekt nicht von den Auftraggebern akzeptiert wird oder teure Modifikationen vorgenommen werden müssen. Hier zieht danndiebekanntetatsache,dassänderungen zu einem späten Zeitpunkt im Projekt immer exponentiell teurer sind als Anpassungen im frühen Stadium des Projekts. Agile Vorgehensmodelle Agile Vorgehensmodelle (z. B. SCRUM, XP, Timeboxing) konnten sich im Rahmen von Projektmanagement-Ansätzen erst seit wenigen Jahren etablieren. Die Erfolge, die damit erzielt werden konnten, lassen allerdings aufhorchen. Neu sind agile Vorgehensmodelle nicht, aber es liegt in der Natur des Menschen, sich gegen nach außen chaotisch wirkende Strukturen zu wehren. Dabei sind Menschen in vielen Handlungssituationen 25. Jahrgang 2013, Heft 6

5 302 E-COMMERCE mit Dingen konfrontiert, welche Agilität erfordern. Schwaber (2004, S. xi) hat es treffend formuliert: It is amazing to me gross klein soziale Komplexität Akzeptanz- Standard- geschlossen Aufgabenstellung Pionier- Potential- offen Abb. 2: Typen von n (in Anlehnung an Kuster et al., 2008, S. 6) Geschäftsziele Anforderungen System Abb. 3: Von den Geschäftszielen zum System (in Anlehnung an Bleek/Wolf, 2008, S. 8) Systemeinsatz??? Test that thousands upon thousands of people travel by car every day, accomplishing their goals in a framework of simple traffic rules, with no central control or dispatching service. In den letzten Jahren hat sich der evolutionäre (agile) Entwicklungsprozess in der Projektabwicklung vermehrt durchgesetzt. Dies wohl auch aus dem Umstand heraus, dass alles menschliche Handeln Veränderungsprozessen unterworfen ist. Evolutionäre Methoden können auf neue Erkenntnisse im Entwicklungsprozess eingehen und sind flexibel genug, auf die Veränderungen im Prozess zu reagieren (vgl. Litke, 2007, S. 261). Die Logik von Evolutionsprozessen beruht auf den fundamentalen Elementen von Versuch und Irrtum, denn sie stößt in Geschäftsziele Anforderungen System Abb. 4: Systemeinsatz als Teil des Projekt-Controllings (in Anlehnung an Bleek/Wolf, 2008, S. 9) Abb. 5: Schematische Darstellung des SCRUM-Prozesses (entnommen aus Pichler, 2008, S. 7) Bereiche vor, über die noch keine Erfahrungen vorliegen (Litke, 2007, S. 261). Dasheißt,dassinndieTeammitglieder besonders intensiv zusammenarbeiten müssen, um sich bzgl. der Beurteilung der Lage und der Konzipierung des nächsten Projektschrittes einbringen zu können. Die daraus resultierende Flexibilität kann Schritt für Schritt zu einem Erfolgsfaktor für die Multichannel-Projektumsetzung werden. Bei der Softwareentwicklung gibt es immer ein klares Ziel: Durch die Entwicklung soll ein einsetzbares Software-System entstehen. Dieses Software-System soll aber nicht in irgendeiner Art und Weise funktionieren, sondern genau so, wie es spezifiziert wurde. Dies führt zu folgendem einfachen Schema (vgl. Abb. 3): Projekt-Controlling greift dabei an folgenden Fragen: Wurden die Geschäftsziele mit dem umgesetzten System erreicht? Genügt die Qualität des Systems? Sind die Anforderungen korrekt umgesetzt worden? Die Anforderungen selber und damit auch ein Teil der Qualität des Systems sind durch Tests abdeckbar. Ob die Geschäfts- und Projektziele erreicht wurden, kann zuverlässig nur durch den Einsatz des Systems getestet werden (vgl. Abb. 4). In diesem Vorgehen liegt auch klar der Vorteil einer agilen Projektmethodik, die so kürzere Anpassungszyklen erlaubt. Für die Umsetzung von Multichannel- n wird derzeit in den meisten Fällen SCRUM eingesetzt. SCRUM in Multichannel-n SCRUM gehört ebenfalls zu den agilen Methoden und ist sehr stark auf die Projektabwicklung und die Projektprozesse fokussiert. Schon nach der ersten Iteration bzw. in der Terminologie von SCRUM, dem ersten Sprint, wird ein lauffähiges Software-Inkrement (= Teil einer Software) entwickelt, an welchem bereits die Geschäfts- und Projektziele getestet werden können (vgl. Abb. 5). Anforderungen werden in grobgranulare Epics gepackt und diese wiederum in feingranularere User Stories unterteilt (ähnlich eines Use Cases, also einem möglichen Anwendungsfall in Bezug auf CONTROLLING ZEITSCHRIFT FÜR ERFOLGSORIENTIERTE UNTERNEHMENSSTEUERUNG

6 Agilität als Erfolgsfaktor im Projekt-Controlling von Multichannel-Business n 303 die Nutzung der Software). Die Gesamtheit der User Stories ergibt dann das sogenannte Product Backlog, welches als Summe aller Teile den Projektumfang ausmacht. Die Umsetzung wird wiederum in Sprints unterteilt. Hier haben sich im Bereich der Umsetzung von Multichannel- n zweiwöchige Sprints als ideale Zeitspanne herauskristallisiert. Pro Sprint wird mit dem Team gemeinsam vereinbart, welche User Stories aus dem Backlog genommen und ins Sprint Backlog für die Umsetzung gelegt werden sollen. Im sogenannten Planning Meeting wird der Aufwand anhand von Punkten pro User Story geschätzt und unter den Teammitgliedern gemeinsam abgestimmt. Im Vergleich zum Berlin-Prinzip wird nicht der Termin verhandelt, sondern der Inhalt. Dies ist der entscheidende Punkt, denn das Team stimmt im Planning Meeting einem gemeinsam definierten Umfang zu und verpflichtet sich zur Umsetzung der in den Sprint-Backlog aufgenommenen Funktionen. Verhandlung und Priorisierung sind also wichtige Elemente im SCRUM-Prozess, diese beiden Schritte sind aber nie einseitig zu betrachten, sondern sind stets ein Teamprozess. Im sogenannten Review Meeting werden die im Sprint umgesetzten Funktionen präsentiert und vom Product Owner abgenommen. Der Test der Geschäfts- und Projektziele ist damit permanent nach Abschluss eines Sprints möglich. Dass die Aufwandschätzung in (Komplexitäts-)- Punkten und nicht in Tagen definiert wird, mag dazu verleiten, die Schätzung als ungenau zu betrachten. Dieses System hat aber einen tieferen Sinn: Schätzungen sind am Anfang noch relativ ungenau und zwar solange, bis einige User Stories umgesetzt worden sind. Die Punktevergabe basiert dabei auf den vorangegangenen Erfahrungen in anderen n (als Vergleichsgröße wird die Komplexität für die Umsetzung verwendet). Außerdem werden noch offene User Stories mit bereits schon umgesetzten verglichen. Damit wird das Schätzresultat von Sprint zu Sprint genauer, und es besteht nach einigen Sprints sogar die Möglichkeit, User Stories in Personentage umzurechnen, um einen Eindruck von der gesamten Umsetzungszeit zu erhalten. Eine sogenannte Velocity (Geschwindigkeits)- Berechnung kann z. B. wie in Abb. 6 umgesetzt werden. Dabei sind die einzelnen Sprints (Date) und die verfügbare Kapazität des Teams definiert (Team Availability Days) sowie die geplanten und umgesetzten Story Points dokumentiert. Schwaber bemerkt dazu treffend: Every sprint review meeting makes visible the difference between estimates and reality and between what the team thought it could do and what it really did (2004, S. 73). Projekt-Controlling wirkt hier bereits direkt auf der Ebene des Teams, welches sich durch den Prozess selber kontrolliert. Eine Gesamtliste mit allen User Stories (also das Backlog) hilft zusätzlich dabei, eine erste grobe Abschätzung der Aufwände zu erstellen (diese kann bspw. in Personentagen erfasst werden). Die Liste muss bei der ersten Aufwandschätzung nicht vollständig sein, sollte aber die wichtigsten und auch aufwändigsten Epics und User Stories enthalten. Dieser Backlog aller umzusetzenden Funktionen (aufgeteilt in User Stories) ist dabei ein exzellentes Controlling-Instrument, um den Gesamtfortschritt im Projekt zu messen. Die ursprünglich bei einererstengrobenschätzungdefinierten Aufwände für jede User Story können während der Umsetzung immer wieder mit den ursprünglich geschätzten Aufwänden abgeglichen werden. 5. Fazit Abb. 6: Sprint-Kapazitätsplanung Pionier- und Potenzialprojekte als vorherrschende Projekttypen im E-Commerce-Bereich erfordern also ein spezifisches Projektvorgehen, damit sie erfolgreich gesteuert werden können. Bei einer Anwendung der weiter oben erwähnten vier Facetten eines Projekt-Controllings auf das SCRUM-Vorgehensmodell ergibt sich folgendes Bild: Aufwand- und Kostenschätzung: Eine grobe Kostenschätzung für das Gesamtprojekt ist von Anfang an möglich. Die Ungenauigkeit der Schätzung des Aufwands und damit auch der Kosten ist aber noch relativ hoch (und generell vergleichbar mit der Schätzung bei klassischen Vorgehensmodellen). Je mehr Sprints durchgeführt wurden, desto genauer können die Aufwände abgeschätzt werden. Da durch die Schätzung mittels Story Points vor allem auf die Komplexität im Vergleich mit anderen User Stories fokussiertwirdundnichtdirektauf den Aufwand, werden dem Projekt- Controlling von Sprint zu Sprint genauere Daten geliefert. Qualitätsmanagement und -kontrolle: Da bereits nach dem ersten Sprint eine ausführbare Software erstellt wird, kann die Qualität der Umsetzung Werden die Geschäfts- und Projektziele erreicht? jederzeit überprüft werden. Und dies von Anfang an. Bei einem klassischen Vorgehensmodell kann diese Überprüfung erst zu einem späteren Zeitpunkt stattfinden und dann sind die Kosten bei einer Änderung weitaus höher. Risikomanagement: Generell gibt es mehr Kontrollpunkte bei agilen Vorgehensmodellen wie SCRUM, da quasi Abb. 7: Mögliche Darstellung eines Backlogs für die Umsetzung eines Multichannel-Projekts 25. Jahrgang 2013, Heft 6

7 304 E-COMMERCE nach jedem Sprint ein Meilenstein erreicht ist, der auch getestet werden kann. Risiken lassen sich insofern minimieren, dass Probleme schon frühzeitig erkannt werden können. Change Management: Last, but not least, lassen sich gewünschte oder aber erforderliche Änderungen frühzeitig erkennen. Die Gefahr besteht hier allerdings, dass durch die stetige MöglichkeitdieSoftwarezutesten,mehr Änderungswünsche entstehen. Agilität im Sinne des SCRUM-Prozesses bedeutet nicht, beliebige Änderungen zuzulassen, welche dann in den gleichen Fertigstellungstermin münden. Vielmehr gibt die kontinuierliche Auslieferung von Software die Möglichkeit, zu verhandeln, welche Funktionalitäten wichtig sind und prioritär umgesetzt werden müssen. In diesem Sinne hat das Berlin-Prinzip mit SCRUM als Vorgehensmodell bei Multichannel- n keine Chance. Keywords Agility Functional project management Multichannel projects Project control Scrum Summary Project management for multichannel projects is facing several specific problems because of the high innovation degree and their demand for speed. An appropriate project methodology will help to establish a proper project control that delivers the right information at any time. This articles shows which project methodology will fit best. Literatur Bleek, W.-G./Wolf, H., Agile Softwareentwicklung, Heidelberg Kuster, J./Huber, E./Lippmann, R./Schmid, A./ Schneider,E./Witschi,U./Wüst,R., Handbuch Projektmanagement, 2. Aufl., Berlin/Heidelberg, Litke, H.-D., Projektmanagement. Methoden, Techniken, Verhaltensweisen, evolutionäres Projektmanagement, 5. Aufl., München Möller, J./Richard, J./Stadler, R. J.,Executive Summary zu Multichannel-Business, id ?mt=11, Stand: o. V., Flughafen Berlin soll erst im März 2013 öffnen, 2012a, wirtschaft/airport-berlin-brandenburg-flug- hafen-berlin-soll-erst-im-maerz-oeffnen , Stand: o. V., Der Mensch im Projekt: Führung, Selbstmanagement, Soziale Kompetenz, 2012b, forum/das-berlinprinzip, Stand: o. V., Chaos Summary for 2010, Summary.pdf, Stand: Pichler, R.,Scrum AgilesProjektmanagement erfolgreich einsetzen, Heidelberg Schwaber, K.,AgileProjectManagementwith Scrum, Redmond Literaturtipps aus dem Online-Archiv der CONTROLLING: Claudia Hienerth, Innerbetriebliche Kannibalisierung zwischen dem Onlinevertrieb und den stationären Landegeschäften Herausforderungen für das Controlling, Ausgabe 12/2006, S Hendrik Schröder und Gabriele Schettgen, Kundenbezogene Erfolgsrechnung im Multichannel Retailing, Ausgabe7/ 2004, S Jörg Link, CRM neue Perspektiven für das Marketing-Controlling, Ausgabe 10/2002, S CONTROLLING ZEITSCHRIFT FÜR ERFOLGSORIENTIERTE UNTERNEHMENSSTEUERUNG