SIPOC Diagram

Many recent inquiries and discussions have focused on the SIPOC diagram – a tool used in the Six Sigma methodology. Because of the interest level, a further explanation is presented here along with a sample and template for your use.

A SIPOC diagram is a tool used by a team to identify all relevant elements of a process improvement project before work begins. It helps define a complex project that may not be well scoped, and is typically employed at the Measure phase of the Six Sigma DMAIC (Define, Measure, Analyze, Improve, Control) methodology. It is similar and related to process mapping and ‘in/out of scope’ tools, but provides additional detail.

The tool name prompts the team to consider the suppliers (the ‘s’ in SIPOC) of your process, the inputs (the ‘i’) to the process, the process (the ‘p’) your team is improving, the outputs (the ‘o’) of the process, and the customers (the ‘c’) that receive the process outputs. In some cases, requirements of the customers can be appended to the end of the SIPOC for further detail.

The SIPOC tool is particularly useful when it is not clear:

◉ Who supplies inputs to the process?

◉ What specifications are placed on the inputs?

◉ Who are the true customers of the process?

◉ What are the requirements of the customers?

Sample SIPOC Diagram

A SIPOC diagram is a tool used by a team to identify all relevant elements of a process improvement project before work begins. It helps define a complex project that may not be well scoped, and is typically employed at the Measure phase of the Six Sigma DMAIC methodology.

Steps to Complete the SIPOC Diagram

SIPOC diagrams are very easy to complete. Here are the steps you should follow:

1. Create an area that will allow the team to post additions to the SIPOC diagram. This could be a transparancy (to be projected by an overhead) made of the provided template, flip charts with headings (S-I-P-O-C) written on each, or headings written on post-it notes posted to a wall.

2. Begin with the process. Map it in four to five high level steps.

3. Identify the outputs of this process.

4. Identify the customers that will receive the outputs of this process.

5. Identify the inputs required for the process to function properly.

6. Identify the suppliers of the inputs that are required by the process.

7. Optional: Identify the preliminary requirements of the customers. This will be verified during a later step of the Six Sigma measurement phase.

8. Discuss with project sponsor, Champion and other involved stakeholders for verification.

SIPOC Templates

The following SIPOC templates are for immediate download and use. The Adobe Acrobat version allows you to print and input your SIPOC information by hand, perhaps by overhead. The Microsoft PowerPoint version allows you to input your SIPOC information and print.

Adobe Acrobat (.PDF)

Microsoft PowerPoint (.PPT)

Continue reading

Use Pareto Tables to Manage Large Data Sets

Pareto analysis is an excellent way to find the most compelling drivers or root causes of a problem you want to solve. A Pareto chart generally looks like Figure 1 below, which can be easily generated by any number of charting tools, such as Microsoft Excel.

Figure 1: Pareto Chart of Root Causes of Failure for Process X

Challenges of a Pareto Chart

With some large data sets, however, there may be a large number of categories or root causes, making the display of these root causes in a chart form difficult. A Pareto chart format is not always feasible. For example, a service desk may create incident tickets for every incident and call that comes in. For each of these tickets, the fix agents will categorize them using a category, sub-category and even a further breakdown of the sub-category. If they wish to perform a Pareto analysis of all combined categorizations of incidents, they could have several hundred groupings. A Pareto chart of this data would not fit on a single page.

Enter the Pareto Table

One easy and highly visible alternative to the Pareto chart is to use a Pareto table. A Pareto table houses the same data as a Pareto chart but can display several hundreds or even thousands of rows of categories. Analysts can see at a glance which items are the primary drivers and can develop improvement plans to address the most impactful culprits. The following is a real-world example of a Pareto table, using service desk ticketing data (category names modified for data protection purposes).

With the category, sub-category and configuration items combined, the Pareto table has 626 groupings. The analyst collated the three levels using a concatenate function in Excel. He then created a pivot table that tabulated the groupings that drove the most tickets. Only a few rows from the top and bottom of the table are displayed below. You can see by looking at the first few rows that the first twenty of the 626 groupings represent over 80 percent of the nearly 35,000 tickets.

Pareto Table for Service Desk Ticketing

7 Steps to Creating a Pareto Table

There are seven steps you need to take to create a pareto table for large data sets.

1. Collect data. Gather the data from a ticketing system, data warehouse, etc. The data may come in many formats.

2. Identify groupings/root causes to measure. The data may have a field that contains the explicit grouping to analyze. However, an analyst may wish to combine data elements to reveal more compelling aspects of the data, like the combining of category and sub-category referenced above.

3. Create a pivot table of counts by grouping/root cause.

4. Sort the pivot table from highest count to lowest.

5. Identify the total count of data items. For example, in the case of service desk tickets, the total count of data items is the total count of tickets (34,967) – each of which has a combined category, sub-category and configuration item.

6. Calculate the percent of total tickets each grouping represents. Use the following formula:

7. Calculate the cumulative percentage. This is the sum of the individual percentages from the first row in the Pareto table through the current row in the table.

Seven steps are all it takes to complete a Pareto table and get a rapid view of the most compelling drivers of your data. An analyst can perform these steps using any number of spreadsheet tools.

What a Pareto Table Tells You

Once the information is visible in this format, the Pareto table clarifies many mysteries housed in the data. Teams can quickly see which items of focus will bring the most value to the improvement efforts. For instance, in the example of the ticketing system from the table above, if teams focused on the top six items (only 1 percent of the total tickets) and made a 50 percent improvement to those six groupings they would reduce the total ticket count by over 30 percent (from 35,000 to 24,000) for future periods.

A Pareto table is an ideal tool in the Measure and Analyze phases of a Six Sigma DMAIC (Define, Measure, Analyze, Improve, Control) project as it helps teams to quickly ascertain primary drivers. It is also extremely useful in the Control phase. Teams may wish to perform a monthly Pareto analysis to ensure improvements remain. Groups may even want to write some automation to dynamically generate a Pareto table and send auto-notifications when categories are out of the desired range.

