»SOA ist eine grosse Chance«

Herr Professor Scheer, in den Unternehmen gibt es Vorgänge, die genau festgelegt sind ? etwa Buchungen oder die Genehmigung von Kreditanträgen. Doch es gibt auch weniger geregelte Aktivitäten, zum Beispiel die Entwicklung neuer Geschäftsideen oder informelle Zusammenarbeit. Welche Möglichkeiten hat da die IT?
Wenn man sich fragt, wann eine Aufgabe beginnt und wann sie abgeschlossen ist, dann zeigt sich oft, dass Teile in einem Ablauf, etwa zur Entwicklung eines neuen Produkts, unstrukturierte Phasen der Kreativität enthalten. Aber hinterher müssen die Ergebnisse dokumentiert werden, und der Prozess läuft dann strukturiert weiter. Automatisieren kann man die stärker strukturierten Abschnitte leichter, aber auch die anderen Phasen lassen sich informationstechnisch unterstützen: etwa durch Groupware-Ansätze. Deren Resultate können dann gespeichert und in späteren Phasen weiterverwendet werden.

Was bedeutet das für die Einsatzmöglichkeiten der Produkte und Technologien Ihres Unternehmens?
Unsere Methoden und Werkzeuge sind eher für die stärker strukturierten Phasen gedacht. Aber wir haben auch Techniken, um zum Beispiel eine Aufgabenliste für einen nächsten unstrukturierten Schritt vorzugeben, ohne den Ablauf genau zu kennen. Wir haben also auch Möglichkeiten, die weicheren Teile von Prozessen abzubilden.

IDS kommt von der Geschäftsprozessmodellierung her, im Lauf der Zeit wurde das Portfolio dann erweitert. Unternehmen wollen schließlich nicht nur dokumentieren. Wie verbinden Sie die Modelle Ihrer Aris-Software mit den Anwendungsprogrammen?
Bei den nächsten Releases der SAP-Software, die auf Netweaver laufen, wird man sehen, wie man von den Modellen schnell zu Konfigurations- und Customizing-Mechanismen kommt. Bei Eigenentwicklungen sind UML und BPEL maßgebliche Standards, die wir unterstützen.

In welchem Maß nutzen die Anwender diese Möglichkeiten Ihrer Werkzeuge?
Es kommt darauf an, wozu ein Projekt aufgesetzt wird. Wenn es allein um organisatorisches Reengineering geht, dann wird man die Modelle nicht unbedingt für Implementierungen weiterverwenden. Wenn es darum geht, eine neue Anwendung zu entwerfen, dann kann man mit unserem UML-Designer aus den betriebswirtschaftlichen Aris-Modellen, die die Anforderungen definieren und weiterführen, UML-Modelle erzeugen und softwaretechnische Informationen hinzufügen.

Führt diese Vielfalt nicht zu Unübersichtlichkeit?
Keine Darstellung reicht für sich alleine aus. In der Automobilindustrie gibt es für den Kunden in einem Prospekt ein Foto des Autos. Wenn jemand an der Montagelinie steht und das Auto zusammenbauen soll, passt das für ihn natürlich nicht. Der Ingenieur, der das Auto entwickelt, ist mit dem Foto ebenso wenig zufrieden, sondern der hat seine CAD-Sicht, seine technischen Zeichnungen. Aber diese Zeichnungen kann jemand an der Werkbank nicht verwenden, weil er sie in ihrer Detailliertheit gar nicht lesen kann. So hat auch eine Software-Anwendung beim Benutzer eine andere Ansicht als bei der Implementierung. Am Ende müssen alle Sichten übereinstimmen: so wie am Fließband das Auto produziert wird, das im Katalog als Foto zu sehen ist.

So lassen sich Ihre Modelle also mit der Entwicklung von Anwendungen verbinden. Wie koppeln Sie Ihre geschäftlichen Spezifikationen mit dem Betrieb der Software?
Uns interessieren primär die betriebswirtschaftlichen Auswirkungen. Also nicht: Wie ist ein Server belegt? Sondern: Wie lange hat die Auftragsbear­beitung gedauert? Die technische Seite beeinflusst die betriebswirtschaftlichen Eigenschaften von Prozessen, darum ­haben wir Kooperationen wie jetzt mit BMC vereinbart.

Es hilft aber nichts, lediglich zu wissen, dass ein Auftrag zu lange gedauert hat. Wenn ein Server überlastet ist, muss in der IT etwas geändert werden.
Wenn Probleme von solchen technischen Eigenschaften herrühren: ja. Es kann aber auch sein, dass der Auftrag nicht vollständig erfasst war, so dass es Rückfragen gegeben hat, oder dass die falschen Mitarbeiter ihn bearbeitet haben. Es sind also auch viele organisatorische Gründe denkbar, warum etwas nicht geklappt hat. Mit unserem Werkzeug Process Performance Manager können wir die Ausführung der Prozesse dokumentieren und analysieren. Wir können zeigen, welche Wege wie häufig benutzt worden sind, so dass man eine transparente Sicht auf das Verhalten der Prozesse hat.

