Defining and Managing Business Processes

Maintain and integrate business process in everything the enterprise does.

BPM and Social Media

Does Social Media play a role in BPM? Can you integrate Social Media in the development and maintenance of business processes? These are questions I have been thinking about. It goes without saying that social media has changed the way people communicate. It has also changed how we get news, some information and the way consumers interact with the enterprise.

However social media (SM), from where I am standing; does not appear to have changed much within an enterprise. I am sure if you work for a social media company you would vehemently disagree with that statement. However the companies I have worked with, generally use SM for outward facing communication, not always internal communication. Some internal areas where I have seen it used is by IT to inform user groups of system status changes, and by executives for quick, internal staff messages. I generally see a preference for F2F (physical or virtual) meetings, enterprise intranet portals and email for internal communication. So the question to explore is, could SM be useful in BPM?

Social Media and BPM

Caveat: I do not have direct experience in applying SM to BPM so the following thoughts are untested. However if I was asked to integrate the two, the following avenues are the ones I would approach first to learn from and then adapt based on the outcome.

1) BP Design
BP design is the heart of BPM. I do not see how SM could enhance the real-time interactive nature of the design process. Video conferencing was an enabling technology for having a broader audience present during the design phase. This resulted in better designs, socialized over a wider enterprise audience, hopefully making acceptance and adoption of the process easier.

Although I do not think SM can help during the initial design of the process, I do believe it can play a role in vetting the design outcome. Using SM for individuals to provide feedback and comments to the BPM team can help ensure that everyone in the group can see and monitor comments in timely manner. Participants also have an easy mechanism to publish their views and thoughts to the group. The BPM team benefits by having all of the feedback in a single, easy to access application. More pedantic uses of SM could be to notify interested parties when the latest version of the BP is available for review, etc. So as a communication tool, I see certain benefits of SM over say email, where not everyone may have access to comments because they were not included in a response thread.

2) BP Improvement
Once the BP has been finalized and changes to the system(s) made, it is adopted and used by people. After these people use the process, they may see improvements that could be made to increase process effectiveness or efficiency. Who do they tell? Where do they go to make the suggestion? I see SM playing a role here. I also see this usage as having the most potential for controversy.

The people who use the process are not always aware of why it was designed in a particular manner. Lacking that information, to them what seems inefficient could actually be a critical step that provides benefits in subsequent activities. Without complete information, the users may find it difficult to make suggestions to a BPM community. This is especially true if the users have experienced harsh criticism from the community in the past, or felt the idea was ignored due to lack of feedback.

This is where a mature SM culture should exist in the organization before taking this step. Criticism, right or wrong, is always going to happen. It is in the way that criticism is delivered that makes it palatable for most people. If the SM culture is one of an open and honest exchange of ideas, then this should work. People who use the process everyday should have good insights for potential improvement. So being able to capture those suggestions for evaluation should result in better processes.

The other end of this conversation is around user expectations. The length of time between when an idea for change is put forward and when it is delivered in the system can be long. Changes to a system, once productive, are generally slower than when the system is being implemented. The expectations of the people making the suggestions will need to be managed under these circumstances. The volume of suggestions may also dramatically increase putting more pressure on the BPM team to turn around their evaluation of the proposed changes. All of these should be thought about before opening up the SM floodgates. (Almost sounds like the BPM team may need to define a BP for this type of activity 🙂  )

3) End User Training
The last area that could benefit from this is not a BPM responsibility, however they do share a consultative role here. By harvesting and analyzing process feedback, a need for training may be identified. If people using a process make requests for changes due to a misunderstanding, it could  point to the need for additional training. Although it would not be the responsibility of the BPM Team to deliver this, they could be used to identify specific areas where increased training or change communication is needed. The appropriate group could then take action to resolve the issue.

Final Thoughts
So overall I do not see a revolutionary role for SM in BPM. SM may be able to increase the speed of BP development, improve  stakeholder communication and provide insight into how the enterprise is adopting new processes. The enterprise should also have experience in, and established some level of cultural norms for using SM, before applying it to BPM. In my opinion, BPM should not be the leading wave for enterprise SM adoption.

