Wednesday, December 23, 2015

Automating Lean, Be Careful.

Let me first define what this post isn't.  This post is not arguing that you should not lean up through automation (Although Deming would have a field day on this topic).  Rather I argue that when starting a new lean culture you should not automate the visual indicators (visual controls) of the process.  Visual indicators broadly include any intuitively-easy-to-understand system for monitoring and controlling a process — with examples ranging from kanbans to painted golf balls — but most common is the visual control chart ( The purpose for visual controls in lean management is to focus on the process and make it easy to compare expected versus actual performance. Introducing a Lean lifestyle to an organizational culture is both exciting and frightening at the same time.  Exciting because the firm can squarely focus on value delivery and consider value in a frame they likely have not done.  Frightening because the concepts and activities which are adopted commonly share the culture to the core.   The tendency when in a new process is to try to automate as much as possible.  Don't.

When creating a lean culture the shift which occurs is to frequently use visual controls to measure constraints.  Creating a dashboard on a computer or email provides value but is too easily ignored in a immature process.  Hands on manually created visual controls instill habits that support Kaizen.

In the book 'Creating a Lean Culture: Tools to Sustain Lean Conversions' David Mann suggests.  "The visuals reflect frequent readings of the health of and adherence to the lean design. And, of course, the visuals record misses in the newly transformed process. Establish a standard accountability process through which the misses are converted into actions that sustain and improve on the transformation, as described in Chapter 5. Now you have elements of standard work for leaders that Go to the visuals regularly to verify they are being completed consistently, in a timely manner, and with appropriate specificity. Conduct the standard accountability meeting with the visual tracking charts or their data brought into the session: – Ask about the misses recorded on the visuals. – Make assignments to understand and act on the causes of process misses and system breakdowns, as well as assignments based on your and others’ observations in the area."

Again Mann implores "You might ask: “Aren't all these visuals a lot to maintain?” Not if there is a systematic process for maintaining them. In fact, that is one of the main contributions of standard work for leaders. Team leaders either do or do not make entries on the visual trackers as specified by their standardized work. Supervisors’ and value stream leaders’ standard work directs them to review the visual controls several times daily (or at least once for value stream leaders) for two reasons: one is to verify the visuals are being maintained. The second is to verify that appropriate actions have been initiated when abnormal conditions are identified on the visual controls. When considered in total, there indeed can be lots of visual controls in a value stream or entire facility. But each visual is singular. A single person is accountable for executing it. One or two or more people have specifically designated responsibility for verifying its maintenance and for taking action if it slips. And any of these visual controls is simple, straightforward, can be interpreted at a glance, easily audited, and diagnosed. Put that together with the simple, unambiguous definition of responsibilities for maintaining and using the controls and the system looks much more manageable, as it is in actual application."

From an IT perspective, visual controls might seem like an embarrassing return to the information Stone Age. Visuals are usually not very snappy looking because they are maintained by hand. People are actually counting things (how many pieces do we expect in this load; how many are actually in it?) and writing them down. Have these people not heard of computers and barcode scanners?

Lean processes are designed not to rely on the extras stashed away in conventional systems to bail things out in a pinch. Even so, things go wrong in lean systems just as they do in mass systems. By design, a lean process has little unaccounted-for slack in the system to fall back on. Because of that, lean processes require far more attention to disciplined cycle-by-cycle operation to ensure the process stays in a stable state. Otherwise, the process will fail to hit its goals and fail to deliver the business results so important in any kind of production system. Paradoxically then, in many ways, simpler lean systems require more maintenance than conventional systems.  The way to stay focused on maintenance is to manually control the indicators and constantly define what's moving the dial.

Overall, the lean management system favors hand-completed visual controls because of its bias toward pitch-by-pitch focus on process and the importance of everyone involved in a process having timely information about how that process is performing. When information is available to only a select few, whether managers or specialists, only those few can take responsibility. Indeed, only those few have the information base for thinking about why the process performed as it did, what the causes of that performance might have been, and what might be done to eliminate the causes of interruptions or to improve performance from its current level.

