Hoe procesbewust zijn onze bedrijfsinformatiesystemen?

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, BPMN

Continue!

Gooien bedrijven binnenkort standaard applicaties overboord?

Bedrijven die opereren in dynamisch complexe en onvoorspelbare omgevingen worstelen steeds vaker met het gebrek aan wendbaarheid van hun bedrijfsprocessen. Zij zijn daardoor niet in staat om snel in te spelen op veranderingen in hun omgeving en voorgenomen groeiambities waar te maken.

Om te overleven moeten bedrijven zorgen dat de inrichting van hun organisatie en processen aansluit bij de strategie van de onderneming en dat zij over middelen beschikken die het mogelijk maken om snel en flexibel het verloop van bedrijfsprocessen aan te passen of nieuwe bedrijfsprocessen in te richten.

Veel bedrijven beschikken niet over de juiste bouwstenen en zitten volledig vast in de starheid van hun bedrijfsapplicaties. Deze situaties zijn vaak ontstaan door gemaakte keuzes tijdens het selectie- en implementatietraject. Over het algemeen trekken organisaties onvoldoende tijd uit om de huidige en toekomstige processen en informatiebehoeften gedetailleerd in kaart te brengen. Hierdoor slagen zij er niet in om de unieke en dynamische kenmerken van hun bedrijf en de markten waarin ze actief zijn boven tafel te krijgen.

Vaak kiezen bedrijven voorzichtigheidshalve voor een best-of-suite benadering. Dan wordt een geïntegreerd bedrijfsinformatiesysteem geselecteerd die alle benodigde functionaliteiten bevat en een leverancier die verantwoordelijk wordt gemaakt voor de invoering van het systeem.

Van de leverancier wordt verwacht dat deze bekend is met de industrie en branche waarin een bedrijf opereert en in staat is om de processen te vertalen naar functionaliteiten in het systeem. Echter gaan leveranciers voorbij aan het gegeven dat elk bedrijf een complex, dynamisch en uniek samenspel is van processen, informatie en mensen (gebruikers). Zij richten zich op het aanpassen van de processen aan de mogelijkheden van het systeem en waar nodig het bouwen van maatwerk voor ontbrekende functionaliteit.

Aan het eind blijft weinig van de eigen identiteit van een bedrijf over en hebben medewerkers hun manier van werken aangepast aan de beperkingen van het systeem. Bedrijven komen daarna door de starheid van het systeem zelden toe aan het verbeteren van processen. Wanneer dan het klant specifieke maatwerk een overstap naar een nieuwe versie of de invoering van additionele functionaliteiten belemmert, gaat het systeem de groei van het bedrijf volledig in de weg staan.

Het probleem met maatwerk binnen geïntegreerde suites zit vooral in het centrale data model en de verwevenheid van functionaliteiten. Wanneer standaard objecten hergebruikt of aangepast worden zal een upgrade altijd leiden tot verplichte aanpassing van dit maatwerk. Om het maatwerk het hoofd te bieden zien bedrijven na jaren van wikken en wegen slechts één uitweg: 'een complete her-implementatie van de bedrijfssoftware' of 'de selectie en invoering van een volledig nieuwe oplossing waarin het maatwerk als standaard is opgenomen'.

Met de volwassenheid van de huidige technologische mogelijkheden kunnen bedrijven kiezen voor een minder ingrijpende aanpak. Een aanpak die primair uitgaat van het te ondersteunen bedrijfsproces en gericht is op maximaal (her)gebruik van standaard aanwezige functionaliteiten.

In deze aanpak wordt gestreefd naar het ontwikkelen van proces-gedreven applicaties, respectievelijk procesgerichte organisaties, via een leverancier- en technologie onafhankelijke benadering. De nadruk ligt niet op het herontwerpen van bedrijfsprocessen maar op het ontwerpen en modelleren van bedrijfsprocessen en services tot volledige uitvoerbare applicaties.

Alvorens de genoemde aanpak te beschrijven laat ik zien hoe de procesgerichte en technologie-gedreven benaderingen in de afgelopen jaren naar elkaar toe gekropen zijn. En belangrijker nog hoe ze een manier gevonden hebben om naast elkaar te bestaan, elkaar te versterken en nieuwe mogelijkheden te bieden aan bedrijven om processen te automatiseren.

