BPMN Tutorial - Part 2 - Collaborations

The Key Techniques of Process Improvement

Every organization has some form of process improvement program in effect today. Some of these are enterprise wide and some are focused on key or mission critical processes. Most are somewhere in between. Some are driven by new technologies, new applications and new strategic direction, objectives, goals and initiatives. Some of these projects come from applying management disciplines like balanced scorecard or value streams, agile process techniques, value chain the Rummler –Brache approach to process change or one of the other 50+ disciplines.

Process improvement techniques have been evolving

Every organization has some form of process improvement program in effect today. Some of these are enterprise wide and some are focused on key or mission critical processes. Most are somewhere in between. Some are driven by new technologies, new applications and new strategic direction, objectives, goals and initiatives. Some of these projects come from applying management disciplines like balanced scorecard or value streams, agile process techniques, value chain the Rummler –Brache approach to process change or one of the other 50+ disciplines. Whatever the approach, few are well versed in the techniques of process improvement. Most organizations fall back on two approaches:

1. Use a consultant to facilitate or actually do the process effort
2. Buy a tool and have the vendor teach you their methodology for using the tool

Both of these put the responsibility outside the organization. It is not surprising the studies show that 75% of process projects are a failure in some way. They may be over budget, take too long, become too complicated, fail to deliver results or actually implement the wrong process. This last one, implementing the wrong process is usually done at the expense of user productivity. So what can be done about this?

Just what is process improvement?

Process mapping is not process improvement. Process mapping will identify where a process is not meeting its original intent. The process team can do maintenance and bring the process ‘up to specification’ that was originally defined for it. Process mapping is also not considered process modeling. Process modeling includes the documents (data) for the process, the decisions (rules) and any other enablers like skills, policies, procedure and technology that are needed to make the process work and deliver results ‘as expected’ by the management.

So, does mapping do anything for you? Yes, there are many benefits from mapping with the most important is that mapping allows you to visualize the work. It can also capture multiple views of a process through the use of swim lanes. In cleaning up the process you can see redundant steps and things that are out of sequence. A map is then a recording of process execution sometimes called the ‘process of record’. They are also a part of methodology usually related to the use of a process mapping tool.

When documenting a process you start with the actions or process steps. These steps help determine many supporting needs such as the data used by a process, where the work is done, who does the work, what they need to do the work, any decisions they might make or rules that drive the decisions and so on. These are the enablers of the process.

Real improvement requires a methodology that focuses on problem solving for process issues and aligning both the process architecture and process execution with business goals. The simplest start for problem solving is comments in interviews that lead to improvement. An interview with key managers and operators of a process and its context identifies problems, opportunities and enabler issues such as poorly performing applications or lack of data access. Any improvement decision should relate processes to organization performance.

One of the key factors often not included is the comments by the users of the process. These are the people that need the skills and other enablers to effectively make a process work. This is especially true when an application is required to support the process. The application navigation will make or break the delivery of value to the business. Only the users are knowledgeable about this need.

Improving the process

Primary in improvement is knowing where the improvement opportunities are located. Are they in a major process? Are they in a sub process? Are they in a related process? Locating the process opportunity requires that the process team gather evidence of lack of process performance. The number one questions should be does it meet the business goals or objectives for that process? In many cases these have never been actually documented but are assumed especially when dealing with sub processes that take on the goal of their parent process.

In addition management requires some definition of the expected yield, what is the risk associated with change and in what sequence would the processes be improved. So a basic improvement approach is needed that is part of overall process management.

Process improvement actions and emphasis involve a number of considerations. Improvement starts with adding/removing steps that focus the process on delivering value to the customer either internal or external to the organization. The question you ask is ‘what steps would you add, such as to remove ambiguities, what steps are technical steps and should be moved elsewhere as they don’t add value to the customer and what steps would you remove as redundant, unneeded or not appropriate to a flow?

After that you look at the step inputs and outputs. Again there are questions such as; are there new inputs or outputs needed, should the inputs and outputs be updated? Finally you ask about process governance and controls with questions like, what checks and balances might be needed to assure correct results

?

Once you have an idea of what the target process should look like you need to consider improving the enablers. Here are a few hints on what to look at:

• Start with policies and procedures. What rules should you move to P&P, what rule definition and explanations do you need? Should the rules be included in the process as an automated decision or as part of an executable process? Usually HR and others help with policies and procedures while IT can help make them automated.
• Then consider the systems and related IT infrastructure. What databases, applications, web presence, mobile capability, connectivity, data management, security and compliance issues you need to address? Usually IT helps with this.
• Next you add the skills consideration such as what competency needs are there, what special tool use should you train them on, what positions and education do they need to do the work and so on. Usually HR can help with this.
• Then there is the document and data consideration. What documents should be included either paper or automated such as electronic form.
• Finally you need to consider what business technology might be needed such as mobile devices, in places like warehouses, retail establishments. Technology such as storage systems, scanners, sensors, cameras and other device that may be specific to an industry or government.

