Data-Warehouse als Applikationsbasis? — Zur Kosten- und Leistungsrechnung (nicht nur) im...

1 Einleitung

„Krankenhauser an der Grenze der Belast-barkeit“ titelte die FAZ am 12. Juni 2003ganz vorne auf Seite 1 und berichtete uberdie angespannte Situation, die „�rzte undPflegepersonal [ . . .] in Konflikte zwischenWirtschaftlichkeit und Mitmenschlichkeitgeraten lasst“ [MuEi03]. Im Mittelpunktder Diskussion: Die Einfuhrung von fall-basierten Pauschalen ab dem nachsten Jahr,welche, so die Intention, das Anreizinstru-ment fur effizienteres Wirtschaften inKrankenhausern werden soll.

Jedoch sind die Krankenhauser damitnicht allein: Soziale Einrichtungen wie Al-tenheime, Behindertenheime und Jugend-hilfeeinrichtungen mussen ihren Pflegeauf-wand minutios dokumentieren undverrechnen. Gemeinden fuhren die kauf-mannische Buchfuhrung ein, um ihre ange-spannte Situation besser managen zu kon-nen, gliedern Regiebetriebe aus undverlangen, dass sie sich dem Wettbewerbstellen. Auch die Industrie gliedert bisherbudgetmaßig finanzierte Aktivitaten wiedie IT-Administration an spezialisierteOutsourcer aus [Comp02; Comp03] undvereinbart genaue Preise fur die einzelnenLeistungen. All dies zeigt: DemControllingvon Dienstleistungen kommt in den nach-sten Jahren eine immense Bedeutung zu.Das Controlling von Dienstleistungen,

insbesondere in so dynamischen Branchenwie dem Gesundheitswesen, erfordert um-

fangreiche Umlagen und Verrechnungenzwischen den verschiedenen Zuordnungs-objekten wie Kostenstellen und Kostentra-gern, die in diesem Fall auf verschiedensteGroßen aus diversen Vorsystemen zugrei-fen. Der klassische Ansatz, die Kosten-und Leistungsrechnung als Komponenteder Finanzbuchhaltung durchzufuhren,muss hier scheitern, da in der Finanzbuch-haltung die notigen Daten nicht zur Ver-fugung stehen.Grundsatzlich wird bei entscheidungs-

relevanten Analysen von Daten aus hetero-genen Systemen seit einiger Zeit der Data-Warehousing-Ansatz verfolgt. EinData-Warehouse ist, nach [Inmo92], „asubject-oriented, integrated, time-variantand non-volatile collection of data in sup-port of management’s decision makingprocess.“ Charakteristisch ist, dass die zuanalysierenden Daten dabei aus den opera-

WIRTSCHAFTSINFORMATIK 46 (2004) 1, S. 22–32

Die Autoren

Peter HofschroerTim Romberg

Peter Hofschroer (M.A.)All for One Systemhaus AGSolution Management All for FinancialsUnixstraße 188436 [email protected]://www.all-for-one.de

Dipl.-Wirtsch.-Ing. Tim RombergForschungszentrum Informatik an derUniversitat Karlsruhe (FZI)Forschungsbereich Business ProcessEngineering & ManagementProf. Dr. W. StuckyHaid- und Neustr. 1476131 [email protected]://www.fzi.de/bpem

Data-Warehouse als Applikationsbasis?Zur Kosten- und Leistungsrechnung(nicht nur) im Gesundheits- undSozialwesen

Kernpunkte fur das Management

Bei der Kosten- und Leistungsrechnung von komplexen Dienstleistungen – hier am BeispielKrankenhaus gezeigt – mussen Kosten nach einer Vielzahl von Bezugsgroßen aus unter-schiedlichen Vorsystemen verrechnet und umgelegt werden. Der Ansatz, die Kosten- undLeistungsrechnung auf Basis eines Data-Warehouse durchzufuhren, hat mehrere Vorteile:

& Die Kosten- und Leistungsrechnung setzt auf vereinheitlichten, bereinigten Datenstrukturenauf, in die die Vielzahl von Vorsystemen Daten liefert.

& Bei den Umlage- und Verrechnungsdefinitionen werden die in Data-Warehouses ohnehinublichen Dimensionshierarchien fur Kostenstellen, Kostentrager und Leistungsarten beno-tigt.

Die eingebaute betriebswirtschaftliche Intelligenz kann die Datenqualitat wesentlich erho-hen.

Stichworte: Data-Warehouse, Kosten- und Leistungsrechnung, Service-Management, Enter-prise-Application-Integration, Gesundheitswesen, Controlling, OLAP

WI – Schwerpunktaufsatz

tiven Vorsystemen physikalisch kopiert,einheitlich strukturiert und bereinigt wer-den, grundsatzlich aber keine �nderungenmehr erfolgen, sondern lediglich Lese-zugriffe fur verschiedene Analysen. DieseRestriktion erlaubt den Einsatz von ver-schiedenen Mechanismen zur Voraggrega-tion und damit zur Performancesteigerung[ChGl00].Bei der Neuentwicklung ihrer Control-

ling-Komponente fur den Dienstleistungs-sektor hat die All for One Systemhaus AGeinen neuartigen Ansatz gewahlt, der dieKosten- und Leistungsrechnung mit denVorteilen eines Data-Warehouse kom-biniert. Neuartig deswegen, weil es sich beidieser Anwendung des Data-Warehouseum keine reine Auswertungsanwendunghandelt, wie im herkommlichen Data-Warehousing-Modell vorgesehen, da sieselbst z. T. umfangreiche Daten erzeugt.Auch erfolgt nicht, wie im Falle des ana-lytischen CRM oder des in [AuFr01] be-schriebenen Operational Data Store-Kon-zepts ein direkter „Loopback“ in operativeAnwendungen.Nach einer �bersicht uber die Anforde-

rungen in komplexen Dienstleistungenstellt dieser Beitrag das Losungskonzeptvor und diskutiert die resultierenden tech-nischen Herausforderungen und Erweite-rungsmoglichkeiten.

