< zur Übersicht

Vor dem Start eines Webshop-Projekts möchten Sie wissen, was es in Summe kostet und was wesentliche Kostenfaktoren sind? Das lässt sich nicht mit einem Satz beantworten. In diesem Artikel beleuchten wir alle wichtigen Faktoren.

 

Was sind Projektkosten?

Auch wenn Sie einen erfahrenen Dienstleister für Ihr Webshop-Projekt ausgesucht haben, also

• Aufwände für ein qualifiziertes Anforderungsmanagement sowie
• Aufwände für Konzeption und Design, Entwicklung und Test, Entwicklungssystem- und Testumgebungen

bekannt und „gedeckelt“ sind, sollten Sie die Ressourcen für die Kosten und Aufwände bei und nach Inbetriebnahme nicht vergessen:

Für einen „Total Cost of Ownership“-Ansatz sind als Projektkosten außerdem zu berücksichtigen:

• Lizenzkosten und Software-Wartungsgebühren je Server oder Nutzer beim Kauf von Standard Software,
• die Plattformkosten und Aufwände für Systembetrieb und -instandhaltung,
• ggf. Aufwände für Datenmigrationen aus dem Altsystem,
• eventuelle Datenbereinigung vor der Datenmigration,
• Redaktionsaufwände für Produktbeschreibungen, Produktbilder usw.,
• Anwenderschulungen für Webshop-Administratoren und -Redakteure sowie
• ggf. Benutzerhandbücher

Und wenn nach Inbetriebnahme die Shop-Redakteure zu komplexe Webshop-Prozesse und -funktionen beklagen, kostet das ebenfalls Zeit und damit Geld.

 

Was treibt die Projektkosten nach oben?

Es kann verschiedene Ursachen geben, warum das vereinbarte Projekt-Budget mitunter nicht eingehalten oder sogar erheblich überschritten wird. Schon vor dem Projektstart werden wesentliche Entscheidungen getroffen, wie z.B. die Software-Auswahl.

Software - Make or Buy

Besonders bei einer Eigenentwicklung der Software (Make), sollte man schon bei der Anforderungsaufnahme und -priorisierung Kosten und Nutzen der gewünschten Software-Funktionen und -Schnittstellen sorgfältig abwägen. Mitunter sind organisatorische Änderungen von Abläufen weniger aufwendig, als eine ggf. jahrelang etablierte Vorgehensweise in Software-Funktionen zu übertragen. Dem Argument „Das haben wir schon immer so gemacht“ sollte sofort die „Warum“-Frage folgen.

Bei Eigenentwicklung der Software ist auch die Software-Architektur so zu konzipieren, dass Aspekte für

• Datensicherheit
• System-Ausfallsicherheit
• System-Skalierbarkeit
• ggf. Mandantenfähigkeit

berücksichtigt werden. Funktionale Änderungen und Erweiterungen müssen mit überschaubarem Aufwand möglich sein.

Bei der Auswahl einer kommerziellen Standard-Software (Buy) müssen die o.a. Aspekte ebenso in eine Bewertung einfließen, wie der Umfang von Out-of-the-Box-Funktionen für wesentliche und umfassend bekannte Geschäfts-prozesse. Wenn Customizing einer vorgegebenen oder gewählten Standard-Software bedeutet, dass diese im Kern umgebaut werden muss – sofern das durch Offenlegung des Hersteller-Quellcodes überhaupt möglich ist – oder wichtige benötigte Funktionen und Prozesse „daneben“ gebaut werden müssen – die Standard-Software also nur für unwesentliche Funktionen verwendet wird – dann entstehen hohe Kosten im Projekt und bei Änderungsbedarfen auch weiterhin nach Projektende, also während der Betriebslaufzeit.

Projekt-Vorgehensmodell – Wasserfall oder agil

Auch die gewählte Vorgehensweise für das Projekt – „Wasserfall“ oder „Agile Entwicklung“ oder eine Kombination aus beidem – kann zu erhöhten Projektaufwänden und damit auch Kosten führen.

Bei Anwendung des "Wasserfall"-Modells können Fehler erst spät im Projektverlauf erkannt werden. Als Fehler sind dabei nicht nur Entwicklungsfehler zu betrachten, sondern auch Fehlentscheidungen in Bezug auf die System-Architektur, die Unvollständigkeit der Anforderungsdefinition und Konzeption, nicht oder unzureichend dokumentierte Systemschnittstellen zu Legacy- oder Dritt-Systemen. Zudem lernen die zukünftigen Anwender und Redakteure des Webshops die neue Applikation erst kurz vor Übergabe kennen. Nicht eingepreiste, aber erkannte und notwendige Anforderungsänderungen oder -ergänzungen müssen dann bewertet, konzeptionell eingearbeitet und nachträglich implementiert werden.

