Business Analyst Foundation Certification

Get Started. It's Free
or sign up with your email address
Rocket clouds
Business Analyst Foundation Certification by Mind Map: Business Analyst Foundation Certification

1. What is Business Analyst?

1.1. The origins of business analysis

1.1.1. Developments in IT have enabled organisations to create information systems that have improved business operations and management decision making.

1.1.2. Technology has enabled new business models to be implemented through more flexible communication mechanisms that allow organisations to reach out to the customer.

1.1.3. The use of IT has also created opportunities for organisations to focus on their core processes and competencies.

1.1.4. IT projects continuing to overrun their budgets by significant amounts and poor communication between business and technical experts remaining problematic.

1.2. The development of business analysis

1.2.1. The impact of outsoursing

1.2.1.1. The outsourcing business model has undoubtedly been a catalyst for the development of the business analysis function.

1.2.2. Competitive advantage of using IT

1.2.2.1. The growing recognition that three factors need to be present in order for the IT systems to deliver competitive advantage.

1.2.2.1.1. First, the needs of the business must drive the development of the IT systems;

1.2.2.1.2. Second, the implementation of an IT system must be accompanied by the necessary business changes;

1.2.2.1.3. Third, the requirements for IT systems must be defined with rigour and accuracy.

1.2.3. Successful business change

1.2.3.1. During the last few years, organisations have adopted a broader view – from IT projects to business change programmes.

1.2.3.2. There has been recognition of the need for roles and skill sets that enable the successful delivery of business change initiatives.

1.2.3.3. The business analyst role – one that uncovers the root causes of problems, identifies the issues to be addressed and ensures any solution will align with business needs – should be well defined, with a clear statement of their scope and focus within the business change lifecycle.

1.2.4. The importance of the business analyst

1.2.4.1. 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.

1.2.4.2. Organisations also want help in finding potential solutions to business issues and opportunities, sometimes where IT may not prove to be the answer.

1.2.4.3. These factors have led directly to the development of the business analyst role.

1.2.4.4. we need also to recognise the potential this can offer, particularly in a global economic environment where budgets are limited and waste of financial resources unacceptable.

1.2.5. Business analysts as internal consultants

1.2.5.1. External consultant

1.2.5.1.1. Advantages

1.2.5.1.2. Disadvantages

1.2.5.2. Internal consultant

1.2.5.2.1. Advantages

1.2.5.2.2. Disadvantages

1.3. The scope of business analysis work

1.3.1. The range of analysis activities

1.3.1.1. Strategy analysis and Definition

1.3.1.1.1. Some business analysts may be required to undertake strategic analysis and identify business transformation actions

1.3.1.2. IT system analysis

1.3.1.2.1. Systems analysts are responsible for analysing and specifying the IT system requirements

1.3.1.3. Business analysis

1.3.1.3.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.

1.3.2. Realising business benefits

1.3.2.1. The analyst may also be required to help develop a business case in order to justify the required level of investment and ensure any risks are considered.

1.3.3. Taking a holist approach

1.3.3.1. The business analyst performs a key role in supporting management’s exploitation of IT to obtain business benefit.

1.3.3.2. All aspects of the operational business system need to be analysed if all of the opportunities for business improvement are to be uncovered.

1.3.3.3. The POPIT model shows the different views that must be considered when identifying areas for improving the business system.

1.3.3.3.1. Processes

1.3.3.3.2. Organisation

1.3.3.3.3. People

1.3.3.3.4. Information

1.3.3.3.5. Technology

1.3.4. Agile systems development

1.3.4.1. The Agile philosophy is to deliver software increments early and to elaborate requirements using approaches such as prototyping.

1.3.4.2. The Agile Manifesto stated:

1.3.4.2.1. We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

1.3.4.2.2. Individuals and interactions over processes and tools;

1.3.4.2.3. Working software over comprehensive documentation;

1.3.4.2.4. Customer collaboration over contract negotiation;

1.3.4.2.5. Responding to change over following a plan.

1.3.4.2.6. That is, while there is value in the items on the right, we value the items on the left more.

1.3.4.3. The analyst will be involved in supporting the business users in clarifying, elaborating and prioritising the requirements during the development process.

1.3.5. Supporting business change

1.3.5.1. The implementation of business change may require extensive support from the business analysts, including tasks such as:

1.3.5.1.1. writing procedure manuals and user guides;

1.3.5.1.2. training business staff in the use of the new processes and IT systems;

1.3.5.1.3. defining job roles and writing job role descriptions;

1.3.5.1.4. providing ongoing support as the business staff begin to adopt the new, unfamiliar, approaches.

1.4. The role and resposibilities of a business analyst

1.4.1. Definition of the business analyst role

1.4.1.1. An advisory role which has the responsibility for investigating and analysing business situations, identifying and evaluating options for improving business systems, elaborating and defining requirements, and ensuring the effective implementation and use of information systems in line with the needs of the business.

1.4.2. Further aspects of the business analyst role

1.4.2.1. So where does this leave us in defining the role and responsibilities of a business analyst?

1.4.2.2. These core responsibilities are:

1.4.2.2.1. Investigate business system, taking holistic view of the situation.

1.4.2.2.2. Evaluate actions to improve the operation of a business system.

1.4.2.2.3. Document the business requirements for the IT system support using appropriate documentation standards.

1.4.2.2.4. Elaborate requirements, in support of the business users, during evolutionary system development.

1.4.2.3. These areas are where business analysts are in a more senior role:

1.4.2.3.1. Strategy implementation

1.4.2.3.2. Business case prodution

1.4.2.3.3. Benefits realisation

1.4.2.3.4. Specification of IT requirements

1.4.2.4. The rationale for business analysis is:

1.4.2.4.1. Root cause, not symptoms

1.4.2.4.2. Business improvements, not IT change

1.4.2.4.3. Options, not solution

1.4.2.4.4. Feasible and contributing requirements, not all requests

1.4.2.4.5. The entire business change lifecycle, not just requirements definition

1.4.2.4.6. Negotiation of conflicts, not avoidance

1.5. The business analysis maturity model (BAMM) = Scope X Authority

1.5.1. Scope LOW & Authority LOW = System Improvement

1.5.2. Scope SOME & Authority SOME = Process Improvement

1.5.3. Scope HIGH & Authority HIGH = Business Improvement

1.6. The factors that support business analyst as profession

1.6.1. Qualifications

1.6.2. Standards

1.6.3. Continuing professional development

1.6.4. Professional body

2. The Competencies of a Business Analyst

2.1. Competencies

2.1.1. Personal Qualities

2.1.1.1. Communication

2.1.1.2. Relationship

2.1.1.3. Influencing

2.1.1.4. Team work

2.1.1.5. Political awareness

2.1.1.6. Analytical skill and critical thinking

2.1.1.7. Attention to detail

2.1.1.8. Problem solving

2.1.1.9. Leadership

2.1.1.10. Self-confidence

2.1.1.11. Personal development

2.1.2. Business Knowledge

2.1.2.1. Business finance

2.1.2.2. Business case development

2.1.2.3. Domain knowledge

2.1.2.4. Subject matter expertise

2.1.2.5. IT principles

2.1.2.6. Organizational structures

2.1.2.7. Supplier management

2.1.2.8. Business architeture

2.1.3. Professional Techniques

2.1.3.1. Project management

2.1.3.2. Strategy Analysis

2.1.3.3. Stakeholder analysis and management

2.1.3.4. Investigation techniques

2.1.3.5. Requirements engineering

2.1.3.6. Business modeling

2.1.3.7. Data modeling

2.1.3.8. Gap analysis

2.1.3.9. Facilitation skills

2.1.3.10. Portifolio managements

2.1.3.11. Benefits managements

2.1.3.12. Agile thinking

2.2. Development of competencies

2.2.1. SFIA - Skills Framework for the Information Age

2.2.1.1. Level of skill

2.2.1.1.1. Follow

2.2.1.1.2. Assist

2.2.1.1.3. Apply

2.2.1.1.4. Enable

2.2.1.1.5. Ensure & Advice

2.2.1.1.6. Initiate & Influence

2.2.1.1.7. Set strategy, Inspire & Mobilise

2.2.1.2. Categories

2.2.1.2.1. Strategy & Architeture

2.2.1.2.2. Change & Transformation

2.2.1.2.3. Development & Implementation

2.2.1.2.4. Delivery & Operation

2.2.1.2.5. Skill & Quality

2.2.1.2.6. Relationship & Engagement

2.2.2. The Business analyst in the SFIA is in the category "Change & Tranformation"and the skil can range between 3 to 6.

2.2.3. Skill analysis matrix (What x How - knowledge about the problem)

2.2.3.1. What is High and How is High then the level might be 3-4

2.2.3.2. What is High and How is LOW then the level might be 4-5

2.2.3.3. What is LOW and How is High then the level might be 4-5

2.2.3.4. What is LOW and How is LOW then the level might be 6

2.3. How to develop the competencies

2.3.1. Trainning

2.3.2. Self study

2.3.3. Work experience

2.3.4. Professional certification

3. Strategy Analysis

3.1. The context for strategy

3.1.1. Why do organisations bother about strategy? What advantage do they hope to gain?

