BPM Methodology – ABBER

Author: Sandeep Mehta

Purpose of this Article

This article will explain a newer approach to implementing a Business Process Management (BPM) solution, invented as an SDLC, by the author of this white paper. Which SDLC (Software Development Lifecycle) is the most suitable for effective implementation of a BPM solution?  How a BPM solution implemented with the right methodology can generate higher ROI (Return on Investment)?
The normal waterfall approach and agile methodology do not directly suit implementing a cutting edge BPM solution.  It demands a much more tailored SDLC. It is very important to understand, why BPM has a need to follow a separate SDLC. Let’s first understand why we term BPM as a separate discipline in the IT world.

Why BPM?

BPM was there when there was no Information Technology.  BPM is a discipline which has evolved over many years.  It presents a way to define business processes, manage them, sustain and improve them.  It is similar to managing the business – how one can grow the business and run it efficiently.  BPM is the core foundation of what we do in today’s Business world.  IT is just an enabler and empowers it to a greater efficiency.
If one can define the Business Processes correctly and enable them, you can rest assured you will achieve high growth and revenues from your business.  In today’s fast paced business environment, there is a strong need to be agile; to be ready to implement changes with rapid speed and high accuracy.  This means your IT systems should be highly flexible, platform independent, scalable and very easy to maintain. This is what a well built BPM system can bring to the table.  One can easily translate BPM to benefits, faster than any other kind of IT deployment.
BPM systems should be the core of a business strategy.  There is no doubt that, BPM will be the way of the future. Business would love to have the power of making changes to the way they do their business at their finger tips.  Rather than going through the long process of SDLCs, deployments, and releases, proposed BPM SDLC can provide rapid and efficient deployment.  It can enable small changes on the fly without ITs heavy involvement.

What is missing in normal SDLCs for BPM?

When we think about SDLCs, “Waterfall”, “SCRUM”, “Prototype” comes to mind.  BPM is a bit different in that, all the methodologies suggested above focus on how to do something?  BPM methodology will focus on what to do?
All the standard methodologies are IT centric.  BPM methodology should be more Business centric.  For successful implementation, Business Processes should drive the IT processes.  This can only happen, if the IT team is mature and understands the rules of the game.  The game here is only one – “Business Process”. The key is to provide innovation to Business with a sound IT knowledge and passion for improvement.  With these goals in mind, the author of this white paper has invented, a customized SDLC called, ABBER

Suggested BPM Methodology – ABBER

The author through his extensive experience in Business and IT world suggests a methodology, which is Agile and Business centric.  It consists of 5 phases namely,

  • Analyze
  • Blue Printing
  • Build
  • Empower Business Users
  • Roll out

(ABBER). The author will henceforth abbreviate this SDLC as ABBER.  The following picture shows the cycle for the Phases and Activities for each phase of ABBER.

To use the ABBER process effectively, it has been kept simple, easy to understand and adopt. The numbers of phases are limited to five (5). The methodology suggests that, there is no initiation. One has to understand that, the business is ongoing. The business knowledge and pain points, or improvement opportunities are existing, no matter how advanced you are. Hence there is no need for initiation phase.
Similarly, there is no project closure. It is a continuous business improvement. The end of the rollout phase spawns another business improvement cycle. The continuous cycle makes it sure in that, the business knowledge is retained with lesser resources to support, maintain and enhance. This methodology will translate to growing market knowledge, experience, capabilities and ultimately higher market share with go to market strategy. Remember this SDLC has been designed from the point of making you the market leader through IT-BPM.
Below each phase is explained in brief with key activities under.

Analyze

The first phase starts with analyzing a business need to resolve the pain points or develop an innovative idea to create high end product or service.  Business need is identified at high level. A deeper dive is done as follows:

Problem Statement

A problem statement should be documented well enough to identify the business need, request objectives, impacts and risk of doing versus not implementing the request.  It should also justify all the benefits it will bring to the organization, when the request is fulfilled.

Current System Capabilities

The person documenting the problem statement should be very well versed about the existing system and its capabilities.  This specialist should have a deep understanding of how the business is running the show for the required functionality.  It is quite possible that, he/she may not be sure about what they would exactly like to see in the new system, however they should be very well aware of the problem at hand i.e. What the current system can support versus what it is lacking and what is expected?

“Wants” versus “Nice to Haves”

