Am currently pulling together material on business improvement for an article in the CBDI Journal. Any ideas, contributions, questions, examples, challenges, pitfalls, or other input welcome.
One of the first problems I've been facing is the question of the Business Model. It has become clear to us that there are (at least) two entirely different notions of Business Model.
The business notion of Business Model is The-Way-We-Do-Business, What-Distinguishes-Us-From-Our-Competitors. For example,
Pile-Em-High-And-Sell-Em-Cheapor
Ship-Em-Quick-But-Collect-Cash-Quicker. I call this Business Model (B). That's what any normal person outside IT thinks a business model is.
The computer notion of Business Model is a collection of line-and-box diagrams, such as data diagrams or process flow diagrams, drawn in IDEF or ER or UML or BPMN or ArchiMate or something like that, together with rigorous semantics for each of the elements on the diagram, which describe the conceptual structure of the business. I call this Business Model (C). These diagrams typically abstract away from many of the things that differentiate an enterprise from its competitors.
Now it is perfectly clear that many business and IT improvements don't involve any change to Business Model (C) whatsoever. For example, a major data cleansing exercise may involve a lot of work for the computer department, and produce some significant benefits for the business, but unless the database schema is altered then there is no need to change Business Model (C).
Incidentally, lots of SOA case studies seem to fall into this category. For example, reducing cycle time or latency probably doesn't change any of the UML diagrams, it merely changes the service level associated with one of the elements depicted on one of the diagrams.
Some business improvements do involve change to both Business Model (B) and Business Model (C). For example, when airlines went over from unique flight numbers to a code-sharing system, in which the same flight could
belongto several different airlines and have several different code numbers. This kind of thing clearly affects database schemas and programs, as well as operational relationships between an airline and its partners.
Another good example involving change to both Business Model (B) and Business Model (C) is when retailers started to introduce loyalty cards, thus allowing them to identify a customer as
the same again.
So here's a question for the enterprise architects and business analysts out there. If the business model is going to drive business improvement, which business model is it? Are you using any formal methods and notations for Business Model (B), or do you jump straight to formal methods and notations for Business Model (C)?
And are there any other kinds of Business Model I should be looking at?
CBDI Journal articles are now available to non-members.
- In Search of a Business Improvement Methodology (December 2008)
- Exploring Business Improvement (January 2009)
Yes indeed Richard. Such terminological discprepancies have to be addressed before any consulting or training assignment - lest it proceed on entirely mkistaken assumptions. A reference model can help us do this succinctly and quickly. See the slide near the end of "Strategy and EA methodology" top right of "Methodology" page at http://avancier.co.uk.
ReplyDeleteThanks Peter
ReplyDeleteReference models tend to follow Confucius when he remarked "What is necessary is to call things by their right names".
See my post on the Wisdom of Confucius.