Warum es ein Qualitätsmerkmal ist, wenn man ein PIM-System auch schnell wieder los werden kann.

Lasst uns ein paar Dogmen schleifen:

  1. Der deduktive Ansatz steht für gut geplant und heilbringend.

Einer PIM-System-Auswahl geht ein langer Prozess der Ist- und Soll-Analyse voraus. Zum ersten Implementierungsschritt kann es erst nach vielen Monden, Excel-Arbeitsblättern, Flip-Charts und Sitzungskeksen kommen. – Ist das so?

Warum nicht schnell – also wirklich schnell – ins System gehen? Es gibt immer – immer ein Lernprozess am entstehenden Daten-Model. Doch hier kann es eben sein, dass die Lösung den steilen Einstieg nicht gestattet, weil Lern- und Onboarding-Kurve eher flach und lang sind.

Es passiert in der Praxis, dass der lange, deduktive Weg gegangen wird, weil es sich a) professionell anhört und b) vom Berater angeraten wurde. Doch dann wird ungeachtet der erzeugten Listen und Pläne agil-darwinistisch gearbeitet. Oder weniger preziös – es gibt beeindruckende Pläne und Analysen … und das Herumwurschteln der Wirklichkeit.

Um Missverständnisse vorzubeugen – das fatalistischen Herumwurschteln soll nicht gepriesen werden. Herumwurschteln bleibt Herumwurschteln und soll nicht mit „Agilität“ verwechselt werden. Agilität braucht eine Menge preußische Disziplin, aber das wäre ein anderer Blogbeitrag.

Vielmehr hier die These, dass agile Methodik für die Erarbeitung des PIM-Konzepts selbst der realistische Ansatz ist – es geht hier noch nicht mal um die Implementierung selbst. Wer diese These teilt, benötigt ein PIM-System, dass keine Entwicklungsplattform ist, sondern ein Standardprodukt – oder anders ausgedrückt, wenn man sich zu lange mit dem PIM-System statt mit dem Produktinformationsmanagement selbst beschäftigen muss, ist es kein gutes System.

  1. Nur ein PIM-System kann echte PIM-Funktionalität bieten.

Es gibt CMS-Systeme, Webshop-Systeme, DataHub-Syteme, ERP-Systeme, die PIM-Funktionalität anbieten. PIM-Hersteller würden das „eingeschränkte PIM-Funktionalität“ nennen. Aber wenn das reicht – reicht es.

So könnte man ja umgekehrt von „überflüssiger PIM-Funktionalität“ sprechen. Das ist nicht die Diskussion „Best of Breed“ versus „integrative Lösung“. Es ist die Aufforderung nach Funktionalität und nicht nach Systemen zu schauen. Es ist sogar die Antwort erlaubt, die PIM-Funktionalität, die benötigt wird, mit einer Excel- oder Access-Anwendung zu erfüllen (für einen internen Proof of Concept sowieso). Verändern sich Anforderungen an die Funktionalität, verändern sich die Möglichkeiten der korrespondierenden Systeme, die man im Einsatz hat, muss man ein PIM-System auch mal wieder De-Implementieren können.

  1. Datenexporte auf allen Ebenen – so schnell geht das nicht.

Doch, muss – das ist ein echtes Qualitätsmerkmal. Damit ist die API-Ebene gemeint, dass dokumentiert auf Entitäten zugegriffen werden kann (SOAP / REST).

D.h. wenn ein Datenarchitekt sich mit dem Datenmodell des PIM-Systems beschäftigen muss, um Drittsysteme anzubinden ist das kein Qualitätsmerkmal. Damit ist auch die Applikationsebene gemeint. PIM-User müssen in der Lage sein Excel-Exporte aus all ihren Zusammenstellungen zu generieren. Wenn dazu ein Consultant angerufen werden muss, ist das kein Qualitätsmerkmal. Wenn man mal ein PIM-System ablösen will oder muss, ist das gut, wenn man an alle Daten aller Entitäten kommt und wenn dieser Teil richtig gut ist, braucht man es vielleicht gar nicht ablösen.

  1. Ein PIM ist nur für Produktinformationen da, man darf es nicht verbiegen mit anderen Entitäten.

Das ist wirklich ein Satz für das Daten-Feuilleton, hat aber nichts mit der Praxis gemein. Schlechte PIM-Systeme erkennt man daran, dass sie eine Produkt-Tabelle haben. Gute PIM-Systeme haben Objekte vom Type Produkt und kommen mit einem flexiblen Datenmodell um die Ecke, das einem erlaubt korrespondierende Entitäten zu modellieren. Mit „korrespondierende Entität“ ist zum Beispiel der Hersteller gemeint. Es ergeben sich für Händler oft die Notwendigkeiten, viel über die Hersteller der Produkte, die sie anbieten erzählen zu wollen oder zu müssen. Das will auch im PIM geschehen und nicht in einem HIM (Hersteller-Informations-System). Das kann noch viel weitergehen, wo Gelegenheiten – da Experimentierfreudigkeit. Es werden Dinge gemacht, die sich der PIM-Hersteller so nie erträumen ließ und das PIM bildet PLM-Funktionalität ab, nur nicht so gut wie ein PLM, oder DAM-Funktionalität – nur nicht so gut wie ein DAM. Das ist nicht weiter schlimm, aber es sollte im Sinne eines „Best of Breed“-Ansatzes auch jederzeit möglich sein, Entitäten aus dem System zu lösen, ohne die Implementierung neu anfangen zu müssen. Oder anders gesagt, wenn der rostige Nagel gezogen wird darf das Haus nicht gleich zusammenbrechen.

  1. Es geht um eine langfristige Bindung an das PIM-System.

Ja – vielleicht, aber das darf nicht die Technik des PIM-Systems diktieren. Unter Umständen kann ein kleines Standard-PIM, das Vorsystem zur Einführung einer Enterprise-Lösung sein, die technisch in der Lage ist die Größe des Vorhabens zu meistern aber mehr eine Entwicklungsumgebung ist. Wobei wir inhaltlich wieder bei Punkt, oder beim Dogma 1 sind. Zusammenfassend sei gesagt – eigentlich wird stets das Tempo, dass man bei der Einführung eines PIM-Systems an den Tag legen kann, als Qualitätsmerkmal gesehen – warum nicht den Blick erweitern und in die Überlegung mit einbeziehen wie hoch der Aufwand wäre das System abzulösen. Zum einen, weil die Frage, auch wenn man gar nicht ablösen will, Rückschlüsse auf das System zulässt und zum anderen, weil es tatsächlich passieren kann. Die Ablösung eines Systems ist nicht die Niederlage – die Niederlage wäre, aus technischen Gründen nicht ablösen zu können.

Autor:

Stefan Fisahn ist Teamleiter Business Solutions bei der Mediengruppe Deutscher Apotheker Verlag in Stuttgart/Gerlingen. Zuvor war er als technischer Consultant für verschiedene PIM-Systeme unterwegs und konnte tiefe Einblicke in verschiedene Ansätze, vom Mittelstand bis Enterprise-Lösungen, gewinnen.