Your BPM project is ready to "Go-Live" and you are excited about finally reaching this point. You are thinking about your creation and all the countless hours spent discussing requirements, revisiting and changing them, creating robust processes, designing and executing flawless architecture, and following best practices while writing code. But no creation can sustain for long without a plan for maintenance. No matter how bulletproof the code is and how many testing iterations you have gone through, there will be changes requested or defects discovered in production.
In an earlier blog post, I outlined the four areas of a BPM COE: Governance, Resourcing, Execution, and Reporting and Metrics. In this particular post, I'm going to provide some additional details on the Governance aspect of the COE. As I mentioned in the earlier post, Governance can be one of the most difficult components of the COE to build due to the large number of constituents and high level within the organization that needs to be involved. In organizations where o
Since most of the people at Avio seem to have some sort of flu or cold virus right now, it made sense to me to talk about how successful BPM engagements tend to lead to the viral adoption of BPM with an organization. Most organizations tend to start with small, tactical implementations in order to get their feet wet and see how BPM fits within their IT and LOB functions. If done properly, initial deployments tend to happen quickly and drive significant results. As a result, the rest of the organization tends to take notice and the collective light bulb goes turn on.
One of the key steps in purchasing a BPMS is often to conduct some level of POC to ensure the BPMS matches the organizational needs. In order to obtain the maximum amount of value from the POC effort, there is a significant amount of preparation and planning which should happen before the POC begins. When planning for the POC, there are three main focus areas which must be defined.
1. Scope
Process beginning and ending
Integration to underlying systems
When most organizations start down the BPM road, it is often done with grand and lofty expectations. BPM projects, especially the initial endeavors, often are expected to be completed very quickly, with limited IT involvement, and deliver significant ROI in a short period of time. Vendors historically haven't done themselves many favors and have fueled their customer's perceptions that the LOBs can implement, change, and integrate their processes without having to significantly, if at all, involve IT resources.