3.1.2. Most of us would probably support the idea that business is becoming increasingly unpredictable and changes are more turbulent,

3.1.3. There are some big changes that organisations face and that strategy development tries to moderate:

3.1.3.1. There are the changes to the ways that we are employed.

3.1.3.2. Society has changed.

3.1.3.3. Organisations are responding to these changes by doing everything they can to increase their flexibility and responsiveness.

3.1.3.4. The world is full of contradictions.

3.1.3.4.1. Global versus local.

3.1.3.4.2. Centralised versus decentralised organisation structures.

3.1.3.4.3. Hard and soft management.

3.2. The definition of strategy

3.2.1. A popular definition appears in Johnson, Scholes and Whittington (2008):

3.2.1.1. Strategy is the direction and scope of an organisation over the long term, which achieves advantage in a changing environment through its configuration of resources and competences with the aim of fulfilling stakeholder expectations.

3.2.2. Johnson, Scholes and Whittington (2008) provide a helpful definition of the issues to be considered during strategy analysis. These are:

3.2.2.1. the long-term direction of an organisation;

3.2.2.2. the scope of an organisation’s activities;

3.2.2.3. advantage for the organisation over competition;

3.2.2.4. strategic fit with the business environment;

3.2.2.5. the organisation’s resources and competences;

3.2.2.6. the values and expectations of powerful actors.

3.2.3. Typical levels of strategy could be

3.2.3.1. Corporate Strategy

3.2.3.1.1. Concerned with the overall purpose and scope of the business.

3.2.3.2. Business Unit Strategy

3.2.3.2.1. Below the corporate level are the strategic business units (SBUs).

3.2.3.3. Operational Strategy

3.2.3.3.1. Focuses on the delivery of the corporate and SBU strategies.

3.3. Strategy development

3.3.1. Strategy may be formulated in different ways. For example:

3.3.1.1. Strategy associated with an individual, often the founder of a business.

3.3.1.2. Strategy may develop from the experiences and views of internal managers.

3.3.1.3. Strategy emerges from the people who do the work.

3.3.1.4. Strategy by adopting a formal, carefully planned, design process.

3.3.2. Another force that may drive strategy formulation is the politics within the organisation. This force comes from five main sources:

3.3.2.1. Dependency

3.3.2.1.1. Departments are dependent on those departments that have control over the organisation’s resources.

3.3.2.2. Financial resources

3.3.2.2.1. Where are the funds to invest in the development of new ideas, products or services? Who has these funds?

3.3.2.3. Position

3.3.2.3.1. Where do the actors live in the organisation structure and how does their work affect the organisation’s performance?

3.3.2.4. Uniqueness

3.3.2.4.1. No other part of the organisation can do what the powerful group does.

3.3.2.5. Uncertainty

3.3.2.5.1. Power resides with people and groups can cope with the unpredictable effects of the environment and protect others from its impact.

3.3.3. Once a strategy has been developed, it is important to provide a written statement of the strategy:

3.3.3.1. it provides a focus for the organisation and enables all parts of it to understand the reasons behind top-level decisions and how each part can contribute to its achievement;

3.3.3.2. it provides a framework for a practical allocation of investment and other resources;

3.3.3.3. it provides a guide to innovation, where new products, services or systems are needed;

3.3.3.4. it enables appropriate performance measures to be put in place that measure the key indicators of our success in achieving the strategy;

3.3.3.5. it tells the outside world, especially our outside stakeholders and market analysts, about us and develops the expectations that they hold.

3.4. External environment analysis

3.4.1. Organisations face a complex and changing external environment of increasing unpredictability.

3.4.2. PESTLE analysis - help organisations assess their broad environment.

3.4.2.1. Political influences

3.4.2.1.1. The stability of the government or political situation

3.4.2.1.2. Government policies – such as on social welfare

3.4.2.1.3. Trade regulations and tariffs

3.4.2.2. Economic influences

3.4.2.2.1. Interest rates

3.4.2.2.2. Money supply

3.4.2.2.3. Inflation

3.4.2.2.4. Unemployment

3.4.2.2.5. Disposable income

3.4.2.2.6. Availability and cost of energy

3.4.2.2.7. The internationalisation of business

3.4.2.3. Socio-cultural influences

3.4.2.3.1. Demographics – such as an ageing population in Europe

3.4.2.3.2. Social mobility – will people move to find work or stay unemployed where they are and rely on state support?

3.4.2.3.3. Lifestyle changes – such as changes in the retirement age

3.4.2.4. Technological influences

3.4.2.4.1. Technological developments

3.4.2.4.2. Government spending on research

3.4.2.4.3. The focus on technology; demand for invention and innovation

3.4.2.4.4. The pace of technological change, the creation of technology enabled industries

3.4.2.5. Legal influences

3.4.2.5.1. Legislation about trade practices and competition

3.4.2.5.2. Employment law – employment protection, discrimination etc

3.4.2.5.3. Health and safety legislation

3.4.2.5.4. Company law

3.4.2.5.5. Financial regulation

3.4.2.6. Environmental influences

3.4.2.6.1. Global warming and climate change

3.4.2.6.2. Animal welfare

3.4.2.6.3. Waste, such as unnecessary packaging

3.4.2.6.4. Environmental protection legislation such as new laws on recycling and waste disposal industries

3.4.3. Porter’s five forces model - evaluate an industry’s profitability and hence its attractiveness (Porter 1980)

3.4.3.1. New entrants may want to move into the market...but there are barriers to entry that organisations build. These include:

3.4.3.1.1. Economies of scale.

3.4.3.1.2. Substantial investment required.

3.4.3.1.3. Product differentiation.

3.4.3.1.4. Access to distribution channels.

3.4.3.1.5. The existence of patented processes.

3.4.3.1.6. The need for regulatory approval.

3.4.3.2. Supplier power limits the opportunity for cost reductions when

3.4.3.2.1. there is a concentration of suppliers and when supplying businesses are bigger than the many customers they supply

3.4.3.2.2. the costs of switching from one supplier to another are high.

3.4.3.2.3. the supplier brand is powerful.

3.4.3.2.4. customers are fragmented so do not have a collective influence.

3.4.3.3. Customer power – or the bargaining power of buyers as Porter called it – is high when

3.4.3.3.1. there are many small organisations on the supply side.

3.4.3.3.2. alternative sources of supply are available and easy to find;

3.4.3.3.3. the cost of the product or service is high, encouraging the buyer to search out alternatives;

3.4.3.3.4. switching costs are low.

3.4.3.4. The threat from substitute products is high when:

3.4.3.4.1. product substitution from new technologies is more convenient;

3.4.3.4.2. the need for the product may be replaced by meeting a different need;

3.4.3.4.3. it is possible to decide to ‘do without it’!

3.4.3.5. There may also be high competitive rivalry when

3.4.3.5.1. there are many competing firms;

3.4.3.5.2. buyers can easily switch from one firm to another;

3.4.3.5.3. the market is growing only slowly or not growing at all;

3.4.3.5.4. the industry has high fixed costs and responding to price pressure is difficult;

3.4.3.5.5. products are not well differentiated or are commoditised so there is little brand loyalty;

3.4.3.5.6. the costs of leaving the industry are high.

3.4.4. ‘what if?’ questions

3.4.4.1. There is a high level of uncertainty and some different approaches are needed to understand potential future impacts. Scenarios may be used to do this.

3.4.4.2. They begin by identifying the potential high impact and high uncertainty factors in the environment.

3.4.4.3. It is tempting to choose just two scenarios – good and bad – when doing this, but really four or more are needed and they should be plausible and detailed.

3.5. Internal environment analysis

3.5.1. Successful strategies depend on the capability of the organisation to perform.

3.5.2. MOST analysis - understanding of the current business positioning

3.5.2.1. We can define the MOST terms as follows:

3.5.2.1.1. Mission

3.5.2.1.2. Objectives

3.5.2.1.3. Strategy

3.5.2.1.4. Tactics

3.5.2.2. When considering the MOST analysis as a means of identifying strengths and weaknesses:

3.5.2.2.1. Is the MOST clearly defined? For example, are the objectives well-formed and SMART (Specific, Measurable, Achievable, Relevant and Time framed)?

3.5.2.2.2. Is there congruence between elements of the SWOT (strengths, weaknesses, opportunities, threats)(see below)? For example, is the strategy aligned with the objectives?

3.5.2.2.3. Has the MOST been communicated to the managers and staff of the organisation?

3.5.3. Resource Audit - can help us to identify core competences.

3.5.3.1. or may highlight where there is a lack of competence that could undermine any competitive moves.

3.5.3.2. There are five key areas to examine, the first three being sets of tangible resource and the other two being sets of intangible resource.

3.5.3.2.1. Tangible resource:

3.5.3.2.2. Intangible Resource:

3.5.4. Boston Box - provides a means of conducting portfolio analysis

3.5.4.1. Developed by the Boston Consulting Group.

3.5.4.2. The relationship between the SBU’s current or future revenue potential is modelled against the current share of the market.

3.5.4.3. Enable organisations to categorise their SBUs and their products/services, and thereby consider whether and how much to invest.

3.5.4.4. Put simply, the cows are milked, the dogs are buried, the stars get the gold and the wild cats are carefully examined until they behave themselves or join the dogs and die.