Advertisements

Digitizing Business Processes – Pt. 1

So you have finalized your BPM library. All the AS IS and TO BE Business Processes (BP) have been vetted and approved by the owners. The next step is to map the TO BE process to a software application and configure it to automate and standardize the BP across the enterprise. The application may be an ERP (Enterprise Resource Planning), SCM (Supply Chain Management), CRM (Customer Relationship Management) system; or a custom-built enterprise software application.

So how do you take the swim-lanes (roles), boxes (activity / controls), and diamonds (decisions) from the process design world and make them a reality in the digital world?

Remember there are differences between procedures and processes. (Click here to review post on this topic). A procedure informs a person how to use the screen; a process informs the system owner which screen needs to be configured and presented to that person to execute the BP.

First Step
Start with the list of TO BE BPs. This list is compared (or mapped) to the relevant functions in the software application that will be used to produce and record the BP outcome. At the end of this mapping activity, you should understand the broad scope of the software application as it relates to your enterprise.

This broad mapping will include some areas where additional questions need to be answered to finalize the mapping. It may also lead to some difficult decisions, especially when a software function is in more than one software application, or where the process requires functions in more than one software application.

[NOTE: If the software application is broad enough, you may be able to start this mapping at the Value Chain (VC) level. For example, most ERP systems have a broad range of integrated functions and applications. So the VCs for Procurement, Financial, Human Resources and Enterprise Planning could be mapped to the ERP system, while the Customer Acquisition/Sales and After Sales Service VCs are mapped to a CRM system. After these broad decisions are made, then the detailed individual business process mapping can be completed, based on the functions in those targeted systems.]

Other Considerations
Information Technology (IT) may have a strategy that no modifications will be made to acquired software, i.e., the business process will be changed to work with the software. In this situation you will need to understand the software in more detail to understand how the BP flow will have to change. Generally if the software was designed to meet global best business practices, the BP changes may be warranted, unless the process is a strategic differentiator.

Depending upon the software acquisition stage the enterprise is in, the BP could be designed from the start with the target software in mind.

If the IT strategy is to modify software to work with the designed BP; software changes may be justified under certain circumstances. The BPL should work with IT to understand the cost and viability of modifying the software to conform with the TO BE process.

In some cases the modification is relatively easy and does not go against the fundamental structure of the software, leading to reasonable software change and maintenance costs. In other cases, the required change is so far-reaching, amending the software would be extremely costly; and turn a 3rd party software product into essentially customized enterprise software.

As the benefit of 3rd party software is reduced lifecycle maintenance costs, each modification should be evaluated, and not just made because the business wants it. The long-term benefits of the change should be considered against the costs.

Example
To help visualize this activity, the Value Chain – Plan to Fulfill, from a previous post, would be mapped to a generic ERP system as follows:

Software Process Mapping

This activity develops a basic mapping of enterprise processes to the software, and identify areas that need additional investment:

  • Prototyping portions of the software
  • Additional functional analysis
  • Software knowledge gaps
  • Potential modifications
  • Software licensing issues

If significant BP issues appear as a result of this activity, it may point to the need for an implementation pilot. A pilot can help uncover and validate the impact changes will have on the enterprise, before a full-scale deployment commitment is made.

This mapping process also defines the scope of the software implementation project. It can be used to ensure that only software functions mapped to a valid BP are configured. If additional functions are requested (or added) after the project scope has been struck, it can help ensure it is based on business needs. By controlling the scope of the software configuration process, implementation costs can be controlled and integration points can be fully understood.

The next post will discuss mapping roles, activities, decisions, and controls to the software functions.

Collaborative Inter-Enterprise Business Processes

So far this blog has covered business processes that originate and terminate within a single enterprise or entity. What happens when a business process extends beyond the boundaries of one enterprise, into another? How do you integrate your business processes with those of a strategic partner to ensure transactions between the two enterprises are executed correctly, consistently and at the most efficient cost? What happens if one enterprise believes in BPM and the other does not, can this still work?

