.png)
ZusammenfassungMSV3 lässt sich in einer SAP-Landschaft auf drei Wegen betreiben: als fertiges Add-on eines Integrators, als Eigenentwicklung über die Integrationsschicht, oder über eine vorgelagerte Plattform, die die Lieferantenanbindung bündelt und an SAP übergibt. Alle drei lösen dieselbe Aufgabe, nämlich Verfügbarkeit abfragen und bestellen, ohne das System zu wechseln. Und alle drei lassen dieselbe Lücke offen: MSV3 beantwortet ausschließlich die Frage, ob ein bestimmter Lieferant eine bestimmte Pharmazentralnummer liefern kann. Den Artikelstamm, eine Alternative bei Nichtverfügbarkeit und den Preis liefert der Standard nicht mit.
Dieser Beitrag richtet sich an IT- und Einkaufsverantwortliche in Krankenhausapotheken, Klinikverbünden und Pharmagroßhandelsbetrieben, bei denen SAP gesetzt ist. Wie MSV3 grundsätzlich im ERP funktioniert, welche Rollen Client und Server haben und wie sich MSV3 von EDI abgrenzt, ist im Grundlagenbeitrag MSV3-Verfügbarkeitsabfrage und Bestellung im ERP beschrieben und wird hier nicht wiederholt.
MSV3 ist der gemeinsame Bestellstandard der Bundesverbände der beteiligten Marktpartner: des Deutschen Apothekerverbands für die Apotheken, von PHAGRO für den Großhandel und von ADAS für die Apothekensoftwarehäuser. Er löst das MSV2-Protokoll ab, wobei MSV für Medium Speed Version steht. Technisch ersetzt er die frühere ISDN-Kommunikation durch ein internetbasiertes Protokoll und Webservices, umgesetzt als SOAP-Dienste über HTTPS mit je einer Funktion pro Service.
Die Spezifikation wurde am 20. Juni 2012 veröffentlicht, erste Pilotprojekte liefen ab Herbst 2012. Für ein SAP-Projekt heißt das: Sie integrieren keinen exotischen Nischenstandard, sondern einen etablierten Webservice mit klar beschriebenen Diensten.
Die Wahl entscheidet weniger über die Funktion als über die Folgekosten. Jeder angebundene Lieferant bringt eigene Zugangsdaten und einen eigenen Endpunkt mit, und genau dort entsteht die Pflege.
| Weg | Wie es läuft | Aufwand beim Aufbau | Laufende Pflege | Passt, wenn |
|---|---|---|---|---|
| Fertiges Add-on | Ein Integrator liefert einen SAP-integrierten Abfrage- und Bestellprozess, der die MSV3-Dienste kapselt | niedrig bis mittel | beim Anbieter | SAP-Standard bleiben soll und wenige Lieferanten angebunden werden |
| Eigenentwicklung über die Integrationsschicht | SOAP-Aufruf über die SAP-Integrationsschicht, Mapping auf eigene Objekte | hoch | im Haus | bereits eine Integrationsplattform betrieben wird und Sonderlogik nötig ist |
| Vorgelagerte Plattform | Eine Plattform bündelt die Lieferantenanbindungen und übergibt ein Ergebnis an SAP | mittel | geteilt | viele Lieferanten angebunden werden und die Pflege je Endpunkt stören würde |
Für Krankenhausapotheken existiert der erste Weg als Produkt: SAP-integrierte Lieferfähigkeitsabfrage und Bestellprozess auf Basis der MSV3-Dienste, damit vor der Bestellung bekannt ist, was verfügbar ist. Für den zweiten Weg gibt es spezialisierte SAP-Integratoren, die die Schnittstelle als Projekt bauen.
Eine MSV3-Abfrage erzeugt keine neuen Stammdaten, sie liefert einen Zustand zu einem Zeitpunkt. Damit dieser Zustand im System verwertbar ist, muss er auf vorhandene Objekte treffen.
| Was MSV3 liefert | Wohin es in SAP gehört | Voraussetzung |
|---|---|---|
| Lieferfähigkeit je Artikel und Lieferant | Bezugsquellenfindung, Anzeige an der Bestellanforderung | Lieferant als Geschäftspartner mit hinterlegten Zugangsdaten |
| Bestellbestätigung und Antwortcode | Bestellung und Bestellhistorie | Artikel im Materialstamm, PZN als führendes oder zusätzliches Feld |
| Liefermeldung | Erwarteter Wareneingang | Zuordnung Bestellposition zu Materialnummer |
| Nicht lieferbar oder Teilmenge | Ausnahmebehandlung im Einkauf | definierte Folgelogik, sonst bleibt der Fall liegen |
Der kritische Punkt ist die letzte Zeile. Eine Absage ist kein technischer Fehler, sondern ein fachliches Ergebnis. Wenn der Prozess dafür keine Folgelogik hat, landet der Vorgang wieder auf dem Schreibtisch, und der Effizienzgewinn der Anbindung ist aufgebraucht.
MSV3 setzt voraus, dass Sie wissen, wonach Sie fragen. Die Abfrage läuft über die Pharmazentralnummer. Woher diese Nummer kommt, ob das Produkt überhaupt noch im Vertrieb ist und welche Alternative in Frage kommt, ist außerhalb des Standards.
| Frage im Prozess | Liefert MSV3? | Woher es sonst kommt |
|---|---|---|
| Welche PZN hat das gesuchte Produkt? | nein | Artikelstamm |
| Ist das Produkt noch im Vertrieb? | nein | Vertriebsstatus im Artikelstamm |
| Ist ein Lieferengpass gemeldet? | nein | Engpassdaten, beim BfArM gemeldet |
| Welche wirkstoffgleiche Alternative gibt es? | nein | Wirkstoff, Wirkstärke, Darreichungsform aus dem Artikelstamm |
| Was kostet es? | nein | Preisdaten, Konditionen des Lieferanten |
| Kann Lieferant X die PZN Y liefern? | ja | MSV3 |
Diese Verteilung ist kein Mangel des Standards, sondern seine Definition. MSV3 ist ein Bestellstandard, keine Datenquelle. In der Praxis bedeutet das für SAP-Landschaften eine bekannte Konstellation: Der Materialstamm wird selbst gepflegt, weil es für Arzneimitteldaten in der ERP-Welt keinen verbreiteten Standard-Feed gibt. In unserer Auswertung von 134 Verkaufsgesprächen mit Fachkreisen ist die manuelle Stammdatenpflege die zweithäufigste Nennung überhaupt, und 19 Gesprächspartner nennen ausdrücklich den Wunsch, Daten direkt in ERP oder Warenwirtschaft übertragen zu lassen.
pharmazie.com ist die konsolidierte Arzneimitteldatenplattform der DACON Datenbank Consulting GmbH, am Markt seit 1989. Sie vereint 25+ pharmazeutische Fachdatenbanken in einer einzigen Suche, der Eisbergsuche®. Zielgruppe sind ausschließlich Fachkreise im Gesundheitswesen. Der Fokus liegt auf DACH, die Arzneimitteldaten decken 50+ Länder ab. Die Daten werden täglich aktualisiert. Für eine SAP-Landschaft ist damit genau der Teil abgedeckt, den MSV3 offenlässt: Artikelstamm mit Vertriebsstatus, täglich aktualisierte Engpassdaten und die Merkmale, über die sich eine wirkstoffgleiche Alternative bestimmen lässt.
Die meisten Verzögerungen in solchen Projekten entstehen nicht an der Technik, sondern an ungeklärten Zuständigkeiten und an einer zu spät gestellten Mengenfrage. Fünf Punkte, die vor der Aufwandsschätzung beantwortet sein sollten:
| Frage | Warum sie den Aufwand bestimmt |
|---|---|
| Wie viele Lieferanten sollen angebunden werden, und in welcher Reihenfolge? | Jeder Lieferant bringt eigene Zugangsdaten und einen eigenen Endpunkt mit. Der Aufwand skaliert mit der Zahl der Verbindungen, nicht mit dem Volumen |
| Welche Funktion wird gebraucht: Anfrage, Bestellung oder beides? | Wer nur die Verfügbarkeitsabfrage anbindet, sieht mehr, spart aber keinen Bestellweg. Der Medienbruch bleibt bestehen |
| An welcher Stelle im Prozess sitzt die Abfrage? | An der Bedarfsanforderung wirkt sie disponierend, an der Bestellung nur noch bestätigend |
| Was passiert bei „nicht lieferbar" und bei Teilmengen? | Ohne definierte Folgelogik landet der Fall wieder manuell auf dem Tisch und der Effizienzgewinn ist aufgebraucht |
| Wer pflegt die Zugangsdaten, und was passiert bei Ablauf? | Ein abgelaufener Zugang sieht im Betrieb aus wie eine Störung und wird als solche eskaliert |
Die vierte Zeile ist die, die in Projektplänen am häufigsten fehlt. Eine Absage über MSV3 ist ein regulär vorgesehenes fachliches Ergebnis und kein Ausnahmefall. Wenn dafür keine Folgelogik hinterlegt ist, verlagert die Anbindung den manuellen Aufwand nur, statt ihn zu senken.
In der Klinik trifft MSV3 auf eine andere Ausgangslage als in der Offizin. Der Bedarf entsteht aus dem Versorgungsauftrag der Stationen, nicht aus dem Handverkauf, die Beschaffung ist mehrstufig, und ein nicht lieferbarer Artikel löst eine Substitutionsprüfung aus, keine Nachbestellung am nächsten Tag.
Für die Anbindung heißt das zweierlei. Erstens muss die Abfrage möglichst früh im Prozess sitzen, also bereits an der Bedarfsanforderung, nicht erst an der Bestellung. Zweitens ist die Ausnahmebehandlung wichtiger als der Normalfall: Was passiert, wenn der Artikel nicht kommt, ist die Frage, die den Nutzen bestimmt.
Drei Einschränkungen gehören in jede Projektplanung. Erstens sind Client und Server zwei getrennte Rollen: Der Client ist die einkaufende Seite, der Server die verkaufende. Wer selbst beliefert, braucht die Server-Seite, und die ist ein eigenes Vorhaben. Bei pharmazie.com ist der MSV3-Client live und produktiv verfügbar, die Server-Seite befindet sich in der Pilotphase.
Zweitens ist MSV3 deutschlandspezifisch. Für Standorte in Österreich, der Schweiz oder im übrigen EU-Ausland trägt das Argument nicht, dort gelten andere Bestellwege.
Drittens ist eine Verfügbarkeitsauskunft eine Momentaufnahme des angefragten Lieferanten, keine Zusage und keine Marktübersicht. Sie beantwortet nicht, ob es das Produkt anderswo gibt.
Die Wahl des Integrationswegs entscheidet über die Folgekosten, nicht über die Funktion. Wichtiger als der Weg ist die Frage danach: MSV3 beantwortet zuverlässig, ob ein bestimmter Lieferant eine bestimmte Pharmazentralnummer liefern kann. Alles davor, also welche Nummer überhaupt gesucht wird, ob das Produkt noch im Vertrieb ist und welche Alternative in Frage kommt, muss die SAP-Landschaft selbst mitbringen.
Weiterführend: der Grundlagenbeitrag zur MSV3-Abfrage im ERP für Rollen, Ablauf und die Abgrenzung zu EDI, der Beitrag zur MSV3-Anbindung in Sage 100 für dieselbe Frage in einer anderen ERP-Welt, und die Übersicht zu Standard, Funktionen und Antwortcodes für die technische Ebene.
Wenn Sie prüfen möchten, welche Stammdatenfelder Ihre SAP-Landschaft für den Prozess braucht, vereinbaren Sie einen 30-minütigen Demotermin oder nehmen Sie Kontakt auf.
