Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

07.05.2009

Gute Planung rechnet sich

07.05.2009
Von Jürgen Beckers und Gerry Wallner 
Im dritten und letzten Teil unserer IT-Einkaufsserie lesen Sie, wie Sie bei der Softwareeinführung die Fäden in der Hand behalten.

Wenn Sie die Ziele des Softwarekaufs herausgearbeitet und einen passenden Anbieter gefunden haben, beginnt die Umsetzung. Dabei kommt es vor allem auf folgende Schritte an:

1) Detaillierte Planung

Entscheidend ist zunächst, dass Sie die Softwareeinführung sorgfältig planen. Um den Projektfortschritt jederzeit überwachen zu können, empfiehlt sich bei industrieller Standardsoftware die Einteilung in vier Phasen: Projektplanung, Umsetzung, Testing und Betriebsübergabe. Für jede Etappe sind die zentralen Aufgaben und Meilensteine zu identifizieren und in weitere messbare Arbeitspakete zu gliedern. Diese Struktur hilft dabei, die personellen und technischen Ressourcen in Einklang zu bringen und die Arbeitsaufträge an konkrete Termine zu binden. Zudem werden komplexe Anforderungen übersichtlicher, und die Beteiligten können Abhängigkeiten von einzelnen Projektschritten sofort erkennen.

Die Pakete werden übersetzt, formalisiert und miteinander in Beziehung gesetzt – lückenlose Dokumentation und Nachvollzug inklusive. Auf diese Weise wird der "kritische Pfad", der alle Arbeitsgänge miteinander verbindet, transparent. Allerdings kann es auch bei guter Planung zu unvorhersehbaren Verzögerungen kommen - etwa wenn Mitarbeiter krank werden und sich nicht kurzfristig ersetzen lassen, oder wenn die Server, auf denen die Software implementiert werden soll, zu spät geliefert werden. Für solche Unwägbarkeiten sollten Sie bei der Projektplanung Zeitpuffer einkalkulieren. Ansonsten ist die Erstellung des detaillierten Projektplans Sache des Anbieters – sofern ihm der Vertrag das Projekt-Management zuschreibt und die geforderten Einzelheiten und Planungsformate sowie den Planungszyklus vorgibt.

Entscheidend ist zudem, dass der Projektplan mit dem Vertrag im Einklang steht. Vor allem bei komplexen Einführungen sollte der Plan regelmäßig an den jeweiligen Projektfortschritt angepasst werden. Ist der aktualisierte Plan nicht mehr vertragskonform, haben Sie zwei Möglichkeiten: Entweder Sie widersprechen unverzüglich, oder Sie einigen sich mit dem Anbieter schriftlich auf den geänderten Projektplan inklusive der sich daraus ergebenden Konsequenzen. Wichtig zu wissen: Widerspricht der Kunde dem Projektplan nicht, obwohl er in wichtigen Punkten vom Vertrag abweicht, kann dies juristisch als stillschweigende Zustimmung zu einer Vertragsänderung gewertet werden.

2) Effiziente Organisation

Wie gut die Umsetzung gelingt, hängt auch von der internen Koordination ab. Angesichts der vielfältigen Aufgaben und Informationen empfiehlt es sich, ein dediziertes Projektteam zusammenzustellen. Koordiniert und gesteuert wird es vom Projektleiter, der zudem als zentrale Schnittstelle zum Anbieter dient und die Erfüllung der vertraglichen Anforderungen kontrolliert. Ansonsten sollte das Team je nach Umfang des Vorhabens aus einem dem Projektleiter zugeordneten Mitarbeiter, einem Lenkungsausschuss, einem IT-Controller sowie einem Juristen bestehen, der die Einhaltung des Vertrags überwacht und juristische Fragen klärt. Das Projektteam legt auch das Eskalations-Management fest: Wer sind weitere Stakeholder, die es regelmäßig zu informieren gilt? Wie wird das vertraglich vereinbarte Eskalationsverfahren für strittige Fragen umgesetzt, und welche Vorstufen gibt es? Solche Absprachen machen den Projektstatus transparent und tragen damit maßgeblich zur Akzeptanz der Softwareeinführung im Unternehmen bei.

3) Umgang mit Änderungen

Änderungen im Projektverlauf lassen sich kaum vermeiden. Viele IT-Projekte scheitern jedoch an der unsachgemäßen Bearbeitung der Change Requests. Um hier auf der sicheren Seite zu sein, sollten Sie alle Änderungen schriftlich dokumentieren und sich auf ein formalisiertes Change-Request-Verfahren stützen, das nicht nur im Vertrag verankert ist, sondern auch gelebt wird (siehe Kasten "Änderungen managen").

Änderungen managen

Formulieren Sie alle Abweichungen vom geplanten Projektverlauf schriftlich!