Many questions. Lets explore some possible answers.

Why?
Lets first understand why and when you would want to integrate your processes with another enterprises processes. Then we can look at the mechanics of defining these process flows. A few situations come to mind in regard to integrating business processes with another enterprise.

  1. Critical Supplier: Your enterprises customer success or failure, hinges on a critical part, or service, provided by a strategic supplier. To be successful your enterprise needs to understand the quantities that can be supplied during a period to ensure you set customer expectations and meet expected customer demand.
  2. Strategic Customer: The flip side of this relationship is as the Supplier. Your enterprise is interested in the demand of a strategic customer to ensure you can meet that demand at a reasonable cost and inventory level. Understanding their forecasted demand for future periods, makes your planning easier; and combined with demand from other customers, enables you to apply your resources in an optimal manner.
  3. Joint Venture (JV): In a JV, two or more enterprises partner on the development and execution of a business venture to reduce individual risk exposure. Generally one of the enterprises is chosen as the “Operator” of the venture and the others are partners supplying agreed to resources. These could be financial resources (cash calls), labour, or IP expertise in the form of people, or specialized equipment, etc.. Under these circumstances, the operator must be able to rely on the availability of the resource requested. The partners must be aware of the resource demand and timing to properly match the JV demands with other parts of their business. Integrated business processes across enterprise boundaries can ensure these objectives are met.

Reciprocity
To fully integrate business processes, both enterprises must be in agreement. If one party wants to and the other doesn’t; then trying to integrate business processes will be a fruitless journey, best not started. The parties should also understand the benefits that will result from this activity. These benefits are an integrated process that is executed efficiently, consistently and correctly each time it is invoked between the participating enterprises.

Methods
To identify this unique relationship in a process model, one of two methods can be chosen. The method chosen is generally based on the depth of the relationship and the required insight into the other enterprises business process. Other drivers could be risk factors associated with the process,  the transactional magnitude, or strategic importance of the transaction. The methods are either 1) using a unique ‘Role‘ in the process flow to represent the external enterprise; or 2) a unique process symbol that recognizes an external process the enterprise has an interest in, but does not execute.

Example
The role method is best used in a situation where both enterprises exchange and integrate a shared business process. It provides insight into the total process and increases the context surrounding the process for both enterprises. If changes are contemplated for the process, it ensures the BPM team is aware of all the parties that need to be involved.

External Role in BP

Example # 1

A unique process symbol can be used in a process flow to represent external processes where details of the other enterprises BP is unknown; however it is important to the overall process flow. The required inputs and expected outputs are known; however how the other enterprise uses and arrives at these values is unknown. The value in representing this external process in the flow is the enterprise understands when critical information is exchanged and the degree of control they have on the data. This symbol identifies that any changes to the inputs or outputs of the flow need to be coordinated with a third-party.

External Process

Example # 2

In the above examples, the Production Manager is developing a short-term production plan. In order to optimize the production run they provide expected quantity details of a critical component to an external supplier. The supplier provides feedback to the enterprise on available quantities, which then enable the production manager to finalize plans and communicate them to the rest of the organization.

Where the process is more integrated and transparent, the supplier is shown as a role and they identify to their customer, i.e., the Production Manager, the steps they go through to determine the final available quantity. In the second example the same information is exchanged; however the Production Manager has no insight into how the final quantity is derived.

Both methods identify a critical communication path that needs to be maintained for optimal enterprise performance. However they differ on the amount of information exchanged between the two enterprises that can be used to resolve short-term production issues.

BPM Success – Many vs. Single Project

BPM will present many challenges to an organization. The question that always come up at the start is do you need to go “all-in” with BPM to be successful; or can BPM be successful in small batches? In some respects the challenges you face under either approaches are flip sides of the same coin. So lets look at each approach separately to understand the benefits and challenges.