2 Anforderungen an dieKosten- und Leistungsrechnungim Gesundheits- und Sozial-wesen

In deutschen Akutkrankenhausern wird von2004 an die Vergutung fur stationare Be-handlungen von Tagessatzen umgestellt aufeine grundsatzlich verweildauerunabhangi-

ge1 Pauschale je Behandlungsfall einer be-stimmten Diagnosegruppe (Diagnosis Re-lated Group, kurz „DRG“). Dieses Modellist in anderen Landern schon seit langererZeit im Einsatz, so zum Beispiel in Aus-tralien, welches als Vorbild fur das deutscheFallpauschalengesetz diente.Krankenhauser stehen somit vor der

Aufgabe, eine Kosten- und Leistungsrech-nung („KLR“) einzufuhren, um sowohlauf Fallebene als auch fur ganze Diagnose-gruppen die Kostensituation der Erlosseitegegenuberzustellen. Tabelle 1 stellt die da-bei relevanten Dimensionen den Entspre-chungen eines typischen Industriebetriebsgegenuber.Zwischen allen Dimensionen bestehen

im Allgemeinen n :m-Beziehungen, d. h.eine Kostenstelle erbringt z. B. Leistungenfur mehrere Kostentrager und diese wie-derum konnen Leistungen von mehrerenKostenstellen empfangen.Die Deutsche Krankenhausgesellschaft

(DKG), die Spitzenverbande der Kranken-kassen (GKV) und der Verband der pri-vaten Krankenkassen (PKV) haben bei ei-ner namhaften Unternehmensberatung einKalkulationshandbuch in Auftrag gegeben,welches seit Anfang 2002 in seiner 2. Fas-sung vorliegt [GDRG02]. Auf knapp 250Seiten legt es exakt und ausfuhrlich fest,wie Abgrenzungen, innerbetriebliche Leis-tungsverrechnung, Verrechnung der Vor-kostenstellen auf die Hauptkostenstellenund Verrechnung der Kostenstellen-gemeinkosten auf die Kostentrager zu or-ganisieren sind, und schafft damit Ver-gleichbarkeit zwischen den einzelnenKrankenhausern. Wie in Bild 1 dargestellt,werden dabei fur insgesamt 12 Kostenstel-lengruppen gegliedert nach 10 Kostenarten-gruppen bis zu 13 verschiedene Bezugsgro-ßen je Patientenfall benotigt. DieBezugsgroßen stammen aus meist ebensovielen operativen Vorsystemen, von der Sta-

tionsbelegung uber denOP-Saal, den Labo-ratorien bis hin zu den diagnostischen undtherapeutischen Bereichen. Die Berechnungder Personalkostensatze erfordert zusatz-lich Daten aus dem Personalsystem.

Trotz zunehmend integrierter Branchen-losungen ist die Realitat im Krankenhausein wahrer „Software-Zoo‘‘ mit diversenInsellosungen. Die vertikale Kostenstellen-struktur in Bild 1 lasst erahnen, dass sichhinter jeder Kostenstellengruppe i. d. R.ein anderes operatives Vorsystem verbirgt.Fortschrittliche Krankenhauser gehen nochweiter: Sie haben beispielsweise die Kos-tenstellengruppe 9 „Radiologie‘‘ unterteiltin die Untergruppen „Rontgen‘‘, „Neuro-radiologie‘‘ und „Computertomograph‘‘oder die Gruppe 11 in „Urologische Funk-tionsdiagnostik‘‘, „Neurologie‘‘, „Gips-raum‘‘ und „Andere‘‘; denn es verbergensich hinter jeder dieser Untergruppen ers-tens andere operative Vorsysteme undzweitens andere Kostenstrukturen und-treiber. Gefordert ist daher ein Ansatz,der den Zugriff auf diese Systemvielfalt zu-lasst.

Was fur das Krankenhaus gilt, lasst sichauch auf andere Bereiche des Gesundheits-und Sozialwesens und ebenso auf vieleDienstleistungsbranchen ubertragen, in de-nen hochspezialisierte operative Vorsyste-me zum Einsatz kommen. Die vorgestellteLosung wird z. B. auch bei sozialen Ein-richtungen, Stadtwerken und offentlichenRegiebetrieben (Baubetriebshofen, Mull-abfuhren) erfolgreich eingesetzt.

3 Losungsansatz

3.1 �berblick

Das vorgestellte Losungskonzept bestehtaus einer neuartigen Kombination aus dem


Tabelle 1 Betriebswirtschaftliche Zuordnungsobjekte im Vergleich

KostenrechnerischeDimension

Erlauterung Entsprechung im Krankenhaus Entsprechung im Industriebetrieb

Kosten- oder Erlosart auch „Sachkonto“ z. B. Personalkosten, Verbandsmaterial,Strom, Abschreibungen, Umsatzerlose

z. B. Personalkosten, Zukaufteile, Betriebs-stoffe, Abschreibungen, Umsatzerlose

Kostenstelle Zuordnung von Kosten zu Verantwor-tungsbereich, vor allem fur Gemeinkos-ten, welche nicht direkt einem Kosten-trager zugeordnet werden konnen.

Station, OP, Wascherei, Labor Lager, Fertigung, Verwaltung

Kostentrager Permanenter Treiber von Umsatzerlosen Diagnosegruppe: Schlaganfall, Bein-bruch, Gehirntumor

Produkt

(Keine feste Bezeichnung) „Durchlaufende“ Einheit, welcher direktUmsatzerlose zugeordnet sind

Patientenfall Auftrag

Data-Warehouse als Applikationsbasis 23


Anlage 5

Personal-

kosten

ärztlicher

Dienst

Personal-

kosten

Pflegedienst

Personal-

kosten med.-

techn. Dienst/

Funktions-

dienst

Sachkosten

Implantate/

Transplantate

Personal- und

Sachkosten

med.

Infrastruktur

Personal- und

Sachkosten

nicht med.

Infrastruktur

1 2 3 4a 4b1

51

6a 6b1

7 8

Normalstation 1 Pflegetage PPR-Minuten2 Pflegetage PPR-Minuten2Ist-VerbrauchEinzelkosten-zuordnung

