Structure in Threes: Organizational Design

Business Structure verses Organizational Structure

One of the interesting issues that came across my desk today as I was discussing a colleague’s new venture was the taxonomy and ontology of our conversation.  She wanted to cover multiple concepts in the same conversation which is a notable goal regarding economy of one’s time.  However, it became apparent that the terms being used were being overloaded during the conversation.  Example: Discussing the Business Structure and Organizational Structure both terms were used interchangeably.  However, when I hear the words Business Structure I think of the legal form in which the business is established (Corporation, LLC, Partnership, etc.).  When I hear the term Organizational Structure I consider whether it is centralized or distributed; a partitioning along functional, product, customer or geographic lines.  As I continue to develop the Business Design Tool (see below) the question becomes how-to ensure that the dimensions are orthogonal to each other while retaining the interconnectedness of these dimensions.

Organizational Development Tools

Many of the recent texts define various dimensions such as complexity, market, size, etc.  However, the interconnection is only a Infographic.  Perhaps these interconnections are only a probabilistic connection leading one to only heuristics.  I will make a interesting systems dynamic study at the Center for Understanding Change when I have some spare time.  In the meantime I continue to develop the Org Design and Modern IT Portfolio Management tools which are looking more and more like an enhancement to the Business Analysis System and Environment (B.A.S.E.) application built in 1994 on MS Access V1.

B.A.S.E. at that time performed a variety of management consulting analysis:

This application will eventually become the basis for the semi-automated workflow for several of Intellectual Arbitrage Group’s practices and services


Structure in Threes: One Enterprise’s Capability is another’s Function

Spent a portion of yesterday going through my project archive (two four drawer lateral file cabinets).  Mostly to clear out duplicated or outdated materials, but some was information mining for the book.  Typically on engagements I spend a fair amount of time to understand clients mental models, language and corporate culture with the objective to operate and communicate in the organizational structure with as little disruption as possible.  While this assists my clients, as I go to the effort of translating concepts into their language so they don’t have to spend the cycles.  This allows them to focus on exploiting the solutions, recommendations I propose and get value from these faster.  Which gets to the point of this post.

The mysterious language of strategy-speak.  Pick up any book on strategy the past decade or two and you’ll see a discussion on the importance of Corporate Capabilities.  The problem being though is the definitions are rather fuzzy.  Is CRM a function or a Capability or both or Software Product or now a Service?  Clearly if we are discussing the “ability” for an organization to manage customer relationships effectively we’re talking capability.  If we discuss the organizational unit tasked with preforming tasks associated with managing customer relationships it would be labeled a business function; which become even more confusing when we add the software products meant to enable performance of those tasks which could be either a product or a service.  And you thought your teenager’s language was confusing.  Those that enter the discussion without context need to spend extra effort to decipher if they can from the dialog.

Why I bring up this semantic problem?  This becomes a critical matter when designing an optimum organizational design.  I stress designing the “optimum” design; like product engineering there are many possible configurations possible.  However, there are a fewer configurations that fit the specific enterprise’s working environment, corporate culture and resources.  These are the high level design inputs parameters which affect the design decisions.  Unfortunately, there hasn’t been a metrics driven approach toward organizational design –something I’m in the process of remedying now through this book– that would include usage of concepts such as Taguchi’s Design of Experiments for design optimization.  However, to use such an approach one needs to standardize on terms such as these, the attributes and metrics associated with these.  Which again brings me back to my achieve and the broad spectrum of models and definitions I’m wading through to create a consistent ontology for Enterprise Design.

I had hoped to avoid the Yet Another Framework (YAF) trap, but I’m still seeing wide variance between associations and societies languages, as broad as what I experienced working on the ISO 103030 (STEP) standard.  My goal is not to create still one more framework, but rather the transformations similar to those John Zachman mentions as key with he discusses his framework. These would not be between cells but between other framework constructs.  The point behind such activity is to make the specific representation system any enterprise uses transparent to the design effort.


These materials though will likely be in the appendix or associated supporting website for the book, as it will likely be a long term effort and would delay development of the core design methodology.