As described, ABBER is an incremental methodology; hence today’s “Nice to Have” will become “Wants” tomorrow for sure. You should prioritize today’s problem first and if you finish dealing with it, only then focus on “Nice to haves”.  Nice to haves are not important until you cater to the “Must haves”. Once you are done with “Must haves”, not doing “Nice to haves” should not be an option.  If you can cater for “Nice to haves” today, you are servicing the “Must haves” of tomorrow.  This is the way to succeed in business.  Best Example: Apple, Inc.
The BPM system will support you as long as you know what you want. Write down each of your requirements.  Go through the list and categorize, what are your immediate needs.  These needs become Priority 1.  The “Nice to Have” features can be addressed in the next incremental cycle.  Once current “Wants” will be satisfied, the next batch of your “Nice to Have” should become “Wants”. Remember, you are now in the continuous improvement cycle; here innovation is MUST and not a choice!

Blue Printing

Gaps – Identify Improvement Areas

Start with gathering the “AS-IS” data. Once you gather the details on the “AS-IS” process work flow, don’t try to target your end goals immediately. Thee next task is to identify, the “Gaps” in the “AS-IS” process.  List down the gaps and think about, where you can improve this process.  This well provide you insight into the improvement areas.

Business Process Design – To Be Workflow

Once you know, the gaps, organize multiple brain storming sessions with the business users, current and future stakeholders to come up with solution framework à “To Be Workflow”. “To Be Workflow” will become the CORE document for your implementation.  “To Be Workflow” details should generate both Business Rules and Document.
These documents should be used by the IT Project manager, Business Analyst, System Engineer, Developers, Testers and Client throughout the project.  The “To Be Workflow” will drive the project scope.

Identify Business Process Modules – Don’t worry about details

From the, “To Be Workflow”, come up with high level solution design.  Determine what modules will be needed and what will be the functionality of each module / use case.  This will be your high level component model.  Each component is nothing but, a high level object.  The components can be clubbed within a group.  Each group can be combined within a set of libraries.  Remember, ABBER does not warrant detail design.  You can always schedule the detail design discussions during the Build phase, but this methodology asks you not to think about minute details during the Blue Printing phase.

Estimation & Approval

You can arrive at the estimate for budget and schedule at this stage, which should be accurate at least to a 75% confidence level to proceed with the request.  The estimation should be based on the numbers and complexities of the following:

  • Backbone
  • Modules
  • Workflows
  • User interfaces, and
  •  Reports

Note: Modules are independent of the workflows, so do not confuse them as the same.  User Interface is separate from the workflow, though these are closely tied.
Backbone deals with the Hardware, OS, Application Software, Database Specification & Design and all the middle layers.
Once all high level components are designed, you can accurately budget the project cost.  Keep in mind to reuse the existing framework and libraries.  Determine the amount of customization, which will be required to meet the new requirements.
At the end of this phase, business requirements and system requirements should be well documented with proper traceability without worrying about the technology selection.  Even though backbone indicates various technical aspects, do not worry about finalizing them.  Keep your mind open to various technology options.  Alternatively, you can use the selection as, your options in the decision making process.  However, your overall decision making for the project should not depend upon the technology selection.  Remember, Technology is an enabler! Don’t get trapped into the politics of technology selection.  Technology will support the system, as long as you do honest evaluation.
Prepare project scope with well documented assumptions and constraints. The risks should be defined at this point for not attempting the initiative.
ABBER is designed to be a light weight methodology, so process overkill should be avoided.  All budgetary approvals should be submitted in one attempt, keeping in mind that, even small measures are capable of improving the business considerably.  Do not try to be 100% perfect.

Technology & Approach

Now deal with technology. Once the business modules are documented, determine what technology, you’ll use – Whether you will use pure play BPM suite or will develop a custom application or implementation by a COTS package.  Select the technology at this point keeping in mind the following factors –

  • Simplicity
  • Reuse
  • Ease of maintenance
  • Quicker implementation
  • Scalability
  • Robustness

Technology selection should not be your project.  Follow any scientific method.  Analyze, which technology suits your current and future needs without going overboard.

Business Rules & User Interface

Business Rules should be configurable by the business team.  Refine your Business Rules at this stage and carry out all the checks and balances.
Develop a user interface for achieving the prime BPM application feature.  At system level, the Business rules could be configured in various ways e.g. property files, database.  This depends upon the number and the nature of the business rules.

Build

I’ll not discuss the build phase in detail, as that is not the focus here.  In today’s world, we understand the Build phase very easily.  However, the following approaches should be considered during the build phase –

    • Create quick and dirty detail design.  Evolve with much more refined design while performing the actual development.
    • Use readily available framework, if it suits your need.  Do not reinvent the wheel.
    • Create generic customizable libraries.  Think about future usability and principle of reuse.
    • Create APIs to support Service Oriented Architecture (SOA)
    • Build generic and scalable Business Rule Engines

Empower

Train Business Users, Make them your partners

