1 Planungsphase Ist-Analyse, Festlegung Arbeitsschritte, Pflichtenhefterstellung
Durchführung geplant für August 2006
Start 01.08.2006
Ende 30.09.2006
 |
abgeschlossen |
 |
Stolpersteine |
Pflichtenheft erstellt - Zeit- und Kostenplanung fällt schwer
Ein Fehler mit gravierenden Auswirkungen auf die bisher installierte Systeminfrastruktur wirkt sich auf den Projektverlauf aus.
Folgende Berichte aus dem Projektverlauf liegen vor:
31.08.2006: Die Ist-Analyse der technischen Voraussetzungen war einerseits relativ schnell abgeschlossen, da bereits im Vorfeld des Projekts eine Systeminfrastruktur aufgebaut wurde, die das Potenzial zur Aufnahme bzw. der Anpassung der voraussichtlich notwendigen Erweitungen mit sich brachte. Klar war die mögliche Abbildung von BMEcat-relevanten Feldern als Erweiterung oder Übernahme in/aus vorhandenen, digital vorliegenden Stammdaten, klar wie die Verfügbarkeit eines auf die Produktdatenbank aufsetzenden Onlineshops aus gleichem Hause.
Durch das interne Arbeiten mit dem System waren auch einige organisatorische Abläufe bereits gegeben. Die personellen Voraussetzungen waren ebenfalls schnell klar, klar war zugleich, dass die für dieses Projekt vorgesehene Personaldecke als dünn zu bezeichnen ist.
Schwieriger erscheint hingegen die Auseinandersetzung und die Einordnung von eCl@ss, die zu wählende Herangehensweise, auch aufgrund einer gewissen Unübersichtlichkeit und vor allem aufgrund bislang nicht vorhandener Erfahrungen mit dem Thema auf Seiten STAUF und auf Seiten des Dienstleisters.
In Bezug auf doie Planung ist intern wie extern weniger investiert worden, da bestimmte Voraussetzungen und Fragestellungen technischer Natur vom Dienstleister kurzerhand beantwortet werden konnten und für die theoretische Auseinandersetzung mit der Thematik intern nicht genügend Zeit zur Verfügung stand. Es wird versucht, hier entsprechende Reserven zu schaffen.
30.09.2006: Da aufgrund der weiteren Beschäftigung mit der Thematik immer wieder neue Teilbereiche aufkommen, die sinnvollerweise mit abgedeckt werden könnten. So hat Stauf zu Beginn den ganzen Bereich der Internetportale unberücksichtigt gelassen, in denen Unternehmen, z.B. der Baubranche, ihre Produkte listen und somit einem viel größeren Interessentenkreis und damit auch anderen Zielgruppen in einheitlicher Form präsentieren. Hier wurde ein weiteres Mal die Bedeutung des Projekts augenscheinlich, aber auch die evtl. Notwendigkeit, nicht alleine auf BMEcat zu setzen.
Die Thematik eCl@ss wie auch BMEcat steht aber auch hier offenbar noch in ihren Anfängen, denn Stauf stieß dabei auf andere, in spezifischen Branchen abgestimmte Formate wie bau:class oder pricat, z.B. im Zusammenhang mit Heinze BauDatenbank, Zentrale Artikelstammdatenbank der Baubranche etc. Die aufkommende Verwirrung trug wiederum zur Ernüchterung bei, da das Bearbeiten der hier gesammelten umfangreichen Informationen sehr viel Zeit in Anspruch nehmen würde.
Die Bearbeitung dieser zusätzlichen Informationen wird in die Initialphase hereinreichen, da Stauf im Zusammenhang mit Pflichtfeldervorgaben einen Abgleich zwischen den unterschiedlichen, für sich relevanten Formaten vollziehen möchten.
Ziel war die Bereitstellung eines Pflichtenheftes, welches in strukturierter Form die verschiedenen Etappen des Projekts darstellt und damit Zugleich als Leitfaden für selbiges verwendet werden kann.
Es war nicht möglich, eine besonders detaillierte Ablaufbeschreibung zu erstellen, da in vielen Bereichen gewisse Kenntnisse weder auf Seiten des Dienstleisters noch bei STAUF zum Thema eBusiness vorhanden waren. So musste vor allem bei möglichen Kosten, bei vermuteten Zeiterfordernissen, bei wahrscheinlich notwendigen Projektschritten mit relativ groben Vermutungen gearbeitet werden, die aber dennoch einen brauchbaren Projektfahrplan vorgaben, auch deshalb, weil zumindest beim Thema BMEcat auf Erfahrungswerte des Dienstleisters zurückgegriffen werden konnte.
Die Erstellung des Pflichtenheftes hat mehr Zeit als erwartet in Anspruch genommen. Abweichung beruht daher einfach auf einer nicht ausreichend kalkulierten Vorgabezeit. Sehr hilfreich war das Beispielpflichtenheft, welches eine gute Grundlage für den Aufbau eines projektspezifischen Exemplars bildete.
Eine vorhandene Zeit- und Kostenplanung würde bei der derzeitigen Personaldecke vermutlich mehr Anpassungsaufwand als Nutzen bringen, da eine aufgrund des umfangreichen Aufgabengebietes des Projektzuständigen oftmals notwendige Delegation von Arbeiten nur auf den Dienstleister möglich wäre, nicht jedoch auf weitere STAUF-Mitarbeiter. Die Übertragung der Aufgaben auf den Dienstleister ist teilweise erfolgt und führt zu leichten Verschiebungen in der Verteilung der Tagwerke, bislang jedoch nicht zu Veränderungen der Tagwerksumme.
An dieser Stelle ist auch darauf hinzuweisen, dass sich Mitte September 2006 ein bislang nicht erklärbarer, schwerwiegender Fehler mit gravierenden Auswirkungen auf die bisher installierte Systeminfrastruktur ereignet hat. Dieser Umstand führte zur, offenbar scriptgesteuerten, automatischen Löschung aller bislang erfassten Produktstammsätze der Mediabase Produktdatenbank mit der Folge einer 70%prozentigen Fehlfunktion des Internetauftritts, da alle auf die Produktdatenbank zugreifenden, dynamischen Internetseiten keine Informationen mehr anzeigen konnten. Diese waren definitiv gelöscht. Ebenso war die Schnittstelle zum Warenwirtschaftssystem betroffen, welches dadurch ebenfalls keine aktuellen Daten mehr zur Verfügung stellen konnte. Hier mussten zum ersten Mal Sicherungsabläufe durchgeführt werden, die nach einiger Zeit zumindest den statischen Weiterbetrieb der Seiten ermöglichten. Wichtig war nun die Ursache(n) der Fehlfunktion ausfindig zu machen, was vom Dienstleister übernommen wurde. Der daraus resultierende Aufwand für Rekonstruktion, Fehlersuche und letztlich Neuprogrammierung der Schnittstelle ist zum großen Teil verantwortlich für die weitere, zeitliche Verzögerung der Abarbeitung des Pflichtenhefts. Zum Teil tauchen bis dato noch unvollständige Stammsätze auf, die aufgrund dieser Panne manuell nachgepflegt werden müssen.
Die größte Problematik im Zusammenhang mit der Fehlfunktion war das vorherige, kurzfristige Ausscheiden des zuständigen Programmierers des Dienstleisters, so dass die Einarbeitung und Wissensaneignung der neu bestimmten Zuständigen eine gewisse Zeit in Anspruch nahm. Um jegliches Risiko zu vermeiden entschied sich der Dienstleister zur kostenlosen Neuprogrammierung der vermutlich fehlerhaften Schnittstellen und zur Entschärfung der automatischen Löschanweisungen in dem entsprechenden Übergabescript.