Next time you encounter large data sets with many groupings, try using a Pareto table to quickly analyze the data and see what serendipitous revelations come to light. You may be pleasantly surprised with the enigmas you unravel with this rapid data-slicing tool.

Continue reading

PRINCE2® vs Agile or PRINCE2 Agile®?

There's a lot of confusion between PRINCE2 and agile methods, and indeed debate (PRINCE2 vs Agile) about which should be used on projects. In fact, both can and are being used increasingly on projects – often together.

In 2015, AXELOS, the owners of PRINCE2 launched PRINCE2 Agile. PRINCE2 Agile is an attempt to get the best of both worlds – the structure and governance of PRINCE2, combined with the flexibility of agile.

This article compares PRINCE2 and agile methods and approaches and explains how PRINCE2 Agile can bridge the gap between the two.

PRINCE2 vs agile

PRINCE2

PRINCE2 is the world's most widely used project management methodology. PRINCE2 qualifications are a standard feature of project management job specifications in the UK and have grown in popularity since PRINCE2 was launched in 1996.

Currently, over 150,000 PRINCE2 exams are sat somewhere in the world every year.

Agile

‘Agile’ is an umbrella term used to refer to numerous product development methods, frameworks and techniques used by development teams.

Agile approaches emerged from the software industry in the 1990’s, to try to overcome many of the problems which had beset traditional software projects, namely: late delivery, over budget, and low quality.

There are many different agile approaches, the most famous being Scrum, Kanban, Extreme Programming, and Lean. All agile approaches are based upon the 12 agile principles.

Who is PRINCE2 for?

PRINCE2 is a customer-focused project management methodology. It offers a set of principles, themes and processes to enable an organisation’s key managers to justify a project. It helps them understand “why should we do it (the project)?” and “are the benefits worth the costs and risks of doing the project?”. It also focuses on how to manage a project effectively to ensure it remains a worthwhile investment in a changing business environment.

PRINCE2 was developed by the UK government in 1996 as a generic project management methodology.

Focus of PRINCE2

Principles

PRINCE2 is based upon a set of 7 principles which guide all aspects of the methodology.

Since it is a project management methodology, it describes the roles and responsibilities of all members of the project management team. This includes higher levels such as the project board, as well as the project manager and team manager roles.

Themes

It also covers a wide range of key project management themes – business case, organization, change, risk, planning, quality and progress. Success on a PRINCE2 project is measured by how well it enables the benefits to be realized by the customer organization.

Processes

PRINCE2 also includes a full project management lifecycle which explains which role is responsible for taking key decisions at crucial times during a project.

PRINCE2 recognizes that on projects there are all kinds of products (outputs) which are produced by teams of people with various specialist skills. These teams have myriad ways of working and PRINCE2 does not attempt to guide how they should work.

Instead, PRINCE2 simply defines the interface between the project and these teams in terms of reporting, accountability and the work to be done.

Who is agile for?

History of agile

Agile approaches were developed by engineers in the software industry in the 1990s when trying to address problems with software projects being consistently late, over-budget or delivering low quality software.

Agile approaches are now increasingly being used in industries besides the software industry.

Focus of agile

Agile approaches don’t concern themselves with the wider questions about whether a project is worth it, or whether the benefits can be realized afterwards. They do focus however on delivering value to the customer by delivering products incrementally, in the most efficient manner possible.

These products are likely to do what the user/customer needs because the customers have been involved in a constant cycle of defining and prioritizing requirements, developing, testing and providing feedback.

Delivery of working products

Agile methods are aimed at the teams doing the work - whether part of a project or not. They focus on questions for the team such as ‘what needs to be delivered next week?’, and ‘is the working software what the customer needs?’

Collaboration

One of the agile principles is that people on teams must work together collaboratively with the customer. This is done by defining and prioritizing requirements, developing, testing and providing feedback in a continuous and repetitive cycle of iterations. Often, the customer will be co-located with the development team.

Self-organisation

Self-organisation by teams is also one of the agile principles. Agile teams determine their own tools and techniques to use (e.g. task backlogs, burn-down charts, Kanban boards), rather than these being mandated by a project manager.

Comparing PRINCE2 and agile

Planning

One key difference between PRINCE2 and Agile methods is that PRINCE2 is often described as a predictive (plan-based) approach, while Agile calls for short-term, incremental achievements independent of an over-arching plan (the adaptive approach).

This means that, while PRINCE2 enables the customer to remain focused on the project’s original business goals, Agile approaches are very responsive to changes in the project environment and customer requirements.

Agile approaches operate on the assumption that the development process is (predictably) unpredictable. They encourage complete transparency, close collaboration and frequent delivery of usable sub-products that will eventually contribute to the final product delivered.

Levels of plan

PRINCE2 has the concept of ‘levels of plan’. This suggests that different plans are required by different levels of the project management team. There are 3 levels of plan in PRINCE2:

◉ Long-term – this is a high-level project plan which is required by the key decision-makers (the project board);

◉ Medium-term – this is a stage plan required by the project manager for every stage of the project;

◉ Short-term – this is a team plan required by each team manager (leader) to cover the work done by their team. This is a detailed plan.

Sprints and timeboxing

Agile approaches such as Scrum, take this concept even further by suggesting a detailed plan for each ‘sprint’. A Scrum sprint is based upon the key Agile concept of a ‘time-box’ - a fixed time period typically ranging from between 1-4 weeks.

Delivering working products

At the end of every Scrum sprint a delivery of working software is made to the customer. Delivering working software at the end of each sprint guarantees that the software will never be delivered late.