3.5.4.4.1. The Cash Cows are the mature products or services, in markets with little, if any, growth.

3.5.4.4.2. The Stars strengthen their position in a growth industry until they become the big profit earners.

3.5.4.4.3. The Wild Cats (or Problem Children) are unprofitable but are investments for the future.

3.5.4.4.4. The Dogs have low market share in markets with low growth and are often the areas that are removed.

3.5.4.5. The Stars and Cash Cows provide the funding for the other segments of the matrix.

3.6. SWOT analysis

3.6.1. Pull together the results of an analysis of the external and internal environments.

3.6.2. Summarise the key strengths, weaknesses, pportunities and threats in order to carry out an overall audit of the strategic position of a business and its environment.

3.6.3. Format of a SWOT matrix

3.6.3.1. Strengths: Internal and Positive

3.6.3.2. Weakness: Internal and Negative

3.6.3.3. Opportunity: External and Positive

3.6.3.4. Threat: External and Negative

3.7. Executing strategy

3.7.1. Executing new strategies implies risk because it involves change.

3.7.2. There are five contextual issues to be considered.

3.7.2.1. Time

3.7.2.1.1. how quickly does the new strategy need to be implemented? What pace of change is needed?

3.7.2.2. Scope

3.7.2.2.1. how big is the change? Is the new strategic direction transformational or incremental?

3.7.2.3. Capability

3.7.2.3.1. does the organisation have the required resources for the change? is the organisation adaptable and able to change? Are the experiences of change positive or negative?

3.7.2.4. Readiness

3.7.2.4.1. is the whole organisation, or the part of it to be affected, ready to make the change?

3.7.2.5. Strategic leadership

3.7.2.5.1. is there a strategic leader for the change?

3.7.3. The strategic leader will have the key role and needs to demonstrate the following key characteristics:

3.7.3.1. Challenges the status quo all the time and sets new and demanding targets.

3.7.3.2. Establishes and communicates a clear vision of the direction to be taken.

3.7.3.3. ‘Models the way’ or ‘Walks the walk’.

3.7.3.4. Empowers people to deliver their part of the strategic change within the vision.

3.7.3.5. Celebrates success with those who achieve it.

3.7.4. Two tools that help in the execution of strategy

3.7.4.1. The McKinsey 7-S model

3.7.4.1.1. These are the seven levers, often described as ‘hard’ and ‘soft’ components and they are all interlinked.

3.7.4.1.2. All seven need attention if the strategy is to be executed successfully. Changing one element, means that all of the others have to change as well.

3.7.4.2. The Balanced Business Scorecard

3.7.4.2.1. The emphasis of the scorecard is to measure aspects of performance in a balanced way.

3.7.4.2.2. In the past, managers have perhaps paid more attention to the financial measures.

3.7.4.2.3. The BBS shows it is important to consider all of the four aspects and answers questions like these:

3.7.5. Critical Success Factors and Key Performance Indicators

3.7.5.1. The BBS helps in the definition of CSFs and KPIs which are vital to assess business performance.

3.7.5.2. It’s important that KPIs are defined as SMART and that they are monitored regularly.

4. The Business Analysis Process Model

4.1. An approach to problem-solving

4.1.1. Mess finding

4.1.1.1. where we often begin when undertaking a problem investigation.

4.1.2. Data finding

4.1.2.1. concerned with analysing the opinions, concerns, knowledge and ideas uncovered in the previous stage.

4.1.3. Problem finding

4.1.3.1. uses the work of the previous two stages to help uncover the heart of the problem.

4.1.4. Idea finding

4.1.4.1. which business analysts try to generate a wide range of ideas.

4.1.5. Solution finding

4.1.5.1. they can be evaluated and we can focus on those that could provide solutions to the problem(s).

4.1.6. Acceptance finding

4.1.6.1. concerned with gaining business acceptance of the solution.

4.2. The Business Analysis process model shows the importance of understanding the business context. We need to be aware of the Mission, Objective, Strategy and Tactics (MOST).

4.3. Stages of the business analysis process model

4.3.1. Investigate situation

4.3.1.1. Objectives

4.3.1.1.1. Concerned with uncovering issues and problems.

4.3.1.1.2. The OSCAR mnemonic can be very useful when clarifying the terms of reference if none exist.

4.3.1.2. Procedure

4.3.1.2.1. Study background material – project initiation document, terms of reference

4.3.1.2.2. Carry out initial investigation with key stakeholders

4.3.1.2.3. Document the results of the investigation – using meeting reports plus diagrams such as a ‘rich picture’, mind-map or fishbone diagrams

4.3.1.3. Inputs

4.3.1.3.1. Terms of reference or project initiation document

4.3.1.3.2. MOST, statement of business values

4.3.1.4. Outputs

4.3.1.4.1. View of the existing business situation, including meeting reports and diagrams such as rich pictures, mind maps and fishbone diagrams

4.3.1.4.2. List of issues/problems

4.3.1.5. Techniques

4.3.1.5.1. Investigation techniques such as interviewing, observation and workshops

4.3.1.5.2. Quantitative investigation techniques such as surveys, sampling and document analysis

4.3.1.5.3. ‘Rich pictures’

4.3.1.5.4. Mind maps

4.3.1.5.5. Spaghetti maps

4.3.1.5.6. Fishbone diagrams

4.3.1.5.7. Business process models

4.3.2. Consider perspectives

4.3.2.1. Objectives

4.3.2.1.1. Take stock of the range of stakeholder perspectives about the business system under investigation.

4.3.2.1.2. These perspectives may then be analysed to uncover stakeholder values and beliefs, and developed into business activity models.

4.3.2.2. Procedure

4.3.2.2.1. Identify key stakeholders whose perspectives are important to the business analysis project

4.3.2.2.2. Investigate the values, beliefs and priorities of the key stakeholders

4.3.2.2.3. Develop and analyse the stakeholder perspectives

4.3.2.2.4. Build conceptual models of activities to fulfil the stakeholder perspectives

4.3.2.2.5. Explore and resolve conflicts between stakeholder perspectives

4.3.2.2.6. Synthesise conceptual models into one view of the desired business system

4.3.2.3. Inputs

4.3.2.3.1. Terms of reference or project initiation document

4.3.2.3.2. Business values and MOST

4.3.2.3.3. Identified stakeholders (from the documentation of the existing business system)

4.3.2.4. Outputs

4.3.2.4.1. Power/Interest grid

4.3.2.4.2. Stakeholder perspectives

4.3.2.4.3. Business activity models based upon stakeholder perspectives

4.3.2.4.4. Consensus business activity model

4.3.2.5. Techniques

4.3.2.5.1. Investigation and negotiation techniques

4.3.2.5.2. Stakeholder identification and analysis

4.3.2.5.3. CATWOE

4.3.2.5.4. Business Activity Modelling (BAM)

4.3.3. Analyse needs

4.3.3.1. Objectives

4.3.3.1.1. Explore the differences between the current and desired situations.

4.3.3.1.2. Identify the opportunities for business change by analysing these differences or ‘gaps’.

4.3.3.2. Procedure

4.3.3.2.1. Examine the activities on the business activity model

4.3.3.2.2. Consider how well each activity is carried out in the current business system and how well it is supported by the organisation’s information systems

4.3.3.2.3. Identify the key business events to be handled within the business system; develop ‘as is’ business process models for the key business events

4.3.3.2.4. Develop ‘to be’ business process models for the key business events

4.3.3.2.5. Analyse the gaps between the existing and the desired business systems. Use these as a basis for identifying potential business system improvements

4.3.3.2.6. Ensure any potential improvements align with the business architecture

4.3.3.3. Inputs

4.3.3.3.1. Agreed business activity model

4.3.3.3.2. View of the existing business system

4.3.3.3.3. Business values and MOST

4.3.3.4. Outputs

4.3.3.4.1. Analysis of activities, including identified areas of weakness

4.3.3.4.2. ‘As is’ and ‘to be’ business process models

4.3.3.4.3. List of potential improvements to the business system

4.3.3.5. Techniques

4.3.3.5.1. Gap analysis

4.3.3.5.2. Activity analysis

4.3.3.5.3. Business process modelling

4.3.4. Evaluate options

4.3.4.1. Objectives

4.3.4.1.1. Collect together the range of potential changes into packages of improvement actions.

4.3.4.1.2. These packages form the basis for developing a set of options.

4.3.4.1.3. They are then presented to business managers for consideration.

4.3.4.2. Procedure

4.3.4.2.1. Identify range of business options

4.3.4.2.2. Explore acceptability of options and reduce to a shortlist

4.3.4.2.3. Develop and document each option in detail. In particular, consider the business, technical and financial feasibility of each option

4.3.4.2.4. Develop business case, including presenting options and recommendations to business managers

4.3.4.3. Inputs

4.3.4.3.1. Project initiation document/terms of reference

4.3.4.3.2. Business values and MOST

4.3.4.3.3. List of potential improvements to the business system

4.3.4.4. Outputs

4.3.4.4.1. Shortlist of business options

4.3.4.4.2. Business case including options, feasibility assessment and recommendations

4.3.4.5. Techniques

4.3.4.5.1. Evaluate