nicht relevant PPR-Minuten2Ist-VerbrauchEinzelkosten-zuordnung

Pflegetage Pflegetage

1. GewichteteIntensivstunden





2. Intensiv-stunden

2. Intensiv-stunden

2. Intensiv-stunden

2. Intensiv-stunden

2. Intensiv-stunden

1. Gewichtete

Dialysen41. Gewichtete






Dialysen4

2. PflegetageDialyseleistung







OP-Bereich 4

Schnitt-Naht-Zeit mit GZFund Rüstzeit5

nicht relevant

Schnitt-Naht-Zeit/HLM-Zeitmit GZF6 und

Rüstzeit5

Schnitt-Naht-Zeit mitRüstzeit 5

Ist-VerbrauchEinzelkosten-zuordnung


Schnitt-Naht-Zeit mitRüstzeit5




Anästhesie 5

Anästhesio-logiezeit 7 und

GZF8nicht relevant

Anästhesio-logiezeit 7



nicht relevantAnästhesio-logiezeit7


Anästhesio-logiezeit7


1. Aufenthalts-zeit Patientin im

Kreißsaal


Kreißsaal


Kreißsaal


Kreißsaal


Kreißsaal


Kreißsaal

2. AnzahlGeburten

2. AnzahlGeburten

2. AnzahlGeburten

2. AnzahlGeburten

2. AnzahlGeburten

2. AnzahlGeburten

1. Eingriffszeit 1. Eingriffszeit 1. Eingriffszeit 1. Eingriffszeit 1. Eingriffszeit 1. Eingriffszeit

2. Punkte lt.Leistungs-katalog






1. Eingriffszeit 1. Eingriffszeit 1. Eingriffszeit 1. Eingriffszeit 1. Eingriffszeit 1. Eingriffszeit







Radiologie 9

Punkte lt.Leistungs-katalog

nicht relevantPunkte lt.Leistungs-katalog



Ist-VerbrauchEinzelkosten-zuordnung3





Laboratorien 10









1. Eingriffszeit 1. Eingriffszeit 1. Eingriffszeit 1. Eingriffszeit 1. Eingriffszeit 1. Eingriffszeit 1. Eingriffszeit2. Punkte lt.Leistungs-katalog







Basiskosten-

stelle12 nicht relevant nicht relevant nicht relevant nicht relevant nicht relevant nicht relevant nicht relevant Pflegetage

Intensivstation 2


Sachkosten ArzneimittelSachkosten übriger

medizinischer Bedarf



6 nicht relevantIst-VerbrauchEinzelkosten-zuordnung

Ist-VerbrauchEinzelkosten-

zuordnung3

Intensivstunden

Dialyse-

abteilung3



nicht relevant

Intensivstunden

nicht relevantIst-VerbrauchEinzelkosten-zuordnung

Kardiologische

Diagnostik/

Therapie

7 nicht relevantIst-VerbrauchEinzelkosten-zuordnung



Kreißsaal


Übrige

diagnost. und

therapeut.

Bereiche

11




8

Endoskopische

Diagnostik/

Therapie

nicht relevantIst-VerbrauchEinzelkosten-zuordnung

Bild 1 Anlage 5 des Kalkulationshandbuchs [GDRG02, 130]

Finanzbuchhaltung

Kosten- undLeistungsrechnung

Personalverwaltung

Patientenverwaltung

…

DataWarehouse

DataMart

DataMart

DataMart

Bericht-generierung

OLAPFinanzbuchhaltung

Personalverwaltung

Patientenverwaltung

…

DataWarehouse

DataMart

DataMart

DataMart Bericht-

generierung

OLAP

Kosten- undLeistungsrechnung

Herkömmlicher Ansatz Vorgestellter Ansatz

Bild 2 Vergleich der klassischen Architektur von Data-Warehouse-Losungen zum vorgestellten Ansatz

24 Peter Hofschroer, Tim Romberg

Data-Warehouse-Ansatz und einer flexi-blen, multidimensionalen Logik fur be-triebswirtschaftliche Verrechnungen unddie Ermittlung von Planungsansatzen. Stattwie in herkommlichen Systemen die KLRals Komponente des betrieblichen Rech-nungswesens zu realisieren – wie z. B. beiSAP [Mehr03] – und die Daten dann furdie flexible Auswertung in das Data-Ware-house zu laden (vgl. Bild 2) werden hierzunachst Daten aus den verschiedenenQuellen in das Data-Warehouse geladenund anschließend die notigen Verrechnun-gen und Planungsszenarien generiert.

3.2 Standard-Faktentabellenund Ladeprozess

Sowohl der Ladeprozess als auch die KLRselbst sind stark metadatengetrieben, umsie an unterschiedliche Bereiche wie Kran-kenhauser, Pflegeeinrichtungen oder of-fentliche Regiebetriebe anzupassen.Fur jedes Szenario konnen beliebige

Faktentabellen und Dimensionen definiertwerden. Es gibt jedoch auch bestimmteStandard-Faktentabellen und Standard-dimensionen wie Kostenstelle oder Kos-tentrager, welche befullt werden mussen,da an sie betriebswirtschaftliche Logik ge-koppelt ist. Die Standardfaktentabellensind zum jetzigen Zeitpunkt:& Finanzbuchhaltung (Buchungen auf Ein-

zelbuchungsebene);& Leistungen (was wurde wann fur wen

mit welchen Ressourcen erbracht?);& Personal (wer war wann in welcher Po-

sition und welcher Vergutungsgruppeund welchem Vollkraft-�quivalent ein-gestellt und welche Bezugsarten hat erin welcher Hohe erhalten?).

Diese konnen aber jeweils aus mehrerenVorsystemen gefullt werden. Die Extrak-tion erfolgt in relationalen Datenbanksys-temen uber direkten SQL-Zugriff, ansons-ten uber XML-Dateien oder flacheASCII-Dateien. Gerade Letztere spielenbei den heute in Krankenhausern anzutref-fenden Vorsystemen eine große Rolle. Da-her wurde gerade auf die Flexibilitat desASCII-Konverters großen Wert gelegt.Durch seine Mapping-Technik konnenschon bei der Extraktion erste Transforma-tions- und Vereinheitlichungsschritte erfol-gen, z. B.:& Schlusselbehandlung/Surrogate

