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?

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.2

Once each process flow has been mapped to a digital function or transaction in a software application, the project implementation scope has been defined and detailed project planning can start. The art of marrying business process and technology generally takes place in the Design or Blueprinting phase of the project.

With the scope defined, each process flow is analyzed to identify how each process element (activity, decision and control) will be realized in the application. Doing this for a handful of processes is not difficult. Doing this for custom coded software is a little more challenging. However doing this for hundreds of processes on any type of software, 3rd party or custom, is very challenging.

Each person on, or associated with, the implementation project will make many small, seemingly insignificant decisions that, when added together will effect the outcome. So how do you control mapping the process components to the application functions to ensure you achieve the desired TO BE Business Process that started this journey? To answer that question is one of the most difficult and challenging aspects of realizing (or configuring) an application.

There are going to be many times when a compromise is required, either in the process or the software. The corporate IT strategy will play a role in this. Even when the corporate IT decree is “no software modification”, changes may still occur because:

• Modification is required (and justified) to enable a strategic differentiator for the enterprise
• Modification is supported by the software provider at certain pre-determined points in a function
• Modification is contracted to, and supported by, the software provider

In each of these instances, cost vs. benefit (tangible and intangible) needs to be considered before the modification is acted upon. The fewer (preferably none) modifications made to the software will save long-term maintenance and upgrade costs.

Begin by looking at the digital function that was chosen in the first part to execute a business process (BP). Each process element; activity, control and decision will be mapped to a screen, or series of screens, within the application. The screen or function should be configurable based on how the software will be used and it is these configuration decision points that need to be controlled in order to align the business process and the application in a way the business requires and can use to meet its objectives.

(NOTE: If during these mapping sessions, the BP Elements are getting down to defining individual fields on each screen, the BP may be at a level of detail that is not sustainable over the long-term. See a post on this topic here).

The main issues that arise during this mapping process are:

1. the order in which the application does things is different from the process flow, or;
2. the way users have to navigate in the application to achieve the end result, or;
3. the application does not support the activity, control or decision wanted by the BP designer.

In each of these situations, the BP Designer and Application Configuration Expert should determine the best, most cost effective way around the issue. The solution could be to adjust the process, drop the step in the process flow, or modify the software.

1) If the order of execution is different from the design, but the outcome is the same, the BP designer can modify the order of the BP flow to match the application. During this re-mapping, any changes that impact other integrated BP flows should also be reviewed to ensure the end result of the affected process is maintained. If the order of execution changes the process outcome, decisions will have to be made by the relevant process stakeholders.

2) The issue of end-user navigation is a little tougher to resolve. Each user will have a different opinion on the navigation and order of screens. Project Change Management should be charged with the responsibility of bringing together the appropriate stakeholders and users to review the changes and identify issues of concern to be addressed before the go-live.

3) The BP designer must evaluate the impact of a missing activity, decision or control point on the overall process. Working with the BP Owner and/or BP Leads they need to determine how they will move forward without that BP element in the application. Depending upon the magnitude of this decision, a basic understanding of modifying the software and a cost guesstimate for the change, can help some business leaders reach a decision.

The critical point to be made here is that during this business process mapping activity many decisions will need to be made by the business and IT to enable the project team to move into the project realization phase. It is these decisions where project schedule (i.e., time), scope, and skill-set collide with business policies, strategies and cost. The swiftness and completeness of the decisions will define the carnage resulting from this collision. Final decisions will be negotiated under the stress of bogging down committed project resources, costs and schedule, in an arena of incomplete information. Attention to, and management of, these decisions will be crucial to the success of the application implementation.

The final steps after this mapping process is concluded is to update all TO BE process flows and get the formal signoff from the BP owner for the changes. The project team should begin the Configuration phase of the project based on the outcomes of the approved changes.

The BPM team should update the metadata of the BP flow and elements with the applicable functional software reference. This will assist them in the future when process amendments are requested, to easily identify the impact on the supporting applications and enable a faster, more complete definition of the scope of the change.

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:

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.

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.

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.

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.

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.

BPM Metadata Process Flow Elements

The most prolific element in the BPM hierarchy with metadata is the process flow element. The most common process flow elements are: inputs, outputs, activities, decisions, control points, roles, and process flow connections. (If you want to refresh your memory on these topics please click on the links.)

Of these process flow elements, this post will focus on the two most widely used elements, activities and decisions. Like their parent object, the process flow, common metadata attributes for all flow elements are technical identification, description and ownership. Technical identification establishes relationships between the element and the process flow(s) it is used in. The ownership metadata attribute is optional, as generally ownership is established at the process flow and inherited by the element. However in some cases ownership of the element can be different from the ownership of the process flow it appears in and this should be noted.

