Process Engineers are Data Scientists - Why we should build better tools for them - NOW!
Before you read this article, take 30 seconds to pay attention to three things: What are you reading it on? Where are you sitting while you read it and How did you get there?. Unless you are on an unlit trail in the woods where you are mindfully manifesting this article (I have one of those a couple miles away, but I still need to take a bus to the trailhead) - the likely answer involves a combination of materials, on a brightly lit display powered by energy with some level of carbon intensity. If you walk several steps back on that supply chain - you will likely find a highly integrated manufacturing complex designed & operated by Process Engineers (& an entire suite of engineers across disciplines).
Process engineers accomplish this using operational data - Lots of it (may be not Tera, or Peta) but likely in the order of mega or giga. Their use of this data is also unique - it is safety critical imposing a high demand on decision quality & data integrity. Ease of accessing the data is a need to have (not nice to have) feature (When you have a safety or a product quality challenge, the window of a catastrophic failure is limited). All this data traditionally can be categorized as materials flow or energy flow which are then managed to optimize revenue. The opportunity (and challenge now) is that both of these also represent carbon flow. A flow that has an ever growing consequential impact on us & the planet.
So how is the ability to access the carbon flow connected with data tools for process engineers & eventually connected to the planet? Let us take a quick detour.
The Carbon emission challenge is a cumulative problem not an average problem. If I emit 1 ton of carbon today to make a widget, I have to worry about the effect of that 1 ton even if I emit only 1/2 a ton to make the same widget tomorrow. Emitting less carbon on average to produce tomorrow does not reduce the impact impacted today. I try to look at solutions to this problem to be broadly in two categories. Painkillers - we try to do what we can today and buy some time for the Antibiotics to kick-in to knock out the underlying problem. There are incredibly smart people working on Antibiotics - No carbon or carbon negative replacements for those materials & processes that lets you read this article - but we need time - so for the rest of this article - I am going to propose some painkillers to reduce that carbon intensity by empowering process engineers who deal with it everyday.
Painkiller #1: Make it easier for process engineers to discover that operational data - this is not a call for just another tool to graph the data, but to actually make it easier. Software in the process engineering world has the attribute of being incredibly comprehensive but with complexity that pretty much negates most of its utility. If the solution to the data discovery problem requires forking a github repo and quickly throwing up a few lines of code on a Jupyter notebook - that is not a solution - It is a technology demo. We need intuitive UX that abstracts the complexity (and hence the opportunity) - to truly make it Easier.
Painkiller #2: Development of operational analytics should require limited to no training or constant project scale implementation. They need to be user-driven & immediately consumable. We are in an incredible time for compute. There are sectors (consumers & media) where the scale has been immense, but in the more secluded industrial data sector - the challenges continue to be massive. Operational analytics should be viewed as the creation of knowledge collateral as much as it is to make immediate decisions. So, how does the consumer - in this case an Engineer who is likely the process expert - translate data to analytics without having to be withered down by complex analytics software? I would think we need tools that re-empowers the engineer. Do you know why we still use Excel (Because it works - and does that!) - But how do we get over excel? Can I be in a world where we do not need to store and email v23 of a spreadsheet with a macro ?
Painkiller #3: The real world is not a simulation, but we often rely on them to design & run our operations. The last mile challenge in the world of operational data is often institutionalizing the knowledge that bridges the design to real-world observation. This is done typically using a combination of heuristics (read experience), estimations, first order approximations & constant monitoring. To me, the entropy generated in all of this is knowledge - institutional knowledge & we need seamless storage of this knowledge. If we are repeating or searching for 'how we did something in the past' - then the organization needs this solution. In my interpretation - this is not about documentation of information - but documentation of knowledge - which kicks up the complexity of the problem several notches.
Recommended by LinkedIn
Why should we consider these painkillers? Let me try and illustrate with an example with a ubiquitous industry - refining. Approximately 101 million barrels PER DAY of oil is refining capacity exists. Assuming we need 20 process engineers per 50,000 barrels of oil (very crude (no pun intended) & likely a very conservative estimate), we have approx 40,400 engineers. Taking the average of the refining carbon intensity per barrel (range 13.9–62.1 kg of CO2-equivalent (CO2e) per barrel) of 38 kg of CO2-equivalent (CO2e) per barrel - we are looking at approx 41,000 engineers with an oversight of 3838 million kg or 3.8 Billion Kg or 3.8 Million metric tons of CO2 emissions PER DAY.
If process engineers are able to impact just 0.1% of this or approximately 1.38 Million Tons per year we would end up NOT emitting CO2 equivalent to:
This is the estimated impact PER YEAR with a 0.1% reduction - but to a process engineer this would only be the beginning & as we have seen with software led empowerment we would likely unlock a flurry of cascading improvements that will magnify the impact. So let us get to building!
Disclaimer: The views expressed here are personal & do not reflect my employer or any other organization I am affiliated with. Please reach out to me at pranav.kannan92@hotmail.com with any questions or concerns.