Fallbeispiel Rechnungsprüfung

In regelmäßigen Abständen schickt der Hotelier an das Reiseunternehmen Sammelrechnungen über den Aufenthalt der Gäste der entsprechenden Reiseveranstalter. Viele kleinere Hotels haben keine ausgereifte Rechnungsstellung, sondern schreiben ihre Rechnungen entweder auf Basis einer Tabellenkalkulation oder senden Sie als Brief – manchmal sogar noch handgeschrieben. Um die arbeitsaufwändige Prüfung der Rechnung zu automatisieren hat das Reiseunternehmen vor Jahren eine spezielle Anwendung außerhalb des SAP-Systems entwickelt. Es vergleicht die Rechnungen der Hoteliers mit den tatsächlichen Einkäufen und verfügt Schnittstellen zu SAP und dem Buchungssystem. Mithilfe dieser Rechnungsprüfung gibt der Sachbearbeiter zunächst die Rechnungen manuell ein, ordnet sie einer Belegart (mit/ohne Bestellbezug etc.) sowie dem Reiseveranstalter und dem Gast zu. Erst danach kann der Rechnungsbetrag validiert werden.

Der gerade beschriebene Prozess ist langsam, fehleranfällig und sehr teuer. Aus diesem Grund wünscht sich der Fachbereich eine moderne IT-Unterstützung, dies es ermöglicht, Rechnungen automatisiert zu erfassen. Um herauszufinden, ob für diese Lösung ein Standardprodukt in Frage käme, entwickelt die IT zusammen mit dem Fachbereich mehrere fachliche Komponentendiagramme und analysiert die Prozesse (Abbildung 2). Die Komponentendiagramme bildet die fachliche Soll-Landschaft ab. Sie zeigen hierbei anhand von mehreren Komponenten übersichtlich auf, welche Anforderungen die neue Software umsetzen soll. Es ist sozusagen eine intelligentere Form des klassischen Kriterienkatalogs.

Mehrstufige Anforderungsanalyse

Die Anforderungen, die man jeder Komponente zuordnet, lassen sich analog einem Kriterienkatalog beliebig fein (zum Beispiel in mehreren Ebenen) ausarbeiten. Zu jeder Komponente entsteht mindestens ein Diagramm, das zeigt, welche Anforderungen sie im Detail umsetzt (Abbildung 3).

Im Gegensatz zu einem Kriterienkatalog ist ein Unternehmen mit Hilfe dieser Sicht problemlos in der Lage, Wechselwirkungen zwischen den einzelnen fachlichen Komponenten zu beschreiben. Eine Komponente könnte zum Beispiel sein, Rechnungen per Scanner in Bilddateien umzuwandeln. Eine andere kann ein OCR-Modul sein, das Rechnungen wieder in Texte verwandelt, die sich maschinell weiterverarbeiten lassen. Eine weitere Komponente könnte in der Lage sein, E-Mails mit elektronischen Rechnungen direkt zu verarbeiten. Letztere Komponente steht zum Beispiel in Wechselwirkung mit einem Regelwerk, das die fachlichen Regeln für die Weiterverarbeitung festlegt.

Ergänzend zur Komponentensicht zeigen Prozessdiagramme, in welcher Reihenfolge die eben skizzierten fachlichen Komponenten aufgerufen werden. Hat man ein fachliches Komponentendiagramm und die Prozesse als Ziellösung der fachlichen Architektur erarbeitet, lässt sich das derzeit eingesetzte System damit gut bewerten. Da das aktuelle System nur über eine manuelle Digitalisierung ohne OCR-Funktionen und Posteingangsverarbeitung verfügt, schneiden die drei erwähnten Komponenten für die automatische Digitalisierung von Rechnungen schlecht ab (Abbildung 4). Analog dazu lässt sich nun auch Kaufsoftware einordnen. Zum Schluss des Vorgangs kann man die Anforderungen zum Beispiel für eine Ausschreibung in einen klassischen Kriterienkatalog überführen. Er ist in diesem flexiblen Auswahlprozess jedoch nicht die Basis, sondern nur eine Art zusätzliche Sicht auf die modellierten Anforderungen.

Fazit

Das hier beschriebene Auswahlverfahren kombiniert klassische Methoden der objektorientierten Anforderungsanalyse mit einer neuartigen, einfachen und übersichtlichen Komponentendarstellung. Die oftmals starren und endlosen Anforderungskataloge werden durch übersichtliche Darstellungen ersetzt. Durch diese fachlichen Sichten lassen sich Anforderungen in mehreren Ebenen beliebig detailliert darstellen. Trotz der Abbildung komplexer Anforderungen bleibt die Darstellung übersichtlich. Daher ist eine Bewertung von Softwareprodukten für alle Beteiligten einfach nachvollziehbar.