4.3.4.5.2. Business options identification

4.3.4.5.3. Cost-benefit analysis, including quantification of costs and benefits; investment appraisal techniques

4.3.4.5.4. Impact analysis

4.3.4.5.5. Risk analysis

4.3.5. Define requirements

4.3.5.1. Objectives

4.3.5.1.1. Produce a well-formed requirements document setting out the business requirements for the new business system.

4.3.5.1.2. This document must include clear textual descriptions of the requirements and sufficient information to trace each requirement.

4.3.5.1.3. Modelling techniques may be used to represent the process and data requirements diagrammatically and hence improve the rigour and clarity.

4.3.5.2. Procedure

4.3.5.2.1. Gather the requirements:

4.3.5.2.2. Document the requirements for the new business system, including as appropriate:

4.3.5.3. Inputs

4.3.5.3.1. Selected option for revised business system

4.3.5.3.2. Business values and MOST

4.3.5.3.3. Terms of reference/project initiation document

4.3.5.4. Outputs

4.3.5.4.1. To be’ process models

4.3.5.4.2. Job definitions

4.3.5.4.3. Revised organisational structure

4.3.5.4.4. Validated requirements document including:

4.3.5.5. Techniques

4.3.5.5.1. Business process modelling

4.3.5.5.2. Job design

4.3.5.5.3. Investigation techniques

4.3.5.5.4. Requirements elicitation, analysis and validation

4.3.5.5.5. Requirements documentation and management

4.3.5.5.6. IT systems modelling techniques

4.3.6. Deliver changes

4.3.6.1. Objective

4.3.6.1.1. The lifecycle and approach to be adopted to develop and deliver the changes will need to be determined.

4.3.6.1.2. The delivery of the business solution will need to consider aspects such as the emotional impact of change and the realisation of the business benefits.

4.3.6.2. Procedure

4.3.6.2.1. Decide the lifecycle and approach to be adopted

4.3.6.2.2. Design and develop the business change solution

4.3.6.2.3. Support the planning and implementation, in particular the development of the required learning materials and the delivery of training for the business staff

4.3.6.2.4. Review the predicted benefit

4.3.6.2.5. Identify any actions required to realise the benefits

4.3.6.3. Inputs

4.3.6.3.1. Business change process and organisation design

4.3.6.3.2. IT software solution

4.3.6.3.3. Business case

4.3.6.4. Outputs

4.3.6.4.1. Business change plan

4.3.6.4.2. Communication plan

4.3.6.4.3. Training approach and materials

4.3.6.4.4. Revised job roles and descriptions

4.3.6.4.5. Benefits plan

4.3.6.4.6. Benefits review document

4.3.6.5. Techniques

4.3.6.5.1. Use case descriptions

4.3.6.5.2. Decision tables

4.3.6.5.3. State charts

4.3.6.5.4. Benefits planning

5. Investigation Techniques

5.1. Prior research

5.1.1. Study website

5.1.2. Study company reports

5.1.3. Study procedure manuals and documentation

5.1.4. Study the organisation chart

5.2. Qualitative approaches

5.2.1. Interviews

5.2.1.1. A well-run interview can be vital in achieving a number of objectives. These include:

5.2.1.1.1. making initial contact with key stakeholders and establishing a basis for the business analysis work;

5.2.1.1.2. building and developing rapport with different business users and managers;

5.2.1.1.3. acquiring information about the business situation, including any issues and problems;

5.2.1.1.4. discovering different stakeholder perspectives and priorities.

5.2.1.2. There are three areas that are considered during fact-finding or requirements interviews:

5.2.1.2.1. current functions that need to be fulfilled in any new business system;

5.2.1.2.2. problems with the current operations or performance that need to be addressed;

5.2.1.2.3. additional features required from the new business system.

5.2.1.3. Advantages of interviewing

5.2.1.3.1. provides an opportunity to build a relationship with the users or clients.

5.2.1.3.2. the interview can yield important information.

5.2.1.3.3. understand different viewpoints and attitudes across the user group;

5.2.1.3.4. investigate new areas previously not mentioned;

5.2.1.3.5. identify and collect examples of documents, forms and reports the clients use;

5.2.1.3.6. appreciation of political factors that may affect how the business performs its work;

5.2.1.3.7. study the environment in which the business staff carry out their work.

5.2.1.4. Disadvantages of interviewing

5.2.1.4.1. take time and can be an expensive approach.

5.2.1.4.2. take up the interviewee’s time, and this may mean that they try to hurry the interview.

5.2.1.4.3. information provided during interviews may be an opinion from just one interviewee’s perspective.

5.2.1.4.4. Where several interviewees have different views may create a need for follow-up discussions and further investigative work.

5.2.1.5. Preparing for interviewing

5.2.1.5.1. This saves a lot of time by avoiding unnecessary explanations and also demonstrates interest and professionalism, which helps to establish a mutual respect and rapport.

5.2.1.5.2. The classic structure of who?, why?, what?, when? and where? provides an excellent framework for preparing for interviews.

5.2.1.6. Conducting the interview

5.2.1.6.1. It is important to structure interviews if the maximum amount of information is to be elicited using a basic structure.

5.2.1.7. Following up the interview

5.2.1.7.1. It is always a good idea to write up the notes of the interview as soon as possible – ideally straight away and usually by the next day.

5.2.2. Observation

5.2.2.1. Observing the workplace, and the staff carrying out their work, especially early in an investigation, is very useful in obtaining information about the business environment and the work practices.

5.2.2.2. The person being observed should be reassured that the objective is to understand the task not to judge their performance.

5.2.2.3. There are several different approaches to observation, depending upon the level and focus of interest:

5.2.2.3.1. Formal observation

5.2.2.3.2. Protocol analysis

5.2.2.3.3. Shadowing

5.2.2.3.4. Ethnographic studies

5.2.2.4. Advantages of observation

5.2.2.4.1. We obtain a much better understanding of the problems and difficulties faced by the business users.

5.2.2.4.2. Help us prepare appropriate questions for a more in-depth interview with the person responsible for that task.

5.2.2.4.3. It will help us to devise workable solutions that are more likely to be acceptable to the business.

5.2.2.5. Disadvantages of observation

5.2.2.5.1. Being observed can be rather unnerving.

5.2.2.5.2. The old saying ‘you change what you observe’ needs to be factored into the approach taken.

5.2.3. Workshops

5.2.3.1. Advantages of workshops

5.2.3.1.1. Gain a broad view of the area under investigation.

5.2.3.1.2. Increase speed and productivity.

5.2.3.1.3. Obtain buy-in and acceptance for the project.

5.2.3.1.4. Gain a consensus view or group agreement.

5.2.3.2. Disadvantages of workshops

5.2.3.2.1. Workshops can be time-consuming to organise.

5.2.3.2.2. If the workshop is not carefully facilitated, it may happen that a forceful participant will dominate the discussion.

5.2.3.2.3. It can be difficult to ensure that the participants have the required level of authority.

5.2.3.3. Preparing for the workshop

5.2.3.3.1. The success or failure of a workshop session depends in large part upon the preparatory work done.

5.2.3.3.2. They should spend time before the event planning the following areas:

5.2.3.4. Facilitating the workshop

5.2.3.4.1. The workshop should start by discussing the objective and endeavouring to secure the participants’ buy-in.

5.2.3.4.2. The facilitator needs to ensure that the issues are discussed, views are aired and progress is made towards achieving the stated objective.

5.2.3.4.3. A record needs to be kept of the key points emerging from the discussion.

5.2.3.4.4. At the end, the facilitator needs to summarise the key points and actions.

5.2.3.5. Techniques

5.2.3.5.1. Discovery techniques

5.2.3.5.2. Visualisation techniques

5.2.3.5.3. Hothouse workshop

5.2.3.5.4. Focus groups

5.2.3.6. Following the workshop

5.2.3.6.1. After the workshop any key points and actions are written up and sent to stakeholders.

5.2.3.6.2. This should be done as quickly as possible

5.2.4. Scenarios

5.2.4.1. Advantages of scenarios

5.2.4.2. Disadvantages of scenarios

5.2.4.3. Process for developing scenarios

5.2.4.3.1. Identify the task or interaction

5.2.4.3.2. Identify the steps and sequence

5.2.4.3.3. Define the control conditions

5.2.4.3.4. Identify the alternative paths

5.2.4.4. Documenting scenarios

5.2.4.4.1. A popular way of documenting scenario descriptions is to develop use case descriptions to support use case diagrams.

5.2.4.4.2. This technique is part of the Unified Modeling Language (UML) and is a textual method.

5.2.4.4.3. However, there are a number of graphical methods for documenting a scenario, such as storyboards, activity diagrams, task models and decision tree diagrams.

5.2.5. Prototyping

5.2.5.1. Important technique for eliciting, analysing, demonstrating and validating requirements.

5.2.5.2. Help business users visualise the new system and provide insight into possible requirements.

5.2.5.3. Offer a way of demonstrating how the new processes or system might work and provide a concrete basis for evaluation and discussion.

5.2.5.4. Agile software development approaches, use evolutionary prototyping as an integral part of their development lifecycle.

5.2.5.5. There is a strong link between scenarios and prototyping because scenarios can be used as the basis for developing prototypes.