In een reeks vervolgartikelen ga ik in op de ontwikkelingen rondom procesgerichte en technologie-gedreven benaderingen.

- [Deel 1] Hoe procesbewust zijn onze bedrijfsinformatiesystemen? Hier probeer ik het concept van configureerbare procesmodellen te verduidelijken en kijk ik naar het procesbewustzijn van de huidige bedrijfsinformatiesystemen.

- [Deel 2] Kan Process Mining bedrijven helpen bij het verbeteren van bedrijfsprocessen? Proces Mining is een methode om uit informatie die vastligt in informatiesystemen (logboeken en transacties) het werkelijke verloop van processen af te leiden. Ik zal deze methode beschrijven en de toegevoegde waarde van Process Mining voor het verbeteren en garanderen van conformiteit van processen toelichten. Verder ga ik de traditionele en op Process Mining gebaseerde benaderingen in een tabel naast elkaar zetten.

Interessant is de ontwikkeling bij Again om met behulp van Process Mining technieken een oplossing te ontwikkelen voor het analyseren van inkoopprocessen in SAP.

- [Deel 3] Internationaal is BPMN, Business Process Model & Notation, uitgegroeid tot de standaard voor het modelleren van bedrijfsprocessen. BPMN versie 2 ondersteunt het ontwerpen van procesmodellen op 3 niveaus met een toenemende mate van detail. Het meest gedetailleerd niveau – het uitvoerbare procesmodel (Executable Process Model) voorziet in het beschrijven van de functies die uitgevoerd moeten worden. Deze uitvoerbare procesmodellen kunnen omgezet worden naar programmacode (“code generation strategy”) of geïnterpreteerd worden (“model interpretation strategy”).

In dit deel ga ik in op hoe we proces- en service gedreven informatiesystemen kunnen ontwerpen en hoe een proces-gedreven informatiesysteem eruit (kan zien) ziet.

Daarna kijk ik naar de verschillende gereedschappen en/of oplossingen die beschikbaar zijn om dit alles waar te maken. Vooruitlopend hierop wil ik kort een aantal aanbieders van gereedschappen in Nederland de revue laten passeren.

In relatie tot eerder genoemde strategieën voor het omgaan met procesmodellen zie ik volgende spelers:

Softwareleverancier Mendix heeft een oplossing voor het model gedreven ontwikkelen van applicaties. De Mendix Business server gaat modellen die zijn opgeslagen in een model repository interpreteren en uitvoeren.

Outsystems en PegaSystems, twee andere aanbieders van model gedreven oplossingen, genereren programmacode die gedeployed wordt naar een applicatieserver.

E2E, een Zwitserse speler die actief is in Nederland, biedt een oplossing voor het modelgebaseerd ontwerpen van integratiemodellen. Deze modellen worden geïnterpreteerd en uitgevoerd door de E2E Server. De E2E Server is een virtuele machine (“process execution engine”), een combinatie van een Enterprise Service Bus en lichtgewicht applicatieserver.

- [Deel 4] Als laatste ga ik toelichten hoe we in mijn optiek deze concepten kunnen gebruiken voor het terugdringen van maatwerk in bestaande bedrijfsinformatiesystemen?

Voor hen die direct naar oplossingen willen springen of meer willen zien / lezen:

- Lees het boek: “Build for Change”, van Alan Trefler, CEO van Pegasystems

http://www.pega.com/insights/resources/build-change-alan-trefler

Of bekijk de video’s: https://www.youtube.com/user/Pegasystems

- Lees het boek: “Process-Driven Applications with BPMN”, van Volker Stiehl of bekijk het artikel van Bruce Silver over een nieuwe aanpak voor Executable BPMN

http://brsilver.com/process-driven-applications/

- Volg de webinars van Marcello La Rosa & Marlon Dumas

From Conceptual to Executable BPMN Process Models (Part 1)

https://www.youtube.com/watch?v=2TzKdMndiSA

From Conceptual to Executable BPMN Process Models (Part 2)

https://www.youtube.com/watch?v=mgZ5B-yUrwY

- Bekijk de video’s van E2E - Model Driven Integration company

https://www.youtube.com/watch?v=tPk-DOBCEEI

Tags: Process Modeling, BPMN

Continue!

How can we beat the growing complexity of electronic business and procurement ?