Believe me; it pays to train your business users.  Don’t think that, it’s a pain.  They will gel with your demands for execution, support and maintenance of the system.  The more knowledgeable they are, the more they will understand your pain points and be helpful. Training the business users helps the project execution in variety of ways –

  • Support on making changes to the business requirements without extra process overhead
  • Proactive training will reduce errors and questions on application usage
  • Understands the significance of the cost and timeline of delivery
  • Less change requests, since they try to think 360 degree about their own requirements
  • Better User Acceptance Testing and speedy defect resolution
  • More satisfaction, since they do not get frustrated

Note: Communication is the key!

Let them configure the business rules. Less dependency on the maintenance team

Another advantage of training the end users is that, they will not be fully dependent on IT to make changes to business rules, which are configurable through a well thought out user interface.  This reduces a significant part of the overhead on IT and brings out overall efficiency for day to day jobs.  This is what an excellent BPM system should deliver.
Do not get scared that, this will reduce IT work and will result in less dependency on IT.  IT is replaceable.  In fact, this is extremely advantageous, as it will provide IT enough time to initiate the next improvement cycle. IT can deal with its priorities better.  This system will help cut down the red tape.  When business users are making changes to the business rules (adding/modifying/deleting), they are directly accountable.  This will reduce the risk of errors happening due to miscommunication.
Empowering business will be a collaborative solution.  It will be a win-win situation for everyone and the organization will rise from within.

Roll out

Less overheads, Shared Responsibilities

It is very uncommon for the non-BPM projects to involve Business in the roll out process for validation, transaction processing etc.  For a BPM project, it is in fact opposite.  IT gets more involved on the business side during the roll out and Business understands the system well in advance.  In fact, if this method is executed perfectly, there will be no need for separate training by IT for the business groups.
The responsibilities are to be shared during the roll out and for a month after the roll out to ensure the system is stable.  Business will play an active role during the roll out, rather than delivering the system on a golden plate.  They will get their hands dirty and will appreciate that, no lunch is free and just by sponsoring the project they will not get a ready made perfect solution.
Once the stable state is achieved, business will be more independent.  The responsibilities could be shared during the transition period / hand-over process.

Incremental Deployment, Continuous Business Improvements

Now that, the ABBER methodology has been explained in brief, it is the right point to understand what will spawn the next BPM improvement cycle.  This is not dissimilar to the Sprint cycle process.  The IT should not start the next improvement cycle until the core “To Be” workflow has been delivered and it achieves a stable state.  The defects identified after the roll out should be resolved and the temptation to classify them in a separate cycle resisted except where the severity of defect is low.  Before commencing the next cycle, secure an approval from the IT maintenance team, business and other stakeholders for their acceptance of the current cycle.
ABBER methodology supports focusing on the issue and dealing them one by one.  Hence unless Business signs off on the first cycle, never move to the next one.  Once again, remember it should be continuously funded initiative with cost saving and high benefit to cost ratio.  Don’t judge that, if you can’t immediately start the next cycle, you will lose the productivity.  At the same time push the business to provide the sign off in a month or two and engage them in the next cycle.

Summary – Satisfied Client with appreciation for IT effort!

The aim is to have delighted clients. IT should be Business’s friend.  Business needs IT and Business is ready to invest money on enterprise wide initiatives.  Business care about IT as far as, IT is executing the projects for them and solving the business pain points.  If IT systems generate revenue, Business will never view IT as a cost center. They will see IT as a way to do business and make a difference to their end clients.  In ABBER there is no start and end dates for an effort unlike PMBOK’s definition of a project.  Business will work with IT on a continual basis with never ending improvement cycles.  Business clients will work with IT as a team and would learn to appreciate the painstaking IT effort.
Business and IT will be the siblings, who will play together to achieve the end goal of increasing the efficiency, reliability, productivity and safety.  In my next paper, I’ll document, Best Practices and Business Harvest Plan through ABBER.

About the Author

Sandeep Mehta has headed BPM practice for a company called “archents”.  He has vast experience in delivering enterprise level programs / projects, right from gathering the business requirements until deployment, maintenance & support.  He has a deep understanding of the customer pain points, both from IT as well as the Business side. He likes to pen innovative thoughts and ideas which in the future will become trends and practices.

I would like to thank Mr. Kishore Karumanchi ( Chairman  & CEO of archents ) for inspiring me and enabling me to the world of BPM.

Sandeep Mehta

ABBREVIATIONS:

ABBER – Analyze, Blue-Printing, Build, Empower & Roll Out
BPM – Business Process Management
COTS – Commercial Of The Shelf
IT – Information Technology
ROI – Return On Investment
SDLC – Software Development Life Cycle
SOA – Service Oriented Architecture

Copyright Project Perfect