Business Activity Modelling - a Starting Point for Software Development Applied to The Functional Specification of a System for Planning Elderly Care in the European Community (planec)
Dr K. Lunn
Meniscus IT Ltd.
email: kenlunn@firstnet.co.uk
Abstract
One of the most fundamental problem of software engineering is the construction of suitable abstractions. Another is the adequate communication of functionality between all parties involved in the construction and implementation of IT solutions, from end-users, through business managers, to software developers. The approach described here uses the notion of business activity (or business process) as a form of abstraction which can be used in a variety of ways to develop specifications and designs for software systems. The method avoids complex notations, at least at the specification stage. The origins of the ideas began with a multi-national company which had a very diverse set of software solutions implemented in similar businesses world-wide. The ideas have been refined and adapted in the functional specification of a system to support elderly care planning in the European Community, and some aspects of that project are reported in brief in this paper.
The business activity perspective has a number of potential uses. At a strategic level it is a good framework for comparing total IT solutions in similar business environments, and consequently can be used as a support for strategic planning of systems. In the procurement process, it provides a good framework for scoping and defining functionality of a required system, and for comparing proposed solutions. In the business reengineering phase, it can be used as the basis for the terminology in describing actual processes and quantifying aspects of changes to business operations. In the software specification and design process it can be used in an object modelling process as a framework for driving the dynamic modelling in a way similar to the event-trace methods of OMT.
The author has used the techniques briefly described here in a variety of consultancy projects. The common characteristic of these projects have been:
A number of business environments with similar but non-identical needs wishing to share software solutions.
A need to communicate to senior management, often with no computing background, the scope and functionality of computer systems.
A need to compare at a gross and at a detailed level the functionality of different computer solutions.
A need to relate computer systems to business operations.
A need to quantify the effects of system changes (of both computer and business operations) for the purpose of assessing financial returns and quality improvements.
A need to involve non-IT staff in the analysis and design of systems.
Although no panacea, the business activity approach has proved to be very effective in communication, obtaining consensus, and co-ordinating group activities. By removing temporal and information flow considerations, which are often a source of confusion and disagreement, it enables a comprehensive map of a business to be constructed; it can be used later to introduce information flow and time dependencies for the purposes of deeper analysis and design.
The approach described here has been pragmatic and driven by the needs of applications. However, a common theme is emerging, and hopefully through the broader application of the techniques they can be related to and/or integrated with established methodologies. The use of the approach in PLANEC has begun to open up the integration into object modelling in a way which appears consistent with and complementary to established approaches.
The PLANEC application
The PLANEC consortium has undertaken the ambitious task of producing a demonstrator computer system which can be used in all member states of the EC; it will support the strategic planning of elderly care provision by a broad range of organisations from municipalities to hospitals and other service providers. The consortium is led by the Stakes Research Institute in Finland, and has partners in Holland, Spain, Germany and the UK, and consists of research social scientists and practitioners in the field of elderly care; a software house has been contracted to construct the demonstrator system, but the responsibility for specifying functionality rests with the social scientists. The author has been facilitating the specification process, firstly by teaching the rudiments of object modelling, and then by introducing and developing the notion of activity modelling.
Although the basic needs of the elderly may be similar in each locality, the provision of services to meet those needs varies widely in type and organisational structure. Each country has different legislation, different infrastructure, and different policies. The greatest challenge, from a software design perspective, has been to devise a suitable abstract description of the problem in a way that can be understood by the social scientists who are steering the development, the software house which will be producing the demonstrator, the potential users of the system, and other interested third-parties.
Object modelling was chosen as a design method for the following reasons:
it is a good basis for prototype-driven, iterative methods of development;
there is a good correspondence between some aspects of the modelling and social science methods;
the methodology is easy to teach at an abstract level;
the resulting designs are clear and easy to communicate to non-computing personnel.
The project found early-on that the greatest challenge was providing a common framework within which to describe the differing approaches to elderly-care provision. The solution adopted was to introduce ideas from Business Process Re-engineering, using an activity (or process) model. This model was then mapped back into the object-modelling. This method is a novel extension of object modelling, and serves as a useful contribution to computer science in its own right.
A Three-Level Business Activity Model
A business activity is a logical grouping of events which can be agreed as a fundamental element of a business. Although some implicit ordering may emerge, the intention is to describe a whole business as a set of about 200 to 300 activities without concern about the order or the interactions of the individual activities. These activities are grouped on three levels. The top level should be no more than about ten activities. For a manufacturing company, these activities may be:
PLAN - develop the tactical and strategic plans of the company
BUY - all purchasing activities and the recording of these activities, including payment
SELL - all selling activities and the recording of these activities, including revenue
MANUFACTURE - all manufacturing activities and the recording of these activities
DEVELOP / DECOMMISSION - all construction and decommissioning of plant
FINANCE - monetary flow and control activities, including investments, etc.
RESEARCH - all research activities
It can be seen that at the abstract level these are very gross divisions of the company behaviour, which may be considered too obvious and simplistic. However, experience shows that it is easy to obtain broad agreement on these. Using a group of experienced researches and practitioners in the field of elderly care, a workshop produced the following breakdown of elderly care provision into:
POLICY - Setting of national policy, regional policy, local policy. Setting of voluntary organisation policy. Identification of cultural norms. Commercial organisation policy (e.g. health care, residential homes, sheltered houses). Negotiation with providers, planners, financiers, and with different policy makers.
PROVIDE / CONSUME - Activities involved in the provision and consumption of care at the organisational and individual level. Organisational planning. Purchasing, provision. Developing of the service. Personnel and day-to-day management. Negotiation with planners and financier. Business plan and implementation. Cash management and financial management. Assessment of needs. Allocation of care.
MONITOR / EVALUATE - Estimation of demand. Creation of information services. Identification of goals. Setting evaluation criteria. Collecting information. Analysing information. Identifying and reporting successes / problems / failures.
FINANCE - Raise funds (e.g. taxation, fees, statutory and private insurance). Budget setting. Control of spending. Forward projection. Allocation of funds. Release of funds.
PLAN - Strategic and tactical planning activities. National, regional and organisation levels. Estimation. Negotiation. Goal setting. Implementation planning. Realisation of goals. Purchase, sell provide. Identification and realisation of policy. Developing of provision.
Agreement on these took less than a morning, and the breakdown has survived six months of scrutiny.
The activity model is intended to hide organisational structure, and simply to describe the functionality of the organisation. Activities may be implemented in many different ways, sometimes even within the same company; for example there may be many types of manufacturing plant within a company, producing different goods, or producing the same goods in different ways. Having obtained the common abstraction it is possible then to map it back onto organisational structure.
The importance of the omission of information flow and temporal considerations cannot be over-emphasised. There is rarely any disagreement on what an organisation does, but there is always disagreement on how it does it. Flows can be added later, once functionality has been agreed.
The second level breaks down into finer detail each of the first level activities. Again, this is a logical grouping, and any temporal or informational links are implicit and/or coincidental. A second level breakdown for the SELL activity of a manufacturing business might be:
NEGOTIATE CONTRACT - all activities involving negotiations and setting up of contracts with a customer.
TAKE ORDER - all activities relating to order taking
DELIVER GOODS - all activities relating to delivery
ACCEPT RETURNS - all activities relating to return of unwanted or unsatisfactory goods
INVOICE CUSTOMER - all activities relating to invoicing
ACCEPT PAYMENT - all activities relating to acceptance of payment
In practice there are likely to be at least double these activities for a particular business type. A second level breakdown for the PLAN activity for elderly care provision was derived in a workshop as:
Order to start planning
Collect information
Analyse information
Set up strategic goals
Set operational goals
Arrange Resources
Negotiate with actors
Make proposal
Consult / liase
Approve plan
Implement plan
Again, this took about two hours to agree and has survived six months of scrutiny.
Finally, the second level activities can be broken down into third-level groupings. For the elderly care planning system, this was only done for the PLAN and MONITOR/EVALUATE activities, as these are the principal focus of the system being developed. A third level grouping for the INVOICE activity in a manufacturing business might be:
Identify goods delivered and accepted
Price goods
Apply discounts
Print invoice
Issue invoice
Again, this is a little simplistic, and it is likely to involve at least twice as many activities in a given business. The third level activity for Analyse Information in PLAN was:
Analyse need/demand
Analyse qualitative output
Analyse quantitative output
Analyse material input
Analyse immaterial input
Analyse effectiveness
Analyse productivity
Analyse economy
Analyse efficiency
Analyse equity
Identify problems and explanations
Identify successes and explanations
Produce projections of future demand
Evaluate against state of the art
This was extended towards the end of the project from a much shorter list. The lesson to be learnt is that the third level is more open to changes. Practical experience of trying to break down to four levels shows that it is very difficult to gain agreement, and becomes much more related to how a business operates rather than what it does.
Having obtained agreement on the third level of activity, it is possible to describe each activity in some detail. This has not yet been done for the PLANEC application. For a manufacturing company, such a description can take up many hundreds of pages. However, the principle value of the activity modelling approach is its conciseness and brevity. Detailed descriptions are at times either too vague or too prescriptive. However, for some purposes, such as software tendering, it is vital to elaborate on activities for a third party to understand.
The initial value of constructing a business activity model
It can be seen that the above breakdown is in some sense simplistic, and it leaves out a lot of detail. However, experience shows that there is considerable value in the process of constructing such a model. The following benefits have emerged:
It is possible to construct the model with business personnel, without consideration of the operation of computer systems, or indeed any consideration of software design issues.
Agreement is easy to obtain up to three levels.
Summarising a business in such a way, which can usually be printed on a single sheet of A4 paper, provides a framework for discussions which is manageable.
The process clarifies terminology.
The model can be constructed in two or three days using personnel with a high-level view of business operations.
Although it is a systemic view of a business, it can be understood easily by anyone with very little introduction.
It builds consensus, and emphasises areas of commonality.
By focusing on function rather than organisational structure, it can be used as a basis for discussion in business process re-engineering, and it can build a bridge between software functionality descriptions and business organisation descriptions.
Strategic uses of a business activity model
Perhaps the greatest value of an activity model at this level is its ability to provide a concise, easily explained terminology, organised in a simple framework, which uses the phraseology of the domain. Some of the uses to which they have been applied successfully are listed below.
Mapping current IT solutions
Using the activity model as a checklist, it is possible to identify all IT systems in use within a business. This is a gross level map; for example a manufacturing business may have different types of manufacturing plant using different software systems. It may be desirable to produce a number of maps for the business, depending on organisational structure, say one for each production stream.
The result of doing this for one organisation highlighted the radical difference in IT support between similar organisations in different countries, from one using over a hundred systems to one using thirty to achieve the same purpose in similar markets. The experience of using this framework was very positive, as it was possible to identify possible changes in IT usage within different businesses, and to relate them to possible business process changes.
Scoping of a package
It is possible to rate a package against each activity. The author has worked with various numeric ratings. The most effective scheme, however, has been to rate the package against each third-level activity according to the scheme:
FULL - the IT package supports all aspects of the activity where IT support is reasonably expected
PARTIAL - the IT package supports some aspects of the activity, but not all, where IT support is reasonably expected
NONE - the IT package supports none of the IT requirements of the activity
NOT APPLICABLE - the activity requires no IT support
In the process of rating the package, the partial support ratings should be accompanied by a description of the deficiencies of the package.
Comparison of packages
Using a rating scheme as above, it is possible to provide a very descriptive and concise overview of the similarities and differences of two or more packages.
Request for tender
The activity model can be used as a checklist for a package supplier or systems developer. By highlighting the activities which need IT support, the supplier can be asked to address the needs of the business. This requires a full description of the activities.
Identifying strengths and weaknesses of IT provision
This was done by the PLANEC group, to establish market needs for the proposed PLANEC system. The activity model was used to construct a questionnaire to identify strengths and weakness of the IT provision in different organisations which need to support the planning of elderly care provision. By collecting information in this form, it is possible to relate the current market to the planned functionality of PLANEC.
Identifying actors
By cross-referencing interested parties with activities, it is possible to gain an understanding of how a system may be used. This was done by the PLANEC partners in their own countries, and it opened up a number of organisational differences between the countries. In each case, there are different actors operating elderly care provision.
Analytical uses of a business activity model
So far, temporal and information flow aspects have been omitted from the model. The reason for this is that at the functional level similar businesses rarely differ. However, at the operational level they do. By introducing temporal and information flows, analysis of different aspects of a business can be incorporated. Two simplified examples drawn from actual projects are given below. They use activities defined in the activity model to indicate information flows, and the effect of delays on information flows.
A problem of invoice errors
Chinese whispers within a group of companies indicated that one company had cut its invoice error rate from 5% of all invoices having an error, to almost zero, by changing from one computer package. This was being used as an argument for a wider utilisation of the given package. To substantiate the claim, an analysis was done of the business process before and after the package installation. Prior to the installation, the information flow relating to orders was:
Changes to standing orders were taken by the salesman visiting the customer. These were taken on paper, and by the time the salesman had returned to the office, and the changes recorded on the computer system, an average of ten days elapsed. The consequence was that a high number of deliveries, approximately 5%, were not as the customer now wanted them. Therefore there were returns which the depot recorded on paper, and sometimes extra emergency deliveries. Returns took five days to record on the computer system. However, the practice was to issue invoices the day after delivery, and the standing orders were used. The customer would then query the invoice, usually at the end of the 30 day payment period; then they would pay the re-issued and correct invoice at the end of a further 30 days payment period.
The net effect of 5% of invoices being paid 30 days late is that the company needs approximately half a percent of its annual turnover needlessly tied up in cash, which for a multi-million pound turnover is a substantial cost to the business. The system looked ridiculously inefficient, but it had been set up fifteen years earlier in a more stable marketplace with fewer products, and when batch processing was the most cost-effective means of providing IT support.
A new system was introduced which allowed telephone ordering, and for the depot to record directly onto the computer system any returns. A burden was taken off the sales force, who could then concentrate more on selling to new customers rather than servicing existing ones. Customers were sold the new process on the basis that they could adjust their stock levels more easily, and therefore reduce their own working capital demands. The result was that hardly any deliveries did not match customers expectations. There were some added benefits of increased customer satisfaction and reduction in extra deliveries to meet needs of customers. The change in the flow of information was as follows.
Explained in this way, it was clear that the new software package was not of a higher quality, thereby reducing invoice errors, but that it facilitated a change in business operation which allowed the errors to be removed. The decision to adopt a change in IT to tackle similar problems could then be taken in a more informed way; arguably changes could have been made to existing systems to achieve the same effect.
Stock reduction
Another Chinese whisper about a computer system in another business area was that it reduced stocks in the warehouse and reduced the number of stock-outs. Again, analysis of the process using information flows between activities indicated the full reason for the improvement in stock management. The flows before the new system were:
Customers would typically order about 15 days in advance of delivery, to fit in with their own production schedules. Orders were taken, irrespective of stock levels in the warehouse. Production would then schedule its activities to maintain stock levels in the warehouse. The new system added an information flow that allowed the production activity to see the orders. This meant that production could respond to changes in order levels rather than changes in stock levels. The result was that stocks could be reduced.
Discussion
The above examples could have been described in many ways. The use of the activities from the business activity model meant that the problem could be explained in terminology which could be understood by different businesses. The use of information flows, with delays, proved very effective at describing the benefits of changes in IT to business managers in ways that could be quantified.
Object Modelling with Activity Models
Activities are logically arranged groups of events. Dynamic modelling, through event traces, is one way of linking events to objects, thereby defining object behaviour and identifying new objects. Activities can be used in a similar way to identify operations on objects. This can be done by simply producing a matrix; a simplified example from the PLANEC application is illustrated below. This is for the ARRANGE RESOURCES activity. PROVIDER, FUNDER and RESOURCE are three of the candidate objects for the PLANEC system.
A similar cross-referencing process can be used to identify attributes.
This process has proved remarkably productive and effective in defining functionality. Over a two day workshop involving the representatives of the consortium, approximately 250 operations and attributes were identified and agreed. The list for one of the objects is given in appendix 2.
The high level specification ended up with nine core objects in the specification:
RESOURCE
POPULATION
CLIENTS
CARE
COSTS
FUNDER
PURCHASER
PROVIDER
PLAN
The objects are related according to the following diagram
The PLAN object interacts with all other objects, and so has been drawn as above for clarity.
These objects are really large groupings which will need further refinement with specialisations and component objects to be devised in the design phase. The objective of the functional specification has been to obtain a logical and complete grouping of all the data and functionality requirements for the first prototype.
The activity model was used extensively to drive the process of defining these objects and their relationships. The process of cross-referencing objects with activities clarified a number of issues an reduced the set of candidate objects considerably.
The relationship of activity modelling to object modelling techniques
An object model, consisting of objects, their attributes, their operations, and their relationships, can be viewed as a computable representation of the real world. Dynamic modelling, through event traces and state diagrams, and functional modelling, through data flow diagrams, can be viewed as a means of refining the object model. Activity models, as used above, can be thought of in the same light. Thus they extend the repertoire of available tools to analyse a business environment.
The difference between activity models and event traces (or use-cases), is their omission of temporal considerations. In this sense they are weaker than dynamic models. On the other hand, they prove easier to deal with in the earlier stages of analysis. In particular, the lack of temporal and information flow considerations allows specification of system functionality without overly constraining implementation.
Planned research
The above methods and techniques have emerged initially as ad hoc approaches to solving high-level analysis and design problems, and communicating IT issues to senior management and to non-IT researchers. They have not, therefore, been related to the literature. Two avenues of research are opening up. One is to extend existing methods, using the activity modelling approach. Another is to investigate the use of activity models as a bridge between business process re-engineering and software engineering.
Conclusion
Activity models are proving a useful means of reasoning about systems at an abstract level. By omitting temporal and information flow considerations, they allow high level reasoning about systems and the environment in which the systems operate. They are largely independent of organisational considerations. They can be used as a framework for strategic planning and analysis, as a basis for a common terminology in BPR, and as an entry point for specification and initial design of systems in an object modelling approach. They offer a possible, useful extension to existing methods, and a possible bridge between BPR and software engineering. They have been proven in a number of practical projects where the characteristics of the projects have involved differing organisations which provide similar products or services.