Every organization that embarks on the BPM journey, goes through the classic BPM Cycle: Model-Automate-Monitor- Analyze-Improve. BPM platforms have evolved over last decade to thoroughly support this cycle and have achieved significant maturity to support enterprise class process solutions. Even though BPM Consulting companies have put in place robust implementation methodologies to ensure successful BPM deliveries, one still hears of projects gone terribly wrong: getting delayed, going over budget, not delivering the expected business value, eventually leading to significant pain for all stake holders.
Why a BPM Project fails can be an elaborate area of research. Reasons can be attributed to technology, the nature of business, Change Management, Expectation management, execution, skillset etc. I’ve put together a list of BPM Commandments that I think can significantly reduce the risk of failures and setbacks especially from a BPM Technology perspective.
9 BPM Commandments to Reduce Risk and Failure
Never Hurry When Discovering Business Processes and Rule
There can be no shortcuts to discovering the business process and the underlying rules. With distributed organizations, getting everyone together for process and rule discovery sounds like the biggest challenge. However, leverage the collaborative Process Modeling features provided by BPM tools (E.g. IBM Blueworks Live) to mitigate this challenge. But never put a shortcut to process discovery and leave it for later. It would possibly cost 10x more time/effort/cost if left open at the discovery stage.
Do not overcrowd your process. Try avoiding to mesh up two or more workflows into one. Create sub-flow.Sub-processes can be run either synchronously (finishing before the parent process does) or asynchronously (completing at any time).
- Asynchronous Sub-Processes: When an asynchronous sub-process is started, the parent process flow does not wait for the child process to complete. The flow continues without pausing. Asynchronous sub-processes do not allow activity-chaining into a child process from the parent process.
- Synchronous Sub-Processes: When a synchronous sub-process is started, the parent process flow waits for the child process to complete before continuing the flow. Synchronous sub-processes do allow activity-chaining into a child process from the parent process.
Design for Change
Business Processes and user requirements tend to change with time. Your design must follow an agile approach to accommodate changes to processes and requirements. Changes may range from momentary (ad-hoc) modifications of the process for a single customer to a complete restructuring for the workflow process to improve efficiency. Make your design modular and flexible so that changes could be executed and tested efficiently.
Build out of the box
Customization must be your last resort. Use out-of- the box features of the BPM platform as much as possible. At times, this calls for putting additional effort to lean that new feature that was just introduced in the latest version. Or, this could call for implementing a certain business requirement in a slightly different way that the business users are used to. Convince them about the newer / out-of-the-box way. But avoid custom coding at any cost.
Be descriptive in your actions
Learn to put optimum level of documentation of everything that you do. E.g. Annotations in process models, code comments, descriptions of decision models, etc. You are not the only one to work on the component that you just built. It is not advisable to overdo documentation by creating 100s of pages of documents. The best approach is to use “in-line” documentation using the out of the box documentations features provided by Process Modelers and BPM Design studios.
It is often seen that a lot of time is lost while handing-off the solutions across teams or even across two individuals within the same team. Simple documentation helps address this gap.
Confront Issues right at the beginning
Every project has issues. Always be truthful in raising the issues that you face in your project upfront. Do not wait until the Testing Teams or User Teams report issues, even it means you need to fix the issue and take a build or two more. The issues that you are trying to hide can hamper your performance at workplace.
It is a common practice with BPM Developers to work on Reporting requirements towards the end of the release cycle. This makes sense as it is easier to build and test Reports after the process is built. However, Reports, especially the complex ones can throw some really nasty surprizes. While you can plan to build Reports towards the end, ensure that you have designed for it thoroughly. Reporting requirements must be analyzed and designed right upfront. Ensure your process design is designed to produce the required reports.
Maintain holy Audit Trail
Ensure that all the user action and system actions appears in the audit trail. Try maintaining a clean and holy trail. In the case of a secure data management system like SecureDocs, audit logs are used to track the date, time and activity of each user, including the pages that have been viewed.
The benefits of having a detailed audit log include:
- Increased Security: Having detailed audit logs can protect a business from liability during legal battles. They also help companies monitor data for any potential security breaches or internal misuses of information.
- Risk Management: Audit logs can play an important part in a business’ overall risk management strategy, demonstrating to customers, business partners and regulators that an organization has made a thorough effort to protect against and prevent potential problems before they occur.
- Demonstrate Compliance: Organizations must comply with statutory compliance such as Sarbanes-Oxley act and the Gramm-Leach-Bliley Act, in addition to industry-specific regulations. Audit logs can be used as proof of regulatory compliance during an audit and can help a company fulfill its record-keeping requirements for compliance purposes.
Plan for Errors
You must allow human errors in built-in solutions. Allow users or the administrators to terminate the instances as a part of the process instead of rolling back. Plan well for the errors that you face in your project.
We at Princeton Blue, always strive to do better for our clients. Every project is a learning experience and we like to share our learnings within the company and with the BPM community. What has been your BPM Journey like? What are the learnings that you have from your successes and failures? Feel free to share your ideas at email@example.com