What are the key techniques?

Process improvement techniques are not only applied to processes but must also be applied to the enablers. Often an old enabler can slow done or negate an improvement. There are 5 analytical techniques that the improvement approaches support:

1. Discovery – Identifying where there are opportunities for improvement
2. Diagnostic – Identifying where there are problems such as bottleneck or choke points, excessive resource use and so on.
3. Predictive –Anticipate issues and opportunities, verification of process and enabler performance expectations and other outcomes of a process.
4. Prescriptive –Correct or remediate a situation
5. Managing and monitoring – Part of process management continuous process improvement this involves identifying points of process execution that may be out of control. This is much like quality measurement and control charts.

1. Observation – This is the most common approach to improving a process. It is usually done with teams but can be done with a domain expert.
1. What do you use it for? Often used for process maintenance through process reviews. This is a technique used for mainly for discovery and prescription and in some cases for monitoring through review.
2. When do you use it? This is often used as a means of identifying opportunities for improvement through team facilitation, especially when it is a large transformation project. For single process effort it is used by a team assigned to fix and improve the process.
2. Performance – You can look at the performance variables (metrics) for each step of a
process the process overall or a suite of processes.
1. What do you use it for? Quantitative analysis of a process. Classic KPIs. There are many industry oriented KPIs and large libraries of KPIs. These are KPIs that relate to processes either directly or indirectly. This involves discovery of which metrics need improvement. For well-defined or engineered processes like in manufacturing or regulatory compliance it means looking at typical process metrics of cycle time, queue time, transport time, throughput and possibly process cycle efficiency and error rates. There are other metrics such as quality, customer satisfaction, effectiveness measures and so on that can be used especially when dealing with case management
2. When do you use it? When you have access to process metric data such as with a process mining tool, previous measurement efforts or industrial engineering studies.
3. Touchpoint/Context analysis – This approach is used when you want to look at processes relationships and impacts on components of the enterprise.
1. What do you use it for? Development of impact maps that highlight hidden
relationships that might hinder deployment. It is a form of diagnostic and prescriptive technique especially as relates to enablers that support the processes.
2. When do you use it? This technique is diagnostic and prescriptive and in the
situation of hidden process relationships it can be predictive. Very useful for analyzing migration strategies from current to future process and enabler suites.
4. Process Mining – Extracting performance and flow material from database logs
1. What do you use it for? Clearly used for discovery of metrics for processes. Also
used for diagnostics regarding repeated paths or excessive path navigation. Especially useful in certain industries like health care, hospitality and law enforcement to find patterns.
2. When do you use it? When you need process metrics.
5. Policy and Procedure (P&P) – Changes in policies and procedures often point to new processes or changes needed in existing processes.
1. What do you use it for? Used to provide the rules evolving from policy statements. Process rules may be impacted by policy changes. Predictive techniques are used here to assess impact via impact maps.
2. When do you use it? When there are major policy changes resulting in strategic initiatives and changes in organization direction. Used as part of large transformation projects to assess impact of current to future migration issues for related processes.
6. Analytics – Rigorous techniques of analyzing quantitative, monetary and phrase descriptions of processes across an enterprise
1. What do you use it for? These are for diagnostic, prescriptive and predictive situations. Usually these involve ranking process improvement opportunities, assessing impact and comparative analysis for process consolidation.
2. When do you use it? When you need comparative analytics for migration analysis, process rankings, impact analysis. Especially useful for analyzing fit of alternative process consolidation options, merger success probability, acquisition fit and other strategic and operational changes.
7. Business change assessment - impact analysis for consolidation, merger, privatization and other structural process changes across multiple operating units or functions
1. What do you use it for? Assess impact of change to various processes, enablers and related parts of the organization.
2. When do you use it? When you analyze alternative change strategies and initiatives. The goal is to discover and diagnose hidden impacts. Used when you have decided on a series of changes and want to know the impact
8. Simulation- Using estimated values or values from reality to find bottlenecks in a new process
1. What do you use it for? Used for diagnosis of process alternatives, discovery of performance bottlenecks, predictive analysis of process breakdown through stress testing.
2. When do you use it? This approach should be used to verify process design and performance expectations.
9. Process Consolidation – Combining processes to get one simpler, common or federated process to be shared
1. What do you use it for? Most used for reducing and standardizing processes. Such situation happen when federating back office processes, reducing process variation in terms of steps, sharing common technologies and skill sets.
2. When do you use it? Most used when centralizing and reducing an organization to create more profit by reducing process and enabler costs. Also used when there is a desire to acquire a standard package for Enterprise Resource Planning, Supply Chain Management or Customer Relationship Management.
10. Process intelligence – Tracking and monitoring the process performance of the organization.
1. What do you use it for? Identifying when processes are changing performance. This mainly for process monitoring and tracking such as in continuous process improvement, process management and process centers of excellence.
2. When do you use it? When you are reaching a levels 3to 5 capability using the capability maturity management approach (CMM).

