Arbeitspaket 7 Datenintegration und Modelling
Durchführung geplant für November 2003
Start 01.09.2003
Ende 30.11.2004
 |
abgeschlossen |
 |
Zeitverzögerung |
Ungenügende Datenpflege der Vergangenheit
Bei der Zusammenführung von Datenbeständen verursachte schlechte Datenpflege der Vergangenheit unerwarteten Arbeitsaufwand. Dagegen konnte das neue CRM-System in kurzer Zeit implementiert und getestet werden.
Folgende Berichte aus dem Projektverlauf liegen vor:
Durch die Einführung von eClass als Klassifizierungsstandard bei Freund mussten Anpassungen des bestehenden Datenmodells getroffen werden. Die entsprechenden Arbeiten begannen am 27.8.2003 und enden im Dezember 2004.
Zunächst wurden hauptsächlich Anpassungen an das Datenmodell des bestehenden ERP appliziert. Diese betrafen sowohl den Artikelstamm als auch teilweise den Kunden- und den Lieferantenstamm.
Für die Realisierung des CRM mussten zusätzliche Tabellen eingeführt werden, die z.B. die Verwaltung von Kontakten und Aktivitäten dieser Kontakte speichern. Das Feinkonzept des CRM wurde im September 2003 abgeschlossen.
Weitere Anpassungen am Datenmodell ergaben sich aus den Erfordernissen des Shops. So musste eine Eingruppierung der Artikel zunächst in eine dreistufige, im finalen Stadium dann nochmals neu in eine zweistufige hierarchische Gliederung vorgenommen und in der Datenbank abgelegt werden.
Durch die mehrfache Änderung der Anforderungen seitens Freund ergaben sich zusätzliche Aufwände, die den Fortschritt der Arbeiten teilweise verzögert haben.
Weitere Anpassungen und Erweiterungen an das Datenmodell wurden im August 2004 vorgenommen, als entschieden wurde, eine eigene Webanwendung für die Pflege der Katalogdaten zu entwickeln. Dafür wurden zusätzliche Tabellen konzipiert und mit den bereits in anderen Tabellen bestehenden Daten gefüllt. Letzte Korrekturen an der Datenstruktur wurden im Rahmen von Anpassungen dieser Applikation im November durchgeführt und werden bis Dezember 2004 beendet.
Außerdem wurden die bisher in einer externen Filemaker Datenbank gepflegten Artikeldaten in das ERP integriert. Auch dazu mussten Anpassungen an das Datenmodell vorgenommen werden.
Um eCl@ss nicht nur im Sinne einer dem Artikel zugeordneten Klassifizierung, sondern auch für die Erfassung und Darstellung von Merkmalen der klassifizierten Artikel nutzen zu können, wurden weitere Tabellen in das Datenmodell integriert. Dadurch kann im Shop und im Händlerbereich der CRM-Anwendung die Klassifizierung der Artikel bei Freund angezeigt werden. Auch die Darstellung der klassenspezifischen Merkmalsleiste und der für die Artikel eingepflegten Merkmalswerte wurde so ermöglicht.
Hauptprobleme lagen in der Änderung von Darstellungen, in den sich aus den aktuellen Arbeitsschritten erwachsenden neuen Anforderungen. Auf diese Art und Weise ergaben sich häufig neue Anforderungen an das Datenmodell, die jeweils evaluiert, implementiert und getestet werden mussten.
Es wurden drei Action points festgelegt:
- Erweiterung des Datenmodells um die für die Klassifizierung und Merkmalsbeschreibung notwendigen Tabellen
- Darstellung des Klassenidentifikators, der eClass-Nummer sowie des Klassennamens für die bereits klassifizierten Artikel im Shop
- Darstellung der Merkmalsleisten für die bereits klassifizierten Artikel anhand der durchgeführten Klassifizierung.
Anhand des bei der Nutzerschulung erhaltenen Feedbacks wurden letzte Maßnahmen zum Finetuning des Shops ergriffen. Diese Maßnahmen erstreckten sich auf nahezu alle Bereiche der Shopanwendung, waren jedoch im Einzelnen meist nur mit geringem Aufwand verbunden.
Die Anpassung des Datenmodells für an eClass 5.1 wurde vorgenommen. Dazu wurde ein Download der Tabellenbeschreibung und der Wertedateien (CSV-Dateien) durchgeführt. Es wurden einige notwendige Überprüfungen/Anpassungen vorgenommen, damit die entsprechenden Tabellen in der dem ERP zugrunde liegenden Datenbank (Informix) erstellt werden können.
Im Shop wurde die Darstellung der Klassifizierung nach eCl@ss in der Detailsicht jedes Artikels eingeführt. Dazu wurden die Datenbankschnittstellen entsprechend angepasst.
Im Händlerbereich (CRM) wurden zwei weitere Ansichten eingefügt. Anhand der Artikelnummer (wenn z.B. aus dem Shop bekannt) kann der Händler die eCl@ss-Klassifizierung eines Artikels ersehen. Dabei werden der Klassenidentifikator, seine Version, die eCl@ss-Nummer (coded name) sowie der Klassenname (preferred name) angezeigt.
Weiterhin wurde eine Ansicht zur eCl@ss-Merkmalsleiste eingeführt. Mittels der Artikelnummer kann sich der Nutzer über die Verknüpfung von Artikelstamm, eCl@ss-Datenmodellerweiterung und eingepflegten Merkmalswerten die dynamisch die Merkmalsleisten und die zugehörigen Merkmalswerte anzeigen lassen.
Es wurden funktionale Tests an der Shoplösung sowie am CRM durchgeführt.
Die Tests am Shop haben ergeben, dass eine Reihe von Problemen, die bereits in den vergangenen Monaten beanstandet worden waren, immer noch nicht gefixt wurde. Durch die fortdauernden Arbeiten an der Schnittstelle zwischen dem ERP und dem Shopsystem kommt es immer wieder zu Problemen mit der Datenbelieferung. Dadurch können nicht alle Funktionalitäten getestet werden. Aber auch die bisher durchgeführten Tests haben noch Verbesserungsbedarf aufgezeigt.
Durch die Tests am CRM-System wurde eine Reihe von Fehlern gefunden. Es wurde eine Mängelliste erstellt und an den Dienstleister übergegeben. Die Mängel wurden von den Entwicklern analysiert und beseitigt. Dabei wurden auch Fehler, die bisher durch die Tests nicht entdeckt worden waren, zutage gefördert und ebenfalls behoben. Dies betraf z.B. logische Fehler in den Daten. Nochmalige Tests haben gezeigt, dass alle bisher gefundenen Fehler von den Dienstleistern gefixt worden sind. Zudem sind noch kleinere Ergänzungen am CRM-System durchgeführt worden.
Die Arbeiten an der Schnittstelle wurden auch in diesem Monat weiter fortgesetzt. Ziel ist die schnellstmögliche Fertigstellung der Arbeiten, damit die Produktivsetzung des Shops noch in diesem Jahr realisiert werden kann.
Die Batch-Jobs für den Datenexport aus dem ERP auf die Shop-Maschine wurden getestet. Kleinere Fehler wurden behoben. Der Dienstleister wurde beauftragt, eine Dokumentation der Datenexport-Jobs zu erstellen. Damit sind die notwendigen Arbeiten zur Datenaustausch zwischen der Datenbank, auf der das ERP läuft, und der Datenbank auf dem Shop-Host abgeschlossen worden. Sobald die entsprechenden Schnittstellen fehlerfrei arbeiten, kann der automatische Datenabglecih zwischen den Systemen angestoßen, abgenommen und produktiv genommen werden.
Es wurde ein Meeting mit OH zur Verlinkung von Shop, Homepage und eventuellen externen Webseiten durchgeführt. Ziel des Meetings war es u.a. das Layout des Webshops von Freund, so wie es aktuell realisiert wurde mit den Vorgaben und den von OH ursprünglich erstellten Entwürfen zu vergleichen. Sobald die notwendigen Entscheidungen getroffen wurden, kann das Customizing der Shop-Lösung finalisiert werden.
Problem: Die Arbeiten an der Schnittstelle konnten immer noch nicht abgeschlossen werden. Damit ist ein beachtliches Risiko für die Fertigstellung des Projektes bis zum Jahresende verbunden.
Lösung: Die Problemsituation wurde bei Freund intern analysiert und entsprechend eskaliert. Die Dienstleister wurden von der Geschäftsführung aufgefordert, die erforderlichen Arbeiten bis Ende November fertig zu stellen. Für den Dezember müssen die notwendigen funktionalen Test und der User Acceptance Test durchgeführt werden. Die Schulung der Mitarbeiter kann parallel zur Erstellung der Operational Handbooks erfolgen, damit kann Zeit eingespart werden.
Der Schwerpunkt der Arbeiten liegt weiterhin in der Erstellung einer lauffähigen Shoplösung.
Die Schnittstelle für den Shop wurde wegen anhaltender Probleme, insbesondere hinsichtlich des Einsatzes der Master/Detail-Struktur auf Artikelebene weiter angepasst. Insbesondere datenbanktechnische Änderungen (Überführung der Datenstruktur in die 3. Normalform) wurden durchgeführt.
Für ein besseres Business Monitoring wurde die Erstellung zusätzliche Reports in Auftrag gegeben und von den Dienstleistern realisiert. Damit verbundene Anpassungen der Datenbankstruktur, sowohl im ERP als auch teilweise in der Datenbank auf dem Shopsystem wurden durchgeführt und getestet. Nach erfolgreichem Abschluss der Tests konnten die Reporte genutzt werden.
Für die Artikeldarstellung im Shop wurden weitere Artikelabbildungen konvertiert und in die Datenbank eingepflegt. Dazu wurden die in den vergangenen Monaten entwickelten Algorithmen und Skripte zur Bildkonvertierung und Bildbearbeitung eingesetzt. Diese haben sich als effektiv erwiesen. Damit wird eine weitestgehend automatische Bildkonvertierung auch für die Zukunft praktikabel.
Es wurden Fehler in der neu erstellten Intranet-Anwendung zur Katalogpflege (Katalogartikelverwaltung) entdeckt. Ein entsprechender Fehlerreport wurde dem Dienstleister übergeben. Daraufhin wurde die Anwendung nochmals überprüft. Die beanstandeten Probleme wurden lokalisiert und entsprechend den Vorgaben behoben.
Die Warengruppen für den Shop wurden an das dreistufige Klassifizierungsmodell angepasst. Parallel dazu wurde die Klassifizierung nach eCl@ss in den Artikelstamm eingepflegt. Alle dazu notwendigen Datenbankanpassungen waren bereits vor längerer Zeit vorgenommen worden.
Die Klassifizierung der Artikel wurde an den Dienstleister geliefert. Das Einpflegen der Klassifizierung wurde durch den Dienstleister im ERP Produktivsystem vorgenommen.
Problem: Die durchgeführten Tests haben weitere Fehler in der Schnittstelle zwischen ERP und Shop-Datenbank ergeben. Die Arbeiten an der Schnittstelle können somit immer noch nicht als realisiert gemeldet werden.
Lösung: Die Probleme wurden den Dienstleistern mitgeteilt. Die Entwicklungsseite wurde aufgefordert, die Fehlersuche und Fehlerbehebung zu forcieren. Die Dienstleister wurden auf den vorgesehenen Abschluss der Projektarbeiten zum Ende des Jahres hingewiesen.
Problem: Es soll möglich sein, externe Webseiten oder die Freund Homepage auch aus dem Shop heraus anspringen zu können. Ziel ist es, den Shop und die Homepage von Freund besser mit einander zu verlinken. Leider konnte das bisher nicht in der Standard-Shoplösung realisiert werden.
Lösung: Von den Dienstleistern wurde daraufhin die Shoplösung nochmals untersucht. Es wurde eine Möglichkeit für ein weiterführendes Customizing von OS-Commerce gefunden und beispielhaft realisiert. Im Oktober soll nun die konkrete Umsetzung, d.h. die Anbindung an andere Webseiten aus dem Shop heraus, erfolgen. Die zu verlinkenden Webseiten werden den Dienstleistern von Freund bzw. OH vorgegeben.
Es wurden schnelle Schritte zur Umsetzung der im vergangenen Monat festgelegten Action Points zur Behebung der erkannten Probleme hinsichtlich der Artikelgruppierung durchgeführt.
Zunächst wurde eine Anpassung der Datenstrukturen auf Datenbankebene durchgeführt, getestet und abgenommen. Danach wurden die funktionalen Anpassungen in Angriff genommen.
Dazu wurde eine Überarbeitung der Schnittstellen sowohl auf Seite des ERP als auf Seite des Shop-Systems durchgeführt. Die entsprechenden Schnittstellen wurden teilweise neu implementiert und angepasst. Anschließend wurden erneute Tests zur Qualitätssicherung der Schnittstellen durchgeführt. Die Ergebnisse zeigten einige kleinere Fehler, die jedoch sofort behoben werden konnten.
Im dritten Schritt wurde die Darstellung der Artikel in der Shop-Lösung angepasst. Dazu musste eine Reihe von Änderungen am PHP-Code der Shop-Lösung vorgenommen und anschließend getestet werden.
Es wurde eine web-basierte Anwendung für die Pflege der Katalogdaten von den Dienstleistern realisiert und getestet. Dabei wurde eine Reihe von Problemen entdeckt, die jedoch schnell beseitigt werden konnten. Die notwendigen Anpassungen auf Datenbankebene wurden ebenfalls vorgenommen.
Mittels der entwickelten Applikation wird des möglich a) die Katalogtexte zu jedem Artikel in mehreren Sprachen zu erstellen b) bestehende Katalogtexte zu editieren, c) Katalogeinträge zu löschen. Es kann nach Artikeln sowie deren Master-Artikeln anhand einer Reihe von Kriterien gesucht werden.
Problem: Derzeit besteht noch das Problem, dass nicht alle in den Shop einzustellenden Artikel im Katalog mit allen Sprachen und Abbildung erfasst worden sind. Des weiteren muss die Artikelgruppierung nochmals überarbeitet werden.
Lösung: Diese Arbeiten werden voraussichtlich im September realisiert und hoffentlich auch abgeschlossen werden.
Aufgrund der Änderungen in der Umsatzsteuerrichtlinien mussten weitere Änderungen am ERP-System, sowohl an der Datenbank als auch im funktionalen Teil der Anwendung, vorgenommen werden. Diese Arbeiten von unserem Dienstleister durchgeführt, verhinderten weitere Arbeiten am eigentlichen Shop-System.
Es wurde eine Hilfskraft eingestellt, die mit der Überarbeitung der Katalogtexte sowie dem freistellen der Artikelfotos betraut wurde. Diese Arbeiten dienen der Katalogpflege für den Online-Shop.
Problem: Im Rahmen der durchgeführten Arbeiten zur Pflege und Überarbeitung der Katalogtexte, stellt sich heraus, dass die bestehenden Datenbankstrukturen nicht den sich neu ergebenden Anforderungen gerecht werden. Bisher hatten für die Beschreibung von Artikeln stets Datenbankfelder mit einer fest vorgegebenen Maximallänge ausgereicht. Diese Datenstruktur wurde ursprünglich aus der Artikeltabelle auf die Katalogtabelle übertragen.
Es zeigte sich jedoch, dass diese Datenbankfelder für die Beschreibung von bestimmten, zusammengesetzten Artikeln nicht mehr ausreichen. Beispielsweise sprengt die Beschreibung eines Werkzeugkasten, der eine Reihe weiterer Werkzeuge enthält die vorgegebene Feldgröße. Andere Artikelbeschreibungen hingegen kommen sehr wohl mit dem vorgegebenen Platz aus. Hier wäre eine einfache Anhebung der Feldgrößen der falsche Weg zur Lösung des Problems.
Lösung: Um dieses Problem zu beheben, wurde entschieden, die Datenbankstruktur anzupassen und eine dynamisch erweiterbare Struktur zu schaffen. Ziel ist es, sowohl die Überschreitung fest vorgegebener Feldgrenzen zu umgehen, als auch die Datenbankgröße auf einem minimalen Niveau zu halten. Um die Eingabe zu erleichtern, wurde zudem festgelegt eine kleine web-basierte Anwendung zu entwickeln, die eine einfache und schnelle Pflege der Katalogtexte ermöglicht. Damit können neue Katalogeinträge schneller und von verschiedenen Arbeitsplätzen erfasst werden. Weiterhin muß die bestehende Datenmenge auf die neue Struktur migriert werden.
Problem: Durch Diskussion mit den Dienstleistern stellte sich heraus, dass sich die Artikelgruppierung nach dem Master/Detail-Prinzip nicht mit der bisherigen Datenbankstruktur abbilden lässt. Diese Artikelgruppierung ist jedoch für die korrekte Arbeit der Shop-Lösung unabdingbar. IM Rahmen der Diskussion zeigte sich weiterhin, dass hier Unzulänglichkeiten in den Projektvorgaben als Ursache dieser Probleme angesehen werden müssen.
Lösung: Um diese Probleme schnellstmöglich und mit minimalem Aufwand zu lösen, wurden folgende Schritte festgelegt: Die Darstellung der Artikel nach dem Master/Detail-Prinzip soll in der Shop-Lösung weiter realisiert werden; eine Anpassung der Backend-Prozesse muss schnellstens von den Dienstleistern konzipiert und Umgesetzt werden. Ziel ist eine Fertigstellung der Anpassungsarbeiten im August.
Es wurden umfangreiche Tests zur Qualitätssicherung der Skripte für den Datenbank-Import/Export durchgeführt. Auch die Transportskripte sowie das zeitliche funktionelle Zusammenspiel der verschiedenen Skriptketten wurde überprüft. Einige aufgefundene Fehler konnten beseitigt werden. Nach Abschluß dieser Arbeiten wurde die Datenbelieferung für abgenommen erklärt.
Problem: Die Überprüfung und Darstellung der Katalogtexte hat gezeigt, daß Umlaute in vielen Texten nicht korrekt dargestellt werden. Die Dienstleister wurden auf dieses Problem hingewiesen, mit der Anforderung es abzustellen.
Lösung: Seitens der Dienstleister wurde eine vollständige Überarbeitung der Katalogtexte (insbesondere Artikelbeschreibungen) vorgenommen. Die bestehenden Probleme mit der Darstellung der Umlaute wurden behoben. Anschließende Überprüfungen zeigten keine weiteren Mänge
Da im vergangenen Monat endlich die Schnittstelle für den Datenaustausch zwischen ERP und Shop-DB fertiggestellt wurde, konnte in diesem Monat mit der Planung und Implementation der gegenseitigen Datenbelieferung beider Systeme begonnen werden. Dazu wurde ein Batch-Plan entwickelt. Mit der Implementierung der entsprechenden Skripte wurde begonnen. Leider traten bei den durchgeführten Testläufen noch eine Reihe von Problemen auf.
Es wurden nochmals Tests hinsichtlich der Master/Slave bzw. Master/Detail-Sicht der Artikel durchgeführt. Für eine Menge von Testartikeln wurden zunächst deutsche Katalogtexte mittels der neu entwickelten Maske eingepflegt. Dabei traten jedoch einige Probleme, insbesondere mit zu knapp bemessenen Datenbankfeldern zutage, die in den nächsten Wochen behoben werden sollen.
Problem: Die auf den erstellten Schnittstellen aufsitzenden Programme zur Datenbelieferung zeigten teilweise erhebliche Mängel.
Lösung: Zunächst musste herausgefunden werden, ob die Ursache in den Schnittstellen oder in den Batchjobs zu ist. Dazu wurde von den Dienstleistern eine Fehleranalyse durchgeführt. Dabei stellte sich heraus, daß an den Schnittstellen korrekte Daten übergeben werden. Als hauptsächliche Fehlerursache wurden Zugriffsrechte auf Betriebssystem-Ebene festgestellt. Aus Sicherheitsgründen wird der Zugriff auf die im Internet stehende Maschine nur über gesicherte Protokolle zugelassen. Die Fehlerbeseitigung wurde für den Monat Juni geplant.
Für die Katalogdatenerfassung wurde eine zusätzliche Maske im ERP implementiert. Zur vollständigen Implementierung der gewünschten Funktionalität wurden eine Reihe von zusätzlichen Änderungen auf Datenbankebene und in der Verarbeitung durchgeführt.
Die Schnittstelle für den Datenaustausch zwischen ERP und Shop-DB konnte endlich beendet werden. Die auf der Schnittstelle aufbauenden Jobs für den Datenimport und –export können nun entwickelt und danach getestet werden.
Um eine Kontrollmöglichkeit hinsichtlich der noch nicht im Katalog erfassten Artikel zu haben, wurde ein neuer Report generiert, der aus der Warenwirtschaft diejenigen Artikel extrahiert, die noch nicht im Katalog erfasst wurden. Damit soll es den Mitarbeitern auch im Falle wechselnder Artikel im Sortiment möglich sein, diejenigen Artikel benennen zu können, die noch keinen Katalogeintrag besitzen. Diese können dann zeitnah nachgepflegt werden.
Es wurden Tests hinsichtlich der Master/Slave bzw. Master/Detail-Sicht der Artikel durchgeführt. Für eine Menge von Testartikeln wurden zunächst deutsche Katalogtexte mittels der neu entwickelten Maske eingepflegt. Dabei traten jedoch einige Probleme, insbesondere mit zu knapp bemessenen Datenbankfeldern zutage, die in den nächsten Wochen behoben werden sollen.
Tests zur Einordnung der Artikel in Warengruppen (Hauptgruppe und Untergruppe) wurden im Online-Shop durchgeführt. Diese Tests verliefen erfolgreich.
Es traten folgende Probleme auf:
Nach der notwendigen Umbenennung einer Reihe von Artikelbildern traten Probleme mit der Zuordnung auf.
Lösung: Es wurde eine neue Lookup-Tabelle implementiert, die die Zuordnung der Artikelnummer zu den Dateinamen der Artikelbilder erlaubt.
Die Produktuntergruppierungen wurden geplant und umgesetzt. HTML-Templates für die Artikeleinzeldarstellung inklusive TÜV und eCl@ss wurden entwickelt. Stammdaten wurden angepasst und qualitätsgeprüft. Fragen der Einbindung von eCl@ss sowie der eCl@ss-Zertifizierung wurden in einem Termin mit der IW Consult geklärt.
Im Rahmen der Datenerfassung und -bereinigung für den Webkatalog wurden u.a. neue Katalogdaten erfasst sowie bestehende Daten auf Konsistenz geprüft. Zudem wurde ein Teil der Katalogtexte bereinigt. Diese Arbeit muss jedoch noch fortgesetzt werden.
Es wurde zunächst ein Konzept für einen Importfilter aus der FileMaker Datenbank in die MySQL-Datenbank entwickelt, auf dessen Basis danach der eigentliche Importfilter programmiert wurde. Der Test des Imports von Daten aus der Filemaker Datenbank in die MySQL-Datenbank mit Hilfe des entwickelten Importfilters wurde erfolgreich abgeschlossen.
Es wurde ein Export von Adressen aus David Fax vorgenommen. Der Versuch des Imports auf einem anderen System schlug jedoch fehl. Die Importfunktionalität von David Fax erwies sich als fehleranfällig und als unzureichend aussagefähig in Bezug auf die Angabe der Fehlerquelle. Eine interne Lösung konnte bisher nicht gefunden werden. Aus diesem Grund wurde ein Meeting mit einem Consultant von David Fax für Februar 2004 vereinbart.
Auch die Arbeiten am Faxsystem haben sich durch aufgedeckt Unzulänglichkeiten am Produkt, die in der ursprünglichen Projektplanung nicht erkannt und somit auch nicht eingeplant werden konnten, verzögert.
Der bereits im Dezember 2003 begonnene Codereview sowie die Codebereinigung wurden fortgesetzt.
Die Filemaker DB wurde in die Informix DB integriert. Dazu wurde ein Ladeprogramm entwickelt und ein Umlautfilter für die Filemaker DB erstellt.
Zur Beschleunigung der Entwicklung und zur besseren Sourcecode-Verwaltung wurden die PHP-Quellen in die Eclipse 2.1 IDE eingebettet. Es wurden erste Maßnahmen zur Codebereinigung durchgeführt. Messungen zur Bestimmung des Durchsatzes zwischen Server und Browser wurden begonnen. Diese sollen in den folgenden Wochen fortgesetzt werden. Die Planung zur ausschließlichen Inhouseverwaltung des Systems wurde begonnen. Erste Entscheidungen wurden getroffen, u.a. bzgl. der – zumindest anfänglichen - Nutzung einer 3Mbit DSL-Anbindung. Die Datenverteilung von der Informix DB auf die dem Webshop zugrunde liegende MySQL DB wurde diskutiert. Es wurde eine Planung zu ihrer Umsetzung vorgenommen. Erste Festlegungen sind bereits erfolgt.
Bei der Datenmigration von der Filemaker Datenbank auf die Informix Datenbank, auf der das Warenwirtschaftssystem beruht, sind Probleme aufgetreten, die mit der mangelhaften Qualität der eingepflegten Daten sowie mit der schlechten Struktur der Filemaker Datenbank zusammenhängen. Eine notwendige Umlautfilterung wird umgehend umgesetzt. Zudem wurde eine komplette Überarbeitung der Daten vorgenommen. Weiterhin musste die Anzahl der Felder der Filemaker Datenbank reduziert werden, um die Nutzbarkeit innerhalb der Warenwirtschaft zu gewährleisten. Diese Arbeiten wurden in Abstimmung mit der Fachabteilung vorgenommen.
Die Umstellung des CRM auf XML erfordert wesentlich mehr Zeit als ursprünglich geplant. Durch die an das CRM-Modul gestellten Anforderungen wurde teilweise die Grenze überschritten, unterhalb der PHP für kleine Anwendungen eine sinnvolle Realisierung mittels einzelner Skripte ermöglicht.
Um dem gehobenen Anforderungen gerecht zu werden, ohne gleichzeitig Abstriche bei der Wartbarkeit und Strukturiertheit der Software machen zu müssen, war es erforderlich, das Design einzelner Klassen zu überarbeiten. Es musste eine stärkere Parametrisierung als ursprünglich vorgesehen erfolgen. Obwohl der Ressourcenverbrauch über dem geplanten Limit lag, konnte jedoch eingeschätzt werden, dass die Vorteile der Methode überwiegen. Es wurde eine höhere Flexibilität erreicht, da die Anwendung mit einer minimalen Anzahl von notwendigen Klassen auskommt, die einzelne Aspekte der Anwendung realisieren. Die Module sind wesentlich einfacher umzustrukturieren als erwartet. Im Bereich der Projektauswertung wurde nochmals diskutiert, ob nicht doch der Einsatz von Java für die Realisierung derart anspruchvoller Module mit einem hohen Grad an Interaktivität sinnvoller gewesen wäre. Der Dienstleister verneinte dies, da im Java-Bereich der Entwicklungsaufwand noch um ein Vielfaches höher gewesen wäre.
Im Bereich Warenwirtschaft/CRM wurden im vergangenen Monat große Fortschritte erzielt, insbesondere die Performanzsteigerung durch das eingeführte Caching bringt für den Nutzer effektive Vorteile. Es müssen allerdings noch einige Anforderungen definiert werden, welche der Ansichten und Funktionalitäten externen Nutzern zur Verfügung gestellt werden. Die geplante Shoplösung wurde in ihrem Konzept bestätigt. Das Customizing des Frameworks ist bereits begonnen worden.
Die Zusammenführung der dezentralen Daten kann zum jetzigen Zeitpunkt nicht realisiert werden. Die Bestandaufnahme, Migration und Zusammenführung der dezentralen Datenbestände wurde auf Dezember verschoben. Mittels einer strafferen Zeitplanung soll der Vorgang bis Ende Dezember zum Abschluss gebracht worden sein.
Das Projekt befindet sich weiterhin in der Umsetzungsphase des Projektplanes. Für den Projektteilschritt Kundenauskunft/CMR wurde die Testphase begonnen. Die Module Allgemeine Kunden Auskunft, Artikelauskunft und CRM wurden intensiven Funktionstests unterzogen. Die erstellte Liste der Bugreports und Change-Requests wurde dem Dienstleister übergeben. Dieser führte umfangreiche Nachbesserungsarbeiten durch, die einen Großteil der beanstandeten Mängel bereits behoben haben. Die Dokumentation der einzelnen Module wurde weitergeführt und an die Bedürfnisse der zukünftigen Nutzer angepasst. Auch hier sind noch zusätzliche Aufwände notwendig, um diese auf einen für alle Beteiligten akzeptablen Stand zu heben.
Die Vorarbeiten in Bezug auf die Datenbankschnittstellen wurden noch nicht abgeschlossen. Zwar wurden die Daten auf der vorhandenen Unix Datenbank vervollständigt, bei einer Überprüfung der Datenbestände wurde allerdings festgestellt, dass die Daten aus der Filemaker Datenbank teilweise nicht mit den Daten der Unix Datenbank übereinstimmen. Alle Daten mussten eingelesen und abgeglichen werden, was mit erheblichem Mehraufwand verbunden ist. Die Arbeiten dauern derzeit noch an. Insbesondere die referenzielle Integrität der beiden Datenbanken spielt eine wichtige Rolle, da die Texte für den Shop aus der Filemaker-Datenbank kommen, während die übrigen artikelspezifischen Daten aus der Unix-Datenbank zufließen. Hier besteht insbesondere für die Mitarbeiter von Freund noch erheblicher Handlungsbedarf.
Die Urlaubssituation bei Freund führt dazu, dass insbesondere ein Teil der aufwändigen Arbeiten (händischer Datenabgleich, Einpflegen neuer Artikeldaten) nur sehr langsam voran kommen. Hier kann auch derzeit keine Abhilfe geschaffen werden.