A different kind of ownership is defined by the role an element is assigned to within the process flow. This type of ownership is generally referred to as RACI and is used to clearly communicate a roles responsibility for the element in the process flow. RACI is an acronym for Responsibility, Accountability, Consulted, or Informed. It is assigned from the perspective of the process role and describes that roles participation in the handling of the activity, task or decision in the process flow. It identifies the role who will perform the activity (Responsible) vs. the role that ensures the activity is completed correctly (Accountable). It also establishes if the role is part of the decision-making process (Consulted), or if they are made aware of the decision after it is made (Informed). This RACI designation should be a mandatory metadata attribute for each element in a process flow.

Process Flow Element Metadata:
Similar to how a process flow, references or disaggregates data from a value chain; elements of  a process flow will behave the same way with the metadata of their parent, the process flow.  The metadata that may be collected for process flow elements are:

• Technical ID
• Description
• Ownership (if different from BP Flow)
• R/A/C/I
• Revenue
• Cost
• Execution frequency
• Cycle time
• Enterprise Security Level
• Data Security
• Critical Control (Y/N)
• Control Type (Detective / Preventative)
• Generated KPI
• IT Application Reference (Manual if not digitized)
• Reference to Report(s)
• Reference to IT Data Structures

All of these metadata attributes can overwhelm the data collection and maintenance process, so choose carefully as there will be thousands of elements by the end of project. If the metadata attribute is part of the parent process flow, and the value will not change at the element level, or it does not serve any analytical reporting value, it should not be duplicated in the element.

Not every metadata attribute is listed and, not every listed metadata attribute should be collected. Choose the ones that will support your BPM program objectives. Metadata may also be constrained by the BPM software, as you may not be allowed to freely define additional metadata attributes for all BPM objects used in the software. Alternately, the software may require certain metadata attributes be collected which will add to the work level. These points must be considered before a final choice is made.

Deciding on and collecting metadata attributes in the late stages of the project, or when the project is complete, is also viable. If the main objective of the project is to define, document and integrate existing business processes, it is wise to concentrate on completing that objective first. After the processes have been defined, you can begin to define the objectives and requirements for BP reporting and analysis from a base of experience and a better understanding of BPM, enabled by the right choice of metadata.

However it is accomplished, metadata definition and data collection for BP Value Chains, Process Flows and Flow Elements is a critical piece of the BPM infrastructure that should not be overlooked.

BPM Metadata – Value Chains / Process Flows

We live in a world of data; big data, real-time data, virtual data, sensor data, and the list goes on. As a result everyone is familiar with the concept of data records describing an object, transaction or activity in various digital systems. Metadata works to describe the data within those records. This blog post will focus on metadata associated with BPM Value Chains and Process Flows.

It should be noted that each metadata attribute added to a BP model should be chosen carefully. If the metadata has value when it is seeded; it needs to be maintained to harvest that value in the future. There is a cost for this maintenance, so before making a final decision it is wise to understand how BP reporting and analysis will be enhanced by the metadata, to ensure the cost is worth it.

Common metadata for all BPM elements are technical identification, description and ownership. The technical identification is a standard naming convention that is referenced by all associated process elements. Once the identification is established it should not change. The description is a text field that holds the definition of the element. Ownership can be the name of a person or position; however it is critically important to establish and maintain this ownership value for all process elements.

Value Chain Metadata:
Value chain elements are the highest level of the BP model hierarchy and do not consist of a lot detail. Potential metadata associated with each link in a VC are:

• Technical ID
• Description
• Ownership
• Data Security Level (H/M/L)
• Geographic Scope
• Profit (or Contribution to Profit)
• Cost

As an example, the following metadata list could be generated for the Retail Value Chain used in a previous post.

Business Process Flow Metadata:
The metadata for a business process flow references, and in some cases, disaggregates metadata values inherited from the value chain it is related to. Depending upon the cost of data collection; and the ease or ability to separate total values into a process view, the applicability of some metadata elements may be limited.

• Technical ID
• Description
• Ownership
• VC Relationship
• Execution frequency
• Execution cycle time (actual/expected)
• Data Security Level
• Geographic Scope
• Criticality Level
• Profit Value / Profit Contribution
• Operating Cost
• Intellectual Property Assessment
• Risk Level
• IT System Reference
• Control Method (Detective / Preventative)

The above can be a lot of data collection considering most enterprises have hundreds, if not thousands, of process flows. The bolded metadata is the minimum that should be considered for adoption in a BP model. Other metadata values should only be adopted if the cost of data collection and maintenance is acceptable.

Following is an example of process flows associated with the Plan to Fulfill Value Chain.

The end result of collecting and maintaining this metadata must be enhanced BPM reporting and analytical capabilities. In the above examples this analysis could take the form of:

• Measuring the efficiency of a locally executed process against expected cycle time.
• Regularly identify and review controls for all highly sensitive data processes.
• Identify all value chains and process flows associated with a change in position.
• Identify processes and value chains in a region that is being reorganized to evaluate impacts on the process model.

There are many other metadata attributes (or data attributes) that could be considered for adoption in a BP model. Each one should be chosen to ensure their selection is aligned with BPM program objectives. This will become extremely important when considering potential metadata attributes for elements included in business process flows (i.e., activities, decisions, etc.), the subject of the next post.