I skipped out on the breakout sessions this afternoon, but am back here for Michael Melenovsky — formerly with Gartner, now senior BPM leader at Satyam — discussing how to accelerate BPM adoption through an integrated business framework: more of a methodology framework than a code framework, however.
He listed the three ways in which BPM projects are initiated, and how that influences the approach to be taken:
- Executive leadership, where an executive goes to seminar or reads an article on BPM, and says “hey, let’s get us some of that”. The objective is strategic alignment and increasing corporate performance; because it’s very top-down, it’s only possible to push down the ideas so far, and often they’re not implemented.
- Middle management, with the goal of operational improvement and cross-departmental coordination, with the BPMS seen as a tool for modeling processes and standardizing work procedures.The key challenge here is getting buy-in from both the top and bottom.
- Line of business management, with the objective of improving productivity, decreasing costs, increasing quality, and providing greater agility. The BPMS is seen as a development platform, and 80% of these projects are driven by the IT department. There is no comprehensive vision, and implementation can take a long time.
He points out that the process layer makes explicit the role that people and systems play at each step of the process. Instead of a world where the IT organization must interpret the process, there is little visibility beyond a department’s boundaries, and it takes a long time and technical resources to change a process, the addition of a process layer makes the process model explicit and allows the model to drive the process execution, with process changes made by non-technical people.
There are three different perceptions of BPM, between business people, IT people and process people in terms of what creates the competitive differentiation and the best way to approach BPM. Each of these has a bias, and it turns out that the process people are the best ones to own a process, not the business people as is commonly assumed. The process people can form a bridge between IT and business, and keep the focus on the process rather than either the people or the systems involved in those processes.
He presented some sample requirements that might be included in a BPM project:
- Business analysts and IT can collaborate around a single executable process model
- Business can simulate the performance of the process for optimization purposes
- Real-time monitoring and analytics
- Task analytics guide human resources in task prioritization
- Automated human workflow with simple to use task routing
- Search capabilities for operations to review standard work procedures
- Task user interfaces that are built quickly using an integrated composite application framework
- Business rules and policy management for non-technical users to manage and modify
BPM provides value to both business and IT: we usually focus on the business benefits, but IT benefits through reduced solution development time, a more comprehensive architecture (usually in conjunction with SOA initiatives), reduced application maintenance costs, and shifting attention to higher-value topics instead of always being down in the code trenches.
He listed six critical success factors for BPM:
- strategic alignment
- culture and leadership
- people
- governance
- methods
- information technology
These aren’t specific to BPM, of course: any project with a significant technology component will rely on the same factors.
He showed a pyramid with a strategy layer at the top, followed by processes, applications, transactional systems, and tools; most companies are missing the process layer, hence try to go directly from strategy to applications, with high-level business executives stating that they need a specific solution, rather than stating their requirements in terms of a business process.
He walked through the participants in a cross-functional BPM project team, and finished up with getting started with BPM:
- identify key stakeholders
- define BPM in the context of benefits
- determine the phases of value that BPM will deliver
- develop a 3-year BPM roadmap
Satyam, of course, offers strategy and solution frameworks for BPM projects.