The customer receives ever increasing increments of working software until, at the end of the final sprint, they receive the fully built and tested system.

Time-boxes and team plans

The agile concept of time-boxes or iterations fits in neatly with PRINCE2’s concept of a team plan because there can be one or more time-boxes within a team plan.

PRINCE2 doesn’t prescribe how many time-boxes a team plan should contain because that’s a decision for the self-organizing Agile team members.

Responding to change

Cost of change

One criticism of more predictive project management approaches is that it is difficult and costly to manage changes. Changes are managed through formal change control processes, and decisions taken by a change authority.

In agile approaches, changes can be done quickly. This is because customer requirements (e.g. software features) are described by the customer in the form of tasks which are prioritised in a backlog.

Because planning is never done further in advance than the next iteration (1-4 weeks usually), tasks can be quickly re-assigned a different priority, new tasks added, or unnecessary tasks removed.

PRINCE2 doesn’t have to be waterfall

There is a perception (wrong in my view) that PRINCE2 struggles to adapt to changing business requirements.

This view is based upon the assumption that PRINCE2 is a project ‘waterfall’ approach. A waterfall approach is where requirements are documented and approved before moving to a design phase, followed by a build phase and finally a testing phase.

There is nothing in PRINCE2 which prescribes such a waterfall approach. In fact, the latest PRINCE2 manual (2017) assumes that on many projects, requirements emerge and evolve as the project continues.

PRINCE2 manages such changes to project scope using its change control approach. However, lower level changes, such as a feature requests can easily be managed at the team level using the prioritization techniques common in agile approaches.

Using both PRINCE2 and Agile

The best of both worlds

Whereas PRINCE2 focuses on understanding what products are required to support the business needs, agile focuses on completing those products in an efficient manner, incrementally delivering more working software (products) as the work progresses.

Utilizing agile approaches on PRINCE2 projects therefore can bring the best of both worlds – the structure and direction of PRINCE2, coupled with the flexibility and responsiveness of agile.

PRINCE2 isn’t concerned with how teams organize or the methods they use. It does however define a simple interface between the customer organisation which is paying for the project and the supplier organisation which provides the teams to do the specialist work.

Business focus and timely delivery

This therefore means that teams on a PRINCE2 project can use any development approach they choose – including any of the agile approaches. Providing they comply with the interface defined by PRINCE2, teams can utilize the benefits of agile (such as on-time delivery), whilst the customer maintains the benefits of PRINCE2’s focus on the business justification.

Quick comparision of PRINCE2 and agile

PRINCE2	Agile methods
Useful for the customer to justify a project	Useful for the supplier to deliver working software
Focuses on higher management levels	Focuses on lower-level teams
Answers questions such as “should we do the project?” and “are the benefits worth the costs and risk?”	Answers questions such as “what do we deliver next week?” “how will we know it (a product) is finished?”
More predictive approach	More adaptive approach

PRINCE2 Agile

In 2015, in recognition that many people were struggling to find a way of applying PRINCE2 on agile projects, AXELOS launched PRINCE2 Agile.

PRINCE2 Agile at its core is essentially the same as PRINCE2. They both rely upon the exact same principles, themes and processes. The only real difference is that the PRINCE2 Agile guidance explains in detail how to tailor these elements for agile projects.

Fix or flex?

In particular, PRINCE2 Agile explains what to ‘fix or flex’ for the 6 performance targets of PRINCE2 (time, cost, quality, scope, risks, benefits).

For PRINCE2 Agile, time and cost are fixed. These cannot change. However, in order to be able to deliver what the customer truly needs, scope and products’ quality criteria can be flexed.

What to flex has to be agreed with the customer. Typically, this is done using Agile prioritization techniques such as MoSCoW, coupled with sprint backlogs.

The other 2 performance targets (benefits and risk) may be either fixed or flexed depending upon the customer’s needs.

Source: knowledgetrain.co.uk

Continue reading

Change Enablement in ITIL 4

Change enablement is a very critical service management practice within ITIL. It is here that we can introduce improvements in services as well as other service management practices.

A change is defined as the addition, modification, or removal of anything that could have a direct or indirect effect on services.

This would typically include changes to IT infrastructure, applications, documentation, processes, supplier relationships, and any other critical components of the service. Although some IT organizations limit their focus only to hardware and software change enablement, it is important to remember that other elements play significant roles in service development and delivery, and changes to them can negatively impact customers.

What is change enablement?

The purpose of the change enablement practice is to maximize the number of successful IT changes by ensuring that risks have been properly assessed, authorizing changes to proceed, and managing the change schedule.

The distinction between change enablement and organizational change management is important. While organizational change management manages the people aspects of changes to ensure that improvements and organizational transformation initiatives are implemented successfully, change enablement usually focuses on changes in products and services.

Change types

In ITIL, we usually identify three types of change that are each managed in different ways i.e. standard, normal and emergency changes.

Standard change	A low-risk, pre-authorized change that is well understood and fully documented, and can be implemented without needing additional authorization. Is often initiated as a service request, but may also be an operational change. Requires a full risk assessment and authorization only during creation, or modification due to business change or occurrence of an incident.
Normal change	A change that needs to be scheduled, assessed, and authorized following a standard process. Involves change models based on the type of change determine the roles for assessment and authorization i.e. low level changes require local (team or supervisor) authorization while high level changes may require board level authorization. Initiation is triggered by the creation of a manual or automated change request.
Emergency change	A change that must be implemented as soon as possible without strictly following the standard process e.g. to resolve an incident or implement a security patch. The process for assessment and authorization is expedited to ensure quick implementation, so scheduling and documentation is not a priority. The change authority may be separate from what is standard or normal practice, typically smaller in number but with greater capacity to expedite approval.

Change authority