For many years the main obstacles and impediments to the uptake of e-procurement, e-business and e-invoicing were divergent legislation and technical complexity. Although the European Commission devoted much effort to increase legal certainty and reduce technical complexity, companies are still reluctant to implement. Many decision-makers are concerned about the multiplicity of solutions available on the market, the cost of implementation and the number of business partners that can be connected. But most of all, they are overwhelmed by the data and process integration complexity.

Despite all standardization initiatives - this complexity is increasing, mainly due to:
- the growing number of platforms and networks which are not interoperable

- the existence and growth of more non-interoperable proprietary and national standards

- ERP systems that do not have a standardized process-aware interface

In my view - the lack of interoperability across the multitude of networks and the inability of providers to fully relieve clients from the complexity of implementation are to be regarded the main reasons for the loss of trust and confidence.

The main challenges to fight complexity are: more openness and insight; and more safeguards and guarantees for implementers.

- More openness and insight

Selecting the right solution and service provider from the variety of options available on the market is hard. Companies when asking providers, are told everything, - technology platform, data standards, network connections, integration tools and other resources - needed to establish these kind of services is readily available. In general providers estimate the cost and complexity of integration to be low and promise to fully relieve organizations from the burden of connecting trading partners. They often forget to indicate what precisely is understood and how much effort is required from the organization itself and its trading partners.

Moreover, we all know, the success of establishing inter-firm communication and collaboration processes depends a lot on the readiness of the industry or market sector in which a company operates and on the maturity of information processes and systems of enterprises. But providers neglect this critical aspect in their estimations and proposals, because their commitment does not cover repetitive effort to contact and convince partners nor does it include solving integration challenges.

It is my belief that companies should not rush into adventures without proper preparation and consultation of experts in the field. If you want a fair and unbiased opinion, start with executing a readiness assessment, get a clear view on the capabilities of your enterprise information system (ERP or CRM) and determine your short and long term business goals and strategy. Do not forget to develop your business case and remember it is not only about costs, but also sustainability, customer intimacy, competitive advantage, compliance with governmental regulations are factors to consider. Last but not least, consult your trading partners and investigate what is being done in the industry.

Providers, to prepare for success, should provide better and more detailed information about the characteristics of their systems such as: number of already connected partners, information flows and processes; number of operational network connections; and the required involvement of internal technical and business specialists. Too often communicated figures drop to lower levels after contracts are signed, which results in a lot of questions, frustration and disappointment.

More openness from both sides and insight in strengths and weaknesses are boundary conditions for making the right choices and realizing defined goals.

- Establishing more guarantees:

Interoperability is not about Interoperability Agreements between service providers but about delivering quality solutions and services. Nowadays the availability of Interoperability Agreements is the main argument to attest interoperability abilities. However demonstrated proof is the only key for a qualitative judgement about a given solution or service. When implementing e-procurement or e-business it is not about what is possible or supported in the (near) future but about what is available from the start.

In my opinion it is time to install a "European Standards and Interoperability Conformity Assessment System" to assure that solutions and services deliver what providers claim and to give confidence to decision-makers. Besides, conformity promotes fair competition and stimulates quality improvement.

The conformity assessment system should be managed by a European Organization for Technical Assessment of e-Procurement and e-Business systems.

This organization has to develop
- a set of clear principles that will allow interested parties to have confidence in the process of providing conformity assessment [USCAP 2011]

- a document describing the process of performing conformity assessment

- a technical specification describing interoperability requirements

- an operational infrastructure for performing interoperability tests

Much work has already been done within the first and second phases of the Global e-Business Interoperability Test Bed project (GITB).

The Global e-Business Interoperability Test Bed project (GITB) focuses on methodologies and architectures that support e-business standards assessment and testing activities from early stages of eBusiness standards implementation, to proof-of-concept demonstrations, to conformance and interoperability testing.

The main and long term objective of GITB is to develop, under EU support and guidance, a set up of a comprehensive and global eBusiness interoperability test bed system in a global collaboration of European, North American and Asian partners. GITB is a global initiative hosted by CEN and supported by ETSI, EIC, NIST, KorBIT and the industry associations AIAG and IAI.

It would be great if in the third phase time could be spent on establishing an assessment and certification system for interoperability. This would drive up confidence of decision-makers in the solutions and services available on the market.

Tags: e-Business, e-Procurement, e-Invoicing

Continue!