Regelwerk

Wenn ein IT-Projekt startet, sind meist drei Leute (Rollen) massgeblich daran beteiligt: der Verantwortliche für die Entwicklung (oft beauftragt - sprich extern), ein Verantwortlicher für die Systemintegration (gern ein externer IT-Consultant) und der Nutzniesser sprich Kunde des Projektes. Es ist kein Geheimnis, dass diese Rollen (bzw. deren Vertreter) fast immer mit Konflikten zu kämpfen haben. In einem unterhaltsamen Podcast geht der Autor Brian Sommer diesem “Teufelsdreieck” nach und untersucht die Ursachen für diese Konflikte. Einige seiner Gründe sind tatsächlich interessant bzw. deren Geschichte und Hintergründe. Hier mal zwei von ihnen.

Systemintegrator vs. Berater
Managementberatungsunternehmen hatten in der Vergangenheit immer auf die unabhängige Beratung gesetzt. Dabei haben sie die Sicht ihrer Kunden als ihre eigene eingenommen. Brown nennt es das Goldene Zeitalter der Consultants. Dann, in den 90ern, begannen die Beratungsunternehmen eigene Leute die Lösungen entwickeln zu lassen. Diese Entwicklung ging zu Lasten der Kunden. Denn jetzt wurde nicht mehr beraten, sondern verkauft. Ein Interessenskonflikt war vorprogrammiert.

Dienstleister als “einsame Wölfe”
Einige Unternehmen haben hohe Sicherheitsanforderungen. Kundendaten sind für alle Externen tabu. Solche lone wolf environments erschweren es, das beste aus den Beratern herauszuholen. Im Gegensatz dazu stehen Unternehmen, die nach dem Leistungsprinzip organisiert sind. Sie setzen eine Qualitätssicherung ein, die unabhängig von Verkauf und Vertrieb arbeitet. Damit sind so aufgebaute Organisationen viel offener für die gemeinsame Nutzung von Informationen (intern und mit ihren Kunden). Es geht um die bestmögliche Lösung. Und das ist immer im Sinne des Kunden.

Der Podcast sei allen wärmstens ans Herz gelegt, die regelmässig in konfliktreichen IT-Projekten ihr Auskommen haben. Brian gibt direkt Hinweise zum Verständnis der Motivationen hinter den beiden Projektseiten: dem Systemsintegrator und dem Lieferanten von Unternehmenslösungen.

The IT ‘Devil’s Triangle’ [podcast]

gefunden via ZDNet

Es gibt Blogeinträge, da ist die Welt nach dem Lesen nicht die gleiche wie davor. - Oder so ähnlich. Jedenfalls hat mir die Lektüre von Carole-Ann zur Entmystifizierung von CEP heute so ein Aha-Erlebnis verschafft. CEP bzw. Complex Event Processing als

ein Themenbereich der Informatik, der sich mit der Erkennung, Analyse, Gruppierung und Verarbeitung voneinander abhängiger Ereignissen (engl. Events) beschäftigt. (wikipedia.de)

Da gab es für mich hin und wieder Fragezeichen, die durch meinen Kopf wanderten. Dank des Artikels sind nun die Unterschiede und Abgrenzungen von Werkzeugen des Prozessmanagements und Business-Rules-Management-Systemen recht deutlich geworden.

Business-Prozessmanagement (BPM) und Business-Rules-Managementsysteme (BRMS) nutzen zwei Arten von Technologien: BRMS-Werkzeuge werden eingesetzt, um Businessverantwortliche ihre Entscheidungen treffen zu lassen. BPM-Tools werden für die Ausführung von Prozessen genutzt, die auf jene Entscheidungen zurückgehen, die ein BRMS-Tool abbildet. So weit, so gut. Als CEP auf den Plan trat, gab es Fragen bezüglich seiner Unterscheidbarkeit zu BPM und BRMS und letztlich seines Einsatzgebietes - oder wie Carol-Ann beschreibt:

When CEP comes into the picture, we feel compelled to question this model.  Is CEP the right technology for processes?  Is it the right technology for decisions?  Some go as far as questioning whether CEP should replace Business Intelligence (BI) and/or Business Activity Monitoring (BAM).

weiterlesen »

