|
Services: Knowledge Portals · Knowledge Map · Knowledge Network · Book of Knowledge · NEWS· INFORMATION
Channels: General Business · Business Technology · E-Business · Knowledge Management Community: Join the Network! · Global Network · Events Calendar · Executive Jobs |
|
Posted by Prac on September 10, 2002 at 13:58:31:
In Reply to: Re: what is a business model? posted by Denise on September 10, 2002 at 00:00:40:
Hi Denise
Glad you are enjoying this site. If one could persevere with all the reading, then one could find some very interesting material in here.
I am from South Africa, and now on to your question.
Let me start off by saying that the 4(5)-tiered business paradigm was my idea. This means that it is totally open to questioning and I concede that others may have better ideas out there.
I have spent a few years aligning the multi-tiered business paradigm to other models, and have found it most useful for enterprise architecting. I have managed to do a sensible representation regarding data, information, and knowledge, and its function within this/these paradigm(s).
In a practical sense, the Strategic level would still be catered for as normal, meaning covering the Where Are We-to-Where We Want to Be, and how to get there. CSFs, Strategic Objectives, and all that stuff.
The Higher tactical level would pick up on the strategic objectives (measurable with deadlines) and align it to the tactical plans within business units, or departments and so forth. For example, How would a strategic objective of say; "Growing the customer base by 10 percent within 6 months" tie in with a tactical objective of say, "Reducing costs by 10 percent within 12 months." etc. What if this objective was set by General management as opposed to Exco? Does it still qualify as a strategic objective? How do we prioritise strategic and tactical objectives? Are strategic and tactical objectives the same thing, and if so, how do we differentiate between the hordes of objectives?
The Lower tactical level would set out to produce an implementation plan (a synthesis) of how the previously-mentioned objectives would be achieved in a practical sense. People, technology, processes, etc. Many times tactical plans are in conflict with strategic objectives, and these should be resolved as a conflict in business engineering.
The Operational level would serve as an implementation of the synthesis, and would utilise procedures etc. as tools to deliver the tactical plans (operations planning?), and indirectly support the strategic wishes of the organization.
I hope you can see how the granularity would flow through to provide a useful approach.
The initial reductionism would constitute part 1 of using the multi-tiered business-engineering approach. The inverse, bottom-up balancing action, is a lot more difficult to achieve.
The operational level's realities would definitely influence the lower-tactical level, and yet it cannot be allowed to change the strategic scope of the organization or the higher-tactical level objectives. The suggestion is that reductionism flies out the window as a driver, and that business engineering is required at any level of the multi-tiered paradigm, even simultaneously so. How would it be possible to manage all these goings ons?
Once again, the lower tactical level would have to balance out the challenges and align it to the objectives of the higher tactical and strategic levels. This cannot be done with the 3-tiered approach as one has to restart with the strategic side of things, which most companies don't have time or money for. It also falls victim to the linear thinking problems, top-down approach, and most often than not, scales out of intellectual control as well as time and budget, meaning it fails as a project.
The other problem I have discovered with the 3-tiered approach is that most engineers and managers get lost within the tactical level.
The users (knowledge workers?) often don't even know what happened to them, and they often re-iterate their need for a system, not realising what system they are referring to, and often getting stuck with a computer system, which they paid for.
Some of them clamour for a computer system, to their own detriment, and they have zero understanding regarding IT architectures and integration, and thus the issues such systems bring along with them. How often haven't I seen those who fought hardest to win the political battle for a particular computer system change appointments once the system starts showing stress and a threat of project failure creeps in?
Sorry for the soapbox. To continue, the step from Strategic to Operational Level is just too big to bundle into the traditional Tactical Level.
I therefore call it the Bermuda Triangle of Business Engineering, for obvious reasons. Most projects go lost within this step, and for very good reasons as well.
The 4(5)-tiered approach offers more than increased granularity. It actually resembles a revolutionery change in how we think about systems/business engineering.
To use this paradigm of thinking/working, there are 3 steps which have to be completed on a continuous basis, and not always in sequence either.
Parrallel processing comes into play here, in the real sense of the word. Things become extremely complicated to manage, but that is the reality of business anyway, and thus it moves a lot closer to how things really work, or the nature of business.
This paradigm just seems more feasible to me, and I have realised it is critical to change the way we think about business engineering, or whatever we may call the ouflow of strategic thinking in practical terms.
Business engineering has failed the expectations of its users, and we have to figure out why, and how to turn it into a useful tool with valuable deliverables.
The drivers for this extended way of thinking are the inside and outside forces continually trying to overpower organizations, forces such as technologies, economics, people, cultural changes, and surprise events at scale.
If the organization is very large (an enterprise), one could add another level of abstraction to further increase the granularity, and ensure the strategic desires are followed through on by moving onto a 5-tiered paradigm, but I would prefer not discussing that here at this time.
The multi tiers increase business control and adaptiveness within the organization. It serves as a most useful management tool for continuous-alignment management.
To conclude, the multi-tiered paradigm should be supported by equally adaptive work methods. I have developed one of these and extended it to cater for more volatile environments, but the truth of the matter is that it would require a lot of brainpower to put a whole suite of methods together to manage the scope and size of enterprise engineering adequately, as well as the inclusion of radical new management software.
Such software would allow for real-time, enterpise health checks and adaptation while the organization is functionally deployed. Such software is not available yet, and HP have shown some promise in this regard, but I think even they have realized how huge a task it would be to cater for the whole organization without losing system integrity.
I think the software should support the revolutionery business paradigm, and not drive it, which is the norm within organizations. We need to change our thinking, before we try to get tools who confuse the enterpise architecture even more.
Allowing technology to be the driver would probably represent Step 1 of entering the Bermuda Traingle of business engineering, which often leads to the Land of No Return(s), or the Syndrome of Forfeited Choices. ;-)
To help you understand a little where my mind is coming from: I believe it costs more to do a job badly than to do it well. I would rather spend my life knowing that my time and energies are spent in supporting the big 'Why' of an organization, than faffing around with ever-changing goals and directives.
Most organizations seem to be faffing around, because they lack the intelligence (as in knowledge base) to allow for a different, and revolutionery extension to all their education and technologies they worked so hard for. I respect and understand that position.
I often wonder though why these organizations went through such a draining process if they cannot prove they have reached their business and tactical objectives? What percentage fit did all that money and energy buy? These are questions most project and prgramme managers do not WANT to be asked, or answered truthfully. What if investors demanded to see the planned versus actual objectives of an organiztion, in order to determine if Exco failed to strategise adequately? Even though few executives are willing to take public responsibility for strategic policy and methods, they still remain accountable, and responsible. Not admitting to the truth does not alter its value, and investors are getting this idea more and more.
Few people can admit they have spent the last 6 months of their lives to ensure the objectives are not to be achieved. Fewer even are willing to accept their role in such a situation.
Think of all the other good things, which could have been achieved with the sum of all the resources (people, time, money, and stress contributions). Think of the waste of knowledge. It makes one wonder, doesn't it?
I re-iterate that a revolutionery way of thinking about business engineering is required. A way that has different objectives than to produce incomprehensible models and impressive documents that no one has time to read. A way, which has as its only objective to rapidly grow the understanding of the business and deliver on strategy(ies).
Hope this helps.
Regards.
Click Here to Post Follow Up in New Forums
Download Our Articles and Interviews
[Guru Interviews] [Real Time Enterprise Business Processes] [IT Users Motivation] [IT Users Commitment] [Commitment and Motivation] [Inquiring Organizations] [Social Influences] [Customer Relationship Management] [Supply Chain Management] [IT Adoption and Utilization] [Managing and Measuring Knowledge Assets] [The Real Competitive Advantage] [Why IT and KM Systems Fail] [Myths About Expertise Management]
[How 'Best Practices' Become 'Worst Practices'] [Beyond Information Ecology to Knowledge Ecosystems] [Knowledge Exchanges and Social Networks] [Why Expert Systems Aren't Enough]
[KM for E-Business Performance]
[Does KM=IT? Not!]
[Other Articles and Interviews]
About BRINT | News About BRINT | Help & FAQs | Users Guide | Advertise
Make BRINT your Start Page | | Link to BRINT | Submit Articles
Terms of Use | Privacy | © Copyright 1994-2007, BRINT Institute, New York, USA