Comments on: But that’s not what I meant! http://www.hooversbiz.com/2007/12/28/but-thats-not-what-i-meant/ Individuals — Companies — Industries: How We Work Now. Wed, 10 Mar 2010 03:31:18 -0600 http://wordpress.org/?v=2.8.4 hourly 1 By: dblwyo http://www.hooversbiz.com/2007/12/28/but-thats-not-what-i-meant/comment-page-1/#comment-2244 dblwyo Wed, 02 Jan 2008 04:00:42 +0000 http://www.hooversbiz.com/2007/12/28/but-thats-not-what-i-meant/#comment-2244 Tim - what you're saying is true but believe you riffed a variation. Or more prosaically we're using the word model in two different though accurate senses. My use was in the sense of enterprise model which represents the functions, activities and workflows of an enterprise, a business unit or operation, e.g. a manufacturer or customer service. Having spent $M and been able to draw on a worldwide engagement and client base we eventually developed some very good blueprints. But the gap between business vision and/or best practice and technology realization remains quite wide. As a friend of mine put, SAP was a state-of-theart 1970s mfg. model (said circa 2000). You use model in the related sense of the picture businessman have of how their business should run and which they get wedded too; often because they acquire that model by osmosis over years of experience and build up a set of rules-or-thumb that have worked for them. Like any primitive hunter-gatherer who memorizes the patterns of his patch of woods he knows it and is good at hunting it. But when the climate, ecology or animal/plant populations change he's not prepared to adapt and adopt. Now there's another whole thread of conversation to start for your blog. Tim – what you’re saying is true but believe you riffed a variation. Or more prosaically we’re using the word model in two different though accurate senses. My use was in the sense of enterprise model which represents the functions, activities and workflows of an enterprise, a business unit or operation, e.g. a manufacturer or customer service. Having spent $M and been able to draw on a worldwide engagement and client base we eventually developed some very good blueprints. But the gap between business vision and/or best practice and technology realization remains quite wide. As a friend of mine put, SAP was a state-of-theart 1970s mfg. model (said circa 2000).
You use model in the related sense of the picture businessman have of how their business should run and which they get wedded too; often because they acquire that model by osmosis over years of experience and build up a set of rules-or-thumb that have worked for them. Like any primitive hunter-gatherer who memorizes the patterns of his patch of woods he knows it and is good at hunting it. But when the climate, ecology or animal/plant populations change he’s not prepared to adapt and adopt.
Now there’s another whole thread of conversation to start for your blog.

]]> By: Tim Walker http://www.hooversbiz.com/2007/12/28/but-thats-not-what-i-meant/comment-page-1/#comment-2156 Tim Walker Sat, 29 Dec 2007 15:03:39 +0000 http://www.hooversbiz.com/2007/12/28/but-thats-not-what-i-meant/#comment-2156 Good insights, dblwyo. In my experience, there's often a major problem -- both with individuals and organizations -- in terms of building bigger and bigger mental models of what ought to be accomplished. Yet all the top performers -- individuals and organizations -- do this, whether consciously or unconsciously. What I'm getting at is that the best are always looking beyond the immediate requirement. It's not just about hitting a quota or satisfying a spec sheet or whatever; it's about addressing the deeper problem / issue / opportunity in a way that builds up the entity's performance and capabilities over the long haul. Way too many IT departments -- or I should say IT ecosystems, since the fault hardly lies only with IT itself -- get bogged down at the specs-and-deadlines level, so that they're never freed up (never free themselves up?) to do the Big Work, i.e. the stuff that could change the company, the enterprise, or the world. The best business leaders are those who keep ratcheting up the arena of concern. Yes, they get the nitty-gritty details right, but then they're paying attention to how those details feed the overall project at hand, and how that project feeds the whole progress of the enterprise. And the *very* best ones do it from angles of *both* work product and organizational process. Good insights, dblwyo. In my experience, there’s often a major problem — both with individuals and organizations — in terms of building bigger and bigger mental models of what ought to be accomplished. Yet all the top performers — individuals and organizations — do this, whether consciously or unconsciously.