The change authority is defined as a person or group who authorizes a change. This can be a team, supervisor, manager, CEO, board, customer or regulator depending on the nature of the change as well as the organizational approach and culture. It is essential that the correct change authority is assigned to each type of change to ensure that change enablement is both efficient and effective. There is no point constituting a board to review every relatively low risk change that can be locally approved.

In high-velocity organizations, it is a common practice to decentralize change approval, making peer review a top predictor of high performance. For example, an agile product team would make decisions on which elements of the product backlog will be tackled in a sprint, while the agile product manager would make decisions on which customer requirements would be included into the product backlog. Organizations adopting DevOps practices might establish systemic approval based on the success of automated checks in the continuous integration/continuous deployment (CI/CD) pipeline.

Change communication

Regardless of who the change authority is, they may need to communicate widely across the organization as well as to key stakeholders. It is important to prepare all persons involved and all persons affected in advance to prevent surprises. Good communication with the Service Desk, for example, may be important to ensure that high call volumes do not come as an unmanageable surprise following a change that went wrong. Marketing teams might wish to avoid planned campaign activity at a time when key systems are expected to be unavailable. Good communication is also particularly important where a large cross-section of persons with specialist knowledge are needed, for example when assessing the risk of a complex change.

The change schedule is used to help plan changes, assist in communication, avoid conflicts, and assign resources. It can also be used after changes have been deployed to provide information needed for incident management, problem management, and improvement planning. It is important to expose the change schedule to all key stakeholders involved in the changes, through communication channels which are likely to get the message to them in a timely manner.

Contribution of change enablement to the Service Value Chain

The change enablement practice is involved in all the activities of the service value chain as shown below:

Plan	Changes to product and service portfolios, policies, and practices all require a certain level of control, and the change enablement practice is used to provide it.
Engage	Customers and users may need to be consulted or informed about changes, depending on the nature of the change.
Design and Transition	Many changes are initiated as a result of new or changed services. Change enablement activity is a major contributor to transition.
Obtain/Build	Changes to components are subject to change enablement, whether they are built in house or obtained from suppliers.
Deliver and Support	Changes may have an impact on delivery and support, and information about changes must be communicated to personnel who carry out this value chain activity. These people may also play a part in assessing and authorizing changes.
Improve	Many improvements will require changes to be made, and these should be assessed and authorized in the same way as all other changes.

Source: bmc.com

Continue reading

8 Basics of Lean Six Sigma for Manufacturing Firms

In the efforts to draw closer to customers, many manufacturers have lost focus on what should be a company’s primary success factor – profitable growth. In today’s competitive manufacturing environment, it takes more than quick fixes, outsourcing and downsizing for companies to consistently achieve their growth and profit objectives. While these options may yield temporary financial relief, they will not lead the way to long-term growth and profitability. For companies to grow and consistently exceed bottom line expectations, they need to get lean. And to get lean they should master eight basics of Lean Six Sigma.

Software as the Solution

Companies were led to believe that computerized systems would provide the solution to all growth and profit challenges. Material requirements planning (MRP) and enterprise resource planning (ERP) system gurus assured organizations that if that implemented their software programs the bottom line would take care of itself. Well it did not happen. Like most perceived panaceas, each of these programs received a lot of hype, but, in general, contributed little toward helping companies identify and achieve their full growth and profit potential.

For a measure of their shortcomings, one needs only to spend some time in an MRP scheduled manufacturing facility – especially during the last weeks of the final financial quarter. In a typical company, converting the quarterly financial forecast into reality still requires overtime, internal/external expediting, last minute on-the-run product changes and even some smoke and mirrors from time to time. Results are scrap, rework and warranty costs that negatively impact profitability and quality, and shipment problems that deliver less than acceptable customer satisfaction. Companies have spent many thousands of dollars in pursuing MRP and ERP only to see growth and profits decline due to uncontrolled operating costs that produced non-competitive pricing.

So, after introducing such computer systems, why is it that many businesses are still struggling to sustain profitable growth and are not close to achieving their full growth and profit potential? The first reason is simple – the results achieved by any computer system are only as good as the people at the controls and the integrity of the data they provide. The second is more complex – most manufacturing managers facing major day-to-day problems and constraints adopt a totally reactive management style. Consequently, their time is consumed applying Band-Aids and/or finding ways to work around system and process problems. That leaves them little or no time to analyze and eliminate the root causes of ineffective systems and processes.

How to Get to Root Causes

How does one turn around such a classic cart-before-the-horse situation? What is required first is a company-wide, in-depth understanding of the fundamentals of Six Sigma and then a total commitment to the consistent and tenacious execution of eight basics of Lean Six Sigma.

Like renowned football coach Vince Lombardi, who achieved success by having his team focus on the mastery of football basics, manufacturing teams need to focus on the mastery of the Lean manufacturing basics. These basics require proactive planning and tenacious execution that demands leadership above and beyond just satisfying day-to-day accountabilities. Some managers cannot envision the benefits of mastering manufacturing basics. Others simply cannot find the time. Like practicing blocking and tackling in football, it is not exciting. And like most football heroes, managers prefer to run with the ball. But without the solid execution of Lean Six Sigma basics, companies will seldom achieve their full growth and profit potentials. Here are the eight basics of Lean Six Sigma which every manager should know and implement:

1. Information Integrity: It is not uncommon for front office management to become disenchanted with computerized systems results when time schedules and promised paybacks are not achieved. It is a given that acceptable systems results cannot be achieved when systems are driven by inaccurate data and untimely, uncontrolled documentation.

2. Performance Management: Measurement systems can be motivational or de-motivational. The individual goal-setting of the 1980s is a good example of de-motivational measurement – it tested one individual or group against the other and while satisfying some individual egos, it provided little contribution to overall company growth and profit. Today, the balanced scorecard is the choice of business winners.