Multiple Small Projects
The challenge you face when you go with many small BPM projects, is you must maintain the processes that have already been put in place, along with adding the new ones. This can stretch BP resources at various times, depending upon the velocity of change in the business units that have adopted BPM.

Initially it is relatively easy to maintain the first few batches of finalized business processes, while developing the next batch, as the BPs are new and generally will not change. However think of the challenge when you are 3/4 of the way through the enterprise. You will be designing and adding new processes that impact existing processes. At the same time these existing processes have aged and may themselves need to be maintained due to changes in the business environment. Coordinating the review and approval of all these types of changes generally stretches the organization near the end.

Another challenge is to decide how to represent processes that have not been discovered and drafted in the current BP design. Generally this problem exists in the early projects, and lessens over time the further you get into the enterprise. A process reference, with potential departmental or functional ownership, can easily be added to the current model. However managing these “placeholder” processes to ensure they are not included in the final process model can be an issue. An enforced naming convention and continual check for these process references at the start of each new project will reduce the possibility of having these placeholders in the final enterprise process model.

Single BPM Project
Lets compare the above challenges to the challenges of implementing a complete enterprise process model in a single project. The first two challenges will be organizational commitment and resources . Getting commitment to a project that crosses the enterprise requires significantly more people to be convinced that it is needed for their continued success and some of their best resources will be required to make it successful. This challenge will manifest itself in significantly more meetings and presentations with senior management across the enterprise, to discuss the BPM value proposition before a project is struck .

Depending upon the size of the enterprise, finding and pulling together the right resources can be difficult. If you do not have the commitment of enterprise management, project resource issues will be exacerbated as when the right person is found, getting management to relinquish their grip on them will be difficult. Significantly more resources are needed in this type of project, along with more extensive business knowledge, which will present its own challenges to ensuring the enterprise continues to operate with reduced organizational capacity over the project term.

The last challenge is coordinating the final process model so all BPs touchdown on the runway at the same time. Some of the less complicated processes will be finalized early in the project, and most will be finalized before the project ends. There may also be a few stragglers that need to be worked on after the project is officially closed. These timing differences need to be coordinated and business expectations managed, to ensure other problems are not created. There is also the risk in any project that a BP may change between the time it is finalized as part of the project and the project go-live.

Which approach is better?
Either approach to a BPM implementation can deliver a full enterprise model. So perhaps the better questions to ask are:

  • What fits the enterprise culture?
  • What resources are available?
  • What is the level of management commitment?

If you choose to implement BPM in a series of small projects, the scope of the project will matter. The projects should be arranged based on natural enterprise boundaries; i.e., geographical, business unit, functional boundaries, etc. Coordination costs will be higher, more changes to the core model may also incur greater verification costs on existing models. However this is offset by spreading the costs over a longer period of time and reducing the overall workload on the organization at any single point in time. The other benefit is taking the experience and learning from one project, to improve the future projects.

A single implementation project will be easier to coordinate, reduce process verification costs, and should reduce organizational fatigue that can set-in over a longer project timeline. The drawback is the drain on resources and the potential impact on operational capacity.

KPI Hazards

Whenever I think about measuring a process or activity two quotes come to mind:

“Errors using inadequate data are much less than those using no data at all” – Charles Babbage
“Not everything important can be measured, and not everything that can be measured is important.” – Albert Einstein

Although it is nice to have complete and accurate information when making a decision, you will not always be in that position so at times imperfect data will have to do. In the same breath, just because you have data to make the decision, make sure it is relevant and appropriate for the decision you are trying to make. This leads into some potential hazards that may be encountered while deploying a management KPI program. I will group these hazards in three areas, Program, Management and IT Systems.

Program Hazards

1) Do not wait to deploy
If you have done all the ground work and are ready to deploy the program, do not wait on the technology. If you postpone deployment until the next great capability, the program will lose valuable momentum. The organization will lose understanding on how and what changes with the program in place. If the program is bogged down in deployment issues, you can easily lose sight of the original objectives you were trying to achieve.