Auch beim Ansatz „Agile Entwicklung“ gibt es diverse Stolperfallen als mögliche Kostentreiber:
Man kann sich das agile Vorgehen als Taktstraße vorstellen, das heißt, ein nicht ausreichend und qualifiziert gefülltes Product Backlog führt zu Leerlauf in den Sprints. Solange nur einfache User Stories im Product-Backlog sind und User Stories für komplexe Funktionen oder erforderliche System-Schnittstellen „später“ erarbeitet werden, führen „später“ erkannte Architektur- und Datenmodell-Überarbeitungen auch dazu, dass bereits implementierte Funktionen angepasst oder verworfen und neu gebaut werden müssen.
Oder: Das Projekt-Umfeld arbeitet nicht im agilen Modus oder in einer anderen agilen Taktung, es gibt aber Abhängigkeiten, z. B. bei Systemschnittstellen mit Legacy-Applikationen, dann kann der ganze Ablauf unübersichtlich und die Abarbeitung der Sprint-Inhalte verzögert werden.

Ganz fatal ist ein Wechsel des Vorgehensmodells mitten im Projekt – aber auch das ist schon vorgekommen. Wenn z. B. das Vertrauen in die agile Vorgehensweise schwindet, weil nicht klar ist, wann und mit welchem Ergebnis der Entwicklungsprozess abgeschlossen wird, dann stehen beide Parteien – Auftraggeber und Auftragnehmer – an der Abbruchkante.

Unsere Empfehlung ist hier, dass beide Parteien vor Projektbeginn offen darüber zu sprechen, welches Verständnis und welche Erwartungen es bei einer agilen Vorgehensweise hinsichtlich Zusammenarbeit, Kommunikation und Entscheidungsbefugnissen gibt. Und es ist genau so offen anzusprechen, welche personellen und zeitlichen Begrenzungen berücksichtigt werden müssen.

Fehlendes oder mangelndes Risiko-Management

Auch in einem vermeintlich überschaubaren Webshop-Projekt ist ein qualifiziertes Risiko- und Chancen-Management ein wesentliches Element zur Projekt- und Kostensteuerung. Risiken sind nichts Schlechtes, es gibt sie in jedem Projekt – wichtig ist, sie zu kennen und aktiv von Beginn an mit allen Projekt-Beteiligten zu managen, das heißt die Eintrittswahrscheinlichkeit zu minimieren und Lösungsszenarien inklusive potenziellen Aufwänden und Mehr-Kosten in der Schublade zu haben.

Um auch positive Aspekte einzubringen, können Chancen in das Risiko-Management einbezogen werden, also z. B.

• entwicklungsbegleitende Systemintegrationstests, um frühzeitig Schnittstellenfehler zu erkennen,
• das Initiieren von organisatorischen Change-Maßnahmen, um die Mitarbeiter für den neuen Vertriebskanal zu begeistern oder
• die kontinuierliche Testdaten-Erstellung und -Erweiterung – ein Thema, was häufig unterschätzt und zu selten eingepreist wird.

Unser Credo: Auch Chancen für ein schnelleres, effektiveres, kostengünstigeres Vorankommen im Projekt sollten erkannt, in das Risiko-Board aufgenommen und die Realisierung im Projektverlauf ermöglicht werden.

Es gibt neben weiteren allgemeinen Projekt-Faktoren, wie:

• unzureichendes Anforderungsmanagement – ausgerichtet an den Projektzielen (siehe Blog-Artikel „Agiles Projektvorgehen“)
• fehlender bzw. nicht ausreichender Test oder verspäteter Testbeginn

auch spezielle Faktoren für Webshop-Projekte, die zu Mehraufwand und damit zu höheren Kosten führen können:

Komplexität des Produkt- und Preismodells

Je nach Art der Produkte und Leistungen, die im Webshop angeboten werden sollen, und den Abhängigkeiten zwischen diesen Produkten und Leistungen, kann das zugehörige system-technische Produkt-Datenmodell einfach sein oder auch sehr komplex werden.