Braiconn Deutschland hat gemeinsam mit Abobe eine Studie durchgeführt, die sich mit den Potenzialen von Document shared services beschäftigt. Unter Document Shared Services versteht Braiconn

konsolidierte dokumentenbasierte Informationsprozesse im Sinne einer zentral angebotenen innerbetrieblichen Dienstleistung, die auf der Basis einer einheitlichen technologischen Umgebung voll integriert sind und bedarfsgerecht (flexibel) angepasst werden können.

Klingt noch nicht ganz so plastisch. Ich stelle mir vereinfacht gesagt, Prozesse vor, die auf Basis von Formularen angestossen, beeinflusst oder abgeschlossen werden. (Ob die zum Beispiel regelbasiert sind, kann ich da noch nicht herauslesen. Das nur am Rande.)
Einer der wichtigsten Motoren für den Einsatz von Document shared services sollte die Zentralisierung von Standardprozessen sein. Sie haben enormes Potential vor allem zeitliche Belastungen aus dem täglichen Alltag im Management herauszunehmen.

Untersucht wurden 118 Unternehmen zwischen Mai und Juni 2008. Es geht vor allem darum, in welchem Masse Komplexität, Compliance und Kosten bei diesen Prozessen in eine harmonische Beziehung gebracht werden können. Befragte Manager geben bei der Steigerung der Prozessdurchlaufzeigen Steigerungen bis zu 35% an. Das ist viel. Ausserdem konnten Prozesskosten um bis zu 30% gesenkt werden. Die Prozessflexibilität erreichte sogar einen 60%igen Zuwachs. - Zahlen, die jedem Prozessverantwortlichen runter gehen müssten wie Öl. Nach Aussage der Studie wollen 40% der Befragten die Document shared services einführen. Kein Wunder bei den Zahlen. Und diese Zahl ist wohl nur vorübergehende Schätzung, denn die Studie belegt ausserdem, dass Managementlösungen auf Formularbasis auf dem Vormarsch sind.

weiterlesen »

Das werde ich mal in meiner Agenda vormerken: Mein erstes Webinar (Web seminar) - also Life-Lernen. Auf dem Blog Agile IT Architecture wird eine Lerneinheit angekündigt, der ich mit Interesse folgen werde: Make Developing Business Rule Applications Easier
Konkreter geht es um Agile Business Rule Development (ABRD).
Hintergrund ist die Feststellung, dass für die Entwicklung von Business-Rule-Applikationen generische Methodologien der Softwareentwicklung nicht mehr ausreichen.

Agile Business Rule Development (ABRD) is a step-by-step process for developing business rule applications. An iterative methodology, ABRD employs agile software-development values. Rule development is organized as a series of cycles: discovery, analysis, authoring, validation, and deployment.

Für den 7. Mai wird das Webinar angeboten und zwar kostenlos. Die Best practiceshaben orientieren sich laut Ankündigung an folgenden Lerninhalten

• Leverage ABRD (als erste open-source methodology für Geschäftsregeln)
• Implementieren der Regeln in einen SOA- oder BPM-Kontext
• Regeln entdecken und analysieren.

Ich bin gespannt, wie gut vollgepackt diese 60 Minuten werden - denn ich könnte mir noch vorstellen, dass eine Stunde ein recht sportliches Tempo ist.

Zum Artikel

Mike Schaffner schrieb vor ein paar Tagen über 8 Trends der Business-Technologie, die man nicht aus den Augen lassen sollte. Er bezieht sich auf einen Artikel, der im Consulting-Organ von McKinsey veröffentlicht wurde. Hier die 8 Trends, die es nach Schaffner zu beobachten gilt:

Relationship Management

• Kreativität verteilen (Distributing co-creation): Das Internet erlaubt neue, kollaborative Wege für die Entwicklung neuer Produkte und Services.
• Die Bedürfnisse und das Wissen der Kunden in der Produktentwicklung einsetzen (crowdsourcing).
• Die Welt der Talente anzapfen: die virtuelle Welt kennt keine Grenzen.
• Aus Interaktionen mehr herausholen: - Technik hilft uns, unsere Anstrengungen zu fokussieren und überführt transaktionsbezogene Aktivitäten in kosteneffektivere Lösungen

weiterlesen »