5.2.5.6. Advantages of prototyping

5.2.5.6.1. to clarify any uncertainty on the part of the analysts and confirm to the user that we have understood what they asked for;

5.2.5.6.2. to help the user identify new requirements as they gain an understanding of what the system will be able to do to support their jobs;

5.2.5.6.3. to demonstrate the look and feel of the proposed system and elicit usability requirements;

5.2.5.6.4. to validate the system requirements and identify any errors;

5.2.5.6.5. to provide a means of assessing the navigation paths and system performance.

5.2.5.7. Disadvantages of prototyping

5.2.5.7.1. The prototyping cycle can spin out of control with endless iterations taking place.

5.2.5.7.2. If the purpose of the exercise has not been explained clearly, the users may think that when they are happy with the mock-up, the system is now complete and ready for use.

5.2.5.7.3. User expectations can be raised unnecessarily by failing to mimic the final appearance of the system, or its performance; If there is likely to be a delay in the real response time, it is important that you build that into the prototype.

5.3. Quantitative approaches

5.3.1. Surveys or Questionnaires

5.3.1.1. Can be useful if we need to get a limited amount of information from a lot of people and interviewing them individually.

5.3.1.2. Can be useful if we need to run a series of workshops would not be practical or cost-effective.

5.3.1.3. However, surveys are difficult to design and this has to be done with care in order to have any possibility of success.

5.3.1.4. The exact design of a survey depends upon its purpose but there are three main areas to consider:

5.3.1.4.1. heading

5.3.1.4.2. classification

5.3.1.4.3. data sections

5.3.2. Special Purpose Records

5.3.2.1. Special purpose records are data-gathering forms used by the analyst;

5.3.2.2. The format is usually decided by the analyst and they are not company records.

5.3.2.3. They can be completed either by the analyst during an observation session or given to the business users to complete.

5.3.3. Activity Sampling

5.3.3.1. Can be used when it is necessary to know how people divide their work time among a range of activities.

5.3.3.2. The results provide quantifiable data about the number of times an activity is carried out per day by the group studied.

5.3.3.3. An activity sampling exercise is carried out in five steps:

5.3.3.3.1. 1. Identify the activities to be recorded. This list should include a ‘not working’ activity as this covers breaks, and also ‘not-related’ task.

5.3.3.3.2. 2. Decide on the frequency and timings, i.e. when and how often you will record the activities being undertaken.

5.3.3.3.3. 3. Visit the study group at the times decided upon and record what each group member is doing.

5.3.3.3.4. 4. Record the results.

5.3.3.3.5. 5. After a set period, analyse the results.

5.3.4. Document Analysis

5.3.4.1. Involves reviewing samples of source documents to uncover information about an organisation, process or system.

5.3.4.2. Useful to supplement other techniques such as interviewing, workshops and observation.

5.4. Documenting the current situation

5.4.1. While the investigation of the current situation is going on, the analyst will need to record the findings, in order to understand the range of issues and the business needs.

5.4.2. Meeting reports should be produced for each interview and workshop so that they can be agreed with the participants.

5.4.3. It is also helpful to use diagrams to document the business situation.

5.4.4. This section suggests five diagrammatic techniques:

5.4.4.1. Rich pictures

5.4.4.1.1. One of the few that provide an overview of an entire business situation.

5.4.4.1.2. Modelling approaches such as data or process modelling provide a clear representation of a specific aspect of a business system.

5.4.4.1.3. Does not have a fixed notation, but allows the analyst to use any symbols or notation that are relevant and useful.

5.4.4.1.4. Can show the human characteristics of the business situation and can reflect intangible areas such as the culture of the organisation.

5.4.4.2. Mind maps

5.4.4.2.1. Useful tool for summarising a lot of information in a simple visual form that is structured to highlight connections between different ideas and topics.

5.4.4.2.2. They provide a means of organising information while, representing all of the issues that have been uncovered about the situation.

5.4.4.2.3. The business system or problem under consideration is drawn at the centre of the diagram with the main elements shown as first level of branches.

5.4.4.3. Business process models

5.4.4.3.1. In order to understand fully how a process is carried out.

5.4.4.3.2. It is helpful to draw a ‘swimlane’ diagram, which shows the tasks in a process, the actors responsible for carrying them out and the process flow.

5.4.4.3.3. Invaluable as a diagnostic aid since they help identify problems such as delays, bottlenecks and duplicate tasks.

5.4.4.4. Spaghetti maps

5.4.4.4.1. A tool to show the movement and interactions of the stakeholders in a particular environment, when performing particular tasks and processes.

5.4.4.4.2. Can be drawn up during an observation session, mapping the movements of users across the room to meet different actors or to use equipment.

5.4.4.5. Fishbone diagrams

5.4.4.5.1. A problem-analysis technique, designed to help understand the underlying causes of an inefficient process or a business problem.

5.4.4.5.2. It is similar to a mind map in some ways, but its purpose is strictly diagnostic.

5.4.4.5.3. A number of approaches may be used when labelling the spines:

6. Stakeholder Analysis and Management

6.1. Stakeholder categories and identification

6.1.1. Customers

6.1.2. Partners

6.1.3. Suppliers

6.1.4. Competitors

6.1.5. Regulators

6.1.6. Owners

6.1.7. Employees

6.1.8. Managers

6.2. Analysing stakeholders

6.2.1. Having identified the stakeholders, the next step is to make an assessment of the weight that should be attached to their issues.

6.2.2. In using the power/interest grid, it is important to plot stakeholders where they actually are.

6.3. Stakeholder management strategies

6.3.1. Power/interest grid

6.3.1.1. No or low interest and no or low power/influence

6.3.1.1.1. Ignore

6.3.1.2. Some or high interest but no or low power/influence

6.3.1.2.1. Keep informed

6.3.1.3. No or low to high interest but some power/influence

6.3.1.3.1. Keep onside

6.3.1.4. No or low interest but high power/influence

6.3.1.4.1. Whatch

6.3.1.5. Some interest and high power/influence

6.3.1.5.1. Keep satisfied

6.3.1.6. High interest and high power/influence

6.3.1.6.1. Constant, active management

6.3.2. Individuals and groups of stakeholders

6.3.2.1. Stakeholders must be considered not just as individuals but as potential groups as well.

6.3.2.2. Their ability to gain strength, particularly with the availability of social media mechanisms, should never be underestimated.

6.3.3. The stakeholders do not stay in the same place over time and so the ways they are managed must be adapted accordingly.

6.4. Managing stakeholders

6.4.1. Stakeholder plan/assessment

6.4.2. Stakeholders’ positions do not remain static during the life of a project.

6.4.3. Once stakeholders’ initial positions have been plotted, a plan should be drawn up for managing each of them and how to approach it.

6.4.4. A one-page assessment can be made for each stakeholder.

6.4.5. Useful approach would be to see all stakeholders at a glance by setting up a spreadsheet using the following headings:

6.4.5.1. Name of stakeholder

6.4.5.1.1. It may also be useful to record their current job titles.

6.4.5.2. Current power/influence

6.4.5.2.1. From the grid.

6.4.5.3. Current interest

6.4.5.3.1. From the grid.

6.4.5.4. Issues and interests

6.4.5.4.1. This is a brief summary of what interests each stakeholder and what we believe their main issues with the project are likely to be.

6.4.5.5. Current attitude

6.4.5.5.1. Champion: will actively work for the success of the project.

6.4.5.5.2. Supporter: in favour of the project but probably will not be very active in promoting it.

6.4.5.5.3. Neutral: has expressed no opinion either in favour or against the project.

6.4.5.5.4. Critic: not in favour of the project but probably not actively opposed to it.

6.4.5.5.5. Opponent: will work actively to disrupt, impede or derail the project.

6.4.5.5.6. Blocker: someone who will just obstruct progress, possibly for reasons outside of the project itself.

6.4.5.6. Desired support

6.4.5.6.1. What we would ideally like from this stakeholder, perhaps using a simple scale of high, medium or low.

6.4.5.7. Desired role

6.4.5.7.1. We may wish to get this stakeholder actively involved in the project, perhaps as the project sponsor or as part of a steering committee.

6.4.5.8. Desired actions

6.4.5.8.1. What we would like the stakeholder to do, if at all possible, to advance the project.

6.4.5.9. Messages to convey

6.4.5.9.1. This is where we define the emphasis that should be put on any communications to this stakeholder.

6.4.5.10. Actions and communications

6.4.5.10.1. This is the most important part of the plan, where we define exactly what actions we will take with regard to this stakeholder.

6.4.6. Defining stakeholder involvement by RACI and RASCI charts

6.4.6.1. A RACI chart – more formally known as a ‘linear responsibility matrix’ – lists the main products/deliverables down the side and the various stakeholders along the top.

6.4.6.2. Where a stakeholder intersects with a product, we indicate their involvement using one of the RACI categories, which mean:

6.4.6.2.1. Responsible:

6.4.6.2.2. Accountable:

6.4.6.2.3. Consulted:

6.4.6.2.4. Informed:

6.4.6.3. A RASCI chart uses a similar approach but has an additional category S for ‘support’.

6.4.6.3.1. Support:

6.4.7. Using social media in stakeholder management

