Swimlane A row on a business process diagram or model that indicates who is responsible for a given process or task. Typical swimlanes represent departments, teams, individuals or IT systems. Swimlane Diagram A technique used to model business processes. A swim- lane diagram models the business system response to a business event. The model shows the triggering event, the business actors, the tasks they carry out, the flow between the tasks and the business outcome.
SWOT Analysis A technique used to summarise the external pressures facing an organisation and the internal capability the organisation has available to respond to those pressures. The mnemonic stands for strengths, weaknesses, opportunities and threats. SWOT analysis is used during strategy analysis.
Tacit Knowledge Those aspects of business work that a user omits to articulate or explain. This may be due to a failure to recognise that the information is required or to the assumption that the information is already known to the analyst. Tangible Benefit A benefit to be realised by a business change project for which a credible, usually monetary, value can be predicted. Task On a business process model or swimlane diagram, a piece of work carried out by a single actor at a specific moment in time.
Task Modelling The technique for developing a model that describes the human activities and task sequences required by a business system. The task model elaborates the tasks identified by mapping business processes on to specific individuals or workgroups. Technical Option A technical option describes how the business solution may be implemented using information technology. Use Case Description A use case description defines the interaction between an actor and a use case.
A use case model consists of a diagram showing the actors, the boundary of the system, the use cases and the associations between them, plus a set of use case descriptions. Value Chain A concept developed by Michael Porter to identify the primary and support activities deployed within organisations to deliver value to customers. Workshop An investigation technique whereby a meeting is held with business actors from a range of business areas in order to elicit, analyse or validate information.
An agenda is prepared prior to the workshop and distributed to participants. The workshop is run by a facilitator; actions and decisions are recorded by a scribe. This new edition reflects this progress and incorporates much new material. The main audience for this book is still practising Business Analysts at all levels.
It offers them a wide-ranging source of practical guidance on how to approach business analysis and how to use key techniques. It will therefore appeal to people wanting to improve their understanding of business analysis. The book also supports everyone wanting to achieve industry qualifications in business analysis especially those studying for ISEB qualifications in Business Analysis.
In addition, the book will be useful for business analysis and information systems students at university, and for managers in other Information Systems disciplines who need to understand business analysis. The book includes material drawn from research discussions and conversations with practitioners in business analysis in the UK, Australia, the USA and Canada.
Some important additions since the first edition include: The introduction of new analysis techniques now more widely used such as Ishikawa diagrams and spaghetti maps. An expanded explanation of requirements engineering — now taking up four chapters.
More on the process and techniques of investigating business needs. A more detailed treatment of benefits realisation including the use of benefits realisation maps. Throughout the business world public, private and not for profit organisations face immense challenges. Business Analysts must respond by developing practi- cal, creative and financially sound solutions. Also thanks must go to Alan Paul — husband of Debbie — for reviewing much of the book and improving it.
BCS publications team members Matthew Flynn, Karen Greening and Sarah Woodall made it all come together in the end and their detailed examination of what had been written has, we hope, saved us from embarrassing ourselves too much. Also, we thank the BCS legal team for their work in protecting copyright.
Many of those solutions will involve new or enhanced information systems, but others may have a broader scope incorporating changes to areas such as business processes and job roles. The reason for producing this book is to provide guidance about business analysis that reflects the breadth of the role and the range of techniques used.
What do business analysts do? What skills do they require? How do they add value to organisations? Also, in the absence of a standard definition of business analysis and a standard business analysis process model, problems have arisen: Organisations have introduced business analysis so as to make sure that business needs are paramount when new information technology IT systems are introduced.
However, recognising the importance of this in principle is easier than considering how it might be achieved. Some business analysts were experienced IT systems analysts and have been less comfortable considering the business requirements and the range of potential solutions that would meet those requirements. Many business analysts come from a business background and have a limited understanding of IT and how computer systems are developed.
While knowl- edge of the business is invaluable for business analysts, problems can occur where IT forms part of the solution and the analyst has insufficient under- standing of IT. This can cause communication difficulties with the developers, and may result in failure to ensure that there is an integrated view of the business and the computer system. Some business analysts, as they have gained in experience and knowledge, have felt that they could offer beneficial advice to their organisations — but a lack of understanding of their role has caused organisations to reject or ignore this advice.
This chapter examines the business analysis discipline and considers how we might define the business analyst role. Much of this book provides guidance on how the various stages in this process model may be carried out. Business analysis work is well defined where there are standard techniques that have been used in projects for many years. In fact, many of these techniques have been in use for far longer than the business analyst role has been in existence.
Our aim is to help business analysts carry out their work, to improve the quality of business analysis within organisations and, as a result, to help organisations to adopt business improvements that will ensure their success.
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 use of IT has also created opportunities for organisations 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 organisation 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 deliver the service that will bring competitive advantage to the organisation.
This situation applies to all sectors, including the public sector. The perception that, all too frequently, information systems do not deliver the predicted benefits continues to be well founded. They have transferred much of their IT work to specialist service providers.
So, in organisations that have outsourced their IT functions, the IT systems are designed and constructed using staff employed by an external supplier. This undoubtedly has advantages both for the organisation purchasing the services and for the specialist supplier. The latter gains an additional customer and the opportunity to increase turnover and make profit from the contractual arrangement; the customer organisa- tion is no longer concerned 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 supplier management and communication of requirements.
The issues relating to supplier 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 is 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.
Investigation of the outsourcing business model has identified that, in order to make such arrangements work, new roles are required within the organisation. A study by Feeny and Willcocks listed a number of key skills required within organisations 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 organisations 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 organisations recognise 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 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. Successful business change During the last few years organisations have broadened their view from IT projects to business change programmes.
Within these programmes, there has been recognition of the need for roles and skill sets that will enable the successful delivery of business change initiatives. The roles of the programme manager and change manager have been well defined, with a clear statement of their scope and focus within the business change lifecycle.
Figure 1. Later business change activities are concerned with change design and development, business acceptance testing and, after implementation, benefits review and realisation.
Clearly, extensive analysis is required here and the nature of this work falls within the remit of business analysis. However, in many organisations a coherent approach to business change, which includes business analysts in the business change lifecycle, is still awaited. The importance of the business analyst The delivery of predicted business benefits, promised from the implementation 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 organisations to implement information systems that yield competitive advantage, and yet this often appears to be just out of reach.
Organisations 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 it.
These factors have led directly to the development of the business analyst role. The importance of delivering the business benefits predicted for business change initiatives has becoming increasingly necessary to the survival of organisations.
The use of consultants Many organisations use external consultants to provide expert advice throughout the business change lifecycle. On the other hand, the use of external consultants is often criticised, particularly in public-sector organisations, because of the lack of accountability and the absence of any transfer of skills from the external consultants to internal staff.
Cost is also a key issue. Consultancy firms often charge daily fee rates that are considerably higher than the employment cost for an internal analyst and, whilst the firms may provide consultants who have a broad range of expertise, this is not always guaranteed.
The experiences gained from using external consultants have also played a part in the development of the internal business analysis role. Many business analysts have argued that they can provide the same services as external consultants and can, in effect, operate as internal consultants.
Reasons for using internal business analysts as consultants, apart from lower costs, include speed internal consultants do not have to spend time learning about the organisation and the retention of knowledge within the organisation. These factors have been recognised 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 organisations.
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.
Consequently, there have been increasing numbers of business analysts working as internal consultants over the last decade. Discussions with several hundred business analysts across a range of business forums have highlighted that business analysis job descriptions are unclear and do not always describe their responsibilities accurately.
A quick survey of the job advertisements for business analysts also reflects a range of possibilities. Even though the role of the business analyst emerged almost 20 years ago, a formal definition of the role is still debated hotly whenever there is a group of business analysts. Consultants, both internal and external, who specialise 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 they are developing.
However, it is useful to examine them separately in order to consider their relevance to the business analyst role. Some business analysts, albeit a minority, 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, we believe that strategic analysis is mostly outside the remit of business analysis.
Given that business analysts often have to recommend process and IT system solutions, it could be argued that they define the tactics that will deliver the business objectives and strategy. Hence, it is vital that they are able to work within the strategic business context. It may also be the case that some business analyst roles will require strategic-level thinking. The use of IT to enable business improve- ments and the opportunities presented by technology will need to be considered during any strategy analysis.
The business analysts are the specialist team within organisations that should be able to advise on the use of technology to drive business change. Given these issues, we feel that although strategic analysis work is not core to business analysis, business analysts will need a good understanding of strategy development processes.
Chapter 3 explores a range of 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 called systems analysis. Systems analysts are responsible for analysing and specifying the IT system requirements in sufficient detail to provide a basis for the evalua- tion 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 what data the computer system will record, what processing will be applied to that data and how the user interface will operate. Some organisations 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 decided 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 specifica- tion. The essential difference here is that a business analyst is responsible for considering a range of business options to address a particular problem or oppor- tunity; on the other hand an IT business analyst, or systems analyst, works within a defined scope and considers options for the IT solution. In some organisations there is little divide between the business analysts and the IT team.
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 apply to use the approaches and modelling techniques that fell historically within the remit of the system analyst job role.
Business analysis If the two analysis disciplines described above define the limits of analysis work, the gap in the middle is straddled by business analysis. Hence Figure 1. 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 a localised business issue.
They would need to recommend actions that would overcome a problem or achieve busi- ness 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. 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 cases, techniques such as stakeholder analysis, business process modelling and requirements engineering may all be required in order to identify the actions necessary to improve the business system. These three topics are the subjects of later chapters in this book. Realising business benefits Analysing business situations and identifying areas for business improvement 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 ensure any risks are considered.
One of the key elements of the business case will be the identification and, where relevant, the quantification of the business benefits. Organisations are placing increased emphasis upon ensuring that there is a rigorous business case to justify the expenditure on business improvement proj- ects.
This is largely because there has been a long history of failure to assess whether or not the business benefits have been realised. The business analyst will not be the only person involved in this work, but supporting the organisation in assessing whether predicted business benefits have been delivered is a key element of the role. Taking a 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.
This model shows us that business analysts need to consider these four aspects when analysing a business system. For each area, we might consider the following: The processes: are they well defined and communicated? Does the process require documents to be passed around the organisation unnecessarily? 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? The organisational context: is there a supportive management approach? Are jobs and responsibilities well defined? Is there effective cross-functional working? The technology: do the systems support the business as required? Do they provide the information needed to run the organisation? 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 organisation 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 the organisation and its impact on the people and the working practices. The adoption of an holistic approach will 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 possibili- ties.
The focus on business improvement rather than on the use of automation per se results in recommendations that typically, but not necessarily, include the use of IT.
There may be situations where a short-term non-IT solution is both helpful and cost-effective. For example, a problem may be overcome by developing internal standards or training members of staff.
These solutions may be superseded later by longer-term, possibly more costly, solutions but the focus on the business has ensured that the immediate needs have been met. Once urgent issues have been handled, the longer-term solutions can be considered more thoroughly.
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, we can recommend changes that will help deliver real business improvements.
The business analyst may be required to support the implementation of the business changes, and Figure 1. One aspect may be the business acceptance testing — a vital element if business changes are to be implemented smoothly. The implementation of business change may require extensive support from business analysts, including tasks such as: writing procedure manuals and user guides; training business staff in the use of new processes and IT systems; defining job roles and writing job role descriptions; providing ongoing support as the business staff begin to adopt the new, unfamiliar approaches.
Chapter 14 explores further the implementation of business change and the key elements to be considered. Although there are different role definitions, depending upon the organisation, there does seem to be an area of common ground where most business analysts work.
The responsibilities appear to be: To investigate business systems, taking an holistic view of the situation. This may include examining elements of the organisation structures and staff development issues as well as current processes and IT systems. To evaluate actions to improve the operation of a business system.
Again, this may require an examination of organisational structure and staff development needs, to ensure that they are in line with any proposed process redesign and IT system development. To document the business requirements for the IT system support using appropriate documentation standards. In line with this, we believe the core business analyst role should be defined as: An internal consultancy role that has the responsibility for investigating business situations, identifying and evaluating options for improving business systems, defining requirements and ensuring the effective use of information systems in meeting the needs of the business.
However, this definition is expanded by considering the guiding principles that underpin business analysis. The guiding principles for business analysis are: Root causes, not symptoms: to distinguish between the symptoms of business problems and their root causes, and to investigate and address the root causes.
Business improvement, not IT change: to recognise that IT systems should enable business opportunity, to analyse opportunities for business improvement and to enable business agility. Options, not solutions: to challenge predetermined solutions, and identify and evaluate options for meeting business needs. Feasible, contributing requirements, not all requests: to be aware of financial and timescale constraints, to identify requirements that are not feasible and do not contribute to business objectives, and to evaluate stated requirements against business needs and constraints.
The entire business change lifecycle, not just requirements definition: to analyse business situations and support the effective development, testing, deployment and post- implementation review of solutions. Negotiation, not avoidance: to recognise conflicting stakeholder views and requirements, and negotiate conflicts between stakeholders.
Business agility, not business perfection: to enable organisations to be responsive to external pressures and to recognise the importance of timely, relevant solutions. Further to the definition and guiding principles, in some organisations there are business analysis roles that apply to the strategic analysis or systems analysis activities described above.
This is typically where business analysts are in a more senior role or choose to specialise. These aspects are: Strategy implementation: here, the business analysts work closely with senior management to help define the most effective business system to implement elements of the business strategy.
Business case production: more senior business analysts usually do this, typically with assistance from finance specialists. Benefits realisation: the business analysts carry out post-implementation reviews, examine the benefits defined in the business case and evaluate whether or not the benefits have been achieved.
Actions to achieve the business benefits are also identified and sometimes carried out by the business analysts. Specification of IT requirements, typically using standard modelling techniques such as data modelling or use case modelling. These BAs have come from different backgrounds — some from IT, and many from business areas — and have brought different skills and knowledge to their business analysis teams.
The scope may be very specific, where an initial study has identified the required course of action and the analyst now needs to explore and define the solution in greater detail.
Alternatively, the scope may only have been defined at an overview level, with the BA having to carry out detailed investigation to uncover the issues before the options can be explored. The authority of the BA can also vary consider- ably, ranging from a very limited level to the ability to influence and guide at senior management level. The business analysis maturity model shows three levels of maturity found when business analysis is developing.
The first of these is where the business analysis work is concerned with defining the requirements for an IT system improvement. At this level, the scope is likely to be well defined and the level of authority to be limited to the project on which the business analyst works.
The next level is where the business analysis work has moved beyond a specific area or project, so that the analysts work cross functionally on the busi- ness processes that give rise to the requirements. The third level is where the scope and authority of the analysts are at their greatest. These levels of maturity apply to three perspectives on business analysis: the individual analysts, the business analysis teams within an organisation, and the business analysis profession as a whole.
At each level, the application of tech- niques and skills, the use of standards and the evaluation of the work through measures can vary considerably. In doing this, the BAs may initially have to develop their own process and standards. By contrast, an organisation that has employed business analysts for some time may have analysts that can work at all three levels of the BAMM.
This extremely accessible book is informed throughout by the use of clear case studies and examples that serve to bring the research process to life for student readers.
Unusually for a Methods text, Wilson also explicitly considers the importance of the supervisor in the dissertation process, and explains for the reader what lecturers are looking for from their students at every stage of the process in a good research project.
This book aims to guide the student through the entire research process by using actual student case examples and explaining the role of the supervisor and how to meet their expectations. It includes step-by-step instructions to help students learn how to use Excel and powerful but easy to use Excel add-ons such as XL Miner for data mining and Analytic Solver Platform for optimization and simulation.
Important Notice: Media content referenced within the product description or the product text may not be available in the ebook version. The expanded material in the second edition of Essentials of Business Analytics also makes it amenable to a two-course sequence in business statistics and analytics.
All statistical concepts contained in this textbook are presented from a business analytics perspective using practical business examples. It can also be used as a guide to the field by practitioners. The book has contributions from experts in top universities and industry. The editors have taken extreme care to ensure continuity across the chapters. In Part A, the tools used by business analysts are described in detail.
In Part B, these tools are applied to construct models used to solve business problems. Part C contains detailed applications in various functional areas of business and several case studies.
0コメント