It is recommended that you initiate the assessment with a workshop where you gather the key stakeholders (known at that time). The primary purposes of such an initial workshop is to make the business analysts meet the stakeholders of the business-modeling effort, and to gather a comprehensive list of problems from stakeholders of the project. See Technique: Assessment Workshop, for details on how to conduct such an initial workshop.

Identify the stakeholders to the business-modeling effort. Identify stakeholders outside the target organization, such as:

• Customers. Who are the customers? What requirements do customers have on the products, in terms of time-to-market, features, security, robustness and safety, and complexity.
• Competitors. Who are the competitors? In which areas are the competitors strong? What can be learned from competitors?
• Other stakeholders. Are their any other stakeholders involved? Are suppliers and partners involved? Are relationships with them a problem? Are there people with strong influence and opinions that need to be kept in the loop to avoid surprises?

Identify stakeholders within the target organization, such as:

• Project managers
• Sales people
• Customer representatives
• Marketing people

Ask each stakeholder (representatives) what his or her expectations are on the target organization. This can be done either as part of and assessment workshop, or in the form of a questionnaire. 

Interview people to understand their attitudes towards change. If people are negative or skeptic towards the change it is impossible to succeed with the change, unless you can turn the negative attitudes into positive.

You must analyze and quantify your customers' present and future expectations. Do not make assumptions about customer expectations-get the information from the customers. You can either interview the customer, more or less formally, or you can use other market-research techniques, such as telemarketing.

Describe briefly the structure of the organization, the roles, and teams they currently have. Also look at the relationship between different parts of the target organization. For example, what is the relationship between sales and maintenance; or between product development and sales?

It may be inviting to use the business-modeling notation to present this information, but it is often better to use whatever description style the stakeholders are accustomed to, be it text, 'org charts', or the Unified Modeling Language. 

Identify any key persons in the target organization. A key person is a person who has one or several of the following characteristics:

• Has the "ear of the masses".
• Can act as mentor.
• Is an expert in some area(s).
• Is opposed to the business-modeling effort.
• Is responsible for the budget.

To succeed with a business-engineering effort it is important to have the key persons on board. You will need to involve them:

• During the rest of the assessment to gather information.
• As experts to help identify changes to the target organization.
• To contribute in a pilot project, then be mentor.

Notice: Watch out for people that want to discuss principles of business modeling, rather than implement an effective new organization.

Most organizations have their business idea and strategy well documented. In the case where you are documenting "virtual" target organization (meaning that you are doing business modeling to understand the business processes of your target customers in order to build better products), this step could be excluded. 

Explore the strategy to assess:

• Whether current processes are in line with the strategy. 
• Whether it is concrete enough to be understood by the people working in the organization. 
• Whether it is measurable. 
• If it is perceived as realistic. 

See also Work Product Guideline: Target-Organization Assessment for more information. 

Determine the following:

• Who to benchmark. If you are aiming at a detailed benchmarking effort, you would look for non-competitors, but still with sufficient similarities. 
• What metrics to use for benchmarking. Relevant metrics are often a combination of time, cost and quality. 
• How to perform the benchmarking - is it a partnership with another organization, or will it be enough to look for public information?

See also Work Product Guideline: Target-Organization Assessment for more information. 

Measuring an organization is about understanding its business processes and measure them. You need to consider the following:

• Define a set of metrics to use that are a good mix of customer perceived metrics (such as delivery punctuality) and internally perceived metrics (such as production costs). 

• Determine who to collect metrics from. 

• Define effect means of collecting the metrics - it has to be easy and as little "intrusive" as possible, otherwise people will not consider themselves having time to give it. 

See Work Product Guideline: Target-Organization Assessment for more information. 

Ask the stakeholders why they want to change their business processes and business tools. The following are some typical answers, and the effect they have on how you choose to explore and introduce the business processes:

• "We want to use this new technology and need to know how it affects our way of working."
  An example could be a company that has decided to build an e-commerce web-site. The least controversial way of approaching this is in many cases to consider the changes as a new line of business, rather than a change of an existing set of business processes. 