2) Develop and use a KPI once
The power of a KPI is in the monitoring and comparing its value and understanding how it changes over time. Using it just once can be a waste of time and resources.

3) Measuring something because it has always been measured
Critically look at each measurement and ensure the measurement is tied to business objectives and goals. If the KPI is not tied to business objectives and goals, ascertain who uses it and why to ensure you are not mindlessly collecting and reporting data.

4) Developing KPIs in a vacuum
Ensure you understand the environment in which the KPI operates. How does it relate and behave under external and internal influences? Does the behavior change based on lifecycle stages, market threats, complimentary products, seasonality, etc.?

Management Hazards

1) Initiate the program without management buy-in
As with any program, senior management needs to understand the goals and objectives of the KPI program to ensure it fits with the current strategy and objectives of the enterprise, or entity they are managing. If the program moves ahead on good intentions, it will face headwinds that will only become stronger, each time the program asks of management attention.

2) KPI Ownership
If you do not get management buy-in to the program, obtaining individual commitment and ownership of a KPI can be next to impossible. If you do have management buy-in, this task is still very difficult as it asks a person to stake their reputation and performance on something they may not have a lot of experience with. Transitioning from the current to future state will require strong management support. (Note: Without ownership, the objectives of the program may never be fully realized.)

3) Not monitoring organizational behaviour
Responsibility is a double-edged sword. When ownership is obtained, people may find creative, unplanned ways of achieving those goals. In some cases this can be very good, in others not so. It is wise to ensure the behaviours of the KPI owners are correct and that incorrect behaviours are caught and adjusted early.

4) Management Influence over KPI value
If management can subjectively manipulate the value of a KPI, it is no longer a KPI. The values should be obtained objectively and consistently. If the value appears to be incorrect, address the concerns and validate the collection process, do not change the value because management wants it manipulated.

5) Achieve the right balance of KPI
Pushing out to many KPIs does not enable the right organizational focus. Pushing out to few, will narrow the focus to potentially obtain sub-optimal results. Finding the right balance and numbers of KPIs is an art, and will only be learned with experience.

6) Continue relying on intuition to make decisions
If people are not relying on what a KPI is telling them, it can point to many different potential causes. One issue could be a lack of trust in the KPI or process. This can be overcome with time and training. Publishing ‘real’ organizational success stories from  various groups in the enterprise can also help overcome trust and belief issues.

IT Systems Hazards

1) Remember security access and authorization
Part of the design feature set must include who and when data can be accessed; and enabling the auditing of data collection processes and data access points. Consider it early in the design phase.

2) Measurement data architecture decision
With data being everywhere in an organization, IT must decide if the data for KPIs and Performance Management will be centralized under the control of one group. The alternative is to keep the data in its source area and add integrated reporting capabilities to the data source for KPI presentation purposes. Decentralized vs. centralized data storage and architecture is a critical decision and can sometimes get bogged down in control issues.

3) Training is as important as KPI reporting and presentation
Training; at go-live and ongoing, is critical to ensuring people understand how and when to the use the system to enhance their decision-making capabilities. Users need to understand the context of the KPI, associated data and potential analytical capabilities for widespread organizational adoption.

There is a place for gut-level decision-making in parts of the business, usually areas where the work is more art, than science. There are many more where the application of rigorous, scientific data collection and analysis are the answer to the question. Knowing which is which separates the extraordinary businesses from the everyday. Putting together a structured, repeatable KPI management process can get you started on the path to extraordinary.

KPI Structure

To improve KPI management the development and use of a business process to consistently define a KPI should be implemented. Part of this process is to define the attributes, or metadata that should included in the definition of each KPI. Following is a collection of attributes that can be considered for defining a KPI. Pick and choose the ones that are relevant to your installation.

KPI Attribute List

KPI Name: A short description of the indicator. This is how the users and enterprise will refer to this KPI.

KPI Definition: A longer description of the KPI providing detail and context on what the indicator is measuring.

