2 Implementierungsphase Produktdatenerfassung, Technische Umsetzung, Schnittstellen, Klassifizierung, Prozessanpassung
Durchführung geplant für Feb-Nov 2008
Start Feb 2008
Ende Nov 2008
 |
abgeschlossen |
 |
erfolgreicher Verlauf |
 |
Zeitverzögerung |
 |
Stolpersteine |
Testreihen haben viel Personalzeit gebunden
Abschluss des Release Kandidat 2 und Übergabe in den Echtbetrieb.
Folgende Berichte aus dem Projektverlauf liegen vor:
Das Arbeitspaket ist abgeschlossen.
Februar 2008
Die Erfassung von Produkt und Mediendaten kam aufgrund von Vorarbeiten und elektronische verfügbaren Quellen von Lieferanten zunächst gut voran. Die Vervollständigung der Daten wird jedoch erheblichen Aufwand erzeugen. Vor allem die Verfügbarkeit von Bilddaten sowie Detaildaten für die Produktattributierung ist bereits als unzureichend erkannt. Dieser Punkt wird fortlaufend behandelt.
Die große Planungsunsicherheit konnte im Projektverlauf schrittweise zurückgedrängt werden. Mit jeder getroffenen Entscheidung haben sich Planungen konkretisiert und konnten beschlossen werden. Bezüglich der technischen Plattform haben sich alle wesentlichen Fragen beantworten lassen.
Eine Schwäche liegt offensichtlich in der Planung der Datenlieferung von Seiten Ungermann. Die Mediendaten liegen nicht in ausreichender Menge und Qualität vor. Einige Daten müssen nachbeschafft werden. Papierdaten sind noch zu erfassen.
Die Vervollständigung dieser Daten ist eine wesentliche Herausforderung. Aufgrund der unerwartet geringen Fähigkeit der Zulieferer diese Daten in maschinenlesbarer Form zu liefern gestaltet sich die arbeit aufwändiger. Der geplante Aufwand ist sehr wahrscheinlich zu gering geschätzt.
Derzeit wird mit den wichtigen Zulieferern über die Lieferung zusätzlicher Dateninhalte gesprochen. Aufgrund der geringen Verbreitung der Klassifikationsstandards in der Branche wird davon ausgegangen, das ein erheblicher Teil der Gruppen und Attribute nicht in eCl@ss enthalten ist und dementsprechend eine zunächst interne Erweiterung des Standards durchgeführt werden muss. Im ERP System muss daher parallel eine eCl@ss und eine interne Kategorisierung implementiert werden.
April 2008
In der vorliegenden Phase wurde die Übernahme von Daten aus mehreren Lieferantenkatalogen für steckerfertige Geräte erprobt. Dabei wurden sowohl die Verwendung von Dokumenten im PDF Format wie verfügbare Informationen in Webseiten der Hersteller evaluiert. Die Kataloge wurden auch auf die Möglichkeiten zur Automatisierung der Produktdatenübernahme geprüft. Ein Grundstock der Daten konnte durch Import strukturierter Daten und deren manuelle Anreicherung in Office Formaten erzeugt werden.
Eine weitere Menge kann nur durch die Übernahme per Copy & Paste übertragen werden.
Die Übernahme und Aufbereitung der Bilddaten ist besonders aufwändig. Um ein einheitliches Aussehen der Bilder zu erreichen, müssen die Ausgangsformate aufwändig nachbearbeitet werden. Um dies zu leisten wird die Einschaltung eines weiteren, auf Bilddatenaufbereitung spezialisierten, Dienstleisters geprüft.
Die Lieferanten waren durchweg nicht oder nur sehr eingeschränkt in der Lage direkt übernehmbare Produktdaten zu liefern. Dies ist insbesondere darin begründet, dass sie die Erstellung ihrer Kataloge und Webseiten teilweise oder vollständig outgesourct haben. Sie sind zwar Eigentümer der Daten, erhalten diese aber nur gegen Kostenersatz in den gewünschten aufbereiteten Formaten. Im Ergebnis können diese Daten nur mit erheblichem manuellem Aufwand übernommen werden. Die Arbeitsweise ist dabei von Copy & Paste und manueller Nachbearbeitung geprägt. Eine mittelfristige Lösung dieses Missstandes wird mit den Lieferanten diskutiert. Eine Kostensteigerung in diesem Punkt sowie Nacharbeiten außerhalb des Projektes sind absehbar.
Das Arbeitspaket ist abgeschlossen.
Februar 2008
Die Beschaffung von Hard- und Software ist in Detailplänen abgebildet. Sie kann problemlos vonstatten gehen. Der Dienstleister erfüllt diese Aufgaben selbständig. Für die Entwicklung stellt der Dienstleister zunächst eine vollständige Umgebung zur Verfügung.
Das Arbeitspaket ist abgeschlossen.
März 2008
Die Anpassungen des ERP für die Aufnahme der Produktdaten und der Klassifizierung wurde begonnen. Die technischen Vorplanungen hierfür werden mit den Möglichkeiten des ERP abgeglichen. Nächster Schritt wird die Planung der BMEcat Schnittstelle sein.
Die Notwendigkeit, neben eCl@ss noch weitere interne Klassifizierungen abzubilden und damit mehrere unabhängige Kategorisierungen im System zu haben stellt eine Herausforderung dar. Diese Klassifizierungen müssen bei der Eingabe aber auch beim Ausgeben der Produkte in Katalogen oder an externe Systeme verwendbar sein. Daher muss bei Ausgaben auch immer wählbar sein, nach welchem Standard die Gruppierung der Daten erfolgen soll. Dieses Detail wird vom Dienstleister auf seine Auswirkungen für den Implementierungsaufwand derzeit untersucht.
Darüber hinaus haben sich unerwartete Probleme bei der Installation er OfBiz Plattform ergeben. Es ist ganz offensichtlich nicht einfach, eine stabile lokalisierte Version für das Betriebssystem DEBIAN aus dem Internet zu beziehen. Auch die Dokumentation ist hier nicht hinreichend. Inzwischen konnte eine Version erstellt und stabilisiert werden. Die Lösung lag auch hier in der Sachkenntnis der Dienstleister und deren Bereitschaft, die Mehraufwände aufgrund der ausgesprochenen Empfehlung in Eigenleistung zu erbringen.
Mai 2008
Die Anpassung des ERP Systems wird planmäßig fortgesetzt. Die Arbeitspakete werden gemäß der erarbeiteten Spezifikationen abgearbeitet.
Hauptpunkte der Realisierung sind in dieser Phase:
- Verwaltung der Produktdaten
- Implementierung des Preismodells
- Implementierung der Kalkulationsfunktionen für Verkaufspreise
- Suchfunktionen
- Reportfunktionen und Listenausgabe.
Gemeinsam mit dem Dienstleister wurde die Konzeption der Kalkulationsfunktionen vom Listenpreis des Lieferanten über Einkaufsrabatte bis zum Verkaufspreis von USK durchgegangen. Eine besondere Schwierigkeit liegt in den unterschiedlichen Kalkulationsverfahren für die wesentlichen Produktgruppen: Ersatzteile, steckerfertige Geräte und Anlagenprodukte haben jeweils unterschiedliche Anforderungen und Kalkulationen. Aus diesem Grund teilt sich der Katalog und alle damit zusammenhängenden Regeln und Funktionen in drei individuelle Produktgruppen.
In der Umsetzung wurde schnell klar, das die Nutzung von Open Source Software keine unbegrenzte Freiheit bietet. Ähnlich jedem kommerziellen Produkt haben die Plattformen Grundannahmen, Benutzerstandards und hinterlegte Prozesse.
Der Dienstleister musste die Vorstellungen aus dem Pflichtenheft mit den Standards der Open Source Software abgleichen und zu jeder Funktion Lösungsvorschläge machen. Der Abstimmungsaufwand ist dabei recht hoch und fordert hohe Aufmerksamkeit des Auftraggebers. Die hierfür notwendige Zeit und die Frequenz in der Entscheidungen getroffen werden müssen sind unerwartet hoch. Diese Aufgabe kann nicht ausschließlich nebenbei erledigt werden und fordert auch einige Einarbeitung im Fachbereich.
Der Dienstleister stellt nach jedem Entwicklungsabschnitt ein Modell der Anwendung im Internet über einen gesicherten Zugang zur Verfügung. Dort kann unabhängig getestet und experimentiert werden.
Der Aufwand zur Abstimmung der Entwicklungsergebnsse hat sich unerwartet wesentlich erhöht. Die Begründung ist hier in folgenden Argumenten zu finden:
- Es wird keine neue Software entwickelt, sondern ein Open Source System angepasst.
- Bedienphilosophie und Einzelheiten sind vom System bereits vorgegeben
- Die Entscheidungsfreiheit ist damit wesentlich eingeengt
- Das Ergebnis muss nicht mit der Vorstellung des Auftraggebers konform sein.
Aufgrund dieser Tatsachen werden immer wieder Ergebnisse hinterfragt und alternative Lösungen gefordert. Dies erhöht den geschätzten Aufwand bei Endkunde und Implementierer signifikant. Die einzig mögliche Lösung ist eine Disziplinierung sowie ein Trainingseffekt für die Abstimmung von geplanter Implementierung und der Kundenvorstellung wie die Funktion im System hinterher aussieht. Immer öfter muss die Diskussion zugunsten der Planeinhaltung jedoch abgebrochen werden.
Juni 2008
Der Juni war geprägt durch die Arbeiten am Katalogausgabemodul für die Produktdaten.
Die Entwickler haben den Stand der Arbeiten vorgestellt und einen ersten Einblick in die Funktion gegeben. Das Modul kann auf Basis von dynamischen Abfragen Listen erzeugen. Aus diesen Listen kann dann wiederum eine manuelle Auswahl getroffen werden. Die manuelle Auswahl ist maßgeblich für die auszugebenen Produkte. Die Ausgabe erfolgt in Dateiform oder als Dokument. Die Formatierung des Dokumentes muß in einem Template vorgegeben werden. Die Ausgabesteuerung ist daher sehr stark auf ein definieres Format festgelegt. Neue Formate müssen ggf. durch Programmierung angepasst werden.
Aufgetretene Probleme und Lösungen:
Die Open Source ERP Lösung bietet keinen einem kommerziellen Produkt vergleichbaren WYSIWYG Editor Funktion zur Gestaltung der Druckausgaben. Diese Funktion ist nur mit hohem Aufwand nachzuentwickeln.
Die Limitation in diesem Punkt muss hingenommen werden. Das Projektbudget kann diese Funktion nicht nachfinanzeren. Es muss daher - um eine praktische Einsetzbarkeit zu gewährleisten - besondere Sorgfalt auf die Gestaltung des Grundformates gelegt werden.
Aus diesem Grund wurden die Arbeiten an diesem Modul unterbrochen. USK muss zunächst eine Formatierung entwerfen und dokumentieren, die sinnhaft erscheint. Auch diese Zulieferung kommt unerwartet und erzeugt beim Auftraggeber entsprechenden Aufwand. Der Aufwand ist aber im Rahmen des Gesamterfolges notwendig.
Juli 2008
Thema der Arbeiten im Juli ist die Datenübernahme aus externen Systemen sowie die Exporte an externe Systeme. Dabei werden die Datenstrukturen innerhalb des ERP-System so mit Daten bedient, dass die externen Daten korrekt im Rahmen der Semantik des ERP-Systems übernommen werden. Die Schnittstellen sind in diesem Fall Batch-orientierte Schnittstellen, die jeweils eine Sammlung von Datensätzen zu einem Zeitpunkt übernehmen.
Die Schnittstellen müssen sich auf die Formate und Inhalte der jeweiligen Partner einstellen könnnen. Jeder Lieferant verwendet potentiell unterschiedliche Formate, Inhalte und Ausgabestrukturen. Die Verbreitung von weitgehend standardisierten Formaten wie BMEcat hat sich als gering herausgestellt. Die Mehrzahl der Liefranten bietet CSV- oder TXT-Dateien als Übernahmeformat.
Es hat sich im Rahmen der Entwicklung herausgestellt, dass das ERP System OfBIZ eine sehr komplexe innere Struktur hat. Die Daten, die semantisch zu den Produktdaten gehören sind über vielfache Datenstrukturen, Tabellen und Funktionsmodule verstreut. Zu jeder Anforderung haben sich damit eine Menge von möglichen Implementierungen ergeben.
Mit jeder getroffenen Entscheidung hat man gleichzeitig die Möglichleiten für nachfolgende Entscheidungen eingeschränkt.
Insbesondere die Realisierung der Merkmalleisten aus eCl@ss hat sich dabei als problematisch erwiesen. Die gewählte Implementierung konnte zwar eine flexible Erweiterbarkeit der Merkmalsleisten und damit eine grundsätzliche Fähgkeit herstellen, zukünftige eCl@ss-Definitionen aufzunehmen. Leider hatte diese Implementierung zur Folge, dass die Datenübernahme in diese Struktur sehr komplex wird. Jeder Importvorgang von externen Produktdaten muss in eine mehrstufige Importroutine aufgelöst werden. Dabei ist gleichzeitig sicherzustellen, dass
- alle Lieferanten mit Stammdaten bekannt sind
- alle eCl@ss Atrribute dem System vorher bekannt sind.
Ist eine der Vorraussetzungen nicht gegeben, so wir der Import Fehler aufweisen.
Eine Anpassung des eCl@ss-Standards hat ebenfalls komplexe Folgen, die im Einzelfall bewertet werden müssen. Parallel ist die Registrierung der eCl@ss-Definitionen sehr aufwendig und erfolgt nicht automatisiert. Diese Schwächen haben dazu geführt, dass die Anwendbarkeit der gewählten Realisierung kritisch überprüft werden muss. Es kann dazu kommen, dass dieser Teil der Relisierung komplett überarbeitet werden muss.
August 2008
Die fortlaufende Implementierung der Funktionen im Bereich Katalogausgabe wurde planmässig fortgesetzt. Die Revision der Lösung zum Thema eCl@ss und Datenimport wurde in einem Workshop besprochen. Es werden im August alternative Realisierungen entworfen und im September vorgestellt. Ziel ist es, die Produktdatenpflege zu vereinfachen und Abhängigkeiten im System so weit zurückzudrängen, das Datenimporte durch Endanwender möglich sind. Derzeit ist jeweils Entwickler Know-how gefragt.
Die Diskussion um die grundlegenden Eigenschaften der Lösung hat sich fortgesetzt. Obwohl OfBiz einen Fundus von Funktionen bietet und zu vielen Themen Ansätze zeigt, erhärtet sich der Eindurck, dass die Module nicht zu Ende gedacht und nicht zu Ende entwickelt sind. Aufgrund der komplexen Struktur ist stets ein aufwendiges Reengineering der bestehenden Logik notwenig. Erst dann können sinnvolle Anpassungen gemacht werden. Die Dokumentation ist in vielen Fällen unzureichend.
Die Abhängigkeiten der Datenhaltung und der Produktstruktur im ERP-System verursacht zudem einen Aufwand, der sehr nahe an einer völligen Neuentwicklung liegt. Gleichwohl sind stets Kompromisse notwendig, die man bei einer Neuentwicklung nicht machen muss.
Insgesamt hat sich folgende Meinung gebildet:
- Soll die Software so wie sie ist oder nur im kleinen Umfang geändert werden
und hauptsächlich konfiguriert werden, dann eignen sich in dem Bereich auch
unter Umständen Open Source Produkte.
- Sollen Programmabläufe, Refactoring und weitere Änderungen an vielen Punkten
in der Software geändert werden, so ist dies immer aufwändig wegen den hohen
bestehenden Abhängigkeiten. Ab einer bestimmten Komplexität der Software ist ein
sehr großer Aufwand notwendig.
Das Arbeitspaket ist abgeschlossen.
September 2008
Die Klassifizierungsarbeit ist nicht im geplanten Fortschritt. Dies liegt aber auch an der Erkenntnis, das die USK Produkte nur in sehr geringem Umfang in eCl@ss enthalten und aufgrund der Spezialisierung der Produkte im Bäckereibereich zu einer Vielzahl an Standardisierungsvorschlägen führen wird. Diese Arbeiten können jetzt, da die Verwendung der Klassen in OfBiz klarer ist fortgesetzt werden (siehe Test und Qualitätssicherung)
Das Arbeitspaket ist abgeschlossen.
Mit den im September gemachten Fortschritten steht jetzt erstmals ein benutzerfreundliches und übersichtliches Werkzeug bereit. Das Produkt kann in diesem Zustand erste Endanwendertests durchlaufen. Hierzu hat USK vorsichtig eine kleine Menge an Demonstrationsdaten eingepflegt. Das jetzt lebende Beispiel wurde den Mitarbeitern vorgestellt. Anhand der Beispiele wurde in kurzen Planspielen besprochen, wie sich die interne Organisation dieses Werkzeug zunutze machen kann. Dabei wurde kein Veränderungsdruck ausgeübt, sondern gezielt die Ideen und Vorstellungen der Mitarbeiter abgefragt. Die Reaktion war positiv und die aktive Teilnahme an den Gedankenspielen bereitet die Einführung der Software vor.
Aus den Gesprächen wurden erste Nutzungsszenarien entwickelt:
- Suche in den Produktlisten
- Telefonauskunft über Artikel
- Druck von Produktunterlagen.
In Ergänzung zu den vorbereitenden Szenarien wurde die eCl@ss Klassifizierung wieder aufgenommen. Weiterhin stellt sich der Standard als nicht ausreichend spezialisiert auf die Branche dar.
In technischer Hinsicht wird untersucht, wie administrative Tätigkeiten bei der Datenpflege automatisiert werden können. Auf Basis der OfBiz Plattform und der Datenlieferung der Lieferanten ergeben sich die klassischen Import Probleme:
- Spezialität der Importroutinen für jedes gelieferte Format
- Pflegeaufwand bei Änderungen
- Abstufung der Routinen, um die Belange des speziellen Datenmodell in OfBiz zu berücksichtigen
Ein grafisches Werkzeug zur Konfiguration der Importe liegt leider nicht vor. Daher musste eine Software, die auf die besondere Datenstruktur ausgelegt ist, klassisch programmiert werden. Die Nachteile dieser Lösung liegen in der geringern Änderbarkeit und der Anfälligkeit gegenüber fehlerhaften oder variierenden Dateninhalten.
Aufgetretene Probleme:
- OfBiz Standard Import nicht flexibel genug
- eCl@ss Standard hat geringe Abdeckung in der Branche
- Anwender fürchten Komplexität der Software
Das Arbeitspaket ist abgeschlossen.
September 2008
Die Anpassungsarbeiten wurden im September ausgesetzt um eine umfassende Prüfung des Leistungsstandes durchzuführen. In mehreren Workshops wurden die bereits realisierten Funktionen geprüft und getestet. Darauf ausbauend hat der Dienstleister Änderungen vorgenommen und eine große Zahl nicht benötigter Komponenten aus der Open Source Plattform ausgeblendet.
Diese Bereinigung hat zu einer wesentlichen Verbesserung der Benutzerfreundlichkeit, die intensive Zusammenarbeit auch zu einem besseren Verständnis der Endbenutzer geführt.
Die Gespräche wurden teilweise mit Ortsterminen, in großem Umfang aber auch mit Mitteln der Fernpräsentation durchgeführt. Dabei wird ergänzend zum Telefon mit Freisprecheinrichtung eine Online Konferenz mit der Möglichkeit, gemeinsam in der Plattform zu arbeiten, benutzt. Diese Möglichkeit hat eine kostengünstige und sehr jederzeit spontan mögliche Abstimmung ermöglicht.
Das Gesamtbild der Anwendung ist jetzt den Beteiligten klarer und die Zuversicht in die grundsätzliche Anwendbarkeit ist zurückgekehrt. Dieser wichtige Grundlagenschritt war notwendig, hat aber zusätzlichen Aufwand erzeugt und die Arbeiten an den Produktdaten sowie die geplante Arbeit an den Betriebsprozessen verzögert.
Die beschriebene Komplexität der Software hat die Anwender verunsichert. Das Projekt hatte sehr stark funktionale Aspekte fokussiert und die Anwenderfreundlichkeit zurückgestellt. Obwohl dies inhaltlich unkritisch war hat es dennoch zu einem schlechten Gefühl der Anwender geführt. Mit dem verlorenen Grundvertrauen ist auch die Motivation an der Mitarbeit gesunken.
Die gesunkene Motivation hat sich direkt auf die Arbeitsfortschritte ausgewirkt. Abhilfe hat erst die Intensivierung der Feedbackrunden mit Anwendern und Entwicklern gebracht.
November 2008
Im Rahmen der Testphase wird der Produktivbetrieb der Anwendung simuliert. Dafür ist der Betriebsaufbau des Systems abgeschlossen worden. Das System wird mit Echtdaten befüllt. Dabei wurden folgende Testfälle durchgespielt:
- Konvertierung der Produktdaten aus einem Ausgangsformat
- Einlesen der Daten in die Datenbank
- Durchführung der Importspezifischen Bereinigungsroutinen.
Danach wird die geladenen Datenbank per GUI abgefragt.
Es sind folgende Methoden angewendet worden:
- White Box Tests: Ausgehend von bekannten Funktionen wurde kontrolliert, ob bestimmte Datenkonstellationen die gewünschten Ergebnisse im System erzeugen. Dies ist insbesondere bei allen berechneten Feldern wichtig. Darüber hinaus sind die Speicherung von Bilddaten sowie die Übernahmen von fehlerhaften Daten geprüft worden. An den Reaktionen können auf diese Weise Implementierungsfehler nachgewiesen werden.
- Bei auftretenden Fehlern sind weitere Tests gemacht worden, um die Systematik des Fehlers zu erkennen. Beschriebene Fehler sind an den Hersteller zur Fehlerbehebung gemeldet worden.
- Black Box Testing: Bei diesen Tests wird aus Endbenutzersicht ein zufallsgesteuertes Bedienen des Systems simuliert. Um dem Vorgehen Struktur zu geben sind vorher Testfälle erarbeitet worden. Diese sind z.B.
- Einlesen von Daten
- Anlagen von Daten
- Editieren von Daten
- Suchen von Daten
- Ausführen komplexer Suchen
- Ausgeben von Produktblättern
- Ausgeben von Exportdaten
- Erstellen von Berichtslisten
- Ausgeben von Angeboten
- Anlegen komplexer Produkte
Auch in diesem Bereich wurden Fehlerlisten erzeugt, die vom Hersteller dann abgearbeitet und in Form korrigierter Versionen wieder zur Verfügung gestellt wurden. Jeder gemeldete Fehler wurde nachgestestet und bei Erfolg dann in der Fehlerliste quittiert. Nach etwa 2 Wochen wurden die kurzen Iterationen gegen ein stufenweises Vorgehen mit längeren Testabschnitten ausgetauscht. Die geringere Fehlerrate zwischen Release Kandidat 1 und 2 hat eine längerfristige Beschäftigung mit dem Produkt erfordert
Nach dem Release Kandidat 2 konnte bereits eine praxisnahe Produktionsphase durchgeführt werden. Auch hierbei sind immer wieder Anmerkungen der Klassen
1 : kritische Funktion, 2: wichtige Funktion, 3: Zusatzfunktionen gemacht worden. Die gewonnenen Daten sind priorisiert und an den Hersteller weitergeleitet worden. Dieser hat die Klassen 1 und 2 direkt bearbeitet und behoben. Die Klasse 3 wurde jeweils als Zusatzfunktion angeboten und auf Basis einer Kosten/Nutzen-Rechnung zur Realisierung beauftragt.
Der November schließt mit dem Abschluss des Release Kandidat 2 und der Übergabe in den Echtbetrieb.
Aufgetretene Probleme und Lösungen
- Testreihen haben viel Personalzeit gebunden
- Systematischer Ansatz hat stark zur Strukturierung und effektiven Arbeit beigetragen. Zudem konnte auf diese Weise eine planbare Zeit für die Mitarbeiter organisiert werden.
- Die Einführung von Fehlerlisten mit definiertem Format und Statusmarkierung hat die Kommunikation mit dem Dienstleister erleichtert.
- Endbenutzer haben viele neue Funktionswünsche kreiert. Diese sind z.T. kostspielig umzusetzen.
