The purpose of this workflow detail is to understand the organization's current (as-is) processes and structure, and based on this understanding, refine the objectives of the business-modeling effort.  

Topics

Find Business Actors and Use Cases Business-Process Analyst Business Use Case (outlined) Business Use-Case Model Find Business Workers and Entities Business Designer Business Analyusis Model Business Use-Case Realization (outline) Supplementary Business Specification Set and Adjsut Objectives Target Organization Asessment (refined) Business Glossary Business Vision Assess target Organization business Architecture Document Business Goal Define the Business Architecture Capture a Common Business Vocabulary Identify Business Goals End User or Customer Maintain Business Rules Business Glossary Business System Business Rule Business Vision (refined) Supplementary Business Specification (refined) Target Organization Assessment Business Rule


Description To top of page

The purpose of this workflow detail is not to describe the entire organization in detail-only enough of it to allow the team to prioritize which parts of the organization to focus on for the remainder of the project. The reasons for doing business modeling should guide the breadth and depth of the effort (see Concepts: Scope of Business Modeling). For example, a broader, more detailed business model will be necessary for a business process re-engineering (BPR) project than for domain modeling. 

[JAC94] (pages 164 - 167) points out, "While we realize that it is vital to produce this model, we wish to emphasize the importance of not spending too much time on it." It also observes, "There are of course situations where it is necessary to go into more detail, but this should be weighed up against the negative consequences of further modeling". This is said because in practice, it is very easy to end up modeling more than is necessary.

This workflow detail usually starts with doing some groundwork before beginning to describe the business use cases. Typically, the organization structure is described, or refined if necessary (see the Organization and Geographic Views of the Business Architecture Document). Business Systems might be defined if a large part of the business will be modeled. Independently of this, a first sketch is made of the Business Entities in the Domain View of the Business Architecture Document. This greatly facilitates communication during the business-modeling workshops by providing a context for discussion. Also, one team may make a start at the Business Workers, possibly beginning with the employment positions within the organization. Although business workers represent roles and should therefore not be confused with positions, the positions provide a helpful starting point for identifying business workers.

Next the Business Goals are defined, using any that have been already identified during Workflow Detail: Assess Business Status. During or after describing the business goals, the Business Use-Case Model is fleshed out with Business Actors and Business Use Cases (and possibly Business Events). Business use cases should be traced back to the business goals that they support. During this tracing, it is possible that you may identify new or refine existing business goals. Where requirements that govern the behavior of the business use cases are uncovered (such as performance requirements), they must be documented in the Supplementary Business Specifications.

Based on the business-modeling objectives, the business use cases are prioritized, and the Business Process View of the Business Architecture Document is updated with the architecturally significant business use cases. Business Use-Case Realizations are then produced for the highest priority business use cases. Business Workers, Business Entities, and Business Events that have already been identified may be used as starting points, although these will be refined. While describing these current business use-case realizations, business rules will be uncovered, which should be captured in the Business Rules-either in a document or directly in the Business Analysis Model.

Any terms, concepts, and definitions discovered while performing these activities must be captured in the Business Glossary. At the end of this workflow detail, objectives and expectations must be reconsidered and adjusted if necessary, based on the experience gained with the highest priority business use cases. If necessary, the Business Vision must be refined. While performing this workflow detail, it might even become obvious that the assumptions or decisions made during Assess Business Status were incorrect. If this is the case, the Target-Organization Assessment might need to be adjusted to reflect the real situation.

Related Information To top of page

This section provides links to additional information related to this workflow detail.

Timing To top of page

Begins in Inception phase, repeated in later iterations as required/planned.

Optionality To top of page

Use this workflow detail if understanding the current business is a goal for the business modeling effort. Skip this workflow detail if you have determined that no major changes will occur to the business processes, or if you plan to develop a new business more or less from scratch.

How to Staff To top of page

Your business-modeling team, all acting as business-process analysts, should interact with the stakeholders' representatives. This extended business-modeling team needs strong business domain knowledge as well as an understanding of how software systems are currently used to automate the business. The core team members need to have good facilitation skills.

Work Guidelines To top of page

Conduct a workshop in which the goal is to understand and outline the business use cases and business actors in the current organization. The following sample techniques can be applied to help you collect correct and relevant information:



This content developed or partially developed by http://www.empulsys.com/rupbm -- This hyperlink in not present in this generated websiteEmpulsys BV.

© Copyright IBM Corp. 1987, 2004. All Rights Reserved.

Rational Unified Process   2003.06.13