The desired outcome for process improvement

The desired outcome is returned value for the process investment. The main reasons for process change are to improve the quality and the efficiency of the process and to align the process with business goals to achieve that value. Applying one or more of the techniques described above provides the insight needed to make changes and align with the goals of the business. Also it is important to keep in mind that you can over analyze something. This is called ‘analysis paralysis’ and results in analysis for analysis sake a situation we all want to avoid.

A well thought out process improvement plan is needed right at the beginning of a process effort to make sure the needs of the business are met. Such a plan sets boundaries and defines when you have just enough analysis to accomplish the purpose of the process project whether it is as large as a complete transformation or just the improvement of one core process with its sub processes and enablers.

SOURCE: bpmandcasemanagement.com

BPMN Tutorial - Part 1 - Simple BPMN Workflow (Business Process Modeling)

Harmon on BPM: Change Management and Human Performance

There are various theories about what constitutes “change management.” The bottom line, in all cases, involves people. When senior managers decide to make changes, they don't care what the machines or the computer systems “think” about change. They care about what the employees, the customers and their business partners think. They worry that customers will decide they don't like the new products and services, or that employees will resist making the changes required for success. Change management is about getting people to support change.

My reading of the Change Management literature suggests that there are, broadly speaking, four approaches, although most theories tend to combine the approaches:

1. Keep everyone informed
2. Work with individuals to overcome resistance
3. Assure that everyone agrees that the new tasks are part of their job
4. Encourage individuals to support the change

Keep Everyone Informed

This rule may seem obvious, but companies and process groups often ignore it. This is especially likely to happen if the company or the process team anticipates that the change will have a negative impact on all or a portion of the staff. If we know in advance, for example, that a change will likely lead to laying off a number of people, there is a tendency to try to avoid communicating that until the last minute. Sometimes this works, but more often people can sense what is likely to happen and they become nervous and upset long before the layoffs occur. In this instance, people resent the change effort and the entire effort suffers. Those who were involved in Business Process Reengineering in the 90s know that BPR came to be widely perceived as something that resulted in major layoffs, and that perception made it very hard for BPR people to achieve their goals of radically improving process improvement performance.

With or without layoffs, employees become nervous when they see that their work is being studied. It's usually far better to start the project by sitting down with those involved in the As-Is process, explaining the goal of the project, and arranging to keep people informed as the project progresses. As a strong generalization, keeping people informed about changes that will likely affect them is the best rule of thumb.

And, of course, it's not just the employees you need to keep informed. No one likes surprises, at least not in a business context. Keeping customers and business partners informed is also important. Moreover, keeping the other processes, and their managers and employees informed about changes in your process that will likely have an impact on them, is just as important.

When a team using the BPTrends Methodology plans a project, they build in a number of meetings that are designed, in large part, to assure that everyone is kept informed on the goals and the evolution of the project's planned changes. Stakeholders are urged to share their thoughts and voice opposition so that everyone knows about potential problems well in advance of any actual process changes being implemented.

Work with Individuals to Overcome Resistance

A second emphasis in change management is on overcoming resistance. Let's assume that it emerges from an early meeting that some of the supervisors involved in the As-Is process are opposed to the type of changes that are being considered. A number of change management techniques are designed to help a process team overcome such resistance. It begins by determining exactly why the individuals are resistant. Some people, for example, are quite skilled using existing tools and are recognized and rewarded for those skills. They fear that a change will obsolete their skills and make them less important. Once this problem is identified, the process team can incorporate training into the transition program to assure that everyone gains the new skills required.

The general theory runs as follows: Individuals seek to secure their own advantage, or at least to avoid becoming disadvantaged. The process team needs to show individuals how the proposed changes will be advantageous to them, or at least show that the changes won't have a negative impact on them. This can't always be done, but it often can, and it's largely a matter of communicating with individuals and determining the exact nature of their concerns.

Assure that Everyone Agrees that the New Tasks are Part of Their Job

Once again, this seems obvious, but is often ignored. In union shops, this can be a very serious problem, but even in a non-union shop, most people have clear ideas about what they were hired to do, or what they are being paid to do, and most resent having their work assignments changed without some kind of negotiation and agreement. Many companies have formal documents, termed “job descriptions” or something similar. These documents define the work expected from a given employee. In the real world there is often some drift that has taken place since the employee was hired or the job descriptionwas written, but most employees have a strong idea about what they regard as a reasonable variation, and what is, in their opinion, an unreasonable change. The rule is simple: you don't make unreasonable changes in someone's job without some kind of negotiation and agreement. You might simply consider this a part of the basic approach that says you must communicate about changes, but it often requires a more formal approach.

