The basic foundation for BPM to scale starts with; a) organization adoption of the BPM approach, that process is a center to the transformation and operational paradigm as well as process is an asset, b) building leverageable assets, specifically encapsulating those assets in technology in a platform that is agile to implementation, ie. can be implemented across organizational activities not just one (essence of 'scale'), meet end users needs when humans are involved (vs. system to system)and can be changed in short order (with little time/effort) as the business changes (the real essence meeting 'scale')..........and from that there is a host of other components that are important for BPM to scale
A good implementation. Success breeds success, garners advocacy, attracts interest, gathers and promotes interest.
Do it right coming out of the gate and they will come. Do it wrong and it gets badmouthed for the duration.
Peter, your question includes the answer: a BPM initiative is scalable if the initial efforts are successful. The new needs friends and success has the ability of making friends really quickly.
Apart from that, we could get into technicalities like having a comprehensive data model, a SoA approach, a taxonomy of processes and a stick-to-the-BPMN-standard attitude.
I suggest that defining "success" of a BPM project as a "key to scaleability" is almost a tautology, based on an assumption of basic BPM competency.
How can one step outside the loop?
If one wants to scale "BPM as the way of building new software-based tools in support of organizational work", then one is in the "manufacturing business processes business".
I first encountered this perspective when working with life and annuity insurance companies. A large insurance vendor might have an insurance product portfolio of between 1,000 and 2,000 products, a portfolio which is continually refreshed and updated. And there is a steady stream of new products, and sometimes older products are retired. And the self-description of the executives responsible for this portfolio was "we are in the insurance product manufacturing business". This was in a RAD tools context; I believe the same manufacturing perspective can apply to business process solutions and BPM with BRM.
Therefore, on this perspective, organizational support for the construction, support and operation of a "process manufacturing business" is key to scaling BPM . The implications are the implications for any business: Board-level support, senior executive leadership, professional cadres of process specialists, sales people, and willing buyers -- and the BPM technology with which we started.
I've used the example of insurance products, which is a business output. On the input side, the history of the adoption of accounting knowledge and practices provides interesting lessons for the adoption of any technology.
It's beyond COEs. It's a whole 'nuther world.
Start small, fail fast and learn quickly. You need to build momentum by a stream of successes. Don't be afraid to fail, but learn form your failures and adapt your (tools methods and approach accordingly). The secret is don't try this with huge mission critical processes why, there's just too much to learn, how to use the tools, techniques, get the business to own the change, adopting agile ways of working. Once you have learned the basics then you can look at building a COE, Governance Architecture, process frameworks and libraries etc.
Some structure, and strategic sponsorship is necessary at the begriming. However, no matter how much training, approach papers or strategy documents that you have written, the only way to scale up quickly is through project success. Learn quickly what works best for you. You don't need to know BPMN front to back to start a project what are the vital few symbols your team need to know.
How is your governance going to work? sooner or later you'll recognize the need for business architecture as well as technology architecture governance, just learning how these structures will work with your in flight projects is an art in itself.
Don't try this all at once! Each project should try to build in a new technique, while embracing the learning from the past, but think small. I think a COE is vital, for sharing knowledge, standardization of tools, templates, training and approach. Establish the COE once you have two or three success and a pipeline of opportunities.
Hi All !
In my perception, the most important keys for scaling a successful BPM project out to the rest of the organization are:
1- Having a very involved role at high level leadership (CIO, VP) who embraces the causes of BPM/Business Excellence, Innovation and cooperation (powerful Sponsorship).
2- Building or molding a common organizational culture focused on Operation Excellence, Innovation and Cooperation;
3- Create or maintain an skilled and engaged "Center of Excellence" (or Business Process Office) and if possible, which also includes more roles than BPM specialist.... also capacitate and include representatives from IT, HR and Operation and Finance to facilitate the vision and impacts in these universes who will be vital for the success and also will work as facilitators to obtain commitment from these areas.
4- Acquire or create a powerful framework for BPM Projects and maintain it under central governance to ensure the execution of any projects according to this framework.
5- Acquire and maintain a good BPMS that best fit to organization needs and future required scalability.
Agree with the comments that suggest that you should be sure your first project is a winner. The implication of that response is that BPM best scales by building on a series of successes, which in turn implies that BPM is meant to grow from the bottom up, rather than the top down. Imagine saying that about a CRM or ERP system: the very idea is nonsensical. Yes, as you scale, you will begin dealing with issues of architecture, taxonomy, etc. But as you wrestle with those questions, you will already have deployed the technology tactically to improve your business. BPM is the sword that severs the Gordian Knot of analysis paralysis.
I deliberately ignore all the standard project / program management critical success factors and will mentioned only BPM-related ones.
A short answer: If you want to scale out your BPM project to the rest of the organisation then it must be architectured that BPM is a core pillar for digital transformation of your organisation.
A long answer: Some (not all of the them) critical success factors are:
1. Vendor-independent understanding of BPM discipline, products, practices and architecture.
2. Understanding how BPM helps to achieve organisational goals.
3. Objective evaluation of the nature of your business processes.
4. Communicating the context for the selection of BPM-suite.
5. Explicit justification of required BPM-suite capabilities.
6. Efficient selection funnel.
7. Availability of practical examples to be implemented as POCs during the selection.
8. Selected BPM-suite operationalisation (including organisational impact analysis and related actions).