Operation Improvement Inc.

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