If the process team sees that it is moving toward a process redesign that will require major changes in various employee job descriptions, it needs to alert appropriate people – supervisors, human resource people – and draft new job descriptions for the To-Be processes being designed. Then, those job descriptions need to be discussed with the employees who will be affected. Often new training will be required to teach people to use new tools and techniques, hardware or new software. In most cases, some tasks previously performed will be discontinued at the same time that new tasks are being added. If the changes amount to requiring higher level skills, then changes in job status and pay will need to be negotiated and agreed upon. This transition can be especially difficult if the job is being deskilled.

Encourage Individuals to Support the Change

There are lots of theories of motivation, but the approach that works best in business environments is an informal kind of behaviorism. People tend to do more when they are reinforced, they tend to do less when they are not reinforced, and they tend to stop doing things when they are punished for doing them.

The key term in all of this is reinforcement. It takes many forms. A pleasant word or smile can be reinforcing, just as ignoring someone can be punishing. In some circumstances formal recognition can be reinforcing. A post saying that the night shift completed 200 units can be a challenge for the day shift, and the achievement of 201 units by the day shift can be reinforcing. Added vacation time, salary increases and bonuses are also good motivating factors.

I remember a situation in a call center when a new program was introduced to encourage the sale of some additional items that required longer call times to sell. After a couple of months, senior management was concerned that the new items were not selling. Investigation and closer observation revealed that supervisors were tracking the time each sales person spent on individual calls and complained to employees who had call times that exceed the average. In effect, anyone who tried to sell the new items was punished, so the items weren't being sold. In real work environments, rewards and punishments are often mixed, and you need to be sure you understand what is actually going on to understand why a given task is or isn't being done.

Management often postures about not wanting to offer bonuses to staff employees, although no one objects to senior management and salesperson bonuses. If you want something done, you need to be sure that the behavior is reinforced. When CEO, Jack Welch, launched the Six Sigma program at GE in the Eighties, he made 20% of each senior manager's bonus dependent on achieving Six Sigma goals. GE's Six Sigma program became a major success!

Once the process team has designed a new To-Be process, you need to consider what will happen when that process is rolled out. What will happen to supervisors who support the new process? What will happen to employees who work hard to try to make the new process a success? If you really want the new process to succeed, your team had better be sure that the supervisors and employees responsible for the new process get reinforced for making the new process a success.

Too many process efforts are launched with a bit of fanfare, and then gradually fail. In most cases they fail for one major reason – People are confused about the new process, and, worse, are being pressured by managers to solve problems that occur. Frequently, the easiest way to solve many of the problems is to revert to the old way of doing things. This environment, frequently typical of roll outs, doesn't provide any incentives for those who make the new process work. In fact, people take longer to use new and unfamiliar tools and techniques and, at the same time, they feel awkward and under pressure to perform well. Understandably, they may find it easier (and more rewarding) to simply fall back on the old familiar ways.

At this point, it should be obvious that Change Management should be employed at two different stages in the redesign process. You use it at the beginning of the project to socialize the project and establish a clear communication plan. And, you use it, indirectly, during the process roll-out to assure the process is being implemented effectively. Normally, the process team is gone by the time the process is rolled out, so you need to build support for the process into the redesign plan. If you want supervisors to reinforce the process redesign or you want management to pay bonuses for good implementation efforts, you need to establish those requirements and guidelines at the time the redesign program is being developed. And, in some cases, you will need to provide supervisor training, to assure that supervisors effectively support staff employees.

Change Management is one of the keys to a successful business process change initiative. Learning the basics involved and incorporating them into your process methodology will increase your chances for success.

SOURCE: BPTrends

How to Analyze a “To Be” Business Process

Have you been asked to create a “to be” process? Are you wondering what the difference is between “as is” or “to be” process documentation? Wondering if you need both or just one of these types of business processes on your project?

In this article, we’ll define what a “to be” business process is, how to analyze a “to be” business process, and then discuss when it’s an appropriate form of requirements documentation.

(In a companion article, we do the same for “as is” business processes.)

Definition of a “To Be” Business Process

A “to be” business process defines the future state of a business process in an organization. Typically the analysis goal in putting together the future state process is to clarify how the business process will work, at some point in the future, once changes are made. Those changes, as we’ll see, could be technology changes or business process changes.

How to Analyze a “To Be” Business Process

A “to be” business process contains all of the sections in a typical business process model – a description, list of roles, list of steps and exceptions, etc.

(By the way, we address business process analysis techniques in detail in ourBusiness Process Analysis virtual course.)

“To be” business process documentation rarely exists in isolation, nor is it conducted as a stand-alone activity. It is typically one deliverable on the path to creating change within your organization, which means it exists as part of a project.

