Implementing BPMS , the Business Way
Since All Business Process Management Software packages have their own ways and methods of making BPM implementations successful , more often than not , BPMS consultants take the BPMS product architecture driven implementation as the BPM way to go
However, in my mind, BPMS all starts from BPM and if we understand that right , this is all that is to be done for any BPMS implementation (inspite of the complexities or differences in underlying product architecture)
So What is this Business Process Management Software Implementation all about?
Let me try by picking on the basics here and start with Business Process by itself
Business Process is a coherent set of Activities and decisions * (List of activities and decisions) defined in an *Order( activities done in an order to achieve certain states ) acting upon a defined set of entities (business/data) to Achieve a Goal ( Objective of the process) within a set of defined metrics (KPI of processes) and done by Collaborating set of Roles *( Actors doing these roles) having *defined Responsibilities and has Interactions with outside world ( Triggering events /Subsequent Events/integrations
If you would now notice, this is all to a business process and surprisingly to configuring the BPMS packages as well
Let's see it again in new light and focus on the words in bold in the definition given above
Activities and decisions
Order( activities done in an order to achieve certain states )
entities (business/data)
Goal
Metrics
Collaborating set of Roles ( Actors doing these roles)
defined Responsibilities
Interactions
So, let's think again, what do we do while implementing business process management software and align it to the words in Bold above?
Understand the key business objective of the process and ensure activities/sequence and aligned to achieving it (Goal metrics)
Define the key business entities in that process ( Business/data/Class , different packages do it differently ) (entities (business/data))
Based on objectives and entities, Model the process (Activities and decisions) in an Order( activities done in an order to achieve certain states )
Configure participants/actors (*Collaborating set of Roles *( Actors doing these roles))
with Defined Responsibilities)
- Define Interfaces /triggers to get data /start/stop an activity and UI's to get inputs (Interactions with outside world ( Triggering events /Subsequent Events/integrations/UI's )
WOW....Wasn't BPMS implementation simple enough?
However, before we close this topic, it is important not to forget the last word in BPM ( Management) , it is most important before starting this madness about BPMS packages configuration to ensure and understand how ,what and why would we manage this business process we just configured above
In Extremely simple words, Managing a business process is all about
-Business Process Management (BPM)
- Capture the process
» Models (Descriptive /Execution)
» Documentation
- Analyze the process
» Productivity
» Efficiency
» Cost reduction
» Speed to Market
» Exception management
» Scalability/Maintainability
- Improve the process
» Standardization
» Automation
» Optimization
- Keep on doing step 2 and 3
All configuration of BPMS packages ( however different because of their underlying product architecture) revolves around these 2 simple definitions and each and every step done by BPMS consultants in configuring these packages is based on one of these definitions as defined above
So, does a PEGA or Lombardi or an ALBPM implementation now make sense as more of BPM rather than just another package configuration ? Think of defining the flows or the activities or setting up roles and users or integrations with data sources , they all fit in this scenario as described above