Zukunftschancen erhoffen Sie für Ihr Unternehmen vom Thema Governance. Denken Sie an neue Produkte oder an das bereits existierende Werkzeug Audit Manager?
Bei Governance geht es darum, eine komplexe Organisation zu beherrschen: vom Risikomanagement her, der Strategie, der Durchsichtigkeit. Da wirken Treiber aus dem rechtlichen Umfeld. Vor allem der Sarbanes-Oxley Act hat einiges in Bewegung gebracht, nicht nur in Amerika, sondern auch in Europa. Die Systeme, die wir im Augenblick haben, sind Ausgangspunkt für weitere Entwicklungen.

Beim Risikomanagement etwa lässt sich ja auch Business Intelligence nutzen. Wollen Sie solche Software selbst entwickeln oder mit Partnern zusammenarbeiten?
Alle Produkte, die wir bauen, haben etwas mit Prozessen zu tun. Das ist unsere Kernkompetenz, dadurch unterscheiden wir uns von der Konkurrenz. Unser Process Performance Manager liefert Kennzahlen über die Dauer und die Kosten von Abläufen. Business Intelligence und Data Warehouses befassen sich normalerweise mit Finanzkennzahlen, die sich auf Perioden beziehen. Wir orientieren uns hingegen an den Prozessen, deren Resultate dann solche Finanzzahlen sind. Deswegen merken die Unternehmen mit unseren Werkzeugen früher, wenn Prozesse schlecht laufen. Sie müssen nicht warten, bis die Finanzzahlen eines Monats, eines Quartals oder eines Jahres da sind, ehe sie reagieren können.

Sie liefern den Unternehmen also nur einige Bausteine für Governance-Lösungen?
Wir gehen vom Prozessgedanken aus und da haben wir noch sehr viele Felder. Governance-Themen sind sehr heterogen. Bei Compliance etwa geht es darum, das Verhalten des Unternehmens mit dem in Übereinstimmung zu bringen, was vorgesehen ist. Das betrifft viele Anwendungen und hat auch mit Dokumentenmanagement, mit Mess- und Belegbarkeit zu tun. Da kann keiner behaupten, eine vollständige Lösung anzubieten.

Ein Trend in der Software-Technologie ist derzeit, Anwendungen im Einklang mit den Prozesserfordernissen aus verfügbaren Diensten zusammenzusetzen. Was halten Sie von einer solchen serviceorientierten Architektur?
SOA ist eine große Chance. Diese Architektur unterstützt die Wiederverwendung von Komponenten, das ist industrielles Denken wie in der Automobilbranche. Da braucht man eine Blau­pause, eine Montagebeschreibung und Stücklisten, in denen die Wiederverwendung dokumentiert wird. Man braucht Beschreibungssprachen und Modellierungen, und das kommt uns entgegen. Wir können aus den Aris-Modellen BPEL-Darstellungen generieren, wenn Anwendungssysteme über eine BPEL-Engine aus Services montiert werden sollen.

Gibt es im Hinblick auf SOA in Ihrer Produktlinie Aris schon alles, oder ­stehen in dieser Hinsicht Erweiterungen an?
Wir haben Features für SOA-Beschreibungen, aber wir wollen ein anwendungsunabhängiges Repository für SOA-Anwendungen schaffen. Damit können die Unternehmen ihre Prozesse aus verschiedenen Sichten beschreiben, egal ob sie das Controlling oder die Compliance betreffen. Im nächsten Schritt können sie auf dieser Grundlage dann die Angebote vergleichen, die von Software-Herstellern in Form technischer Service-Beschreibungen kommen.

Ein solches Repository wäre dann eine betriebswirtschaftliche Abstraktionsschicht über einem Repository für Web Services, wie es verschiedene Hersteller bereits anbieten?
Ja, und das ist unsere Chance. Die Unternehmen, die von der Implementierung her kommen, haben nur die technische Sicht. Da ist aber noch eine Welt darüber. In der Automobilbranche kann der Vertriebsmitarbeiter nicht mit einem NC-Programm, das zeigt, wie ein Motorblock gefräst wird, zu einem Kunden gehen. Der will ein Foto haben, um das Produkt sehen zu können. Entsprechend brauchen wir eine betriebwirtschaftliche Sicht auf die Dinge, die in ­einem Unternehmen passieren. Und das ist unsere Domäne.

Software-technisch ebenfalls im Kommen sind Geschäftsregeln. Wie sehen Sie deren Rolle?
Man könnte die Steuerung von Prozessen aus dem Kontrollfluss der Systeme herausziehen und in Business Rules ­dokumentieren, so dass man sie wiederverwenden kann. Man kann dann die gleichen Regeln in verschiedenen Prozessen benutzen und auch in einem Prozess mehrmals die gleichen Regeln. Im Augenblick haben wir durch Workflow-Technologie die Kontrollstruktur herausgezogen und die Software flexibler gemacht. Wenn wir als nächstes die Geschäftsregeln herausnehmen, dann haben wir nur noch kleine Bausteine, die sich verbinden lassen. Damit hätte man noch mehr Flexibilität.

Werden die Aris-Tools entsprechend ergänzt? Für die Engine haben Sie ja gerade eine Partnerschaft mit dem Hersteller Corticon geschlossen.
Wir haben einen Editor, mit dem man Business Rules betriebswirtschaftlich definieren kann, danach lässt sich Durchgängigkeit bis zur Ausführungsebene, zur Rules Engine herstellen. Bisher sind die Regeln Ergänzungen für Spezialanwendungen ? zum Beispiel ­eine Preiskalkulation. Aber ich glaube, dass sie in den nächsten Jahren auch Teil von Software-Plattformen werden.