3. Sequential Production: It takes more than systems sophistication for manufacturing companies to gain control of factory operations. To achieve on-time shipments at healthy profit margins, companies need to replace obsolete shop scheduling methodology with the simplicity of sequential production. Manufacturing leaders have replaced their shop order “launch and expedite” methodology with continuous production lines that are supported by real-time, visual material supply chains…sequential production. The assertion that sequential production only works in high production, widget-manufacturing environments is a myth.

4. Point-of-Use Logistics: Material handling and storage are two of manufacturing’s high cost, non-value-added activities. The elimination of the stock room, as it is known today, should be a strategic objective of all manufacturers. Moving production parts and components from the stockroom to their production point of use is truly a return to basics and a significant cost reducer.

5. Cycle Time Management: Long cycle times are symptoms of poor manufacturing performance and high non-value-added costs. Manufacturers need to focus on the continuous reduction of all cycle times. Achieving success requires a specific management style that focuses on root causes and proactive problem solving, rather than fire-fighting.

6. Production Linearity: Companies will never achieve their full profit potential if they produce more than 25 percent of their monthly shipment plan in the last week of the month or more than 33 percent of their quarterly shipment plan in the last month of the quarter. How linear does a production department produce to the company’s master schedule? As companies struggle to remain competitive, one of the strategies by which gains in speed, quality and costs can be achieved is to form teams of employees to pursue and achieve linear production.

7. Resource Planning: One of the major challenges in industry today is the timely right sizing of operations. Profit margins can be eroded by not taking timely downsizing actions, and market windows can be missed and customers lost by not upsizing the direct labor force in a timely manner. These actions demand timely, tough decisions that require accurate, well-timed and reliable resource information.

8. Customer Satisfaction: Customer satisfaction is in the eyes of – surprise! – the customer. Perceptions are what a company needs to address when it comes to improving customer satisfaction. It does no good to have the best products and services if the customer’s perception of “as received” quality and service is unsatisfactory. Companies need to plan and implement proactive projects that breakdown the communication barriers that create invalid customer perceptions.

Answer Is in Six Sigma Basics

While many business gurus may have identified one or more of these Six Sigma basics as important to the successful pursuit of business excellence, the fundamental importance of these basics seems to have been lost in the proliferation of buzz words and the mania of systems sophistication. It is time for companies to put a hold on sophisticated systems development that cause self-inflicted, day-to-day chaos. In its place, they should initiate an action learning program for gaining a company-wide understanding and acceptance of the importance of the basics of Six Sigma. Once buy-in and commitment have been achieved, aggressive planning and tenacious implementation must follow. In short, that is putting “horse in front of the cart.” And such a program will build a solid foundation for redefining and revitalizing a company’s pursuit of profitable growth.

Continue reading

Lean’s Visual Improvements Impact Clinical Operations

Among great strides in quality and efficiency achieved by Virtua Health in New Jersey, USA, in recent years are the results achieved by process improvement teams at the healthcare system’s 95-bed Virtua West Jersey Hospital Berlin in the emergency department, operating room and central sterile supply.

The Virtua Hospital Berlin initiative focused on visual improvements of clinical operations in the specified areas, reduction of inventory costs, enhancement of employee satisfaction and safety, and most importantly better serving patient needs. Specifically, the teams at Berlin were charged with eliminating patient and employee safety related issues in the operating room (OR) and creating a systematic collaboration between the central sterile supply (CSS) and the OR as it related to equipment processing. In the emergency department (ED), the challenge was to improve the reception area and triage as seen through the eyes of patients.

The first step was to understand current processes through time observation studies, stakeholder interviews, spaghetti charts and value stream maps (Figure 1), then to identify waste in the process. Waste elimination was highlighted in the value stream map in the form of wait time for ED patients and travel time for the nursing staff in the OR.

Figure 1: Value Stream Map for the Emergency Department

Visual Management Tools and Observation

To improve satisfaction and efficiency in the emergency department, the ED team decided to start the continuous improvement journey at the first step – the reception area and triage. This was the patients’ first interaction with the hospital. Cluttered areas made it difficult for patients to identify the process they needed to navigate for treatment. This created a negative impression that was reflected in patient satisfaction surveys. It was decided that visual management tools, such as 5S, were to be implemented to simplify the process for both patients and clinical staff.

In the OR, nurses were forced to take many trips into the supply storage area to obtain supplies and equipment during surgeries, interrupting the flow of that process. Licensed clinicians were “picking” cases, during the day, as their schedule allowed. The observations further revealed employee safety issues (trip hazards, blind spots, movable rolling racks, etc.) in the storage room. The observation tool “golf score” was used to assign points to the physical motions nurses used while preparing case carts. This tool helped to identify excessive motion of the staff in the preparation process. It indicated staff reaching where they could not see, bending and lifting. The team’s actions improved the case cart golf score from 417 to 91.

The team also noticed a large amount of clutter and excessive inventory in both the CSS and the OR. The goal for the CSS and the OR was to reduce the inventory and create a replenishment method to keep the inventory in control. That team also initiated a pilot project utilizing “just in time” (JIT) concepts to start the case carts in the CSS. The incorporation of JIT concepts allowed staff from the CSS to pick carts in the CSS and deliver to the OR only when the supplies and equipment were actually needed.

With approval from the hospital’s executive sponsors, the visual improvement goals were set and aligned with the Virtua Star of excellence (Figure 2).

Figure 2: Alignment of Kaizen Goals with System-wide Strategic Imperatives

The Kaizen Event and Trystorming

The two teams were split into sub-teams, one for each identified area. The sub-teams observed the process firsthand and reviewed pre-work completed by Kaizen leaders during the previous few weeks. Upon their return into the meeting rooms, the teams then used Work-Out tools to brainstorm solutions and put together an implementation, or “trystorm,” plan for the next day.

