PMD - Entwicklungsaufwand aus ökonomischer Sicht.

In einem Gespräch mit dem Entwicklungsleiter eines großen Universitätsklinikum, das gerade mit der Einführung von i.s.h.med beschäftigt war, fragte dieser, wie aus meiner Erfahrung die Aufwände der PMD Entwicklung aus meinen Erfahrungswerten zu beurteilen seien.

Offensichtlich war er sehr erstaunt, als ich ihm sagte, daß alle PMD Entwicklungen, die ich durchgeführt hatte jeweils nie unter einem Aufwand von 10 Tagen lagen.

Ich wiederum war erstaunt darüber, daß er erstaunt war darüber.

How come?

 PMD wird den Kliniken vom Hersteller als Technik verkauft, mit der ein Administrator oder auch ein halbtechnischer MedController wunderbare Dokumentationen erstellen kann - ganz einfach.

Wir können das nur bestätigen - solange man von einfachst Dokumenten ausgeht.

Business Rules Rule.

 Bereits die Implementierung von einfachsten Business Regeln dürften einen mittelschweren K.O.-Schlag für den eifrigen Admin bedeuten, der mal schnell ein PMD hingezaubert hat.
Jede Business Regel, die sich in Programmierung niederschlägt unterliegt den Regeln einer Programmentwicklung - was bedeutet, dass die folgenden Komponenten beherrscht werden müssen.

• Programmiersprache (hier ABAP)
• Ausnahmebehandlungen zur Business Regel
  Keine Regel ohne Ausnahme.
  Und aus Erfahrung erzeugt die Implementierung einer Regel eher viele Ausnahmen.
  Beispiel: Dialyse
  Ermittlung der OPS Ziffer.
  Eine OPS Ziffer ist schnell ermittelt, die Ausnahmen hier:
  Dauer der Dialyse größer als 6 Stunden? - OPS f. verlängert intermittierend ermitteln
  Unterbrechung zwischen zwei Dialysen kleiner als 24 Stunden? - Keine neue OPS ermitteln.
  Zeiten - Überlappungen mit Vorgänger oder Nachfolger, Start < Ende.
  Nach (automatischer) Berechnung der ORGFA: stimmt die ORGFA der Bewegung mit der ORGFA des Erfassenden überein?
  Darf der Erfasser von ORGFA INT die Dialysen ändern, die von ORGFA GASTRO erfasst wurden?
• Transport
  Programmobjekte werden im System verwaltet und erzeugen bei Änderungen Transportaufträge, die organisiert werden wollen.
  
• Test
  Jede, auch nur kleinste Änderung an der Implementierung der Business Regel, erfordert einen Test des gesamten Dokumentes. 
• Qualitätssicherung
  Vor allem im MedizinControlling sind PMDs ein Instrument der Qualitätssicherung.
  Aus den Dokumentationen werden nicht zuletzt auch Leistungen berechnet, die Abrechnungsrelevanz haben.
  Jeder Fehler in der Dokumentation kann zum Verlust von Leistungen führen.
  Deshalb muss die PMD Entwicklung selbst unter dem Augenmerk der QS betrachtet werden, und je mehr Logik und Regeln in einem Dokument liegen, um so mehr Aufwand entsteht bei der Qualitätssicherung der PMD Entwicklung.

Probleme mit dem 'ZU'-System.

Darüber hinaus ist die Akzeptanz der Verwender des PMD ein ganz wesentlicher Faktor.

Das bekannte ERP System aus Walldorf, steht bei Ärzten und Fachpersonal stetig in der Kritik, und auf der Beliebtheitsskala von 1 bis 10 meistens bei Null.
Das System ist ZU langsam, ZU umständlich, ZU hässlich, und mit Word geht es ja auch viel besser und angenehmer.

So hat das PMD immer eine kritische Rolle - und Chefärzte, die 'NEIN' zu einer Lösung sagen bleiben meistens auch dabei.

2112portals.com ist ein Projekt dem die Grundidee 'Think Widget' unterliegt. 

Wir denken nicht in Klötzen, sondern in Klötzchen.

Unsere Software ist verstehbar und bei jeder Entwicklung denken wir daran, daß das Ergebnis dem Benutzer helfen soll (z.B. Zeit zu sparen, Fehler zu vermeiden).

 Was übrig bleibt.

 Zufriedene Benutzer, die vor einer durchdachten, nachvollziehbaren und bedienbaren Lösung stehen,

oder frustiertes Personal, die ihr System nur als Problem betrachten können.

Und die Ökonomie?.

"Es kostet sehr viel Geld, schlechte Produkte zu bauen".

(aus Augustines Erkenntnisse, Gesetz Nummer XI)

Gute Lösungen kosten (nach unseren Erfahrungen) zwar etwa drei mal mehr als Schlechte,
die Kosten, die aber in den schlechten Lösungen versteckt sind, sind unabsehbar.

Das Problem an der Betrachtung ist die Quantifizierbarkeit der Ergebnisse.

Wieviele Leistungen gehen verloren, durch lückenhafte und schlechte Dokumentation?

Wieviel (menschliche) Leistung geht verloren durch Mitarbeiter, die mit leichtem Widerwillen ihre Aufgaben verrichten, nur weil sie einem ungeliebten System gegenüberstehen?

Wie hoch ist im Gegenzug der Produktivitätsgewinn durch Anwendungen, die eine hohe Benutzerakzeptanz haben?