Get in Touch
With Our Experts
+49 711 / 75886-600
Bitte schreiben Sie eine Nachricht
Weiter
Wie können wir Sie erreichen?
Bitte klicken um Validierung zu starten
Zurück
Absenden
Vielen Dank für Ihre Nachricht!
Wir werden uns so bald wie möglich bei Ihnen melden.
Fenster schließen

Highway to PIM – #4: technische Implementierung

15. Februar 2016
Ein PIM-System bietet Unternehmen enorme Vorteile im Management von Produktdaten. Die zentrale Verfügbarkeit für sämtliche produktbezogenen Daten sowie die umfangreichen Möglichkeiten der Automatisierung sparen Unternehmen wertvolle Zeit und Ressourcen.

Voraussetzung ist jedoch, dass das System gut gewählt, die Datenstruktur sowie die Prozesse perfekt auf das Unternehmen abgestimmt wurden. Die grundsätzliche Vorgehensweise hierzu sowie hilfreiche Tipps konnten Sie bereits in den ersten drei Artikeln dieser Serie lesen:

#1: Der Business Case
#2: Auswahl des PIM-Systems
#3: Business Blueprint

Ihr Businessplan steht, das System wurde evaluiert und auch ihr Business Blueprint ist fertig? Dann auf zum nächsten Schritt: Die technische Implementierung Ihres PIM-Systems.

Die Technical Design Documentation (TDD)

Falls Sie nach den ersten Schritten bereits denken „genug von Konzepten, ich will jetzt loslegen“, werden Sie jetzt vermutlich enttäuscht sein. Denn auch die technische Umsetzung will genau geplant sein. Im technischen Detailkonzept, meist TDD genannt, werden die im Business Blueprint definierten fachlichen Anforderungen in konkrete technische Details übertragen. Es beschreibt die technische Architektur: Welche Formate werden erzeugt bzw. benötigt? Wie funktioniert die Transformation und Übergabe der Daten? Wie werden die Schnittstellen und Customizings umgesetzt? Aber auch grundsätzliche Vorgaben wie Coding Conventions, die Notwendigkeit eines Source Code Repositories oder Performance-Anforderungen sollten an dieser Stelle definiert werden. Ein weiterer wichtiger Bestandteil Ihres technischen Konzepts ist ein DoD – die Definition of Done. Also: Wann ist eine Implementierung/Customizing als fertig anzusehen? Hierzu werden zum einen klare Erwartungen und Abnahmekriterien definiert. Was muss das jeweilige Customizing/Implementierungsteil können? Welche UseCases stehen dahinter? Aber auch konkrete Testcases sind für eine DoD entscheidend: Wie wird getestet, ob die Implementierung funktioniert? Beschreiben Sie hier Schritt für Schritt das konkrete Testvorgehen, als auch die geplanten Ergebnisse – sowohl im Ausgangs- als auch im Zielsystem.

Ein typisches Beispiel ist die Shopversorgung: Sie benötigen konkrete Details darüber

  • Wie wird übertragen?
  • Was wird übertragen?
  • Wie wird es technisch umgesetzt?
  • Wie wird es geprüft?

Betrachten Sie dazu zunächst die Vorgaben des Shops genauer: Welches Übergabe- bzw. Importformat ist gefordert? Bei Standards, wie etwa dem Katalogstandard BMEcat, klären Sie zudem, ob unternehmensspezifische Erweiterungen notwendig sind.
Der nächste Schritt ist die Detaildefinition des Datenmappings. Hier definieren Sie die tatsächlichen Inhalte und Inhaltsregeln:

  • Welche konkreten Daten werden in welchen Feldern übertragen?
  • Gibt es Abweichungen bei den Feldlängen von Quell- und Zielsystem?
  • Wie wird mit abweichenden Datentypen umgegangen?
  • Wie setzen sich Feldinhalte von z.B. Langtexten oder Titel zusammen?
    Werden hier mehrere Quellfelder und Attribute in ein Zielfeld verkettet?

Nach der Definition des Detailmappings muss natürlich geklärt werden, wie die Datenübertragung stattfinden soll und wie diese gesichert, protokolliert und überwacht wird. Übertragen Sie die Daten als Paket über ein asynchrones SFTP? Wie stellen Sie den erfolgreichen Transport ins Zielsystem sicher? Gibt es mehrerer komplexe Routen die eingehalten werden müssen? Wird der Einsatz eines entsprechenden Enterprise Service Bus benötigt?
Und zu guter Letzt: Tests, Tests und nochmal Tests. Werden reine Komponenten bzw. Unit Tests eingesetzt? Gibt es Integrationstests? Wie sind diese aufgebaut und welchen Erfolgskriterien unterliegen Sie? Lässt sich eine Testautomation erreichen?

In unserem Beispiel wären wenigstens die folgenden Punkte zu testen:

  • Ist die erstellte Datei valide (z.B. XML Schema Validierung)?
  • Sind spezielle Inhaltslogiken korrekt durchgeführt worden?
  • Wurde die Übertragung korrekt durchgeführt?
  • Akzeptiert das Zielsystem die Datei und verarbeitet sie korrekt?
  • Werden die ausgegebenen Daten im Shop korrekt dargestellt?