When thinking about visual controls think about their purpose.  What habits are you trying to control and what habits are you trying to break?  How different is accountability when controls always visible and updated?  Remember this is uncomfortable because it's new.  Often people accuse these indicators as "common sense".  We know they aren't common sense otherwise most organizations would organically be using them.  Visual controls support visual lean management.  While lean management is the number one driver for lean success, visual controls server as a fuel lean practitioners can use to build their lean culture .  

Wednesday, September 16, 2015

If You're a Service Based Company You're Full of Waste

Service industries mostly ignore lean's tremendous transformation potential. This is because it's very difficult to differentiate the difference between work product and waste.  For many service organizations (e.g., insurance and banking) as well as some office functions within manufacturing supply chain organizations, information is the work product. In any case, because information enables behavior, there is direct bottom-line impact from improvements made to information systems when these changes reinforce appropriate behaviors.  However, with some tweaking of the tools, lean principles and concepts apply equally well in service settings.

There is often substantial resistance to change in service organizations.  I would argue this is multiplied in service/office environments because often lean failures occur in large part because of management's lack of patience for the the proper growth along the maturity curve.  The inability to physically see waste makes managing it's elimination even more difficult.  The answer is to create patience and visibility through events such as kaizen workshops which can break through cultural barriers and help nudge change along.  Another obstacle is that customers are often part of the process. Stopping a process in its tracks to apply lean with customers can be difficult. But, events can make it easier by pulling people off the front line and placing them into the transformation process where they can be invisible to customers. For example, a customer should not be told by order fulfillment to wait an extra week for shipment while improvements are being made. Similarly, a restaurant does not expect to drag its patrons into the kitchen to participate in its redesign.

Direct observation of work is one of the most challenging lean skills to master when dealing with service based firms. Practitioners must be able to observe a process and truly understand how the activities, connections, and flows of the process are linked to the results. A manufacturing environment lends itself to the practice and development of direct observation. The process comes alive like a ballet with the motion of people, equipment, and material. But it is much harder to observe processes for service tasks, such as accounts payable, requisition fulfillment, or evaluations. Tools such as process mapping can help develop observation skills. However, in service organizations, what people do and the product, information, or service are often on different tracks. Instead of leading to a better process, putting two distinct processes on the same map only causes confusion. Separate maps can be used to explore different aspects of the process. An activity map captures people's actions. A product/process map captures what happens to a product or service. As an organization captures current reality, it needs to look at how it designs and executes activities, connections, and process flows.

According to Hitchicker's Guide to Lean "applying lean in a service environment is just plain harder. Service processes, which are cross-functional by their very nature, can be difficult to see, and documentation and measurement are sparse. However, the results can be astounding. To get a sense of the potential, here is a simple value-added test. A value-added activity is defined by three strict criteria: 1.  The activity must be valued by the customer who is willing to pay for it. 
2.  It must change the product or service. 
3.  The activity must be done right the first time.

In a service organization, problems are less visible. That is because the buffer, the thing that shields the organization from little problems, is not a tangible element, such as inventory, but something more elusive: time. Instead of working around problems a service organization must make them visible and create structures to force workers to solve problems as they occur."

Flinchbaugh, Jamie; Andy Carlino (2006-01-02). The Hitchhiker's Guide to Lean: Lessons from the Road

Let's take an office environment as an example in this case.  Overprocessing waste can sometimes be hard to detect, because it is often disguised as "we are doing more for the customer." But processes that exceed what customers value, yet offer no benefits are, indeed, waste. In a manufacturing environment, people can readily discover and eliminate overprocessed features. In a service setting, however, overprocessing examples are subtler and can seem insignificant; but small improvements can add up to major savings.

As we continue to find faster and better ways to manufacture products, deliver services, process information, etc., the knowledge workr will increasingly be required to process data more accurately and faster than before. Therefore, information must effortlessly stream cross-functionally throughout an organization. Additionally the focus must be not to create waste within these functional groups. The knowledge workers in these groups will need to learn and adapt new software applications to meet the ever-changing business related requirements. A “Lean” power user is someone that does that but also incorporates Lean tools and concepts while learning and working with new applications. Many organizations are ‘drowning’ in how to manage all of this and at the same time meet customer demand (internal or external) while ensuring the employee is not stressed. Furthermore, many employees may not have had adequate training on the suite of products or other applications that may dramatically improve information flow, and subsequently office productivity. 

