In de voorbije 10 jaar is veel academisch onderzoek verricht naar “Process Aware Information Systems (PAIS)”. In publicaties [zie referenties] van Wil van der Aalst en anderen wordt de volgende definitie gehanteerd:
“A Process-Aware Information System (PAIS) is a software system that manages and executes operational processes involving people, applications, and/or information sources on the basis of process models.”
Een vrije vertaling van deze definitie luidt als volgt: “Een Procesbewust Informatiesysteem is een software systeem dat operationele processen beheert en uitvoert op basis van procesmodellen en daarbij mensen, applicaties, en/of informatiebronnen betrekt”.
Volgens de onderzoekers worden Procesbewuste Informatiesystemen gedreven door proces- en servicemodellen. Daarbij ligt de focus op het verkrijgen van een strikte scheiding tussen proces- en applicatielogica. Deze scheiding van belangen maakt het mogelijk om beiden, processen en applicaties, onafhankelijk van elkaar te wijzigen.
Het onderzoek naar Procesbewuste Informatiesystemen richt zich op het modelleren, analyseren, verbeteren en monitoren van bedrijfsprocessen. Dit heeft geleid tot enkele conceptuele benaderingen die een zinvolle bijdrage leveren aan het realiseren van aanpasbaarheid, installeerbaarheid, controleerbaarheid en geschiktheid van processen en systemen.
Voor de inrichting van processen hebben de onderzoekers het concept van Configureerbare Procesmodellen (“Configurable Process Models”) bedacht.
Configureerbare Procesmodellen zijn modellen waarin meerdere procesvarianten, die dezelfde of soortgelijke doelstellingen nastreven, worden samengevoegd in één model. De aanleiding voor het bestaan van verschillende procesvarianten kunnen zijn: verschillen in wet- en regelgeving tussen landen of verschillen in behoeften en verplichtingen tussen vestigingen.
Kanttekening: Het ontwikkelen van Configureerbare Referentie modellen uitgaande van verschillende procesvarianten is geen eenvoudige opgave. Het vraagt om diepgaande kennis van het bedrijfsdomein en van de modelleertaal BPMN2. (BPMN2 is algemeen geaccepteerd als taal voor het modelleren van bedrijfsprocessen)
Het configureren van procesmodellen doorloopt 4 fasen:
- Fase 1: Specificatie (design-time): De configureerbare procesmodellen worden ontwikkeld.
In een Configureerbaar Procesmodel worden verschillend varianten van processen samengevoegd in één model. Procesvarianten kunnen zijn: referentiemodellen van branche- of beroepsverenigingen, Industrie referentiemodellen, procesmodellen van ERP leveranciers gebaseerd op best practices.
Kanttekening: Industrie referentiemodellen worden gekenmerkt door een groot aantal kruispunten met complexe afhankelijkheden. Deze modellen zijn vaak alleen in PDF beschikbaar en moeten nog overgebracht worden naar een procesmodel. Dat geldt voor een aantal van onderstaande referentie modellen.
Het APQC PCF (American Productivity & Quality Center – Process Classification Framework);
Het APICS SCOR model (APICS Supply Chain Council – Supply Chain Operations Reference SCOR®);
Het VCG VRM (Value Chain Group – Value Reference Model);
Het TM Forum Business Process Framework (Etom)
De scheiding tussen procesvarianten in een Configureerbaar Procesmodel wordt gemarkeerd door een configureerbaar kruispunt. Een configureerbaar kruispunt representeert een ontwerpkeuze die een procesanalist moet maken bij het configureren van het uiteindelijke procesmodel.
Kanttekening: Configureerbare kruispunten maken nog geen onderdeel uit van de officiële BPMN Versie 2.0 specificatie.
- Fase 2: Configuratie (configuration-time): Het procesmodel wordt specifiek gemaakt voor een organisatie. Dit leidt tot een geconfigureerd procesmodel.
- Fase 3: Deployment (Instantiation-time): Het geconfigureerd procesmodel wordt gedeployed naar de proces-laag waar het model als template dient voor processen die worden uitgevoerd.
- Fase 4: Operatie (run-time): Afzonderlijke instanties van een proces worden uitgevoerd volgens het geconfigureerde model.
Kanttekening: In later onderzoek [4] is de fase transformatie toegevoegd. Deze fase is bedoeld om geconfigureerde procesmodellen te transformeren naar de taal van het bedrijfsinformatiesysteem dat in gebruik is.
Volgens de onderzoekers maakt het ontwikkelen van Configureerbare Procesmodellen onderdeel uit van de levenscyclus van Procesbewuste Informatiesystemen. Grofweg ziet de levenscyclus van een Procesbewuste Informatiesysteem er als volgt uit:
In deze levenscyclus zijn niet opgenomen het modelleren van gebruikersinterfaces en services, het ontwikkelen van applicatie componenten, en het ontwerpen van de persistentie modellen.
Voor het vereenvoudigen van procesmodellen wordt gebruikt gemaakt van beslismodellen. Deze beslismodellen worden aangeroepen via een Business Rule Task. Deze Business Rule Task verwacht weer output terug die dan door een Decision Gateway gebruikt wordt om het vervolg van het proces te bepalen.
Beslismodellen worden gemodelleerd met de DMN Decision Model & Notation standaard en uitgevoerd door een Business Rule Engine. Het modelleren van beslisregels gebeurt met een Business Rules and Decision Management System. De beslismodellen kunnen onafhankelijk van het procesmodel worden aangepast.
Wanneer organisaties gebruik maken van eenzelfde Procesbewuste Informatiesysteem dan is het niet mogelijk om afwijkende processen te implementeren. Het gebruik van beslismodellen biedt dan wel de nodige flexibiliteit voor het afhandelen van processtappen.
“Een Procesbewust Informatiesysteem is een software systeem dat operationele processen beheert en uitvoert op basis van procesmodellen en daarbij mensen, applicaties, en/of informatiebronnen betrekt”.
Wanneer we opnieuw kijken naar de definitie van een Procesbewust Informatiesysteem dan zien we dat bij de huidige bedrijfsoplossingen het procesbewustzijn niet verder gaat dan “op basis van procesmodellen”, BPM en WFM systemen daargelaten. Deze laatsten richten zich dan ook in het bijzonder op het automatiseren van bedrijfsprocessen en werkstromen.
Bedrijfsapplicaties zoals ERP, CRM, WMS, PLM en MES – beschikken wel over enige vorm van procesbewustzijn maar zijn in beginsel functie-georiënteerd en data-gedreven. Het procesbewustzijn ligt opgeslagen in programmacode of in tabellen en kan alleen aangepast worden door het ontwikkelen van maatwerk of het wijzigen van configuratie parameters.
Bovendien wordt de workflow functionaliteit die in sommige applicaties aanwezig is niet of nauwelijks gebruikt. Dit komt vooral doordat de functies voor het uitvoeren van een proces in een menu zijn opgenomen. Gebruikers hebben zodoende geen behoefte aan een geautomatiseerde werkstroom. De programmacode valideert regelmatig de status van het object waar een gebruiker mee bezig is alvorens toestemming te geven om verder te gaan.
Kanttekening: In de moderne geïntegreerde bedrijfsinformatiesystemen hebben gevestigde leveranciers voor een meer proces-gedreven benadering gekozen.
- Het beste voorbeeld van een volledig geïntegreerde omgeving is QAD Enterprise Applications. QAD maakt gebruik van Progress Corticon BRMS voor het modelleren van besluitvormingslogica en van Progress OpenEdge BPM voor het modelleren van bedrijfsprocessen.
- SAP heeft met SAP NetWeaver CE (Composition Environment) waar SAP NetWeaver BPM (Business Process Management) en NetWeaver BRM (Business Rule Management) deel van uitmaken een omgeving waarmee volledig proces-gedreven bedrijfsinformatiesystemen gebouwd kunnen worden.
SAP NetWeaver CE (Composition Environment) maakt het mogelijk om service-geschikte (service-enabled) functionaliteiten uit de SAP Business Suite applicaties (ERP, CRM, …) en services van anderen samen te voegen tot – wat heet – ‘composite applicaties’ die zelf weer service-geschikt zijn. Al deze verschillende services kunnen dan weer gebruikt worden in de procesmodellen om een volledig proces-gedreven oplossing te realiseren.
In 2010 heb ik voor een groep van organisaties met verschillende SAP en andere systemen voorgesteld om een gedeelde generieke omgeving voor de ondersteuning van inkoopprocessen met leveranciers te ontwerpen op basis van SAP NetWeaver Composition Environment.
Het idee was om deze organisaties de mogelijkheid aan te reiken om onderdelen uit de gedeelde inkoopomgeving te gaan gebruiken naast bestaande organisatie-specifieke functionaliteiten. Een soort cafetaria-model wat op termijn voorzag in transitie van alle organisaties naar één proces-gedreven SAP omgeving.
De architectuur zag er als volgt uit:
De generieke functionaliteit bestaat uit service-geschikte functionaliteiten uit een centrale SAP ERP of SRM omgeving. Deze functionaliteiten zijn via de SAP Composition Environment als services beschikbaar gesteld.
- Organisatie 1 maakt gebruik van de functionaliteiten in haar bestaande SAP omgeving. De gegevens worden gesynchroniseerd tussen de bestaande SAP database en de generieke SAP database. Leveranciers hebben toegang tot deze gegevens via de web-gebaseerd user interface. Facturen worden elektronisch aangeleverd.
- Organisatie 2 maakt gebruik van de generieke functionaliteit voor contracten en catalogi maar de verwerking van orders, ontvangsten en facturen gebeurt in de eigen omgeving. De leveranciers hebben toegang tot orders en kunnen ontvangsten en facturen registreren via de web-gebaseerde user interface. De order-, ontvangst- en factuurgegevens worden gesynchroniseerd tussen de bestaande en generieke SAP database.
- Organisatie 3 maakt volledig gebruik van de generieke omgeving.
- Organisatie 4 maakt intern gebruik van contracten en catalogi maar laat deze niet onderhouden door leveranciers. Orders en facturen worden elektronisch uitgewisseld met leveranciers. Organisatie 4 maakt geen gebruik van de generieke functionaliteit.
Hiermee sluit ik deel 1 af en nodig ik iedereen uit om te reageren.
Binnenkort vind u hier de andere artikelen uit deze reeks.
Tags: Process Modeling, BPMN2
