Business process management/Charter for the bpm engine

Related lessons

	The Charters for BPM Program Governance - An Overview
	Charter for the BPM Engine
	Charter for BPM Democracy
	Charter for Alignment
	Charter for Conflict Resolution
	Charter for BPM Investment
	A Charters Glossary

Executive summary

The engine is the set of people, tools, and methods used to implement a BPM program. A mechanical engine converts potential energy into kinetic energy. Similarly, a BPM engine converts business opportunities into realized solutions. All three engine components are required, and they are interdependent. This Charter examines the roles and responsibilities needed in a BPM program. Starting with the types of people needed for proper governance, this Charter progresses to tooling and then onto methodology requirements.

Presented are the critical requirements for each piece of the engine. A program that satisfies the comprehensive list is more likely to succeed and is said to be more robust than one where the list has gaps. A robust program is able to deliver solutions quickly and efficiently. It can also adjust to future demands in an agile fashion.

One major difference between a BPM program and other types of business enablement programs is in the position and the relationship of BPM programs within organizations. BPM programs are cross-functional and span various business and IT units. The end-users may be involved in a variety of processes being managed. Thus, the BPM engine naturally lends itself to the concept of sharing. Portions of the engine can be fulfilled by common, shared implementations.

Objectives

This Charter

Specifies roles and responsibilities required in an organization,
Defines requirements for the tools to support BPM projects,
Identifies elements of a methodology useful for managing a BPM portfolio, and
Discusses sharing the engine.

Once established, the engine is the execution mechanism by which

Strategic objectives are mapped to discrete projects,
Projects get implemented, and solutions are deployed, and
Remaining opportunities and completed projects are re-evaluated for further action.

Scope

The engine is framed with a basic structure in this Charter. An organization should be able to take this Charter and begin the process of internalizing it. That includes

Assigning specific individuals to the roles and responsibilities, possibly extracting them from existing teams and jobs,
Selecting and acquiring the tools, and
Adopting the methods.

This Charter does not impose a rigid structure upon an organization. Rather, suggestions are made regarding fundamental responsibilities. Specific titles and roles can and should be modified. Individuals may find themselves filling multiple roles at various times in a program's lifetime.

Defining a staged timeline is covered in the Charter for BPM Investment because it is intimately tied to an organization's budget and appetite for implementation.

Also, while the engine includes all people supporting the portfolio, end-users are covered in the Charter for BPM Democracy. This Charter focuses on program teams that are governing, delivering, and supporting the solutions.

Plan

Requirements

Roles and responsibilities

A baseline engine includes two tiers of people. Tier 1 forms the Leadership layer. Their mission is to set the direction of the program and to enable execution by Tier 2. Program direction includes specific constraints or business decisions that need to be observed. These might include specific compliance regulations, resourcing models that include onshore and offshore workers, technical constraints, and more.

Tier 2 forms the Execution layer. Their goal is to implement the program in a manner that produces results for the specified objectives. At the program-level, the Execution layer organizes the solution teams and has oversight of their work. Where possible the Execution layer must work within the constraints imposed by the Leadership layer or propose and justify changes to the boundaries set by the Leadership layer.

The tables below outline the key members of each tier.

Tier	Responsibilities	Representative Groups
1: Leadership Sets the direction and empowers resources	Determine, communicate, and validate program objectives Provide funding and resources Establish a supportive environment, including arranging contributions from related, non-BPM programs Resolve conflicts	Executive Finance Technology Delivery
2: Execution Implements the program and provides results	Select, deliver, and validate projects Recruit and retain people Select and implement tools Define and incorporate methods Escalate conflicts	Business Owners Senior Management Technical Staff Program Management

Tier 1 Role	Responsibilities
Executive Sponsor	Sets direction and strategic objectives Ultimate decision maker for conflicts
Financial Director	Sets funding plan for accomplishing objectives Standardizes the critical success requirements (metrics) for projects Validates alignment with defined targets
Chief Technologist	Defines the technical landscape of software and systems Incorporates new technologies Standardizes designs and patterns for reuse
Portfolio Director	Ensures prioritized selection and successful delivery of BPM solutions Manages the talent required for the portfolio Incorporates new methods

