In this chapter we are going to comprehensively cover a method for outlining a business in terms of the business processes that it follows. As with everything outlined in this book, the choice of techniques and the rigour with which they are to be used depends very much on the purpose and organization that is under taking the development. If the development project is for a new business area or a new client, then a comprehensive business analysis is very important. If the devel- opment is for an established business area, and the development team are familiar with that area, then a less rigorous approach might be more sensible. The size and scope of a system also determine the level of business modelling needed; smaller systems development can be carried out with little or no business analysis, as the risk and cost of failure are relatively small.
The techniques discussed here will result in models that have a number of potential uses. The most obvious one is as input to the systems analysis stage of a bespoke development. However, businesses very often choose to use packages, and these models can be used as input to a package evaluation exercise (see Chapter 10). Understanding business processes is also essential for the develop ment of accurate cost-benefit models (see Chapter 7). Figure 8.1 shows the rela- tionship between business process modelling and the stages of cost-benefit modelling and systems analysis. The key outputs of business process modelling are business process definitions (including a process map) and a business object model that in turn are used by later stages.
We shall use UML activity diagrams as a way of describing business processes. We shall also introduce some elementary object modelling as a way of under- standing the business context. UML, however, is only a partial solution to recording a business analysis, and we will introduce some additional notations and conventions along the way. The range of models that can be used to describe a business is unlimited. It is more important at this stage that you gain an under- standing of business modelling than a full understanding of all the possible models that can be used and all the subtle details of the modelling notations. At the end of the chapter we will discuss other models that might be considered here, and as you gain experience and understanding of the notations you might bring them into the business modeling Modelling is about communication, and the choice of model is the one that provides the best communication; in this chapter I have chosen a workable and generally sufficient set of modelling methods and notations for business analysis.
The stages that we will describe in this chapter are indicated in Figure 8.2. The first step is to derive an overall map of the business processes. This gives an over- view of the business area that is to be modelled, and where ultimately we plan to introduce a new IT system. Then the relevant business processes will be analysed using scenario analysis. This will capture a great deal of detail about the business process, and structure it in a particular way. From the scenarios we will produce business workflows that can be described using UML activity diagrams. We will also produce a business object model that identifies some of the key entities in the business environment.
There are many approaches to modelling businesses. This approach is loosely based on the SELECT Perspective method (Allen and Frost, 1998), with elements gleaned from a diverse set of sources. Business modelling to this level of detail is not often included in analysis and design methods, and in practice many organiza tions will omit this stage or carry it out in a limited fashion. This can lead to omis sions later in the development process that emerge at the testing or deployment Metalwho stages. The approach described corresponds to the Unified Process, and we shall discuss the relationship with the Unified Process later, though it does not clearly describe a process for business modelling.