6.4.7.1. Offers the business analyst additional resources to learn about stakeholders and to manage the relationships with them.

6.4.7.2. Facebook and Twitter offer a cost-effective way of communicating with large groups of people on a frequent basis and keeping them informed

6.4.7.3. This can help to build a sense of community and make people feel involved in what is going on.

6.5. Understanding stakeholder perspectives

6.5.1. Soft Systems Methodology

6.5.1.1. The basic premise underlying SSM is that real-world situations are rarely simple and are often very complex.

6.5.1.2. It is often the case that stakeholders have different views about what the ‘problem’ is and also about what needs to be done.

6.5.1.3. There are five main stages that should be applied:

6.5.1.3.1. A real-world situation to be explored

6.5.1.3.2. Stakeholders’ perspectives on the situation and the organisation

6.5.1.3.3. Conceptual models based on each perspective

6.5.1.3.4. Comparation of models with perceived real-world situation

6.5.1.3.5. Definition of actions needed to improve the situation

6.5.2. Analysing the perspectives

6.5.2.1. SSM provides us with a very useful tool that we can use to explore the stakeholders’ perspectives.

6.5.2.2. CATWOE elements is actually best done in the following order:

6.5.2.2.1. W = Weltanschauung or worldview: This summarises a stakeholder’s beliefs about the organisation or business system, which explain why it exists and what it should be doing.

6.5.2.2.2. T = Transformation: This is the principal business activity of the business system, in other words what lies at the heart of its operations.

6.5.2.2.3. C = Customer(s): Stakeholders can differ, too, in their views of who their customers are (or should be).

6.5.2.2.4. A = Actor(s): These are the people who carry out the transformation.

6.5.2.2.5. O = Owner(s): The perspective is someone’s view of a business system.

6.5.2.2.6. E = Environment: All organisations operate within the constraints imposed by their environment. PESTLE can be used to identify the main external factors.

6.6. Busines activity models

6.6.1. Creating a business activity model

6.6.1.1. A conceptual model of what we would expect to see to fulfil a particular stakeholder perspective.

6.6.1.2. The business analyst to think about the activities that each stakeholder’s perspective implies.

6.6.1.3. A BAM shows what the organisation should be doing, as opposed to a business process model which explores how it does these things.

6.6.2. Types of activities – Plan, Enable, Do, Monitor, Control

6.6.2.1. DOING activities that are at the heart of the model. These are derived from the transformation of CATWOE and reflect the organisation’s principal business activities.

6.6.2.2. ENABLING activities are next added. These lead into the doing activities on the model and acquire or replenish the resources needed to carry them out.

6.6.2.3. PLANNING activities. We are interested in the planning required within this business system (which will support the strategy execution). Planning activities also include setting targets, such as KPIs.

6.6.2.4. MONITORING activities, the actual evaluation of the performance is done.

6.6.2.5. CONTROL activities may be required to institute the necessary remedial actions, if the monitoring activities reveal that performance is not what was expected in the plans.

6.6.3. Developing a consensus model

6.6.3.1. Initially, there will be one BAM for each distinct perspective.

6.6.3.2. At a later point, these are examined in order to identify where there is agreement or conflict between the BAMs.

6.6.3.3. Ultimately, the aim is to combine them and, in discussion with the stakeholders, achieve a consensus BAM.

7. Modelling Business Processes

7.1. The business processes are the means by which an organisation carries out the internal operations and delivers its products and services to its customers.

7.2. There are many reasons for creating business process models:

7.2.1. To understand how the existing process works.

7.2.2. To explain what they do and how their task relates to the others working on the process.

7.2.3. To help ensure consistency of approach.

7.2.4. To identify the problems and weaknesses of an existing business process

7.3. Organisational context

7.3.1. It is useful to examine the organisational context in which the business processes take place.

7.3.2. The traditional view of a business is based on the specialist functional areas.

7.3.3. Functional view of an organisation

7.3.3.1. Very useful for the internal management and staff to see how the organisation is structured and where they fit within it.

7.3.3.2. There are some limitations with this view:

7.3.3.2.1. It is predominantly internally oriented, concentrating on the structure of the organisation and the internal reporting lines,

7.3.3.2.2. it defines the formal structure, ignoring the unofficial communication and cooperation between staff.

7.3.3.2.3. This view is also ‘static’ as it does not show what the business does over time.

7.3.3.3. Thinking of the organisation as separate, autonomous departments may erect barriers and create operational difficulties

7.4. An alternative view of an organisation

7.4.1. Paul Harmon (2007) developed the organisation model that provides an alternative view of an organisation,

7.4.2. The model is often developed in two stages: firstly, the external factors that influence the organisation are considered and then the internal business process is analysed.

7.4.3. There are four areas that define the context in which the organisation operates.

7.4.3.1. The suppliers of the resources required by the business processes.

7.4.3.2. The beneficiaries from the organisation.

7.4.3.3. The competitors operating within the same industry or business domain.

7.4.3.4. The generic factors that may affect the organisation such as changing regulation, economics or green issues.

7.4.4. Analysing the external context encourages the business analyst to think carefully about the context for the organisation.

7.5. The organisational view of business processes

7.5.1. An organisational business process map is formed from a high-level set of activities carried out in order to deliver benefit or value to the customers.

7.5.2. Process maps show sets of related processes, and their interactions, in a single diagram.

7.5.3. It is useful to begin by considering:

7.5.3.1. the core operation at the heart of the entire process, for example, taking bookings or selling goods;

7.5.3.2. the processes that provide input to the core process, for example, scheduling events or making goods;

7.5.3.3. the processes concerned with delivering products or services to the customer, for example, issuing event confirmation or delivering goods;

7.5.3.4. any sales, marketing or customer service processes.

7.5.4. The overview process map is extremely useful to identify the boundaries of each process by showing where the process begins and where it ends.

7.5.5. An alternative approach is the Michael Porter’s value chain to take a look at the products and services and consider what processes are required to deliver them.

7.5.6. We can use the concept of a value chain to develop high-level process maps for the organisation.

7.6. Value propositions

7.6.1. A value proposition is a definition of an organisation’s product or service that will demonstrate to customers that we understand and can satisfy their needs.

7.6.2. The proposition attributes cover three areas:

7.6.2.1. product/service attributes that define the product itself;

7.6.2.2. customer relationship aspects;

7.6.2.3. image and reputation aspects.

7.6.3. Elements of a value proposition:

7.6.3.1. Product / Service

7.6.3.1.1. Functionality – or what the product does.

7.6.3.1.2. Price – what we charge for the product.

7.6.3.1.3. Quality – or how well the product performs.

7.6.3.1.4. Choice – do we simply provide a standard product or can it be tailored to the specific needs of the customer?

7.6.3.1.5. Availability or timing – for example how quickly can we respond to customer requests

7.6.3.2. Image

7.6.3.2.1. The image may be that of the product, built up through extensive advertising and supported by the product attributes in order to generate customer loyalty.

7.6.3.3. Relationship

7.6.3.3.1. The customer relationship aspects will influence how a customer feels about purchasing from the organisation.

7.6.4. An organisation can differentiate itself in three ways:

7.6.4.1. by being the most efficient;

7.6.4.1.1. Efficiency here means high volumes, low costs (and hence, low prices).

7.6.4.2. by having the best products;

7.6.4.2.1. Best products implies high quality but also innovation and the ability to introduce new products before the competition.

7.6.4.3. by providing the best customer service.

7.6.4.3.1. High levels of customer service rely on flexibility which allows the product to be adaptable to the exact needs of the customer.

7.7. Business Process models

7.7.1. A business process is triggered by a business event and includes five key components:

7.7.1.1. the tasks that make up the process

7.7.1.2. the decision points

7.7.1.3. the process flow, the decision points

7.7.1.4. the actors that carry out the tasks

7.7.1.5. the outcome of the business process.

7.7.2. Unfortunately, there is no universally agreed set of terms in business process modelling. We have adopted the following convention:

7.7.2.1. ‘Process’

7.7.2.1.1. refers to an entire set of activities that start with a triggering event and end with some output being delivered.

7.7.2.2. ‘Task’

7.7.2.2.1. refers to an individual activity within the overall process; these are usually carried out by an actor at a single point in time.

7.7.2.3. ‘Step’

7.7.2.3.1. refers to the activities carried out within an individual task.

7.7.3. Business events

7.7.3.1. External – these business events originate from outside the organisation or the business system under consideration.

7.7.3.2. Internal – these business events originate within the business system and typically involve business managers making decisions.

7.7.3.3. Time-based – these business events occur at a regular point in time.

7.7.4. Developing the business process model

7.7.4.1. Two of the most popular are the UML activity diagram technique and the Business Process Model and Notation (BPMN).

7.7.4.2. Often called ‘swimlane diagrams’ because the ‘swimlanes’ showing all of the tasks performed by a defined ‘actor’,

7.7.4.3. The swimlane diagramming technique includes the following elements:

7.7.4.3.1. the overall layout;

7.7.4.3.2. the symbols used;

7.7.4.3.3. the sequencing of the symbols.

7.7.4.4. Actors may be individual people, a group of people or an organisation, or may be an IT system.

7.7.4.4.1. where they get their input information from;