Tier 2 Role	Responsibilities
Business Owners	Ensure alignment between solutions and objectives Enforce the change management policies, including minimum quality criteria
Senior Management	Coordinate functional areas to deliver results
Technical Staff	Design and implement requisite technologies for solutions Design and implement scalable platform infrastructure Tune and optimize solutions for usage profile Support deployed solutions
Program Management	Deliver solutions to specified targets Build roadmaps for solution opportunities that might be delivered in later increments Manage risk and communication plans

Vendor participation within both tiers of the program is also critical. Vendors provide tool and method support for the engine. Their contribution should include

Feedback - Providing feedback to the vendor organization for improvement,
Education - Providing relevant instruction,
Mentoring - Informing teams of best practices, and
Coaching - Assisting in issue avoidance and risk management.

Here is a suggested structure for the tiers. As mentioned earlier, individuals might need to participate within multiple roles and responsibilities, especially during the early stages of a program.

Simplified governance organization.

Methods

The methods determine how the parts of the program operate. The program methodology in most organizations will actually be comprised of methodologies in different areas. The cumulative methodology should address the following requirements.

Method Area	Requirements
Demand Management	Support prioritization of opportunities based on their impact against the strategic objectives of the business. This means picking meaningful projects that provide benefit.
Supply Management	Provide sufficient engine capacity to deliver the selected opportunities. This includes having a ramp-up plan for skilled resources and infrastructure, whether they be centrally or departmentally allocated. These resources can also be sourced externally.
Innovation	Parts of the organization must be able to advance the state-of-the-art, either in their approach or in their tooling. Innovation provides an opportunity for validating options with limited investment.
Delivery Agility	Provide a mechanism for projects to adjust their course to changing objectives. This includes the ability to terminate a project early if it is not able to deliver sufficient benefit to justify the investment.
Change Management	Allow the pace of deployment to be adjusted for an organization's culture. A balance should be determined by certain factors, including Significance of changes, Quality of the releases, Training and deployment costs, and Capacity to incorporate feedback into roadmap.
Continuous Improvement	Allow for incremental delivery of benefit over identified time windows. It must be possible to divide feature sets into groups and to have those groups delivered in staged releases.

Tools

Tools for the engine encompass the software products, technical infrastructure, communications infrastructure, and generally, the things that people use to get their jobs done. The tools should not obstruct or delay the progress that the program can achieve. Do not pick tools with which people must develop workarounds or that make the methods harder to use. Here are some minimum tooling requirements.

Category	Requirement
Applicability	Provides features that allow the methods to be employed. Matches the skillsets and capabilities of the people involved - at all levels. Meets today's requirements and also allows for growth.
Technical Fit	Fits with the IT strategy - matches standards and protocols used by the organization.
Comprehensiveness	Facilitates the realization of objective goal setting with project-level benefits achievement. Provides measurement and analysis capabilities to enable validation.

Sharing

As a program evolves and grows, it will begin generating interest from various business areas that want to achieve the gains that BPM affords. The fastest way to onboard these new groups is to leverage the capabilities of the engine. Sharing the engine expedites the growth of the program and can be accomplished in all three engine areas.

Experts - Each solution team should use experienced BPM resources, either accessed through a shared group or by cross-pollination. Cross-pollination places experts onto each newly commissioned team, so that no team starts from scratch. New team members go through an accelerated learning curve working with experienced practitioners. The experts help the rookies avoid mistakes. An organization should have a mechanism to evaluate the individuals and to provide them with the skills they need to become said experts.
Software and Infrastructure - Once validated by the innovation team, software tools and infrastructure should be examined for possible leverage. If applicable to more generalized or common tasks then other teams gain an advantage in start-up costs. At a minimum, the start-up costs include software evaluation, software acquisition, and infrastructure creation. These start-up costs also have a time element behind them. The more quickly a new project can get moving the more quickly it can deliver business benefit. Business units need not constrain themselves by looking only to internal funds. Software and infrastructure leverage can be had by looking across company units. The Leadership tier should establish criteria for when sharing is and is not appropriate.
Methods - The set of methods is comprised of industry-available practices plus the cultural modifications that an organization imposes upon those methods. The first projects do an amazing job at uncovering and resolving differences between industry approaches and organization-specific requirements. These should be encapsulated so that future teams can avoid the same hurdles. Lessons learned and post-project assessments should be included in the methodology. This historical knowledge is most valuable if the encountered issues result in codified solution techniques and best practices for future use.