Responsibility: The person responsible for the outcome of the KPI. This could also be a role or position (not recommended).

Unit of Measure: Provides the measurement criteria of the numeric value, i.e., $, Each, %, SKU, Days, Boxes, etc.

Calculation Formula: If the value is derived from a calculation, provide the formula and calculation details.

Reporting Period: Real-time / Daily / Weekly / Monthly / Quarterly / Annual / etc.

Value Ranges: A set of potential values used to gauge the current value. The values would be categorized as “High”, “Low”, “Average”, and if appropriate “Abnormal”, and “Critical”.

Status Setting Formula: If the indicator has a status setting mechanism (i.e., Green/Yellow/Red) to quickly identify its health, document the formula that sets this status.

Data Source: Identify the data source for the indicator.

Time (Data) Latency: Identify the time difference between when the KPI value is updated and the actual values change. For example, Sales Revenue changes in real-time after each sale is complete; however the Sales Revenue for KPI purposes is updated nightly, leaving a 24 hour data latency period.

Management Latency: Identify the period of time between when an indicator reaches a critical threshold and when management needs to take action.

Value Categories: Identify the different values that should be collected for this KPI; i.e., actual, plan, budget, forecast, benchmark, target, etc.

Forecasting Required: Identify if the KPI should be included in the regular forecasting process. If calculations to derive forecasted values are different from the actual value calculations, identify the forecasting formula (if different from actual).

Leading / Lagging: identify if the KPI is predictive or historical. This can be important if the KPI is used in a Balanced Scorecard.

Data Security: Identify the required level of data security.

Performance Trend Profile: Identify the calculation and time period for determining the current and desired trend for this KPI.

Aggregation Levels: Describe how the KPI is aggregated at various organizational levels, Summed, averaged, recalculated, etc.

Historical Data Requirements: For Go-Live only, determine if historical data is required for the KPI. If historical data is required, determine the historical periods it is available for.

Data Transformation Requirements: The source data may not be in the correct data format. As a result the definition of transformation rules will need to be defined and applied to the source data to put it into the correct format.

Ergonomic Properties: Identify the best presentation methods for this KPI. Determine if the KPI is best suited to viewing at a single point in time vs. a time range, comparison across different value categories or to other KPIs, data bands (high, average, low).

Related / Associated KPI: Identify related or associated KPIs.

To complete this post, lets look at an example of how these attributes would be used.

Hypothetical Situation:
The CEO wants to understand the coverage of sales revenue for each employee in the organization. From the interview it is determined the sales revenue should be equal to what is published externally to shareholders and creditors, and they want the entire headcount of the organization included. The KPI should be reported to executive management on a monthly basis as part of the standard reporting package. If it is available, comparison to planned values would be helpful. The following data would be collected for this KPI:

KPI Name: Sales Revenue per Employee
KPI Definition: Published operating sales revenue divided by the number of employees at the end of the period that matches the sales revenue. It identifies the sales coverage for each employee and can be compared to average employee wage.
Responsibility: CEO
Unit of Measure: Dollars ($)
Calculation Formula: Operating Sales Revenue / Number of Employees
Reporting Period: Monthly
Value Ranges: High > $200,000 / Low < $60,000 / Average $125,000 / Critical < $45,000
Status Setting Formula: Green => $100,000 / Yellow < $ 100,000 / Red < $ 60,000
Data Source: General Ledger / Payroll System
Time (Data) Latency: 1 Month
Management Latency: 1 Fiscal Quarter
Value Categories: Actual / Plan / Benchmark
Forecasting Required: N
Leading / Lagging: Lagging Indicator
Data Security: Publicly available at the consolidated Enterprise level, Executive and SBU Management only for all data levels below Enterprise.
Performance Trend Profile: Target Trend is UP / Current Trend is FLAT. Trend data with a simple average over a rolling 12 month period.
Aggregation Levels: Consolidated Enterprise is required / Optional breakdown of indicator by Strategic Business Unit (SBU) and Main Operating Geography. Indicator should be recalculated at each level beneath Enterprise.
Historical Data Requirements: For comparison purposes, previous fiscal year, at the enterprise level only.
Data Transformation Requirements: Weekly sales values from the GL must be summed into monthly fiscal values.
Ergonomic Properties: Monthly figures shown for the past 12 months using a line chart. Comparison: Monthly Sales KPI for the same period and Average Employee Wage (Annual).
Related / Associated KPI: Operating Sales Revenue, # of Employees

