Operation Improvement Inc.

See Also:

Operation Improvement Inc. » Learn, Share, Teach, Improve

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.

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!

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.

Supporting the Dependency Diagram With Visual Definitions

Common Error and Solution for Performance Charts

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