• "We need to make our business processes more effective to meet the competition."
  In this case you need to ask some follow on questions to understand to what degree you need to become more efficient - are we talking about minor improvements, or about major rework and lots of new kinds of technology support. You also need to understand who those competitors are, and what kind of metrics is used to compare. 
• "Our old legacy systems are breaking in the seams and we need to replace them before they burst." This also requires some follow-on questions to understand whether there is an expectation the business processes will change or not. If not, the approach is often to perform some high-level business modeling to get a map of the current organization, sometimes a domain model may suffice. 

Analyze the capacity for change in the target organization. Organizations just like individuals can accommodate change but only within a limited range. Some organizations are better prepared for change than others are. To understand the organizational capacity for change we recommend that you interview the people in the organization, to understand the attitudes, and willingness to change.

Factors to consider are:

• Whether there is a wariness of current conditions - the risk then is that any suggested change is perceived as being for the better and not properly questioned. 
• Whether there is a wariness of change - the organization may have gone through several reorganizations for various reasons that were not perceived as successful by the stakeholders. In this case any suggested changes need to be made rather concrete and be well motivated in order for people working in the organization to even consider whether they are of any value. It is also of value to explore why previous change efforts were not successful.
• What are the general attitudes among people working in the target organization. Are they "young and hungry" or "experienced and settled"? 
• Whether the target organization is an existing one, or whether it is something intended to be build from scratch. If the latter, you need to understand the intended capabilities of people in the new organization, and how much of ramp-up time it would be possible to give them. 

In additions to the soft factors mentioned above, you should also assess the readiness for any new technologies, such as those needed to build an e-business solution. Examples of such technologies are [CONA99]:

• Client/server.

• Database management.

• Programming languages, such as HTML, XML, Java.

• Scripted server pages and servlets, such as Microsoft's Active Server Pages, Java Server Pages.

• Object communication protocols, such as OMG's Common Object Request Broker Architecture (CORBA), the Java standard Remote Method Invocation (RMI), or Microsoft's Distributed Component Object Model (DCOM).

• Components, such as Microsoft's ActiveX/COM.

• Web applications frameworks, such as IBM's WebSphere or Microsoft's Windows DNA.

This assessment will strongly influence the level of risks you should be willing to take when forming the architecture of your solution.

The best way to identify problems is to gather a number of key people for a problem-identification session. See Guideline: Brainstorming and Idea Reduction, for general advice on how to organize such a session.

Ask questions such as:

• What are the problems in the target organization?
• Is there a perception that something is broken?
• Are projects routinely behind schedule or over budget?
• What problems do they have?
• Have any metrics been collected that can be analyzed?

Identify what negative effects each problem has, or will have, if it is not eliminated or reduced, for the projects. To know the effect of a problem helps you understand how critical it is to eliminate or reduce the problem.

Identify root causes of each problem. To know the root causes of a problem helps you understand how to remove or reduce the problem, and how much it will cost. Fishbone Diagrams may be of help. If there are several root causes to a problem you need to weigh them against each other, in which case Pareto Diagrams may be of help. 

Warning: It is very common to rush headlong into defining the solution, rather than taking time to first understand the problem. Write down the problem, and see if you can get everyone to agree on the definition.

Rank the problems with respect to the effect they cause. For example, use a 1-to-5-scale, where 5 is for problems with the most dangerous effect, and 1 is for harmless problems. The primary purpose is to understand the relative importance of the problems.

One of the simplest ways to gain agreement on the definition of the problem, is to write it down and see if everyone agrees. List the problems in a table:

Analyze the results of the collected information and compile a list of areas and issues to focus on. Issues that should be addressed early usually fall into one or several of the following categories:

• Major problem areas. Areas where you can improve the performance of the business processes a lot.
• Areas where you can make short-term profits. Areas where you can show fast results.
• Areas where an improvement will have high visibility.

Document the gathered information and the conclusions in the Work Product: Target-Organization Assessment.

You need to include some recommendations for the future as part of the assessment. The recommendation should describe what approach to take to business modeling. See Concept: Scope of Business Modeling for a set of typical scenarios.