Mathematical Bummers and the American Canyon/Napa Earthquake

As Northern California cleans up from the American Canyon/Napa Earthquake of August 24th, 2014, I am reminded of a mathematical exercise I was asked to perform in my early years as an engineer with my former employer.





The question posed by upper management was this:

Given estimated probabilities of an earthquake, grass fire, flood, etc... what is the probability in any given year that any of the natural disasters hit the factory.  For example, suppose estimates from the U.S. Geological Survey for the probability of natural disasters in any given year were as follows:

p_earthquake = 5%
p_{grass fire} = 10%
p_flood = 2%

What is the probability that any of these hit?

Well, if you multiplied the probabilities, you'd simply get the chance that all 3 of these natural disasters happen in the same year... so 5% * 10% * 2% is 1 in 1,000.

But that was not, "What is the probability that all of these hit in the same year?"  The question is what is the probability that any of them hit in the same year?

To get to the bottom of this, you simply ask yourself, "What is the probability that none of these things happen in any given year?"

Well,
the probability that no earthquake hits is 95%.
the probability that no grass fire hits is 90%.
the probability that no flood happens is 98%.

So the probability that none of these things happen is 95% * 90% * 98% = 83.8%

What's the probability that any one of these things happen? 16.2% a.k.a 1 in 6.

So we handed this answer into upper management and I wasn't in the room, but I was told that my director got scoffed at for presenting this figure.

It's been 13 or 14-years since I handed in that calculation and they've been rolling that dice every year.  Now that it's happened (I slept through it, "shaken, not stirred"), I feel a bit vindicated.

Why does this matter to Zymergi or our customers?  Well, it's the basics of bioreactor contamination probabilities.

If you add up the probabilities of your sterile envelope failures as well as your sterile operations failures, you end up with an N-sided dice that you roll each time you put up a production culture.  And if you've done the math, you realize it doesn't take that many low probability vulnerabilities before they add up.

Process Data for the Rest of Us

I first started using OSIsoft's PI in 1999 when I got hired as a fermentation engineer at the world's largest cell culture plant (at the time, 144,000-liters).

I remember the first week vividly.  Me - not knowing anything about how read cell culture trends - watching my boss run his cursor over PI trends, nodding his head and then running off to meetings telling the operations staff what's happening in the bioreactors.

Over the years, I've put my eyeballs on thousands of cell culture runs and became an expert on the matter.  Yet, no matter how many trainings gave to tech(nician)s, supe(rvisor)s, and managers to increase the population of process experts at the company, I got the sense that ultimately it was still my team's (i.e. manufacturing sciences') job to know what's happening to the cell culture runs in-progress.

OR, maybe not...

The VP of the plant had the PI administrator write a script to open up PI ProcessBook and snapshot current trends as a images and put it on a website (remember, this was back in 1999).  Clearly management recognized the value of these trends, but was just too much activation energy to get PI data to "The People."

So when I left my awesome company (and awesome job), I set out to do one thing:



And by PI, I mean "process data."

Google had already pioneered the one text-box, one click format for accessing website data.   So why is it that cGMP citizens can find information on the internet faster than they can find critical process data from within the enterprise?

This is why I bothered creating ZOOMS and this is why I think that there's a place for ZOOMS in the competitive space of trend visualization on the web.

It actually wasn't until the Jared Spool lecture at this year's OSIsoft PI User's Conference that I learned how to better enunciate this creation.  


A quick recap:

The bottom of the escalator is where you are if you know nothing about an app (new users live here).  The top of the escalator is if you know everything about the app (developers live here).

Current knowledge is where the user is today; and target knowledge is where a user needs to be to know enough about the application to perform his duties.

Mr. Spool tells us that intuitive design happens when the knowledge gap (the difference between target knowledge and current knowledge) is zero.

A key observation is that the more powerful and feature-rich the tool, the higher up the target knowledge is...and the harder the knowledge gap is to close.

The success of Google (which is to be replicated with ZOOMS in the process trend visualization context) is a modest number of features in order to lower the target knowledge... and thus diminish this knowledge gap and achieve intuitive design.

There are plenty of feature rich PI trend visualization tools for process experts.  ZOOMS is process trends for the rest of us; in other words: PI for the "non-user."

At the end of the day, it's People, Process, and Technology... in that order.  You can buy awesome technology, but if only a small minority of your people use it, you're neither capitalizing on their potential, nor your process.