Slide Bundle - Business Analysis 2024-2025 PDF

Slide Bundle D0I68A – D0I81A Business Analysis / Business Analyse Prof. Dr. Jochen De Weerdt 2024 - 2025  Part I Business Analysis (BA)  BA1. Introduction to Business Analysis Prof. Dr. Jochen De Weerdt Lecture ove...

Slide Bundle D0I68A – D0I81A Business Analysis / Business Analyse Prof. Dr. Jochen De Weerdt 2024 - 2025  Part I Business Analysis (BA)  BA1. Introduction to Business Analysis Prof. Dr. Jochen De Weerdt Lecture overview 1. What is Business Analysis? 2. Role of a Business Analyst 3. Competencies of a Business Analyst 4. BA Planning and Monitoring 5. Stakeholder Engagement 6. Conclusion 2 Supporting lecture material Milani, F., (2019) Digital Business Analysis. Springer. Chapter 1 Chapter 6 Chapter 7 3 1. What is Business Analysis? 4 What is Business Analysis? “Business analysis is the practice of enabling change in an enterprise by defining needs and recommending solutions that deliver value to stakeholders” 5 What is Business Analysis? “Business analysis is the practice of enabling change in an enterprise by defining needs and recommending solutions that deliver value to stakeholders” 6 Proliferation of IT systems (80s) IBM AS/400 System Model 10 http://cdn.ttgtmedia.com/rms/computerweekly/photogalleries/236963/1351_20_ibm-as-400-system-model-10-computer-fashions-of-the-1980s.jpg 7 Project success https://www.infoq.com/articles/standish-chaos-2015 8 From business need to solution 9 BACCM 10 Field of practice - IIBA 11 BABOK (Business Analysis Body of Knowledge) A collection of concepts, activities, deliverables, competences, principles etc. that is considered as standard within a profession Identifies currently accepted practices Recognizes business analysis is not synonymous with software requirements Defined and enhanced by professionals who apply it Captures the sum of the knowledge required for the practice of business analysis as a profession BABOK is not a methodology, nor does it prescribe or favor a methodology It is not a “How to” business analysis instruction manual 12 BABOK Knowledge Areas 13 2. Role of a Business Analyst 14 What is a Business Analyst? According to the International Institute of Business Analysis (IIBA), a business analyst works as a liaison among stakeholders in order to elicit, analyze, communicate, and validate requirements for changes to business processes, policies, and information systems. The most important element is the business focus; ensuring business needs are understood and communicated so that the final solution meets the business needs. Solutions may be IT related, non-IT related, or could be process improvement. The business analyst is responsible for eliciting the actual needs of stakeholders, not simply their expressed desires and often play a central role in aligning the needs of business units with the capabilities delivered by information technology. 15 What is a Business Analyst? A variety of roles are covered by this definition. Some examples of different types and titles include: Business analysts with very strong business skills and understanding of the business domain whose key role is to analyze business processes, procedures, etc. in order to identify problems and determine solutions. These analysts are more involved in what the IIBA defines as enterprise analysis and are likely to be involved prior to the initiation of an IT project. IT business analyst who is focused on requirements elicitation and analysis, and solving problems using information technology solutions. This analyst serves as a bridge between business and IT and generally begins work after a project has been initiated. This analyst specifies “what” the system must do. Systems analyst is an IT business analyst who is more focused on system design and the technical aspects of the solution. This analyst takes the requirements and creates functional specifications regarding “how” a system will do the “what.” Many other titles are used including the business systems analyst which has been described as a combination of the IT business analyst and the systems analyst. 16 Role of an Analyst – Problem Solver 17 Role of a Facilitator Positive, continuous discussion and progress 18 Role of a Negotiator Mediates between clients, stakeholders, and other involved parties 19 Role of an Architect Solutions that include systems development process improvement organizational change models business processes designs and so on 20 Role of a Planner Accurately identified, captured, and tracked throughout the project life cycle; define, organize, schedule etc. 21 Role of a Communicator Use discussion, conversations, and interviews to further understanding and communicate with others 22 Role of an Expert Know your business, industry and domain 23 Role of a Strategist Long-term, vision, goals, tactical plans 24 Summary Problem Solver Facilitator Negotiator What competencies Architect are needed? Planner Communicator Expert Strategist 25 3. Competencies of a Business Analyst 26 What is a Competency? A competency is the capability to apply or use a set of related knowledge, skills, and abilities required to successfully perform "critical work functions" or tasks in a defined work setting. 27 Main Areas of Competence Business Knowledge Analytical Thinking Organizing and Time Management Communication and Interaction Tools and Techniques 28 Business Knowledge External Business Knowledge: Business Acumen Industry Knowledge Information Technology Internal Business Knowledge: Business Model and Strategies Organizational Knowledge 29 Analytical Thinking Discovering Synthesizing Conceptual Thinking Deliver solutions that Analyzing Decision Making bring business value Identifying Evaluating 30 Organization and Time Management Organizing … different types of meetings manage complex plans manage frequent changes 31 Communication and Interaction While being neutral, facilitate … Agreements, Discussions, Collaboration, Meetings, Workshops, Eliciting facts, Perspectives 32 Tools & Techniques 33 In this course, strong focus on BPM 34 4. BA Planning and Monitoring 35 Knowledge areas 36 Knowledge Areas and Tasks 37 BA Planning Parameters Objective What is the outcome of the business analysis work? What is to be delivered? Needs What is the perceived problem, need, or opportunity that is to be investigated? Scope What is the scope of the project? Approach What is the main approach (predictive versus adaptive) to be taken? Activities How is the outcome to be achieved (activities, planning, timing, methods, tools etc.) Complexity & Risk Of what level of complexity is the project? What is the risks of the project? Approval Gain approval and secure resources required to do the work. 38 Further Knowledge Areas and Tasks 39 Elicitation Focus on gathering requirements from various stakeholder groups Identify the tasks, knowledge and techniques for capturing requirements “What do the Stakeholders need?” 40 Elicitation Techniques Brainstorming Focus Groups Interviewing Observation Prototyping Requirements Workshop Survey/Questionnaire Document Analysis Interface Analysis 41 Requirements Management and Communications Focus on presenting and communicating documented requirements to all stakeholders, including project team members, to bring the group to consensus on project scope. Identify and manage change “Does everyone understand and agree?” 42 Enterprise Analysis Understanding the “big picture” Define business goals the solution must meet Integrate requirements into larger business architecture Support initiatives and long-term planning Strategic planning, business case development, Cost Benefit Analysis, feasibility studies “Why are we doing this?” 43 Requirements Analysis Focuses on analyzing the data Defines the methods, tools, techniques to structure raw data collected during elicitation Identifies gaps in requirements Defines the “solution” capabilities and can serve as the foundation for selecting among solution alternatives. “What must the solution do?” 44 % of Requirements Activities Hickey and Davis, 2004, A unified model of requirements elicitation 45 Solutions Assessment &Validation Focus on ensuring the best approach is chosen, that the solution will meet stakeholder objectives, that the solution is feasible, and guides solution “verification.” “Does the solution do what it is supposed to do?” 46 5. Stakeholder Engagement 47 Stakeholders Definition: a person or group with a relationship to the change or solution. The most general version of this idea is "relevant people". BAs usually shouldn't focus on people with no relationship to the solution or the change, as they are usually not relevant. But what makes a person relevant to a change or to a solution? What turns a person into a stakeholder? A person is a stakeholder if a change or solution causes them to experience a change in value, or if they can affect value experienced by a stakeholder. Experiencing a change in value doesn't mean that you're a change agent, or directly involved in a controlled transformation of organizational systems. For example, consider a project that is going to move staff to a new office. The families of the people being moved are stakeholders, not because they are part of the change, but because they affect the value change experienced by the employees. Stakeholders are part of the system, and are valuable sources of information to the Business Analysis 48 Importance of stakeholder engagement … for a healthy and productive collaboration and ensuring a movement forward in the analysis process ✓ Efficient Communication Strategy (rally support rather than fighting resistance) ✓ Better Stakeholder Satisfaction (increased participation) ✓ Limiting Scope Creep (increased clarity reduce conflict) 49 What we want to know Attitude Contribution Who are the What are their interests How do we best mange stakeholders? in the project? the communication What are their attitudes What are their What is their with the stakeholders? towards the project? particular expectations involvement and or requirements? potential contribution? Identify Expectations Communication 50 Stakeholder Engagement Manage Stakeholders Analyze Stakeholders Identify Stakeholders 51 Who are Stakeholders? 52 Who are Stakeholders? 53 Who are Stakeholders? 1 Business Analyst By definition, the business analyst is a stakeholder in all business analysis activities. The BABOK®Guide is written with the presumption that the business analysis is responsible and accountable for the execution of these activities. In some cases, the business analyst may also be responsible for the performance of activities that fall under another stakeholder role. 2 Customers A customer is a stakeholder outside the boundary of a given organization or organizational unit. Customers make use of products or services produced by the organization and may have contractual or moral rights that the organization is obliged to meet. 3 Domain Subject Matter Expert (SME) A domain subject matter expert is any individual with in-depth knowledge of a topic relevant to the business need or solution scope. This role is often filled by people who will also be end users or people who will be indirect users of the solution, such as managers, process owners, legal staff (who may act as proxies for Regulators), consultants, and others. 54 Who are Stakeholders? 4 End User End users are stakeholders who will directly interact with the solution. The term is most frequently used in a software development context, where end users are those who will actually use the software application that is being developed, but in the broader context of a solution they can include all participants in a business process. 5 Implementation Subject Matter Expert (SME) Developers/Software Engineers Organizational Change Management Professionals System Architects Trainers Usability Professionals 6 Project Manager Project managers are responsible for managing the work required to deliver a solution that meets a business need, and for ensuring that the project’s objectives are met while balancing the project constraints, including scope, budget, schedule, resources, quality, risk, and others. 55 Who are Stakeholders? 7 Tester Testers are responsible for determining how to verify that the solution meets the solution requirements defined by the business analyst, as well as conducting the verification process. Testers also seek to ensure that the solution meets applicable quality standards and that the risk of defects of failures is understood and minimized. 8 Regulator Regulators are responsible for the definition and enforcement of standards. Standards may be those that the team developing the solution is required to follow, standards the solution must meet, or both. Regulators may enforce legislation, corporate governance standards, audit standards, or standards defined by organizational centers of competency. 9 Sponsor Sponsors are responsible for initiating the effort to define a business need and develop a solution that meets that need. They authorize work to be performed and control the budget for the initiative. 10 Supplier A supplier is a stakeholder outside the boundary of a given organization or organizational unit. Suppliers provide products or services to the organization and may have contractual or moral rights and obligations that must be considered. 56 Stakeholder Analysis Stakeholder matrix Based on Power of influence Interest in the improvement initiative 57 Stakeholder Analysis Stakeholder Influence Impact Stakeholder Management Keep and ensure that the stakeholder Keep Satisfied High Low remains satisfied Work very closely to ensure that they Key Players High High are in agreement about the changes Keep an eye on the stakeholders’ Monitor Low Low interests or influence in case of changes Ensure a good flow of information to Keep Informed Low High keep them informed. 58 Onion Diagram Affected External Stakeholders Enterprise Stakeholders Affected Organizational Units Solution Delivery 59 RACI Matrix Responsible (R), Accountable (A), Consulted (C), Informed (I) Sometimes RASCI with S for Support 60 RACI Matrix Deliverable/Phase/Activity R: Responsible A: Accountable C: Consulted I: Informed Business Subject Matter Current State Analysis Sponsor Team Analyst Expert Project Subject Matter Project Plan Sponsor Team Manager Expert Project Subject Matter Business Manager/ Project Requirements Analysis Expert/ Analyst Business Manager Business Users Analyst 61 Stakeholder Management Managing Stakeholders is about communication (plan) Why – reason for communicating keeping the stakeholder satisfied, to keep them supporting the initiative, to keep them updated for their upcoming increases involvement or is to keep an important decision maker in the loop so to facilitate the decisions that must be taken? What – information to communicate Different stakeholders will be interested in different kinds of information. When – frequency from a scale starting from daily/weekly to quarterly reports How – ways of communicating from sending emails and status update meetings to personal meeting 62 Communication Plan Stakeholder Why What When How CIO Sponsor Progress, Weekly Status Meetings Solutions, Challenges, Requirements, Budget Project Manager Will take over Progress, Monthly (weekly) Project Meetings delivery solutions, requirements Legal Verify Legal aspects On needs basis Meetings Old CRM Maintenance Migration Weekly Project Meetings Developer Informed Solution, Monthly Progress Requirements Meetings Advisors Verify Solutions On needs basis Meetings/Worksh ops End Users Requirements Solutions, Weekly Dedicated Requirements workshops Customers Informed Relevant updates On needs basis Email 63 6. Conclusion 64 Conclusion Business Analysis is a broad domain focused on identifying and developing solutions within organizations for particular needs or changes that can drive business value Business Analysts are typically generalists carrying out different roles in a project typically with a varied skill set A key success factor for BA projects is proper stakeholder management, focusing on analysis, management and communication 65 What should you know and what should you be able to do? You should know: what business analysis is about what the role is of a business analyst what the usual competencies are of a business analyst what the key concepts and stages are in the planning and monitoring of a business analysis project what typical stakeholders are, and which approaches exist to analyze and manage them 66  BA2. Context Analysis Prof. Dr. Jochen De Weerdt Lecture overview 1. Business Strategy 2. External Context Analysis 3. Internal Context Analysis 4. Strategy Execution 5. Link to Enterprise Architecture (EA) 6. Conclusion 2 Supporting lecture material Milani, F., (2019) Digital Business Analysis. Springer. Chapter 2 Chapter 3 3 Where are we? BABOK Knowledge Areas 4 Strategy Analysis 5 1. Business Strategy 6 What is strategy? An integrated set of actions aimed at increasing the long-term wellbeing and strength of an enterprise (Porter, 1980) The determination of the basic long-term goals of an enterprise, and the adoption of courses of action and the allocation of resources necessary for carrying out these goals (Chandler, 1962) The long-term direction of an organisation (Johnson et al., 2017) 7 What is strategy? Harry Mintzberg (2000) Plan Ploy Pattern Position Perspective 8 Importance of strategy Foundation for success through aligning execution with the context of the internal and external environment Key considerations Global competition Increased complexity Continually changing customer expectations Technology 9 Why a concern for business analysis? Benefits from being aware of and being capable to apply knowledge of the strategic context Analyse and discuss strategic opportunities Build credibility when discussing the organization with stakeholders Question appropriateness and alignment of decisions taken prior to and during a change initiative Provide leadership and influence for the delivery of strategically aligned change Working without reference to the strategic context reduces the value of business analysis services 10 Understanding strategic context What is the organisation’s “current state”? What is the organisation’s desired “target state”? What is the plan to move between the current state and target state? Aka strategic mission or roadmap Performance measurement Current state Target State Strategy Execution 11 Performance SWOT measurement Current state Target State Strategy Execution Strengths Opportunities Weaknesses Threats Internal context External context analysis analysis - VMOST - PESTLE - Resource audit - Porters Five Forces - BSC - Growth share matrix 12 2. External Context Analysis 13 External context analysis External perspective Economic growth Monetary policy Regulations Technological trends Focused on opportunities and threats Two main methodologies/techniques PESTLE analysis Porter’s Five Forces model 14 PESTLE analysis 15 16 Add in an extra E: PESTLEE - STEEPLE E for Ethical Think of GDPR, AI regulatory initiatives, etc. Core technique for assessing wider macro environment within which an organisation operates 17 Porter’s Five Forces model 18 Blue Ocean Porter’s model not always great in case of “disruptive” change, especially in technological or technology-driven environments 19 3. Internal Context Analysis 20 Internal context analysis Internal perspective Organizational strategy Business model Capabilities Organizational culture and structure Focused on strengths and weaknesses (instead of opportunities and threats) Techniques: VMOST, Resource audit, BSC, Boston Box 21 1) VMOST Vision: defines the target state for the organisation Mission: Describes what the organisation does or will do Objectives: The specific objectives or outcomes that the organisation wants to achieve Strategy: The long-term approach that is taken by the organisation to achieve the vision, mission, and objectives Tactics: The specific and detailed means by which the strategy should be executed. Tactics are often adapted when feedback regarding success of the strategy is received. 22 VMOST implementation – key questions Does a VMOST for the organisation exist? Are the elements of the VMOST clearly defined? Is the VMOST communicated and understood within the organisation? Are the vision and mission aligned? Are the objectives SMART (Specific, Measurable, Achievable, Relevant, Time-bound)? Are the objectives balanced? Do the tactics align to the strategy? 23 2) Resource audit Identify strengths and weaknesses per resource type Can be applied to sub-units (e.g. department, team) 24 3) Balanced Scorecard (BSC) Kaplan, Robert S., and David P. Norton. "The balanced scorecard: measures that drive performance." Harvard Business Review 83.7 (2005): 172. 25 4) Growth share matrix BCG matrix – Boston Box Categorize products along two dimensions Identify strengths and weaknesses from the product portfolio 26 4. Strategy Execution 27 Developing and executing strategy Starting from the results of internal and external context analysis Analysis of the gap between current en desired target state Key techniques 1) Business Model Canvas (BMC) 2) Business Capability Model (BCM) 28 1) Business Model Canvas A business model describes the rationale of how an organisation creates, manages and delivers business value 29 A. Customer Segments & Value Propositions Who are the organization’s important customers? For whom is value proposed? Value Proposition Canvas Customer jobs Customer pains Customer gains Value Proposition Canvas 30 Customer Jobs Jobs describe the things your customers are trying to get done in their work or life. Functional Jobs Performing or completing specific tasks or solving specific problems (track time, write report, clean the apartment) Social Jobs Refer to times when the customer wants to look ‘good’ or gain social value or reputation. These jobs are about how the customer wants to be perceived by others. Emotional Jobs Refer to times when the customers aim at achieving a certain emotional state or feeling 31 Customer Pains Customer Pains is anything that causes the customer be become annoyed before, during or after getting a job done, or prevents them from getting the job done. Undesired Outcomes and Problems: Things that does not work Things that does not work well Things that have negative side effects Things that cause bad feeling (look bad, bored) 32 Customer Gains Customer Gains are when the customer is getting the outcome or benefits they want. Required gains – basic expectation such as calling with smartphone. Expected gains – basic gains that are expected such as good design from Apple Desired gains – usually gains that customers would say if asked Unexpected gains – go beyond expectation 33 Products and services A list of what you offer – as display of what the customer can see. Physical such as goods and products Intangible such as IP Digital such as music Financial such as investment funds What is it that your product features do? 34 Pain relievers Describes how exactly your product or service alleviate specific customer pains. Produce savings? Feel better? Fix bad solutions? … Not all pains are equally relevant to relieve. 35 Gain creators Describes how the product or the service create gains for the customer. Happy customers? Outperform existing solutions? Makes job or life easier? Bring positive consequences? Remember, not all gains are equally relevant, focus on the essential gains. 36 Customers in a Market 37 Market Segmentation 38 Market Segmentation Market segmentation is the dividing a market into different clusters of customers. In each segment, customers are different between segments but similar within. 39 Example of Customer Archetype (Personas) Example from http://www.slideshare.net/sblank/2-8-element-foodday-5-final 40 Product Market Fit Fit is when your value proposition matches the customers needs. 41 How can value be produced? Newness – New set of needs not previously perceived (cell phones, ethical funds) Performance – Improving product or service performance (PCs) Customization – Targeting specific needs of individual customers or segments Getting the job done – helping with getting certain jobs done (Rolls-Royce Jet Engines) Design – stand out because of better design (fashion and consumer electronics) Brand/status – value through brand/status (Rolex) Price – Offering lower price (Ryanair) Cost reduction– Help reducing costs (Salesforce.com) Risk reduction– reducing risk when buying something (service guarantee) Accessibility– Making products or services available to customers who lacked access (Mutual funds, online trading) Convenience/usability– simplify usage of something 42 B. Channels & Customer Relationships Customer journey mapping Channel Describes how a company communicates with and reaches its customer segments to deliver its value proposition. 43 The Funnel – Physical Products From Steve Blank slides found at http://www.slideshare.net/sblank/delft-climate-kic-070212-part-2 44 Virtual Products 45 Types of Customer Relationships Personal Assistance – based on human interaction Dedicated Personal Assistance – Dedicated representative to an individual client Self-Service – no direct contact but help themselves Automated Services – mix of self-service and automated processes Communities – user community where users help each other, and companies understand their customers better. Co-Creation – co-create value with customer 46 C. Key Resources & Key Activities Describes the most important Describes the most important assets (resources) required to things a company must do to make a business model work. make its business model work. Physical Production IP Platform/Network Human Financial Problem Solving 47 D. Cost structure and revenue streams Profit = Revenues – Costs 48 Types of Revenue Streams? Sales Usage fee Subscription fee Renting/licensing fee Brokerage fee Advertising fee 49 2) Business Capability Model (BCM) A capability an abstract collection of resources, processes, and technologies that together in whatever combination, enables an organization to achieve a desired outcome. A capability … describes “what” an organization does (unique and independent from each other) … is long lasting (the “how” will change but not the “what”) … no duplication 50 Generic Capability Map 51 Example capability map (Insurance company) 52 Levels of Capabilities Direct Lead Marketing Management Management Marketing Contact Execution Management Channel Management 53 Modeling a Capability Performance Gap Impact Value High Medium Low High Medium Low Lead Management Risk High Medium Low 54 Value of Capability Analysis Awareness of Capabilities that initiatives are to support Alignment of business initiatives with strategic goals and directions Identify where (needs) to strengthen a capability Build upon strengths for new initiatives Identify gaps and development needs (more on this later) 55 Word of Caution Capability Analysis usually done at high level of management, not the typical business analyst work The point is to be aware, understand, and use capabilities to make better solutions Do not focus on all capabilities, only the relevant ones for the initiative Unless there is value in having a capability analysis, do not do it 56 5. Link to Enterprise Architecture (EA) 57 Enterprise Architecture Every organization has an EA Enterprise Architecture Business architecture An EA represents the core building blocks of the Compliance organisation and Security Application Data demonstrates how it is architecture architecture organized EA domains Infrastructure architecture 58 Business architecture “A blueprint of the enterprise that provides a common understanding of the organisation and is used to align strategic objectives and tactical demands” Areas Business motivation and strategy Organisation structure and design Operating model Organisational structure Value propositions for products and services Processes Capabilities Information 59 Application architecture Portfolio of business applications Alignment to “Business architecture” is crucial 60 Data architecture Describe all the data (objects) that are being held within the business Alignment to Business architecture Application architecture (Where is the data stored within my portfolio of applications?) 61 Infrastructure architecture Hardware, OS, networks, cloud, etc. 62 Compliance and security architecture Compliance Meet and manage internal and external compliance expectations Security Protect assets from harm, loss, and danger 63 Main frameworks for EA TOGAF (The Open Group Architectural Framework) Zachman Framework Federal Enterprise Architecture Gartner Methodology 64 6. Conclusion 65 Conclusion We scrutinized some frameworks for External context analysis Internal context analysis Strategy execution Link to EA Business analysts’ concern? Strategic awareness allows for improved BA service delivery Strategic alignment is a key success factor for many BA projects Especially important for senior business analysts 66 What should you know and what should you be able to do? You should know: why business strategy is an important knowledge area for business analysis what methods/techniques exist for analysing the external context what methods/techniques exist for analysing the internal context which frameworks are available to help with executing business strategy what the relevance is of enterprise architecture in all of this 67  BA3. Requirements Engineering Prof. Dr. Jochen De Weerdt Lecture overview 1. Requirements Definition and Types 2. Requirements Elicitation 3. Requirements Analysis 4. Requirements Validation 5. Requirements Documentation 6. Requirements Modelling 7. Requirements Management 8. Conclusion 2 Supporting lecture material Milani, F., (2019) Digital Business Analysis. Springer. Chapter 11 Chapter 13 Chapter 14 Chapter 15 Chapter 18 3 Where are we? BABOK Knowledge Areas 4 What do people want? 5 Requirements Analysis and Design Definition 6 1. Requirements Definition and Types 7 What is a Requirement? A requirement is (1) a condition or capability needed by a stakeholder to solve a problem or achieve an objective (2) a condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specification, or other formally imposed documents a documented representation of a condition or capability as in (1) or (2) In other words A requirement is a feature or characteristic that has been requested by a stakeholder and may form part of a solution 8 What is a requirement? As implied by this definition, a requirement may be unstated, implied by or derived from other requirements, or directly stated and managed One of the key objectives of business analysis is to ensure that requirements are visible to and understood by all stakeholders 9 Types of Requirements 10 Business Requirements Higher-level statements of the goals, objectives, or needs of the enterprise Describe the reasons why a change/project has been initiated, the objectives that the project will achieve, and the metrics that will be used to measure its success 11 Stakeholder Requirements Statements of the needs of a particular stakeholder or class of stakeholders Describe the needs that a given stakeholder has and how that stakeholder will interact with a solution Stakeholder requirements serve as a bridge between business requirements and the various classes of solution requirements 12 Solution Requirements Describe the characteristics of a solution that meet business requirements and stakeholder requirements Developed and defined through requirements analysis Frequently divided into two sub-categories, particularly when the requirements describe a software solution Functional Requirements Non-functional Requirements 13 Functional Requirements Describe the behavior and information that the solution will manage Describe capabilities the system will be able to perform in terms of behaviours or operations as well as specific information technology application actions or responses 14 Non-functional Requirements Capture conditions that do not directly relate to the behavior or functionality of the solution, but rather describe environmental conditions under which the solution must remain effective or qualities that the systems must have They are also known as quality or supplementary requirements These can include requirements related to capacity, speed, security, availability and the information architecture and presentation of the user interface 15 Transition Requirements Describe the capabilities that a solution must have an the conditions the solution must meet to facilitate transition from the current state to the future state, but which are not needed once the change is complete Temporary nature Examples Data migration and conversion Stakeholder communication and training Business continuity, release strategies, customer service 16 Overview 17 Requirements Engineering The RE framework clarifies the activities to be carried out when defining requirements Requirements should be unambiguous, well- structured, correct, and relevant 18 2. Requirements Elicitation 19 Requirements Elicitation First, foremost and crucial stage of the RE process Uncover, acquire and elaborate requirements Different sources Stakeholders Documentation Existing systems Different techniques Qualitative Quantitative 20 Qualitative Elicitation Techniques Gaining impressions and opinions Types: Collaborative Workshop Focus group One-to-one Interviews Meetings Observation Scenarios Prototyping and wireframes User role analysis/personas 21 Quantitative Elicitation Techniques Focused on volumes, frequencies, … Types: Surveys Questionnaires Document analysis 22 3. Requirements Analysis 23 Objective Identify requirements that overlap are in conflict with other requirements are duplicates need to be separated into individual requirements because they are composite or complex 24 Tasks Categorizing requirements Defining/accepting requirements Modelling requirements Prioritising requirements 25 Defining Requirements Examine elicited requirements, filter, and build a well-formed set Making sure requirements are clear, correct, and relevant Filters: Unravelling multiple requirements Check for overlapping or duplicate requirements Confirm relevance of the requirement Evaluate feasibility Remove conflicts Confirm quality of expression 26 Evaluating Feasibility Technical feasibility Business feasibility Financial feasibility 27 Quality of Expression Clear Concise Consistent Relevant Unambiguous Correct Testable Traceable 28 Prioritizing Requirements The number of requirements collected in a project can be huge, ranging from hundreds to several thousands The requirements represent what stakeholders expect from a solution The resources to build that solution are usually limited, so that it is hardly feasible to satisfy all the elicited requirements right away Solution: sort out the requirements according to their relative importance Different approaches to prioritization: MoSCoW Kano Model 29 MoSCoW Technique MoSCoW is a tool for helping priority discussion between stakeholders and business analysts The technique makes use of a nominal scale to sort the requirements MoSCoW is an extremely common technique for prioritization; reason is that it is extremely simple to use and explain, and applies accross various application domains MoSCoW stands for: Must have Should have Could have Would have (sometimes Won’t have) 30 Must Have Refers to requirements that the system must satisfy If a Must Have requirement is not satisfied, there is no way the solution can be delivered to stakeholders If at least one of the following conditions is true, then a requirement is a Must Have: Delivering the solution without the requirement makes no sense to the stakeholders (they find no utility) Delivering the solution without the requirement is illegal Delivering the solution without the requirement is unsafe (there is a danger for the stakeholder) 31 Should Have Is different from the Must Have in that it is not absolutely necessary to satisfy the requirement The requirement being unsatisfied will cause the stakeholder to be unsatisfied about the solution If at least one of the following conditions is true, then a requirement is a Should Have: The requirement is important but not essential It can be harmful to deliver the solution without the requirement, but the solution remains relevant The solution cannot work without the requirement, but a workaround (temporary solution) can be used to deal with that gap 32 Could Have Requirements which are desirable, but which have a moderate impact on stakeholders’ satisfaction Desired, but less important than Should Have A stakeholder could accept to remove the requirement 33 Would Have (or Won’t Have) Requirements which could be intersting to implement over the long run, but which do not justify spending resources at the moment of the implementation If we had more money/time, we would do it 34 KANO model KANO works in the same way as MoSCoW, but makes use of 5 levels KANO expresses the importance of a requirement to a stakeholder based on the satisfaction and level of implementation of a requirement 35 Must-Be What the stakeholder takes for granted Can be viewed as the Cost of entry to initiate the solution 36 One-Dimensional (Should Have) What the customer demand for the solution, in order for the solution to be acceptable Satisfaction gets higher (proportionally) as the implementation level increases 37 Attractive (Could Have) What the stakeholders do not demand, but appreciate greatly if implemented correctly Satisfaction gets higher (not proportionally) as the implementation level increases 38 Indifferent What the stakeholders do not demand, and for which they are indifferent Satisfaction stays steady as the implementation level increases 39 Reverse What the customer does not want to be verified in its solution Satisfaction gets lower (proportionally) as the implementation level increases 40 4. Requirements Validation 41 Definition Show that the requirements define the system that the customer really wants ( "Quality Gateway"), typically conducted by stakeholders external to the project Justified by the very high costs of errors on requirements The non-detection of an error on the requirements can cost up to 100 times more than the cost of an implementation error The error is amplified through the phases of specification, design and implementation, and becomes significant at the release of the solution Requirements validation is different from Testing Validation: check that the documented requirements are consistent with actual customer expectations Testing: Verify that the system being implemented comply with the specifications, that is the expectations defined in the requirements documents 42 Formal vs. informal validation Linear project approach Documented requirements are reviewed and “signed off” or “baselined” Agile project approach Less formal, but still sufficient clarity required to include them in the backlog Ongoing refinement while in the backlog until “ready” to be allocated to an iteration (e.g. sprint) 43 Criteria Validity Does the requirements reflect the actual expectations of customers? Is the document valid given the elicitation output? Consistency Are there conflicts between requirements, or different descriptions of the same function? Completeness Are all functions (and constraints) required by the customer included? Realism Can the requirements be implemented given the budget and the available technology? Verifiability Can the requirements be checked (during testing for example)? 44 Techniques: requirements review Systematic manual analysis by the business analyst of documented requirements Regular reviews of the documentation should be undertaken while the requirements definition is being developed The customers and stakeholders should be involved in reviews (stakeholders’ involvement) Reviews may be formal (with templates, written documents) or informal (oral feedback) Good communications between developers, customers and users can resolve problems at an early stage 45 Techniques: prototyping Using an executable preliminary model of the solution to check "in practice" if the requirements are correct Create incomplete versions of the solution under development (mock- ups in the case of a software) A prototype typically simulates some aspects of the solution, and can be completely different from the final product 46  47 Techniques: test-case Test-case: test preparation for testing purposes. Nothing is tested here – testability is just verified. Difficult-to-implement tests are indicative of potential issues in the requirements A test case is a set of test components Each component describes entries, actions or events and expected response to determine whether a function of an application/solution works correctly 48  49 5. Requirements Documentation 50 Importance Enables communication Provides a basis for ensuring requirements consistency Provides a firm basis for validating that there is an accurate record of what the solution should provide Essential for further activities to develop and test the solution 51 Documentation Styles Text based Requirements catalogue User story Diagrammatic Use case model Data model Business process model 52 Linear vs. Agile The approach of a project has an impact on documentation Linear project approach: more formal Requirements are documented prior to development Requirements are reviewed and “signed off” Agile project approach: more ad-hoc Requirements are defined in outline (sketchy), early on Changes are applied when more details emerge during the development Requirements evolve during development 53 Example linear approach: waterfall System Inception System analysis Design Implement System Acceptance Maintenance Abolish 54 Example agile approach: scrum 55 Requirements Catalogue Typical for linear projects Simple, tabular format for defining requirements Template listings with key characteristics exist Included characteristics can differ depending on the type of project ✓ Identifier ✓ Business area ✓ Name ✓ Stakeholders ✓ Description ✓ Associated non-functional ✓ Source requirements ✓ Owner ✓ Related requirements ✓ Author ✓ Acceptance criteria ✓ Type ✓ Rationale ✓ Priority ✓ Version history 56 User Stories Often used in agile projects: “backlog of user stories” A user story defines the features actors require from a system Written from an actor or user role perspective, typically informally Quick to develop Intention is to outline the identified requirement, but detail on how to deliver it is subject to discussion, prototyping, and evolutionary development 57 User Story Development 3Cs framework Card: Each user story is documented using a card format, limiting the amount of information Conversation: Each user story is the basis for a conversation where the user story is explored in further depth Confirmation: User stories get accepted when they are evaluated against defined acceptance criteria Standard format As a … (who is the user role or actor?) I want … (what is the capability or feature needed?) So that … (why is the user story beneficial to the user role?) Several user stories can be combined in an epic 58 Example Name: View order As a registered customer I want to view the orders I have placed for products So that I can track when the products will be delivered Priority: Should have Confirmations: Only registered customers are able to view orders Each registered customer can view orders they have placed Only orders placed by a registered customer will be displayed Information about product location will be displayed for orders not yet fulfilled The delivery date will be displayed for all products that have been delivered 59 6. Requirements Modelling 60 Modelling Requirements Modelling can be applied to many requirement levels Business/stakeholder Oftentimes no real “modelling” Other techniques more relevant: personas, prototyping, business glossary, customer journey mapping, Exception: use case diagrams, high-level process models Solution requirements Non-functional requirements → not really applicable Functional requirements → particular focus of diagrammatic modelling techniques Use case diagrams Business process models Data models 61 62 Diagrammatic Models Describing requirements in textual format is often difficult Ambiguity Poor precision Unclear No holistic perspective Models are ideal instruments to provide a picture of the entire solution and confirming the requirements that are in scope UML (Unified Modelling Language) provides a modelling language implementing a variety of different diagram types 63 64 1) Modelling the business perspective Visualising actors who will engage with the system and the features they need to access Excellent for business stakeholders to represent their view of the solution The system/solution still largely remains a black box Different levels of detail: Context diagram Business use case diagram System use case diagram UML Use Case Diagrams are a standard notation 65 UML Use Case Diagram Elements Actors Whoever or whatever expects a service from the system User roles, external systems, etc. Usually shown as matchstick figures Software products that are an actor can be denoted using a rectangle Use case Something that an actor wants a system to do Stated goal + actions/processing steps expected from the system to achieve this goal Modelled using ovals – “verb + noun” naming convention System boundary Large box around all use cases Associations Linking actors and use cases 66 Example Use Case Diagram 67 and Special type of link between use cases Allow for reusing certain steps that are common for multiple use cases, into a separate use case A seconds special link type between use cases For extension scenarios, e.g. processing steps that will be developed during a later iteration 68 Example Use Case Diagram (2) 69 Example Use Case Diagram (3) 70 Example Use Case Diagram (4) 71 2) Modelling the data perspective A data model allows the stakeholders who use the system to agree the data that is to be recorded and accessed First step might be a data dictionary (business glossary) Data modelling is not only used as a basis for database design It is an important task for business analysts to understand what governs the creation, manipulation and deletion of data Especially the conceptual level is relevant, sometimes also logical Two standard techniques Entity relationship diagrams (ERDs) UML Class Diagrams 72 Example UML Class Diagram for Order Processing 73 Example ER diagram 74 3) Modelling the process perspective Next to data, business processes are obviously a key perspective for defining and documenting functional requirements Techniques BPMN UML Activity Diagrams etc. 75 BPMN 76 Activity Diagram 77 7. Requirements Management 78 Managing Requirements Requirements management is the overall process of managing changing requirements Begins at the same time as the project, but continues after the end of the project Requirements change because: Different stakeholders have different requirements and these are often contradictory, appear at different times New requirements emerge during the process as business needs change and a better understanding of the system is developed Experience of users with the solution or its prototype generate more mature requirements Environment (domain) changes 79 Requirements and Change Initial Changed understanding understanding of problem of problem Initial Changed requirements requirements Time 80 Requirements Management Levels We must distinguish two classes of requirements, which require different managements approaches Sustainable requirements Stable requirements derived from the core activity of the customer organization. For example, a hospital will always have doctors, nurses, etc. The requirements can be derived from domain models Volatile requirements Requirements change during development or when the system is in use In a hospital, requirements resulting from the policy of health care is likely to change 81 Types of Volatile Requirements Mutable requirements Requirements that change due to the system environment, to the domain Emerging requirements Requirements that emerge as the understanding of the system develops Consequential requirements Requirements that result from the introduction of another computer system or any other solution introduced in the business (change of work processes) Compatibility requirements Requirements that depend on on other systems or organizational processes 82 Traceability Traceability is concerned with the relationships between requirements, their sources and the system design Source traceability links the requirements to the stakeholders who proposed these requirements Requirements traceability links the requirements to other dependant requirements in the solutions in order to assess how many other requirements will be affected by a change in the solution(impact analysis) Design traceability links requirements and design modules that implement them in the solution 83 Traceability Traceability is concerned with the relationships between requirements, their sources and the system design Horizontal traceability: tracing the requirement from inception to delivery Vertical traceability: tracing a requirement up or down the requirements hierarchy 84 Horizontal traceability Backwards from traceability Ability to trace the source of a feature or requirement from any later point in the business change or software development cycle “What was the source for this requirement and who raised it?” Forwards to traceability Ability to identify any requirement and track where it has been developed and implemented “What happened to this requirement?” 85 Vertical traceability Alignment with general/technical requirements Ultimately also alignment with business values, policies, strategy and objectives 86 8. Conclusion 87 Conclusion Requirements are a fundamental concept in conducting a business analysis project Requirements Engineering entails elicitation, analysis, modelling, documentation, validation, and management Requirements documentation is a crucial aspect within a business analysis project Business and especially functional requirements are often subject to diagrammatic modelling Providing clarity, consistency, sufficient detail, alignment, etc. Most important viewpoints: Business: use case diagrams Process: business process models Data: data models 88 What should you know and what should you be able to do? You should know: what requirements are and which types of requirements exist what methods/techniques exist for eliciting requirements what methods/techniques exist for defining and prioritizing requirements what requirements validation is about and which techniques exist for this purpose what requirements management entails, in particular in terms of traceability what requirements documentation is about and why it is important which main techniques are used for requirements documentation what requirements modelling is and to which types of requirements this is mostly applied examples of diagrammatic modelling languages for the business, process, and data perspectives what use case diagrams are and how they can be used for modelling requirements 89  BA4. Delivery of Solution and Project Management Prof. Dr. Jochen De Weerdt Lecture overview 1. Making the Business Case 2. Solution Development Approaches 3. Testing the Solution 4. Delivering the Solution 5. Conclusion 2 Supporting lecture material Milani, F., (2019) Digital Business Analysis. Springer. Chapter 14 Chapter 18 Chapter 19 3 Where are we? BABOK Knowledge Areas 4 Solution Evaluation 5 1. Making the Business Case 6 Business Case A business case presents and evaluates one or more courses of action that will address a problem or enable the organisation to grasp a business opportunity Supports decision making, persuade stakeholders to move forward Stress benefits, not features Sell the benefits before discussing the costs Ensure the ‘buyers’ understand the size of the problem or opportunity before time, effort, money required to implement the solution 7 When to Produce a Business Case Immediately after preliminary investigation Living document: ongoing review Projects should pass certain tests, especially related to business viability, before they can proceed to a next stage (“decision gates”) 8 Structure of a Business Case Introduction Executive summary Description of the current situation Options considered Option description Analysis of costs and benefits Impact assessment Risk assessment Recommendations 9 Analysis of Costs and Benefits Tangible and intangible costs Tangible and intangible benefits Appraisal techniques Payback (break-even) Discounted Cash Flow (DCF) / Net Present Value (NPV) Internal Rate of Return (IRR) 10 Template Cost-Benefit Analysis 11 Cost of the Solution Top-down vs. bottom-up Rough Order of Magnitude PERT (Three point) estimation Bottom-up More accurate, but requires detailed solution description Top-down Fast, less costly, but less accurate 12 Rough Order of Magnitude (ROM) Goal: provide stakeholders and decision makers with a rough idea of the project’s costs Accuracy of ROM estimates is typically -25% to +75% (PMBOK, 6th edition) Upper boundary = ROM_Estimate x 1,75 Lower boundary = ROM_Estimate x 0,75 13 PERT (Three Point) Estimation Subject matter experts propose three different estimates Optimistic estimate Pessimistic estimate Most likely estimate PERT: Program Evaluation and Review Technique PERT distribution overweighs the “most likely” estimate compared to a triangular (normal) distribution E = (O + 4*M + P)/6 14 Impact and Risk Assessment Example impact areas: Organisation structure Interdepartmental relations Working practices Management style Recruitment Appraisal and promotion Supplier relations Risk assessment Description + Impact + Probability + Countermeasures + Ownership 15 Business Cases in an Agile Context Organisations steer away from large, monolithic projects towards more incremental approaches A modified approach to business case production is required An initial business case is produced based on the feasibility study MoSCoW prioritisation is applied to formulate options Delivery of each release is an opportunity to revisit or extend the business case and reprioritize the backlog according to changes in the environment 16 2. Solution Development Approaches 17 The Delivery Style Numerous methods, standards and lifecycles that may be used when developing solutions to fulfil defined requirements Factors Roles: key roles to be performed during the project Deliverables: artefacts to be delivered by the team Context: characteristics of the business and the project Lifecycle: the process adopted for development and implementation 18 Context Culture and philosophy Business context Constraints Prioritised business needs Project drivers 19 Delivery Lifecycles Software development lifecycles provide a clear basis for conducting development projects Sets out a sequence of stages required to define, develop and deploy an IT system. These lifecycles can be easily adapted to business change projects, even if software engineering angle is not present Main SDLCs Waterfall V model Incremental lifecycle Iterative lifecycle 20 The Waterfall Lifecycle Feasibility Study Analysis Design Development Testing Implementation 21 Main Characteristics Series of sequential stages Each stage is “signed off” before the next starts Backwards-facing arrows indicate the need to check back Benefits Strong basis for firm and clear project management Should support delivery of high-quality solution Drawbacks High risk for project delays due to exhaustive quality focus Does not enable adaptation and change well 22 The V Model 23 Main Characteristics Variant of waterfall model Testing stages explicitly shown At each stage, the derivation and usage of test criteria is made explicit Business case is used post-implementation to review the success of the recommended solution Similar benefits and drawbacks compared to waterfall 24 The Incremental Lifecycle 25 Main Characteristics Recognizes the difference in importance of certain requirements A need remains to have a complete set of requirements and an overall design at the start Goal: developing and delivering the solution in a series of increments High priority requirements first Lower priority requirements deferred Drawbacks Total delivery cost likely higher than delivering in one release High level analysis and design of the solution should be future-proofed, if not, prone to inconsistencies, errors and conflicts 26 The Iterative Lifecycle Spiral model (Boehm, 1986) Introduced the concept of iterations Heavily based on prototyping Became the basis for early Agile approaches, including Rapid Application Development (RAD) Newer Agile approaches DSDM Scrum 27 Agile Principles 28 Main Characteristics Collaborative working Prioritised requirements Timeboxed iterations Evolutionary development Empowered teams Incremental delivery Continuous testing Experiential learning 29 Agile Methodologies Scrum Lean Kanban Crystal Extreme Programming (XP) Feature Driven Development (FDD) Dynamic System Development Method (DSDM) 30 Scrum Minimum Viable Product (MVP) 31 Lifecycles – Summary SDLC Predictive/Adaptive Linear/Evolutionary Waterfall Predictive Linear V model Predictive Linear Incremental lifecycle Predictive Evolutionary Agile Adaptive Evolutionary Agile approaches very popular nowadays They can cope with the rapid pace of business change Predictive techniques assume that business stakeholders know exactly what they want at the outset of a project. This is often problematic. Fragmentation can be a problem because of the lack of overview understanding of the intended solution 32 Selecting an Approach 33 3. Testing the Solution 34 Solution Evaluation Context Strategy Design Deliver Evaluate BA Plan Analysis Analysis Solution Solution Solution Stakeholder External Current s State Internal Activities Future State Cost Risk Time Change 35 Alternatives Not as expected? Delay Not being realized Actions Do nothing Organizational change Change the solution Retire the solution 36 Testing Important part of the implementation phase Different definitions Testing is trying to demonstrate that the systems works fine Testing is running the system with the purpose of finding errors Testing is finding the differences between the desired results and the real results Testing is measuring software quality 37 Test levels Testing occurs at different levels: Unit/Module testing (lowest level) Integration testing (the system as a whole) System testing (specific aspects) Safety test Volume test Performance test Stress test (extreme situations) Acceptance testing (by the business) 38 Testing life cycle: V-model 39 Software testing lifecycle Unit tests: Validate that each unit of the software performs as designed For each module, does each operation perform as expected For method xyz(), there could be another method testxyz() Integration tests: Check that modules work together in combination Expose faults in the interaction between integrated units All sorts of hidden assumptions are surfaced when code written by different developers are used in tandem Typically, most projects are on schedule until they hit this point 40 Software testing lifecycle System tests: Evaluate the system’s compliance with the specified requirements Have all user stories been implemented, and do they function correctly? Acceptance tests: Evaluate the system’s compliance with the business requirements and assess whether it is acceptable for delivery Internal acceptance testing is usually performed by members of the organization that developed the software but who are not directly involved in the project (Development or Testing). For example, the members of Product Management, Sales and/ or Customer Support doing alpha testing. External acceptance testing is performed by people who are not member of the organization that developed the software. For example, users doing beta testing 41 Integration testing Different approaches: Bottom-up integration testing Empty control module calling the module to be tested (Driver) Top-down integration testing Empty modules at the lower level (returning the correct results) (Stub) Big-bang integration testing After testing all modules, they are combined, and the entire system is tested. 42 Unit/module testing Static testing (no execution) Desk checking Structured walkthroughs Control flow & reachability Data flow Dynamic testing (execution with test cases) Problem: if we can not test exhaustively, which test cases to select? “Black box testing” (functional testing) “White box testing” (content testing, structural testing)- 43 Black box testing Independent from the code (not looking at the code) Random testing (random selection of input values) Varied selection from the problem domain Boundary values from the problem domain Disadvantage: What else is in the code? 44 White box testing Looking at the module content Tester should have an in-depth knowledge of the source code being tested (predicates, paths, selections, loops) Selecting input values that cover as much as possible (paths, branches, loops, special boundaries) Disadvantage: What if it is not in the code? 45 Traditional 'white box' criteria Path coverage: trying to test each possible path through the module. ▪ Path coverage: N * M ▪ Branch coverage: N + M N M Branch coverage: trying to test at least each branch and predicate once. Structured testing: boundary cases of loops. Special values testing: exceptions, limits 46 Branch coverage Test cases a+c b+d a b Not tested: a+d b+c c d 47 User acceptance testing 48 4. Delivering the Solution 49 The Business Change Lifecycle 50 Implementation stage Implementation of a business change programme requires planning and careful execution Three major aspects Business readiness assessment Transition and migration People’s response to change 51 Business readiness assessment Is the business area where changes are to be made sufficiently prepared to accept and operate the new ways of working? McKinsey 7S model can be of use Key areas to review Need to evaluate “fit” between these areas 52 Transition and migration Data migration Training sessions Creation of user guides, procedure descriptions, checklists, etc. Deciding on implementation strategy Direct changeover Parallel running Pilot running Phased implementation 53 Human response to change SARAH curve 54 Realisation stage Focus on how the expected business benefits are to be achieved Aspects Benefits plan Benefits dependency network Benefits review/business case management 55 5. Conclusion 56 Conclusion A lot of focus in business analysis projects is on the analysis and solution design However, delivering the solution and managing the way in which the solution is developed (and tested) are crucial for success as well Key elements The business case The delivery style and project management lifecycle Solution testing Solution delivery 57 What should you know and what should you be able to do? You should know: what a business case is and which role it plays in the broader BA life cycle which solution development approaches exist, what their characteristics are, and main benefits/drawbacks how solution testing can be achieved, particularly in projects involving software development. the different levels and approaches for testing a solution what the most important aspects are at the solution delivery stage 58  Part II Business Process Management (BPM)  BPM1. Introduction to BPM Prof. Dr. Jochen De Weerdt Lecture overview 1. The world of Business Process Management (BPM) 2. The BPM lifecycle 3. Process discovery: as-is process modelling Many of the slides in this presentation are based upon lecture material from W. van der Aalst 2 (TU/e), M. La Rosa (QUT), J. Mendling (WU Vienna), and M. Dumas (University of Tartu). Lecture material Dumas, M., La Rosa, M., Mendling, J., Reijers, H. (2018) Fundamentals of Business Process Management. Chapter 1 Chapter 2 Chapter 5 (Sections 5.1, 5.2, and 5.3) 3 1. The world of Business Process Management (BPM) 4 Business Process Management: What is it? Body of principles, methods and tools to design, analyze, execute and monitor business processes 5 Why BPM? “The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency.” 6 Why BPM? Information Yields Technology Business Value Enables Yields Process Change Index Group (1982) 7 How to engage in BPM? Continuous Process Improvement (CPI) Does not put into question the current process structure Seeks to identify issues and resolve them incrementally, one step at a time and one fix at a time Business Process Re-Engineering (BPR) Puts into question the fundamental assumptions and principles of the existing process structure Aims to achieve breakthrough, for example by removing costly tasks that do not directly add value 8 Our phenomena of interest: Business processes Collection of related events, activities and decisions, that involve a number of actors and objects, and that collectively lead to an outcome that is of value to an organization or its customers. Examples: Order-to-Cash Quote-to-Order Procure-to-Pay Application-to-Approval Fault-to-Resolution (Issue-to-Resolution) Claim-to-Settlement “If it does not make at least three people mad, it’s not a process.” Hammer and Stanton (1995) 9 “My washing machine doesn’t work…” Insurance Call Centre Company Technician Customer Customer Parts Service Store Dispatch Centre VALUE fault-to-resolution process 10 Processes and outcomes Every process leads to one or several outcomes, positive or negative Positive outcomes deliver value Negative outcomes reduce value Fault-to-resolution process outcomes: Fault repaired without technician intervention Fault repaired with minor technician intervention Fault repaired and fully covered by warranty Fault repaired and partly covered by warranty Fault repaired but not covered by warranty Fault not repaired (customer withdrew request) 11 What is a business process: Recap 12 The core elements of a process Activities active elements (e.g. ‘enter sales order’) time-consuming, resource-demanding state-changing Events passive elements