2. Make or Buy? - Kalkulation mit Weitblick in der Evaluierungsphase
Hat das Projektmanagement die Orientierung und Informationssammlung abgeschlossen, wird die Bedarfserhebung Schritt für Schritt validiert. Durch schlüssige Konzepte und Kompromisse können die benötigten Features & Functions und der Integrationsumfang schließlich festgelegt werden. Am Ende dieses Prozesses steht ein eindeutiges Ergebnis zu Konzeption und Systementscheidung mit Realisierungsauftrag.
Im Wesentlichen müssen Sie sich nun für oder gegen ein bestimmtes E-Commerce-System oder eine Kombination aus mehreren Systemen und Drittentwicklungen entscheiden. Dabei liegt dieser Entscheidung eine ganz prägnante Frage, ein regelrechter Management-Klassiker, zugrunde. Die Frage: "Make or Buy?"
IT-Projekte starten heute nicht mehr auf der grünen Wiese. Irgendeine digitale Lösung - und sei sie auch nur provisorisch - ist meist schon da. Nicht nur wegen der bisher bereits investierten Ressourcen erscheint das Fortsetzen plausibel. In der Tat sind eigenentwickelte Teilsysteme in der Anpassung hochflexibel und schonen dank wegfallender Einarbeitungszeit und kurzer Wege beim Setup zunächst das Budget. Eine dicke Rechnung steht allerdings schon mittelfristig ins Haus, wenn man auf Qualität, Sicherheit (Stichwort: Zertifizierungen) und Entwicklungsfortschritt achtet.
Wenn also intern beispielsweise eine Schnittstelle entwickelt und dauerhaft betreut werden soll, muss es ein dezidiertes Produktmanagement geben, das die Software im Einklang mit allen anderen Systemfortschritten und mit professionellem Anspruch weiterentwickelt. Eine Aufstellung allein der dafür benötigten personellen Aufwände zeigt, dass Kosten entstehen, die sehr schnell deutlich über den Lizenz- und Wartungskosten eines vergleichbaren Standardprodukts liegen. Und dabei ist noch nicht einmal berücksichtigt, dass ein Herstellerprodukt zudem regelmäßig neue Features, Wartung und Support bietet.
Beleuchten Sie bei der Beurteilung eines Systems die folgenden Schwerpunkte:
Reifegrad des Systems
Diese Bewertung steht in direktem Bezug zu den oben genannten Sicherheitsüberlegungen. Welche Sicherheitslöcher werden durch das System in die Unternehmens-IT eingeführt und wie können sie geschlossen werden?
Qualität
Welche Qualitätsmerkmale der Software können ausgemacht werden, wie und wann werden diese transparent gemacht und bewertet. Eine transparente Entwicklungsinfrastruktur seitens des Herstellers und Zugang zu Quellcode, geplanten Weiterentwicklungen und dem Arbeitsstand machen die Beurteilung leicht.
Infrastrukturbedarf
Wie ressourcenintensiv ist die Software? Welche Hardwareanschaffungen und Serverumgebungen werden empfohlen? Nach welchen Business Cases kann unterschieden werden? Gibt es Migrationsszenarien in beide Richtungen (wachsen und reduzieren)? Wie kann mit Lastspitzen umgegangen werden?
Updatezyklen und Ressourcenbedarf
Wann und wie häufig ist mit Updates zu rechnen? Wie laufen diese ab und welche Ressourcen müssen dafür eingeplant und budgetiert werden? Sollen diese intern oder extern umgesetzt werden und falls beides, zu welchen Anteilen?
Notfallplan
Ach auf Probleme, die hoffentlich nie auftreten, muss es eine Antwort geben. Für den Fall, dass im Rahmen der Planung oder hinsichtlich interner Ressourcen alle Stricke reißen: Wer kann unterstützen, mit wem können Notfallszenarien besprochen werden?