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.
Leave a Reply
You must be logged in to post a comment.