Since a “to be” process is completed as part of a project, you’ll want to lead a team of stakeholders through the entire business analysis process – starting with getting oriented (perhaps by analyzing or reviewing the “as is” business process documentation, continuing with defining business objectives and scoping the change, and with creating your business analysis plan (particularly important if there is more than one inter-related process to document) and then creating your “to be” process documentation.

These steps might seem overwhelming, but they can be completed relatively quickly to implement a small improvement – perhaps even within one or two very focused meetings. On the other hand, they may happen over the course of several weeks or months for a large scale business process improvement effort that involves supporting technology changes.

When “To Be” Business Process Analysis Is Appropriate

Here are some scenarios when working towards a “to be” or future state business process documentation is appropriate:

• You are working on a project that impacts the business process.
• You are working with a team of stakeholders or subject matter experts toimprove a business process.
• During the roll out of a new technology change, interim business processes are needed to handle special case scenarios, such as active work items received before the change.
• Your technology team has just introduced a new piece of software and the business users don’t know how to use it.
• Your organization is deploying a new product or service and requires one or more new business processes to sell, deliver, and/or implement the service.

In short, if your project creates change, consider creating one or more “to be” business processes to clarify what the change means to the members of the business community. The clarity you create will help the business users embrace the change more fully, enabling your team to create a positive impact within your organization.

SOURCE:  bridging-the-gap.com

Metrics-Based Process Mapping

When It Comes To Social Responsibility, People Think Of Microsoft Before The Red Cross

When asked to name a socially responsible organization, people were more likely to point to for-profit companies like Microsoft and Starbucks than nonprofit charities, according to a recent survey.

For the survey, conducted online, 1,021 Americans were asked to name a company or organization that is socially responsible. The companies that ranked the highest were the ones named most frequently by respondents, and their answers were kind of all over the place.

Leading the pack was Toms, the 9-year-old retailer known for its one-for-one business model -- buy a pair of shoes (or eyeglasses) and the company gives a pair to a child in need.

“Before Toms was founded no one had any idea what a socially responsible company was,” said Heath Shackleford, the founder of Good Must Grow, the marketing consultancy that commissioned the survey. His firm seeks to help socially responsible companies market their causes to shoppers.

Shackleford said the reason some of these for-profit outfits had a higher visibility than the nonprofits could’ve been that the survey focused on questions about companies with charitable missions. Still, he said, he was surprised by the results.

It makes some sense that Starbucks and Whole Foods came out on top -- both are known for progressive policies when it comes to their employees, offering health care and tuition assistance, among other things. And perhaps respondents conflated Microsoft with its founder Bill Gates, who runs the biggest charitable foundation in the world.

Other companies that made the ranking include retail behemoth Walmart and Chick-fil-A, which a few years ago was in the spotlight when its CEO spoke out against gay marriage. The top-ranked charity on the list, the Red Cross, is no stranger to controversy either. It came under fire last year over charges that it put public relations ahead of charitable work.

Still, there's clearly a big knowledge gap around the idea of socially “responsible” organizations. A full 30 percent of the survey respondents couldn’t name a single socially responsible company or business at all.

SOURCE: Huffington Post

Webinar: What is Continuous Improvement? What you Should Know about Lean

Feral Leadership Drives the New Social BRM

Enterprise IT will require a new set of "social skills" that reflect the evolution from analog to digital corporate cultures.

Business Relationship Management (BRM) was never easy for central IT in the first place. But the frenzy for enterprises to define and craft a "digital strategy" at the corporate level has added a whole new dimension to IT's relationship with the business.

Unfortunately most current BRM strategies are a legacy of dated analog business models. As such, they focus disproportionately on traditional interactions between constituents when relationship building and collaboration are increasingly occurring on internal and external social platforms.

This is creating the need for what I refer to as the emergence of Social BRM that is driven by a "feral" leadership style; one where enterprise IT leaves the HQ "cage" and returns to the wild where the customers roam.

I would like to reinforce in no uncertain terms that Social BRM is not a replacement for traditional communications, collaboration and relationship building skills. However, the fact is the proportion and variety of social communications channels in businesses have increased exponentially at the expense of some of the more traditional formats.

Social BRM has three key goals:

1. To increase the efficiency and effectiveness of internal communications within central IT using digital communications strategies.
2. To improve the efficiency and effectiveness of digital communications between IT and business unit partners, vendors and customers.
3. To serve as a departmental branding proof point. As a result enterprise IT will be seen as having the "social skills" and street-cred necessary for partnering on deployment of internal and external social enterprise initiatives.

So what action steps can the feral CIO take to initiate a culture of Social BRM?

First, study the business units' communications styles on the current social enterprise platforms (Yammer, Chatter, etc.) to determine their digital engagement baseline. You may have a better chance starting your Social BRM strategies as a joint venture with divisions that are less socially mature. You can then jump in later with more socially sophisticated business units after gaining confidence and credibility with other digital immigrants.

Next, begin to embed social media communications strategists within enterprise IT in the same way marketing embeds shadow IT. While this may seem like a luxury today, it will serve as an insurance policy against irrelevance as HQ builds a corporate digital strategy that will surely require Social BRM skill sets.

CIOs must be cautious not to confuse a preponderance of socially-savvy millennials in their organization with a Social BRM strategy. The fact that a staffer has personal "vanity metrics" like a thousand Facebook friends or Twitter followers by no means translates into an ability to not only to enable, but to facilitate communications within and across enterprise cultures.

Next, send a signal that the Social BRM strategy is led by the CIO. This can be as simple as becoming the face of a meaningful and thought provoking blog or community on critical IT issues within the business units. IT will increasingly be required to stimulate ongoing digital conversations and this can not be outsourced to the corporate marketing communications department. This is a twenty-first century version of IT needing to "publish or perish."

Thinkstock

Finally, you can go totally feral and establish a collaborative dialogue directly with the company's customers. I've experienced this in my work as a researcher at CSC where Chief Innovation Officer Dan Hushon launched the CrowdChat platform to establish unfettered collaborative communications between technologists and CSC customers.

To what extent has your job required an increase in Social BRM skills? Have you had to embed new staff that possesses these skills or have you been able to teach the old dogs new tricks?

SOURCE: CIO.com

Project Management Approach for Business Process Improvement

Overview

Business process improvement initiatives are frequently key projects within an organization – regardless of the size of the organization or, frankly, the size of the business process improvement initiative. Even if a business process improvement initiative is targeted at an individual department, the impact of the change will be organization-wide. By ensuring that the initiative is managed as a strategic project, there are increased opportunities for success.

Process improvement initiatives are continuous. As organizations grow, they need to continuously analyze and refine their processes to ensure they are doing business as effectively and efficiently as possible. Fine-tuning processes gives an organization a competitive advantage in a global marketplace.

Process improvement is a strategy and a tool to help an organization meet its long term goals and objectives. One key goal for all organizations is to meet the demands of their clients – both internal and external. Clients’ needs change – whether due to economic factors, new product introductions, mergers or acquisitions, expansion or contraction. Continuously reviewing processes for potential improvements and efficiencies enables companies to adapt effectively to their clients’ changing needs.

Sometimes improving one process may inadvertently have an adverse affect on other processes. For example, let’s say a company changes its sales order processing. Once that process is improved, it becomes apparent that the improvement in that process has created a backlog in order fulfillment in the manufacturing department. A project management approach would address such issues as part of the risk planning, and the order fulfillment process would have been reviewed as an extension of the sales order process. Or, the initial project would have been assessed to determine if making changes to the sales order process would be beneficial to the company as a whole, given investments needed for other parts of the company.

The following graphic depicts a lifecycle of a process improvement initiative:

Although a project has a defined beginning and a defined end, in this graphic we are depicting a cyclical environment for continuous improvement. While this may be confused for ongoing operations after deployment of the initial process improvement project, it should, rather, be looked at as a separate project for each cycle of improvement. While monitoring is operational, once a need for improvement is recognized; a project with a defined beginning and a defined end and with set goals and objectives is established.

When process improvement initiatives are formally undertaken, by a project team led by an experienced project manager (experienced in process improvement-type projects), the following high-level overview steps will likely comprise the project work:

• Documenting the current process to be analyzed.
• Measuring the current process (gathering metrics) and developing a baseline. Metrics may be customer-based or organizational-based.
  • Customer-based metrics may include:
    • Customer satisfaction
    • Service level
    • Time to market
    • Accuracy of customer orders
  • Organizational-based metrics may include:
    • Utilization of resources
    • Manufacturing line utilization
    • Cost per unit for development
• Validating the documented current process and ensuring metrics are baselined appropriately.
• Setting new metrics for the process based on organizational long-term goals – e.g., one improvement may be to go from 85% customer satisfaction to 93% customer satisfaction over a 9 month time period or to reduce cost per unit from $25 per unit to $15 per unit over a one year time period.
• Analyzing the process as documented to make improvements.
  • This, along with documenting a process, can be the most significant amount of time on the project.
• Design and develop changes to the process to ensure improvements as desired.
• Validate the design to the process.
• Implement the new process change.
• Review and measure the results of the new process change.
  • Measure against baseline metrics in a designated time period.

Overview of a Case Study: Process Changes for a Manufacturing Company

This paper will provide a high level overview of a case study of a manufacturing company that saw the value in taking a project management approach to a process change initiative.

Overview

Company XYZ has been aware that their production of widgets will not continue to satisfy clients’ demands. They have seen an increase of 10% year after year for widgets over the last 5 years with no end in sight for the increase in demand. The CEO had asked an internal team to review current manufacturing processes and propose changes to the processes, along with upgrades to equipment to meet the demands for the future. When the team’s proposal was submitted to the CEO, it recommended an upgrade to manufacturing equipment and a redesign of the production line with no solid metrics relating to the number of anticipated increases. Also missing (and critical to the outcome) was an analysis of what would happen in procurement, delivery, as well as warehousing, if these changes were made to the manufacturing process, and whether these departments would be able to manage those changes. After seeing such deficiencies in the team’s plan, and with past experiences in such projects at another company, the CEO chose to engage a project management consulting company, ABC Projects, to outline a project plan for this initiative. ABC Projects specialized in process improvement initiatives. The CEO knew that these efforts were more likely to be successfully implemented when run as a well-managed project.

The Project Plan

ABC Projects outlined a project plan with tentative timelines and cost ranges until discovery was completed. The project plan included the discovery and identification of needs for increased production, as well as identification of affected departments and/or processes if the increase in production were carried out.

ABC Projects knew from experience that other areas besides the manufacturing line would be affected. For example, procurement had a set budget for purchases. The expenditure necessary for materials that were not ready to be used in manufacturing would wreck havoc on cash flow and require consideration of how to store materials until they are ready to be used by manufacturing. Further, additional vendors from which to purchase the materials would need to be identified, should the current vendors be unable to meet procurement’s increased demands. Alternative vendors needed to be in place before any supply issues arose. It was evident that the processes for procurement must be very closely integrated with the manufacturing processes to maintain an ongoing flow of materials to production.

The project team developed a detailed plan for identifying the stakeholders and how they would proceed to gather the data necessary to accurately document the manufacturing processes. The plan included a detailed list of questions to ask each stakeholder to ensure that all interviewers asked the same questions and gathered the same data. The project team knew from experience that documenting processes required a thorough understanding of the business, because, when being interviewed, individuals often unintentionally skipped relevant details. Thus, experienced people were required to extract information needed for an accurate and detailed documentation of processes.

The project team also developed a plan for potential risks and strategies for managing them should they come to fruition. They wanted to be sure that once they determined the options for making changes to the manufacturing processes, that they could accommodate potential changes to other processes. They knew that changing one process would likely have a domino effect throughout the company. For example, during one of the scenario planning sessions, the project team found that if procurement was unable to fulfill the material needs of manufacturing from one vendor, without a back up vendor in place, there would potentially be a shortage of materials which would cause a delay in production or costs would increase by at least 30%. This would be unacceptable and would ultimately cause customer dissatisfaction which could lead to a loss of business to competitors.

The team also put together a change management plan; because a major component of the project would be communicating changes company-wide and ensuring the appropriate people were on-board and prepared to work with the new processes. Additionally, the project team needed the individuals involved on the production line to be willing to test new processes as well as new equipment with no interruption in meeting current client demand. Without support from these individuals, this would be an impossible task and one that had a high potential of risk associated with it.

Additionally, the project team sent out a company-wide communication so that employees knew what was happening and why, and they asked for suggestions from employees. By getting the input of the individuals who were doing the job day in and day out, they increased the likelihood of success on the project.

The Work Breakdown Structure included several milestones to allow the company to move forward with working with new processes and upgrades to equipment without interrupting the current production schedule. At each milestone, there were several tasks for measuring progress and comparing it to expected results and baselines. Assessments were completed regularly to ensure the current plan held true to the objectives. At any point during the project, if the assessments showed deficiencies from the objectives, then an evaluation of the process design and, if necessary, a correction occurred. The Work Breakdown Structure included training time to get individuals up to speed on new equipment.

The Risk Management Plan included contingencies should current employees be incapable of learning the new equipment and performing their role in a timely fashion. Part of the contingency plan was to use employees who adapted quickly to the new equipment on the new production line and maintain the old production line with employees who learned less quickly, until they were able to get up to speed. An integrated team concept, including mentoring, was put in place to assist people in getting up to speed on new equipment.

Regular status meetings were scheduled with manufacturing, procurement, delivery and other departments to maintain lines of communication and general awareness of the project status. These meetings also served to ensure that employees were comfortable with change and were able to participate in decisions that would affect how they perform their job.

Project Results

Prior to undertaking the project, Company XYZ was producing 250 widgets per day. At the time of the undertaking of the process improvement initiative, client demand had just reached 250, and demand had increased by 10% annually over the last five years and it appeared that the increase would continue for the foreseeable future.

The directive from the executives was to improve manufacturing processes through changes in processes as well as upgrading equipment, toward a goal of producing up to 400 widgets per day. Based on current projections, the company would experience a five year timeline before having to undertake another increase in production to satisfy growing client demand. At that point, if client demand continued to increase, the company would be in a better position to invest in another manufacturing site in order to meet demands after the five year mark.

Additionally, in the current production line there was, on average, a 3.6% defect rate in widgets produced. One of the directives specific to this project was to attempt to reduce this defect rate by at least half within the next two years.

The following were discovered during the project:

• Capacity for procurement was limited due to cash flow and budgetary issues, as well as storage. Any new process needed to take this into consideration once production increased and would have to allow for a smooth flow between procurement and manufacturing.
• It became apparent that once the number of widgets manufactured increased, demands on warehousing and delivery would increase accordingly. A plan was put in place to change warehousing and delivery processes to reduce the strain on these functions.

The project had run slightly over the projected timeline, but did remain within budget. The increase in the timeline resulted from an underestimate of the space required to store manufactured widgets prior to delivery. This occurred to a great extent because the decrease in the defect rate was .06%, significantly exceeding the goal of 1.8%, thus causing an increase in the number of widget units to be stored. Although this was not anticipated in a contingency plan it did not cause the executives to be unhappy. It was a good problem.

Summary

A project management approach enabled the company to meet their production needs for the future, while at the same time not disrupting their current production to fulfill client demand. There was never a glitch in the production line while new processes were being tested and evaluated. Continuous communication ensured that everyone was in the loop on changes to processes and actually had the benefit of increasing participation from employees on how to improve processes to better meet client needs. Additionally, continuous review and adjustments to the risk management plan ensured that the end result was well thought out and tested and ensured that any glitches in proposed changes were caught immediately and could be addressed.

Adhering to a standard project management methodology enabled this company to implement a very high risk project efficiently, on budget and within reasonable time to meet long term strategic goals.

SOURCE: Ginaabudi.com

Transitioning to a World of Decisions

As the concepts of decision modeling and management increasingly move from theory to practice, it has been interesting to note how it is perceived and approached by both business and IT. Perhaps not surprisingly, my experience has shown this to be a smoother transition for business. This is something we should expect as it presents a more natural representation of the business for the business. The IT side has certainly had a variety of tools available in numerous platforms to support this approach and the emergence of the Decision Model and Notation (DMN) standard now brings a cohesive view across industries. However, it does seem to present a few challenges to IT in this early stage of evolution.

The two challenges that seem to be most prevalent are the structure of rules within a decision and testing decisions/rules. I will only briefly discuss the former here as it is worthy of its own discussion in far more detail. The core issue is the reliance on decision tables as the sole representation for rules within a decision. Those who have worked with business rules over the years know that nearly all BRMS platforms provide a variety of metaphors for rule expression – IF/THEN rules (both technical and in business friendly language), decision tables, decision trees, workflows, etc. The guiding principles in choosing a rule representation have usually focused on performance and providing an appropriate and understandable business expression. I (and, I believe, many others) have always strongly believed there is no “one size fits all” methodology. Trying to force a square peg into a round hole by using only one form of rules can result in unnatural representations, an explosion in the number of rules, and occasional performance issues. To date, the projects on which we’ve been involved have used the following guiding principle: try for decision tables first but do not hesitate to move to other expressions where it makes sense. We’ve generated more precise guidelines for making this decision in a consistent fashion. These will be the topic of a future paper.

That brings us to testing. IT often tends to dive into the details and work from the bottom up. For decision testing, this implies an initial focus on individual rules. Most platforms have a number of tools available to facilitate this task (e.g., tools that stop you from generating an ill-formed or incomplete rule). Unit testing of rules often considers two types of testing:

• Positive Testing
  • A rule will fire when all the conditions on the “IF” side are satisfied
• Negative Testing
  • A rule will not fire when the conditions on the “IF” side are not satisfied.

Negative testing occurs implicitly as testing that an individual condition being false would cause the rule to not execute would be testing that the rule engine itself works as specified, and not the actual rule itself. There are a number of well-known best practices here and this process should be relatively straightforward.

Business, of course, doesn’t really care that an individual rule works. They want to know whether or not the decision rendered is correct. “Scenario” testing in some context has been an integral part of testing a rule system and, again, most BRMS platforms have supported it in some fashion. At one point it was often rolled up into a very large, general category of “system” testing. The emphasis on decisions now casts this in a more significant light.

Scenario testing validates that the rules as a complete rule set (or decision) provide the proper results when executed. This approach is necessarily a joint effort between IT and business. As the rule set constitutes a decision point or service, the interface signature can be accessed in a variety of ways to send input and receive output data. However, I believe it is absolutely critical for business to provide the input data and expected results. IT may suggest the scenarios (decisions, sub-decisions) that need to be tested and even provide input on the data variations needed to exercise various paths through the decisions. This last point is where I’ve seen the major disconnect happen on projects. Business often has an attitude of “it’s your code, you test it”. While IT should do the actual testing here, they should not be the ones determining what the valid business scenarios might be for a particular decision(s). Working as a team is the only way to ensure a quality decision implementation.

There are a number of very basic guidelines to keep in mind when doing decision/scenario testing.

• Scenario testing verifies the behavior of a decision as a component, rather than an individual rule.
• Scenario testing executes scenarios with a full set of input data (as opposed to what might only be minimally necessary to execute a single rule).
• Scenario testing must use realistic data similar to what will actually be processed when rendering a decision. This may often be historical data from similar systems that are currently in place.
• Decision testing data should not be prepared by the IT development team. It is ideally prepared by the business owners. This is to ensure that the data is truly representative and that the expected results are what the business expects (and not just what the development team has inferred is correct).
• Actual testing results should be compared against the expected results. The expected results should be persisted as part of a regression test suite that can be used later to validate correct functioning after any changes that might be made.

I fully expect this list to continue evolving as we become more experienced as a decision management community.

SOURCE: BPMInstitute