Context of Operations

This is most of an email I sent to a colleague who was about to teach a class on Operations.  This was my introduction to him of me and what I do.   

“I have spent the past 23 years designing processes (12 years), designing departments (7 years) and designing businesses (4 years).  If you don’t mind I will recount how that progression occurred.  Initially I worked on determining the root cause of process performance problems (nice alliteration) and designing solutions.  The effort was typically directed to one department.  As the projects grew so did the breadth of the processes.  It did not take long until I was working on processes that spanned departments which definitely increased the complexity.  I did have great success and eventually was asked to step into the CIO role at La-Z-Boy (LZB).  In that role I redesigned the IT department for the LZB division (3 years) and then created an entirely new IT department to service the all 14 divisions at LZB (4 years) plus the corporate office.  Though my title was CIO my actual role was IT Department designer, leader and manager.

 

As a Vice President I did have control over those areas reporting directly to me and so I could design them to work the way I wished them to.  IT, HR and Finance are all support functions and because each area is asked to participate in all projects you can see how important it is for them to work closely together.  If you know anything about IT you will be aware of the challenge made to every CIO – Align IT with the business.  Problem is businesses are not aligned with themselves and therefore there isn’t just one thing IT can align to.  (I contend that there really is not something called “the business” but instead a collection of departments that share a common business name.)  

 

Businesses need a way to have all of the parts working together.  It does not benefit a company to let each department go off and try to optimize itself thinking it will have an optimized whole.  It simply does not work that way.  Optimizing all the parts does not optimize the whole.  After leaving LZB four years ago I started documenting the design of the entire business to show relationships and how the parts needed to work together.  It actually shows how to align the parts of a company – the holy grail of business.

 

You have some process work in your course.  If you are a process designer you know that processes are invisible until each activity/component is documented.  Documenting processes is actually documenting process designs.  It is only when the entire process is visible that you can determine if a change is warranted and what the impact of that change will be.  By documenting the process before making changes you minimize risks of unintended results.  Also by documenting the process you can determine whether the process needs to be changed in order to achieve certain performance goals or if it is a matter of execution.  Poor process performance is the result of either a poor design or the poor execution of the design.  Until you document the process you can not know where the problem exists.  More than 80% of the time it is design-related.

 

Now reread the last paragraph and substitute the word ‘process’ with the word ‘business’.  The principles are exactly the same.  Most executives (people in your class) do not understand that businesses have designs.  They know products have designs and some will know processes have designs but few if any will know that the business has an actual design.  And because they do not know designs exist in businesses they do not look at the design when they are having performance issues.  They look at their employees (remember performance = design + execution) and if you can not see the design you go after execution.  This is why so many projects in companies have such a low ROI and management is frustrated with their investments.  They are not resolving the root cause.

 

I know this is a roundabout way of getting to one suggestion I would have with your course.  And that is context.  Context provides the appropriate background for any area of study.  One pet peeve of mine is when people judge actions taken decades ago and use today’s mores as the backdrop.  Without knowing what was going on in the past those judging do not have the right context to understand the actions that were taken.  Without understanding the entire business your students may not fully grasp Operations.  I do see that you speak about business and process design and I want to encourage you to show how things are connected, not separated.  It really is not ‘business and operations’ any more that it was ‘the business and IT’.  All of it is the business because “Everything is connected to everything”.

 

There is a particular sequence that leads up to the performance requirements for Operations.

Ø      Capstone. 

o       Strategic information such as the determination of the performance goals for the company.  What are the revenue goals and profit goals?  They drive everything. 

o       In addition you have to understand the competitive environment.  Without knowing the competitive environment you are making plans in a vacuum.  Returning to the idea of context, the competitive environment provides the context for designing the business for success. 

Ø      Market Model.

o       Markets, customer segments, product groups, products and Value Propositions.

o       Determine whether your Market Model can deliver on your revenue goals.  If not you have to make adjustments to the Market Model design.  You may increase your markets, sell to new customers, develop new products or redesign existing products.  You may acquire an existing company which will broaden your Market Model.

o       Part of the work in documenting the Market Model is determining customer expectations.  This is critical because Market Model requirements are input into Operations (Process Model).

Ø      Process Model. 

o       The Process Model contains all of the processes that the business performs.  What I am referring to may be slightly different than how you think about it.  Selling is a process.  Marketing is a process.  Assembling components is a process.  Making components is a process.  There are processes that focus on Creating Demand for a company’s products and services.  There are processes created in order to Fulfill Demand for those products and services.  I expect that in your course you equate Operations with Fulfill Demand processes.  If I am correct in that assumption I would suggest that in the future you consider all processes as part of Operations.  That is why Lean concepts work on the shop floor and in the office as well. 

o       The point I wish to make here is that the performance requirements for processes is not arbitrary.  The market place will determine what is an acceptable price or acceptable lead time both of which are determined by the Process design (Operations).  The market gives Operations the minimum requirements in order to be competitive.

 

I will stop here.  I have probably worn out my welcome by now.  You should know there are two more Models that are part of a business design:  Organizational Model and Systems Model.  If you wish to have an overview of them I would be glad to share it with you.

 

Everything I have written comes from my business partner and me.  I can not direct you to a different source because we are the sources for these ideas.  This is just the tip of our ice berg.  I have much, much more I could discuss. 

 

Let me know if you wish any clarification on the ideas I have presented.  I will be glad to respond.”