Thought Leadership
Agilität und Industrialisierung von Geschäftsprozessen sind für ein Unternehmen entscheidend, ob man zu den Gewinnern oder Verlierern auf dem globalen Markt zählt. Agilität bedeutet die Fähigkeit zur Innovation und die Anpassungsfähigkeit der eigenen Geschäftsmodelle.
Schnelle Reaktionen und pro-aktive Initiativen binden Kunden und schlagen Wettbewerber aus dem Feld. Eine immer höhere Marktdynamik ist die treibende Kraft. Weitere starke Antriebskräfte insbesondere in Krisenzeiten sind die Kostenreduktion und die Einhaltung von Vorschriften (Compliance)! Daher konzentrieren sich führende und erfolgreiche Unternehmen darauf, ihre Strategien mittels durchgängiger, intelligenter und flexibler Geschäftsprozesse dynamisch umzusetzen.
Die Dynamik fordert ihren Tribut
Ein Problem dabei ist eine heute immer noch traditionell arbeitende IT, die in der Regel zu 80% mit Wartungs- und Betriebsaufgaben beschäftigt ist. Zur Abdeckung der Anforderungen aus den Fachabteilungen, besonders wenn es um Implementierung und das Betreiben von Kreativ- und Situativ-Prozessen geht, fehlen in vielen Fällen Ressourcen und Budget. Dazu kommt, dass sich traditionelle Methoden und Werkzeuge zum BPM nicht für Kreativ- und Situativ-Prozessen eignen. Diese „adhoc“-Prozesse stellen in gewisser Weise den „Long Tail“ aller Geschäftsprozesse dar: Es sind viele, sehr unterschiedliche Prozesse mit außerordentlich hoher Dynamik, aber nicht unbedingt vielen Instanzen. Sie lassen sich nicht in Workflow-Schemata pressen. Es sind Prozesse, deren Geschäftsregeln und Fachlogik so dynamisch sind, dass auch traditionell programmierte Anwendungen an ihre Grenzen stoßen.
Beispiel: Der Mitbewerber eines Telekommunikationsanbieters hat einen neuen Vertriebskanal geöffnet und gewinnt Marktanteile. Jetzt geht es darum, sich schnellstens auch in diesem Kanal zu präsentieren und ein in diesem Kanal wettbewerbsfähiges Produkt zu haben. Das bedeutet, dass man möglichst innerhalb von wenigen Tagen das neue Produkt komponieren und in den Markt tragen kann. Dazu gehört auch das Abrechnungssystem mit dem Kanalbetreiber und mit den Kunden. Wenn man die notwendige Applikation traditionell entwickelt, kann das einige Wochen bis Monate dauern. Selbst mit einem traditionellen BPM-Werkzeug lassen sich solche Anforderungen kaum schneller umsetzen. In der Zwischenzeit gewinnt der Mitbewerber Marktanteil um Marktanteil. Time-to-Market matters.
Der Weg aus der Sackgasse
Heute werden solche Situativ-Prozesse vielfach immer noch manuell ausgeführt oder man bedient sich in der Fachabteilung der üblichen Endanwenderwerkzeuge Excel, Access und E-Mail. Der scheinbare Vorteil: Die Fachabteilung ist autonom von der IT und kann neue situativ benötigte Funktionalität schnell nachziehen. Traditionelle Software-Releaseverfahren sind in den Augen der Fachabteilungen hier nicht ausreichend, da zu langsam und inflexibel. Will man aber solche Lösungen kompliant machen oder globalisieren, so stellt man schnell fest, dass man in einer Sackgasse steckt. Jetzt werden neue Wege einer IT-Unterstützung erforderlich. Dazu müssen zwei Dinge radikal geändert werden:
- die Zusammenarbeit von Business und IT.
Beginnen wir mit der Methode. Das traditionelle Software-entwicklungsmodell „plan – build – deliver“ unterstützt zwar ein sauberes handwerkliches Arbeiten, aber eine handwerkliche Fertigung hat die Nachteile, langsam und teuer zu sein. Um in der IT schneller und preiswerter zu werden, müssen wir das Entwicklungsmodell ändern. Die Idee „wie“ kommt aus der industriellen Produktion. Hier war einer der großen Durchbrüche im Sinne der Produktivitäts- und Qualitätssteigerung die Komponentenfertigung. Basierend auf einer Plattform wird durch Komposition verschiedener vorgefertigter Bauteile schnell, sicher und zuverlässig produziert. Das neue Paradigma einer industriellen Fertigung lautet:„source – make – target“
Diese Prinzipien sollten in gleicher Weise in der IT eingeführt werden. Der Vorteil einer handwerklichen Fertigung ist aber eine maßgeschneiderte Individuallösung. Hier genau liegt das zweite Problem, unter dem eine traditionelle IT vielfach leidet. Um den Vorteil der Individuallösung zu erreichen, muss die IT die exakten Vorgaben des Business bekommen und umsetzen. Leider hat das nicht immer funktioniert: IT und Business verstehen sich in vielen Fällen nicht. Die Ursache liegt in der Unterschiedlichkeit der Sprache der Fachabteilungen und der Sprache der IT. Ein fachliches Design einer Aufgabenstellung, die durch IT-Unterstützung zu einer höheren Produktivität und Steigerung der Qualität im Business führen soll, unterscheidet sich vom technischen Design auch im heute als Lösungsansatz vielfach propagiertem BPM.
Diese Bruchstelle verhindert einen umfassenden Ansatz zur Feststellung der Konsistenz von fachlichem und technischem Design. Die IT baut nach bestem Wissen und Gewissen, aber eine Garantie, dass die fachlichen Anforderungen korrekt in der technischen Lösung umgesetzt sind, gibt es nicht. Der Lösungsansatz heute: Man iteriert die IT-Lösung und hofft auf eine Konvergenz von Fachlichkeit mit der IT-Lösung. Trotz methodischer Fortschritte im Software-Engineering ist ein solcher Prozess zur Entwicklung und Produktion von IT-Lösungen immer noch viel zu zeit- und ressourcenraubend. In diesem traditionellen Modell der Zusammenarbeit von IT und Business wird die IT als Engpass empfunden, ja sogar als Bremser von Erfolg und Fortschritt des Unternehmens. In vielen Unternehmen ist die IT nicht mehr in der Lage, der Geschäftsdynamik zu folgen und die Lösungen zu liefern, die das Unternehmen nach vorne bringen.
Wir brauchen also nicht nur eine industrielle Fertigung von IT-Produkten, sondern auch eine neue Organisation der Zusammenarbeit von Business und IT.
Jetzt kommt die Idee aus dem Web 2.0. Das Grundprinzip von Web 2.0 stellt die Beziehung von Konsument und Produzent auf den Kopf und macht aus Konsumenten Produzenten. Übertragen wir das auf die neue Zusammenarbeit von Business und IT, dann werden aus IT-Konsumenten IT-Produzenten. Das Business baut sich seine Applikationen selbstständig ohne IT. Es wurde basierend auf Ideen und Konzepten von Web 2.0 das „Mashing Up“ (Mash up, engl. „Vermanschung“, bezeichnet die Erstellung neuer Inhalte durch nahtlose (Re-) Kombination bereits bestehender Inhalte.) erfunden: Der IT-Nutzer baut seine Applikationen ohne IT. Aber Achtung: Heutige Mashups sind nicht unternehmenstauglich! Mashing Up alleine ist es nicht, wir müssen die beiden Ideen der industriellen Produktion und des Web 2.0 inspirierten Mashing Up miteinander verbinden. Das Ergebnis sind „Business Mashups“.
Im Sinne der Industrialisierung braucht man also zur industriellen Softwarefertigung nicht nur Komponenten, sondern auch eine Plattform, die die Regeln und Methoden des Mashing Ups der Komponenten beschreibt. Hier liegt der Schlüssel zur neuen Arbeitsteilung und Organisation zwischen Business und IT. Die IT muss diese Plattform schaffen und betreiben, auf der das Business selbständig und ohne Programmierung Business Mashups durchführen kann. Ein Business Mashup ist also die Komposition von vorgefertigten Komponenten per Aggregieren und Konfigurieren gemäß vorgegebener Bauvorschriften.
Das entspricht der engineer-to-order Produktion eines Autos aus den von den Zulieferern gelieferten Teilen. Das ergibt auch eine neue Fertigungstiefe in der Softwareproduktion. Bits und Bytes bleiben in der IT, das Fachwissen wird per Business Mashups schnell und flexibel in ausführbare Prozesse und Business Services umgesetzt. Die vorgefertigten Komponenten für das Mashing Up kommen von der IT oder von Softwareanbietern beispielsweise über das SaaS-Modell („Software as a Service“). Das sind die Zulieferer der industrialisierten Anwendungsentwicklung.
Eine Plattform für eine solche engineer-to-order Softwareproduktion wird heute Service Delivery Platform (SDP) genannt. Es ist eine Plattform zur Erstellung von Business Mashups durch Fachexperten, die von der IT eingerichtet und betrieben wird. Eine SDP besteht aus von der IT vorgefertigten Komponenten (den Werkzeugen, Lösungsschablonen und Regelpaketen) und der Methodik, wie man diese Komponenten anwenden, ergänzen und fertigstellen kann – kurz: eine Business-Applikation instanziiert. Insofern kann eine SDP als eine service-orientierte Standardsoftware auf einer Meta-Ebene verstanden werden, die eine Klasse von Applikationen beschreibt. Das Modell kann im Endeffekt als Ontologie verstanden werden (Eine Ontologie besteht aus einer Taxonomie, Terminologie und Semantik. Sie vernetzt Wissen und schafft so Integration.).
Die Fachexperten können so eine individuelle Instanziierung von agilen Business Services dieser Klasse vornehmen und zu einem Business Mashup komponieren. Solche Business Mashups sind nicht nur schnell und fachabteilungstauglich zu erstellen, sondern auch betriebs- und revisionssicher, also unternehmenstauglich. Das liegt daran, dass die vorgefertigten Komponenten, die am besten als Services in einer SOA bereitgestellt werden, nicht beliebig kombinierbar sind, sondern die Komposition durch entsprechende Regeln („Policies“) in der Ontologie semantisch festgelegt wird.
Bild 1: Eine Service Delivery Platform (SDP) dargestellt als Metamodell einer Klasse von Applikationen. Die Instanziierung einer Applikation geschieht revisions- und produktionssicher durch Mitarbeiter in den Fachabteilungen, während die IT für das Einrichten und Betreiben der SDPs zuständig ist. Das ist die neue Aufgabenteilung zwischen IT und Business im Rahmen einer Industrialisierung der IT, die die leidige und kostentreibende Verständnislücke zwischen IT und Business vermeidet. So gewinnt das Business höhere Produktivität und Qualität durch IT, ein Ansatz, der deutlich mehr bringt als das traditionelle Anpassen und funktionale Erweitern von Standardsoftware, vor allem ein Mehr an Geschwindigkeit. Eine SDP ist daher bestens geeignet zum Managen von Situativ-Prozessen.Insofern unterscheidet sich eine SDP grundsätzlich von traditioneller Standardsoftware, bei der die Geschäftslogik standardisiert und paketiert als Applikation geliefert wird und dann höchstens noch angepasst werden kann. Bei den Anpassungen bestehen aber immer wieder Einschränkungen, denn wenn Anpassungen nicht mehr releasefähig im Rahmen der Standardsoftware sind, verliert man alle Vorteile einer Standardsoftware. Standardsoftware ist daher dann bestens geeignet, wenn es sich um Standard-Geschäftslogik von der Stange handelt. Das beste Beispiel dazu ist eine ERP-Applikation. Eine SDP dagegen eignet sich immer dann besonders gut, wenn ein Prozess hohen Anforderungen an Änderbarkeit und Transparenz unterliegt, so dass die traditionelle Softwareentwicklung und Software-Releaseverfahren nicht mehr ausreichen. Sie eignet sich daher hervorragend zum Implementieren und Betreiben von Kreativ- und Situativ-Prozessen.
Beispiel Volkswagenbank
Projekterfahrungen aber sind noch jung: Erste Erfolge mit SDPs hat beispielsweise die Volkswagenbank mit einem Credit Risk Rating System gemacht – in den heutigen Tagen eine mehr als aktuelle Applikation! Die Innovations Softwaretechnologie, ein innovatives schwäbisches Unternehmen, das inzwischen zur Robert Bosch Gruppe gehört, hat hier diesen Ansatz erfolgreich umgesetzt. Mittels einer SDP werden bei der Volkswagenbank die notwendigen Business Services unternehmensspezifisch für die Bank und mit landesspezifischer Ausprägung für die jeweilige Niederlassung dynamisch an den Markt angepasst. Unabhängig von der IT führen die Rating-Experten Änderungen an der Geschäftslogik und der Benutzeroberfläche der Anwendung – als Instanz eines Business Services – durch. Der Fachbereich wurde so zum Service Owner. In der Tat wurde hier eine Excel/Access-Lösung abgelöst. Sie ist heute eine professionelle IT-Lösung mit der die Fachexperten dennoch autonom von der IT kompliant und konsistent im internationalen Unternehmen arbeiten können.
>> Aufzeichnung des Vortrags der Volkswagenbank (Video)<<
Neben bekannten, aber bisher in ihrer Tragweite vielfach unterschätzten Technologien wie Rule Management Systeme stecken auch neuere technologische Ansätze in heutigen SDPs wie die Object-Process-Methodologie (siehe dazu auch: www.opcat.com) oder ein dynamisches Applikations-Framework, das genau dann Vorteile bringt, wenn sich die Workflows und Benutzeroberflächen eines Geschäftsprozesses häufig ändern.
Fazit
Business Mashups erlauben die Produktion von agilen Business Services. Sie kombinieren dabei die Prinzipien einer industriellen komponentenbasierten Plattformfertigung entsprechend dem „source – make – target“ Paradigma und die Web 2.0-Konzepte von Mashing Up , so dass IT-Konsumenten zu IT-Produzenten im Unternehmen werden.
SPDs setzt man nicht ein, um bekannte und bewährte Standardsoftware zu ersetzen, sondern um sich Wettbewerbsvorteile zu schaffen: Man automatisiert die Kreativ- und Situativ-Prozesse. Mit einem dynamischen Applikationsframework hat man jetzt die Lösung zur Industrialisierung solcher Prozesse. Mehr noch, man bezieht auch die Fachexperten in den Fachabteilungen in die Erstellung ihrer Business-Applikation ein. So gelangt man durch industrialisierte Softwareentwicklung zu der neuen Arbeitsteilung zwischen IT und Business – mit deutlicher Steigerung der Produktivität bei der Erstellung dynamischer Business-Applikationen mittels Service-Delivery-Plattformen.
So hängen Business Mashups und Business Services voneinander ab
Aus fachlicher Sicht unterstützt ein Business Mashup genau einen Business Service. Ein Business Service ist eine aus fachlicher Sicht eine abgeschlossene Dienstleistung, die alle Phasen von der Konzeption und Entwicklung des Business Service bis hin zu Inbetriebnahme, Vertrieb und Vermarktung, Pflege und Wartung, Abrechnung bis zum Abschalten des Business Service umfasst. Zu einem Business Service gehört also auch sein Lebenszyklus-Management. Ein Business Service kann auch andere Business Services entlang seines Lebenszyklus und in jeder Phase verwenden. Es gilt also eine Art „Unterservice-Prinzip“: Ein Business Service kann von verschiedenen Business Services genutzt werden und kann auch verschiedene andere Business Services revisions- und betriebssicher nutzen.
Ein Business Service kann auch als eine Aktivität in einem Geschäftsprozess aufgefasst werden. Da in einem Geschäftsprozess auch ein „Unterprozess-Prinzip“ in analoger Weise wie bei Business Services gilt, ist von einem abstrakten Standpunkt aus betrachtet ein Geschäftsprozess auch ein Business Service, und ein Business Service kann auch als Geschäftsprozess verstanden werden.
Dr. Wolfgang Martin