(Quell-Id! Ziel-Id);& Klartextkodierungen (z. B. Fachabtei-

lungsname auf Kostenstellennummer);& Datentypkonvertierungen;& Vereinheitlichung von Zeichenketten

(z. B. Telephon ! Telefon);

& Umrechnung von Maßeinheiten/Skalie-rung;

& Kombination/Separierung von Attribut-werten;

& Berechnung abgeleiteter Werte mittelsFormeln.

Was die Berechnung abgeleiteter Werte an-geht, ein konkretes Beispiel aus dem Kran-kenhaus: Aus der OP-Software werden pa-tientenbezogene Daten ubergeben u. a. mitden Angaben OP-Beginn, OP-Ende,Schnittzeitpunkt, Nahtzeitpunkt, AnzahlOperateure, Rustzeitminuten. Laut Kalku-lationshandbuch [GDRG02, 130] mussendie Personalkosten des arztlichen Dienstesfur die OP-Kostenstellengruppe nach dem�quivalenzminutenwert auf die Behand-lungsfalle verrechnet werden, der sich ausfolgender Formel ergibt:

Bezugsgroße ¼ (Nahtzeit – Schnittzeit)� Anzahl Operateure þ Rustzeitminuten

Diese einfache Formel kann schon bei derExtraktion im Mapping hinterlegt werden.Neben den drei genannten Faktentabel-

len mit Bewegungsdaten gibt es noch we-sentlich kleinere Standard-Faktentabellen,die bei der spater beschriebenen Konsis-tenzprufung und Planung eine Rolle spie-len. Dazu gehoren Preislisten, Stucklisten(wie viel Material wird fur eine bestimmteLeistung im Regelfall benotigt?) und Per-sonalschlussel. Diese haben eher den Cha-rakter versionierter Stammdaten. Zum Teilwerden sie direkt aus den Operativsyste-men geladen, zum Teil aus den Bewegungs-daten direkt nach dem Ladevorgang abge-leitet.Die Daten in den genannten Tabellen

sind in einem relativ gering verdichtetenZustand. So enthalten zum Beispiel die Da-ten der Finanzbuchhaltung die einzelnenSachkonten (Kostenarten) – nicht seltengibt es davon an die 1000. Um die Per-sonalkosten in einer bestimmten Periodeauf einer bestimmten Kostenstelle zu er-mitteln, ist daher die Addition vieler Ein-zelwerte notig. Fur die Umlagen und Ver-rechnung wird relativ oft auf einebegrenzte Anzahl solcher aggregierter„Kennzahlen“ zugegriffen2 (vgl. dazu obenBild 1).Aus Performancegrunden werden diese

in eigene Kennzahlen-Faktentabellen miteiner reduzierten Anzahl von Dimensionengeneriert und von da aus auch fur Umlagenund Verrechnungen verwendet (vgl. Bild 3).Dieses Verfahren erlaubt, zwischen Man-danten mit unterschiedlichen Kontenpla-nen oder Leistungskatalogen Vergleichbar-keit herzustellen. Die Kennzahlenwertekonnen manuell korrigiert oder es konnen

sogar weitere Kennzahlen komplett manu-ell erfasst werden. Der letzte Punkt ist hilf-reich z. B. bei handschriftlich gefuhrtenUrsprungsdaten wie gefahrenen Kilo-metern pro Fahrzeug.

3.3 Umlagen und Verrechnungen

Die Verrechnungen erfolgen in den folgen-den vier Schritten:

1. Schritt: Gemeinkostenverteilung

Die Gemeinkostenverteilung verrechnetauf einer Sammelkostenstelle gebuchteKosten verursachungsgerecht auf die Kos-tenstellen, auf denen die Kosten tatsachlichentstanden sind. Ein Beispiel ist die Per-sonalkostenverrechnung [GDRG02, 88ff.]des arztlichen Dienstes, der i. d. R. in derFinanzbuchhaltung auf einer Sammelkos-tenstelle gebucht wird und z. B. nach denjeweiligen Stationsbelegungstagen auf dieStationskostenstellen verrechnet wird. DieVerteilung wird anschließend so interpre-tiert, als hatte sie bereits in der Finanz-buchhaltung so stattgefunden (sog. primareKosten).

2. Schritt: Innerbetriebliche Leistungs-verrechnung

Die innerbetriebliche Leistungsverrech-nung entspricht der Rechnungsstellungzwischen Kostenstellen fur bestimmteLeistungen. Als Besonderheit werden hiervorher festgelegte Verrechnungspreise ver-wendet statt einfach die entstandenen Kos-ten anteilig zu verrechnen, sodass auf derabgebenden Kostenstelle im Allgemeinenein positiver oder negativer Saldo verbleibt.Auch Hauptkostenstellen konnen hier als


Data

Warehouse

Fibu-Buchungen

Leistungen

Personal

Kenn-zahlen

Verrechnungen & Umlagen

Bild 3 Kennzahlen im Zusammenspielmit Umlagen und Verrechnungen


abgebende Kostenstellen auftreten. Ist dieabgebende Kostenstelle eine Vorkostenstel-le, so muss der verbleibende Saldo im an-schließenden Schritt weiter umgelegt wer-den.

3. Schritt: Kostenstellenumlage

Die Kostenstellenumlage schließlich sorgtfur die vom Kalkulationshandbuch gefor-derte Umlage aller Kosten von Vorkosten-stellen (Kostenstellen, die keine direkteLeistung am Patienten erbringen, wie z. B.Verwaltung, Pforte) auf Hauptkostenstel-len.

4. Schritt: Kostentragerverrechnung

Die Kostentragerverrechnung verrechnetdie Kostenstellengemeinkosten der Haupt-kostenstellen auf die einzelnen Patienten-falle (im Sinne von Auftragen). Unter Kos-

