In the sections before, I have discussed what a business model should contain and how the contained information should be structured. Now that I have explained how to document a model, I have to explain how to build a model. Build means:
The development of a business model is a significant task, which needs a lot of resources and takes a considerable amount of time. It is therefore an important decision for an enterprise to start such an effort regardless if this decision has been taken in order to try to document and finally improve the enterprises business operation or to provide a basis for the development of a "standard application software" which will be sold to customers operating in the modelled business domain.
Because it is always an expensive project, it is important in both scenarios (enterprise restructuring or basis for standard application system), that the high level management is sponsoring an envisaged modelling project. Only if there is sufficient management support, it will be possible a) to convince employees to fruitfully work together with the analysts or b) to hire expensive business professionals which have to provide the required business knowledge.
The first step of a modelling project always must be to find the right sponsors, sponsors who are powerful enough to prepare the ground for the modelling project even if it generates extra work for certain employees or extra costs for a development project.
After the project has been sold to the management, the next important step is to sell it to the enterprises personnel. This can be twofold according to our 2 scenarios.
Very important for enterprise modelling is, that the analysts get the required information right from the front, where business is performed and not from secondary sources like manuals, forms, recorded business procedures, or used systems. Business professionals therefore must support an analyst by explaining their tasks and by answering questions in an open and stressfree environment. This can only happen, if the business professionals are convinced, that they significantly contribute to the model, and that the model finally will make their daily job easier and will help them to improve their position in the enterprises business environment.
The best what can happen is, that the employees see the model as their model, that means, the model is treated by them as the description of how they think business has to be performed.
A critical success factor for a "standard application" is, that it covers almost all existing business transactions of a business domain in a manner acceptable to most enterprises.
This goal can only be achieved, if real business professionals from different enterprises can be asked, how a specific business should be handeled. Therefore there must be money available to hire these business professionals as consultants which have to provide the essential business knowledge. It is completely wrong to believe, that an IT application designer can do the business requirements definition job sufficiently well. Business requirements collected this way very likely are not accepted by real business professionals and than of course the standard software will not be very successful.
It is therefore very important, that the IT application designers ask for support when business requirements have to be defined. Instead they should see their job in the technical design, that is the most efficient usage of the IS related things like modularisation, selection of the proper operating system, implementation language, databases, and so on.
This again only can happen, if the IT application designers are convinced, that there exist two equally important aspects (IS and business aspects) which have to be considered. They must see themselves as the key specialists for all IT related aspects, and they must agree that they need to be complemented by equally good specialists for the business aspects of the system to finally make it successful.
Once it is decided, that a modelling project has to be set up the project must be staffed.
The project leader responsible for the project administration must form two groups of developers with different skills and responsibilities:
The modelling project should be started with a team of two or three key experts of each category which than is permanently adjusted to the needs determined by the size of the problem domain defined and the level of detail actually reached. See also "Teaming considerations" below.
There are two different ways to build a model, the "top down" approach and the "bottom up" approach.
The "top down" approach favours an intellectual methodology starting from a very high level "score card" specifying a couple of objectives which have to be achieved. Guided by these objectives a step by step decomposition and structuring of the problem domain is performed until the required level of detail has been reached. The advantage of this method is, that the analysts and designers can go for an ideal business structure from the very beginning of the modelling project. Disadvantage is, that the way business is currently handled is ignored to a very large extent. This means, if the model becomes the basis for future operations big changes within an implementing organization are very likely.
The "bottom up" approach favours a practical methodology which starts with a thoroughly performed investigation of the actual business performance. Than the collected material is analysed and resturctured according to the defined modelling principles. The advantage of this method is, that existing practices are reused more intensively and that therefore changes to an organization following the new recommendations stated by the model are moderate. Disadvantage is, that the new structure - due to compromises commonly accepted - do not be as optimal as possible.
The most promissing modelling approach is to combine both methods.
A "top down" approach for the definition of the modelling principles and the basic model structure will guarantee an almost optimal model structure and a "bottom up" approach for the definition of the final business objects and business procedures will guarantee completeness and a smooth transition if model based systems will be implemeted.
Assumed, this combined approach is used, the steps described in the following sections have to be planned for the modelling project.
The proper definition of the content of a model must be one of the very first task performed in a modeling project. It is very important, that it is clear to the analysts from the very beginning what has to be modeled and what has to be excluded from the model. If the borders of a problem domain and by that of a model are not well defined, than a modelling project may tend to become a never ending story, because analysts have a natural tendency to model "the whole world" - and that will definitely take a while.
The boundaries of the problem domain (respectively the model) must be defined by a small group of key business professionals, which are very familiar with the problem domain and its intersections with neighbour domains from a more or less global viewpoint. It is very advantageous, if they have a vision into which direction a problem domain should evolve in the future.
After the boundaries of a problem domain have been defined, the basic structure of the domain model can be determined. That is, the model can be broken up into logical sub-domains. This task again should be done by the key business professionals, because this is one of their main instruments to determine how business should be handeled optimally in the future. As the appropriate form for such a high level content structure a hierachical decomposition chart should be used.
For an enterprise model for instance this basic structure should define the preferred enterprise organization structure and its hierarchy, that is the needed divisions and their responsibilities (like "production", "marketing and sales", "administration and controlling", "financing", "personnel" ...). Geographical and other important aspects - if relevant - may be addressed as well.
For an industry model the business areas relevant for the described industry should be defined - for the automotive industry for instance that could be manufacturing and national as well as worldwide distribution with its wholesale and retail aspects. For other industries a set of other areas may be of interest.
Of course everything should be described from a high level point of view which gives the desired amount of freedom and flexibility to the analysts which have to describe the lower levels of the model.
No business behaviour can be designed from scratch. There are always procedures (documented or not) which give some guidance to business professionals performing a specific task. And this existing behaviour represents an enormous reservoir of business experience. It therefore would be imprudent to ignore all this business knowledge.
The problem is how to collect all this knowledge to make it available to the business analysts who are in charge of the definition of a specific segment of the envisaged model.
I have to come back to the two scenarios drafted above.
If an enterprise model has to be developed, the business professionals actually doing the various jobs can be asked to describe, what they are doing and how they are doing it. A structured form to record the interviews can be developed, so that later analysis and restructuring of the recorded information is supported. The definition of a set of business area relevant keywords that generically describe a certain kind of activities is very usefull if it is expected, that certain tasks are performed at different places in a similar, but not identical manner. To give an example: "pricing" may be done differently by the departments responsible for marketing their set of products. If such keywords are used in the interview reports, it is easy to find those similar tasks during the final modelling phase.
Business information can easily be collected from existing forms or databases used in the enterprise. During interview performance it only should be kept in mind, that the business professionals are asked for their recommendations to enhance (complete or streamline) the existing information units.
A little bit more difficult is the investigation of actual business behaviour if an industry model or a business domain model has to be developed that has to function as the basis of a standard business solution for that domain. Such kind of models are normally built from organizations not directly and deeply involved in the targeted business domain. Therefore such organizations normally have detailed analysis, structuring and development skills, but the business skills are in most cases relatively poor.
For such a project it is essential, that good business professionals are hired. These business professionals ideally should come from different enterprises, enterprises that are commonly accepted to be the most successfull ones in their domain. These business professionals should be changed frequently, to cover the different sights needed during to the progress of the modelling project.
Good practise is to start a project with business professionals belonging to the middle management of the enterprises. These professionals normally have a vision of how to improve the business behaviour in the area they are responsible for. They also are reasonably far away from the real doing and therefore their thinking is not trapped to the existing behaviour.
Later it should be switched to business professionals which are closer to the real doing, that is first line managers and team leaders, which actually know about various tricks how to do the business and which also know common inhibitors and pit falls, which make sometimes the life of a business professional difficult.
For the collection of information of course also the means mentioned for enterprise model generation can be exploited. Existing versions of standard application programs are in addition a good source to be analysed in order to guarantee at least a certain level of continuity.
The final and most important step in a modeling project is the restructuring of the collected information according to the basic structure of the model defined at the beginning of the project.
During this step primarily all redundancies should be eliminated from the model.
Business objects have to be defined optimally from an information point of view as well as from a behaviour point of view. Information units have to be arranged in logical clusters and a certain information element must exist only once. The same is true for the methods defined to express the business objects behaviour.
Business procedures must be broken down to their elementary components, duplicate components have to be eliminated, and the remaining components have to be assigned to a single owner - normally a certain organization unit. According to the responsibilities of an organization unit, the unit's business procedures have to be compiled from the elementary components starting from the important business events investigated - again according to the basic structure of the model defined at the beginning of the modelling project.
During the real business modelling process one thing is essential:
Always keep in mind, that you are building a model, and in a model everything is possible. A model represents a high level of business abstraction. Therefore it has to be free of technical and organizational aspects. Never structure something or (even worse) exclude something having in mind currently existing implementation inhibitors like technical limitations or organizational constraints. Technical limitations or organizational constraints never should be considered in a model. A business model must be designed to last a very long time and who knows, what kind of technical features exist tomorrow. So if you think, you have found the optimal structure from a business point of view, record it that way.
If necessary, drawbacks and compromises can be applied during technical application desing and implementation. Starting from the abstract level of the model it is the technical designers responsibility to exploit existing technical features as optimal as possible.
Different teams have to be formed during a modelling project, but one principle has top rank when putting the teams together.
It are always the business professionals, which have the lead with respect to the model content. The IS specialists are only responsible for the selection of the adequate documentation form and the strict adherence to the selected documentation principles to guarantee a consistent business model.
What kind of teams are promising in order to achieve a good model? The following table is an attempt to give some guidance:
Modelling Phases and Team Structures
|Definition of the model boundaries||1 teamleader - a person with adminstrative and moderation skills functioning as a facilitator.
2 to 3 business professionals - persons with deep knowledge about the problem domain and the adjacent domains. Middle management with a strong business vision.
|Definition of the model basic structure||1 teamleader - a person with administrative and moderation skills functioning as a facilitator.
2 to 3 IT professionals - persons with good knowledge about modelling principles (good overview) and abstract thinking capabilities.
1 to 2 business professionals - persons with a good overview knowledge about the business domain.
|Collecting information||1 overall team leader with administration skills to coordinate the activities.
Several subteams covering the various business sub-domains.
For each sub-domain a small team of one business professional with good sub-domain skills and one IS specialist with abstraction and recording capabilities as well as some moderation capabilities.
|Restructuring of information / final modelling||1 overall team leader with administration skills to coordinate the activities.
Several subteams covering the various business sub-domains.
For each sub-domain a small team of one or two business professional with good sub-domain skills and one IS specialist with abstraction and modelling skills.
A consolidation team with a moderator (preferably one of the key business professionals), one key IS specialist functioning as the "model master" responsible for the incorporation of interim results in the master model to keep the master model consistent and free of redundancies and several business professionals (preferably the key business professional of all currently existing subteams).