Embed Size (px)
Citation preview
Edited by Debra Paul
and Donald Yeates
Business Analysis
Business AnalysisEdited by Debra Paul and Donald Yeates
Endorsed by IBSDF
Business Analysis is a practical introductory guide for anyoneinvolved with business analysis, improving efficiency, or thealignment of IT with organisational objectives.
Business Analysis explores: the key early stages of the development lifecycle; the nature of business problems; howorganisations develop; and the drivers that contribute to thedevelopment of the business analysis discipline.
Practical business analysis techniquesBusiness systems developmentBusiness process managementManaging changeInformation resource management
About the authors
Business Analysis has been written by a team of experts whoare both practitioners and educators in the business analysisfield. They are all members of the International BusinessSystems Development Forum.
‘Great breadth,
good depth.
A highly
recommended
introduction to
Business Analysis.’
Neil Venn,
Seabright Consulting
This book is brought to you by the British Computer Society – the leading professional and learned society in the field of computers and information systems.
� ������ ������
� � � � � � � � � � � � � � �
BCS FIRST FLOOR, BLOCK D,NORTH STAR HOUSE, NORTH STAR AVENUE,SWINDON, SN2 1FA, UK
B U S I N E S S
BCS_Books_Business_Analysis_Amended:Layout 1 22/8/07 12:39 Page 1
Business Analysis
The British Computer SocietyThe British Computer Society is the leading professional body for the IT industry.
With members in over 100 countries, the BCS is the professional and learned society
in the field of computers and information systems.
The BCS is responsible for setting standards for the IT profession. It is also leading the
change in public perception and appreciation of the economic and social importance
of professionally managed IT projects and programmes. In this capacity, the Society
advises, informs and persuades industry and government on successful IT
implementation.
IT is affecting every part of our lives and that is why the BCS is determined to promote
IT as the profession of the 21st century.
Further Information
Further information about BCS can be obtained from: The British Computer Society,
First Floor, Block D, North Star House, North Star Avenue, Swindon, SN2 1FA, UK.
Telephone: 0845 300 4417 (UK only) or þ 44 (0)1793 417 424 (overseas)
Email: [email protected]
Web: www.bcs.org
International Business Systems Development Forum (IBSDF)The IBSDF is an independent, not-for-profit organization dedicated to the develop-
ment and promotion of ‘best practice’ in business analysis and information systems
(IS) development. It is wholly owned and run by its international membership.
The objectives of the IBSDF are:
1. to provide a forum for the identification and adoption of international best
practice in business analysis and related IS development;
2. to broadcast business analysis and IS development theory and practice within
the Business and IS and IT communities;
3. to ensure that business analysis and IS development qualifications meet the
requirements of business and IS and IT communities.
To achieve its objectives, the IBSDF:
l organizes conferences and seminars;
l liaises with other standards bodies;
l publishes papers;
l produces books;
l provides consultancy support;
l serves on relevant qualifications committees.
The IBSDF is constantly on the look out for new members who would wish to be
active in helping to achieve its objectives.
Further information
Further information about the IBSDF can be obtained from IBSDF, Orchard House,
Dingle Lane, Sandbach, Cheshire, CW11 1FY, UK.
Telephone þ 44 (0)1270 765363 and fax þ 44 (0)1270 750018
Email Jim Stone, Chairman at [email protected]
BusinessAnalysisEDITED BY
Debra Paul and Donald Yeates
# 2006 The British Computer Society
Reprinted July 2006
All rights reserved. Apart from any fair dealing for the purposes of research or private study, or
criticism or review, as permitted by the Copyright Designs and Patents Act 1988, no part of
this publication may be reproduced, stored or transmitted in any form or by any means,
except with the prior permission in writing of the Publisher, or in the case of reprographic
reproduction, in accordance with the terms of the licences issued by the Copyright Licensing
Agency. Enquiries for permission to reproduce material outside those terms should be
directed to the Publisher.
The British Computer Society
Publishing and Information Products
First Floor, Block D
North Star House
North Star Avenue
Swindon SN2 1FA
UK
www.bcs.org
ISBN 10 1-902505-70-0
ISBN 13 978-1-902505-70-1
British Cataloguing in Publication Data.
A CIP catalogue record for this book is available at the British Library.
All trademarks, registered names, etc. acknowledged in this publication are to be the property
of their respective owners.
Disclaimer:
The views expressed in this book are of the author(s) and do not necessarily reflect the views
of BCS except where explicitly stated as such.
Although every care has been taken by the authors and BCS in the preparation of the
publication, no warranty is given by the authors or BCS as Publisher as to the accuracy or
completeness of the information contained within it and neither the authors nor BCS shall be
responsible or liable for any loss or damage whatsoever arising by virtue of such information
or any instructions or advice contained within this publication or by any of the
aforementioned.
Typeset by Tradespools, Chippenham, Wiltshire.
Printed at Antony Rowe Ltd., Chippenham, Wiltshire.
Contents
List of figures and tables ix
Contributors xii
Foreword xiv
Abbreviations xv
Preface Debra Paul and Donald Yeates xvii
1 What is business analysis? 1
DEBRA PAUL
Introduction 1
The origins of business analysis 2
The development of business analysis 2
The scope of business analysis work 4
The role and responsibilities of a business analyst 9
References 11
Further reading 11
2 The competencies of a business analyst 13
CRAIG ROLLASON
Introduction 13
Behavioural skills and personal qualities 14
Business knowledge 18
Techniques 21
How can I develop my competencies? 23
The Skills Framework for the Information Age 24
Summary 26
References 27
Further reading 27
Useful websites 27
3 Strategy analysis 29
DONALD YEATES
Introduction 29
The context for strategy 29
What is strategy? 31
Strategy development 32
External environment analysis 35
Internal environment analysis 40
SWOT analysis 43
v
Implementing strategy 44
Summary 47
References 47
Further reading 47
4 The business analysis process model 49
DEBRA PAUL
Introduction 49
An approach to problem-solving 49
The process model 51
Investigating the situation 52
Considering the perspectives 54
Analysing the needs 57
Evaluating the options 58
Defining the requirements 60
Summary 62
References 63
Further reading 63
5 Investigation techniques 65
DEBRA PAUL AND MALCOLM EVA
Introduction 65
Interviews 65
Workshops 68
Observation 71
Scenarios 74
Prototyping 77
Quantitative approaches 78
Summary 81
References 81
Further reading 82
6 Stakeholder analysis and management 83
JAMES CADLE
Introduction 83
Stakeholder categories and identification 83
Analysing stakeholders 86
Stakeholder management strategies 87
Managing stakeholders 91
Summary 92
Further reading 93
7 Modelling the business system 95
DOT TUDOR
Introduction 95
Business Analysis
vi
Soft Systems Methodology 96
Documenting business situations 98
Business perspectives 99
Business activity models 102
Business events and business rules 107
Critical success factors and key performance indicators 109
Validating a business activity model 109
Use of the business activity model in gap analysis 110
Summary 110
Further reading 111
8 Business process modelling 113
KEITH HINDLE
Introduction 113
What is business process modelling? 113
The importance of process modelling 115
The business process modelling technique 118
Improving business processes 126
Planning the business process improvement initiative 130
Advanced process modelling concepts 131
Summary 133
Further reading 133
Useful websites 134
9 Requirements engineering 135
MALCOLM EVA
Introduction 135
The problems with requirements 135
The place of requirements engineering and the systems
development lifecycle 137
A process for requirements engineering 139
Actors 141
Requirements elicitation 143
Building the requirements list 147
Requirements analysis 147
Documenting the requirements 149
Validating requirements 155
Managing changes to requirements 156
Summary 157
References 157
Further reading 157
10 Modelling the IT system 159
DEBRA PAUL AND JAMES CADLE
Introduction 159
Contents
vii
Modelling system functions 159
Modelling system data 162
Summary 175
Further reading 176
11 Managing the information resource 177
TONY JENKINS
Introduction 177
Managing data resources 178
Support for the systems development lifecycle 180
Valuing and classifying data 182
Supporting business activities 184
Data administration 187
Data modelling 191
Technology for capturing and storing data 191
Security, governance and related issues 192
Summary 194
References 194
Further reading 194
12 Making a business and financial case 195
JAMES CADLE
Introduction 195
The business case in the project lifecycle 195
Identifying options 196
Assessing project feasibility 198
Structure of a business case 201
Investment appraisal 209
Presentation of a business case 211
Benefits realization 212
Summary 213
Further reading 214
13 Managing business change 215
KEITH HINDLE
Introduction 215
Introducing a new system 215
Emotions and the change process 216
The need for change management 220
The change process 220
Summary 231
References 232
Further reading 232
Index 233
Business Analysis
viii
List of �gures and tables
Figure 1.1 Potential range of the business analyst role 6
Figure 1.2 The three views of a business system 8
Figure 2.1 Competencies of a business analyst 14
Figure 3.1 Strategy creation 33
Figure 3.2 Porter’s five forces model 38
Figure 3.3 The Boston Box 42
Figure 3.4 Format of a SWOT matrix 43
Figure 3.5 The McKinsey 7-S model 45
Figure 3.6 The balanced business scorecard 46
Figure 4.1 Problem-solving model 50
Figure 4.2 The business analysis process model 52
Figure 5.1 Structure of an interview 67
Figure 5.2 Workshop techniques 71
Figure 5.3 STROBE 73
Figure 5.4 Process for developing scenarios 75
Figure 6.1 Stakeholder management in the project lifecycle 84
Figure 6.2 Generic stakeholder categories 84
Figure 6.3 Stakeholder power/interest analysis 87
Figure 6.4 Basic stakeholder management strategies 88
Figure 7.1 Checkland’s soft systems methodology 97
Figure 7.2 Example of a rich picture 98
Figure 7.3 Example of a mind map for a sales system 99
Figure 7.4 Business activity model notation using cloud symbols 104
Figure 7.5 Business activity model for a travel company 105
Figure 7.6 Business event triggering activities 108
Figure 8.1 Outline business process model 114
Figure 8.2 The process concept 114
Figure 8.3 Process versus functional view of a business 115
Figure 8.4 Business process and the embedded IT system 117
Figure 8.5 Overview process map for a library service 120
Figure 8.6 Example value chain 121
Figure 8.7 Porter’s generic value chain 121
Figure 8.8 End-to-end process model 124
Figure 8.9 Process model with alternative paths 124
Figure 8.10 Flow conventions 125
Figure 8.11 Process map with link from other process 125
Figure 8.12 Detailed swim-lane diagram (partial) 126
Figure 8.13 Handoffs on the high-level process model 127
ix
Figure 9.1 The waterfall lifecycle 138
Figure 9.2 The ‘V’ model 139
Figure 9.3 Requirements engineering process 140
Figure 9.4 Example decision tree to support a requirement ‘Calculate
Customer discount’ 141
Figure 9.5 Tacit to explicit knowledge 146
Figure 9.6 Requirements catalogue template 150
Figure 10.1 Use case diagram for project control system 161
Figure 10.2 Use case diagram showing <<include>> 162
Figure 10.3 Use case diagram showing <<include>> and <<extend>> 163
Figure 10.4 Diagram showing one-to-many relationship 165
Figure 10.5 Diagram showing many-to-many relationship 166
Figure 10.6 Diagram showing resolved many-to-many relationship 166
Figure 10.7 Diagram showing fully mandatory one-to-many
relationship 167
Figure 10.8 Diagram showing fully optional one-to-many relationship 167
Figure 10.9 Mandatory parent entity with optional child entities 168
Figure 10.10 Optional parent entity with mandatory child entities 168
Figure 10.11 Named relationship between entities 169
Figure 10.12 Exclusive relationships 169
Figure 10.13 Entity relationship diagram for a sales system 170
Figure 10.14 Definition of the class ‘Account’ 171
Figure 10.15 Association between two classes 172
Figure 10.16 Association with one-to-many multiplicity 172
Figure 10.17 Association with one-to-zero-to-one multiplicity 173
Figure 10.18 Association with one-to-one-to-many multiplicity 173
Figure 10.19 Association with one-one-to-20 multiplicity 173
Figure 10.20 Association with many-to-many multiplicity 174
Figure 10.21 Association class 174
Figure 10.22 Generalization structure 175
Figure 11.1 Extract from a Corporate Data Model 181
Figure 12.1 The business case in the project lifecycle 196
Figure 12.2 Process for developing options 197
Figure 12.3 Incremental options 198
Figure 12.4 Aspects of feasibility 199
Figure 12.5 Force-field analysis 200
Figure 12.6 Categories of costs and benefits 203
Figure 12.7 Gantt/bar chart for proposed project 209
Figure 12.8 Benefits realization approach 212
Figure 13.1 Emotions and the change process 217
Figure 13.2 Learning cycle 218
Figure 13.3 Logical levels model 219
Figure 13.4 The power/impact grid 222
Figure 13.5 Force-field analysis 223
Figure 13.6 Concerns-based adoption model – stages of concern 226
x
Business Analysis
Table 9.1 Levels of tacit and explicit knowledge 145
Table 9.2 Techniques and knowledge types 146
Table 9.3 Example requirements list 147
Table 12.1 Payback calculation 209
Table 12.2 Net present value calculation 210
Figures
xi
Contributors
James Cadle has been involved in the management services field for 27
years, occupying a variety of roles from consultant to project manager and
operations manager. Since 1985, James has specialized in the areas of
project management and business/systems analysis, occupying a number
of senior management roles within London Regional Transport and then
with Sema Group plc. James is currently a director of Assist Knowledge
Development and specializes in business analysis and project manage-
ment training and consultancy.
Malcolm Eva has been working in IT since 1980, first as a programmer and
then in systems analysis and business analysis. He has been a senior
lecturer in information systems at Thames Polytechnic (now Greenwich
University) and University College Northampton. He has also worked for
both the Ministry of Defence and BT as a systems analyst and trainer in
systems analysis. Malcolm is a founding member of the International
Business Systems Development Forum (IBSDF) and a member of the BCS
Requirements Engineering and Information Systems Methodologies
Specialist Groups.
Keith Hindle has over 30 years of IT and business experience in training
and consultancy in the areas of business analysis and system development,
in fields ranging from manufacturing to insurance and public education.
Keith is currently the business development manager at the international
IT solutions company Parity. He is a member of the BCS Business-IT
Interface and Requirements Engineering Specialist Groups and a member
of the Institute of IT Training. He was the chair of the judging panel for the
BCS’s Business Analyst of the Year Award.
Tony Jenkins is senior partner in the European consulting group,
DOMAINetc, and a chartered member of BCS. He has worked in IT for
37 years, his interests centring on the interfaces between data manage-
ment, systems development processes, IT service management and
business processes. He is a member of the BCS Council, Vice Chair of
the BCS Data Management Specialist Group and chair of the founding
committee of the IBSDF. He is also a BSD, ITSM, Applications Manage-
ment and ITILIM examiner for the Information Systems Examinations
Board (ISEB).
xii
Debra Paul (co-editor) has worked in IT for over 20 years, in the public and
private sectors, occupying a range of roles in both business and systems
analysis. Currently she is a director of Assist Knowledge Development and
is involved in delivering training and consultancy in her specialist fields of
business and systems analysis and consulting skills. Debra was a founding
member of the IBSDF and was a judge of the BCS Business Analyst of the
Year Award, 2004 and 2005.
Craig Rollason is a senior business analyst with a wide range of experience
within the IT industry and extensive experience in the utilities, government
and manufacturing sectors. In his current role, Craig has been responsible
for business case development, requirements gathering, supplier manage-
ment and the procurement for multi-million programmes of work covering
areas of commercial billing systems, document and drawing management,
regulatory changes and management information. Craig is a member of
the BCS Business-IT Interface Specialist Group and was a judge of the BCS
Business Analyst of the Year Award, 2004 and 2005.
Dot Tudor is a graduate in mathematics, statistics and English. She has
worked as a business analyst, systems analyst, programmer, systems
implementer and project manager, with a wide variety of projects in both
public and private sectors. Dot specializes in facilitation, project manage-
ment and computer systems development methodologies and supplies
facilitation, consultancy and training to companies, nationally and
internationally. She is a DSDM Practitioner, and a Prince2 and ISEB
Certified Project Manager. She is a founder member of the IBSDF and the
BCS Methods and Tools Specialist Group.
Donald Yeates (co-editor) has worked in the IT industry with users and
with consulting and computer services organizations in the public and
private sectors in the UK and internationally for most of his working life.
He is a Visiting Fellow of an international business school in Henley in the
UK. He has been a Fellow of BCS since 1984 and was awarded a further
Honorary Fellowship in 1994 for his contribution to the work of the ISEB.
He was appointed a Fellow of the Royal Society of Arts in 1995.
xiii
Contributors
Foreword
Much has been reported about IT systems that do not satisfy business
requirements or that fail to realize the expected benefits to organizations.
This has led to extensive efforts in the areas of programme, project and
service management, which has undoubtedly produced improvements in
recent years. However, without a comprehensive understanding of the
business environment in which any IT or information system will need to
perform, and of how the resulting business and IT systems are to be
aligned, real success is unlikely ever to be achieved. This in conjunction
with approaches to solution development and delivery, such as out-
sourcing, has increased the importance of roles such as business analyst
and requirement analyst.
Such business analysts may come from within the business itself or have
a background in IT systems analysis, design or development. In either
case, the skills needed and techniques employed are likely to be different
to those that the business analysts are accustomed to using. These will
include not only the fundamental skills and competencies of business
analysis itself, such as identifying business drivers and engineering
requirements, but also those of business process modelling, change
management, internal consultancy and an ability to understand the
information and data needs of a business. All of these are covered in a clear
and informative way within this book.
This book, written by some of the best known and respected proponents
of business and requirement analysis, provides a thorough grounding in
these techniques within a best practice lifecycle, which provides
comprehensive coverage of the topic. The guidance included is consistent
with and supplies a supporting text for the ISEB examinations within this
increasingly important subject area.
The expertise brought together in the development of this book is second
to none, and I am convinced that it will inspire those that read it to
contribute to the ongoing improvement of the discipline of business analysis
and to the full exploitation of its techniques in the successful delivery of IT-
enabled change projects. Without this increased professionalism in the area
of business and requirements analysis, all the extensive work in the
development and implementation of best practice in programme, project
and service management in recent years will have been to no avail.
Eur. Ing. Paul Turner FBCS
Business & IS Skills Ltd
xiv
Abbreviations
BAM Business Activity Model
BBS Balanced Business Scorecard
BCS British Computer Society
BPEL Business Process Execution Language
BPM Business Process Management
BPMI Business Process Management Initiative
BPML Business Process Modelling Language
BPMS Business Process Management System
CARE Computer-aided Requirements Engineering
CASE Computer-aided Software Engineering
CATWOE customer, actor, transformation, Weltanschauung
(world view), owner, environment
CEO Chief Executive Officer
CIA confidentiality, integrity, availability
CRM Customer Relationship Management
CSF Critical Success Factor
DBMS Database Management System
DCF Discounted Cash Flow
DMSG Data Management Specialist Group
DSDM Dynamic Systems Development Method
DVD Digital Versatile Disk
EAI Enterprise Application Integration
ERP Enterprise Resource Planning
GMC General Medical Council
HR Human Resources
IRR Internal Rate of Return
IS Information Systems
IT Information Technology
KPIs Key Performance Indicator
MoSCoW must have, should have, could have, want to have
but won’t have this time
MOST (analysis) mission, objectives, strategy and tactics (analysis)
NPV Net Present Value
Ofcom Office for Communications
Ofsted Office for Standards in Education
PESTLE (analysis) political, economic, sociocultural, technological,
legal and environmental (analysis)
SBU Strategic Business Unit
xv
SFIA Skills Framework for the Information Age
SMART specific, measurable, achievable, relevant, time-
framed
SSADM Structured Systems Analysis and Design Method
SSM Soft Systems Methodology
STP Straight-Through Processing
STROBE Structured Observation of the Business Environment
SWOT strengths, weaknesses, opportunities, threats
UML Unified Modelling Language
xvi
Business Analysis
Preface
The ideas for this book grew out of research that we carried out for the
Information Systems Examinations Board on behalf of the International
Business Systems Development Forum. We visited employers in the public
and private sectors to collect views about the examinations and
qualifications available in the UK in business analysis and systems
development. It became clear that demand for business analysts would
continue to grow but that there was no readily available text about
business analysis.
So, the book was born with the British Computer Society as a willing
midwife. All of our contributors are experienced practitioners in the
mysterious art of business analysis and have offered their knowledge to
illuminate the subject. They share their hard won experiences with you.
Notes about each contributor are contained in the acknowledgements.
In addition, there are several people we need to thank. We would like to
thank James Cadle for his critiques, suggestions and additional material
above and beyond the call of friendship. Thanks Jim! Thanks must also go
to Alan Paul who cast his eye over the edited chapters and identified many
improvements. We are also grateful for the specialist help we have had
from Matthew Flynn, Suzanna Marsh and Florence Leroy of the BCS.
Finally, we hope that you, the reader, enjoy this book and find it useful.
Business analysts play a key role in tackling the challenges of today’s
business world; good luck with meeting these challenges.
Debra Paul – Sonning Common, England
Donald Yeates – Henley, England
xvii
1 What is business analysis?DEBRA PAUL
INTRODUCTION
This is a book about business analysis, a discipline that promises to offer
much for the alignment of organizations’ business objectives with the
possibilities offered by information technology (IT). The reason for pro-
ducing this book is the perception that this alignment, the holy grail of the
information systems world, is somehow out of reach. The term ‘business
analysis’ is often used, but there persists a lack of clarity about what it
really means, and this creates more questions than answers. What do
business analysts do? What skills do they require? How do they add value
to organizations? Also, there is no standard definition of business analysis,
and no standard process model exists. There are many reasons for this, but
two key issues are as follows:
l Organizations have introduced business analysis to make sure that
business needs are paramount when new computer systems are being
introduced. However, recognizing the importance of this principle is
easier than considering how this might be achieved.
l Many business analysts have a business background and have a
limited understanding of IT and how computer systems are devel-
oped. This may distance them from the IT developers and result in a
failure to ensure that there is an integrated view of the business and
computer system.
In this chapter, we examine the discipline known as business analysis and
consider how we might define the business analyst role. In Chapter 4, we
describe a process model for business analysis, where we provide an
overview of how business analysis is carried out and the key techniques to
be used at each stage. The aspects of business analysis work that are well
defined are, of course, the various techniques that are available for use in
business analysis projects. Many of these techniques have been in use for
far longer than the business analyst role has been in existence. Much of
this book provides guidance on how the various aspects of the business
analyst role may be carried out. We describe numerous techniques that we
feel should be in any business analyst’s toolkit and place them within the
overall process model. Our aim is to help business analysts carry out their
work, improve the quality of business analysis within organizations and,
1
hence, develop the key ingredient for business success – business/IT
alignment.
THE ORIGINS OF BUSINESS ANALYSIS
Developments in IT have enabled organizations to develop information
systems that have improved business operations and management
decision-making. In the past, this has been the focus of IT departments.
However, as business operations have changed, the emphasis has moved
on to the development of new services and products. The question we
need to ask now is ‘What can IT do to exploit business opportunities and
enhance the portfolio of products and services?’
Technology has supported the implementation of new business models
by providing more flexible communication mechanisms that enable
organizations to reach out to the customer, connect their systems with
those of their suppliers and support global operation. The use of IT has also
created opportunities for organizations to focus on their core processes and
competencies without the distraction of the peripheral areas of business.
These days, the absence of good information systems would prevent an
organization from developing significant competitive advantage. Yet for
many years, there has been a growing dissatisfaction in businesses with the
support provided by IT. This has been accompanied by recognition by
senior management that IT investment often fails to deliver the required
business benefit. In short, the technology enables the development of
information systems, but these often fail to meet the requirements of the
business and to deliver the service that will bring competitive advantage to
the organization. This situation applies to all sectors, including the public
sector. In 1999, a report from the Select Committee of Public Accounts
(1999) reported on over 25 cases from the 1990s ‘where the implementation
of IT systems has resulted in delay, confusion and inconvenience to the
citizen and, in many cases, poor value for money to the taxpayer’. The
perception that, all too frequently, information systems do not deliver the
predicted benefits appears to be well-founded.
THE DEVELOPMENT OF BUSINESS ANALYSIS
The impact of outsourcing
In a drive to reduce costs, and sometimes in recognition of a lack of IT
expertise at senior management level, many organizations have decided in
the past decade or so to purchase IT services rather than employ IT staff.
Hence, they have moved much of their IT work to specialist service
providers. This outsourcing of IT work has been based upon the belief that
specialist providers, often working in countries where costs are lower than
in the UK, will be able to deliver higher quality at lower cost. So, in
Business Analysis
2
organizations that have outsourced their IT functions, the IT systems are
designed and constructed using staff employed by an external supplier.
This undoubtedly has advantages for both the organization purchasing the
services and the specialist supplier. The latter gains an additional customer
and the opportunity to increase turnover and make profit from the
contractual arrangement; the customer organization is no longer con-
cerned with all staffing, infrastructure and support issues and instead pays
a specialist provider for delivery of the required service. In theory this
approach has much to recommend it but, as is usually the case, the flaws
begin to emerge once the arrangement has been implemented, particularly
in the areas of contract management and communication. The issues
relating to contract management are not the subject of this book and
would require a book in their own right. However, we are concerned with
the issue of communication between the business and the outsourced
development team. The communication and clarification of requirements
are key to ensuring the success of any IT system development, but an
outsourcing arrangement often complicates the communication process,
particularly where there is geographical distance between the developers
and the business. We need to ask ourselves the questions ‘How well do our
business and technical groups understand each other?’ and ‘Is the
communication sufficiently frequent and open?’ Communication failures
will usually result in the delivered IT systems failing to provide the
required level of support for the business.
Investigation of the outsourcing business model has highlighted that in
order to make such arrangements work, new roles are required within the
organization. A study by Feeny and Willcocks (1998) listed a number of key
skills required within organizations that have outsourced IT. This report
specifically identified business systems thinking, a core element of the
business analyst role, as a key skill that needs to be retained within
organizations operating an outsourcing arrangement. The outsourcing
business model has undoubtedly been a catalyst for the development of
the business analysis function as more and more organizations recognize
the importance of business representation during the development and
implementation of IT systems.
Competitive advantage of using IT
A parallel development that has helped to increase the profile of business
analysis and define the business analyst role has been the growing
recognition that three factors need to be present in order for the IT systems
to deliver competitive advantage. First, the needs of the business must
drive the development of the IT systems; second, the implementation of an
IT system must be accompanied by the necessary business changes; and
third, the requirements for IT systems must be defined with rigour and
accuracy. The traditional systems analyst role operated primarily in the
What is business analysis?
3
last area, but today’s business challenges require all three areas to be
addressed.
The rise of the business analyst
The delivery of predicted business benefits, promised from the imple-
mentation of IT, has proved to be extremely difficult, with the outsourcing
of IT services serving to add complication to already complex situations.
The potential exists for organizations to implement information systems
that yield competitive advantage, and yet this often appears to be just out
of reach. Organizations also want help in finding potential solutions to
business issues and opportunities, sometimes where IT may not prove to
be the answer, but it has become apparent that this requires a new set of
skills to support business managers in achieving this. These factors have
led directly to the development of a new role – the business analyst –
where advice and internal consultancy are provided about the use and
deployment of IT in order to deliver business benefits.
The use of consultants
It has also been argued that external consultants have played a part in the
development of the internal business analysis role. The reasons are clear:
external consultants can be employed to deal with a specific issue on an
as-needed basis, and they bring a broader business perspective and can
provide a dispassionate, objective view of the company. On the other
hand, the use of external consultants is often criticized because of their
lack of accountability and the absence of any transfer of skills from them to
internal staff. Cost is also a key issue. Consultancy firms typically charge
upwards of £1500 per day, and although in the main the firms provide
consultants with a broad range of expertise, this is not always guaranteed.
Consequently, there has been increasing use of internal consultants over
the past decade. Reasons for using internal consultants, apart from lower
costs, include speed (internal consultants do not have to spend time
learning about the organization) and the retention of knowledge within the
organization. These factors have been recognized as particularly important
for projects where the objectives concern the achievement of business
benefit through the use of IT and where IT is a prime enabler of business
change. As a result, although external consultants are used for many
business purposes, the majority of business analysts are employed by their
organizations. These analysts may lack an external viewpoint, but they are
knowledgeable about the business domain and crucially will have to live
with the impact of the actions they recommend.
THE SCOPE OF BUSINESS ANALYSIS WORK
A major issue for business analysts, based on feedback from a wide
range of organizations, is the definition of the business analyst role.
Business Analysis
4
Anecdotal information collected between 2001 and 2005 from several
hundred business analysts has highlighted that their job descriptions are
unclear and do not always describe accurately their responsibilities. A
quick survey of the job advertisements for business analysts also reflects
a lack of agreement. For example, in some cases the job description of a
business analyst seems, on close inspection, to be similar to that of an
analyst/programmer, e.g. ‘Candidates must have experience of Java.’ In
other organizations the business analysts appear to be required to work
at the opposite end of the scale and provide strategic analysis for their
business units, e.g. ‘Candidates must be comfortable working with
senior management.’ Even though the role of the business analyst
emerged over 10 years ago, a formal agreed definition has not been
reached. Recently there has been some mention of business analysis in
reference texts, but in contrast to the plethora of books on other IT
disciplines, this has been brief and has offered only limited guidance.
Skidmore and Eva (2004) reflected the wider perspective of the business
analysis role by observing that with regard to information systems
development, ‘business analysts are concerned with exploring business
solutions’. A more specific view was taken by Maciaszek (2001), who
stated that eliciting and confirming information system requirements is
an ‘activity conducted by a business analyst’. This view was defined in
more detail by Yeates and Wakefield (2004), who clarified that ‘the
business analyst’s responsibility is the production of clearly stated
business requirement definitions, which can be passed to a system
designer to be turned into specifications that are the input to the
development process’.
The range of analysis activities
One way in which we can consider the business analyst role is to
examine the possible range of analysis activities. Figure 1.1 shows three
areas that we might consider to be within the province of the business
analyst. Consultants, both internal and external, who specialize in
strategic analysis often have to get involved in business process redesign
to make a reality of their strategies, and good systems analysts have
always needed to understand the overall business context of the systems
that they are developing. However, it is useful to examine them
separately in order to consider their relevance to the business analyst
role.
Strategic analysis and de�nition
Strategic analysis and definition are typically the work of senior
management, often supported by strategy consultants. Some, albeit a
minority, business analysts may be required to undertake strategic
analysis and identify business transformation actions, but most will
probably have a role to play in supporting this activity. In the main,
What is business analysis?
5
we believe that strategic analysis is mostly outside the remit of
business analysis. We would, however, expect business analysts to have
access to information about their organization’s business strategy and
be able to understand it, as their work will need to support the
achievement of this strategy. It may also be the case that some
business analyst roles will require strategic-level thinking, for example
in considering whether technology developments can deliver innovation
to the company and open new strategic opportunities. In the light of
this, we feel that although strategic analysis work is not core to
business analysis, business analysts will need a good understanding of
strategy development processes. Therefore, Chapter 3 explores some
strategic analysis techniques and provides an overview of the strategic
planning process.
IT systems analysis
At the other end of our model, there is the IT discipline of systems
analysis. This is concerned with analysing and specifying the IT system
requirements in sufficient detail in order to provide a basis for the
evaluation of software packages or the development of a bespoke IT
system. Typically, systems analysis work involves the use of techniques
such as data modelling and process or function modelling. This work is
very specific to describing the computer system requirements, and so
the products of systems analysis define exactly the data that the
computer system will record, the processing that will be applied to that
data and the operation of the user interface. Some organizations
consider this work to be of such a technical nature that they perceive it
to be completely outside the province of the business analyst. They have
identified that modelling process and data requirements for the IT
system is not part of the role of the business analyst and have separated
the business analysis and IT teams into different departments. The
expectation here is that the IT department will carry out the detailed IT
systems modelling and specification. Nowadays, it is less common for
organizations to employ IT staff with the job role ‘systems analyst’, and
FIGURE 1.1 Potential range of the business analyst role
Business Analysis
6
the detailed specification of the requirements is often undertaken by
systems designers or developers. However, in other organizations the
divide between the business analysts and the IT team is less obvious or
does not exist. In these cases the business analysts work closely with the
IT developers and include the specification of IT system requirements
as a key part of their role. In order to do this, the business analysts
need a more detailed understanding of IT systems and how they operate
and need to be able to use the approaches and modelling techniques
that historically fell within the remit of the systems analyst job role.
Business analysis
If the two analysis disciplines described above define the limits of analysis
work, then the gap in the middle is straddled by business analysis. Hence,
the model highlights the possible extent of business analysis work.
Business analysts will usually be required to investigate a business system
where improvements are required, but the range and focus of those
improvements can vary considerably.
It may be that the analysts are asked to resolve an identified and very
localized issue. They would need to recommend actions that would
overcome a problem or achieve business benefits. However, it is more
likely that the study is broader than this and requires investigation into
several issues, or perhaps ideas, regarding increased efficiency or
effectiveness. This work would necessitate extensive and detailed analysis.
The analysts would need to make recommendations for business changes,
and these would need to be supported by a rigorous business case.
Another possibility is that the business analyst is asked to focus
specifically on enhancing or replacing an existing IT system in line with
business requirements. In this case the analyst would deliver a require-
ments document defining what the business requires the IT system to
provide.
Whichever situation applies, the study usually begins with the analyst
gaining an understanding of the business situation in hand. A problem
may have been defined in very specific terms, and a possible solution
identified, but in practice it is rare that this turns out to be the entire
problem, and it is even rarer that any proposed solution addresses all of
the issues. More commonly, there may be a more general set of problems
that require a broad focus to the study. For any changes to succeed, the
business analyst needs to consider all aspects, for example the processes,
IT systems and resources that will be needed in order to improve the
situation successfully. In such situations, techniques such as stakeholder
analysis, business process modelling and requirements engineering may
all be required in order to identify the actions required to improve the
business system. These three topics are the subjects of later chapters in
this book.
What is business analysis?
7
Managing business bene�ts
Analysing business situations and identifying areas for business improve-
ment is only one part of the process. The analyst may also be required to
develop a business case in order to justify the required level of investment
and consider any risks. One of the key elements of the business case will be
the identification and, where relevant, the quantification of the business
benefits. In recent years much emphasis has been placed on the delivery or
realization of these business benefits. This is largely because there has
been a long history of failure to confirm, or dispute, whether this has
happened. Supporting the business in order to assess whether the
predicted business benefits have been delivered and to take actions that
will help deliver those benefits are further key aspects of business analysis.
Supporting business change
At a later stage, the business analyst may be required to support the
implementation of the changes. This support may involve advising the
business users as they adopt new processes and procedures or assisting, or
even directing, the user acceptance testing activity for an IT system.
Chapter 13 explores the management of business change and the key
elements to be considered here.
Taking an holistic approach
There appears to be universal agreement that business analysis requires
the application of an holistic approach. Although the business analyst
performs a key role in supporting management to exploit IT in order to
obtain business benefit, this has to be within the context of the entire
business system. Hence, all aspects of the operational business system
need to be analysed if all of the opportunities for business improvement
are to be uncovered. Figure 1.2 represents the three viewpoints that it is
useful to consider when identifying areas for improving the business
system.
FIGURE 1.2 The three views of a business system
Business Analysis
8
This model shows us that business analysts need to consider these three
aspects when analysing a business system. For each area, we might
consider the following:
l The processes: are they well defined and communicated? Is there
good IT support, or are several ‘workarounds’ in existence? Does the
process require documents to be passed around the organization
unnecessarily?
l The people: do they have the required skills for the job? How
motivated are they? Do they understand the business objectives that
they need to support?
l The organizational context: is there a supportive management
approach? Are jobs and responsibilities well defined? Is there effective
cross-functional working?
We need to examine and understand these three areas if the business
system is to be effective. It is often the case that the focus of a business
analysis or business change study is on the processes and the IT support.
However, even if we have the most efficient processes with high standards
of IT support, the system will have problems if the staff members do not
have the right skills to carry out their work or the organization structure is
unclear.
It is vital that the business analyst is aware of the broader aspects
relating to business situations, such as the culture of their organization
and its impact on the people and the working practices. The adoption of an
holistic approach will to help ensure that these aspects are included in the
analysis of the situation.
Business analysis places an emphasis on improving the operation of the
entire business system. This means that although technology is viewed as a
factor that could enable improvements to the business operations, there
are other possibilities. The focus on business improvement rather than the
use of automation per se results in recommendations that typically, but
not necessarily, include the use of IT. For example, in some situations
these recommendations may relate to staff development. It is important
that our focus as business analysts is on identifying opportunities for
improvement with regard to the needs of the particular situation. If we do
this, then we can recommend changes that will help deliver real business
improvements.
THE ROLE AND RESPONSIBILITIES OF A BUSINESS ANALYST
So where does this leave us in defining the role and responsibilities of a
business analyst? Although there are different role definitions, depending
on the organization, there does seem to be an area of common ground
where most business analysts work. The responsibilities here seem to be as
follows:
What is business analysis?
9
l To investigate business systems, taking an holistic view of the
situation. This may include examining elements of the organization
structures and staff development issues as well as current processes
and IT systems.
l To identify actions required to improve the operation of a business
system. Again, this may require an examination of organizational
structure and staff development needs in order to ensure that they are
in line with any proposed process redesign and IT system develop-
ment.
l To document the business requirements for the IT system support
using appropriate documentation standards.
In line with this, we believe that the core business analyst role should be
defined as follows:
An internal consultancy role that has the responsibility for investigating
business systems, identifying options for improving business systems and
bridging the needs of the business with the use of IT.
Beyond this core definition, there are the aspects of business analysis that
appear to apply where business analysts are in a more senior role or
choose to specialize. These aspects are as follows:
l Strategy implementation: here, the business analysts work closely
with senior management to help define the most effective business
system in order to implement elements of the business strategy.
l Business process redesign: here, the emphasis is on both the business
process management and operation.
l Business case production: more senior business analysts usually do
this, typically with assistance from finance specialists.
l Specification of IT requirements, typically using standard modelling
techniques such as data modelling or case modelling.
Business analysis offers an opportunity for organizations to ensure that
technology is deployed effectively in order to support the work of the
organization. A new breed of analysts is emerging with both the skills
and knowledge about the business domain plus the analytical skills of
consultants. The challenge for the analysts is to ensure that they
develop the extensive toolkit of skills that will enable them to engage
with the business problems and assist in their resolution. The challenge
for the business is to support the analysts in their personal develop-
ment, give them the authority to carry out the business analysis work
and listen to their advice. This book has been developed in the light of
these challenges; we hope both business users and analysts will find it
useful.
Business Analysis
10
REFERENCES
Feeny, D. and Willcocks, L. (1998) Core IS Capabilities for Exploiting
Information Technology. Sloan Management Review, 39, 9–21.
Maciaszek, L.A. (2001) Requirements Analysis and System Design: Devel-
oping Information Systems with UML. Addison-Wesley, Harlow.
Select Committee of Public Accounts (1999) Improving the Delivery of
Government IT Projects, First Report. House of Commons, HC 65, 5
January.
Skidmore, S and Eva, M (2004) Introducing Systems Development. Palgrave
Macmillan, Basingstoke.
Yeates, D and Wakefield, T (2004) Systems Analysis and Design. FT Prentice
Hall, Harlow.
FURTHER READING
Harmon, P. (2003) Business Process Change. Morgan Kaufmann, Boston,
MA.
Johnson, G. and Scholes, K. (1999) Exploring Corporate Strategy. FT
Prentice Hall, Harlow.
Porter, M.E. (1980) Competitive Strategy: Techniques for Analysing
Industries and Competition. Free Press, New York.
Senge, P.M. (1993) The Fifth Discipline: The Art and Practice of the Learning
Organization. Century Business, New York.
What is business analysis?
11
Index
activitiesanalysing 57supporting 184–187
activity sampling 80–81analytical skills 16–17attention to detail 17
balanced business scorecard (BBS) 45,46, Fig. 3.6
BAM see business activity modelBBS see balanced business scorecardbehavioural skills 14–18benefits
in business see business benefitsrealization 212–213, Fig. 12.3
Boston Box 42, Fig. 3.3BPEL see business process execution
languageBPM see business process
managementBPMI see Business Process
Management InitiativeBPML see business process modelling
languagebusiness activities,
supporting 184–187business activity model (BAM)
consensus model 106–107control activities 103dependencies 104developing 105–106doing activities 103enabling activities 103gap analysis, use in 110generally 55–56, 102modelling notation 104, Fig. 7.4,
Fig. 7.5monitoring activities 103planning activities 102–103validating 109–110
business analysisdefinition 1, 7development of 2–4holistic approach to 8–9, Fig. 1.2modelling techniques 61origins of 2process model 49–63, Fig. 4.2range of activities in 5scope of 4–9
business analystbehavioural skills of 14–18business knowledge of 18–21competencies of 13–27, Fig. 2.1personal qualities of 14–18rise of 4responsibilities of 9–10
role of 5–6, 9–10, Fig. 1.1business benefits, managing 8business case
appendices 208–209considered options 202cost/benefit analysis 202–207,
Fig. 12.6description of current situation 202development of 18impact assessment 207investment appraisal 209–211, Table
12.1, Table 12.2management summary 201–202project lifecycle, in 195–196,
Fig. 12.1options in, identifying 196–198presentation of 211–212recommendations 208, 209, Fig. 12.7risk assessment 208structure of 201–209supporting information 208–209
business changechange phase 217–218, Fig. 13.2emotions and 216–220,
Figs 13.1–13.3learning cycle 218, Fig. 13.2logical levels model 219, Fig. 13.3managing see management of
business changeprocess of 220–231refreeze phase 218–220, Fig. 13.3spreading 230–231supporting 8sustaining 229–230unfreeze phase 216–217, Fig. 13.1
business events 107–108, Fig. 7.6business feasibility 198–199business intelligence projects 185–187business knowledge 18–21business options
developing, 197, Fig. 12.2identifying 196–198incremental 198, Fig. 12.3
business performance 115–116business perspectives 99–101business process execution language
(BPEL) 133business process management
(BPM) 132–133Business Process Management
Initiative (BPMI) 133business process modelling
advanced concepts in 131–133definition of 113–115detailed process analysis 125–126,
Fig. 8.11, Fig. 8.12
end-to-end 123–125, Figs 8.8–8.11external views of 114–115generally 113importance of 115–118internal views of 113–114language (BPML) 133and IT 116–118, Fig. 8.4map for 119, 120, Fig. 8.5outline, 113, 114, Fig. 8.1overview model, building 119–122,
Fig. 8.5process concept in 114, Fig. 8.2process goals 113–114process view in 115, Fig. 8.3techniques in 22, 118–126, Figs
8.5–8.12value chain in 120, 121, Fig. 8.6,
Fig. 8.7business processes
analysing 57–58improving 126–130, Fig. 8.13modelling see business process
modellingplanning improvement
initiative 130–131business rules 108–109business situations, documenting
generally 53–54, 98–99mind map approach 99, Fig. 7.3rich-picture technique 98, Fig. 7.2
business systemsmodelling of see business systems
modellingthree views of 8–9, Fig. 1.2
business systems modellinggenerally 95–111techniques for 22
CATWOE mnemonic 100–101change see business change;
management of businesschange
change phase, businesschange 217–218, Fig. 13.2
commercial awareness 16communication 14–15communications plan,
developing 225–226competencies
developing 23–24generally 13–27, Fig. 2.1
competitors, as stakeholders 85concerns-based adoption model 225,
226, Fig. 13.6consensus model 106–107consultants, use of 4
233
control activities 103cost/benefit analysis in business case
presentationavoided costs 206categories in 203, Fig. 12.6generally 202–204, 207intangible benefits 206intangible costs 205tangible benefits 205–206tangible costs 204
critical success factors 109critical thinking 16–17CSFs see critical success factorscustomers, as stakeholders 84–85
dataadministration of see data
administrationarchitecture of see data architectureavailability, valuation by 182capture of 191–192classifying 183–184dictionary of 189–190lifecycle of 182–183lost, valuation of 182migration of 190modelling of see data modellingownership of 189resources, managing 178–180security of 192–194storage of 191–192valuing 182
data administrationchange control in 190generally 187–188standards in 188–189
data architecture 190–191data modelling
generally 191relationships in see relationships in
data modellingtechniques for 22
DCF see discounted cash flowdependencies 104discounted cash flow (DCF) 210document analysis 81doing activities 103domain knowledge 18–19
EAI see enterprise applicationintegration
ego strength 18emotions, and business
change 216–220, Figs 13.1–13.3employees, as stakeholders 86enabling activities 103enterprise application integration
(EAI) 130entity relationship diagrams 163–164,
169, 170, Fig. 10.13ethnographic studies 74external environment analysis 35–40
facilitation techniques 22–23feasibility
aspects of 198, 199, Fig. 12.4in business see business feasibilityfinancial 200
force-field analysis 200, Fig. 12.5PESTLE analysis and 200technical 199
finance, knowledge of 18financial feasibility 200force-field analysis, in business
change 222, 223, Fig. 13.5
gap analysis, BAM in 110
holistic approach 8–9, Fig. 1.2
improvement phase, in businesschange 229–231
influencing 15–16information resource,
managing 177–194internal environment analysis 40–42interviews
advantages and disadvantages of 66body of 68closure stage 68conducting 67–68following up 68generally 65introduction stage 67–68preparation for 66–67structure of 67, Fig. 5.1
investigation techniquesgenerally 22, 53, 65–81interviews 65–68, Fig. 5.1observation 71–74, Fig. 5.3prototyping 77–78scenarios 74–77, Fig. 5.4workshops 68–71, Fig. 5.2
investment appraisalgenerally 209–211net present value calculation 210,
211, Table 12.2payback calculation 209–210, Table
12.1IT
business process modellingand 116–118, Fig. 8.4
competitive advantage of using3–4
introducing new system 215–216principles of, knowledge of 19–20systems analysis 6–7systems modelling see IT systems
modellingIT systems modelling
attributes in 164constructs in 161–162, Fig. 10.2,
Fig. 10.3data in 162–175, Figs 10.3–10.22entity relationship
diagrams 163–164, 169, 170,Fig. 10.13
functions 159–162, Fig. 10.1generally 61, 159optionality in 166–168, Figs
10.7–10.9relationships in 164–166, Figs
10.4–10.6use case diagram 160, 161, Fig. 10.1
key performance indicators (KPI) 109
KPIs see key performance indicators
leadership 17–18learning cycle, business change 218,
Fig. 13.2logical levels model 219, Fig. 13.3
management of business changeactivities, planning 224–225adapting 228communications plan,
developing 225–226concerns-based adoption
model 225, 226, Fig. 13.6execution of plan 227–229force-field analysis 222, 223,
Fig. 13.5generally 215–231impact, understanding 221–222,
Fig. 13.4improvement phase 229–231key staff 227need for 220objections, managing 228–229planning 222–226, Fig. 13.5, Fig. 13.6professionalism 227roll-out, sequencing 228spreading change 230–231sustaining change 229–230techniques for 22training 228trust, developing 223–224
managers, as stakeholders 86McKinsey 7-S model 45, Fig. 3.5mind map approach 99, Fig. 7.3monitoring activities 103
net present value (NPV)calculation of 210–211, Table 12.2generally 210–211
notation, in BAM 104, Fig. 7.4, Fig. 7.5NPV see net present value
objections, managing, in businesschange 228–229
observationadvantages and disadvantages of 72ethnographic studies 74formal 72generally 71–72protocol analysis 72shadowing 72–73STROBE 73, 74, Fig. 5.3
optionality, in systemsmodelling 166–168, Figs10.7–10.9
optionsevaluating 58–60feasibility of, assessing 59identifying potential 59
origins 2organization
design of 20structure of 20
outsourcing, impact of 2–3owners, as stakeholders 85
partners, as stakeholders 85
Index
234
personal qualities of businessanalyst 14–18
PESTLE analysisbusiness feasibility and 200business system modelling and 10description of 36–37
planning activities 102–103political awareness 16Porter’s five forces model 38, Fig. 3.2problem-solving
approach to 49–51generally 17model for 49, 50, 51–52, Fig. 4.1,
Fig. 4.2procurement 20–21project management techniques 21protocol analysis 72prototyping
advantages and disadvantages 78generally 77–78
quantitative approachesactivity sampling 80–81document analysis 81generally 78–81questionnaires 78–80special-purpose records 80
questionnairesadvantages and
disadvantages 79–80classification section 79data section 79generally 78–79heading section 79
refreeze phase, businesschange 218–220, Fig. 13.3
regulators, as stakeholders 85relationship-building 15relationships in data modelling
associations in 172–174,Figs 10.15–10.21
class models 169–170classes 170–172, Fig. 10.14exclusive 169, Fig. 10.12generalization 174–175, Fig. 10.22generally 164inheritance in 174–175many-to-many 165, Fig. 10.5,
Fig. 10.6names in 16, Fig. 10.11objects 170one-to-many 165, Fig. 10.4one -to-one 165, Fig. 10.6
requirementsanalysis of 147–149catalogue 150–153, Fig. 9.6changes to, managing 156–157defining 60–62documenting 149–155, 154–155elicitation of see requirements
elicitationengineering see requirements
engineeringlist of, building 147, Table 9.3
modelling approaches 153–154problems with 135–137validating 155
requirements elicitationgenerally 143tacit knowledge 143–146, Table 9.1,
Fig. 9.5techniques in 146, Table 9.2
requirements engineeringactors in 141–143decision tree for 140, 141, Fig. 9.4generally 22, 61, 135–157place of 137–139process for 139–141, Fig. 9.3
rich-picture technique 98, Fig. 7.2roll-out, sequencing, in business
change 228
scenariosadvantages and disadvantages
of 75–77developing 75, Fig. 5.4documenting 77generally 74–75
self study 24SFIA see Skills Framework for the
Information AgeSFIAplus 25–26shadowing 72–73Skills Framework for the Information
Age (SFIA) 24–25soft systems methodology (SSM)
generally 96model in 96–97, Fig. 7.1
special-purpose records 80SSM see soft systems methodologystakeholder analysis
generally, 54–55, 83–92steps in 83, 84, Fig. 6.1techniques in 22
stakeholder categoriescompetitors 85customers 84–85employees 86generally 83generic 83, 84, Fig. 6.2managers 86owners 85partners 85regulators 85suppliers 85
stakeholder identification 54–55stakeholder management
generally, 83–92steps in 83, 84, Fig. 6.1strategies in 87–90, Fig. 6.4techniques in 22
stakeholder perspectives 55stakeholders
analysing 86–87, Fig. 6.3categories of see stakeholder
categoriesmanaging see stakeholder
management strategiesin requirements process 141–143
STP see straight-through processingstraight-through processing (STP)
130strategic analysis
generally 5–6, 29–47techniques in 21
strategyanalysis of see strategic analysiscontext for 29–30creation of 33, Fig. 3.1definition of 31–32development of see strategy
developmentimplementing 44–47
strategy developmentgenerally 32–35origins of 33, Fig. 3.1
STROBE 73, 74, Fig. 5.3subject matter expertise 19suppliers, as stakeholders 85SWOT analysis
generally 43–44matrix format 43, Fig. 3.4
systems analysis, in IT 6–7systems development lifecycle
corporate data model 180, 181,Fig. 11.1
support for 180–182
tacit knowledge 143–146, Table 9.1,Fig. 9.5
teamworking 16technical feasibility 199techniques
business change, managing 22business process modelling 22business systems modelling 22data modelling 22facilitation 22–23investigation 22project management 21requirements engineering 22stakeholder analysis 22stakeholder management 22strategy analysis 21
training 23
unfreeze phase, businesschange 216–217, Fig. 13.1
validating BAM 109–110
waterfall lifecyclegenerally 138–139overview version 138, Fig. 9.1‘V’ model 139, Fig. 9.2
work experience 24workshops
advantages and disadvantages of69
facilitating 70following 71generally 68–69preparing for 69–70techniques for 70–71, Fig. 5.2
Index
235
BCS products and services
Other products and services from the British Computer Society that might
be of interest to you include:
Publishing
BCS publications, including books, magazine and peer-reviewed journals,
provide readers with informed content on business, management, legal
and emerging technological issues, supporting the professional, academic
and practical needs of the IT community. Subjects covered include
business process management, IT law for managers and transition
management. www.bcs.org/publications
BCS professional products and services
The BCS promotes the use of the SFIAplus IT skills framework, which
forms the basis of a range of professional development products and
services for both individual practitioners and employers. This includes BCS
SkillsManager and BCS CareerDeveloper. www.bcs.org/products
Qualifications
Information Systems Examination Board (ISEB) qualifications are the
industry standard both in the UK and abroad. With over 100,000
practitioners now qualified, it is proof of the popularity of the qualifica-
tions. These qualifications ensure that IT professionals develop the skills,
knowledge and confidence to perform to their full potential. There is a
huge range on offer, covering all major areas of IT. In essence, ISEB
qualifications are for forward-looking individuals and companies who
want to stay ahead and who are serious about driving business forward.
www.iseb.org.uk
BCS professional examinations are examined to the academic level of a
UK honours degree and are the essential qualifications for a career in
computing and IT. Whether you seek greater job recognition, promotion or
a new career direction, you will find that BCS professional examinations
are internationally recognized, flexible and suited to the needs of the IT
industry. www.bcs.org/exams
The European Certification of IT Professionals (EUCIP) is aimed at IT
professionals and practitioners wishing to gain professional certification
and competency development. www.bcs.org/eucip
European Computer Driving Licence (ECDL) is the internationally
recognized computer skills qualification that enables people to demon-
strate their competence in computer skills. ECDL is managed in the UK by
the BCS. ECDL Advanced has been introduced to take computer skills
certification to the next level and teaches extensive knowledge of particular
computing tools. www.ecdl.co.uk
237
Networking and events
BCS’s specialist groups and branches provide excellent professional
networking opportunities by keeping members abreast of latest develop-
ments, discussing topical issues and making useful contacts. www.bcs.org/
bcs/groups
The society’s programme of social events, lectures, awards schemes and
competitions provides more opportunities to network. www.bcs.org/
events
Further information
This information was correct at the time of publication but could change
in the future. For the latest information, please contact:
The British Computer Society
First Floor, Block D
North Star House
North Star Avenue
Swindon SN2 1FA
Telephone: 0845 300 4417 (UK only) or þ44 1793 417424 (overseas)
Email: [email protected]
Web: www.bcs.org
Business Analysis
238
Edited by Debra Paul
and Donald Yeates
Business Analysis
Business AnalysisEdited by Debra Paul and Donald Yeates
Endorsed by IBSDF
Business Analysis is a practical introductory guide for anyoneinvolved with business analysis, improving efficiency, or thealignment of IT with organisational objectives.
Business Analysis explores: the key early stages of the development lifecycle; the nature of business problems; howorganisations develop; and the drivers that contribute to thedevelopment of the business analysis discipline.
Practical business analysis techniquesBusiness systems developmentBusiness process managementManaging changeInformation resource management
About the authors
Business Analysis has been written by a team of experts whoare both practitioners and educators in the business analysisfield. They are all members of the International BusinessSystems Development Forum.
‘Great breadth,
good depth.
A highly
recommended
introduction to
Business Analysis.’
Neil Venn,
Seabright Consulting
This book is brought to you by the British Computer Society – the leading professional and learned society in the field of computers and information systems.
� ������ ������
� � � � � � � � � � � � � � �
BCS FIRST FLOOR, BLOCK D,NORTH STAR HOUSE, NORTH STAR AVENUE,SWINDON, SN2 1FA, UK
B U S I N E S S
BCS_Books_Business_Analysis_Amended:Layout 1 22/8/07 12:39 Page 1