tenstellengemeinkosten versteht man dieKosten, die nicht direkt auf Auftrage ge-bucht werden, im Gegensatz zu den sog.Kostentragereinzelkosten wie im Kran-kenhaus z. B. teure Medikamente, Blut-konserven, Transplantate und Implantate,die man direkt einem Auftrag zuordnet.Das Kalkulationshandbuch [GDRG02,S. 130] bestimmt je nach Kostenstellen-und Kostenartengruppe die zu verwen-dende Bezugsgroße oder schreibt die Ein-zelkostenbuchung vor.Technisch gesehen lassen sich die ver-

schiedenen Verrechnungsarten (die genann-ten 4 Schritte) und Verrechnungsmethoden(z. B. nach festen Anteilen, nach Bezugs-großen, nach Bezugsgroßen mit �quiva-lenzziffern) als mathematisch relativ ein-fache Operationen (z. B. Skalarprodukt)auf mehrdimensionalen Datenwurfeln ab-bilden. Mithilfe dieser Operationen lassen

sich prinzipiell auch Verrechnungen in an-deren Faktentabellen, wie den Personal-daten oder branchenspezifischen Fakten-tabellen, realisieren.

3.4 Aggregationen/Hierarchien

Jedes Data-Warehousing-System mitOLAP-Funktionalitat besitzt ein Werk-zeug fur das Hierarchisieren von Dimen-sionselementen. Auch die klassischen be-triebswirtschaftlichen Zuordnungsobjektewie Kostenstellen, Kostenarten, Auftrage,Projekte und Kostentrager stellen Dimen-sionen dar und werden zu sinnvollen Ag-gregationsbaumen hierarchisiert. Bild 4zeigt die Hierarchiebaume der Kostenstel-len und Kostenarten, wie sie im Kalkula-tionshandbuch [GDRG02, 22–25] vor-geschrieben sind, umgesetzt im Hierarchie-Explorer der vorgestellten Anwendung



(aus Platzgrunden sind nur die ersten zweiEbenen dargestellt).Die einmal definierten Hierarchien ste-

hen auf diese Weise sowohl fur aggregierteSichten in Auswertungen als auch zum Ex-port in OLAP-Werkzeuge zur Verfugung.Des Weiteren sind sie die Grundlage furdie Definition von Kennzahlen, Umlagenund Verrechnungen gemaß der Vorschrif-ten des Kalkulationshandbuchs.Fur die Umlage- und Verrechnungstech-

niken mussen jedoch nicht nur die beiden

typischen RechnungswesendimensionenKostenstellen und Kostenarten (Sachkon-ten) hierarchisiert werden, sondern auchdie Leistungsarten der Leistungsmengen-statistiken, die aus den verschiedenen ope-rativen Vorsystemen in die entsprechendeStandardfaktentabelle des Data-Warehouseintegriert wurden (vgl. Bild 5).Das nachfolgende Bild 6 zeigt die Ver-

wendung der Hierarchiebaume fur Kosten-stellen, Kostenarten und Leistungsarten beider Definition der oben erwahnten Ge-

meinkostenverteilung. Sie greift an dreiStellen auf die Hierarchien zu:& Als abgebende Kostenstellen der Vertei-

lung ist der Hierarchieknoten „Alle Vor-kostenstellen“ eingestellt;

& Als abgebender Kontenbereich (also dieKonten, deren Salden verteilt werden)wird der Hierarchieknoten „Personal-kosten arztlicher Dienst“ der oben dar-gestellten Sachkontenhierarchie verwen-det;



& Als Bezugsgroße wird die Kennzahl„Belegungstage“ definiert, die selbstwiederum von der Leistungsartenhierar-chie abgeleitet wird, die so definiertwurde, dass sie Zugriff auf die Stations-belegungsstatistik nimmt (und nicht et-wa auf die OP-Statistik etc.).

4 Leistungsmerkmale desLosungsansatzes

Der vorgestellte Losungsansatz macht dasData-Warehouse zu einer Applikations-plattform und erlaubt so die Losung derfolgenden weiteren Anforderungen.

4.1 Datenhygiene auf Basisbetriebswirtschaftlicher Logik

Bei der Zusammenfuhrung von Daten ausunterschiedlichen Vorsystemen gibt es im-mer Inkonsistenzen. Dies zu beklagen istnicht zielfuhrend, man wurde einen der„großten Fehler“ machen, die R. Volck inseinem Erfahrungsbericht aus 40 Projektennennt: Das Warten auf bessere Daten inoperativen Systemen. „Der Traum vonkonsistenten Daten in operativen Systemenwird immer ein Traum bleiben. Ein funk-tionierendes Data-Warehouse kann aller-dings Mangel in den operativen Daten auf-

decken und beseitigen helfen“ [Volc00,242].Durch das eingebaute betriebswirt-

schaftliche Hintergrundwissen kann dieKonsistenzprufung unserer Data-Ware-house-Anwendung nicht nur fehlendeWerte in Pflichtattributen oder fehlerhafteoder unzulassige Werte aufdecken, sonderndie Daten auch auf inhaltliche Plausibilitatprufen. Beispiel: „Kann ein Patient nachOP-Statistik am 15.08.2002 am Blinddarmoperiert worden sein, der laut Belegungs-statistik aber schon im Oktober 1998 ent-lassen worden ist?“Dazu kommen weitere wichtige Werk-

zeuge zur Durchsetzung der Datenhygie-ne: Die automatische Erlosverprobungstimmt die fakturierten Leistungsmengenmit den Buchungen in der Finanzbuchhal-tung ab. Die Personalverprobung pruft, obsich die mitarbeiterbezogenen Personal-kostenstatistiken mit dem Rechnungs-wesen decken. Das Data-Warehouse deckthier Mangel in den Vorsystemen auf[Volc00, 242] und diese Mangel sind in ers-ter Linie in den Vorsystemen zu beseitigen.Wenn dies nicht moglich ist, konnen dieDatensatze manuell nachbearbeitet oder imExtremfall ganz geloscht werden.Der Komplettierung mit Attributwerten