What I’m getting at is that the best are always looking beyond the immediate requirement. It’s not just about hitting a quota or satisfying a spec sheet or whatever; it’s about addressing the deeper problem / issue / opportunity in a way that builds up the entity’s performance and capabilities over the long haul. Way too many IT departments — or I should say IT ecosystems, since the fault hardly lies only with IT itself — get bogged down at the specs-and-deadlines level, so that they’re never freed up (never free themselves up?) to do the Big Work, i.e. the stuff that could change the company, the enterprise, or the world.

The best business leaders are those who keep ratcheting up the arena of concern. Yes, they get the nitty-gritty details right, but then they’re paying attention to how those details feed the overall project at hand, and how that project feeds the whole progress of the enterprise. And the *very* best ones do it from angles of *both* work product and organizational process.

]]> By: dblwyo http://www.hooversbiz.com/2007/12/28/but-thats-not-what-i-meant/comment-page-1/#comment-2153 dblwyo Sat, 29 Dec 2007 13:39:47 +0000 http://www.hooversbiz.com/2007/12/28/but-thats-not-what-i-meant/#comment-2153 Hear, hear. Unfortunately a central problem in the applications arena. It was my proud privilege to be in a similar meeting at IBM talking about DB2 which was and is the most powerful, complex DBMS around (after Oracle beat 'em to the punch on a commercially viable relational dbms). The research lab's definition of user friendliness was "exposing" the API's for user apps to access. Our notion was to point at Lotus Approach and/or MSFT's Access for a UI, design and development tools. Guess who won ? This is a much...much bigger issue and lies at the heart of the malaise in the tech industries though. In 25 years of fooling around with this stuff the biggest gap (in my experience) were analysis of business requirements in business sensible terms and then TRANSLATING those into at least the high-level design. Call it the knowing doing gap. Carr's points about technology is accurate insofar as the bottom of the stack (hardware, network,OS, middleware (including dbms's))are concerned. Where IT is NOT a commodity is when it helps solve business problems and/or opens up whole new vistas of changing the way we do things. The usual suspects for IT effectiveness remain the usual small list, e.g. Fedex, because of their abilities to drive business-based design. Take a look at the Web sites of any major ERP vendor and ask yourself what model of the enterprise lies behind the discombobulated jumble of alleged functionalities. Certainly not any derived from a deep understanding of mfg., logistics, et.al. The door's wide open but whether the cultural gap and skill mis-alignments will ever be bridged constructively, ah... Hear, hear. Unfortunately a central problem in the applications arena. It was my proud privilege to be in a similar meeting at IBM talking about DB2 which was and is the most powerful, complex DBMS around (after Oracle beat ‘em to the punch on a commercially viable relational dbms). The research lab’s definition of user friendliness was “exposing” the API’s for user apps to access. Our notion was to point at Lotus Approach and/or MSFT’s Access for a UI, design and development tools. Guess who won ?
This is a much…much bigger issue and lies at the heart of the malaise in the tech industries though. In 25 years of fooling around with this stuff the biggest gap (in my experience) were analysis of business requirements in business sensible terms and then TRANSLATING those into at least the high-level design. Call it the knowing doing gap. Carr’s points about technology is accurate insofar as the bottom of the stack (hardware, network,OS, middleware (including dbms’s))are concerned. Where IT is NOT a commodity is when it helps solve business problems and/or opens up whole new vistas of changing the way we do things. The usual suspects for IT effectiveness remain the usual small list, e.g. Fedex, because of their abilities to drive business-based design. Take a look at the Web sites of any major ERP vendor and ask yourself what model of the enterprise lies behind the discombobulated jumble of alleged functionalities. Certainly not any derived from a deep understanding of mfg., logistics, et.al. The door’s wide open but whether the cultural gap and skill mis-alignments will ever be bridged constructively, ah…

]]>