Einzelne, nicht konfigurierbare haptische Produkte ohne Service-Leistungen und Varianten, wie z. B. Farbe oder Größe, sind sicher der einfachste Anwendungsfall.

Standard-Software für Webshops stellt zumeist auch die systemtechnische Abbildung von sogenannten Master-Produkten und zugehörigen Produkt-Variationen (Farbe, Größe u. ä.) out-of-the-box bereit.

Wenn das Vertriebsprodukt jedoch aus konfigurierbaren Komponenten besteht und für die Konfiguration der Komponenten Bedingungen bzw. Abhängigkeiten beachtet werden müssen, um eine valide gebrauchsfähige Zusammenstellung zu erreichen, dann kann die Abbildung dieses Produkt-Komponenten-Modells im gewählten Software-Ansatz (siehe Make or Buy-Entscheidung) zu erheblichen Entwicklungs- und vor allem Test-Aufwänden führen. Hier wäre der Einsatz und die Integration eines Produkt-Konfigurators zu überlegen.

Als sehr komplex können z. B. Tarife mit konfigurierbaren, preisrelevanten Leistungsparametern als Dauerschuld-Verhältnisse in Kombination mit Einmal-Leistungen wie Hardware-Verkauf oder -Systeminstallationen angesehen werden.

Je nach Komplexität des Produktmodells kann auch das zugehörige Preis-Modell beliebig komplex werden, zumal bei Hinzunahme von Preis- und Rabatt-Modellen in Abhängigkeit von Kundengruppen, Vertriebsregionen, Kunden-Rahmenverträgen o. ä.

Es empfiehlt sich, dass Daten-Modell für Produkte und Preise frühzeitig zu erstellen und zu stabilisieren, da Modell-Änderungen im späteren Projektverlauf erheblichen Anpassungsbedarf für die bereits implementierten Funktionen und Nutzungsprozesse im Webshop bedeuten können.

Abweichungen vom Standard-Warenkorb-Prozess

Erweiterungen des einfachen Warenkorb-Prozesses „Produkt auswählen – Lieferadresse eingeben – Rechnungs-daten eingeben – kostenpflichtig bestellen“ wie z. B.

• ein Abgleich des Warenkorb-Inhalts mit dem Ist-Produktbestand des Kunden oder
• zusätzliche, für die nachfolgende Leistungserbringung erforderliche, Abfragen und Eingaben des Webshop-Nutzers oder
• die Überprüfung und Validierung der gewählten Produkte im Warenkorb auf Kompatibilität oder
• vor Abschluss der Webshop-Bestellung ist ein Abgleich mit Bestellvorgängen in anderen Vertriebskanälen erforderlich,

führen ebenfalls zu einem höheren Implementierungsaufwand.

 

Wie lässt sich ein Überschreiten des Projekt-Budgets verhindern?

Ja, es gibt auch Projekte, bei denen das geplante Projekt-Budget eingehalten oder sogar unterschritten wird. Um das zu erreichen, haben wir ein paar Tipps kurz zusammengefasst:

„Wer billig kauft, kauft zweimal.“ – bewerten Sie bei der Auswahl von Software-Technologie und Implementierungs-Partner nicht nur den Preis.

Risiko- und Chancen-Management – Risiken gibt es immer, also benennen Sie Risiken von Beginn an, planen Sie Risiko-Budget ein und sorgen Sie mit dafür, dass Risiken nicht oder nur minimiert eintreten können.

Projekt-Kommunikation – sorgen Sie dafür, dass alle offen und lösungsorientiert miteinander reden

Projekt-Vorgehen – treffen Sie Ihre Festlegung nicht nach Lehrbuch, sondern entsprechend den realen Möglichkeiten.

Zielorientiertes Anforderungsmanagement – definieren Sie dafür Projektziele im Sinne „Was und wo ist der Schmerz, wenn das Projekt NICHT durchgeführt wird?“ und priorisieren Sie die Anforderungen zur Erreichung dieser Ziele.

Funktionstest von Beginn an – überlegen Sie, welche Testarten, Testsysteme, Test-Durchführende Sie für einen frühzeitigen Teststart für die wirklich wesentlichen Prozesse und Daten-Übergabestellen benötigen.

 

Wir sind sicher, dann wird das Projekt ein Erfolg! Sie benötigen Hilfe?

JETZT KONTAKT MIT UNSEREN EXPERTEN AUFNEHMEN

< zur Übersicht