aus anderen Quellen kommt im Kranken-haus eine enorme Bedeutung zu. Das Kal-kulationshandbuch [GDRG02, 130] siehtfur 30 Kostenstellen-/Kostenartengruppen

eine Verrechnung auf die Patientenfallemittels einer „Punktbewertung lt. Leis-tungskatalog“ vor (vgl. Bild 1 oben).Die betroffenen Vorsysteme ubergeben

an das Data-Warehouse nur Tag, Uhrzeitund die Leistungsart, die sie fur einen Pa-tientenfall erbracht haben, nicht aber ihreBewertung. Da das Thema Bewertung vieleVorsysteme betrifft, ist es viel einfacher dieBewertung in der zentralen Data-Ware-house-Anwendung vorzunehmen. Dazugehort auch die wahlfreie Entscheidung,ob nach einem bundeseinheitlichen Kata-log wie z. B. GO� (Gebuhrenordnung fur�rzte) oder nach einem krankenhausinter-nen Katalog bewertet werden soll. Dasheißt im Klartext, dass schon wahrend desLade- und Transformationsprozesses be-triebswirtschaftliche Logik benotigt wird.In der Applikation werden die Leistungenbewertet, die Transformation aktualisiertdie Daten aus den Vorsystemen entspre-chend. Dazu kommt erneut eine Konsis-tenzprufung, ob fur alle Leistungsdatender Faktentabelle eine Bewertung in denLeistungsstammdaten vorgenommen wur-de.

4.2 Generierungvon PlanungsansatzenDie hierarchischen Aggregationsstrukturendes Data-Warehouse eignen sich hervor-ragend fur die Definition von Planungen in



verschiedenen Szenarioauspragungen (bestcase / worst case / . . .), da „Planzahlen oft-mals nicht auf Detailebene, sondern aufhoherer Granularitat eingegeben werden“[AFFF01, 236]. Wie Bild 8 zeigt, konnenauf jeder Aggregationsstufe Planwerte mitund ohne Bezug auf Vergleichswerte ande-rer Wirtschaftsjahre und Szenarien einge-geben und auf die unteren Zuordnungsein-heiten heruntergebrochen werden.

5 TechnischeHerausforderungen

Die Architektur bringt nicht nur Vorteilesondern auch einige Herausforderungenmit sich.

5.1 Aktualisierungshaufigkeit undPerformance von Auswertungen

Bei einem klassischen Data-Warehousing-Ansatz werden Daten aus verschiedenenOperativsystemen geladen, dort bereinigtund anschließend uber Data-Marts aus-

gewertet. Zwei Vorverdichtungsmechanis-men erlauben hierbei Antwortzeiten im Se-kundenbereich:& Die Vorverdichtung beim Laden des

Data-Marts aus dem Data-Warehouse(nicht relevante Dimensionen werden„wegaggregiert“) und

& die persistente Speicherung von verdich-teten Werten auf den verschiedenen Hie-rarchiestufen.

Im letzten Punkt unterscheidet manROLAP-, HOLAP- und MOLAP-Syste-me nach ansteigendem Umfang der Vorver-dichtung [vgl. ChGl00]. Beide Vorverdich-tungen dauern recht lange und laufendaher in der Regel zu festgelegten Zeit-punkten uber Nacht, einige Male im Mo-nat.In unserem Ansatz wird das Material

nach dem Einlesen starker nachbearbeitetund die Voraussetzungen fur dieses Vor-gehen sind nur noch zum Teil gegeben:& Wenn bei der Konsistenzprufung Man-

gel an den Operativdaten auftreten,mochte man diese im Regelfall in denOperativsystemen beheben, um die Da-tenqualitat insgesamt zu steigern. In die-

ser Phase konnen also mehrere Ein-lesevorgange pro Tag im laufendenBetrieb notig sein.

& Viele definierte Standardberichte werdenlaufend interaktiv abgerufen, um dieAuswirkungen der gerade bearbeitetenUmlagen- oder Kennzahlendefinitionsehen zu konnen – sei es zur Fehler-suche, sei es zur Feinjustierung von Bi-lanz und GuV.

In diesen dynamischen Phasen wurdenVorverdichtungen den Zeitbedarf fur einenRoundtrip von Operativdaten zu Auswer-tungen im Allgemeinen verlangern stattverkurzen.

Eine befriedigende Performance lasstsich durch eine Kombination aus zwei Ele-menten erreichen:& Einhalten von Prozessphasen: Die Con-

trolling-Abteilung muss wissen, ob siesich gerade in der Phase Datenimportund -bereinigung, der Phase Control-ling-Aufbereitung des Materials (inkl.KLR), der Phase Berichtgenerierungund OLAP-Bereitstellung oder der Pha-se Stammdatenpflege befindet und solltediese Phasen nicht zu schnell wechseln.



& Unterstutzung der Prozessphasen durchjeweils optimierte Vorverdichtungen.Ein Beispiel: Unter der Annahme, dassin der Phase Controlling-Aufbereitungdie importierten Daten stabil sind, lassensich diese zur Performance-Steigerungvorverdichten. Dabei muss berucksich-tigt werden, dass z. B. in die Standard-faktentabelle Finanzbuchhaltungswertein dieser Phase noch Controlling-buchungen (Umlagen etc.) geschriebenwerden.

Bei wiederholtem, sequentiellem Durchlaufder Phasen bewegen sich die Daten durchdas Data-Warehouse ahnlich wie ein Ver-brennungsgemisch durch einen Viertakt-

motor: „Ansaugen“, „Verdichten“, „Zun-den“, „Ausstoßen“. Hier wie dort wird inder dritten Phase die eigentliche Leistunggeliefert. Je hoher die „Drehzahl“, destostarker wird die Datenbank belastet. In derPraxis gibt es aber auch andere sinnvollePhasenubergange.

Eine weitere nutzliche Beobachtung ist,dass sich die von der Anwendung ausgelos-ten Schreibvorgange praktisch nur auf dasaktuelle Geschaftsjahr, und dort vorwiegendauf die letzten Monate beziehen. Fur abge-schlossene Perioden ist eine uber mehrereZyklen stabile Vorverdichtung moglich. Al-lerdings benotigt man deren Werte auch we-sentlich seltener bei der Arbeit am Material.