Day 2 and 3 of the Kaizen event were devoted to making the actual changes. Of course, during this period the OR/CSS and the ED were still receiving and treating patients. The ED team identified ideas it wanted to trystorm in the actual area, including simplifying the patient sign-in process, removing unnecessary clutter, and actually trystorming a new streamlined triage process for the patients. One result was an overall reduction of the registration/triage time range of 70 percent. The team also decided that in order to visually improve the area a new coat of paint would be beneficial. That idea was immediately embraced by the medical director, who donated his own time to the cleaning and painting.

After reviewing current case mixes and use of supplies, the CSS/OR team moved mountains of inventory, removed massive amounts of clutter, and disposed of outdated and unused supplies. This was a labor- and time-intensive undertaking, but by the last day the team was able to put the pieces together again in order to see these improvements visually. The OR/CSS not only became a cleaner and more organized environment, but the team also was able to donate and redistribute many medical supplies to other ORs in the healthcare system. Outdated equipment and supplies were disposed of and safety hazards that had been identified in the areas were removed. The reclaimed space was then marked to clearly identify tasks that were to be performed and to avoid future possibility of clutter.

While the majority of the team focused on reclaiming control over the actual storage area, the CSS sub-team removed trip hazards and reorganized the actual CSS storage area. It also created a first step to a JIT system that would start the cases in the CSS and would free up space by only delivering the supplies and equipment needed for surgeries the next day. This also increased the teamwork between the two physically separated teams and removed non-essential tasks, creating greater value for the clinical team.

Sustaining Changes with 30-Day Action Plan

As some of the ideas and tasks could not be accomplished in the actual Kaizen week, a 30-day follow-up action plan helped to assure items were completed and changes could be sustained. Beyond the physical changes, the teams also implemented an improved replenishment system in the OR to further reduce on-hand inventory, spread visual controls to other areas in the OR, and adjusted the patient sign-in and triage process in the ED. Everyone caught the true Kaizen spirit of continuous improvement, striving for better patient care every day.

Leadership involvement is critical to the success of such initiatives, and the team received support from local leadership throughout and after the event. Executives engaged in the process included the hospital’s chief operating officer, the vice president for patient care, the assistant vice president of operations and the quality director. This alongside with the participants from the area, the facilities team, and the fresh eyes from outside the area were important factors to creating this visual success story.

As Pat Williams, nurse director of the hospital’s emergency department, said, “This has been an incredible experience to see the process through the eyes of the patient. And the great thing is, it still continues to spread.”

Continue reading

Six Sigma Certification | Career Path | Jobs | Salary

Learning Six Sigma and using its methodologies can have an incredible influence on your future. Being prepared to put Six Sigma certification into your profile gives your promise to improve your business understanding and analytical abilities. Six Sigma certification offers a professional view of the competition.

That can lead to better occupation opportunities and a better salary. Additional design Six Sigma certifications claim so much respect is that they are not easy to achieve.

Obtaining your Six Sigma certification gives you out from the crowd when you are applying for a new job or working on getting a promotion with your modern employer. Six Sigma expertise is in high demand, and hiring managers at companies that have implemented Six Sigma understand the value of certification. They know the commitment it takes to become Six Sigma certified and might not even consider your application if you do not have the credential.

Six Sigma certification shows employers that you understand Six Sigma and that you are committed and motivated. They instantly recognize that you are very knowledgeable in decreasing costs, increasing revenue, improving quality and processes, and gaining employee buy-in.

Six Sigma certification also indicates to employers that you have been trained to be an effective leader. Whether you are a certified yellow belt or black belt, Six Sigma training and certification is all about honing your leadership skills. Employers know that and will compensate you for it.

Job Opportunities for Six Sigma Certified Yellow, Green, and Black Belts

Many companies and government organizations use Six Sigma and need certified yellow belts, green belts, and black belts. Companies like American Express, Boeing, Amazon, and Bank of America have all used Six Sigma to develop methods and business operations.

Read: Will a Six Sigma Certification Help Your Career?

Depending on which belt you have and how much experience you have playing in or leading Six Sigma projects, you could get a job in operations, manufacturing, information technology, quality assurance, and more.

According to Six Sigma, The starting point for marketing and sales is not the salespeople; it is the customers. Six Sigma can be used to uncover the best ideas to build and grow relationships with customers in sales. Great relationships are the key to improving sales.

Yellow belts, green belts, and black belts could be applied as Six Sigma consultants, production managers, quality analysts, business analysts, building engineers, process development engineers, project managers, warehouse operations managers, information technology project managers, data scientists, industrial engineers, process development directors, and more. The list continues on and on.

Six Sigma Job Requirements

Keep in mind, and most employers would not even consider a Six Sigma position that needs more than an entry-level understanding of the Six Sigma DMAIC framework without a yellow belt, green belt, or black belt certification.

Many employers require candidates to have a point of a bachelor’s qualification in business or another related field. Coursework in project management, statistics, accounting, finance, and business administration are crucial to hiring managers.

From an enterprise’s perspective, attaining a Six Sigma certification enables an individual to become vital. An individual reaches the ability to identify and cut repeatable errors.

With a Six Sigma certification, individuals would be able to transform an organization to increase revenue. You will be able to identify and reduce errors. These errors would have brought poor customer satisfaction and damages to the business. Certified Six Sigma professionals can help decrease complaint resolution time, customer complaints, spending, and cost overruns.

Finally, employers are most involved in candidates who not only have a Six Sigma certification but also have a history of ongoing education, training related to Six Sigma, project management, and continuous improvement.

Salaries for Certified Six Sigma Yellow, Green, and Black Belts