7.7.4.4.2. in general terms, what they do with it;

7.7.4.4.3. where they forward it after they have completed their work.

7.7.4.5. The tasks carried out by each actor are shown in a separate band or ‘swimlane’ and arrows are used to show the flow of the work between the different swimlanes.

7.7.4.5.1. The trigger or business event that initiates the task.

7.7.4.5.2. Inputs to the task. This may include the trigger.

7.7.4.5.3. Outputs from the task.

7.7.4.5.4. Costs relevant to this particular task.

7.7.4.5.5. Measures and standards applicable to the task.

7.7.4.5.6. Detailed breakdown of steps within the task.

7.7.4.5.7. Business rules to be followed in performing the task.

7.7.4.6. Hierarchy of process models

7.7.4.6.1. The set of process models – from organisation-level to swimlane diagram to task analysis.

7.7.4.7. Beginning and ending the process

7.7.4.7.1. It is usual for the swimlane of the process initiator to be at the top of the model.

7.7.4.7.2. The variations between the different approaches determine how much detail is shown in that particular swimlane.

7.7.4.7.3. The end of a process is represented by a bullseye symbol.

7.7.4.7.4. Usually processes have multiple pathways and hence multiple ways in which they can end.

7.8. Analysing the as-is process model

7.8.1. Processes are constantly changing to reflect the different environment in which they operate.

7.8.2. Unfortunately, many of these changes occur in an ad hoc and uncontrolled way.

7.8.3. Identifying problems

7.8.3.1. We need to find out how well the 'as-is' process supports the business.

7.8.3.2. Once we have determined the required performance levels, the next step is to compare them with the actual performance of the existing process.

7.8.3.3. A gap between the actual and required performance levels indicates the need for improvements.

7.8.4. Analysing the hand-offs

7.8.4.1. Where one actor passes the work to another actor.

7.8.4.2. Queues form at hand-offs because the two actors have not synchronised their work.

7.8.4.3. A further cause of delays is where there is inadequate resource capacity to handle the throughput.

7.8.5. Analysing the processing

7.8.5.1. it is important to look for the following possibilities:

7.8.5.1.1. Duplication of work.

7.8.5.1.2. Redundancy.

7.8.5.1.3. Lack of standardisation.

7.8.5.1.4. Incompleteness.

7.8.5.1.5. Inconsistent measurement or control.

7.8.6. Other factors causing inadequate performance of a process

7.8.6.1. The staff working on the process may not have the right skills, training and motivation to produce the desired results.

7.8.6.2. The resources made available to run the process may be insufficient to handle the volume of transactions received.

7.8.6.3. The process may not be managed appropriately.

7.9. Improving business processes (to-be business process)

7.9.1. Business rules

7.9.1.1. Constraints – these are the business rules that have to be applied and restrict how a process or task is performed.

7.9.1.2. Operational guidance – these are the business rules that determine how procedures are conducted within the organisation.

7.9.2. Simplify the process

7.9.2.1. Simplifying a process can be achieved by eliminating unnecessary tasks or hand-offs.

7.9.2.2. The process was first introduced but as a result of changes to the business have now become redundant.

7.9.3. Extend the processing

7.9.3.1. The process may be improved by adding extra tasks to the process, or further steps to a task.

7.9.4. Remove bottlenecks

7.9.4.1. Bottlenecks result when there is a mismatch in the capacities of related tasks.

7.9.5. Change the sequence of tasks

7.9.5.1. ‘As is’ business processes often reveal their origins.

7.9.5.2. Example is the use of computer systems to automate the flow through a process, removing the need for human intervention.

7.9.6. Redefine process boundary

7.9.6.1. The boundary of an ‘as is’ process may be redefined in order to improve the process.

7.9.7. Automate the processing

7.9.7.1. Automation means using computer software to perform tasks rather than carrying them out manually

7.9.7.2. There is a range of automated solutions that are relevant to process improvement initiatives:

7.9.7.2.1. Bespoke IT development.

7.9.7.2.2. Packaged applications.

7.9.7.2.3. Workflow management systems.

7.9.7.2.4. Straight through processing (STP).

7.9.8. Redesign the process

7.9.8.1. The approach could be described as the incremental improvement of an existing process. Hence the sequential steps:

7.9.8.1.1. develop the ‘as is’ model;

7.9.8.1.2. analyse the ‘as is’ process and define its problems;

7.9.8.1.3. identify potential improvements;

7.9.8.1.4. document the ‘to be’ process model.

7.9.8.2. There are some situations, however, where we cannot adopt this approach.

7.9.8.3. we will be able to model the new ‘to be’ process as a black box, defining:

7.9.8.3.1. the expected outcomes from the process;

7.9.8.3.2. the events or triggers that the process will need to react to.

7.9.9. Process Measurement

7.9.9.1. When we are designing an improved business process, we must define not only what the process does but also how well that processing is to be carried out.

7.9.9.2. The importance of measurement is illustrated by the oft-quoted statement ‘You can only manage what you can measure.’

7.9.9.3. Internal measures

7.9.9.3.1. Internal measures are often derived from organisational objectives, critical success factors and key performance indicators.

7.9.9.3.2. These measures are usually defined at an organisational level, cascaded down to departmental level and then further to the operational level.

7.9.9.3.3. The operational measures should support the higher-level measures, right up to the organisational level.

7.9.9.4. External measures

7.9.9.4.1. The other aspect to performance measurement is concerned with what the customer expects to have delivered.

7.9.9.4.2. There are three major areas to think about:

7.9.9.5. Process and task measures

7.9.9.5.1. The performance targets set for a particular process have to align with the expectations of the customers.

7.9.9.5.2. Estimating the timeline for a process is difficult. It will depend on a range of factors including:

7.9.9.6. Performance issues

7.9.9.6.1. Measures and targets need to be chosen with care especially when managers are given incentives to achieve those targets.

7.9.9.6.2. Targets will change the way that people behave – that is what they are designed to do.

7.9.9.6.3. It is possible that the behaviour could be inappropriate if we have not thought the implications of the targets.

8. Defining the Solution

8.1. Gap analysis

8.1.1. Gap analysis requires the business analyst to explore the differences between a current state and a desired future state.

8.1.2. A Business Activity Model (BAM) provides a conceptual overview of a desired future business system, showing ‘what’ activities would be needed to fulfil a stakeholder perspective.

8.1.3. At a more specific level, gap analysis may be used to examine any of the following areas:

8.1.3.1. the ‘as is’ and ‘to be’ business process models;

8.1.3.2. the competencies held by an individual and those required for a particular role;

8.1.3.3. the IT system requirements and the features offered by an off-the-shelf software package.

8.1.4. Identifying areas of concern

8.1.4.1. The activities on the BAM should be inspected and categorised in order to identify those requiring further attention.

8.1.4.2. Three categories may be used for the activities:

8.1.4.2.1. operating satisfactorily – no immediate action;

8.1.4.2.2. some issues to be addressed – action required;

8.1.4.2.3. not in place – urgent consideration.

8.1.5. Framework for gap analysis (elements of POPIT model)

8.1.5.1. The initial investigation focuses on modelling the processes or defining the requirements but this can lead to the change proposals being limited or failing to address the real problems. The holistic approach adopted by business analysts helps to avoid such issues.

8.1.5.2. The POPIT model can help considerably with this investigation as it provides a framework and aide-memoire that helps ensure that the analysis considers all of the required elements.

8.1.5.2.1. Processes

8.1.5.2.2. Information and technology

8.1.5.2.3. Organisation

8.1.5.2.4. People

8.1.6. Formulating options

8.2. Introduction to Business Architecture

8.2.1. Any proposed business change must align with the business architecture.

8.2.2. The business architecture helps to provide increased visibility and effectiveness.

8.3. Definition of Business Architecture

8.3.1. A blueprint of the enterprise that provides a common understanding of the organisation that can be used to align strategic objectives and tactical demands.

8.3.2. A robust business architecture results in the following:

8.3.2.1. the strategy drives changes to the business architecture;

8.3.2.2. the business architecture informs and refines the strategy;

8.3.2.3. the business architecture translates the strategy for execution;

8.3.2.4. the strategy execution enables and generates improvement to the overall business architecture.

8.3.3. A business architecture has three primary objectives:

8.3.3.1. To promote organisational health

8.3.3.2. To help fulfil unrealised opportunities

8.3.3.3. To aid organisational performance in a competitive market place

8.3.4. In addition, it is worth keeping in mind the following key points about a business architecture:

8.3.4.1. The scope of a business architecture is the scope of the business.

8.3.4.2. A business architecture is not prescriptive.

8.3.4.3. A business architecture is developed iteratively.

8.3.4.4. A business architecture is reusable across business units and businesses.

8.3.4.5. A business architecture is not about the deliverables.

8.4. Structure of a business architecture

8.4.1. For example, the artefacts of a business architecture might document any of the following:

8.4.1.1. capabilities;

8.4.1.2. values;

8.4.1.3. information;

8.4.1.4. products;

8.4.1.5. suppliers and partners;

8.4.1.6. motivations;

8.4.1.7. business units;

8.4.1.8. policies.

8.4.2. Evolving best practice has shown that the key elements of a business architecture represent the following areas:

8.4.2.1. business motivations;

8.4.2.2. business capabilities;

8.4.2.3. value streams

8.4.2.4. organisational business units;

8.4.2.5. information concepts.

8.5. Business Architecture techniques

8.5.1. Definition of a capability model

8.5.1.1. Capability models represent, at a high level, what the organisation needs to be able to do in order to deliver value to customers.

8.5.1.2. A full business capability model usually investigates and models the whole organisation across a number of business strata (layers).

8.5.1.3. The main strata (layers) found on a typical business capability model would be:

8.5.1.3.1. strategic or direction setting;

8.5.1.3.2. core or customer facing;

8.5.1.3.3. supporting.

8.5.1.4. It should be noted that the following rules apply when producing a business capability model:

8.5.1.4.1. capabilities should be defined in business terms;

8.5.1.4.2. capabilities should be named as nouns not verbs;

8.5.1.4.3. capabilities are static (value streams show movement);

8.5.1.4.4. capabilities should be unique across the entire capability model;

8.5.1.4.5. capabilities are enabled via value streams.

8.5.1.5. Organisations that document and maintain business capabilities can change more quickly and effectively than those that do not.

8.5.2. Definition of a value stream

8.5.2.1. Value streams are used to identify, map and analyse the value exchanged between an organisation and various stakeholders (internal and external) that interact with it.

8.5.2.2. They focus on the delivery of value and may not reflect the way the work is done in practice.

8.5.2.3. The value stream shows the main sequential stages which add value to the customer. It should be noted that the value stream considers all the stages needed.

8.5.2.4. It is common for each of the individual stages within a value stream, such as the one shown here, to be enabled by a number of organisational capabilities identified from the previously defined Business Capability Model.

8.5.2.5. When producing a value stream, it is worth noting some key guiding principles. Value streams should:

8.5.2.5.1. be stakeholder focused;

8.5.2.5.2. take a holistic view;

8.5.2.5.3. be customer centric;

8.5.2.5.4. facilitate further decomposition;

8.5.2.5.5. help identify which business capabilities help achieve stakeholder value.

9. Documenting and Managing Requirements

9.1. The requirements document

9.1.1. Structure

9.1.2. Content of the requirements document

9.2. The requirements catalogue

9.2.1. Types of requirements; general, technical, functional and non-functional

9.2.2. Hierarchy of requirements

9.2.3. Documenting a requirement

9.3. Managing requirements

9.3.1. Elements of requirements management

10. Modelling Requirements

10.1. Modelling system functions

10.1.1. Use case diagrams

10.2. Modelling system data

10.2.1. Entity Relationship Diagrams

10.2.1.1. Entities, attributes and relationships

10.2.1.2. Types of relationships

10.2.2. Class Models

10.2.2.1. Objects and classes

10.2.2.2. Attributes

10.2.2.3. Associations

11. Delivering the Requirements

11.1. Delivering the solution

11.2. Context

11.2.1. The context for the organisation and the project will provide the basis for deciding how any business changes are to be delivered.

11.2.2. The key factors to take into account are as follows:

11.2.2.1. The culture and underlying philosophy of the organisation

11.2.2.2. The business context for the proposed changes

11.2.2.3. Any constraints that impinge upon the project

11.2.2.4. The prioritised needs of the business

11.2.2.5. The drivers for the project

11.3. Lifecycles

11.3.1. The waterfall lifecycle

11.3.2. The ‘V’ model lifecycle

11.3.3. Incremental lifecycle

11.3.4. Iterative systems development lifecycle

12. Delivering the Business Solution

12.1. BA role in the business change lifecycle

12.2. Design stage

12.2.1. Information and Technology

12.2.1.1. Development

12.2.1.2. Testing

12.2.1.3. Design

12.3. Implementation stage

12.3.1. SARAH model

12.4. Realisation stage

12.4.1. Contents of the benefits plan

13. Making a Business and Financial Case

13.1. The business case in the project lifecycle

13.2. Identifying options

13.3. Assessing project feasibility

13.3.1. There are many issues to think about in assessing feasibility but all fall under the three broad headings

13.3.1.1. Business feasibility

13.3.1.1.1. The proposal matches the business objectives and strategy of the organisation and – if it is a commercial firm – if it can be achieved in the current market conditions.

13.3.1.2. Technical feasibility

13.3.1.2.1. The proposed solution must meet the organisation’s demands in terms of system performance, availability, reliability, maintainability and security.

13.3.1.3. Financial feasibility

13.3.1.3.1. The organisation can afford the proposed solution. There may already be a budget imposed. The organisation needs either to have the required funds available or to be in a position to borrow them.

13.3.2. PESTLE analysis can be used in assessing feasibility to examine the environment outside an organisation. It can be used to assess feasibility like this:

13.3.2.1. Political: Is the proposed solution politically acceptable?

13.3.2.2. Economic: Can the organisation afford the solution?

13.3.2.3. Socio-cultural: Does the solution fit with the organisation’s culture?

13.3.2.4. Technological: Can the solution be achieved, technically?

13.3.2.5. Legal: Is it legal, will the regulator allow it?

13.3.2.6. Environmental: Does it raise any ‘green’ environmental issues?

13.3.3. A final tool that can be employed to assess the feasibility of an option is a ‘force-field analysis’.

13.3.3.1. We consider those forces inside and outside the organisation that will support adoption of the proposal and those that will oppose it.

13.3.3.2. We need to be sure that the positive forces outweigh the negative.

13.3.3.3. The forces may include the PESTLE factors mentioned above and also the key stakeholders in the organisation.

13.3.3.4. If we conclude that the negative forces are just too strong, then the proposal is not feasible and must be abandoned or re-cast in a way that gets more positive forces behind it.

13.3.4. In considering the feasibility of options, we also need to think about their impacts and risks.

13.4. Structure of a business case

13.4.1. Contents of a business case

13.4.2. Categories of costs and benefits

13.4.3. Impact assessment

13.4.4. Risk assessment

13.5. Investment appraisal

13.5.1. Payback

13.5.1.1. Payback calculations have the virtue of being easy to understand and relatively easy to construct.

13.5.1.2. Where interest rates and inflation are low they provide a reasonable forecast of what will happen.

13.5.1.3. However, they do not take account of what accountants call the ‘time value of money’.

13.5.2. Discounted cash flow (DCF) or ‘net present value’ (NPV)

13.5.2.1. A method that takes account of the time value of money is known as discounted cash flow (DCF) which leads to a ‘net present value’ (NPV) for the project.

13.5.2.2. This means that all of the cash-flows in years after Year 0 are adjusted to today’s value of money.

13.5.2.3. Management accountants work out the ‘discount rate’ to use in a discounted cash flow calculation by studying a number of factors including the likely movement of money-market interest rates in the next few years.

13.5.3. Internal rate of return

13.5.3.1. This is a calculation that assesses what sort of return on investment is represented by the project in terms of a single percentage figure.

13.5.3.2. This can then be used to compare projects one with another to see which are the better investment opportunities, and to compare them all with what the same money could earn if just left in the bank.

13.5.3.3. So, for example, if the IRR of a project is calculated at three per cent and current bank interest rates are five per cent, then on financial grounds alone it would be better not to spend the money.

13.5.3.4. IRR is worked out by standing the DCF/NPV calculations on their head. The question we are asking is, what discount rate would we have to use to get a net present value of zero after five years (or whatever period the organisation mandates should be used for the calculation)?

13.5.3.5. In other words, at what point would financial costs and benefits precisely balance each other? For example, trying different discount rates until an NPV of zero is produced.

14. Establishing the Requirements

14.1. A framework for requirements engineering

14.1.1. The requirements engineering encapsulates a more disciplined and rigorous approach to requirements definition.

14.1.2. The business analyst should follow a roadmap that guides them through the key steps required to develop a well-defined requirements document.

14.1.3. Requirements elicitation is concerned with drawing out information and requirements from the business stakeholders, using a toolkit of techniques to undertake requirements elicitation effectively.

14.1.4. Requirements analysis stage focuses on examining and organising the elicited requirements and the business analyst verify carefully to ensure that initial requirements are well formed "SMART".

14.1.5. Once the set of unique requirements have been identified, it is important to check them against the business objectives.

14.1.6. The business analyst has a gatekeeper role, ensuring only those requirements that pass the scrutiny will be entered in the document.

14.1.7. This iterative process continues until the analyst is content that the requirements have been defined to the desired level of detail and quality.

14.1.8. Requirements validation involves the external stakeholders reviewing the requirements in order to agree and sign off the requirements document.

14.1.9. Requirements documentation is concerned with the development of a well-organised requirements document.

14.1.10. Requirements management covers the activities needed to manage any changes to the requirements.

14.2. Actors in requirements engineering

14.2.1. The business representatives

14.2.2. The project team

14.3. Requirements elicitation

14.3.1. Tacit and explicit knowledge

14.3.2. Requirements elicitation techniques

14.4. Requirements analysis

14.4.1. Requirements filters

14.4.2. SMART requirements

14.5. Requirements validation

15. Bibliographic reference

15.1. Book: Business Analysis, Third edition

15.2. Editors: Debra Paul, James Cadle and Donald Yeates

15.3. Published by BCS Learning & Development Ltd