Nach einem Whitepaper, das BEA Systems in den letzten Tagen veröffentlich hat, ist Business Process Management noch längst nicht auf dem Zenit angekommen. Im Gegenteil - die Kurve für Interesse und Aufmerksamkeit steigt weiterhin steil nach oben. BEA hat zahlreiche Reports, Umfragen und Fachartikel analyisiert und kommt zu folgendem Ergebnis was die Trends in diesem Jahr angeht.

• Starkes Wachstum - Der BPM Markt ist einer der schnellstwachsenden Märkte der Softwareindustrie. Bis 2011 erwartet man eine 10-fache Wachstumrate.
• Konsolidierungen und gebündelte Technologien - Die Marktbereinigungen sind in vollem Gange. Heute agieren nur noch 25 Anbieter gegen 150 Anbietern in 2005.
• verkürzte Projektlaufzeiten - immer komplexere Prozesse werden mit BPM gesteuert. 65 Prozent der eingesetzten BPM-Lösungen integrieren bereits drei oder mehr Systeme. Eine stärkere Integration in bestehende Systeme sind die wichtigsten Trends in diesem Jahr.
• Mehr Kontrolle im Unternehmenmanagement - die Herausforderungen liegen vor allem in der Verbesserung der internen Policies und der Change Management Prozesse.

Ausserdem gehen von Collaborations- und Social Computung starke Impulse aus. Für die meisten IT- und Businessmanager steht zudem fest, dass der Optimierung der Prozesse dringlichste Aufmerksamkeit zukommen muss. Es ist signifikant, dass dieser Herausforderung höhere Priorität eingeräumt wird als beispielsweise der Markteinführung neuer Produkte oder globales Wachstum. Ja sogar die Kostenkontrolle soll gegenüber der Verbesserung der Prozesse zurückstehen.Das Whitepaper hat sich zur Aufgabe gemacht, einige Fragen näher zu betrachten.

• Wie sieht der aktuelle BPM-Markt aus (Übersicht, sein Wachstum und Reifegrad)
• die Top-7-Treiber für den ROI im BPM
• Wie verbessern BPM-Marktkonsolidierungen und Technologiekonvergenz den Kundennutzen
• Wie verändern Kollaborationen und Social Computing Ad-hoc-Prozesse werden
• Wie BPM  immer stärker die tradionellen Unternehmensanwendungen verbinden wird.

Nach einer kostenlosen Registrierung kann man sich das Whitepaper bei BEA herunterladen. Leider müssen europäische Anfragen mit einigen Problemen bei der Anmeldung zurecht kommen.

Habe einen lohnenden Artikel bei Jim Sinur (Perspectives on Business Process Management) gefunden, dessen Aussagen ich vollkommen beipflichten möpchte. Er beschreibt fünf Gründe, die aus seiner Sicht mit Sicherheit dazu führen, das ein Business Prozessmanagement zum Scheitern verurteilt ist.

1. Das Management unterstützt BPM nur halbherzig.
Einer der entscheidenden Umstände für erfolgreiches Business-Prozessmanagement ist die Unterstützung aus der Geschäftsleitung. Der Hauptgrund hierfür - es gibt zuwenig Geschäftsführer, die die Dringlichkeit von professionell geführten BPM verstanden haben und deshalb BPM ungeteilte Aufmerksamkeit zuteil werden lassen.
Wenn es an ausreichender Unterstützung durch die Geschäftsleitung fehlt, hilft möglicherweise ein Visionär im Unternehmen weiter, der verinnerlicht hat, dass gute Prozesse immer eine Erhöhung der Produktivität bedeuten - und der natürlich die nötige Kompetenz besitzt, Werkzeuge für diese Visionen einzufordern. Meistens jedoch müssen Business-Prozessmanager ohne diesen Support auskommen. Alles was jetzt eigentlich hilft, ist ein Modellprozess in kleinerem Masstab, der in wenigen Monaten umgesetzt werden kann. Wiederholbare - sprich kalkulierbare Wirkungen - sind es, die die Unterstützung eines Business Prozessmangementes realistisch werden lassen.

weiterlesen »