Im Grunde klingen all diese Tests sehr simpel, müssen aber streng genommen alle mit klaren Vorgaben, Durchführungsanleitungen und zu erwartendem Ergebnissen versehen werden.
Kurzum: Es werden klare Testfälle benötigt.
Das TDD beinhaltet somit sämtliche technischen Anforderungen, Funktionsaufrufe als auch das grundsätzliche Regelwerk. Es bildet die Basis jeglicher Implementierungsarbeit und ist ebenso als abgenommene Implementierungsanleitung anzusehen. Ohne dieses Bekenntnis sind spätere Streitgespräche darüber, ob die Implementierung nun korrekt durchgeführt, abgeschlossen aber auch ausreichend getestet wurde, vorprogrammiert.

Vorbereitung und Umsetzung

Nun können Sie mit der Vorbereitung der technischen Implementierung beginnen. Brechen Sie dazu das gesamte Projekt in einzelne Arbeitspakete herunter, denen Sie Ressourcen und Tasks zuweisen. Hierfür bietet sich (natürlich bereits auch schon zu einem früheren Zeitpunkt nützlich) eine entsprechende Software zur Organisation und Planung von Tasks und Projekten an (z.B. JIRA, Assembla, Mantis oder ähnliches). Hierüber lässt sich sowohl eine Entwicklungsdokumentation als auch eine Kollaboration der notwendigen Ressourcen sehr einfach organisieren und durchführen.
Dabei ist es völlig unerheblich welche Vorgehensweise Sie in ihrem Projekt gewählt haben. Ob Sie sich nun für ein agiles Vorgehen mit hoher Schlagzahl und schnellen Sprints von kleinem Umfang entschieden haben oder hingegen für ein Wasserfallmodell in Größenordnung der Niagarafälle. Eine entsprechende Organisation und Planung der Aufgaben und Verantwortlichkeiten in möglichst kleine Einheiten ist Pflicht!
Auf die einzelnen Vor- und Nachteile, Unterschiede und Einsatzszenarien für die verschiedenen möglichen Vorgehensmodelle möchte ich an dieser Stelle nicht näher eingehen, da Sie definitiv den Rahmen sprengen würden und genug Material für einen eigenen Artikel liefern. Daher in aller Kürze die Quintessenz zwischen Iterativ-, Sequentiell-, Spiral- oder Misch-Modellen: Sie brauchen in jedem Falle klare Zieldefinitionen auch für technische Umsetzungen und müssen diese durchführen. Ob Sie dies nun in wenigen großen oder in vielen kleinen Schritten gehen, fest steht dass sie jeden Schritt auch tatsächlich gehen müssen. Ok, Sie haben nun also eine TDD und eine DoD (oder viele kleine?), haben Arbeitspakete gebildet und den verantwortlichen Ressourcen zugewiesen. Dann: Let’s go! Lasst die Implementierungen beginnen!
Ein letzter Tipp aus der Praxis: Unser Team setzt Entwicklungen immer zuerst lokal auf einem eigenen Testsystem um. Funktioniert dort alles einwandfrei – auch im Zusammenspiel mit anderen Implementierungsteilen – wird es auf einem Testsystem beim Kunden deployed. Optimaler Weise folgt dann ein Rollout in einem Stagingsystem dessen Hardwareumgebung möglichst identisch mit dem Produktivsystem ist. Erst wenn in sämtlichen Phasen alle zuvor definierten TestCases einwandfrei abgenommen wurden, erfolgt der Rollout auf dem Produktivsystem. Durch diese mehrstufigen Testphasen stellen Sie sicher, dass Ihr Produktivsystem nicht durch Fehlentwicklungen beeinträchtigt wird.
Es gibt natürlich noch eine sehr große Menge an weiteren Dingen, die im Rahmen von technischen Implementierungen zu beachten sind. Wurde z.B. ein Code-Freeze vereinbart? Ist die Skalierbarkeit einer Entwicklung ein Thema? Ist ein scale out möglich oder nur ein scale up? Wird eine Continuous Integration eingesetzt? Ist das Zielsystem Unicode-fähig?
Einfach zu viel, um alles in einen einzigen Artikel zu packen. Daher bleiben wir vorerst beim bisher Beschriebenen und weisen darauf hin, dass in der Technik mehr steckt als ein stumpfes runterprogrammieren von Algorithmen.

Highway oder Holperweg?

Auch wenn es sich hierbei um den letzten Artikel der Serie „4 Schritte zum PIM“ handelt, muss klar sein, dass dies auf keinen Fall der letzte Schritt eines PIM-Projekts ist. Vernachlässigen Sie bitte nicht die kontinuierliche Weiterentwicklung und das Application Management Ihres Systems. Die Freude der User und der Nutzen des Systems für Ihr Unternehmen würden nicht lange währen.

Wir hoffen, wir konnten Ihnen mit dieser Serie hilfreiche Tipps für Ihr PIM-Projekt geben und dazu beitragen, dass es eben kein allzu holpriger Weg wird. Gerne stehen wir Ihnen auch mit praktischer Unterstützung zur Seite. Unser Team freut sich, von Ihnen zu hören und berät Sie gerne unverbindlich: sales@parsionate.com

Ihr Webbrowser ist veraltet

Aktualisieren Sie Ihren Browser damit diese Webseite richtig dargestellt werden kann.

Zur Infoseite browser-update.org