Elsewhere I have described what I understand by 'perspectives' in relation to stakeholders and business systems developments. In this note I want to extend this to include the effect that such perspectives have on developments. A secondary objective is to reduce the number of misunderstandings held by some candidates for the Certificate in Business Analysis Practice, and thereby to make my life as an examiner a little easier!
Perspective is simply another word for a view or a viewpoint. In the previous note I suggested alternative viewpoints of why the railway system exists, with each viewpoint being a perspective held by one or more people the stakeholders. These differed because different groups hold different views based on their own experiences, expectations, ethics, and so on. The differences between perspectives may be quite minor, they can be significant; either way they pose a problem.
In business systems development the aim is to develop a system which supports the achievement of agreed business objectives. But if there are stakeholders who hold different views of the business, perhaps disagreeing about exactly what the business should do, of how it might go about it, or even of why the business exists, then it will be a major problem to satisfy all the stakeholders because each will 'see' a different solution.
This is where the approach popularly known as 'soft systems' comes into its own. And, whether or not he ever used this name for it, Peter Checkland is recognised as the originator of the approach.
Checkland has authored a number of texts on the subject including 'Learning for Action', written in conjunction with John Poulter. This contains one of the easier descriptions of root definitions and perspectives with some interesting examples and asides. Definitely worth a read.
In the world of soft systems each perspective is defined in terms of a root definition comprised of six elements - the CATWOE components.
It is not the purpose of this note to discuss these fully, but it should be recognised that each root definition (RD) expresses the characteristics of a potential system. Each RD will include a statement of a Transformation which will express that perspective's view of the main change of state of some entity between its input state and its output state; each will include a World View expressing why such a transformation is thought to be a good thing; each will be conditioned by Environmental factors; and so on for all six elements.
Thus the six components of a root definition describe one perspective, one view, of what a business system of the future should be, who benefits from it (C), who operates it (A), the main transform activity (T), the world view that makes this a system to be aimed for (W), who owns it (O), and what constrains or conditions it (E). So what is a Business Activity Model?
A Business Activity Model (BAM) is effectively an expansion of a root definition. The RD defines a business system and the corresponding BAM expands that definition to show the set of activities that would be needed to support it. A BAM shows these as a dependency structure.
(An historical aside - in some respects a BAM is similar to the old future logical representations of systems from the seventies and eighties in that it shows activities which would be necessary, but not how they would be implemented. It is a vision of a future; one that says, if the business is to achieve or live up to the root definition then these are the activities that it would need to perform. Different root definitions would require different sets of activities and so different BAMs.)
Developing a BAM is not a trivial task but it is made a lot easier when you have a well-formed root definition and when you understand the control cycle of Plan, Enable, Do, Review.
All business systems will include activities that plan what needs to be done, plus activities which obtain the resources required to do these things, plus the activities which actually do things; a classic Plan, Enable, Do cycle. In a well defined system there will also be activities to monitor and control these activities against a set of defined criteria.
(By the way, Peter Checkland never said that activities needed to be labelled with Ps, Es etc., he just has activities, and he encloses all P, E and D activities in a single all-embracing activity to show that everything need to be monitored and controlled against set criteria.)
How can we make use of the control cycle? Well, the BAM is a dependency structure and so we can work back from the main Doing activity by adding the Enabling activities which would obtain the required resources, and then add the Planning activities which identify what resources are needed. The main Doing activity must be related to the T of the root definition. After all, the T is a transform so it is doing. A further obvious correlation with the root definition is that the Es define P activities in the BAM. This is obvious when you "see" it. If an environmental factor is, say, legislation on emissions, then you had better have a business activity which keeps an eye on the rules. This would be shown as a P activity in the BAM.
So, are there some rules of thumb here? Of course there are. The T (from CATWOE) becomes a D; each E (from CATWOE) becomes a P. Of course there can be other P activities. The E activities sit between the Ps and Ds in a dependency structure. Enclose the whole lot and place define criteria, monitor and control activities on the outside with a dependency arrow from control back to the embracing activity symbol.
This is not intended in any way to trivialise Root Definitions and BAMs, nor to suggest that they are not sometimes difficult, but the principles are sensible. People make them more difficult that they need to be or completely miss the point. And this is what I want to finish with what a BAM is NOT!
The notational elements of a BAM can be used to represent many aspects of business activity but their principal use is for visualising and discussing alternative business systems. I would emphasise business system here; not computer system, not project to introduce a computer system. Yes, some activities might require to be automated but the business system we typically model is what would need to be in place in the future, post-project if you like. It should show all the activities needed to achieve the Transform, irrespective of how they might be implemented.
Pretty standard errors that we see in exams are that the BAM takes a narrow scope, usually because the BAM is trying to show represent a project to produce a business system. You would not expect to see Purchase hardware as an activity (unless of course the business you were modelling bought and sold hardware!). The BAM shows the business system that will result from a project, not the project itself.
And finally ...
Of course we address Root Definition and BAM fully in our Business Analysis Practice course.