Einen wirklich gutes Summary, wie ein Business Process Management (BPM) aufgebaut werden sollte, habe ich in einem PDF der Butler Group nachlesen können. Und nicht nur das. Im Enterprise Decision Management Blog fand ich dazu auch noch einen lesenswerten Kommentar von dem hier schon häufiger zitierten James Taylor - mit dem recht eindrücklichen Titel Business rules are core to the BPM/SOA value proposition.

Die Butler Group hatte im vergangenen Jahr einen ausführlichen Bericht erstellt, zu dem jetzt ein Management Summary erhältlich ist.

KEY FINDINGS

• Business Process Management (BPM), as a product in its own right, has emerged from the competitive influences of the diverse workflow, integration, and re-engineering camps to deliver solutions that allow the intellect of business users to be a key driver of success.
• During the last two years solutions that operate under the BPM banner have become more functionally inclusive.
• When used to its best advantage, high-calibre BPM provides a systematic approach to improving business and operational processes.
• Cost-saving benefits may provide an initial attraction, but it is product quality and persistent usage that will drive the ongoing benefits of BPM.
• There remains a requirement to address the functional divide between what the BPM software vendors are delivering and what business services users really need from core BPM products.
• A Business Rules Management System (BRMS) approach to development will reduce the inefficiencies that exist within current development methodologies.
• The emergence of rules as a subset of BPM is an indication of the growing maturity of the market.
• Possibly the most important aspect of a rules repository, certainly in respect of the stated promise of BPM, Service Oriented Architecture (SOA), and BRMS, is the ability for the developer to re-use rules within multiple process deployments.
• Butler Group positions SOA and its associated integration services as having a crucial role to play in the BPM service delivery picture.
• Business Activity Monitoring (BAM) promises to keep processes running smoothly, but information overload could end up being counter-productive.
• BPM continues to struggle with standards and their agreed usage. Fundamentally if the sector cannot reach a consensus on the use of headline standards such as Business Process Execution Language (BPEL) and Business Process Modelling Notation (BPMN), there is little chance of it progressing further down the scale.

Zum Management Summary der Butler Group,
Business rules are core to the BPM/SOA value proposition von James Taylor

Zum Theme Business Rules Management System (BRMS) fand ich eben in meinen Feeds einen Beitrag von Column2, der sich auf die Gartner BPM Konferenz der letzten Woche bezieht. Auf dieser Veranstaltung hielt Marc Kerreman zum aktuellen Entwicklungsstand von Business Rules Management Systems einen Vortrag. Wie stark Business Rules in Geschäftsprozesse eingreifen und sie optimieren können, war darin Schwerpunkt.
Business Rules werden als implizite und explizite Regeln definiert, die eine Geschäftsaktivität definieren und beschreiben (wobei implizit meint, das die Regeln in Applikationen eingebettet sind).

Auf dieser Basis wurde an dem Gartner-Event diskutiert, in welchem Masse sich Geschäftsregeln innerhalb eines Unternehmens durch geografische oder andere regulatorische Faktoren stark unterscheiden können. Marc Kerreman beschrieb die Vorteile von Business Rules Managementsystemen (BRMS), um die Komplexität von Geschäftsregeln quer durch ein Unternehmen hinweg in den Griff zu bekommen. Wichtig für diesen Aspekt ist, wer die Regeln eigentlich verwaltet bzw. verantwortlich für sie ist. Das sind entweder

• Business Manager - sie bestimmen jene Regeln, die häufig geändert werden müssen, um geschäftliche Agilität sicherzustellen; sie definieren und verfassen vor allem die die weniger komplexen Regeln.
• Systemarchitekten verfassen die weiaus komplexeren Regeln und sind ausserdem dafür verantwortlich, dass das System reibungslos performt.
• Businessanalysten entwerfen neue Regeln - basierend auf ihren Analysen; sie erforschen und simulieren Regelszenarien.

weiterlesen »

Ein kurzes Video gibt es zur Zeit auf TechWeb TV zu sehen. Thema: Online Account Opening & Other Biz Process Improvements. Sunny Banerjea (Global Solutions Leader) und Adam Lawrence (Industry Sales Executive) - beide von IBM - geben kurz Auskunft über die Probleme und Herausforderungen für Prozessoptimierungen im Online Banking. Tasks, die in Banken sozusagen zum täglichen Geschäft gehören.