Prüfen Sie, ob die Änderung vertraglicher Bestandteil ist. Gibt es darüber Konflikte mit dem Anbieter, schalten Sie die zuständigen Projektgremien ein.

Ist die Änderung kein Vertragsbestandteil, legt der Anbieter einen Umsetzungsvorschlag vor.

Komplexe Änderungen erfordern eine eingehendere Prüfung. Sieht der Vertrag nichts Gegenteiliges vor, wird der Anbieter dafür speziell vergütet.

Die Änderungen kann der Anbieter entweder schriftlich ablehnen oder ein Nachtragsangebot zur Umsetzung vorlegen. Dieses sollte auch die Folgen der Modifikation für andere Arbeiten, für Mitwirkungsleistungen des Auftraggebers sowie für Budget und Zeitplan enthalten.

Egal, ob Sie das Nachtragsangebot annehmen oder nicht - Ihre Entscheidung müssen Sie immer schriftlich formulieren.

Setzen Sie für die Bearbeitung von Change Requests möglichst kurze Fristen an und regeln Sie die Rechtsfolgen, wenn die Frist nicht eingehalten wird.

Erklärt sich der Auftragnehmer bereit, die Änderungen vorzunehmen, ist der Projektplan entsprechend anzupassen.

Wenn der Auftragnehmer für die Änderungen verantwortlich ist – etwa weil er wegen eigener Fehler nachbessern muss –, trägt er die Kosten. Geht es bei den Änderungen jedoch um Zusatzwünsche des Auftraggebers, die nicht vertraglich vereinbart wurden, kann sie der Anbieter entweder verweigern oder einen Aufpreis für die Umsetzung verlangen

4) Konsequentes Controlling

Die Einführung einer komplexen Software steht im Spannungsfeld zwischen Funktionen, Zeit, Kosten und Qualität. Daher sollten Sie diese Parameter während des Projekts regelmäßig kontrollieren. Ansonsten besteht die Gefahr, dass Probleme erst wahrgenommen werden, nachdem Einführungstermin und Budget bereits überschritten sind. Auch wenn das Projekt-Management laut Vertrag Sache des Auftragnehmers ist: Durch ein eigenes Controlling stellen Sie sicher, dass Zeit- und Kostenvorgaben eingehalten, die richtigen Collaboration-Tools verwendet und Updates rechtzeitig mitgeteilt werden.

5) Dokumentation

Während des Projektverlaufs werden viele Dokumente ausgetauscht, da verliert man leicht den Überblick über getroffene Absprachen. Die entsprechenden Details - etwa nach welchem System Informationen dokumentiert und archiviert werden, wie bestimmte Dokumente zu benennen und Ergebnisse zu präsentieren sind und welche Dateiformate Grafiken und Projektpläne haben sollen - sollten Sie daher schon bei Projektbeginn festlegen. Auch die Konfiguration der Software sowie kundenspezifische Anpassungen sind umfassend zu dokumentieren und archivieren. Nur dann können die für die Wartung zuständigen externen Mitarbeiter bei Problemen nach der Einführung – etwa beim Einspielen neuer Releases – nachvollziehen, welche Einstellungen und Anpassungen zuvor an der Software vorgenommen wurden.

6) Abnahmetest

Vor der Inbetriebnahme sollten Sie nochmals prüfen, ob die Software allen vertraglichen Anforderungen gerecht wird. Allerdings kommt bei der Einführung von Standardsoftware mit dauerhafter Nutzungsrechteinräumung in der Regel das Kaufrecht zur Anwendung, das keine Abnahme vorsieht. Anspruch auf einen Abnahmetest haben Sie daher nur, wenn dies explizit vertraglich vereinbart ist (siehe Kasten "Details zum Abnahmetest") (sp)

Details zum Abnahmetest

Welche Tests sind vorgesehen (Funktionstest, Integrationstest)?

Wann und über welchen Zeitraum sollen die Tests erfolgen?

Welches Testsystem wird genutzt?

Wer übernimmt welche Testaufgaben?

Welche Tools werden eingesetzt, wer beschafft sie?

Wer stellt welche Testdaten in welchem Format bereit?

Welches Datenvolumen und welche Systemlast sind für die Tests vorgesehen?

Welche Fehlerklassen gelten für Vertragsabweichungen, nach welchem Verfahren werden die Fehler behoben?

Wer protokolliert die Testergebnisse nach welchen formellen Kriterien?

Welche Vergütung erhält der Anbieter für die Tests? Was ist nicht vergütungspflichtig?

Wann ist ein Abnahmetest als gescheitert anzusehen, und welche Fristen gelten für Nachbesserungen?

Was passiert, wenn der Abnahmetest endgültig scheitert?