Projects to Programs – An Introduction and Initial View
One of the big challenges facing large companies today in the area of Smarter Process is to figure out how to fully capitalize on the BPM opportunity. Through encouragement and guidance, initial BPM projects are delivered to gain experience and skills in applying BPM. These are often contained within a single part of an organization. They cover one or a few key business processes. Through my travels and visits with customers as well as trying to keep up with papers and articles that touch this space, my views continue to evolve. I’m sharing a snapshot here for others to read and reflect upon.
Irrespective of how wildly successful initial projects are found to be, business stakeholders, most of whom are always on the lookout for opportunities to improve the bottom line, often find these early BPM projects. The business value delivered in these limited scope projects becomes the basis for proposals for enterprise wide adoption of BPM and what is often called a BPM Program. The project to program transition is the then next big challenge.
There is not a specific formula or approach that is guaranteed to work for those moving from initial BPM projects to an enterprise-wide BPM program. However, there are a few key things to consider and a few techniques that can help reduce risk and increase chances for success.
Linking BPM to the Business
The first part of setting up for a BPM program is to assess the readiness of an organization to deploy a full BPM program. While there are a number of ways to do this assessment, I prefer to engage with the owners, practitioners and stakeholders that are experienced with the initial set of projects, most of whom will be part of rolling out a full-scale program. In addition to those experienced with the early projects, additional stakeholders and participants that will play a key role should be engaged.
The business stakeholders need to be interviewed. While technical readiness is also important, I find it valuable to engage with the business stakeholders directly and in conjunction with those in the IT function that are responsible for that linkage.
The business stakeholders are the ones that will relate a business goal and vision. They will have a strong role in inventorying and deciding which processes should be automated. Getting agreement on high level objectives and concrete measurements that reflect progress against those objectives is essentially to rolling out a successful BPM program. These business stakeholders will be funding the BPM program, so they have to be on board and excited about the opportunity. In most cases I see, they need to initiate the movement from project to program, or at least be co-sponsoring the movement with the forward thinking IT folks that see the value proposition.
The redpaper at http://www.redbooks.ibm.com/abstracts/redp4898.html?Open has a strategy chapter in the beginning that further defines and outlines how to get the needed business sponsorship and to get the business objectives in place that can be used to measure progress.
The other people an organization has that can fill the various roles to be played in rolling out a BPM program must be also inventoried. Additional outside skills might need to be brought in to supplement an existing organization’s capacity. Outside skills should be used to deliver projects but also to mentor and train in house capacity. If an organization is implementing key processes that support their most important value chains, then to me, this seems like work that should be done with in house skills. Remember, these are not projects that are over in a few months. True BPM means continuous process improvement. Funded projects that terminate upon first delivery just don’t match the model.
With the business stakeholders on board and a view on skills and the organizational capacity at hand, it is then time to turn to the more technical elements and assess the assets and challenges in these areas.
Technical Infrastructure and Topology
The technical infrastructure required to support a BPM program will go well beyond that of supporting a few initial projects. First, a real platform goes beyond BPM, moving towards what I call a ‘Smarter Process Platform’. This platform includes not only IBM BPM, but also IBM BlueWork Live, IBM Business Monitor and IBM Operational Decision Manager for starters. Rolling out a BPM program without these key elements is possible, but this is the recommended breadth of capability to give due consideration.
The scale out model for the technical infrastructure also becomes bigger when thinking about rolling out a program. This means for example, rolling out multiple IBM BPM cells and having infrastructure to scale to more concurrent users, a large numbers of groups and lots of active process instances and human tasks at any one time. This also means looking at things like multiple Process Centers and Decision Centers. While the cloud and virtualization offer great accelerators when it comes to getting the infrastructure rolled out, the basic layout and capacity requirements are something to understand right away and plan for. Knowing a ‘Smarter Process’ program is going to be rolled out will cause different infrastructure decisions to be made than those that were in place to support a few initial projects.
Operations and Procedures
Operational procedures for managing and monitoring this platform also need to be planned for and accommodated in the overall approach. This is often something that is overlooked or underspecified in early projects. It is often possible to get by with less here for initial projects. Scaling out in this area, however, demands that the manual steps of before be automated and the reactive approaches to problem solving become proactive and documented.
How the platform is leveraged by the program participants must be considered next. I talk about this as application design or sometimes use the term “fit for purpose”. Processes that will evolve based on continuous process improvement from human dominated processes to processes that have a strong straight-through element must leverage many of the valuable features found in IBM BPM. Evolving processes can also mean having separately defined enterprise class decisions using IBM ODM. Features from other products available in the enterprise such as integration and analytics need to be blended in with the combination of capabilities from IBM BPM, IBM ODM and IBM Business Monitor.
These technical elements of infrastructure and application design are leveraged in a development process that features iteration, playback and other means of regular and deep interactions between the business and IT stakeholders involved in rolling out the BPM program.
Center of Excellence
Getting all this sewn together into an approach that works for a specific organization that can be managed does not just happen by having done groundwork on business linkages, laying out of the infrastructure, documenting operations and paying attention to application design. Something is needed that helps pull all of this together and provide end to end governance over the BPM program.
In my experience, getting that organizational capacity and continuous process improvement approach rolled out properly requires some sort of center of excellence (COE) or center of competency. My recommendation is that a COE does more than advise. A COE needs to provide participants for key projects that are part of the BPM program. They need to create reusable artifacts, and I mean code artifacts such as BPM Toolkits, that can become accelerators for individual projects and can become a basis for consistently solving many of the various things that come with rolling out a BPM program. Toolkits that have common user interface elements and service interfaces that do backend system integration are two examples of artifacts a COE should create.
The COE also becomes the champion and evangelist for continuous process improvement. They define and administer the approach for governance, iteration and playbacks. They essentially own and keep an eye on the process of continuous process improvement.
To summarize then, the elements to be considered and analyzed when rolling out a program are shown in this graphic.
The importance of a COE to pull together and provide continuity is highlighted once again. The COE needs to be at the heart of any successful program.
Rolling out a Smarter Process program is big task. There are many more details to consider than are laid out in this brief blog entry. Look for future entries to dive deeper into some of these topics.