When and how to use BPMS?

Business Process Management Suite (BPMS) is a set of tools truly enables the following key strategic objectives

  • Business – IT alignment
  • Time to market (Agile software development)
  • Adaptability
  • Process Efficiency – Foundation for Six Sigma
  • and lot more

If BPMS is in the technology road map and the organization is following the road map to move towards the vision, BPMS must be articulated to the executive management teams both in IT and business. The executive management teams may ask high level questions to understand how the BPMS fit in the organization landscape and how it will assist the organization to move towards the vision. When you deal with executive management team before you make them understand some concepts, ensure you erase the misconception they might already have. What BPMS can not do?

BPMS is going to replace all ERP like SAP, PeopleSoft?

BPMS will not replace the existing ERPs, portfolio systems. BPMS will stay top of it and orchestrate any new system development involving all key enterprise systems like ERP, portfolio

BPMS can be used for technology migration projects? Example, From database version 1 to version 2?

BPMS purpose is not to use technology migration project. First of all, BPMS can not add any value in the technology migration projects.

Few frequently asked question by the executive management team related to BPMS direction are listed below.

When to use it?

Use for a new system development if – the business processes changes frequently and they are core business processes, services provided by the new system can be used across different products, the requirements of the systems are relatively vague and would change frequently, involves multiple teams to complete the life cycle of the system function.

How to use it?

From get go, approach the BPMS will be used by both business and IT teams. Get the business teams involved from the beginning, engage them in the initial market research, selection & evaluation and financial commitments in procuring, establishing the foundation like infrastructure, competency centers. Bottom line, it should not be perceived as IT tool. It is a tool used by both business and IT team. How to use it? Capture all the business process flow, analyze the business processes, implement and manage it. All done in the same tool.

How the teams from IT and business work together? (particularly how the IT architects and business process designer work together)

The tool, methodology and approach brings both the IT and business teams (IT – Business alignment, partnership) together by design. The business team will be using the tool to document the business processes (for any project requirement), business analyst/consultants from both IT & business will analyze the business requirements using the tool (like simulation, identification of bottle necks etc), IT architects will build the connectors (to the ERP, Portfolio, enterprise database ware house), IT architects/consultants will auto build (code generation) the application using the tool, business analyst will using the same tool to perform business activity monitoring (let us say, the requirement is to build the credit decision engine and BAM will used to monitor the approval rate by state, product, type of loans etc)

What are the core competencies the IT organization must have to move in this direction?

Business consulting to business, innovation, business process management, business process modeling, business architecture, enterprise architecture, strategy, IT finance management, SLA management, vendor management, etc

How the development partners (like out sourcing partners) play a role in this setup?

Like any software system, the quality of the software systems are not guaranteed until verified/tested. Out sourcing partners can a play major role in verification (testing) of the newly build software system. They can play a role in building the connectors in BPMS. They can play a major role in maintaining the enterprise systems like SAP, PeopleSoft, CRM, etc They can play a role in assisting in capturing the business processes in the tool (the percentage should be very low in this category)

How different architects work together to define software system architecture?

The involvement of various architects in the system architecture definition process is given in the responsibility assignment matrix (RAM) in the table 1. All the architects work together to define the software system architect.

Table 1. RAM for architects.

Architect IV FV CV Dev.V DV OV

Table 2

Code Description Comments
A Accountable Responsible for success/failure of this activity
P Participant Actively participates in the activity
NA Not applicable This person is not applicable for this task.
I Input Provider Project Team needs input from this person in this activity
S Sign-off Required Must sign-off the appropriate document
C Co-ordination Co-ordinates and Leads the effort.

Table 3

SA System Architect
AA Application Architect
DA Data Architect
IA Information Architect
INA Integration Architect
SECA Security Architect
PA Process Architect
NA Network Architect
SEA Server Architect
WRA Web Runtime Architect

Table 4

IV Information Viewpoint
FV Functional Viewpoint
CV Concurrency Viewpoint
Dev.V Development Viewpoint
DV Deployment Viewpoint
OV Operational Viewpoint

Genchi Genbutsu for Enterprise Architects & Strategists

There are at least two school of thoughts for enterprise architecture.

  • Law maker approach
  • Do what makes sense and do the right thing approach

Law maker approach

I had witnessed the first approach in the past. I was not playing an enterprise architect manager nor enterprise architect role at that time. Watched from the side line and it is better to learn the mistakes from others. The law maker approach is to come up with all the standards, road maps, patterns,etc and it is up to the civilian (rest of the organization) to abide to the law. If the civilian did not follow the law, then civilian violated the law and if civilian assess the law is inappropriate then an appeal can be made to the enterprise architects and they reevaluate the standards or patterns. I do not believe in this approach. This will create the EA as the special group or ivory tower team makes decision but never will have clear picture on implementation and lack details on the value generated to the organization.
Do what makes sense and do the right thing approach

I love this approach. Not just for IT strategy nor EA. I love this approach for any role. For the Enterprise Architects, this approach is the apt approach to fetch value to the organization.

Factual Data —> Analysis + Intuition = Solution

The above concept applies to any management consultant. Boutique management consultant firms (like Boston Consulting Group, BCG) when they get engaged with a client, they work on very interesting problems like “why WALL-E (a movie recently released by Walt Disney) did not exceed the expectations?” and for this kind of consultation, they need factual data, quantitative analysis and apply intuition to derive the solution.

Enterprise Architects are the management consultants with stronger technical knowledge. To add value to the organization EA need to get the factual data, quantitative analysis, intuition and come up with road maps, IT investment management framework, patterns, compliance, etc.

To get the factual data EA needs to understand the end to end business life cycle. For example, if an organization is financial service organization, then EAs need to personally visit contact centers, customer services centers, business centers, dealership, zone offices etc. If possible, at least for a day, they need to play the appropriate roles in each centers. (Like be a credit analyst, customer service agent, call center agent, collection agent, repossessing agent etc) Get a loan or lease product from the same financial service company and be a real customer and use the web sites as the customer. Experience gained during this visits, role plays, interviews and etc provides EA (and IT strategist) an edge to come up with realistic strategic plan for the organization which will have a direct positive impact to the bottom line of the core business.

BPMS Tool – Who should use it?

Business Process Management Suite tool is not an IT tool. It is a tool must be used by both business and IT. It is a platform to bring both IT and business together. IT – Business alignment has been a topic for a while in the enterprise and IT strategy related discussion for a while. The true IT business alignment in the grass root level can be accomplished by selecting and implementing the BPMS tool in an organization.

Like innovation, agility is an another strategic imperatives being used by many successful organization. To accommodate the rapid change in the market, the agility within the IT organization in terms of technology, process, systems and etc are must have. It is not a good/best practice it is must have requirement in this dynamic market.

Who are the real users of the tool?

When the tool is viewed as an IT tool, then it is the starting point to defeat the whole purpose of the tool. BPMS is not an IT tool. It is an enterprise too which should be used by both IT and business. Generally, the business process management of the organization is maintained by non IT organization. Some of the organization has a centralized organization responsible for the business process management. They facilitate the business process for any new project requirement and also maintain the process house of the organization. It is a centralized business team to perform this function.

To summarize, the BPMS is not an IT tool and should be used by the following teams to make the BPMS implementation successful.

  • BPM team (a centralized business facilitation team responsible to map a business for new requirement and maintain the process house of the organization)
  • Business teams (cross functional)
  • IT application architecture team
  • IT enterprise architecture team
  • Business analyst
  • Executive Business analyst (who work for CEO or COO and provide the necessary business information working with the functional areas)
  • Application development partners (right sourcing)
  • Developers