Automation: You Can’t Trust People to Do Anything

How to avoid the kinds of monumental, world stopping blunders we have been seeing.

Introduction

Whether you are talking about Biden basically not being able to speak, Boeing not being able to build jets, CloudStrike not being able to deploy software or the Secret Service not establishing an adequate perimeter around a presidential nominee, people just can’t seem to get it done.  Today we are going to discuss the problems inherent in using people to do much of anything, and what our alternatives are.

The Problem

Manual processes simply can’t be trusted.  Pilots use checklists to make sure they don’t miss anything, but there are still errors and lapses in judgement, as we see on the news every day.  

Repetition

Anytime we do something more than once, we are going to figure out a way to shortcut it and then go on cruise control, where we don’t think about much of anything. This is exactly why pilots use checklists as mentioned above.

Ad Hoc or Off the Cuff

When we are doing something once only, or we are making it up as we go along, we are bound to make some mistakes.  Since we are basically ‘live’ in an ad hoc environment, like Biden was in the first presidential debate, we make mistakes.

Quality control

When we are doing repetitive or ad hoc tasks, it is imperative to have some kind of safety net, a back up strategy to save us from failing or appearing to bumble about.  The pilots we were talking about usually have a copilot to perform quality control as they are processing the checklist.

The Solution

Surely there has to be a better way than to have people repeating the same procedures over and over, or making things up as they go along and not getting their work checked before it is used or deployed

Define the Problem

First, whether we are building jets or deploying software, there is a set of tasks to accomplish to call the job complete.  We are not going to say workflow, because this puts us into a linear mindset where we can’t imagine more than one thing getting done at a time.  For instance, at General Motors, we build the engine, the transmission and the body all at once, and only have to bring them together at the end.  WE call these things dependencies.  They don’t have to happen in any order as long as they all happen.  This mentality works at Boeing or the Secret Service as well.  For Biden, if he is in possession of all his faculties, He should have produced a list of things he wanted to talk about and a list of questions he was most likely to be asked.  This is all defining the problem.

Define the Solution

Once we know what we need to do, we can start making a plan to get it done.  For each of the tasks defined above, we need to know who is going to do the work, what the necessary resources are, the associated costs, who is checking the work, and maybe most importantly, the priority.  In Biden’s case, we enumerated that he needed to know what he wanted to say and what questions he was likely to be asked.  His solution then would be to make the statements and answer the likely questions until he was as slick as guano on a door knob.  Then as a check, he needs a staffer to quiz him and maybe come up with some other questions as a control.  The process is the same for Boeing.

Set a Schedule

Once we have defined the problem and the solution, we need to set a schedule of completion.  If we don’t the task will expand to take all the available time.  This can be acceptable for an artist or artisan, but we live in a production-oriented world, and the artist doesn’t really need all this structure.  Clearly, mere mortals do.

A Better Solution

Of course, when we point out these kinds of problems, we always detail some kind of solution.

Automation

In a perfect world, we would all use an Enterprise Resource Planning (ERP) tool to deal with the complications of building jets. This process would include the steps for testing and quality control built in.  We probably don’t need an ERP to prepare for a debate, but that just makes Biden’s performance that much more egregious.  Some things need more than just to be planned.  Some things can actually be completely automated.  If they can be, they should be.  You will notice that we haven’t mentioned CloudStrike since the Introduction.  Deploying software is one of those things that can be automated completely, and should be.  Since we had the CloudStrike outage, we can state that they don’t use any automated deployment or testing processes.  Here at Sentia, we have been working on automating deployments now for about three months.  First, we have stabilized the network and infrastructure so there is redundancy in every functional part of the network, like database, web server, domain controller firewall etc.  Now we are working on actually automating the deployments themselves.  When a work item is created, the developer pulls down the application code from the repository. He or she then makes a new branch in the repository for a feature or a bug and completes the task.  The developer then runs automated Unit Tests he or she has developed and written to ensure that nothing was broken in the development process. The developer checks the new code into a branch and raises a 'pull request' (PR) to merge the feature or bug into the main code repository. In order to merge the code, it must be inspected by someone, in this case, a senior developer.  Once the code is merged, it is automatically deployed to the Test environment.  The testers are notified of a new work item and they go and do their testing, including regression testing, which is also largely automated, to make sure that the feature works, or the bug is fixed and nothing else was broken in the process.  When this is successfully completed, the new code is deployed to the User Acceptance Testing (UAT) environment.  This is where management and customers can accept or reject the new code.  Once management has passed this code in UAT it is automatically pushed to the Production environment.

What we have defined here are multiple levels of testing.  The developer tests, the testers test, the client tests, and finally management tests and approves any deployment.  Clearly CloudStrike doesn’t have these layers of testing in place.

Conclusion

We have defined three different scenarios to make sure that earth shaking mistakes are not made.

• Checklists of things to accomplish with measures of what success looks like, with deadlines
• ERP style process management that defines who does what work, when and using what resources
• Custom solutions that actually do the work for you, like automated deployments

You might be wondering what this all has to do with healthcare and health insurance.  This is the future of health insurance.  Eventually it will be the future of healthcare in general as we implement the ERP and pivot from paying for procedures performed to paying for health and wellness.  With a custom solution, though, we can automate the entirety of health insurance.  With the knowledge that ‘if the doctor says you need it, then you need it,’ we can shortcut everything the current, evil, wasteful health insurance companies do now.  Sentia’s health insurance company will provide the Electronic Medical Records system (EMR) that the care giver will use to document each patient encounter. Since we know via the EMR what procedures were performed, we will pay for them in real time, shortcutting everything the old, inefficient, legacy insurance companies do, until we put them out of business.   Then we will change the paradigm to paying for health and wellness instead of paying for procedures.  For the privilege of serving patients, we will collect a flat data management fee of $10 per month.  To this we will add the actual risk incurred by the insured patient.  That should net us a 40% plus savings over the legacy insurance companies with their tens of thousands of employees, huge buildings, sites in every state and everything else they use to tell you why they aren’t paying for your medical care the way they agreed to.

Today we have shown how to easily avoid world shaking blunders without depending on people to do much of anything.  Doing the thinking about the actual process should free those people to do what they are best at: create and innovate.  Let the machines do what they are good at: freeing us to do what we are good at, and not make huge mistakes.