Six Sigma certification is a highly sought-after credential among employers, and they are willing to spend top dollar for job candidates that have yellow, green, and black belts. According to the Salary survey, a Certified Six Sigma Yellow Belt employed in the United States could make from $40,299 to $76,529 per year, depending on the company they work for and where they work.

Salary reports that certified Six Sigma green belts can make from $51,280 to $98,381 yearly, and certified Six Sigma black belts salaries vary from $62,214 to $118,134 per year. Depending on how many years of experience you have, which organization you work for, and where you work, your salary could reach even higher.

And Last Words

As you can see, becoming Six Sigma certified has advantages for both you and the company you are working for. Six Sigma methodologies are capable of improving your company’s bottom line and making customers happier, as well as enhancing your marketability and chances of quality employment for many years to come.

Continue reading

Case Study: Edward Jones Adds Robotic Process Automation with Lean Six Sigma

Robotic process automation (RPA), commonly referred to as “bots,” is a type of software that can mimic human interactions across multiple systems to bridge gaps in processes that previously had to be handled manually. RPA software applications can be integrated with other advanced technologies such as machine learning or artificial intelligence. But at the most basic level, they act like super-macros following a detailed script to complete standardized tasks that do not require the application of judgment.

Why Combine RPA and Lean Six Sigma?

Replacing manual work with bots removes the possibility of human error, reduces rework and quality checks, while also increasing accuracy. Bots can work much faster than humans and at any hour of the day so long as the underlying systems are operational. The potential to reduce overhead costs and increase process cycle time is vast. Bots also provide enhanced controls for risk avoidance.

Bots can serve as a foot in the door to gain traction for a quality program. Senior level executives get excited by the potential of this relatively affordable technology. By incorporating a thoughtful Lean Six Sigma (LSS) process review into a company’s bot deployment strategy, quality programs will gain additional visibility and leadership support.

Effective Bot Deployment at Edward Jones

Edward Jones is a financial services firm serving more than 7 million clients in the US and Canada. Their operations division began exploring RPA in 2017 and subsequently implemented their first bot into production in November 2018. Since then, they’ve deployed 17 additional bots, yielding 15 full-time employees in capacity savings, which in turn generated more than a million dollars in cost avoidance. While still at an early stage in this journey, the operations division has developed a structured approach using LSS tools to assess process readiness for automation, minimize or remove non-value-added work steps prior to development (abandonment), and redesign the process to fully leverage the benefits of RPA.

LSS Process Review

Using a questionnaire to begin their intake process, business areas submit critical data regarding process volumes, capacity needs, system utilization and risk level. This data feeds into a prioritization matrix that allows them to decide where to focus energy and time. Once a process is identified for RPA, a member of the quality team engages the business area for a LSS process review using familiar tools such as a project charter, stakeholder analysis, SIPOC (suppliers, input, process, outputs, customers) and process maps.

After thoroughly understanding the process’s current state, the practitioner and corresponding business area redesign the process for robotics. Next, they complete an FMEA (failure means and effect analysis) and business continuity plan to ensure process risk is being adequately controlled. After this LSS process review has concluded, a broad group of experts – including robotics developers, internal audit staff, risk leaders and senior leadership from all impacted business areas – are brought together to jointly review the robotics proposal and agree on a go/no-go decision.

A critical component of this process review is thorough documentation of every step along the way. Using an Excel playbook to organize all the tools in one place enables a smooth transition as the effort moves from the quality team to the robotics development team. Then, this comprehensive documentation is retained by the business area for ongoing maintenance. Specific elements of this documentation include a systems inventory, a record of all sign-off dates and approvals and a business continuity plan for disaster recovery. Having complete documentation enables the business areas to take a proactive approach when faced with upcoming system changes or unexpected work disruptions. It also equips business areas with any data points required for routine internal or external audits.

Deployment Pitfalls to Avoid

There are some specific areas of concern when it comes to RPA.

◉ Communication: Provide clarity to business areas about what RPA can and cannot do, and what processes fit best with this technology. Without an accurate understanding of the capabilities of RPA, there will be an influx of unsuitable requests for this new technology and, as a result, many disappointed business areas and wasted effort spent putting together their business case. At Edward Jones, the most common misunderstanding was regarding the lack of reading ability for the specific RPA vendor being used. While the bots can recognize characters in static fields, they are not able to interpret characters in an unstructured context. This ruled out many initial RPA requests. Additionally, while comparing RPA to macros was initially an effective way to explain the technology to business leaders that were not knowledgeable about technology development, this comparison created an unfortunate misconception that coding and implementing bots was as fast and easy as creating a macro. Business areas were not expecting development time to take four to six months for what they perceived to be a simple request.

◉ Change Management: Incorporate thoughtful change management throughout the deployment at all levels of the organization. Leveraging bots will take away manual tasks being completed by employees. Some employees may welcome the automation of monotonous tasks, but others may view this technology as a threat to job security. Supervisors will need to adapt and grow their skills to include oversight of the RPA technology. Strong people leaders often don’t have the same level of competency in the technical space, and they will need to quickly increase knowledge and skill to effectively manage their automated processes. Senior/C-suite leaders will need to consider the inherent risks associated with using RPA, the infrastructure and skills needed to support an RPA program, and how to obtain the needed resources and talent.

◉ Human Resources: Bots may create job redundancy, creating the potential for job loss reassignment. Engage human resources early to navigate these situations.

◉ Governance: Balance senior leader involvement so they feel comfortable with automation without extra levels of required approvals that slow the development process down.

◉ Don’t Force a Problem to Fit the Solution: RPA is not the right solution for every bad process. In the early phase of bot deployment, it is easy to let excitement about the new technology lead to poor choices around when to apply RPA. This leads to disappointing results that could undermine the entire bot deployment. Identify clear criteria regarding when bots are an appropriate solution and use a disciplined approach to evaluate each new process improvement opportunity. Consider non-bot solutions before a final decision is reached.

