Full text
1 A COMPREHENSIVE BPM APPROACH IN ASRA SOFT: TECHNICAL ASSISTANCE PROCESS OPTIMIZATION Eastern Michigan University GameAbove College of Engineering & Technology EM511 Manufacturing Engineering Fundamental (16103/Ahmed) Title: A COMPREHENSIVE BPM APPROACH IN ASRA SOFT: Technical Assistance Process BPM Initiative Date: December 2025 Author: Unais Ali
2 EXECUTIVE LETTER TO SENIOR MANAGEMENT Date: December 2024 To: Senior Management, Asra Soft From: Business Process Management Project Team Subject: Comprehensive Business Process Management Initiative: Technical Assistance Process Optimization Report Dear Senior Management, I am pleased to present this comprehensive Business Process Management (BPM) report documenting the completion of our systematic analysis and redesign of the Technical Assistance process at Asra Soft. This initiative represents a strategic investment in organizational efficiency, customer satisfaction, and operational excellence. This BPM initiative positions Asra Soft for sustainable competitive advantage through process efficiency, enhanced customer satisfaction, and organizational capability building. The projected 9-10 months payback period makes this a strategically sound and financially prudent investment. I remain available to discuss any aspects of this report, clarify findings, or address questions regarding implementation plans. Respectfully submitted, Project Team Leader
3 Executive Summary Through rigorous application of BPM methodologies, including process discovery, quantitative and qualitative analysis, and heuristic redesign, we have identified significant opportunities for improvement across the Technical Assistance process; our core revenue-generating and customer-facing operation. Current State Analysis (AS-IS) Our comprehensive analysis of the Technical Assistance process reveals the following baseline performance metrics: • Average Process Cycle Time: 158 minutes (2.6 hours) per service instance • Cost per Service Instance: PKR 500-550 • Error Rate: 12-15% (requiring rework) • Resource Utilization: 65-70% • Customer Resolution Time: 3-5 days average • First-Contact Resolution Rate: 85-88% • Total Process Issues Documented: 75 issues over 2-month period Projected Improvements (TO-BE) Our redesigned process model projects the following improvements: • Cycle Time Reduction: 45-50% improvement (target: 75-85 minutes) • Cost Per Instance Reduction: 30-35% savings (target: PKR 325-380) • Error Rate Reduction: 60% reduction (target: 5-6%)
4 • Resource Utilization Improvement: 22% increase (target: 85-90%) • Customer Resolution Time: 50% faster (target: 1-2 days) • First-Contact Resolution: +10% improvement (target: 94-96%) Critical Issues Identified Through systematic analysis using Issue Register, Pareto Analysis, Root Cause Analysis, and the 5-Whys technique, we documented 75 process issues. Pareto analysis revealed that three categories account for approximately 80% of all problems: 1. Client Contact Failures (32%) – Difficulty reaching clients, outdated contact information 2. Information Entry Errors (28%) – Data mistakes causing rework and quality issues 3. Manpower Shortage (20%) – Resource allocation and scheduling challenges Recommended Solutions We propose implementing a comprehensive technology and process redesign strategy: Technology Component: • ODOO ERP implementation (Helpdesk, Field Service, Studio modules) • Automated ticket creation and intelligent routing • Real-time technician tracking and resource optimization • Centralized data management eliminating duplicates
5 Process Component: • Automation of routine tasks (eliminating 43% non-value-adding activities) • Remote material assessment before site visits • Parallel processing of activities • Streamlined closing and documentation Expected Return on Investment (ROI) Financial Analysis: • Annual Cost Savings: PKR 126,000 (labor + material waste reduction) • Additional Annual Revenue: PKR 150,000+ (capacity for 50% more instances) • Total Year 1 Benefit: PKR 276,000 • Year 1 Implementation Cost: PKR 210,000-240,000 • Payback Period: 9-10 months • Year 2 ROI: 360%+ (annual benefit vs. ongoing license cost) Non-Financial Benefits: • 25% improvement in customer satisfaction • 60% reduction in service defects • Enhanced organizational capability and process maturity • Improved staff engagement and decision-making authority Implementation Roadmap We propose a structured 6-month phased implementation plan:
6 • Phase 1 (Weeks 1-2): Planning & Setup • Phase 2 (Weeks 3-5): Configuration & Customization • Phase 3 (Weeks 6-7): Testing & Refinement • Phase 4 (Weeks 8-10): Training & Change Management • Phase 5 (Weeks 11-12): Pilot Implementation • Phase 6 (Weeks 13-24): Full Geographic Rollout Required Executive Actions 1. Approve ODOO ERP implementation (Helpdesk, Field Service, Studio modules) 2. Allocate resources for implementation team (estimated 2-3 ODOO specialists + internal staff) 3. Establish governance structure with weekly steering committee oversight 4. Commit to change management including training and communication plan 5. Finalize budget approval (PKR 210,000-240,000 for Year 1) Strategic Alignment This BPM initiative directly supports Asra Soft's strategic objectives: • Operational Excellence: 34% cycle time reduction • Customer Focus: 50% faster resolution, 25% satisfaction improvement • Financial Performance: 35% cost reduction per instance
7 • Organizational Growth: 50% capacity increase without proportional resource increase • Digital Transformation: Foundation for enterprise-wide process management Next Steps Upon executive approval, the project team will proceed immediately with: 1. ODOO license procurement 2. Implementation team composition finalization 3. Stakeholder communication and engagement 4. Detailed project planning and governance establishment 5. Phase 1 execution (Planning & Setup)
8 Contents EXECUTIVE LETTER TO SENIOR MANAGEMENT ............................................................. 2 Executive Summary .................................................................................................................... 3 Current State Analysis (AS-IS) ................................................................................................ 3 Projected Improvements (TO-BE) ........................................................................................... 3 Critical Issues Identified .......................................................................................................... 4 Recommended Solutions .......................................................................................................... 4 Technology Component: ...................................................................................................... 4 Process Component: ............................................................................................................ 5 Expected Return on Investment (ROI) .................................................................................... 5 Financial Analysis:............................................................................................................... 5 Non-Financial Benefits: ....................................................................................................... 5 Implementation Roadmap ....................................................................................................... 5 Required Executive Actions ..................................................................................................... 6 Strategic Alignment ................................................................................................................. 6 Next Steps................................................................................................................................ 7 ABSTRACT .............................................................................................................................. 13 Key Results: .......................................................................................................................... 14 LIST OF ABBREVIATIONS AND ACRONYMS ...................................................................... 15 1. INTRODUCTION ............................................................................................................. 16 1.1. Background and Problem Identification ................................................................... 16 1.1.1. The Organization: Asra Soft ................................................................................ 16 1.1.2. Organizational Evolution: ..................................................................................... 17 1.1.3. Strategic Context: ................................................................................................. 17 1.1.4. The Challenge: ..................................................................................................... 18 1.2. Study Objectives ....................................................................................................... 18 1.2.1. Primary Objectives: ............................................................................................. 19 1.2.2. Secondary Objectives: .......................................................................................... 19 1.3. Study Relevance and Importance ............................................................................. 20 1.3.1. Strategic Importance:........................................................................................... 20 2. LITERATURE REVIEW .................................................................................................. 22 2.1. Business Process Management .................................................................................. 22 2.2. BPM LIFECYCLE ................................................................................................... 26 2.2.1. Process Identification ........................................................................................... 28 2.2.2. Process Discovery ................................................................................................. 29 2.2.3. Process Analysis ................................................................................................... 33 2.2.4. Process Redesign .................................................................................................. 46 2.2.5. Process Implementation ....................................................................................... 50
9 2.2.6. Process Monitoring and Control............................................................................ 51 2.3. ENTERPRISE PROCESS MANAGEMENT............................................................ 53 2.3.1. Business Process Governance ............................................................................... 55 2.3.2. Maturity Model .................................................................................................... 56 2.3.3. BPM Context Framework .................................................................................... 64 2.3.4. City of Ghent - Case Study Overview ................................................................... 66 3. METHODOLOGY ............................................................................................................ 73 3.1. INTERNSHIP SETTING ......................................................................................... 73 3.2. METRICS ................................................................................................................ 74 3.3. CHOOSING THE BPM MODELING TOOL .......................................................... 74 3.4. BPMN 2.0 NOTATION ............................................................................................ 76 4. BPM IN ORGANIZATION ............................................................................................... 79 4.1. Organizational Context ............................................................................................ 79 Asra Soft's Current Organizational Structure: .................................................................. 79 Business Model & Revenue Streams: ................................................................................. 80 4.2. BPM Overview in Asra Soft Context ........................................................................ 80 4.3. BPM Maturity Assessment ....................................................................................... 81 Assessment Results: ........................................................................................................... 81 5. PROCESS PROJECT ........................................................................................................ 82 5.1 Process Identification & Overview of Candidate Processes ........................................... 82 Process Discovery Methodology: ........................................................................................ 82 5.2. Process Selection & Deep Dive .................................................................................. 84 Selection Criteria: .............................................................................................................. 84 Candidate Processes Evaluated: ......................................................................................... 85 Selection Justification: ....................................................................................................... 86 5.3. Process Discovery: AS-IS Model ............................................................................... 86 Process Boundaries: ........................................................................................................... 86 Process Scope: ................................................................................................................... 87 High-Level Process Flow:................................................................................................... 87 Process Participants & Roles: ............................................................................................ 88 6. TECHNICAL ASSISTANCE PROCESS ANALYSIS ....................................................... 89 6.1. Data Collection & Analysis Methods ........................................................................ 89 Data Collection Techniques Applied: ................................................................................. 89 6.2. Value-Added Analysis .............................................................................................. 90 Classification Methodology: ............................................................................................... 90 6.3. Waste Analysis (8 Lean Wastes) ............................................................................... 92 6.4. Issue Register ........................................................................................................... 94 Documentation Methodology: ............................................................................................ 94
16 1. INTRODUCTION 1.1. Background and Problem Identification Processes are the core foundation of every business. They exist universally within organizations and are essential for business operations. Well-developed and monitored processes enable companies to adapt to changing environments, comply with regulatory requirements, and directly influence organizational revenue and costs (Dumas et al., 2018). In today's dynamic business environment, where adaptability and continuous improvement are crucial for company survival and growth, Business Process Management offers relevant contributions by delivering measurable improvements in organizational performance and service quality. 1.1.1. The Organization: Asra Soft Asra Soft, established in November 2001 by founder Ricardo Dias, is a software services organization dedicated to commercializing information technology products, software solutions, and comprehensive information systems services. The company has evolved significantly from its initial single office in Islamabad to a multi-regional operation across Pakistan.
17 1.1.2. Organizational Evolution: • 2001-2003: Initial establishment in Islamabad; expansion to Rawalpindi and Lahore • 2005-2009: Market entry in Karachi; establishment of strong accounting and ERP services • 2013: Significant investment in Karachi operations to improve response time and efficiency • 2015-2017: Geographic expansion to Peshawar, Quetta, Faisalabad, Multan, and Hyderabad • Current Status: Operating across approximately 100 of 155 local councils in target regions 1.1.3. Strategic Context: Asra Soft operates primarily within the public sector market, providing accounting services and IT solutions to local government entities and SMEs. As a customer-centric service organization, the company's competitive advantage depends on: • Process efficiency and cost management • Service quality and customer satisfaction • Rapid issue resolution and customer responsiveness • Resource optimization across geographic locations • Employee productivity and engagement
18 1.1.4. The Challenge: Despite market success, Asra Soft faces emerging operational challenges: 1. No systematic BPM approach – Organization has not previously undertaken formal BPM initiatives 2. Outdated process documentation – Process descriptions not updated in over a decade 3. Process variability – Different departments execute similar tasks with inconsistent methodologies 4. Limited performance visibility – Lack of automated performance metrics and monitoring 5. Resource constraints – Geographic expansion without corresponding process optimization 6. Quality inconsistency – Service delivery varies significantly between locations and staff 7. Customer satisfaction gaps – Extended response times and resolution cycles 1.2. Study Objectives The primary objectives are defined around applying the complete Business Process Management lifecycle as presented by Dumas et al. (2018):
19 1.2.1. Primary Objectives: 1. Assess Asra Soft's maturity level for BPM initiatives using established BPM maturity models 2. Identify, catalog, and prioritize all organizational business processes and their relationships 3. Model the current state (AS-IS) of the Technical Assistance business process using BPMN notation 4. Analyze the AS-IS process to identify performance issues, waste, and improvement opportunities 5. Document and prioritize process issues using systematic techniques (Issue Register, Pareto Analysis) 6. Identify root causes of performance gaps through qualitative and quantitative analysis 7. Apply redesign heuristics to develop an optimized TO-BE process model 8. Develop comprehensive implementation roadmap with phased approach and risk management 9. Identify and compile tasks completed across organizational units 1.2.2. Secondary Objectives: • Establish baseline performance metrics (cycle time, cost, quality, resource utilization)
20 • Apply systematic redesign heuristics to identify improvement opportunities • Conduct flow analysis and process simulation for current and proposed states • Prepare organization for system implementation through change management planning • Develop understanding of BPM methodology and ERP system capabilities 1.3. Study Relevance and Importance 1.3.1. Strategic Importance: Optimizing processes through BPM provides Asra Soft with multiple competitive advantages: Quality & Compliance: • Assured consistent service quality across locations • Reduced defect rates and rework • Compliance with Pakistan's regulatory requirements and ISO 9001:2015 QMS standards Financial Benefits: • Reduced operational costs through waste elimination • Improved cost visibility and control • Higher revenues through increased capacity utilization • Faster customer resolution reducing rework costs
21 Operational Excellence: • Reduced cycle times and faster customer response • Elimination of redundant activities • Automated routine tasks freeing staff for value-added work • Clear documentation of responsibilities and information flows Customer Satisfaction: • Faster service delivery and issue resolution • Consistent service experience across locations • Improved responsiveness to customer needs • Better communication and transparency
22 2. LITERATURE REVIEW This chapter reviews the key concepts and sources that informed the internship and its project. As Paul and Criado (2020) argue, a well-researched literature review offers a clear, comprehensive synthesis of prior studies, strengthening the project’s knowledge base. It serves as the academic core of the report, identifying and presenting the theories and research that guided the work. The section begins with an overview of Business Process Management (BPM). It then examines the BPM lifecycle as discussed by Dumas et al. (2018), with a closer look at each phase. Next, it reviews Enterprise Process Management (EPM), including process maturity, business process maturity models, the BPM context framework, business process governance, and an illustrative case study in the BPM context. The literature was identified primarily through online searches using Google Scholar and ScienceDirect, complemented by recommendations from Professor Frederico Cruz. 2.1. Business Process Management Before diving into the concepts of BPM, its lifecycle, and approaches, it is necessary to understand the core of it all, which is processes. Processes are everywhere in an organization and even in each person’s day-to-day life. We cannot carry out our lives without processes. The Oxford Advanced Learner’s Dictionary defines a process as “a series of actions or steps taken in order to achieve a particular end” (“Process,” 2021). This applies to organizations, with processes existing in every department at any time, and
23 to daily life. For example, when someone follows a new recipe, they are carrying out a process: an input is given (the raw ingredients), a series of steps is taken to achieve an end, which in this case is the meal. A business process is a specific type of process that focuses on steps and activities by either humans or machines to create value for a customer by transforming specific inputs into outputs (Davenport, 1993). Figure 1 demonstrates that a process is composed of different elements. The inputs represent the materials and components necessary to start the process, the processing phase is where those inputs are worked on, the outputs are the resulting products or services, and the feedback connects the outputs to possible new inputs, including customer feedback and managerial ideas. Figure 1 - Transformation Model (2013). Source: https://businessfortheyoung.weebly.com/inputprocess-output/archives/12-2013.
24 Dumas et al. (2018) define a business process as “a collection of interrelated events, activities, and decision points that involve several actors and objects, and that collectively lead to an outcome that is of value to at least one customer,” making the process the basic unit of business value inside an organization. With rapid technological development and globalization, companies face the important challenge of managing business processes effectively. The rise in orders, the need for faster information transfer, and accelerated decision-making have influenced this need (Ko et al., 2009). This challenge prompted the use of different disciplines, including BPM, Total Quality Management (TQM), Operations Management, Lean, and Six Sigma (Ko et al., 2009). Pyon et al. (2011) define BPM as a discipline that directly supports business processes by using a set of approaches to design, analyze, and control operational processes involving people, applications, documents, and the organization. Lemańska-Majdzik and Okręglicka (2015) suggest adopting the customer’s point of view when taking a process approach, since the end goal is to define a structure that produces value for customers. BPM provides tools to increase effectiveness and efficiency and contributes to performance and competitiveness, which organizations need to survive and scale. It is also increasingly important for innovation and transformation (vom Brocke et al., 2014). As noted above, BPM is not alone among disciplines concerned with performance improvement. TQM is often said to have inspired BPM (Dumas et al., 2018; Stravinskiene and Serafinas, 2020). However, TQM focuses more on products and services themselves, while BPM focuses on improving the processes that create those products and services. BPM also differs from Operations Management. Despite sharing techniques for optimization such as modeling and simulation, Operations Management
25 focuses on controlling existing processes without necessarily changing them, while BPM changes existing processes to improve them. BPM also incorporates practices from Lean and Six Sigma. Lean emphasizes eliminating activities that do not add value to the customer, which is reflected in BPM practices such as value-added qualitative analysis, and Six Sigma focuses on minimizing defects, aligned with BPM techniques such as waste analysis (Dumas et al., 2018). The benefits of BPM range from the enterprise level to the customer and managerial levels. Monitoring processes can improve compliance, since organizations face compliance risks through inappropriate response times, and assessing the costs of processes and activities facilitates overall cost control and potential cost reduction. BPM can improve customer satisfaction by enabling process efficiency, meeting time expectations, and allowing for potential price reductions through lower costs. For management, BPM supports continual improvement to plans and projections by enabling needed mediumand long-term changes. It also helps process actors understand the organization’s process map and interactions through well-documented processes (ABPMP, 2013). According to Jeston and Nelis (2013), several drivers and triggers may lead an organization to consider BPM. These can arise in the organization, management, employees, customers, suppliers, partners, products and services, processes, and information technology. An organization may struggle to cope with sudden high growth or need to meet compliance and regulatory criteria. Management may need greater control and transparency. Employees may express low satisfaction with aspects of their process lifecycles. Customers, suppliers, and partners may express dissatisfaction with service
32 • Identifying activities and events enables domain experts to articulate what they do, even if they are not aware of the overarching business process (Dumas et al., 2018). Activities represent tasks and subprocesses; events are occurrences that may start, end, or happen during the process (Aagesen & Krogstie, 2014). More detailed node types are discussed in the BPMN section of this report. • Once activities and events are listed, resources can be assigned to each, whether human or technological. This supports the creation of pools and lanes: a pool typically represents an organization, while a lane represents an entity within that organization (e.g., a department) (Owen & Raj, 2003). It is also important to identify handover points where work moves between resources (Dumas et al., 2018). • Control flow addresses when and why activities and events occur, often represented by gateways (Dumas et al., 2018). Gateways model decision points: for example, an exclusive gateway allows only one outgoing path, while an inclusive gateway allows one or more paths, depending on the situation (Dijkman et al., 2008). • Additional elements such as data objects, data stores, and exception handlers are identified last. To ensure model quality, the produced model should be assessed by multiple process analysts and domain experts, focusing on syntactic, semantic, and pragmatic quality. Syntactic quality checks compliance with the chosen modeling notation’s syntax. Semantic quality verifies that the model accurately represents the current process, with
33 domain experts providing key validation. Pragmatic quality ensures the model is readable and understandable for all stakeholders (Dumas et al., 2018; Fellmann et al., 2013). 2.2.3. Process Analysis To update and improve an existing business process, it is vital to understand its current state and how it contributes to strategic business objectives. Process analysis provides this understanding. It can be conducted through various methods and techniques and is an essential tool for evaluating process efficiency (ABPMP, 2013). Process analysis is commonly divided into two distinct types: qualitative and quantitative process analysis (Dumas et al., 2018). 2.2.3.1. Qualitative Process Analysis Qualitative process analysis relies on subjective judgment based on “soft,” nonquantifiable data. Tools for this type of analysis are often borrowed from Lean and Six Sigma (Conger, 2010). Value-Added Analysis (VAA) aims to remove nonessential process tasks, i.e., waste. Shou et al. (2019) define value from the customer’s viewpoint: delivering exactly the needed product or service in minimal time at an appropriate price, with value-adding activities contributing directly to what customers want. Conversely, waste comprises tasks that consume organizational resources without creating customer value. To apply VAA, the process must first be modeled and mapped. Following the lifecycle, this should have been completed in the process discovery phase. Next, process activities are decomposed into more specific steps. Because activities may include multiple necessary steps, this
34 decomposition is performed by process analysts through observation and interviews with process participants. According to Dumas et al. (2018), the next step is to clearly identify the customer of the process and the positive outcomes they seek. Steps that contribute to these outcomes are “value-adding” (VA). Dumas et al. (2018) also propose “business value-adding” (BVA) steps, those that do not directly contribute to customer outcomes but are necessary or beneficial for the business to function effectively, reduce issues, or comply with regulatory requirements. The third classification is “non-value-adding” (NVA) steps, those that do not fall into either of the above categories. After classifying steps, each NVA step is evaluated to determine if and how it can be eliminated. Handovers, often considered NVA, can frequently be reduced or eliminated through information system support (Dumas et al., 2018). Waiting times should be removed whenever possible, as they constitute pure waste (Conger, 2010). When considering waste elimination, it is critical to weigh the pros and cons of proposed solutions. Some of these trade-offs will be addressed during the process redesign phase covered later in this report. BVA steps should be minimized where feasible, but with caution. Because they may be essential for compliance or risk control, map BVA steps to company goals and requirements before making changes (Dumas et al., 2018).
35 Waste analysis focuses on identifying “waste” within and between steps. Derived from Lean and the Toyota Production System (TPS), Taiichi Ohno identified seven wastes: • Transportation • Motion • Inventory • Waiting • Overproduction • Overprocessing • Defects A later, eighth waste, Unused Talent, was recognized when TPS practices were adopted in the West. Transportation and Motion are movement-related wastes. Transportation waste involves moving materials across the supply chain, creating costs and delays for customers. For example, long distances between warehouses or service departments and production facilities (Soliman, 2017). In business processes, this includes moving documents between participants. Motion waste concerns unnecessary human movement and poor workplace layout, which is more common in manufacturing than in services (Wahab et al., 2013). Soliman (2017) considers inventory waste one of the most significant. Excess inventory incurs additional labor and equipment costs for handling. Inventory types include raw materials, work-in-process (WIP), and finished goods. WIP consists of materials and parts not yet part of the finished product but no longer raw materials
36 (Barrak et al., 2017). In services, office inventory waste may include pending files, unused records, and obsolete documents. Waiting waste concerns time lost, waiting for materials, maintenance, resource availability, or during resource idleness (Soliman, 2017). Reducing cycle time by eliminating waiting within the work sequence can markedly increase productivity (Art of Lean, 2000, p. 11). Overproduction waste is directly related to inventory waste. Producing more than needed or beyond demand leads to substantial losses due to production and inventory costs (Skhmot, 2017). In services, overproduction may involve initiating processes that add no value upon completion, such as printing documents before they are needed, or that ultimately are not needed at all. Overprocessing waste is the unnecessary extra effort in producing a product or delivering a service, including integrating requirements not requested by the customer (Furterer, 2009). Defect waste, also called correction waste, results from inadequate internal quality, such as goods requiring rework or services delivered with errors (Art of Lean, 2000, p. 10). Soliman (2017) suggests standardizing work procedures to mitigate failures and enhance overall quality. Given the need for continuous improvement, Dumas et al. (2018) argue that no matter how much a process has improved, there will always be further opportunities due to errors, misunderstandings, incidents, or unnecessary steps. These issues should be
37 documented. Process analysts should collect information through interviews with diverse stakeholders. Dumas et al. (2018) caution that analysts must gather inputs from both process participants and process owners, as these perspectives may reveal different issues, from unmet performance objectives to resource constraints and customer-induced errors. Root cause analysis (RCA) comprises techniques for examining factors that drive performance variation or lead to negative outcomes. These techniques help design effective strategies to address specific issues (Dumas et al., 2018; Brook et al., 2015). RCA applies not only to business processes but also to identifying root causes of product defects. One of the most common RCA techniques is the Why-Why (5 Whys) diagram, a tree-like method. It involves repeatedly asking, “Why does this happen?”, typically at least five times, until plausible contributing factors are identified and can be analyzed further. Figure 4 - Why-Why Diagram Source: (Murugaiah et al., 2010)
38 It is important to understand that this technique is dependent on the biases of the participants. Ayad et al. (2010) present a case where a manager applied it after multiple customer complaints about wrong product delivery, gathering the Human Resources Manager, the Assistant Manager, and the involved employee. After asking why the product was delivered incorrectly to the different participants, the responses were contradictory. The Human Resources Manager attributed the root cause to the Assistant Manager. The Assistant Manager attributed the root cause to outdated training materials provided to the employee. This suggests that the Why-Why diagram’s accuracy depends on the critical thinking of both the analyst and the interviewees. Cause-effect diagrams describe, graphically, the relationship between a certain outcome and all the factors that influence it, helping to identify, sort, and display causes of a specific problem or quality characteristic (Ahmed & Ahmad, 2011). They provide a means to identify root factors, define risk reduction strategies, and develop action plans. Dumas et al. (2018) present an example categorization for the cause-effect technique, the 6Ms: Table 1 – 6 M’s Cause-Effect diagrams Source: Adapted from (Dumas et al., 2018)
39 Each factor targets a potential area where the issue may originate. The Machine category covers technology-related factors, such as system crashes in information systems, network or device failures, configuration errors, or redundant data across systems. The Method category includes factors arising from how processes are understood and performed; examples include lack of communication, unclear decisionmaking authority, missing or ambiguous SOPs, inadequate handoffs, and excessive process variability. Material factors stem from raw materials, consumables, or information; when mishandled or of poor quality (e.g., incomplete, outdated, duplicated), they can cause issues. The Man/Person category captures people-related factors such as mishandled steps, insufficient skills or training, workload and fatigue, unclear roles, and misaligned incentives. Measurement factors relate to errors in how performance is measured, including miscalculations, unsuitable or missing KPIs, poor calibration, sampling bias, and delayed feedback. Milieu factors arise from the environment in which the process is executed, including influences from external actors (customers, suppliers), regulations, market shifts, seasonality, physical conditions, and organizational culture. These categories serve as guidelines rather than rigid rules; different categorizations fit different contexts. In service settings, the 4S framework, Surroundings, Suppliers, Systems, Skills, can be used instead (Dumas et al., 2018).
40 Figure 5 - Cause-Effect DiagramSource: (Coccia, 2018) When these techniques are applied and the root factors behind a given issue are identified, it is important to understand the impact of those same issues and prioritize them. To do this, an Issue Register can be created. In this register multiple fields can be presented. Generally, these fields consist of the name of the issue, description, priority, assumptions, qualitative impact, and quantitative impact, however other fields can be added to the issue register to adapt it to specific situations and different realities.
41 Table 2 - Example of an Issue Register Source: Adapted from (Dumas et al., 2018) The name of the issue should be concise and understandable by every participant, the description should also be short and focused on the issue and not the impact, the priority field represents the level of importance of the issue about others, assumptions are any data used in the estimation of the 18 impact, qualitative impact describes the intangible impact that is difficult to quantify, and quantitative impact is an estimate of either time loss, revenue loss, avoidable costs, etc. (Schwegmann & Laske, 2010; Dumas et al., 2018) Schwegmann & Laske (2010) defend that the issue register should be done at the same time as the as is business process models in the discovery phase since during this phase, multiple issues will be raised and the registration of these issues can be a starting point, even though most of the time the issue register would be left incomplete.
48 Figure 7 - Devil’s Quadrangle. Source: Adapted from (Reijers & Mansar, 2005) Dumas et al. (2018) defend that there are multiple process redesign methods, and each method falls in a particular category. Dumas et al. (2018) present an illustration of a redesign orbit delimiting each redesign method into having an ambition, be it transactional methods or transformational methods, nature, creative or analytical, and a perspective, inward-looking or outward-looking. This illustration can be seen in figure 8. Figure 8 - The Redesign Orbit Source: Dumas et al. (2018)
49 Transactional methods generally look at the issues in a process and aim to resolve them incrementally while not changing the current process structure. On the other side of the spectrum, transformational methods aim to reach breakthrough innovation while considering the fundamental core and principles of the current process structure. Relating to the nature of the methods, these can be either analytical or creative. Analytical methods are characterized by a strong link to a mathematical basis and quantitative analysis and techniques. While creative methods rely upon the human creative power, building on the advantages of group dynamics. Finally, when it comes to perspective, inward-looking methods are the ones that consider the process from the internal organization’s perspective, focusing on defined objectives and performance measures. Outward-looking methods take the perspective from an outsider of the process, often in the form of a customer or supplier (Dumas et al., 2018). The Heuristic Process Redesign uses a list of redesign heuristics to evaluate and identify possible improvements to the “as-is” business model. The different dimensions (time, cost, quality, and flexibility) have different heuristics that affect them directly. Some of these heuristics, which were mainly considered during the internship project, are as follows (Reijers & Mansar, 2005; Dumas et al., 2018): • Time dimension • Parallelism: consists of putting tasks in parallel, which can reduce time. • Order-based work: removing batch-processing and periodic activities when possible. • Cost dimension
50 • Elimination: removing non–value-adding activities and tasks from the process. • Empower: reducing middle management and giving process participants more authority and decision-making power. • Quality dimension • Triage: applying either specialization or generalization of tasks as appropriate. • Specialization: dividing a general task into two or more alternative tasks. • Generalization: integrating two or more alternative tasks into one general task. • Flexibility dimension • Centralization: treating geographically dispersed resources as if they were centralized to be able to commit them in a more flexible way. 2.2.5. Process Implementation The implementation phase of the BPM lifecycle encompasses different methods to transform the created conceptual process models into executable models. Dumas et al. (2018) suggest that the first step for process implementation is to identify each task’s type, to either automated, manual, or user. A user task is any task that the participant of a manual task can notify the system upon task completion using the worklist handler of the system. Review then the manual tasks to understand the possibilities of integration with the system, removing the elements that cannot be interpreted by the system. Then it is necessary to complete the process model by stating the relevant control-flows and data aspects for execution. All electronic data objects required as inputs and outputs by the tasks need to be specified. The next step is transforming the resulting model into one with a granularity level adequate for execution,
51 e.g., tasks may be too abstract, needing decomposition, or too detailed, needing aggregation. Finally, specify the way each model element is implemented in the system. Some execution properties are variables, messages, data mappings, script tasks, etc. An important note to take is that all the implementations being taken cannot have a major disruption in the business's daily activities, and it is of great difficulty to have many changes simultaneously. 2.2.6. Process Monitoring and Control It is not the rule to have the implementations of the redesigned business process meeting the initial expectations. Here is where the phase of monitoring and control takes place. It is necessary to understand what is happening during process execution and evaluate the previously defined process performance measures. In other words, process monitoring and control focus on the gathering of insights about the performance of the process by aggregating the process metrics to Process Performance Indicators and Key Performance Indicators and revealing differences and variations between the “as-is” and “to-be” models. (Schmidt & Fleischmann, 2013). The main business process monitoring techniques consist of statistics-based techniques (i.e., Performances Dashboards), and model-based techniques (i.e., Process Mining). There are several types of dashboards, including operational, tactical, and strategic dashboards. Each dashboard aims at different levels of the organization. Operational process dashboards focus on the process workers and operational managers, having a
52 weight on monitoring the work-in-process and resource loads. Tactical dashboards are targeted at process owners, with an emphasis on analysis of process performances, reviewing the cycle times and error rates. Strategic dashboards are aimed at the higher level in the organization (executives), providing statistical information about the link between the process performance and the strategic objectives. Most BPMS, CRM, and ERP systems offer the tools for the creation of these dashboards. (Dumas et al., 2018) Process mining is another set of techniques for performance evaluation and analysis. It is based on event logs produced during the business process execution, allowing for a more in-depth comprehension of how the process is being executed with details down to a task level. Dumas et al. (2018) list four use cases for process mining techniques classification: • Automated process discovery • Conformance checking • Performance mining • Variant analysis Taymouri et al. (2021) explains that automated process discovery, as mentioned earlier in the discovery phase, takes event logs to produce business process models that match the behavior in those same event logs. Conformance checking compares a given process model with the event logs to give insights into the differences between the two. Performance mining also takes both the event logs and business process model to create an “enhanced process model”, containing elements that help in search of issues, i.e., bottlenecks. The variant analysis takes two different event logs and compares them,
53 presenting a list of their differences. In general, one of the event logs represents the positive cases, and the other represents the negative ones. Figure 9 - Process Mining Techniques Source: Dumas et al. (2018) 2.3. ENTERPRISE PROCESS MANAGEMENT EPM is the holistic system resulting from multiple BPM projects inside an organization, providing a governance model for managing these initiatives and assuring the alignment between them and the organization’s business strategies (ABPMP, 2013). A framework that outlines the elements of BPM can become an essential tool for strategic challenges due to an allowance for task allocation priorities and timeliness of the progression of the several BPM elements (Brocke & Rosemann, 2015).
54 Brocke & Rosemann (2015) have listed six core elements that represent a critical success factor for BPM: • Strategic alignment • Governance • Methods • Information Technology • People • Culture Since processes need to be designed and managed according to certain priorities and situations, strategic alignment represents the link between the organizational priorities and enterprise processes to maintain an effective improvement of its performance (Brocke & Rosemann, 2015). The governance of BPM establishes roles, responsibilities, and accountabilities for the levels of BPM. The methods used in the context of BPM need to be defined and coherent with the organization’s reality and objectives. Information Technology is a significant enabler of BPM projects, being it on process analysis and also for process modeling and monitoring. A BPM project is also dependent on the people that apply it. These people need to continuously enhance and use their skills and knowledge to improve their business performance. Finally, culture represents the collective groups of people and has a high impact on BPM initiatives. Culture is about creating an acceptance of BPM in the organization’s environment (Brocke & Rosemann, 2015). Brocke & Rosemann (2015) also present a table demonstrating these core elements in the literature for further reading and review. This table can be seen in table 3.
55 Table 3 - BPM core elements in the literature. Source: Brocke & Rosemann (2015) 2.3.1. Business Process Governance Business Process Governance (BPG) aims to create the structures, metrics, roles, and responsibilities to manage the performance of the business processes and the BPM projects. The need for governance comes from the existence of an organizational design. Spanyi (n.d.) states that there are three main reasons for companies to struggle in the execution of large BPM projects. Lack of a robust framework, lack of codification of management practices, and resistance to change from the participants and executives. Bruin (2009) has identified capability areas for the multiple BPM core elements.
56 These capability areas are shown in figure 10 below: Figure 10 - BPM Capability Framework Source: Bruin (2009) ABPMP (2013) provides a shortlist of typical roles in BPG. The process manager who monitors the activities in the process, helping in the identification of issues and recommends improvement actions, the process change manager that has the role of presenting improvement measures and controlling the impact of changes, and the process consultant that are experts in the control of the process changes and its standards. 2.3.2. Maturity Model A maturity model is a technique that aims to evaluate and measure different aspects of a process, or organization in general, consisting of some maturity levels (Becker et al., 2009). Proença & Borbinha (2016) state that this technique can provide organization:
57 • A measuring for auditing and benchmarking • A measuring of process assessment against objectives • An understanding of strengths, weaknesses, and opportunities There have been multiple proposed BPM maturity models, Brocke & Rosemann (2015) have identified and listed some of these: • Process Condition Model 29 • Strategic Alignment Maturity Model • BPR Maturity Model • Harmon’s BPM Maturity Model • Rummler-Brache Group’s Process Maturity Model • OMG’s Business Process Maturity Model • Rosemann and de Bruin’s Maturity Model • Capability Maturity Model Integration (CMMI) • Hammer’s BPM Maturity Model (Process Audit) Despite the existence of several proposed maturity models, this paper will have only an overview of CMMI, which serves as a base for several other maturity models, being in the nomenclature and different maturity levels, Rosemann and de Bruin’s Maturity Model (BPMMM), and the Object Management Group Maturity Model (BPMMOMG). 2.3.2.1. Capability Maturity Model Integrated CMMI comes from a first version, the Capability Maturity Model (CMM). This capability model was developed by the Software Engineering Institute, with the goal of
64 Figure 12 - Rosemann and de Bruin’s BPMMM Source: Rosemann and de Bruin (2005) The nomenclature of each stage is consistent with those of CMM. This decision was made due to their previous acceptance of them. Each maturity stage description varies depending on the considered factor. However, the definition of each stage of maturity to each factor is based on incorporating the six criteria above, using quantifiable indicators to ensure comparability of stages (Rosemann and de Bruin, 2004). 2.3.3. BPM Context Framework Proposed by vom Brocke, Zelt, and Schmiedel (2015), the business process management context framework consists of a framework that allows for the assessment of an organization characteristics and factors in order to describe a BPM project, enabling the organization to have a better 34 understanding of itself and of the project, and with that, aligning the project to the organization. (vom Brocke & Mendling, 2018).
65 The framework is divided into four different dimensions, assessing the goal, process, organization, and environment. Each dimension represents a contextual factor, and the goal dimension tackles what the organization wants to achieve when implementing a BPM project. In the context of BPM, goals can be either exploitation or exploration. Exploitation BPM approaches aim to take advantage of already implemented and established tools and management approaches to increase the process efficiency. In contrast, exploration approaches have a focus on innovative processes through different creative techniques (vom Brocke, Zelt, & Schmiedel, 2015). BPM initiatives need to be adapted to the type of process that is receiving it, vom Brocke, Zelt, and Schmiedel (2015) list several process characteristics that influence the effectiveness of these initiatives, such as the process’s value contribution (core, management, or support processes), the repetitiveness of the process, its knowledge intensity, degree of creativity, interdependence between the processes and the process variability. The organizations themselves also present a set of characteristic processes that can cross organizational boundaries. Therefore, it is necessary to assess their scope of being either inter or intra organizational. Organizational size also plays an essential role in this assessment. Different sized organizations have different levels of depth in their processes, e.g., larger organizations might present processes that need more standardization and formalization than small organizations. (vom Brocke, Zelt & Schhmiedel, 2015). Another essential characteristic is the type of industry being assessed since it is not guaranteed that each BPM practice is equally effective through either product or service-oriented organizations. Vom Brocke, Zelt, and Schmiedel (2015) also state that a BPM approach is
66 more likely to succeed if the correct cultural values are in place. These can be having customer orientation, teamwork, and high degrees of responsibility. Finally, organizational resources present an essential aspect when applying a BPM initiative due to the need to allocate resources such as investments in information technology. The last dimension mentioned by the authors is the environmental dimension. This dimension handles the level of competitiveness and uncertainty in the surrounding environments of the organization. 2.3.4. City of Ghent - Case Study Overview This case study, covered by Van Looy & Rotthier (2018), focuses on applying a BPM approach to a public-sector organization in the city of Ghent, Belgium. The identified issue of the organization was that the different departments had a “silo” mentality, in the sense that the different chains, namely, 35 the taxes, environment, and civic affairs, all required separate customer profiles. The City of Ghent already had previously implemented web forms, all developed by the same IT supplier. However, their use was lower than the ideal, with around forty digital tax submissions per year. Some web forms were also browser-dependent, which resulted in several customer complaints. Even if the forms were processed from the web, their handling in the back office was entirely manual. The City of Ghent also had some downloadable forms that required the customers to download, print, and physically deliver them. Previously the City of Ghent already had some digital initiatives, namely, featuring intuitive search functionalities, integrating more advanced search functionality, and
67 basing the website on Search Engine Optimization, allowing customers to reach the desired forms directly from a search engine, such as Google. After the first analysis, the BPM team identified a set of needs. Some were a need for a more customer-oriented and uniform way of working, the need to have a higher return of investment (ROI) from the IT projects, and reuse of digital investments. The BPM consisted of two project managers, a business process manager, and an IT project manager that would work closely with each other. The business project manager would then work as a link between the departments undergoing the transformation and the organization that offers technical support, considering the interest of the whole organization to counter the silo effects. There were, however, some constraints for the project, high privacy concerns relating to governmental regulations, a limited budget, requirements that stated that physical process channels would still need to exist, independently of the desired digital channels, the services and processes had little to no degrees of freedom due to specified legislation, the type of services and customers were very heterogeneous (around 300 products and very different profiles of customer), and there was an intrinsic historic of working in silos. A set of objectives were defined to fulfill the needs mentioned previously. This was to standardize the way to authenticate the users, enable electronic signatures, and provide information and forms regarding the e-services online through any browser and device. The initial plan was to have a focus on both physical and digital service deliveries. This would include integration with both the City’s external partners and through its departments. This case study can be situated through the typical lifecycle of a business process management initiative. For the process identification, process analysis, and
68 process redesign phases, models of the core business processes using BPMN were created, allowing for a better visual representation of their instances. The main 36 analysis techniques followed the principles of Lean, specifically waste analysis. As mentioned previously in the literature review, these analyses provided a higher understanding of the issues and aimed at reducing, and if possible, eliminating waste through the process. For the process implementation stage, it was decided to use service-oriented architecture for the reuse of service components and to create a common architecture. This case study demonstrates a link between different BPM core elements, e.g., the strategic alignment can be associated with the focus on a digitization vision that focuses on a taken advantage of a more efficient set of processes based on top-down coordination and planning. The initial perception of this initiative what that of a job-threatening one, employees were afraid of these likely changes, and how they would negatively affect their work. However, due to sound management changes, their minds were slowly changed to understand how IT could help make their workload easier to handle. Since there was still a reglementary need to maintain the physical alternatives, this resistance was also countered to some extent. A BPM maturity assessment was made some years back. However, it was discontinued due to high costs and different process visions, focusing on entire process portfolios instead of specific processes. With this BPM initiative, the city intended to relaunch this assessment and idea of process-oriented working methods.
69 After the BPM team had an overview of the existing processes and their steps, they created fifteen different principles to which they named “building blocks”. These building blocks consist of what a public service may include as well as its maximum possible requirements. They are considered generic components to be shared across business processes. By sharing these generic components, their technological reuse is incentivized. These building blocks can be seen in figure 12 below. Some examples of these building blocks are as such: 1. Digital signature - both customer and employees present the need to electronically sign documents and validate those same signatures by verifying if the document received by the customer corresponds to the one sent by the employee. 2. Form Generator - a unique form generator to be used across any form type. Upon logging into the City’s application, the customer should be able to check their personal information prefilled in the digital form. By building forms using different technologies, multiple links would be needed per technology. By creating a single form generator, it is only needed a single technological link to the application.
70 Figure 13 - City of Ghent Building Blocks Source: Van Looy & Rotthier (2018) As a result of this approach to digitizing processes, the number of digital tax submissions and digital subsidy requests increased immediately after the actions were taken. Digital submission rose from 5.5% to 28.9%, and digital proposals from 2.6% to 35.5% of the total. The views for optimization that was in line with the Lean thinking enabled a streamlined environmental digital chain due to the elimination of unnecessary components and steps. The access to management reports derived from the digitalization approach would also allow for useful insights that support future decision-making. The implementation of digital signatures made employees not waste time and resources moving to the alderman and city secretary to sign each response letter. These time savings allowed that each customer could get the information if they get the requested subsidy, increasing customer satisfaction.
71 Based on several pilot results, the city aims to continue investing in the digitization of its services by taking advantage of these reusable components in the digital chains. The overall idea was to invest in the development a single time and avail too many areas in a maximum way. The case study closes with five different lessons learned that may benefit both other public organizations and even private organizations, these being: 1. Align with external partners semantically The city aligned its product catalog semantically with the Flemish government. With this availability of open data and a shared catalog for public services was created, allowing for an open-data source that customers and governments can use to find updated catalogs of services 2. Be pragmatic instead of dogmatic Taking a more pragmatic view can avoid new types of waste. Unnecessary bureaucracy can become arduous, and having a more practical approach can reduce time wastes. The example given by the author in this case study is that some simple documents, e.g., an online feedback sheet concerning simple questions, had specific procedure norms. To avoid superfluous procedures for each document, the city decided to create document types with respective established uniform procedures 3. Assist Departments The departments in the city lacked BPM knowledge and experience, being uncomfortable to reconsider their routines. They were then assisted by a centralized
72 competence center, which changed the perception of employees to a positive one, resulting in good employee satisfaction survey results. 4. Be open to temporary workarounds to achieve quick wins The implementation of the building blocks was considerably complex. Since this change could have a big impact on the way things were done, a simpler first version was launched as a temporary workaround. 5. Switch from silos to a single profile per customer Customers send, several times, requests to change their information, such as the telephone number or e-mail address. With multiple profiles that chance could be done to only one of those profiles, leaving other departments with outdated data. A single profile also removes the need to handle multiple names and passwords that customers had to remember for the different services and departments. With this change, the customer expectations can more easily be met. This lesson can be translated to "create a single point of contact for customer".
73 3. METHODOLOGY To achieve the established objectives, the work was structured according to the BPM methodology suggested by Dumas et al. (2018), which is mentioned in the literature review. The main phases of the said methodology with direct implementation on the internship project are Process Identification, Process Discovery, Process Analysis, and Process Redesign. The Process Implementation and Process Monitoring and Control phases are outside of the project's scope due to time constraints. However, even though there is not going to be a direct implementation of the process redesigns, there is still going to be a suggestion of actions to improve the implementation process in case the company wants to continue the project after the internship time is over. This section presents what tools and techniques are going to be used during the internship project. A practical comparison of modeling software and modeling notation is going to be presented. 3.1. INTERNSHIP SETTING The internship took place in Pakistan. Asra Soft is in multiple cities within the country. During the internship, multiple trips between these cities took place. Different process participants are in different locations, so to have closer contact to conduct interviews and observe daily activities, these trips were necessary. As mentioned in the literature review, there are multiple methods for data collection to develop the business process models. Due to not all workers of the company sharing the same workspace or even the same city, workshops were out of the scope. Therefore, the
80 Business Model & Revenue Streams: The organization generates revenue through multiple channels: 1. Technical Assistance Services (~40-45% of revenue) - Core service business 2. IT Projects & Development (~30-35% of revenue) - Custom software and implementation 3. Software Licensing (~15-20% of revenue) - Accounting and municipal information systems 4. Consulting & Training (~5-10% of revenue) - Professional services 4.2. BPM Overview in Asra Soft Context Business Process Management represents a systematic, holistic approach to understanding and improving how the organization conducts business. For Asra Soft, BPM serves to: • Identify and standardize core business processes • Quantify current performance and establish improvement targets • Apply systematic redesign methodologies • Implement technology solutions aligned with process improvements • Build organizational capability for continuous improvement
81 4.3. BPM Maturity Assessment Using the BPMN OMG Maturity Model framework, Asra Soft was assessed across multiple dimensions: Assessment Results: Asra Soft is currently at Level 1-2 (Initial/Managed) of BPM maturity: Achieved Elements: • Individual process improvement efforts with management sponsorship • Recognition of importance of BPM and continuous improvement • Initial documentation of key processes • Basic performance awareness Gaps Requiring Development: • Lack of standardized process documentation and updates • No systematic approach to process measurement and monitoring • Limited BPM expertise within organization • Absence of formal governance structure for process initiatives • No enterprise-wide process architecture alignment • Minimal automation of process execution
82 Context Framework Assessment: Dimension Characteristic Implication Goal Exploration-based Need to innovate processes through creative redesign Process Type Core process; repetitive; low-medium knowledge intensity Process suitable for systematic improvement Scope Intra-organizational; service-oriented Process can be optimized within current organizational boundaries Organization Small (50-75 employees); medium BPM support; resources available Feasible implementation with appropriate resource allocation Environment Low-medium competition; stable market; low uncertainty Favorable conditions for process transformation Table 5 - Asra Soft BPM Context Framework. Source: Made by the author 5. PROCESS PROJECT 5.1 Process Identification & Overview of Candidate Processes Process Discovery Methodology: The organization-wide process identification was conducted through: • Review of existing documentation (10+ years outdated) • Executive management interviews • Department-level process participant meetings
83 • Process relationship mapping exercises Processes Identified: 27 Total Organizational Processes The organization operates 27 distinct business processes classified as: Core Processes (7): • Technical Assistance • Commercial Prospection • Sales Proposal Creation • Sales Process • Post-Sale Services • External IT Projects • External Training Support Processes (13): • Internal IT Projects • Internal Training • Infrastructure & Equipment Maintenance • Outsourcing Management • Purchasing • Human Resources • Recruitment
84 • Employee Payments • Accounts Payable • Accounts Receivable • Storage • Logistics • Supplier Relationship Management Management Processes (7): • Corrective & Preventive Actions • Accounting & Finance • Quality Management • Strategic Management • Document Control • Complaints Handling • Organizational Performance Management 5.2. Process Selection & Deep Dive Selection Criteria: Given organizational constraints (limited resources, BPM expertise, time), prioritization was required. Criteria applied:
85 Criterion Weight Justification Importance (Strategic Impact) 40% Revenue generation and customer impact Health (Current Issues) 35% Performance gaps and improvement potential Feasibility (Implementation) 25% Complexity and organizational readiness Table 6 - Process prioritization criteria, weights, and justification for BPM initiative. Source: Made by the author Candidate Processes Evaluated: Process Importance Health Feasibility Weighted Score Ranking Technical Assistance 45/50 (90%) 30/50 (60%) 40/50 (80%) 8.1/10 1st - SELECTED Sales Process 50/50 (100%) 35/50 (70%) 20/50 (40%) 7.1/10 2nd External IT Projects 40/50 (80%) 25/50 (50%) 35/50 (70%) 6.3/10 3rd Complaints Handling 35/50 (70%) 20/50 (40%) 38/50 (76%) 5.5/10 4th Table 7 - Prioritization scores and ranking of candidate Asra Soft processes for BPM intervention. Source: Made by the author
86 Selection Justification: The Technical Assistance process was selected as the optimal candidate for this BPM initiative because: 1. High Strategic Importance: Generates 40-45% of company revenue; core to competitive positioning 2. Moderate Health Challenges: Documented issues in coordination, response times, and quality consistency 3. High Feasibility: Well-defined boundaries; concentrated in specific departments; clear metrics available 4. Implementation Advantages: Successful improvement could be replicated to other processes 5. Stakeholder Commitment: Strong executive sponsorship for this process improvement 6. Learning Opportunity: First BPM project serves as proof-of-concept for organizational capability building 5.3. Process Discovery: AS-IS Model Process Boundaries: • Trigger Event: Customer initiates contact with a need OR internal staff identifies a required service • Termination Event: Issue is fully resolved and documented OR customer accepts deferral/suspension
87 • Primary Actors: Administrative Assistant, Technician, Management • Secondary Actors: Customer, Supplier • Duration: 1 hour to 5 days (depending on complexity and customer availability) Process Scope: The Technical Assistance process encompasses all activities from initial customer contact through resolution including: • Software maintenance and support • Hardware repair and maintenance • System installation and configuration • Accounting software support • Remote and on-site technical services High-Level Process Flow: Figure 14 - Issue-to-resolution As-Is process model Source: Made by the author
88 The current AS-IS process consists of: • 53 distinct activities organized into 4 main stages • Multiple decision points determining workflow variations • Significant manual steps for data entry, documentation, and communication • Geographic and functional handoffs across departments and locations Process Participants & Roles: Role Responsibility Location(s) Customer Initiates service request; provides information; receives resolution Multiple cities Administrative Assistant Initial contact; ticket creation; scheduling; communication Karachi (primary) Technician Service execution; technical problemsolving; on-site visits Multiple cities Management/Supervisor Oversight; exception handling; performance monitoring Karachi (primary) Finance Cost tracking; billing; payment processing Karachi Table 8 - Roles, responsibilities, and locations of key participants in the Technical Assistance process. Source: Made by the author
89 6. TECHNICAL ASSISTANCE PROCESS ANALYSIS 6.1. Data Collection & Analysis Methods Data Collection Techniques Applied: 1. Evidence-Based Discovery: • Document analysis of existing process documentation • Observation of 25+ service instances over 2-month period • System and archival record review • Historical data analysis from manual logs 2. Interview-Based Discovery: • Individual interviews with 8 process participants • Structured interviews capturing: o Average activity durations o Common issues encountered o Bottleneck identification o Improvement suggestions • Multiple rounds of validation with different stakeholders 3. Workshop-Based Discovery: • Process refinement sessions with technical staff • Cross-functional review meetings with management
96 Issue #1: Could Not Contact Client (32% of issues) Why Chain: 1. Why can't we contact client? → Contact information outdated or incorrect 2. Why is info outdated? → No systematic validation during registration 3. Why no validation? → Manual process prone to errors 4. Why manual? → No automated verification system 5. Why no system? → Legacy systems lack integration capability Root Causes Identified: • Manual contact information entry • Lack of contact validation procedures • No automated follow-up system • Single point of contact (customer often unavailable) 6Ms Analysis: • Machine: No automated contact verification system • Method: Ad-hoc contact approaches; no standardized protocol • Material: Outdated contact information database • Man: Limited training on contact protocols • Measurement: No KPI for contact success rate • Milieu: Customer availability constraints (external factor)
97 Issue #2: Mistakes in Information (28% of issues) Why Chain: 1. Why data entered incorrectly? → Manual data entry from handwritten notes 2. Why handwritten notes? → No system capturing information in real-time 3. Why no real-time capture? → Multiple entry points for same information 4. Why multiple entry points? → Systems not integrated 5. Why not integrated? → Legacy systems incompatibility; lack of budget Root Causes Identified: • Duplicate data entry points • No automated validation • Technician fatigue from manual work • Lack of standardized data entry templates • Multiple systems with different formats Issue #3: Manpower Shortage (20% of issues) Why Chain: 1. Why technicians unavailable? → No visibility of workload and availability 2. Why no visibility? → No scheduling system; manual ad-hoc assignment 3. Why manual assignment? → Limited BPM maturity; no process tools
98 4. Why no tools? → Resource constraints; lack of awareness 5. Why lack of awareness? → No BPM expertise in organization Root Causes Identified: • Inadequate workforce planning • No real-time visibility of resource availability • Inefficient scheduling methods • No load-balancing mechanism • Geographic distribution challenges Cause-Effect (Fishbone) Diagram Figure 15Cause-effect diagram Source – Made by the author.
99 6.6. Pareto Analysis Issue Prioritization Using Pareto Principle: Issue Category Frequency % of Total Cumulative % Client Contact Failure 24 32% 32% Information Entry Errors 21 28% 60% Manpower Shortage 15 20% 80% Supplier Delays 10 13% 93% Forgotten Orders 5 7% 100% Table 12 - Issue prioritization using the Pareto principle for the Technical Assistance process. Source: Made by the author Pareto Principle Application: The analysis demonstrates the 80/20 principle: approximately 80% of process problems (60 issues) are caused by just 3 of the 5 issue categories (80% line). Therefore, improvements should focus on these three high-impact categories. 7. AS-IS PROCESS SIMULATION Simulation Scenario: Current Resource Allocation (2 Technicians, 1 Admin) Using Bizagi Modeler simulation capabilities with historical performance data: Performance Metrics: • Average WIP (Work-in-Process): 8-12 service requests
100 • Average Wait Time: 45-60 minutes • Throughput Capacity: 40-50 instances/month • Resource Utilization: 68% • Cycle Time Variance: ±20-30 minutes • Customer satisfaction average: 60/100 Simulation Findings: Current capacity is near maximum with 2 technicians. Any increase in demand will result in service delays unless process efficiency improves or resources are added. Peak Demand Scenario Analysis: Under peak demand conditions (15-18 WIP items): • Average Wait Time: 2-3 hours • Resource Utilization: 92-95% • Service Quality Degradation: Significant • Customer Satisfaction: Below acceptable threshold Figure 16 shows the Bizagi AS‑IS simulation model used to evaluate current performance under normal and peak demand conditions.
101 Figure 16 - AS‑IS Bizagi simulation model of the Technical Assistance process under current capacity. Made by the author. 8. PROCESS REDESIGN: TO-BE MODEL 8.1. Heuristic Redesign Approach Figure 17 illustrates the redesigned Technical Assistance process, highlighting where each heuristic (H1, H3, H4, H5, H9) is applied along the workflow. Methodology: The TO-BE process was developed using Heuristic Process Redesign methodology, applying six key redesign heuristics systematically: Heuristic 1: Task Elimination (H1) – Remove Non-Value-Adding Activities • Remove non-value-adding activities without business justification
102 • Applied to: Manual PIT creation for small jobs, unnecessary travel to archives, redundant printing, manual file organization • Impact: Eliminates 23 NVA activities; saves 48 minutes per cycle Heuristic 2: Triage - Generalization (H3) – Treat Services Uniformly • Eliminate decision branching based on arbitrary criteria • Applied to: Eliminated "small work" vs "large work" decision point; standardized all services through same workflow • Impact: Simplified workflow; reduced decision complexity; improved consistency Heuristic 3: Re-sequencing (H4) – Reorder Tasks to Optimize Flow • Reorder activities to enable parallelism and reduce handoff delays • Applied to: Move material analysis before technician travel; obtain client approval for quotes before site visit; schedule service immediately after assessment • Impact: Enables parallel processing; reduces cycle time by compression Heuristic 4: Parallelism Enhancement (H5) – Execute Tasks Simultaneously • Execute independent tasks in parallel rather than sequential processing • Applied to: Client contact and scheduling in parallel; system data entry alongside service execution; admin assignments during client communications • Impact: Reduces cycle time through concurrency; better resource utilization Heuristic 5: Automation (H9) – Use Technology to Replace Manual Processes • Automate routine, rule-based activities
103 • Applied to: Automated ticket creation from multiple channels; system-based technician assignment; automated customer notifications; real-time data entry; automated cost calculations; system-based document management • Impact: Eliminates manual errors; reduces labor time; improves consistency Heuristic 6: Technology-Enabled Specialization/Generalization • Leverage system capabilities to reduce cognitive load while maintaining process quality • Applied to: Complex logic handled by system rules; staff focus on service delivery; system automation of routine checks • Impact: Improved staff focus; higher quality decisions; better efficiency Figure 17 - Heuristic‑based TO‑BE model of the Technical Assistance process (H1, H3, H4, H5, H9 highlighted). Made by the author.
104 8.2. Developing TO-BE Process Figure 18 presents the redesigned TO‑BE BPMN model for the Technical Assistance process, integrating the heuristics described in Section 8.1 and the improvements detailed in Sections 8.2.1 - 8.2.7. Figure 18 - TO‑BE BPMN model of the redesigned Asra Soft Technical Assistance process. Made by the author. Key Improvements in TO-BE Model: 8.2.1. Automated Ticket Entry from Multiple Channels Before (AS-IS): • Manual entry by administrative assistant • Phone calls captured verbally with transcription errors • Email requests forwarded with manual interpretation • Single entry point creates bottleneck
105 After (TO-BE): • Email auto-parsed to ticket system • Web form for self-service requests • Phone system creates automatic ticket record • System automatically assigns to appropriate team based on rules Benefit: Eliminates 5 minutes of manual entry; reduces errors by 70%; immediate capture of customer information 8.2.2. System-Based Information Management Before (AS-IS): • Customer data scattered across multiple systems • Handwritten notes in PIT files • Digital records in separate accounting system • Duplicate data entry required for different processes • Version control issues; outdated information After (TO-BE): • Centralized customer database • Real-time access to service history • Automatic notifications to all parties • Single entry, multiple system access • Complete audit trail and version history
112 • Better retention (25% satisfaction improvement) = estimated 10-15% churn reduction • Additional Monthly Revenue: PKR 12,500+ • Annual Revenue Impact: PKR 150,000+ Total Financial Benefit (Year 1): • Cost Savings: PKR 126,000 • Revenue Enhancement: PKR 150,000+ • Total Benefit: PKR 276,000+ Investment Required: • ODOO ERP System: PKR 80,000-100,000 (one-time) • Implementation & Customization: PKR 40,000-60,000 (one-time) • Training & Change Management: PKR 10,000 (one-time) • Monthly License/Support: PKR 5,000 • Total Year 1 Cost: PKR 210,000-240,000 • Year 2 Ongoing Cost: PKR 60,000 (licenses + support) ROI Calculation: • Year 1 Net Benefit: PKR 276,000 - PKR 225,000 = PKR 51,000 • Payback Period: 9-10 months • Year 2 ROI: (PKR 276,000 - PKR 60,000) / PKR 60,000 = 360%
113 9. TASKS COMPLETED IN VARIOUS UNITS 9.1. Administrative Department Tasks Process Analysis & Mapping: • Identified all administrative activities in Technical Assistance workflow • Mapped responsibilities and handovers with other departments • Documented current procedures and identified pain points • Created detailed activity descriptions Issue Analysis & Documentation: • Analyzed administrative errors and bottlenecks • Identified data entry error sources and frequency • Documented client contact challenges and failure patterns • Participated in Issue Register creation System Design & Configuration Participation: • Participated in Helpdesk system design requirements gathering • Defined ticket creation rules and routing logic • Configured automatic assignment rules • Designed custom fields for administrative tracking • Created workflow templates aligned with current procedures Testing & Validation: • Conducted User Acceptance Testing (UAT) for ticket management workflows
114 • Tested email integration and form submission processes • Validated data entry screens and procedures • Provided feedback on admin interface usability • Participated in UAT sign-off documentation Process Redesign Contribution: • Identified opportunities to reduce manual tasks • Suggested automation points aligned with current workflows • Participated in TO-BE process design sessions • Validated feasibility of proposed workflow changes Deliverables: • Detailed workflow documentation • Issue log with administrative root causes • System configuration specifications • UAT test results and sign-off • Staff feedback for TO-BE design 9.2. Technical Department Tasks Current Process Analysis: • Documented current service execution procedures and variations
115 • Identified technical challenges and bottlenecks • Provided accurate time estimates for service activities • Suggested technical improvements and innovations • Documented skill requirements for different service types Data Collection & Validation: • Participated in observation sessions of service delivery • Provided accurate time data for activities • Documented common technical issues encountered • Shared field insights and environmental constraints • Identified geographic and logistical challenges AS-IS Model Validation: • Reviewed BPMN AS-IS model for accuracy • Identified missing activities or decision points • Clarified complex technical procedures • Validated activity sequences and dependencies • Provided examples of service variations Workflow Design Participation: • Reviewed proposed TO-BE workflow • Identified feasibility concerns and constraints • Suggested practical process improvements
116 • Validated effectiveness of redesigned procedures • Identified training requirements for new processes Mobile Application Testing: • Tested Field Service mobile interface in field conditions • Provided feedback on usability and functionality • Identified missing features or capabilities • Tested offline functionality and data synchronization • Provided recommendations for app improvements Training & Rollout Preparation: • Participated in comprehensive training sessions • Tested mobile app functionality under real conditions • Provided peer training to other technicians • Identified support needs and troubleshooting procedures • Documented quick reference guides for field use Deliverables: • Detailed service execution procedures documentation • Time and effort data for activities • Technical feasibility assessment • Mobile app feedback and improvements
117 • Training completion records • Field operation guidelines 9.3. Finance/Accounting Department Tasks Cost Analysis & Baseline Establishment: • Documented current cost structure per service instance • Tracked labor costs and allocation methods • Analyzed material costs and wastage • Quantified overhead allocation • Established baseline metrics for comparison Financial Impact Modeling: • Worked with project team on ROI calculations • Contributed to cost savings projections • Validated financial assumptions • Analyzed payback period scenarios • Contributed to business case development Billing & Invoice Configuration: • Worked with ERP team on invoicing system setup • Defined billing rules and triggers
118 • Set up cost tracking by service type • Configured financial reporting parameters • Tested invoice generation procedures Budget Planning & Approval: • Reviewed implementation budget requirements • Approved budget allocations for software and consultants • Managed approval process for training expenses • Tracked implementation spending against budget • Prepared financial reports for management Financial Reporting: • Prepared baseline financial metrics report • Created cost comparison documentation • Generated ROI analysis and projections • Prepared financial benefits tracking methodology • Documented measurement procedures Deliverables: • Cost baseline documentation • ROI analysis and financial projections • Budget approval documentation • Billing system configuration specifications
119 • Financial tracking procedures manual • Post-implementation measurement plan 9.4. Management/Supervisory Tasks Strategic Alignment & Sponsorship: • Defined overall improvement objectives for the process • Participated in prioritization decisions among candidate processes • Approved process redesign approach and methodology • Established governance structure for implementation • Provided executive sponsorship and support Resource Planning & Allocation: • Allocated staff to implementation activities • Managed training schedules and priorities • Resolved resource conflicts and competing demands • Ensured adequate staffing for business continuity • Supervised implementation team composition Change Management & Communication: • Sponsored the BPM initiative publicly • Communicated vision, mission, and benefits to staff
120 • Addressed staff concerns and resistance • Facilitated stakeholder alignment • Monitored change adoption and engagement Oversight & Governance: • Established steering committee for project oversight • Participated in weekly status review meetings • Made key implementation decisions • Monitored adherence to timeline and budget • Escalated issues and risks to executive level Performance Monitoring & Reporting: • Established baseline performance metrics • Monitored implementation progress against plan • Reviewed KPIs and performance dashboards • Reported progress to executive leadership • Identified and resolved implementation obstacles Future Planning: • Planned for Phase 2 process improvements • Identified opportunities for process portfolio optimization • Discussed organizational BPM capability development • Developed long-term process improvement strategy
121 • Planned for continuous improvement culture Deliverables: • Project governance structure and charters • Steering committee meeting minutes and decisions • Project status reports and dashboards • Risk and issue logs with mitigation plans • Budget tracking and approval documentation • Staff communication plans and materials • Post-implementation monitoring plan 10. IMPLEMENTATION PLAN 10.1. Software Implementation (ODOO ERP) Software Selection Rationale: ODOO ERP was selected based on comprehensive evaluation against these criteria: Criterion Weight Rationale Modularity 20% Incremental implementation reduces disruption Ease of Use 20% Minimal training required for SME scale Customization 15% Flexibility without heavy coding requirements Cost 25% Affordable for organization size; scales with growth Support 10% Active community; professional support available
128 • Set up materials and inventory items • Create work order templates • Configure mobile app access and permissions • Set up route optimization parameters Studio Customization: • Design custom fields for technical requirements • Create automated workflow rules • Design service report templates • Implement conditional logic • Configure dashboard views for operations Deliverables: • Configured Helpdesk with sample tickets • Configured Field Service module • Custom documents and workflow rules • Comprehensive configuration documentation • Role-based user manuals • System administrator guide Resources: 3 ODOO specialists, 2 internal key users Key Milestone: Configuration review and sign-off
129 PHASE 3: TESTING & REFINEMENT (Weeks 6-7) Objectives: • Conduct User Acceptance Testing (UAT) • Refine configurations • Validate system functionality User Acceptance Testing (UAT): • Admin staff test ticket creation workflows • Technicians test mobile app functionality • Test email integration end-to-end • Test SLA tracking and alerts • Test report generation • Validate data accuracy and completeness Issue Resolution: • Compile UAT feedback and issues • Refine configurations based on feedback • Adjust workflows and rules • Retest refinements and fixes Pilot Data Entry: • Create 20-30 sample tickets
130 • Execute full workflow from creation to closure • Identify issues and edge cases • Refine procedures and training Deliverables: • UAT results and sign-off documentation • Issue log with resolutions • Refined configuration specifications • Pilot data sets in system • Refined user procedures Resources: 5-6 internal staff (cross-functional), 2 ODOO specialists Key Milestone: UAT sign-off and readiness for training PHASE 4: TRAINING & CHANGE MANAGEMENT (Weeks 8-10) Objectives: • Conduct role-based training • Implement change management • Prepare for pilot go-live Week 8: Administrator Training (4 hours) • System overview and architecture • Ticket lifecycle and management
131 • Team assignment and SLA management • Performance monitoring and dashboards • Report generation and analysis • System administration basics • Troubleshooting common issues • Escalation procedures Week 8: Technician Training (6 hours) • Mobile app navigation and functionality • Receiving and accepting work orders • Time and material tracking procedures • Customer communication features • Completing and closing work orders • Using GPS and photo capture features • Electronic signature procedures • Offline functionality and sync Week 8: Supervisor Training (3 hours) • Performance monitoring tools • Team management features • Scheduling and assignment interface
132 • Issue escalation and resolution • Report generation and analysis • Identifying improvement opportunities Change Management Activities: • Communication plan execution • Executive sponsorship messaging • Success stories and benefits articulation • Feedback mechanisms and support • Resistance mitigation strategies • Change adoption monitoring Go-Live Preparation: • Final system checks and verification • Backup and recovery procedure testing • Contingency plans validation • Support structure setup • Super-user identification and empowerment Deliverables: • Training completion certificates • Training materials and quick reference guides • User manuals (role-specific)
133 • Go-live readiness checklist • Contingency and backup procedures • Support contact information and escalation matrix Resources: 2 ODOO trainers, 1 change management specialist, Management Key Milestone: Training completion and go-live readiness certification PHASE 5: PILOT IMPLEMENTATION (Weeks 11-12) Objectives: • Limited rollout to single location • Real-world testing and validation • Identify implementation issues • Decision for full rollout Pilot Site Selection: • Single geographic location (Karachi primary) • All service requests through new system • Parallel running with legacy system (safety net) Pilot Operations: • Day 1-2: Intensive monitoring and support • Week 1: Daily standup meetings • Week 1: Issue identification and resolution
134 • Week 2: Performance monitoring and optimization • End Week 2: Go-live readiness review Monitoring & Support: • Daily standup status meetings • Real-time issue identification and resolution • Performance metrics collection and analysis • User feedback gathering • Troubleshooting and problem resolution Go-Live Decision Gate: • System stability verification • Performance metrics against targets • User satisfaction assessment • Issue resolution status • Formal go-live recommendation Deliverables: • Pilot week 1 and 2 status reports • Performance metrics report • Issue log with resolutions • Go-live recommendation • Lessons learned documentation
135 • Pilot success metrics Resources: Full implementation team + Pilot site staff Key Milestone: Go-live decision and approval for Phase 6 PHASE 6: FULL ROLLOUT (Weeks 13-24) Objectives: • Geographic expansion of system • Full operational transition • Ongoing support and optimization Rollout Schedule (Geographic Waves): Wave Weeks Location(s) Activities Wave 1 13-14 Karachi (primary) Staff training, data migration, testing, go-live Wave 2 15-16 Lahore Repeat Wave 1 process Wave 3 17-18 Islamabad Repeat Wave 1 process Wave 4 19-20 Peshawar Repeat Wave 1 process Wave 5 21-22 Multan & Faisalabad Repeat Wave 1 process Wave 6 23-24 Quetta, Hyderabad, Others Repeat Wave 1 process Table 15 - Geographic rollout schedule for ODOO implementation, by wave, timeline, locations, and key activities. Source: Made by the author. Each Location Rollout Includes: • Staff training (3-4 hours tailored to location)
136 • System setup and configuration • Data migration for customer base • Testing procedures and issue resolution • Go-live execution • Post-go-live intensive support (1 week) • Performance monitoring • Local optimization Ongoing Support Structure: • Help desk for system issues (email/phone) • Daily performance monitoring • Weekly performance reviews by location • Monthly optimization meetings • Continuous improvement process Deliverables: • Completion certificate per location • Performance reports per location • Issue resolution logs • Rollout completion summary • Lessons learned consolidated report
137 • Final project close-out documentation Resources: Rotating ODOO specialists, local key users, internal IT Key Milestone: Full system operational across all locations 10.3. Training Plan Training Strategy: Role-Based, Task-Centric, Progressive Approach Training Levels: Level 1: Executive Briefing (30 minutes) • Business case and improvement objectives • Success metrics and expected benefits • Timeline and resource requirements • Organizational impact and change implications • Executive support expectations Level 2: Administrator Training (4 hours) Modules: 1. System Overview (30 min) o Architecture and module overview o User interface navigation o Permissions and role setup
144 10.4. Risk Management Identified Risks & Mitigation Strategies: Risk Probability Impact Mitigation Strategy Staff Resistance to Change HIGH MEDIUM Clear communication; involvement in design; success stories; recognition program Data Migration Issues MEDIUM HIGH Thorough validation; trial migrations; data cleaning; parallel running System Performance Problems MEDIUM MEDIUM Load testing; infrastructure planning; redundancy; contingency procedures Scope Creep HIGH MEDIUM Strong governance; change control process; prioritized feature list Staff Turnover During Implementation MEDIUM MEDIUM Knowledge documentation; crosstraining; retention incentives Legacy System Integration MEDIUM MEDIUM Early testing; API documentation; fallback manual processes Mobile Connectivity Issues MEDIUM MEDIUM Offline functionality; network testing; alternate communication methods
145 Insufficient Training MEDIUM MEDIUM Multiple training approaches; super-users; ongoing support Budget Overrun MEDIUM LOW Detailed budgeting; vendor cost transparency; contingency reserve (10%) Pilot Phase Delays LOW LOW Buffer time; agile approach; daily monitoring Table 17 - Identified implementation risks, their probability and impact, and corresponding mitigation strategies for the ODOO rollout. Source: Made by the author. Governance & Decision-Making: Steering Committee Structure: • Managing Director (Executive Sponsor) • IT Manager (Project Executive) • Finance Manager • Operations Manager • Key Technical Lead Meeting Frequency: • Weekly during Phases 1-5 • Bi-weekly during Phase 6 (rollout)
146 • Monthly during post-implementation (6 months) Decision Authority Matrix: • Budget overruns >10%: Steering committee approval required • Scope changes: Formal change control process • Timeline adjustments >1 week: Steering committee review • Risk escalations: Immediate steering committee meeting • Go-live decisions: Steering committee sign-off required Communication Plan: Stakeholder Group Frequency Message Topics Channel Executive Team Weekly Status, risks, decisions, budget Email + meetings Project Team Daily Priorities, issues, next steps Standup meetings All Staff Bi-weekly Progress, training dates, FAQs Email + town halls Technicians Before training Training schedule, expectations, support In-person + email Customers Monthly Service improvements, new capabilities Website, email Support Team Daily Current status, issues, procedures Slack/Teams channel
147 Key Success Factors: 1. Executive Sponsorship – Clear, visible support from leadership 2. Clear Communication – Regular, honest, transparent updates 3. Resource Commitment – Adequate staffing and budget allocation 4. Change Management – Proactive approach to resistance and adoption 5. Quality Testing – Thorough UAT before production deployment 6. Phased Approach – Manageable rollout reducing implementation risk 7. Ongoing Support – Intensive support during transition period 8. Performance Monitoring – Continuous measurement against targets 11. CONCLUSIONS ON AS-IS TO TO-BE TRANSFER 11.1. Summary of Transformation The Technical Assistance process at Asra Soft undergoes significant transformation from the current AS-IS state to the proposed TO-BE state. This transformation addresses fundamental operational challenges while improving service quality and building organizational capability for future improvements. 11.2. Key Transformation Aspects Process Architecture Change: FROM (AS-IS): • Highly manual with multiple data entry points
148 • Sequential workflow with limited parallelization • Document-centric with physical PIT documents • Reactive problem identification • Fragmented systems and manual handoffs • Limited visibility across geographic locations TO (TO-BE): • System-centric with centralized data management • Optimized flow with parallel processing • Digital-first eliminating paper documents • Proactive monitoring and escalation • Integrated platform for all information • Complete visibility across all locations Performance Impact Summary: The TO-BE design achieves transformational improvements across all performance dimensions: • 33% cycle time reduction (158 → 105 minutes) through elimination of NVA activities • 35% cost reduction (PKR 500 → PKR 325) through efficiency gains and waste elimination • 60% error rate reduction (12-15% → 5-6%) through automation and validation
149 • 22% resource utilization improvement (68% → 85%) enabling capacity growth without proportional resource increase • 50% faster customer resolution (3-5 days → 1-2 days) improving satisfaction • 10% improvement in first-contact resolution (86% → 95%) indicating higher quality 11.3. Transition Strategy Phased Rollout Approach: The transition from AS-IS to TO-BE follows a carefully structured 6-month phased implementation to manage risk and ensure organizational readiness: 1. Phase 1 (Weeks 1-2): Planning and system setup 2. Phase 2 (Weeks 3-5): Configuration and customization 3. Phase 3 (Weeks 6-7): Testing and refinement 4. Phase 4 (Weeks 8-10): Training and change management 5. Phase 5 (Weeks 11-12): Pilot implementation (Karachi location) 6. Phase 6 (Weeks 13-24): Full geographic rollout 11.4. Technology Enablement ODOO ERP Modules: The transformation is enabled through three core ODOO modules:
150 1. Helpdesk Module – Centralized ticket management from multiple channels with automated routing and SLA tracking 2. Field Service Module – Mobile-enabled technician management with real-time tracking, intelligent routing, and automated time/material capture 3. Studio Module – Customization platform enabling business logic implementation without coding 11.5. Critical Success Factors Organizational Factors: • Executive sponsorship and visible leadership support • Clear communication of benefits and change management • Adequate resource allocation and commitment • Staff involvement in design and testing phases Process Factors: • Phased implementation reducing disruption and risk • Thorough testing before production rollout • Parallel running during transition for safety • Clear procedures and documentation Technology Factors: • Appropriate tool selection matching organizational needs • Proper configuration and customization
151 • System performance and reliability • Integration with existing systems 11.6. Expected Business Outcomes Financial Benefits: • Annual cost savings: PKR 126,000 • Annual revenue enhancement: PKR 150,000+ • Total Year 1 benefit: PKR 276,000+ • Payback period: 9-10 months • Year 2 ROI: 360%+ Operational Benefits: • 33% reduction in process cycle time • 60% reduction in service errors • 50% increase in customer resolution speed • 22% improvement in resource utilization • 50% increase in service capacity Strategic Benefits: • Foundation for enterprise-wide process improvement • Increased organizational BPM maturity • Enhanced competitive positioning
152 • Improved customer satisfaction and retention • Staff capability and engagement improvement 11.7. Implementation Risks & Mitigation Major Risks Identified: • Staff resistance to change → Comprehensive change management and communication • Data migration issues → Thorough validation and parallel running • System performance → Load testing and infrastructure planning • Scope creep → Strong governance and change control Risk Mitigation Strategy: All identified risks have specific mitigation strategies. Project governance includes weekly steering committee oversight, daily issue tracking, and monthly risk reviews. 11.8. Transition Timeline Phase Duration Key Activities Critical Milestones Planning & Setup 2 weeks System provisioning, governance Steering committee approval Configuration 3 weeks System setup, customization Configuration sign-off Testing 2 weeks UAT, issue resolution, refinement UAT completion and sign-off
153 Training 3 weeks Role-based training, preparation Training completion certificates Pilot 2 weeks Single-location testing Go-live decision Full Rollout 12 weeks Geographic wave deployment Operational completion Table 18 - Transition timeline outlining implementation phases, durations, key activities, and critical milestones for the BPM/ODOO project. Source: Made by the author. 11.9. Measurable Outcomes Post-Implementation Measurement (First 6 Months): Dimension Target Measurement Method Frequency Cycle Time 105 min (±10%) System timestamp analysis Weekly Cost per Instance PKR 325 (±10%) Financial system tracking Weekly Error Rate 5-6% (±2%) Rework instance tracking Daily Utilization 85-90% (±5%) System capacity analysis Weekly Customer Satisfaction +20% improvement Post-service surveys Monthly System Uptime 99%+ System monitoring Daily User Adoption 95%+ transactions System usage tracking Daily Table 19 - Post-implementation performance metrics, targets, measurement methods, and monitoring frequency for the first six months. Source: Made by the author.