I used to design processes. Now you say, what the hell
does that mean. Design processes?
Well, here's one way to look at it. Everything in life is a process. Everything you do, every step, every action, is part of a process.
Many processes can be united together into a 'system'. Still, the whole universe is in process, going from one state to another, loosely bound together by what we call time.
Countless tiny discreet steps have accumulated to form what we call life. And then, when you introduce choice into the process you've allowed for countless other tiny discreet steps to be declared.
This is how something is done. This is how anything is done. This is how everything is done.
And as it turned out, I was really good as asking the right questions whenever presented with a choice. And thus, guiding the design of the process. How you respond to those questions is key to attaining the desired responses.
I can see how processes become automatic. With as many choices as we have these days, the average person would be subdued, their mental health would lapse, and the process would come to an undesirable conclusion, if we had to really think about all of our processes. All the steps. All the modifiers to those steps. Trying to do at least a rudimentary cost/benefit analysis. Do I get the New and Improved Kitty Litter or stick with the old stuff? That's what it comes down to. The Kitty Litter Conundrum.
So, we automate. We leverage our belief system to accommodate huge segments of our behavior. Driving. Eating. So much of the day-to-day.
Not a problem—until you're automating parts of your belief system that are not producing "the pursuit of happiness."
Until you're automating with a requirement from the design process, until you've done the requisite analysis, you may be locking yourself into decisions that do not produce the expected or desired result.
It's at those times when you need to have some comprehension of the design process. It's at those times you need a professional. Someone skilled in illuminating the process, breaking it down, in exquisite decomposition, into those all-important steps.
When I was doing process design, I would often find that the design failed because it had not, after all, identified all the prerequisite steps. Usually there was some sub-routine that had been missed (or purposefully left out), a subset of tiny steps that, while infinitesimal in comparison to the entire system, had critical effects in the downstream processing. When the consultant tells you "We're gonna take a microscope to this process" it's not always just a means of billing more hours. You really do have to take the process down to the microscopic levels to unwind all the possible consequences downstream.
And to do that … you have to ask the right questions.
Sometimes you have to be fearless to ask the right questions. I kept running into process problems devolving into personnel problems. During process design, company practices and employee performance put the spotlight on parts of the process you cannot control. If you design the prefect process, but it is ignored in practice, there's not much process design can do overcome the breakpoint.
In such situations, it's tempting to design in more steps than are truly necessary to get the desired result. I always resisted that—and as a result was canned. Cut loose. Terminated. From a couple of projects. That's one of the hazards for being an independent consultant. (Which is always the reason I stayed independent—I avoided the verbal whippings some of my colleagues, who worked for the big corporations like Price Waterhouse and Earnst and Young, would receive if an associate pushed back on a company's HR situation.) Yeah, yeah, I got fired—but there was always another project, looking for solutions only a hired gun like me could provide.
I spent ten plus years doing process design. It is not rocket science. In fact, if done correctly, process design always resolves to the simplest requirements. You might require the Webb Space Telescope as your result, but it is ultimately the result of an intense development cycle that most correctly produced all the tiny details reuired--the blueprint for accomplishing the vision. If it succeeds (and I don't think I've ever been confronted with a bigger "if" than the Webb Space Telescope) it will be the result of getting the tiniest requirements identified and articulating the chain of processes that will drive a trajectory (a.k.a plan) to success.
Process design, baby. It's a pretty sexy occupation. I think. You have all the accoutrements … multimillion-dollar clients, willing to spend big to GET IT RIGHT; an expense account with luxury accommodations. If you thrive on it, you have your way with a large audience, while capitalizing on an ability to relate to the line worker, and consequently finding all the little 'gotchas' inherent in analysis. In my own experience, I had stays at Ritz-Carlton and Mark Adams, drove Lincoln Town Cars and Camaro Convertibles, eaten at The Palm and Big Al's. I traveled the world, well, I went to Tokyo four times. (I traveled more of the world while in the United States Military—which is another story.)
The whole gig, in its own way, was very glamorous. At every company I went to, the SAP consultants were the rock stars. Usually paired up with the company's own version of rock star employees. Big shots on big projects with big plans—which invariably boiled down to lots and lots of processes.
My little specialty became The Blueprint. The design document that captured current state design, and bumped that up against future state requirements. I'd had just enough business experience in Logistics Processing that I was able to turn that experience and the related gain into knowledge, which I leveraged into the available SAP solutions. Of course, there were many times when the SAP functionality did not align with the business requirements. In which case bolt-on solutions would need to be designed into the overall chain of processes. I would design sub-routines, or applications/apps, to be integrated with the primary tool, which were also part of process design.
Now, I'm ten years removed from work as a process engineer.
But.
I find that a cursory analysis of my personal processes reveals a lot of inefficiency. And even outright failure. In what I'm saying and doing.
For example: my eating processes are totally unstable right now, it worries me that they are unsustainable. I know everything I need to know about my diet. Nutrition is the desired output. But my processes allow for way too much empty calories. I won't go through the breakdown for you (unless you specifically request it through a DM to me), suffice to say the scale don't lie. I am not achieving the desired results in terms of weight loss (among other considerations), and I'm convinced my problem is my process design. It's time for a full analysis! Time to do a 'systems' analysis, time to break things down at multiple levels, helicoptering between 50,000 feet—and the weeds.
And that's just one aspect of my life, one 'system'.
I have other systems that are not processing with 100% efficiency.
I look forward to the analysis, which is, after all, something we all do. Everyone is equipped to do the same kind of analysis I do. Start off, if you must, with the "Steps Required to Make a Peanut Butter Sandwich" routine, challenging yourself to capture even the tiniest detail/step to the process. Remember, my experience was that inefficiencies bubbled up mostly in the sub processes of a system. If you're not including the steps of "traveling to the kitchen" and whatever your subroutine is for opening a specific cabinet door in your overall process, you're not getting to the level of detail required.
I know, I know—sounds like I'm imposing rocket science protocols for every aspect of your life.
To be clear, I am not. As I observed in the beginning, automation is a bulwark for mental overload. But before you can effectively automate, you have to get down to the lowest level of analysis, and then you must ask all the right questions, tease out all the parameters that might trigger automation. Before you can justifiably automate. That comes with a thorough analysis. With guidance from a pro.
If you can't find a pro available in your area, you'll have to become your own pro. If you decide to go down that path, I would be available to assist. I can at least illuminate the path I progressed along if you think that might have value for you. It appears there is a lot of employment right now that could use skilled problem solvers. All you need to solve a problem is a standard method of analysis, like I've tried to articulate here. It's so simple it becomes essential.
So, what 'system' are you going to look at after reading this? What's your most inefficient behavior? Why not take that 'system' and apply the simple technique of process design. The timing is perfect for the fresh start associated with a new year!