◉ Vendor Approvals: Any third-party vendors must permit bots to interface with their systems. Review vendor contracts or have new contracts signed to ensure bots are legally allowed to interact with vendor systems and web sites before beginning development.

◉ Resource Constraints: Set clear expectations with business areas about the work involved and resources needed to design and implement an RPA solution. The quality team and technical developers do not have the knowledge required about the specific processing steps to complete this work without a subject-matter expert from the business area being heavily involved throughout the project life cycle.

◉ Results: Heavy focus on capacity savings only tells part of the story. Identify other meaningful methods of communicating value from RPA implementation, such as risk reduction, faster cycle time, improved client experience or increased accuracy.

Case Study: Automating Retirement Disbursements to Charities

An example of an RPA implementation at Edward Jones involves the process of receiving, validating and executing on client requests to send monetary donations from qualified retirement accounts to charitable organizations. Prior to implementing the bot, the Qualified Charitable Distribution (QCD) process required 11 hours of manpower each day to get through the volume of donations – and the number of requests had been doubling each month.

The process had five to 10 errors monthly due to the manual data entry required, which in turn took one to three hours of leader or senior processor time to resolve. A bot was designed and implemented that would validate the original request (quality check) and then enter the appropriate data into a computer screen to issue the check to the selected charity.

Stakeholder Analysis and SIPOC

After the project charter was created and agreed upon by the project Champion and project team, a stakeholder analysis was conducted to identify any additional individuals or business areas that were upstream or downstream of the process or might be affected by a change to the process. These parties were consulted or communicated with throughout the effort to ensure process impacts were understood and considered as the automation opportunity was identified and designed.

Next, a SIPOC matrix was created to understand all the process inputs, including systems, data files and end users. Together, the stakeholder analysis and SIPOC are essential in ensuring all critical components of the process upstream and downstream are identified early in the automation effort so no processing gaps are created during RPA development.

SIPOC Analysis: SIPOC for the QCD Automation Project

Supplier	Inputs	Process	Outputs	Customer
Client, branch team	Clilent instructions, intranet form message	Branch team sends form message with client instructions for QCD	Unexcuted client request in the retirement department queue	Retirement support team
Retirement support team	Form message, client account information, IRS rules, client request	Retirement associate reviews client request for QCD to confirm eligibility	Validated client request	Retirement support team
Retirement support team	Validated client request	Issue check	Executed request, issued check	Client, branch team
Retirement support team	Client request, issued check	Close client request on system	Completed client request for QCD	Client, branch team

Current- and Future-State Process Maps

The next step was to create detailed current- and future-state process maps. The current-state process map must include enough detail to highlight all the data sources required by the process, and where that data must be entered to move the process forward. The future-state map must incorporate all of those critical points, while also accounting for the limitations of RPA technology (inability to “read”) and the advantages of RPA (directly ingesting data files, speed and accuracy).

For the QCD process, the client verification step needed to be handled differently for RPA than in the original process. Previously, an employee was comparing client names between the original client request and the account registration referenced in the request to ensure a match. Names can be difficult for RPA to match because the technology doesn’t understand common nicknames that might be used interchangeably with legal names. For example, “Bill” and “William” would flag as a mismatch by the robotic technology, while a human processor would recognize those as referring to the same individual. To avoid large numbers of false positives from the bot flagging mismatches caused by nicknames, an alternative form of identification matching was used, in this case a social security number.

In a typical Six Sigma effort, the goal is to achieve a more streamlined future-state process map with less processing steps and fewer decision points. One key difference between process maps for an RPA effort compared to a more typical Six Sigma improvement effort is that the future-state process maps may contain more, not fewer, steps and decision points. This is normal and shows that the automation capability is being fully utilized to provide a higher level of accuracy. Since the bot processes at a speed much faster than a human can achieve, these additional quality checks do not add to the overall process cycle time. Each decision point with RPA represents a quality assurance checkpoint, allowing for the final output to have higher accuracy than the original process achieved.

Figure 1: QCD Process – Before BPA

Figure 2: QCD Process – After RPA

Risk Assessment

Once the future automated state has been identified, conduct a risk assessment to understand the risks associated with the current process and how the process risks may be affected by RPA. The largest risk associated with the QCD process was the manual nature of the process and likelihood of human error. This risk was eliminated by using bots.

However, automation adds different types of risks, including system failures and coding errors. By identifying potential risks and using control reports to quickly identify and remediate issues, these risks can be effectively managed.

Business Continuity Plan

The final element of the process review is a business continuity plan, specifically focused on failure of RPA to successfully perform the programmed tasks. Consideration should be given to a failure of the bot itself but also any underlying systems that the bot needs to interact with to obtain data or execute requests. Planning should include how to perform the work if the automation is not operational for a particular timespan as well as how to identify and resolve errors made by the bot if the programming becomes corrupted.

Through this planning exercise, a critical aspect of the QCD process was identified that may have led to future bot failure had it not been remedied. Volumes for this highly seasonal process rise drastically at year end, and a single bot was unlikely to keep up with the work at this peak. Programmers were able to proactively solve this issue by diverting process volume onto three separate bots to stay on top of the surge of work during these high-volume time periods.

Results

The QCD bot was implemented in September 2019 and immediately realized 11 hours of capacity savings with no errors. The total project cycle time from the initial continuous improvement analysis, through the bot design, development, testing and implementation took seven months. Since implementing RPA on this process, 100 percent of the process has been automated with zero errors. Process risk was reduced by one point on a 10-point scale by eliminating human error from manual work steps.

During routine follow-up six months after bot implementation, the project team learned that the benefits received from the automation had grown significantly. The volume of client requests for charitable distributions had increased rapidly, so the bot was now performing work that would have taken 34 hours – or five employees – to complete each day.

Continue reading