How do you identify the most important business processes?
At the highest level, a business is defined by its goals and strategies. (Ends and Means) Within that context, a process is a plan for creating a capability, a potential to produce. When executed, a good process plan delivers the correct product, consistently with measurable results.
The product could be that “widget” every book mentions – “we can produce 1000 widgets an hour from iron castings”. Product could even be an intangible like electric power or bandwidth – “we can provide energy for a 100 Kilowatt demand for up to 8 hours out of 24 from sunlight”.
Note the words “can” and “from”. Process improvement simply means improving our ability to make more with less. The “less” could mean less raw material, less expensive equipment, less time, less risk or less waste. (Every process has a product and a by-product.) Improvement only happens by accident, or when we learn something. The reverse is also true. Process performance worsens sometimes by accident or when we forget. Accidental improvements are temporary. Knowledge is the key.
So, the question of most important process takes us in three directions.
First: It is good advice to “play to one’s strengths.” What are our strengths? What are the core competencies that we can develop and improve? What are those processes that should never be outsourced? Those are most certainly highest in importance.
Second: The Sustainment process. An important component of operations management is continually training, reviewing methods, correct use of tools and technology, safety protocols, and so on. Professional athletes, performers and musicians never stop practicing and rehearsing.
Third: The Learning process. Since accidents do happen, an incident should trigger a learning process. Was the consequence of the accident a good thing or a bad thing? Why did the accident happen? I like a simple classic approach to causal analysis.
A. Identify the immediate cause. – (The roadway nail that caused a flat tire.)
B. Look for a causal chain of events. – (The carpentry truck ahead with the open toolbox. The speed bump. The speed at which the carpenter drives.)
C. Examine human action. What choices and decisions could have been, and will be different? – (Lock the toolbox. Slow down for speed bumps.)
Finally, don’t wait for accidents to happen. A fire drill is sustainment. An experiment-day is a controlled and managed “accident”, a way for us to learn what makes a process better or worse.
A Few Thoughts about “Problem Solving”
Among other techniques, I have encouraged teams to begin an analysis with the immediate cause of a problem, and work backwards along a causal chain. This form of analysis documents two components of causality: 1) causes (things) acting inevitably in accordance with their nature. and 2) decisions and choices (root causes) made that could have been different.
If I imagine dealing with a mechanical product failure, one could learn about (1) the strength, durability, duty cycle, etc of a particular material or component; or (2) the many alternatives, including different materials, that could have been chosen in the product design.
However, a thorough understanding of a problem should begin with a clear understanding of the purpose that cannot be achieved due to an obstacle. Sometimes we can become so fixated on the next immediate objective that we forget about the ultimate goal. Can we go “over, under, around” or must be work through the problem in order to succeed?
Years ago, someone asked me for help with a spreadsheet issue. Their computer was complaining about running out of space and they wanted to know how their computer could expand. I asked them how many of these huge spreadsheets they had, and the answer was one! They only had -one- spreadsheet!
The rest of the story…
When the computer was new, they started their first calculation in row 1, column 1 – and kept going. It never occurred to them to open a second or third file for subsequent projects! When we talked about how multiple projects can be organized into multiple spreadsheet files, they immediately realized their “problem” was not the size of their computer – but their inexperience with the new software.
If you are experienced with office software suites and had a little laugh over this story – don’t forget that sometimes we all have these moments where enlightenment from a “Brilliant Flash of the Obvious” (a BFO) makes an apparent problem vanish and we get a clearer picture of how to proceed.
Check your assumptions!
AWS Lessons Learned
In every field of endeavor today, the need for continuous learning and self-improvement never ends.
“Hybrid” skills – knowledge that spans traditional HR silos and categories have always created opportunities for me. So, I always take the opportunity to expand in new directions.
After my own business requirements led to dabbling in Amazon Web Services for email delivery, cloud desktop services and small cloud web servers, I decided to try the AWS certification tests, starting with what they call the “Cloud Practitioner”.
The certification programs also most certainly bring Amazon more business. For example, I quickly learned that the domain registration and name server services at Amazon were quite superior to the service I had used for years – and I have already begun the migration of the first four of many domain names to Amazon’s Route 53 service.
Next up for me is the Amazon Architect program. Fortunately, there are many hours of free preparation materials available at the Amazon web site. There is also much that can be learned from sample tests that are offered by third party training organizations. These free tests are an enticement to sample their website and consider their fee for training programs.
Here are some tips for others who may want to explore Amazon AWS services and certifications.
- Think big. Really REALLY big!
On the one hand, AWS has services for small organizations and their “only pay for what you use” pricing lets almost anyone experiment with web servers, cloud telephony, email, cloud data storage and more for tens of dollars per month and not thousands.
On the other hand, consider what would be involved in configuring and launching thousands of servers in dozens of data centers – while sharing and securing data between these centers and millions of end users. No “on premises” data center experience prepares you for the scale, the “wholesale” mindset you must develop to effectively use AWS for substantial workloads.
- Don’t Panic!
AWS services are modular and are intended to be loosely connected to produce a resilient and highly available result that can be evolved in small iterations to continuously improve. However, you must first break the “code” of AWS naming conventions.
If you have programmed, you may be familiar with concepts such as “objects”, “structured code”, “event driven routines” and more. When you pick up a new programming language these elements and common built-in functions are typically available if you can “google” the new language terminology for the familiar code building blocks. (Do arrays start at zero or one? Does this language use Braces or brackets? Indented structure blocks of reserved words. Etc.)
AWS often makes creative names for functions and services that you must work to match up conceptually with functions you may have encountered before. On top of this new nomenclature, AWS condenses these names to acronyms, and one must remember and retain the difference between SES, SNS, SQS or ELB, ALB, NLB – and so on. When you expand the acronym and “translate” the service name you often find something familiar.
Of course, there is much you will find that is new and much that is arcane. Overall, you will find the AWS view of “good architecture” is logical, secure, and labor and time saving if used properly. Ask yourself, “if I were designing AWS itself – how would I do it?”
- AWS is always changing.
The “free” sample tests and training videos on the web are not 100% accurate in their scoring. One test heavily emphasized the “access control list” for security, while AWS now prefers resource policies unless ACLs are the only option. Another list marked an answer wrong claiming AWS did not support a particular option or feature – but that was “old news”. New features often change the way cloud applications are designed and deployed.
Training and improvement Tools
Learn, Share, Teach, Improve
Some years ago, I saw a clever poster that diagrammed systems of the human body. It was the most complex flow diagram with dozens of boxes and lines representing the interaction of electrical and chemical activity and their effects on the whole.
This diagram was presented as a “wholistic systems” view of human anatomy, but it was mind-stopping in its complexity. Such an analysis might be appropriate as input for a computer simulation, but it did not conceptualize anatomy and biological process in a form that was suitable to learn, teach and share knowledge.
I have seen this same kind of complexity in business. I have seen telephone routing protocols that make it impossible for a human being to predict where calls will be delivered, who will be overloaded and who will be left idle. I have seen workflows in service and manufacturing operations with a multitude of steps, loops and IF-THEN-ELSE forks in the road that would leave workers uncertain how to proceed.
From cross-discipline experience in many different work environments we derived a different method of describing work that is suited to learn, share, teach and improve business processes.
You know that humans need conceptual structure. Sentences can’t run too long. Articles benefit from paragraphs. Social Security numbers and phone numbers are hyphenated so that they can be remembered as three things instead of 10.
For example, we think of the first three digits of a phone number as an area code. Applying a conceptual structure, grouping, and naming things of like kind is what empowers human thought and decision-making.
Did you ever try to assemble a jigsaw puzzle as a child? The first step was always to group. Pieces of a certain color were pulled aside and in our mind we said “sky”, or “grass”, “people”. Our process dependency diagrams are approached the same way.
At a high level, we group the inputs, outcomes (nouns) and process steps (verbs) into a mentally manageable number that can be presented on a single page. This “umbrella” process diagram shows the overall dependencies for a successful outcome. Each earlier process step is usually earlier in time, but it is definitely a prerequisite for success.
Each process step is broken down onto a detail sheet and more details about the inputs and outputs emerge as well. A process guidebook organized in this way makes it easy to access the level of detail that the user needs for their level of experience.
Decisions are handled by referencing what we call factor tables. We either know in advance the decisions that will be made in a process or not. If not, the work is “out of process” and needs to be reviewed at a higher level; a supervisor, manager, or engineer – depending on the operation. This feedback is a crucial part of the improvement process.
The result: ideas about work and results are presented in a linear, easy to understand format without loops and branches. We describe work conceptually, and not in the fashion a computer requires.
“Joe, we can never replace you.”
“Joe, we can never replace you.” This is so often true and felt of every long-term team member.
I have never met anyone with the unique background and skills of Greg, Nancy, Barry, Kelly, Courtney, James, Janine, Henry, Linda, John and so many others that I have worked with in the past.
Sandy had a master’s degree in English. She was brilliant, but that educational background was not really required when she first joined our team. Barry had a PhD in Physics – a certification not necessary to curate software for a user community. Both were life-long learners, adaptable and eager to expand their skills.
So perhaps we shouldn’t try to replace someone. Instead of writing job requirements based on “Joe” today, let’s think about Joe’s background, aptitude, attitude and skills versus the job when he first took the position.
If “first impressions Joe” turned out to be a pretty good employee, then someone else will be able to do that job. They may not tick every box that made Joe special, and that is ok.
The objective is not to replace the irreplacable. The objective is to find someone who can do the job and learn/grow within it.
In a short time, that new employee will likely become irreplaceable just like Joe.
Reports Are Not The Same As Data!
At the start of a new operations process development or improvement effort, I typically want to see two things firsthand.
It is important to have a personal view of the work presently being done, as well as the methods and the tools or resources available at the place of effort. It is also vital to get an early look at the process metrics and performance outcome data that the workers and their management think is actionable. These first steps allow us to start with a clearer picture of the objective (the deliverable) and begin to develop a vision and implementation plan for a better way.
What I frequently get in response to my requests is one or more reports instead of data. Where once there might have been actual data, its source and method of capture is undefined and cannot be audited. What began as observations systematically compared to a standard has been digested into predetermined narratives with implicit and often wrong conclusions.
Data means measurements, with the method of measurement totally transparent and always open to constructive critique, caveat and refinement.
As an example, telephony systems have not always left audit trials for call center operations.(And many today do not meet the standard of measurement above.) In the systems that do have call detail databases, much time and effort is spent trying and failing to reconstruct the “state of the business” at some past date and time.
I approached this problem on an older system by taking and saving periodic real time snapshots of the PBX system state. (Calls in queues, current wait times, etc.) These frequent “state of the business” measurements gave us actionable data and helped us to monitor performance as we made changes and introduced new methods and tools to call center agents.
The entire chain of logic (observation, data grouping, statistical summation) and graphical reporting was presented in a form that not only provided actionable information, but also communicated the answer to this most important question, “How Do We Know?”
Of course, measurement in the service sector has the same issues of measurement variability as precision measurement in manufacturing. The solutions to this challenge are similar, but that is another topic.
“If we don’t have a clear picture, then we don’t act!” ** – Organizing Product and Process Knowledge
For centuries, people took for granted that the sun and heavens moved around the earth. Against that night sky was the surprising, independent and often retrograde movements of the planets. How does one make sense of that? How does one grasp, in principle, that contrary movement?
Of course you know the answer, as does every child who grew up with a ceiling-mounted mobile of our solar system. We now think of the (1) sun as stationary. We (2) imagine circular motion around the sun, and then refine that new conceptual model by adding more knowledge. We learn that those planetary orbits are (3) elliptical. Then, we discover that (4) not all planets orbit in the same horizontal plane. (Mercury and “sometimes-a-planet” Pluto are tipped a bit.)
As we learn more, the mental picture does indeed become clearer. If our job is to launch a spacecraft to another planet, this clear picture is vital. We need as complete an inventory as possible of what is known about the solar system and its moving parts. We don’t stop at four metrics. Organized Knowledge is power.
Businesses can often make quantum leaps in their ability to deliver value, if someone takes an independent and objective look at how workers and managers think about their jobs. If product and process learning has slowed or stopped, you may need a fresh approach that “puts the sun at the center” of your thinking.
Take a look at the difference a clear picture makes:
- A tech support team dreaded every phone call. A fresh look at their processes led to change, and they were confident in their job after a week!
- A metal machining operator reduced job setup time from four hours to 15 minutes when a fresh look at the process reduced the setup of hundreds of parts to just a dozen or so basic configurations.
- The wrong mental picture caused a service desk to deliver worse performance while their metrics showed improvement! A fresh look at their metrics turned this around immediately.
It is hard to make things easy.
Your high school English teacher probably warned you about too long sentences. Many people will not get a clear picture unless you break ideas down into manageable sentences with nouns and verbs. Product and process knowledge should be organized in absorb-able chunks for similar reasons.
We often say that properly organized process and product knowledge is a mechanism to learn, share, teach and improve. It documents dependencies between ends and means – what are the prerequisites for successful results.
We call this approach to improvement: factoring. We have been coaching, teaching classes, writing books and running on-site improvement projects based on these methods for over two decades. If you see opportunities to apply this in your operation, we are here to help.
—-
** “If we don’t have a clear mental picture, then we don’t act!” This is one of the most memorable gems from Dr Charles R. Hobbs, but there is more to unpack than the surface meaning.
Re-Engineering a Contact Center’s Support Desk Processes, Tools and Metrics
Actionable metrics are conclusions that rest atop a careful pyramid of reasoning that has first-hand observation at its foundation. This is true, even in the realm of precision measurement where we quantify things too small, too big, too fast, too slow or too abstract the see with unaided senses.
Attribute measurement, where we drop events into categories, is very common in contact center metrics. When, where and how many cases by type is often where categorical analysis begins, but if the measurement foundation if flawed, then the conclusions will be weak and uncertain.
True Story!
One client had well over 100 agents providing Technology support for the company’s workers in all 50 states. Their old Remedy ticketing system always had them start a new call and a fresh ticket with a “Category, Type & Item” ticket type. An audit of calls showed that most of these tags were so vague as to be useless or simply wrong.
Here is what we did to re-structure the process.
First, agents were trained to understand that the classification was provisional. It could be reclassified once all evidence was in.
Second, we looked at the anatomy of their Technology infrastructure, and reconstructed the category, type, item choices accordingly. (We have successfully used this anatomical approach to clarify the scope of support in other organizations.)
Now, the most important part!
We added three fields with behind the scene changes to the ticketing software, and modified the agent process like this:
When each call came in, we documented “Symptoms”. The field names and work flows reflected this early first step – and pick lists of previously reported symptoms suggested a provisional category, type and item.
Every support call starts with at least one symptomatic behavior in tech, but analysis cannot stop there. A given symptom may have a benign cause, a serious cause, or may be a complex interaction of two or more causes. So the next modification to the process was this:
We trained our agents in the basic anatomy of the systems that they support so that they could attempt to code a “Diagnosis” the cause of the problem. Too often, support centers are happy to simply make a symptom disappear instead of identifying causes and dependencies. Our process approach emphasizing cause identification allowed the support organization to take preventative action for all users that would be impacted by that same cause, but who had not yet experienced trouble!
Finally, the process of closing a ticket now included “Outcome” (a case resolution discussion) and a final classification of category, type and item.
Obviously, there were nuances. We created simple dependency diagrams that allowed agents to quickly grasp technology anatomy. There were TIER I and TIER II division of labor and escalation issues, and sub-tickets and master tickets were used to collate up cases by cause. Re-organization of TIER I into teams that specialized in specific and related systems had a positive impact on training time and call outcomes. Of course, call routing had to be analyzed and re-engineered to reflect all process changes.
However, the result was a new and improved paradigm in that organization for support center “best practices”, and since this project, we have seen some of these ideas imported into other organizations and into later generation ticketing and contact center software.
Contact Us
Our Consulting Partner…
Available on Amazon
 |
|
Available on Amazon
 |
|