5.2 Zyklische Abhangigkeitvon Kennzahlen und Verrechnungen

Dem Leser ist vielleicht aufgefallen, dass inBild 3 ein potenzieller Zyklus zwischenKennzahlen und Verrechnungen steckt.Wurde eine Verrechnung nach einer Kenn-zahl (als Bezugsgroße) erfolgen, welcheselbst die von der Verrechnung erzeugtenDaten mitaggregiert, so wurden ohne Ver-anderung der operativen Datenbasis bei je-dem Aggregierungs- und Umlageschrittandere Werte berechnet. Darum, und weilfur verschiedene Auswertungen nicht im-mer nur das Endresultat der gesamten Ver-rechnungskette sondern auch die einzelnen


Fibu

Leistung

Personal

…

Data

Warehouse

DataMart

DataMart

DataMart Bericht-

generierung

OLAP

Definition derKennzahlen und

Umlagen / Verrechnungen

Umlagenund

Kennzahlen

Operativ-Daten

Operativsystem

e

Stammdaten, Verdichtungen

Fibu

Leistung

Personal

…

Data

Warehouse

DataMart

DataMart

DataMart Bericht-

generierung

OLAP



Umlagenund

Kennzahlen

Operativ-Daten

Operativsystem

e


Fibu

Leistung

Personal

…

Data

Warehouse

DataMart

DataMart

DataMart Bericht-

generierung

OLAP



Umlagenund

Kennzahlen

Operativ-Daten

Operativsystem

e


Fibu

Leistung

Personal

…

Data

Warehouse

DataMart

DataMart

DataMart Bericht-

generierung

OLAP



Umlagenund

Kennzahlen

Operativ-Daten

Operativsystem

e


I. Datenimport und Bereinigung

„Ansaugen“

II. Controlling-Aufbereitung des Materials

„Verdichten“

III. Berichtgenerierung und OLAP-BereitstellungIV. Stammdatenpflege

„Zünden“„Ausstoßen“

Wird bearbeitet

Wird ungültig, muss zum Zugriff neu berechnet werden

Vorverdichtung möglich, da stabil

Im Normalfall in dieser Phase nicht benutzt

Legende:

Generierung Generierung

Generierung Generierung

Bild 9 „Viertaktmotor“


Zwischenergebnisse interessieren, wird inder Faktentabelle Finanzbuchhaltung einezusatzliche Dimension Verrechnungsstufeeingefuhrt.Die kostentragerbezogenen Kennzahlen

in den Fibu-Werten werden danach unter-schieden, ob sie auf den nackten operativenZahlen, den Werten inklusive Gemeinkos-tenverteilung und innerbetrieblicher Leis-tungsverrechnung (sog. Primarkosten)oder den Werten inklusive der Umlagen-buchungen (Sekundarkosten) aufsetzen.Die Definitionen der Gemeinkostenvertei-lung und der innerbetrieblichen Leistungs-verrechnung durfen nur auf den originarenFibu-Kennzahlen sowie auf Kennzahlenanderer Faktentabellen aufsetzen, die Um-lagendefinitionen auf allen außer den se-kundaren Kennzahlen.

Die Berechnung kann dann zyklenfrei inden folgenden funf Schritten erfolgen (s.Bild 10).1. Erzeugung der Nicht-Fibu-Kennzahlen

und der Operativen Fibu-Kennzahlenaus den importierten Daten;

2. Erzeugung der Gemeinkostenverteilun-gen und innerbetrieblichen Leistungs-verrechnungen;

3. Erzeugung der primaren Kennzahlen;4. Erzeugung der Kostenstellenumlagen;5. Erzeugung der sekundaren Kennzahlen.Die dicker werdenden grauen Pfeile im Bilddeuten an, dass hier Werte aus mehrerenVerrechnungsstufen summiert werden. Diegenerierten Buchungen der Gemeinkosten-verteilung und Kostenstellenumlage hangennaturlich nicht nur von den Kennzahlen-werten, sondern auch direkt von den jewei-ligen Kostenstellen-/Kostenartensalden dervorgelagerten Verrechnungsstufe ab.Fur die Kostentragerverrechnung ließe

sich dieses Bild prinzipiell fortsetzen, aberhier werden momentan ausschließlich kos-tentragerbezogene Kennzahlen aus Nicht-Fibutabellen verwendet, so dass sich dasProblem nicht stellt. Es liegt auf der Hand,dass ein voller Durchlauf dieses Prozesseseinige Zeit in Anspruch nimmt und auchhier bei der Arbeit am Zahlenmaterial eineschrittweise Stabilisierung der Definitionenvon Gemeinkostenverteilung, innerbetrieb-licher Leistungsverrechnung und Umlagenzu empfehlen ist.

6 Fazit

Unser Beitrag hat gezeigt, dass sich ein Da-ta-Warehouse als Plattform fur bestimmtebetriebswirtschaftliche Anwendungen –insbesondere KLR und Planung – verwen-

den lasst. Dabei profitieren die Anwendun-gen von der Integrationsleistung des Data-Warehouse, seinen bewahrten Konzeptenwie Dimensionshierarchien und seinenVoraggregierungsmechanismen. Im Gegen-zug profitiert das Data-Warehouse von derIntelligenz der Anwendungen, durch diesich die Datenhygiene auch fur „reine“OLAP-Auswertungen steigern lasst.Das Abweichen vom klassischen Data-

Warehouse-Ansatz kann potenziell zu Per-formance-Problemen fuhren, welche aberbeherrschbar sind, wenn man bei der Ar-beit am Material gewisse Phasen einhalt.Die eingesetzten Mechanismen zur feingra-nularen Steuerung, bei welchen Werten inwelcher Phase eine Vorverdichtungsstrate-gie verfolgt wird und bei welchen nicht,oder die Definition von arithmetischen