The following are some common data and information flow questions and situations that today’s employees struggle with that can be an identifier of waste in the office process: 

“My Inbox is drowning in emails. How do I establish standards that will reduce email traffic?” “I often double or triple handle a single report because I don't have all the information when I need it.” 

“It seems I spend half my time requesting information from one department or another because access rights are not granted or no one has trained me on how to obtain the needed information from their system. It’s frustrating that we are not all integrated.”

 “My Desktop filing system is a mess. I just save files to my C drive or Desktop.” “How do I categorize my files and emails, and then ‘automate’ where they are saved?”

 “My computer screen is littered with icons and junk I don’t use. It’s hard to find what I need.” 

“When staff go on leave, other staff in the same office do not know how to find the right document or information even though it is stored on a shared drive.” 

Applying Lean in an office environment will achieve reduce waste.  The problem with office waste is that it's everywhere.  In fact it's so common that if you were to parallel it with manufacturing waste you would likely need more warehouse space the hold the waste then your material.  

Value stream mapping is an essential tool for identifying and measuring the impact of information waste on process outcomes.

But for many service organizations (e.g., insurance and banking) as well as some office functions within manufacturing supply chain organizations, information is the work product. In any case, because information enables behavior, there is direct bottom-line impact from improvements made to information systems when these changes reinforce appropriate behaviors.

Lean organizations focus on providing value for the customer. In a manufacturing environment, the process does not directly touch the customer; it creates the products that touch the customer. In service organizations, however, value and process are often one and the same. The customer is typically the beginning, middle, and end of the process.

From the customers' perspective, value should be more than a design activity. It should be an everyday lens. A service defect is a major customer problem. But a service organization can not just inspect the end results of its processes. Because the customer is so close, every employee action is a chance to either provide or destroy value. Starbucks provides more value than a cup of hot coffee. Each store provides a comfortable, convenient, and reliable environment. And they can charge for the extra value. Not all coffee drinkers value or are willing to pay for the Starbucks experience, so they go somewhere else. Whatever the service, it is important to deeply understand how different types of customers have different needs. By understanding these different audiences, a business can customize its processes and services to offer the right kinds and amounts of value to each subgroup.

To design around the customer and give them what they want, an organization needs to consider what impact its processes have on customers. How much of customers' time does an organization waste by making them wait for service or rework? How many times does an organization ask its customers to provide the same information over and over? For example one major airline asks all of its qualified passengers that check in on-line or at a kiosk whether they would like to upgrade to First Class - before the reservations system checks to see if First Class seating is available or even an option. Each request only takes about 15 seconds; but each 15-second delay is a painful reminder that this airline does not value its customers' time.

For an organization offering products and services that are considered necessities, it is not as critical to infuse them with value. But an organization that provides necessities needs to pay particular attention to how it consumes its customers' money - and especially their time. Time is the currency of the 21st century. In designing around customers, it should be considered that, to a degree, time often has greater value than money. A person can always get more money, but lost time is gone forever. The moral: do not waste customers' time. "Factor Five: Events are Necessary

Lean is not about events, it is about everyday behaviors, skills, and thinking. But events help create the right environment and deliver results. There is often substantial resistance to change in service organizations. Events such as kaizen workshops can break through cultural barriers and help nudge change along.

It is usually difficult to deploy lean practices and skills in service settings. One obstacle is that customers are often part of the process. Stopping a process in its tracks to apply lean with customers can be difficult. But, events can make it easier by pulling people off the front line and placing them into the transformation process where they can be invisible to customers. For example, a customer should not be told by order fulfillment to wait an extra week for shipment while improvements are being made. Similarly, a restaurant does not expect to drag its patrons into the kitchen to participate in its redesign.

When customers can be involved in the improvements, there is a lot to gain. Not only will an organization's processes be improved, but the customers' experience can be improved as well. Working side-by-side in the war against waste can help an organization build camaraderie with its customers. The downside is that the organization could risk exposing too much of its inner workings and dirty laundry; if customers do not like what they see, they may not wait for improvements. An organization needs to balance both sides of the equation to see what works best.