During the ramp-up, the program will reach a certain operating equilibrium. At this inflection point, the engine elements can still be shared, but changes will be noticeable in how they are shared.

Experts - Team members will become increasingly specialized in a larger BPM ecosystem. There will be experts in specific integration technologies, in portfolio management, domains of business operations, and so on. These experts will need to be shared because every BPM project will include tasks that these experts can address more efficiently than others, and it is not scalable to make everyone an expert in every area. Career objectives for individuals should include targets for attaining levels of expertise or for providing value across projects.
Tools - While not every project will use all of the same tools, there will be a core set of software products and infrastructure environments in common across the program. Where appropriate, costs for software licensing, hardware and hosting, and operational support for the BPM program can be shared so that no individual group bears an unacceptable load. This cost sharing not only allows projects to get started more quickly, but it keeps the operational costs lower than if the project had to furnish all of the operating budget themselves.
Methods - Common methods allow projects to provide similar metrics about their delivery capabilities, business benefits, and operational costs. This common bookkeeping allows the Leadership tier to better manage the program for success, continuing with beneficial projects and tweaking or terminating others.

The Charter for BPM Investment separates the maturity curve into three stages. The middle stage of Adopt is where most of these transitions are observed, with Validate and Transform representing the before and after, respectively.

Implementation

An organization must define a timeline and roadmap for realizing the engine. Here are some preliminary steps, with further discussion provided in the Charter for BPM Investment.

Specify Requirements - For each stage, specify the requirements for the engine. The immediately imminent stages will be more detailed than future stages. Clear and concise quality requirements for the roadmap are essential for driving the change management and adoption aspects of the program.
Establish a Roadmap - Take those requirements, and map them to a timetable. Communicate on the achievement of intermediate goals.
Regularly Revisit - Aggregate results and new information to drive revisions to the requirements and roadmap. Recalling Tenets 1 and 2, it is okay to make mistakes as long as mechanisms are in place to detect, to correct, and to avoid in the future.

Assumptions

As a program evolves, the mixture of people will change. Early stage programs will focus more on execution and confirming program viability. Over time, the people will specialize more. A smaller program requires more versatile resources to cover the range of responsibilities. As a larger set of projects imposes greater demand upon the engine, there will be more people filling the various roles. This is expected, but be prepared to equip each resource with adequate skills.
Tools will change over time. There is a limited lifetime for infrastructure, and software products change in their capabilities. Plan for the tools to change on a regular cadence, allowing new possibilities to be incorporated into the delivery of projects.
Use the successes and deficiencies of projects to adjust the program. Do not stick to the roadmap simply because it was established at the outset. Remember Tenet 1.

(Anti-)Behaviors

Behaviors

Anti-Behaviors

Insufficient Execution Methods - Six Sigma Falls Short

Conclusions

The BPM engine is key to the program. It provides the people and equips them with the means by which they can accomplish their jobs - delivering business results.

The organization must be staffed by representative parts of the company. Critical constituents include the Executive Sponsor for rapid decision-making, and Finance leader for proper cost-accounting and validation. Execution teams will change over time, both in their responsibilities and their capabilities, but some elements will endure through each lifecycle stage.

Choose tools and methods that work for the program. This might require an objective analysis to determine where the gaps may lie with the tools and methods currently in use in the organization. Let business drive the decisions, and fulfill them with IT experience and competence.

The more that skilled resources can be shared, that common tools leveraged, and that the methodology adapted based on experience, then the more quickly those goals can be realized. Comparatively, solutions that otherwise deliver the same business return will have a higher return on investment if they share the engine than if they do not.

Lesson exercises

This article is issued from Wikiversity - version of the Wednesday, December 10, 2014. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.