Operationen wie z. B. dem Skalarproduktauf mehrdimensionalen Datenwurfeln, sindunabhangig von der Anwendungsdomaneanwendbar. Sie wurden sich daher grund-satzlich eignen, die Standardfunktionalita-ten von handelsublichen mehrdimensiona-len DBMS (z. B. SQL Server AnalysisServices von Microsoft) zu erganzen, umdie genannten Anwendungen noch perfor-manter zu unterstutzen.

Anmerkungen

1 Auf die Zu- bzw. Abschlagsregelungenbei �ber- bzw. Unterschreitung der ein-zelnen Grenzverweildauern wird an die-ser Stelle nicht naher eingegangen.


Abstract

The Data-Warehouse as an Application Platform? – How to do Cost Accounting (not only)in the Health and Social Care Sector

Using the hospital as an example for service sectors with a heterogeneous application land-scape, we put forward the hypothesis that it is not feasible to implement cost accountingapplications inside operative systems such as ERP, as it is assumed by the conventional datawarehousing approach. Rather, the data warehouse, with its extraction, validation andtransformation tools, delivers the right platform, creating an application layer which acts onthe data before it is being loaded into multidimensional cubes.The cost accounting application enriches the data in the data warehouse by imputing

costs and profits to the various calculatory objects such as ledgers, cost centres and costobjects (products).Our hypothesis is further validated by the fact that typical data warehousing tools, e.g.

tree structures, are ideal for defining the often complicated calculation metadata.

Keywords: Data Warehouse, Cost Accounting, Management Accounting, Service Manage-ment, Enterprise-Application-Integration, Healthcare Delivery, Healthcare Sector, DiagnosisRelated Groups, OLAP

Nicht-Fibu-

Kennzahlen

Primäre

Kennzahlen

Sekundäre

Kennzahlen

1 3

4

5

Operative

Fibu-Kennzahlen

1

2

Kostenstellen-

umlagen

Gemeinkostenverteilung u.

Innerbetriebliche LV

Andere

FaktentabellenOperative Fibu-Daten

Bild 10 Berechnungsreihenfolge fur Kennzahlen und Verrechnungen


2 Im Folgenden sind mit dem Begriff„Kennzahlen“ diese aggregierten Wertegemeint.

Literatur

[AFFF01] Albrecht, J.; Findeisen, D.; Furtado, P.;Frietsch, H.: Umsetzung des multidimensionalenDatenmodells. In: Bauer, Andreas; Gunzel, Hol-ger (Hrsg.): Data Warehouse Systeme: Architek-tur, Entwicklung, Anwendung. Heidelberg 2001,S. 236.

[AuFr01] Auth, G.; Frie, T.: Kopplung operativer(horizontaler) Applikationen mit dem DataWarehouse. Universitat St. Gallen (HSG), Insti-tut fur Wirtschaftsinformatik, Lehrstuhl Prof.Dr. R. Winter, Bericht BE HSG/CC DW2/01,September 2001.

[ChGl00] Chamoni, P.; Gluchowski, P.: On-LineAnalytical Processing (OLAP). In: Muksch, H.;Behme W. (Hrsg.): Das Data-Warehouse-Kon-

zept. Architektur – Datenmodelle – Anwen-dungen. Wiesbaden 2000.

[Comp02] „Deutsche Bank vergibt IT an IBM“,Computerwoche Nr. 40 vom 2002-10-04.

[Comp03] „Commerzbank hegt Outsourcing-Pla-ne“, Computerwoche Nr. 6 vom 2003-02-07.

[GaVa01] Gatziu, S.; Vavouras, A.: Phasen desData Warehousing: Monitoring. In: Bauer, An-dreas; Gunzel, Holger (Hrsg.): Data WarehouseSysteme: Architektur, Entwicklung, Anwen-dung. Heidelberg 2001, S. 75–81.

[GDRG02] Deutsche Krankenhausgesellschaft(DKG); Spitzenverbande der Krankenkassen(GKV); Verband der privaten Krankenkassen(PKV): Kalkulation von Fallkosten: Handbuchzur Anwendung in Krankenhausern.http://www.g-drg.de/dokumente/kalkhb_v2.pdf,2002-01-31, Abruf am 2003-07-10. (Die Seiten-angaben beziehen sich auf die PDF-Paginierung)

[Hinr01] Hinrichs, H.: Phasen des Data Warehous-ing: Extraktionsphase. In: Bauer, Andreas; Gun-zel, Holger (Hrsg.): Data Warehouse Systeme:Architektur, Entwicklung, Anwendung. Heidel-berg 2001, S. 81–83.

[HiQu01] Hinrichs, H.; Quix, C.: Phasen des DataWarehousing: Transformationsphase. In: Bauer,Andreas; Gunzel, Holger (Hrsg.): Data Ware-house Systeme: Architektur, Entwicklung, An-wendung. Heidelberg 2001, S. 83–93.

[Inmo92] Inmon, W. H.: Building the Data Ware-house. John Wiley & Sons Inc, 1992.

[Mehr03] Mehrwald, Christian.: SAP Business In-formation Warehouse 3: Architektur, Konzep-tion, Implementierung. Heidelberg 2003.

[MuEi03] Muller, C. P.; Eilmes, W.: Vierzig ProzentSchreibkram – aber sonst ist es ein schoner Be-ruf. Zwischen Mitmenschlichkeit und okono-mischen Zwangen / Alltag in deutschen Kran-kenhausern. Frankfurter Allgemeine Zeitung,12. Juli 2003, Seite 4–5. Aufmacher „Kranken-hauser an der Grenze der Belastbarkeit“ auf Sei-te 1.

[Volc00] Volck, Rainer: Kriterien fur erfolgreicheData Warehouse-Projekte: Erfahrungen aus 40Projekten. In: Jung, Reinhard; Winter, Robert(Hrsg.): Data Warehousing 2000: Methoden, An-wendungen, Strategien. Heidelberg 2000, S.227–248.



Data-Warehouse als Applikationsbasis? — Zur Kosten- und Leistungsrechnung (nicht nur) im...

Documents

Transcript of Data-Warehouse als Applikationsbasis? — Zur Kosten- und Leistungsrechnung (nicht nur) im...