A word of caution: while events are necessary, an organization should not over-rely on them. Otherwise, events may become the only mechanism for change, which severely limits an organization's potential for performance improvement. Some early events should focus on creating a living lean model. In a retail company, a single storefront may serve as the lean model. In an office setting, it might be one element or flow through the organization. To help explain lean and get employees on the lean bandwagon, living models are far more effective than theories, words, or training alone. By focusing on a small area or department of five to 20 people, an organization can quickly create a living example of what lean could look like across the enterprise - and thereby accelerate the journey for the entire organization. Living models also serve as laboratories to test applications, experiment with implementation options, and help anticipate issues the organization will face when it undertakes a broader transformation."

Flinchbaugh, Jamie; Andy Carlino (2006-01-02). The Hitchhiker's Guide to Lean

Thursday, March 12, 2015

Technical Debt, It's all Around Us.

Technical debt. The term has been popular for a while and is used to refer to a lot of scenarios. In my experience, one of the most overlooked forms of technical debt is created when operational support requirements are excluded from the project life cycle.
In many companies, operational support is not considered part of the project life cycle. Operations and project are often completely decoupled at the lower and middle levels of the IT department, only dovetailing because both divisions report to the CIO or VP of IT. Often it’s this very component of the life cycle which delivers the most value to the customer.

This disconnect is created when communication between IT and the rest of the business is limited. When the business defines objectives and timelines for code project with limited or no interaction with the operations team, the operations requirements that are needed to support various projects are presented in an abbreviated form or left out entirely. The project team might not even know that operations requirements exist until the code is almost ready to go live, if then.

I recently participated in an emotionally-charged meeting that was scheduled to review the root cause of the failure of a client-facing system. The project team was angry with the operations team for not supporting their code in a highly-available (HA) environment. The operations team was defensive, stating that they didn’t have the time or resources to address their backlog, including the HA environment.

The project team specified an HA environment in their runbook as part of their handoff to IT operations. The HA system was acknowledged by the operations team as a requirement to adequately support the live code, prioritized and assigned. However, the HA system’s completion was not considered release-gating by the project team, so the project was declared complete as soon as the code was live.
The project team expected their live code to be considered part of the production system, with accompanying up-time SLAs. The IT operations group was working on the HA environment, but didn’t have dedicated resources on the project, so its completion was a long, drawn-out process. The same people working on HA were also doing regular maintenance tasks, working on systems for other projects, and putting out fires. Again, where in this dispute does the customer value delivery exist? Doe most IT departments consider customer value when negotiating this type of delivery?

Part of the miscommunication was created in the beginning of the project, when people from the operations team were not included in the project team. It was exacerbated when the code was permitted to launch without an HA environment. It really snowballed when the project team went on to the next project not fully delivering the value of the code in terms of the delivery life cycle. The operations team, with its own unique requirements pushed code live without ensuring that the requirements were completed, and then repeated the pattern all over again.

After just a few project lifecycles, it becomes clear that the decoupling of IT operations requirements from business requirements within consecutive projects creates a backlog for IT operations that can’t be
surmounted without drastic remediation efforts. Futhermore this lack of oversight often reveals a lack of understanding of value delivery life cycles. When domains are permitted to hand their delivery over the fence to the next group they tend to value less quality over quantity.

Fortunately, this problem has a simple solution. It’s not easy, because it requires being realistic about how many projects your company can complete in a given amount of time. If you have are in the habit of ignoring IT operations requirements, you might be surprised at how much paying attention to them will slow your project completion rate. You might have to be realistic about the number of operations people you truly need to support your project work. You need to understand the value your creating for your customer is not realized until what you have developed is fully implemented and the customer is finding the value in it. You have done nothing relative to value delivery if you’re not ensuring the product you’re delivering is delivered in full.

In summary, pay attention to three key aspects to prevent a buildup of technical debt as a side-effect of project work:
1. Make operations requirements release-gating
2. Don’t launch on temporary environments to get the product out. Deliver your product to deliver value not presence
3. Bring operations people into the project early and often in the life cycle. In fact make them part of the life cycle if you want to succeed early.
Projects are not complete unless the systems on which they live are complete and delivering value to the customer. Anything not providing value to the customer is considered waste. Be the change agent in your organization. Stop throwing anything out to the client to see if will work. This isn’t fishing.

Popular Posts