This method pays dividends when questions arise in the future about a KPI. It also speeds the deployment of the KPI as some of the technical requirements are identified to start the development process. Any future changes or additions to KPI reporting should be easier with this documentation.

When a consistent methodology is used to define KPIs, the organization can rely on the values reported. This should lead to better informed decisions through out the organization and reduced support costs.

KPI Management

One aspect of Enterprise Performance Management (EPM) that can be easily integrated with BPM to add significant enterprise value is identifying where key performance indicators (KPIs) are generated, and providing context on how and where they are used. BPM can also link data sources for the KPIs and provide insight into mathematical calculations needed to derive their values.

Identifying where KPIs are used and in what decisions they play a role, can increase the understanding and importance of the business process, along with providing insight into how the enterprise is managed. It can also assist in streamlining data collection procedures and enable the rationalization of KPIs used throughout the organization.

To start let’s get a little more familiar with what a KPI is, and how it can be used. In future posts we will develop a structure for KPIs and provide insight into how BPM can help an enterprise manage and organize their KPIs.

Most enterprises are awash in KPIs (or metrics), measuring everything, from operations, management, and market performance, along with any number of external factors. So generally the issue is never one of trying to find a new KPI, but rather rationalizing and focusing on the right KPI for a given situation or circumstance.

KPI Value & Volume

Generally executive management in an enterprise will monitor a few critical KPIs at any given point in time. This set of metrics tends to be very dynamic depending upon the situation the enterprise is in. Metrics monitored today, will probably change next week and the week after that. Senior and middle management will generally monitor a higher number, and less dynamic set of KPIs than executives. However these will also change depending upon enterprise and business unit circumstances. Operating personnel will monitor a higher number of metrics, on a more frequent basis, as they work with a set of metrics that evolve slowly over time.

However when we take a look at the impact these metrics have on the enterprise, and the value they can generate, the situation is reversed. Actions taken by operating personnel based on a metric will influence the outcome of a local process, with a compensating value. Management actions will impact their scope of control and perhaps influence a related managers scope of control, with a value commiserate with that scope. When an executive takes actions, the impact can be felt across the entire enterprise, with the value or outcome of those decisions generally following a similar pattern.

KPI Landscape

KPIs can be linked from the top of the organization, to the bottom; with reciprocal action going back up the chain. Combined with planning and forecasting systems, and collection of actual values, all levels of the organization can monitor critical metrics from their viewpoint. When these KPIs are linked properly at each organizational level, they can be used as levers to influence organizational actions. This can ensure changes are properly communicated and incentivized to the people who must take the action; while the outcome is monitored to ensure the decisions were correct or understand if further adjustments are needed. This ability to influence actions and outcomes shows the potential power and the leverage a KPI can have in an enterprise.

BPM provides  a framework to completely integrate KPI reporting and management into processes throughout the organization, and provide the context in which the KPI is used. KPIs will (and should) change over time. Establishing and reporting on new, or maintaining existing, KPI reports can be a time-consuming and expensive proposition for an enterprise. With BPM these direct costs can be identified and managed to ensure proper returns.

There can also be an indirect cost associated with getting the data collection process wrong, and presenting an incorrect value leading to a bad decision. The consistent collection of data and application of BPM methodology (structure of how KPIs are defined, sourced and reported) can help ensure the enterprise has the right information, applied to the right situation, at the time a decision is required.

So if KPIs are important to an enterprise, and structure is necessary to ensure they are consistently and properly defined and sourced, what is the configuration of a good KPI? This will be the topic of the next post.