Dessertation project on BPM in IT Industry

1

Project on Business Process Management

In One97 Communication

A dissertation submitted in partial fulfillment of the requirements

For the award of

PGDM

by

Dhrubaji Mandal Roll No.16

Part-time Post Graduate Programme in Management

Management Development Institute Gurgaon 122 007 September, 2015

Format for the second page of the Dissertation Project Report

Business process Management

2

A dissertation submitted in partial fulfillment of the requirements

for the award of

PGDM

By

Dhrubaji Mandal

Under the guidance of

Shri Rahul Kashyap Dr. D. P Goyal Sr. Program Manager Professor & Dean One97 Communication MDI, Gurgaon

Part-time Post Graduate Programme in Management

Management Development Institute Gurgaon 122 007

Sep, 2015

3

Certificate of Approval

The following dissertation titled "Business Process Management in One97 Communication” is hereby approved as a substantive work/study in management carried out and presented in a manner satisfactory to warrant its acceptance as a prerequisite for the award of PGDM for which it has been submitted. It is understood that by this approval the undersigned do not necessarily endorse or approve any statement made, opinion expressed or conclusion drawn therein but approve the dissertation only for the purpose it is submitted. Dissertation Examination Committee for evaluation of dissertation Name Signature 1. External Examiner _______________________ ___________________

4

Certificate from Dissertation Advisory Committee This is to certify that Mr. Dhrubaji Mandal, a participant of the Part-time Post Graduate Programme in Management has worked under our guidance and supervision. He is submitting this dissertation titled "Business process Management in One97 Communication” in partial fulfillment of the requirements for the award of the PGDM. This dissertation has the requisite standard and to the best of our knowledge no part of it has been reproduced from any other dissertation, monograph, report or book. Faculty Advisor Organizational Advisor Designation Designation Management Development Institute Organization Gurgaon Address Date Date

5

Abstract Business Process Management In IT Industry: One97 Communication by

Dhrubaji Mandal Today’s companies do not only need to do more than ever before, they need to do it all faster and better, preferably with lower costs and higher ROI. Furthermore, in order to preserve the competitive advantage and to face the quickly increasing global competition, “companies must continuously implement the best practice management principles, strategies and technologies” Business process management (BPM) is a field in operations management that focuses on improving corporate performance by managing and optimizing a company's business processes.[1] It can therefore be described as a "process optimization process." It is argued that BPM enables organizations to be more efficient, more effective and more capable of change than a functionally focused, traditional hierarchical management approach.[2] These processes can impact the cost and revenue generation of an organization. As a policy-making approach, BPM sees processes as important assets of an organization that must be understood, managed, and developed to announce value-added products and services to clients or customers. This approach closely resembles other total quality management or continual improvement process methodologies and BPM proponents also claim that this approach can be supported, or enabled, through technology . The goal of BPM is to reduce human error and miscommunication and focus stakeholders on the requirements of their roles. BPM is a subset of infrastructure management, an administrative area concerned with maintaining and optimizing an organization's equipment and core operations. This study used the framework for Corporate Strategy, which links the external environment with the organizations by utilizing the concept of matching of environmental opportunities and threats with organizational resources and capabilities. . The perspective assumed was of the middle management of these firms

6

The major findings are: Business process management systems (BPMS) may result in considerable rewards for the companies adopting them. Typical advantages are: reduced lead times, less hand-off errors, and more flexibility to change the structure of supported business processed. BPMS’s support the enactment of business processes that flow throughout the organization across departmental borders. Therefore, it may be essential that an organization’s mindset is such that processes by themselves are deemed valuable to improve business performance. Otherwise, people may want to stay within their functional silo’s, not care much about ongoing efforts of process discovery and mapping and altogether refrain from making a BPMS implementation a success Business Process Management (BPM) is an approach to improve and to optimize business processes, aiming to contribute company's enterprise value and performance. The concept of using business processes to improve efficiencies and effectiveness of an organization has been around for a long time, BPM becomes “a boundary less approach to modern competitiveness” . According to historical researches, “a prerequisite for managing an organization based on its processes is to know which business processes are performed within the organization and how they are related to each other. Hence, process-oriented firm explicitly designs and documents its business processes” For this reason, the companies are improving and controlling processes more seriously. In today’s dynamic business environment, organizations need to be agile so they’re ready to respond to whatever challenges come their way. BPM provides that agility by giving you more direct control over your operational processes. We can make better use of technology and your entire enterprise becomes far more responsive, helping you meet your goals

BPM helps create value for the enterprise through growth, improved performance, better productivity, and higher staff effectiveness, and better customer service. All of these improvements result directly from improved processes.

7

Table of Contents Page Acknowledgement Abstract (maximum two pages)

Table of Contents 1. Introduction ---------------------------------------------------------------------------------------------------------------------9

1.1About Company: One97 Communication (Pay tm) -----------------------------------------------------------------------9

1.2Company Structure -----------------------------------------------------------------------------------------------------------10

2RESEARCH CONTEXT------------------------------------------------------------------------------------------------------13

2.1 A. Critical Success Factors for BPM Implementation ---- --------------------------------------------------------------13

2.2 Strategy ---------------------------------------------------------------------------------------------------------------- -------13

2.3 People---------------------------------------------------------------------------------------------------------------------------13

2.4 Optimization and Process Management------------------------------------------------------------------------------------13

2.5 Project Management----------------------------------------------------------------------------------------------------------13

2.6 Process Architecture----------------------------------------------------------------------------------------------------------14

2.7 IT Architecture --------------------------------------------------------------------------------------------------------------- 14

2.8 Standards and Measurements------------------------------------------------------------------------------------------------14

3. Managing Business Process Improvement Initiatives ----------------------------------------------------------------16

3.1 Support Teams ----------------------------------------------------------------------------------------------------------------17

3.2 Several Skills Needed --------------------------------------------------------------------------------------------------------17

4. The Six Phases of Managing Process Improvement Initiatives------------------------------------------------------18

4.1 Project Team Kick-Off Meeting -------------------------------------------------------------------------------------------18

4.2 Phase 1: Understand the Project Need -------------------------------------------------------------------------------------18

4.3 Phase 2: Analyze the Current Business Process -------------------------------------------------------------------------20

4.4 Phase 3: Redesign of the Business Process--------------------------------------------------------------------------------20

4.5 Presentation to Executives --------------------------------------------------------------------------------------------------22

4.6 Phase 4: Implement the Redesigned Process -----------------------------------------------------------------------------22

4.7 Phase 5: Roll Out the Redesigned Process --------------------------------------------------------------------------------23

4.8 Phase 6: Evaluate and Measure ---------------------------------------------------------------------------------------------24

5. Strategies and Business Drivers -------------------------------------------------------------------------------------------25

5.1 Drivers for Adoption ---------------------------------------------------------------------------------------------------------26

5.2 Implementation Issues--------------------------------------------------------------------------------------------------------27

6. The Agile methodology -------------------------------------------------------------------------------------------------------30

6.1 Approaches to BPM ----------------------------------------------------------------------------------------------------------30

\

6.1 The Agile methodology-----------------------------------------------------------------------------------------------------31

6.2 BPM cycle -------------------------------------------------------------------------------------------------------------------- 32

6.3 Success criteria of Agile project--------------------------------------------------------------------------------------------33

7. Approaches to BPM modeling ---------------------------------------------------------------------------------------------35

7.1 Limitations of BPM modeling ----------------------------------------------------------------------------------------------37

8. Requirements for an agile BP methodology ----------------------------------------------------------------------------38

8.1 Incompleteness ------- --------------------------------------------------------------------------------------------------------38

8.2 Empowering people ----------------------------------------------------------------------------------------------------------39

8.3 Business process design should be integrated with usage of technology ---------------------------------------------39

8.4 Design should be carried out at the instance level ---------------------------------------------------------------------- 39

9. A Conceptual Architecture of Business Process Management Systems -----------------------------------------40

9.1When to Use Business Process Management Systems ------------------------------------------------------------------ 41

9.2How to Evaluate Business Process Management Systems --------------------------------------------------------------42

10. Structuring AS-IS and TO-BE Process Improvement ------------------------------------------------------------44

10.1 “As Is” Business Process --------------------------------------------------------------------------------------------------45

10.2 When “As Is” Business Process Analysis is Appropriate -------------------------------------------------------------45

10.3 “To Be” Business Process -------------------------------------------------------------------------------------------------46

10.4 Project ------------------------------------------------------------------------------------------------------------------------47

10.5 Objective BPMS project ---------------------------------------------------------------------------------------------------47

8

10.6 As-is (previous situation) --------------------------------------------------------------------------------------------------49

10.7 To-Be (desired situation) --------------------------------------------------------------------------------------------------51

10.8 Process teams ----------------------------------------------------------------------------------------------------------------52

10.9 Development cycle ---------------------------------------------------------------------------------------------------------52

10.9 Testing ------------------------------------------------------------------------------------------------------------------------54

10.9.1 Communication -----------------------------------------------------------------------------------------------------------55

10.9.2 Communication within the project team:------------------------------------------------------------------------------ 56

10.9.3 Communication to the business:----------------------------------------------------------------------------------------56

10.10 Project outcomes ----------------------------------------------------------------------------------------------------------57

11. Conclusion ----- --------------------------------------------------------------------------------------------------------------58

References -------------------------------------------------------------------------------------------------------------------------59

9

Acknowledgement

The satisfaction which accompanies the successful completion of project is incomplete without mentioned of a few names. I take this opportunity to acknowledge the efforts of all those who have been a helping hand on completing this project.

I would like to express our heartfelt appreciation and gratitude to our head Mr. Rahul Kashyap, Senior Program Manager One97 Communication. This project is a result of his teaching, encouragement and inputs in the numerous meeting he had with me despite his busy schedule. He made sure that my stay in office was a learning Experience

I would also like to thank Prof D. P Goyal Professor, Information Management and Dean of Graduate Programmers, for his constant support continued encouragement and indescribable help throughout this project. Nevertheless with all due regards and respect to the contribution made by various person at each stage of the project , i take this opportunity to thank all those who have been instrumental in completion of Project "Business Process Management in One97 Communication" Finally, I would like to thank our Institute MDI Institute for making this experience to work on this Project. The learning from the experience has been immense and would be cherished throughout my life

10

1. Introduction

1.1About Company: One97 Communication (Pay tm)

One97 Communications Limited is India's leading Mobile Value Added Service Company. Founded in 2000 by Indian entrepreneur Vijay Shekhar Sharma, an Indian businessman who is also the founder of Pay tm. One97's Innovative mobile content, messaging, commerce services and made-to-order network applications offer new revenue streams to telecom operators. Working closely with service providers and enterprises, it offers customer lifecycle management and mobile marketing to enhance their profitability. Championing speed of delivery, One97 thrives on its widely deployed telecom applications service platform to deliver scalable, flexible and customized services. Also the company has recently launched the product by the name PAY tm (pay through mobile) which has been established as a brand in very short time Headquartered in New Delhi, One97 is more than 2900 people strong with regional offices in Mumbai, Pune, Chennai, Bangalore and Kolkata with global presence in Africa, Europe, Middle East and Southeast Asia. We are backed by marquee investors like Ant Financial (Alipay), SAIF Partners, Sapphire Venture and Silicon Valley Bank In February 2015, an Alibaba Group affiliate, Ant Financial Services Group, announced signing of a deal to purchase 25% stake of One97 Communications In March 2015, Ratan Tata, an Indian businessman and chairman Emeritus of Tata Sons, made a personal investment in One97's Pay tm. Tata was granted a small stake in One97Communications and he also took on the role of an adviser at the company

11

1.2 Company Structure

Company consist of about 2900 staff members, different departments are working together for the success of the company , the IT department is one of the core department it consist of the different sub –department like Development , deployment , implementation and support . The core it business of company is providing the value added services to the Telecom operator It generally deals with the telecom provides them the platform to establish the value added services like Call ring tone , miscall alert services , Ussd services , IVR and other many more vas product . The sales and product team work with the IT team to get the business successful. Sales team after dealing with client gives the requirement to the product team, product team liaises with the platform and development team to cater the requirement of client. Once the product is developed and all the testing and others is done, then finally the maintain ace and support is handled by the support team. Support team provides 24 * 7 supports to the client and help in the growth of business. 1.3 About BPM Process and Implementation

12

Within any business activity or enterprise it is crucial that the variable of “operational efficiency” is maintained at sufficiently high levels. Business Process Management (BPM) is the term used to encapsulate a process-driven approach to attaining enterprise operational efficiency. Indeed; BPM in recent years has become as top priority in organizations wanting to survive the current competitive markets BPM is defined as “supporting business processes using methods, techniques and software to design, enact, control and analyze operational processes involving humans, organizations, applications, documents and other sources of information” Business process management helps organizations by providing real benefits such as Automation of Standard Procedures and Processes, Ability to Visualize, Simulate and Trouble-Shoot Business Processes, Change Business Rules and Processes without Impacting Underlying Applications, Manage and Monitoring the Performance of Operations and Personnel. It is clear that BPM implementation is a complex and difficult process that can potentially reap enormous benefits for successful companies and be catastrophic for those organizations that fail to manage the implementation process. The questions that arise are therefore: What are the critical success factors for BPM implementation? Which themes can be used to measure the success of BPM initiative? The resulting framework of this study is suggested to be applied within individual BPM initiatives that will depict the essential elements to be care of. „Success‟ is a complex phenomenon. Success in the context of this study is defined as the resulting status of when the intended goals of the BPM initiative are met to a satisfactory level. Success factors within the context of this research are defined as those key areas where „things must go right‟ in order to the BPM activities to proceed efficiently and be completed successfully. A business process is the complete and dynamically coordinated set of collaborative and transactional activities that deliver value to customers Business process management includes concepts, methods, and techniques to support the design, administration, configuration, enactment, and analysis of business processes. The basis of business process management is the explicit representation of business processes with their activities and the execution constraints between them Business Process Management Systems is a (suite of) software application(s) that enable the modeling, execution, technical and operational monitoring, and user

representation of business processes and rules, based on integration of both existing and new information systems functionality that is orchestrated and integrated via

services. Business Process Management. Business Process Management Systems are based on developments in both the business and IT domain. First, two major business trends that relate to BPM are Total Quality Management (TQM), Business Process Re-engineering (BPR) and is also closely related to Service Oriented Architecture Second, We can identify a rise in the implementation and use of new types of information systems like Enterprise Resource Planning (ERP) systems, Workflow Management

13

(WFM) systems, Enterprise Application Integration (EAI), advanced planning systems and so on. What once started as the automation of a company’s internal processes has now become digitization of supply chain To effectively understand the terminologies and features of BPM, one should start from an appreciation of the BPM life cycle. There are many views of the generic BPM life cycle, but we adopt Van der Aaslt et al.‟s below figure because succinctness and relevance According to them, The BPM life cycle consists of:

Process design: In this stage, fax- or paper-based as-is business processes are electronically modeled into BPMS. Graphical standards are dominant in this stage. System configuration: This stage configures the BPMS and the underlying system infrastructure (e.g. synchronization of roles and organization charts from the employee’s accounts in the company’s active directory) .This stage is hard to standardize due to the differing IT architectures of different enterprises. Process enactment: Electronically modeled business processes are deployed in BPMS engines. Execution standards dominate this stage Diagnosis: Given appropriate analysis and monitoring tools, the BPM analyst can identify and improve on bottlenecks and potential fraudulent loopholes in the business processes

14

2 RESEARCH CONTEXT

2.1 A. Critical Success Factors for BPM Implementation

CSFs in general have been one of the earliest and most actively researched topics. They can be defined as a limited number of areas, in which results, if they are satisfactory, will assure successful performance. According to this definition, our purpose is to define the groups of CSFs that influence the success of BPM implementation. As described before, applying meta-synthesis method, seven clusters are identified. The extracted categories are based on literature review and the references which these factors extracted from are represented in this sub- section

2.2 Strategy Strategy required two approaches. Firstly, there needs to be to be a clear link between the corporate strategy and the company’s core processes. And secondly, whenever the corporate strategy is altered, the required process changes need to be reviewed [16]. Different researchers indicate the role of alignment between business objectives and the goal of the BPM efforts as an essential element for the success of projects [11]. Strategy is characterized further by following sub factors such as: strategic alignment, top management support, governance

2.3 People The people in BPM context refers to the individuals and groups who continually enhance and apply their process related expertise and knowledge [37]. People are one of the most important elements in the business process change since processes should be conducted by people in organization [11]. The factor can be further described by two sub factors: management of people, and roles, responsibilities and skills

2.4 Optimization and Process Management Optimization and process management focus on the management and improvement of cross functional processes. This involves continues monitoring, evaluation, measurement (e.g. cost, quality, time) and process innovation Process management teams use a standard approach to navigate process analysis and design this factor includes the following sub factors: process management BPM methods process improvement methodology

2.5 Project Management Lack of suitable project management is one of the important problems that organizations are faced during the BPM implementation. It is the discipline of planning, Organizing, securing and managing resources to bring about the successful completion of specific engineering project goals and objectives The following sub factors explain project management; project planning, project executing and project control

15

2.6 Process Architecture Existing literature specifically recognized the vital role of process architecture in BPM efforts. The role of process architecture in structural design of general process systems and applies to fields such as computers (software, hardware, networks, etc.), business processes (enterprise architecture, policy and procedures, logistics, project management, etc.), and any other process system of varying degrees of complexity is very important Process architecture in a BPM Success context can be further characterized with two other sub factors: change management and process modeling.

2.7. IT Architecture The IT architecture is an organized set of consensus decisions on policies & principles, services & common solutions, standards & guidelines as well as specific vendor products used by IT providers both inside and outside the Information Technology Branch (ITB). IT architecture is explained further by the sub factors such as: information technology and BPM suites

2.8 Standards and Measurements Performance measure refers to measurements of the processes, project and people performance. The processes performance should be measure correctly to compare them with the goals and benchmarks and choose the suitable process for change in addition of assessment of the improvement. BPM projects need some metrics and standards to monitor the progress and ensure that the goals are achieved It is explained by these sub factors: Measurement techniques, process performance, measurement standards

16

The approach followed in this research (Figure) starts with a literature study (A) in the field of Business Process Management. A BPM lifecycle has been identified and used to order the BPM literature that has been found during this literature study. This literature study was used to define a framework for BPM; w hich provided the foundation for the first version of an evaluation method of BPM products (B). This first version has been applied to different BPM products, which resulted in an evaluation of these products (C). These evaluations have been used to improve the method and they have been compared (D)

In order to reach the objective of the research, the following research questions are answered in this thesis:

1. What is Business Process Management?

2. How does the BPM lifecycle look like?

3. Which literature is relevant for each lifecycle phase?

4. What criteria can be derived from the literature?

5. How can these criteria be used to evaluate BPM products?

6. . What can we learn from the comparison of the analysis results of the three BPM

products,

When improving the evaluation method?

a. What improvements are necessary to the chosen phases?

b. .What improvements are necessary to the chosen criteria of the phases?

c. What improvements are necessary to the way these criteria are used

17

3. Managing Business Process Improvement Initiatives

Business process improvement initiatives prove to be some of the more challenging projects for Project managers. This is for a number of reasons, including:

Most such projects affect the entire business, and it takes a significant amount of time to Understand those affects

There are many “moving parts” and trying to get the right resources secured for the Project at the right time is frequently difficult to accomplish

Some project managers can’t get past the fact that the process improvement initiative is an actual project and not an operation

The work of the business must keep moving forward even with changes in processes

3.1 Managing Business Process Improvement Initiatives There are several steps necessary to effectively manage a business process improvement Initiative. We’ll discuss each of these steps in further detail Figure: Six Phase Approach to Managing Business Process Improvement Initiatives

Of key importance as you work through the process is ensuring that you have team members Skilled in:

• Modeling, analytical and design techniques

• Research, interviewing, and group facilitation techniques

• Communication and change management

• Representing all business units affected by the project

• Training

Let’s take a closer at these areas. First, you’ll want to search for the best team members - those with the expertise necessary to help ensure a successful project. I’ve successfully delayed Projects until the key team members could be made available. Certainly you’ll need individuals with expertise in the processes being evaluated and redesigned, a business analyst to help with requirements gathering, individuals with experience managing change initiatives, individuals with process redesign expertise, and representative individuals. From every department or business unit being affected by the project. For the latter group, in addition to management level staff, you will want to include those

Understand

Project

Evaluate

and

Measure

Analyze

Business

Process

Redesign

Business

Process

Implement

Redesigned

business

Process

Roll out the

redesign

business

Process

18

employees actually doing the Work from day-to-day because they will bring a perspective management simply doesn’t have. Trainers are also needed to ensure that all employees affected by the change know how to utilize the new processes,

3.1 Support Teams Consider a process advisory team to support the project - individuals who represent the Perspective of a particular department or business unit being affected-- to be the pilot test group. You can bounce ideas off of the team members to get their perspective on how a particular Process may help them to perform their tasks. While your advisory team will not be involved in the Project day-to-day, they will serve as your “test crew” and will help you promote the project within the company. Also consider establishing Checkpoint Review Teams to make recommendations on whether to Proceed with aspects of the project at your “go/no go” decision points. These team members should be separate from your day-to-day team and will help with quality testing, communications, risk identification and provide general guidance for you, the project manager.

3.2 Several Skills Needed The process above requires you to have more than just strong technical project management Skills. Also need: • Facilitation skills • The ability to build strong working relationships • Affective communication and presentation skills • The ability to influence others • Team leadership skills In fact the more important than your technical project management skills are your People skills. Your ability to make connections with others, gain their confidence and make them Comfortable with what is happening is essential components of a successful project.

19

4. The Six Phases of Managing Process Improvement Initiatives Let’s look at the six phases identified above in more detail. But first, remember this - as project manager, you must continuously monitor and control business process improvement projects. Never shortchange the amount of time required to actually manage the project to ensure a successful conclusion. Such initiatives are definitely not “hands off” projects and require your Constant attention to detail. But first the project team kick-off meeting.

4.1 Project Team Kick-Off Meeting Before the project even launches, hold a meeting with the entire project team. If the team is not Co-located, I’d highly recommend making the case to get the team together face-to-face for at least a day. If possible, ask the project sponsor and other key stakeholders to participate. This Important project team kick-off meeting enables you to:

• Communicate the importance of the initiative and its impact on the organization

• Review project objectives and benefits to the organization

• Answer questions and address concerns (remember - some of your project team Members may also be impacted by the coming changes!)

• Set expectations for status reporting and regular communications

• Enable the team members to become acquainted with each other, thus raising their Comfort level and confidence in working with each other

• Work with the team to establish processes and procedures around:

Problem solving Decision making Escalation of problems

4.2 Phase 1: Understand the Project Need

In this initial phase of the project we are: • Developing an initial description of the problem to be solved • Developing your preliminary project plan, including key checkpoints for go/no go decisions • Identifying your stakeholders • Identifying the full project team

20

• Determining the preliminary project scope • Determining desired performance improvements in the business • Preparing the preliminary business case for the change in process • Developing the process vision statement (work with key executive stakeholders to determine their vision of a “to be” process.) • Developing preliminary communication plans • Setting preliminary timelines and budgets • Determining training needs and implementation/roll out plans This information is required for approval to move forward with the initiative. Don’t work in a bubble; get your initially identified team members involved in this phase - they will have expertise We don’t have and will bring a different perspective to the project. Most particularly in this initial phase, project managers often find it challenging to identify who will be effected by the project - frequently they forget some key stakeholders. Remember that your stakeholders include everyone who will be impacted by the project in any way. There are direct stakeholders and indirect stakeholders. Ideally in this early phase of the project you’ll want to have a few key team members in place: • Individuals with expertise in analysis and redesign of processes • Individuals who represent the department/business unit being affected These individuals can help to ensure that you are getting all the necessary information to move to the next step, i.e. approval to move forward with the project. Be sure your business case includes, at a minimum, information on: • The initial problem statement • Process or processes that are part of the project scope • High level schedule • Initial resource requirements • Initial budget requirements • Potential project risks • Expected ROI

21

4.3 Phase 2: Analyze the Current Business Process Once you have approval to move forward to Phase 2, update your project documents to reflect any changes or additional information you have received. This phase focuses on looking closely at the current process that is to be changed. Gather Information on the current (“as is”) process through a variety of ways, including:

• Interviews

• Focus groups

• Surveys

• Observation (of individuals working with the current process)

The “as is” model of the process will enable you to see where the gaps are and where Improvement opportunities exist. You’ll also determine the root cause of the problem. Your team members in this phase include a process analyst, a process modeler, and a facilitator for Focus group workshops and your process advisory team members. Don’t hesitate in this phase to speak one-on-one with those using the current process specifically to learn their ideas for how they might improve their job performance. I have found that individuals who are using the process day-after-day frequently have ideas and suggestions on how to make their job easier (and they may be using those methods already). Don’t assume this information will come out during the formal interview process. Make a point to ask them specifically about it. Once you have developed your “as is” process, validate it with those doing the job to be sure you incorporated everything. Once your data is gathered and you have developed and validated the “as is” process, present your findings formally to the sponsor and key executive stakeholders for approval to move on to the next phase of the project.

4.4 : Phase 3: Redesign of the Business Process In Phase 3 We will focus on best practice research and on developing a redesign of the business process - your “could be” options. Stakeholder input is absolutely essential at this point. Not just from the management/executive level, but those individuals who are actually using the process or will need to do so. Anyone impacted by the change should be involved in some way - whether they participate on teams providing input in redesigning the process or are available to bounce ideas off of and test theories. You and your team will be working quite extensively with the stakeholders throughout Phase 3. Take these steps:

1. Do some research?

What are current best practices?

22

What are some innovative ideas in use by competitors?

Remember - competitive information often attracts the attention of executives

2. . What are the criteria for the new process? This will affect the “could be” options. E.g.,

Customer calls answered by the second ring

Data entered into a customer relationship system accurately 100% of the time

Packages delivered to the correct address 100% of the time

3. Determine relational importance of the criteria for the new process - prioritize based on Company needs

What are the “could be” options for the process?

Use brainstorming techniques to capture all possibilities then narrow down to 2 -3 of the best options to test with stakeholders

Design “could be” processes based on the criteria Will the “could be” process options enable the criteria to be met?

4. Socialize with all relevant stakeholders the 2 - 3 “could be” processes mapped out and get feedback Develop a “to be” option from the 2 - 3 “could be” options based on:

Which process best meets the needs

Which process gets the most “thumbs up” from stakeholders

Which process, when implemented, will meet all stakeholder needs and business

objectives

Think about requirements around technology, facilities, equipment and training

Needs for example, take the best of all “could be” options to develop a final “to be” option for Presentation to the executive stakeholders. A straw model development of the new process (“to be” option) is a great way for those Stakeholders effected to see how it might work for them. Get a small pilot group to try it out.

23

4.5 Presentation to Executives When presenting your “to be” option for go/no go decision to the executive stakeholders, be sure to be prepared to discuss: • Impact on technology, facilities, equipment • Training needs • Budget requirements • Benefits to the organization • Potential risks in implementation Be prepared to present a detailed plan for implementation and roll out of the new process, along With plans for evaluating its success and measuring it against the established criteria. All of this should be included in your updated business case and updated project plan. Once Approval is obtained from the executive stakeholders, move to Phase 4.

4.6 Phase 4: Implement the Redesigned Process Phase 4, implementing the redesigned process, includes finalizing the “to be” process your team designed based on any feedback and final decisions from the executive stakeholders. Remember that the current team members may not have the skills to assist in the implementation phase so be sure to pull together the team that will oversee implementation. Again, some representative group from those business units/departments affected should be included on the team. Undoubtedly there are sub-projects involved - be sure to identify all of them. For example:

• Human Resources to develop new roles and responsibilities or to provide training the New process

• Information Technology to secure new hardware and develop software

• Operations to develop policies and procedures around the new process The members of your process redesign team should be assigned in the sub-project teams so that there is consistency and valuable information and insight is not lost. Of key importance to you as the project manager, is to maintain regular meetings with all subproject team leads to ensure information sharing, problem resolution and continued control and maintenance of the required timeline, budget and quality expectations. It is important that all sub teams follow the same processes around documentation, status reporting, testing procedures, etc. In Phase 4 you are focused on keeping the sub-project teams working toward a common goal. I have met with great success in using a collaboration portal to ensure coordination among all sub teams and to keep all necessary data and information accessible by all team members and Stakeholders.

24

Pilot Group A pilot group should run through the entire process from start to finish looking for any issues that May arise. Do not underestimate the importance of proper and thorough testing of the new Process. This will be a large component of the time required to complete the project and is essential to be done prior to full roll out and implementation of the process company-wide. Make any changes or “tweaks” based on the pilot groups testing results, retest, and prepare for Full roll out. Presentation to the Executive Stakeholders Your presentation to the executive stakeholders should focus on the finalized process, including Results of the testing done by the pilot group. Present your plan for full roll out company-wide including:

• Communications strategies

• Training plan

• Timeline for roll out

• Plan for evaluation and measurement of impact on the business

4.7 Phase 5: Roll Out the Redesigned Process In Phase 5, you may have yet another team in place for roll out. These team members may include individuals to assist in training staff on the new processes and also being available to answer questions and ensuring everyone utilizing the new process is confident and comfortable In their abilities to perform their roles. Be sure to spend time communicating throughout the organization (remember you should have been communicating status all along to everyone) - the more people know, the more comfortable and confident they feel, and - the more they have anticipated and bought into the future change.. Ask your pilot group to help communicate the new process to their colleagues. Having worked with the new process, they can be invaluable champions. They can answer questions and Address the concerns of their peers who are less familiar with the new process. Use a variety of Methods to communicate:

• Email

• “Lunch and Learn” discussions

• Company portal

• Internal newsletter

• Small group meetings

Be sure that training is provided to everyone who will be using the new process and that they feel comfortable before they are sent off to use it. Ensure training programs include hands-on practice time. The more confident those affected by the change feel - they have been well trained, they understand why the change is happening and the benefits that will accrue to the organization and to them, they feel a part of the solution - the more likely you will have a successful roll out of a new process within the organization.

25

4.8 Phase 6: Evaluate and Measure A cross-functional continuous improvement team - comprised of individuals from all departments Effected - should be put in place to evaluate and monitor the new process and measure against Business impact criteria put in place by the executives. Be sure a team is also available - a few “go to” people - for questions, concerns and comments that arises as the process is used. Even though it has been tested, you may still find that some Small adjustments are required as it is being fully utilized within the organization. Gather together all stakeholders and team members for a debriefing meeting to discuss what Went well on the project and where improvements are required for future projects. Capture these Lessons learned for use on future process improvement projects Of key importance in any process redesign project - regardless of its size or impact within the Organization - is not to underestimate the time needed to communicate beforehand and getting Potential champions on board with the change. Ensure a change management process is followed throughout and affectively plan for, including any contingencies. There will be issues – be Prepared for them by developing a comprehensive project management plan for the initiative. Taking a project management approach to business process improvement initiatives increases the likelihood of success and adoption throughout the organization. Adopt these best practices to ensure a successful process improvement project: Develop a comprehensive project management plan including:

Change management plan

Communications plan

Risk management plan

Testing plan

Training plan

Roll out, measurement and evaluation plan Continuous communication keeps everyone moving toward the same objective Monitoring and controlling is essential as is having the right people on the project team And the project sub-teams at the right time Process improvement experts are essential on the team Rely on employees from throughout the organization who will be impacted by the change to help provide ideas, suggestions, test out theories and help you to socialize the initiative While these are challenging initiatives for all project managers - even the most seasoned – the Better prepared you are for the project, the more likely you’ll have a successful conclusion.

26

5. Strategies and Business Drivers Although many respondents report a lack of understanding of BPM within their organizations we can assume that those opting to answer this survey have a reasonable idea of what the term means. Most respondents to the survey acknowledge the importance of managing their business processes, with 63% rating it as “Imperative” or “Significa

When this translates into a BPM strategy, 60% of those responding to this survey have live BPM

projects, including 26% who have extended BPM-enabled processes across departmental boundaries.

A further 22% are at the planning stage. These results show a 7% increase in live projects since the

2008 survey.

5-level BPM Maturity Model –

27

5.1 Drivers for Adoption

Looking at the drivers for adoption, we see that “Improving process throughput

(productivity)” and “Removing unnecessary process steps (efficiency)”, are the two

most often stated. “Improving accuracy and repeatability (quality)” comes a

significant third, reflecting the role that BPM can play in continuous quality

improvement and Six Sigma programs.

Perhaps due to its mixed heritage of Enterprise Application Integration (EAI), forms processing, and custom application development, there is no clear ownership of BPM. In a third of organizations the IT Department is most likely to initiate projects, compared to the next third where projects are initiated by Line of Business (LOB) managers. Given the need to focus BPM skills and experience, it is understandable that many organizations have created a Business Improvement group or a dedicated BPM unit. These are the consultants and analysts who would consider BPM software to be an essential part of their process toolkit. Interestingly, only 1% of respondents had BPM projects initiated by external consultants

28

As regards application areas, members of the IT department indicate a strong belief in BPM concepts for their own departmental processes, perhaps reflecting a level of custom application development rather than use of BPM toolsets. Customer support projects are next most popular, providing levels of escalation and ensuring consistent response management. Finance applications are the most universally applicable across all vertical markets, but Product Development makes a strong showing, reflecting the use of BPM for change management

We next looked at the spread and ambition of existing BPM projects, and the

planned expansion areas. Whilst 27% of organizations are currently extending

projects across departmental boundaries, only 5% are extending to supply chain

partners and customers. However, looking at aspirations here shows a will to utilize

BPM across processes in their broadest definition, with a trebling of those planning

to do so in the future, albeit that no planning horizon was set.

5.2 Implementation Issues

As we suggested earlier, user resistance to change is the biggest managerial

issue, and all of the usual change management techniques should be used to

reduce this. Involving users in the design of the process and modeling of changes

is likely to improve acceptance. Lack of understanding or knowledge of BPM has been highlighted as an

impediment in previous AIIM reports, and is more likely to apply to senior

management and LOB management than to users. Another common theme from previous AIIM reports is “Underestimating the time to

map and agree processes”. In many organizations, documented work instructions

and actual working practices seldom match, and the prospect of encapsulating the

29

process heightens these differences. It is worth spending the time to get this right.

Failure to do so will result in users continually seeking workarounds within the BPM

process in order to do their jobs. As we shall see later, a single identifiable process

owner who can represent the process users is also a benefit.

By its nature, BPM is likely to involve interfaces to other systems, whether they are

scan and capture systems or core enterprise systems. Transaction-centric

processes might be expected to present greater difficulties in this area than

document-centric ones. We explored this issue in the survey, but found that there

was no real difference overall. We did detect that content-driven processes score a

little higher for long-term optimization of the process.

“Unexpected exception requirements” was the second biggest technical issue, again

reflecting time taken to fully map existing processes. The third factor, “Over-

complexity of process creation and rules engines” suggests a difficulty of

accommodating exceptions into the core process plan, or possibly a lack of

experience and expertise. BPM applications can be daunting to untrained users, and

many would benefit from more generic training in the BPM methodology itself.

30

In Figure we showed a long list of candidate processes and their likely ROI, but we

also wanted to find out what the common factors for success are. In Figure 15 we

see the Process Owner aspect coming to the fore, followed by aspects of the process

itself. If a process is currently heavily forms-driven, it is likely that over time the

process steps and exceptions have been ironed out. However, good returns can also

be achieved where processes allow a degree of optimization in areas such as

parallelization of serial tasks, and where formalization of routing and branching can

be handled in a more repeatable manner.

31

6. The Agile methodology

Approaches to BPM Many organizations have seen the benefits which BPM can provide, it may result in a significant advantage for the organizations applying them, and however, implementation of business process management systems (BPMS) can be complex and time-consuming. It also requires a tighter Alignment and extensive collaboration between business and IT. During the implementation project a proper methodology must be considered to Support and to ensure that the goals can be achieved. Fortunately, literatures on business process management suggest that great efforts have been done in the field of methods for BPM implementation. Ravesteyn (2007) listed 21 BPM (-related) implementation methods (appendix 1) from professional and academic world. One of these methods has emerged in the last decade: Agile software development methodology (The Agile methodology). When we talk about software development methods, is it easy to recognize the waterfall model, which is a traditional approach. Traditional approach consists of "…sequential phases of planning, analysis, design, implementation and maintenance. The approach involves detailed requirements gathering, followed by a design which includes all Specifications. Development then proceeds according to the plan." (Vinekar2006). Thus it often has a long development cycle. A lack of responsiveness to change is another issue of traditional sequential development Requirements often change after a project begins, and process owners often change their expectations for the desired process during the project implementation phase. The developers and other participators need time to respond towards the changing requirements, but it takes time and can be costly, the project could hence fail to deliver on time and on budget. If the project is going to fail, it is much better to know after 1 week rather than after 3 months. Additionally, the lack of involvement of the users creates a gap between business and Information Technologies (IT), where business claims that IT does not understand the business processes, and conversely. Within this content, the agile methodology is developed to overcome the weaknesses of plan-based methods of software development. Given the true natures of BPMS project which emphasizes collaboration between IT and business as well as rapid response to change, BPMS implementation project is the ideal candidate to apply the Agile methodology.

32

6.1 The Agile methodology Agile software development is a framework of a group of software development methods for software development project management as well as solution implementation, with principles of iterative and incremental development, continuous testing, and frequent re-planning based on Current reality where requirements and solutions evolve through highly collaboration between self-organizing, cross-functional teams. The Agile methodology favors the need for flexibility and adaptability of the organization (Highsmith, 2002), it allows business and IT to work together on design in terms of desired processes which could result in a quick quality solution, it helps customers to achieve dramatic business results by accelerating time-to-market (Simmons and Steele, 2012). Other benefits of Leveraging this methodology include cost savings, risk reduction, and greater customer satisfaction by promoting a focus on customer needs (Ambily O.A et al., 2011). Because of the adaptability of the methodology, customers’ demands of change in plans or requirements can often are realized in the next iteration of development. Agile methodology also allows organizations to respond to the unpredictability of a project (Simmons and Steele, 2012). Because the design stage is not formal and developers work In short iterations, significant requirements can be changed without much loss of productivity. There are several methods under the agile framework, some methods focus on project management and collaboration practices, while others focus on software development practices. Scrum is one good example of the first kind

Scrum Scrum is a discipline used to manage project and to stimulate collaboration using iterative, incremental practices. Within the Scrum discipline, a series of iterations are used as basic units in the project. In the end of one iteration, a working piece of software will be delivered and can be tested, which generally results in a BPMS implementation that one iteration comprises. One Or more processes of the project or one process if the project is complex enough. A key benefit of iterative development is that, a deliverable developed during iteration can be directly tested by the end users at the end of the iteration.

Team In an Agile project, the teams are cross-functional (Boehm, 2002). The customers (business) usually will join the development team, they normally take responsibility to form the requirements of functionalities and to test the deliverable within iteration without to taking the existing corporate In Agile, testing is involved and accomplished by all members of the team to validate the client requirements at frequent intervals. As soon as possible one sub-process is build or any bugs are fixed, they can begin to test and give feedback quickly. Under such a scheme, potential bugs are early detected and fixed; it will further help to reduce the cycle time and the cost of

development.

33

Iterations

Since Agile methodology promotes adaptive planning (Highsmith, 2002), a BPMS implementation project who applied Agile methodology, has often minimal planning. Although iterations are typically short, a full software development cycle is fulfilled during one iteration, including planning, analysis, design, coding, testing. This decreases the project risk and allows rapid changes when it is desired.

6.2 BPM cycle Bottlenecks in processes are often clearly identifiable but how do we improve the current chain and transform the focus of the adhoc response to an organization that goes for continuous Optimization? This can be done by means of the BPM cycle

This cycle is called plan-do-check-act cycle, in which a process is performed Based on a plan (with goals, coupled with the strategy of the organization). There is a regular 'check' on the basis of measurements and evaluations. When unwanted deviations are found that differ from the plan and the strategy, an 'act' adjustments will be implemented in order to correct it. Then the cycle begins again with 'Plan' to initialize process improvement so that the quality of the process always improves. Consequently, the BPM cycle is a learning curve within the organization in which people remain

Critical and constantly look at where quality can be increased. To effectively understand the terminologies and features of BPM, one should start from an appreciation of the BPM life cycle. There are many views of the generic BPM Life cycle (Havey, 2005; Hillet al., 2006; van der Aalst, 2004a, b, c; van der Aalstet al., 2003) but we adopt van der Aasltet al. because of its succinctness and relevance. According to them, the BPM life cycle consists of van der Aalstet al.

34

Process design. : In this stage, fax- or paper-based as-is business processes are electronically modeled into BPMS. . System configuration. : This stage configures the BPMS and the underlying system infrastructure (e.g. synchronization of roles and organization charts from the employee’s accounts in the company’s active directory . This stage is hard to standardize due to the differing IT architectures of different enterprises. Process enactment. : Electronically modeled business processes are deployed in BPMS engines. Execution standards dominate this stage. .

Diagnosis. : Given appropriate analysis and monitoring tools, the BPM analyst can identify and improve on bottlenecks and potential fraudulent loopholes in the business processes. The tools to do this are embodied in diagnosis standards

6.3 Success criteria of Agile project Based on existing literature, there are a number of articles describing empirical studies related to the Agile methodology. Wan and Wang (2012) verify critical success factors (CSF) in their empirical case study, while Schatz and Abdelshafi (2005) provide results from the Primavera case study indicating how to measure success in an Agile project. Chow and Cao (2007) Indentify 12 critical success factors of Agile software development projects. Using quantitative methods by gathering survey data from 109 Agile projects. They define CSF’s as "the factors that must be present for the Agile project to be successful" Chow and Cao (2007). Besides these case studies, other findings are based on quantitative researches. In the systematic review of Dybå and Dingsøyr (2008), they evaluate, synthesize, and present the empirical findings on Agile software development. This is further detailed by Misra et al. (2009), who conducted the CSF's into three categories: time, cost, and quality, which can be recognized as competitive criteria for software development project. In an Agile environment, it’s often difficult to measure the success since Agile welcomes changing requirements. However, Misra et al. (2009) proposed five criteria used to determine the success of Agile software development project, which the most critical success factors can be categorized into any of them:

• Reduced delivery schedules.

• Increased return on investment (ROI).

• Increased ability to meet with the current customer requirements.

• Increased flexibility to meet with the changing customer requirements.

• Improved business processes.

35

These criteria summarize the three important angles of the success of agile project. Based on these criteria, the outcomes of the project are used to validate whether the project is successfully implemented adopting Agile methodology. The agility of organizations increasingly depends on their ability to set up new business processes or to modify existing ones in a dynamic manner, and rapidly adapt their information systems to these process changes. This paper propose a new agile business process management methodology, which is part of the a multidisciplinary research project – Agile business Process (AGILIPO). It is argued that existing business process (BPM) methodologies do not offer the necessary flexibility or agility and that new approaches are required. The new methodology is inspired on goal-orientation complemented by a classificatory framework, aimed at introducing standardization and reducing the time and effort required in the process identification phase. Wiki-based technology is proposed as the basis upon which to build a collaborative approach to business process mapping, design and re-design, supplemented by folksonomy to provide ontological support. Finally, the methodology adopts an approach to validation, which is embedded in the previous phases of process identification, mapping and design. With the increased challenges of globalization, re-engineering is now re-emerging in the form of BPM (Smith and Fingar, 2002). The drive of BPM is coming from a demand for a common way to implement inter-enterprise business processes that is independent to the technology used to Support them. Recent research in BPM pays more attention to flexibility as a way of coping with the unpredictability of business processes (Dadam et al. 2008, Reichert et al. 2008). Changes are not only emerging in an organizations environment - market or society - but also within its Organizational structure (fluctuation, restructure of business units, process change)

36

7. Approaches to BPM modeling Business Process Management (BPM) is a discipline which has been around since the early 90s, launched by the article by Hammer (1990) and reinforced by the book by Hammer and Champy (1993) on business process reengineering (BPR). Hammer (1990) stressed that IT made it possible for companies to undertake major revisions in the way they did work. At the time, it was yet another attempt at bringing more efficiency to private and public organizations, drawing attention to the situation of fragmentation of horizontal processes which has consequences on delays for the customer, increases in costs of the final product and weakened competitively. The way to overcome this was through the reengineering of the work processes, elimination of layers and radical reorganization. Although it had some success in a few companies, the BPR movement fell into discredit mainly due to the “scorched earth” policy which was adopted in many of the interventions. BPM methodologies have two major objectives: (1) to capture existing business processes by structurally representing their activities and related elements; and (2) to represent new business Processes in order to evaluate their performance (Davenport, 1993; Kettinger et al., 1995). But what is a business process? According to Davenport (1993) and Hammer and Champy (1993) a business process contains the following elements:

(1) has its customers;

(2) is composed of activities;

(3) these activities are aimed at creating value for customers;

(4) activities are operated by actors which may be humans or machines;

(5) often involves several organizational units which are responsible for a whole process

More recently, BPM has resurfaced through the Total Quality movement and the work of the European Foundation for Quality Management (EFQM, 1999). Such rebirth has been championed mainly by practitioners (Burlton, 2001; Smith and Fingar, 2003) and is reinforced by a host of process-based techniques, such as Six Sigma, CRM or Business Intelligence. The so-called third generation BPM brings a different perspective to process management. It is announced no longer as the panacea to all the ills of the business but as the only way to implement strategy effectively. Each process is depicted as a response to a stimulus from the organization’s environment, starting from the stimuli from the stakeholders. If high-level processes are broken down into sub-processes in close alignment with the organization’s strategic priorities, it will be possible to draw process map (architecture) which reflects the strategic needs of the organization BPM seeks to streamline and govern the multitude of handoffs between functions, departments and divisions.

37

BPM technology accomplishes this by first modeling processes and then executing the model. BPM is not a question of all or nothing. It is a continuum, which ranges from better process-related know-how of the employees to an organizational and technological solution that covers every aspect. In other words, the use of a BPM system is not a silver bullet for all business processes. For each business process, the different performance-related dimensions must be considered (Kung and Hagen, 2007). Business process modeling has had different emphases over the last couple of decades by both Researchers and practitioners. It is the first and most important step in Business Process Management lifecycle (Van der Aalst, 2003), which intends to separate process logic from Application logic (Sharp and MacDermott, 2001). When discussing business processes, it is important to differentiate the process type from the process instance. The notion of process type is used to talk about the process in general, (e.g. sales process). The notion of process instance is used to pinpoint a particular process (e.g. processing a sales lead concerning a particular customer). Much work has been done by researchers in order to shed some light on BP modeling methods, which has given rise to different classifications. Kueng et al. (1996) have proposed four categories to group process modeling approaches: (1) Activity-oriented approaches tend to define a business process as a specific ordering of activities (sometimes referred to as tasks) BP are seen as event-driven Process Chains (Scheer. 1994). These approaches generally offer good support in refining process models; however, they have limitation in representing the true complexity of work and, in turn, have difficulty in integrating new business processes. (2) Object-oriented approaches are associated with object orientation, such as encapsulation, inheritance, and specialization (eg. (Booch 94). The principles of object orientation are applicable to business process modeling. However, practitioners, such as process owners and team members, tend to describe their work by activities rather than by objects. (3) Role-oriented approaches suggest that a role be involved in a set of activities, and carry out particular responsibilities (Ould, 1995). A group of primitive activities can be assigned to a particular role (i.e. actor or agent). However, these approaches are not suitable to express the logic of intricate sequencing. (4) Speech-act oriented approaches based on speech act theory under language/action Perspective, view the communication process as four phased loop: proposal, agreement, Performance and satisfaction (Medina-Mora et al., 1992). Although business cases can be viewed as a communication between customers and performers, this approach does not provide much help in analyzing existing processes or creating new processes.

38

7.1 Limitations of BPM modeling

BPM modeling methods present advantages or disadvantages according to a host of different issues. The organization’s business process modeling requirements differ and so do the environments where the models are to be used (Bider, 2005). For example, modeling methods may depend on whether or not the organization is functionally structured; on whether it has formal means of internal communications; on how strictly it defines responsibilities for each position; or on whether or not processes have been previously identified. The mechanisms for verifying the process in terms of correctness, completeness, relevance and Feasibility or economic efficiency are also extremely complex (Curtis et al., 1992; Becker et al. 2000). Correctness of the process constrains the modeling primitives and combines them according to pre-defined rules. A model must also be semantically correct; therefore, it has to be formally correct and consistent with the perception of the real world. The consistency between different models is viewed as a part of the correctness of the model. Completeness demands that a sufficient set of concepts is included in order to provide the Expressive power that is needed for representing all relevant aspects of the domain. Relevance postulates the need:

• to select a relevant object system (universe of discourse),

• to take a relevant modeling technique or to configure an existing meta model adequately, and

• to develop a relevant (minimal) model system.

A model includes elements without relevance, if they can be eliminated without loss of meaning for the model user. The economic efficiency dimension is comparable to criteria for business feasibility and is supported by notions such as reference models, appropriate modeling tools or the re-use of Models. Lindland et al. (1994) claim that economic efficiency factors restrict the correctness or the clarity of a model. From the point of view of BPM practitioners, the limitations that BPM modeling might be summarized as follows (Coelho, 2005):

Process improvement is focused on methods and tools, often forgetting the people dimension

BPM often begins with a lengthy and monolithic “AS IS” analysis

BPM is focused on a team of external consultants mapping the organization’s explicit Knowledge, often with little regard for the tacit knowledge

The approach relies mainly on individual interviews with no further involvement of users in the identification/design of the business processes

The task of documenting methods and procedures is very heavy, making the exercise rather unattractive to the organizational members involved

39

8. Requirements for an agile BP methodology

As part of the AGILPO project, we aim to define a methodology for the incremental design and implementation of business processes. The methodology considers the human and social aspects associated with the understanding of what the organization’s business processes are. Moreover, the methodology should make the description of all activities of a business process possible and should support and be supported by a set of AGILIPO-specific tools. The key idea is to enable the identification and design of business process on top of tangible representations of the business processes which users immediately agree on. The tangible representations will start to be built on already automated sets of activities belonging to specific business processes. Thus, users will visualize existing automated processes and their activities, and they will contextually describe the activities that are related to the ones they are visualizing. The discovery process should follow a technique of tacit knowledge management, where the users suggest process changes using a language that is based on concepts related to workflow exception. Moreover, users should provide their feedback about the business process when they are executing their daily work. This means that the tools have to integrate the interface for workflow execution with the visualization and reporting interface. The agile business process proposal is characterized in the following manner (Rito-Silva et al., 2009): The agile business process proposal is characterized in the following manner

8.1 Incompleteness

The process does not need to be completely understood. Trying to completely understand a process is time expensive, reducing the number of feedback cycles and increasing the chances that automated processes does not conform to organizational needs.

The process does not need to be completely specified in the sense that it is allowed that activities not pre-specified occur in some of its instances. This allows the instantaneous adaptation of processes, instances, to the emergence of new organizational needs.

Incompletely defined processes should be executable and its execution should integrate planned and unplanned activities such that incompletely specified processes will not limit the normal operation of the organization.

40

8.2 Empowering people

Processes should promote collaboration, creativity and intelligence instead of restricting them.

The system should allow people to perform unplanned activities and integrate them with planned activities

8.3 Business process design should be integrated with usage of technology

To avoid a situation of paralysis by analysis due to different perspectives on

processes, a modeling approach based on the operation of the business should be enforced. This way, the different perspectives on process modeling will be focused on bottom-up leveraging of the actual operation of the business.

Integrate the execution and modeling of the process, such that the process

executor is also one of its modelers

8.4 Design should be carried out at the instance level

It should be possible to describe processes on a case-by-case approach

instead of trying to model all the possible situations in the process specification. This will allow a reduction of the complexity of business process models and it will provide two Views of the process: the type view, containing the expected behavior common to all Instances and the instance view, containing exceptions to the expected behavior Present on the type view of the process.

It should be possible to promote unplanned exceptions, described at the instance level, to become part of the planned behavior of the business process, described at the type Level. Which exceptions to promote to the type level should depend on the automation? Cost and benefit? Moreover, this approach promotes the bottom-up definition of Processes.

41

9. A Conceptual Architecture of Business Process

Management Systems

Given above is conceptual architecture of a BPMS. Its main components are the Process Development Environment, the Process Engine, Business Activity Monitoring (BAM), and System Administration. Business analysts and business users employ the development environment to define business processes and business rules to be executed on the BPMS. This component also enables processes to be simulated before they are deployed, so that potential bottlenecks are identified and removed.

42

The process engine is responsible for managing project instances. This includes creating process instances, prioritizing them, ensuring process integrity and performance, managing the interfaces with services and users, executing business rules, and generally ensuring that the business process meet the expectations of the business. Business Activity Monitoring (BAM) provides the business with data and reports on the performance of various business processes. This enables the process owner to identify bottlenecks and to drill down into the data to obtain even more detailed views of process capability. System administration refers to the features of the BPM product that enable system administrators to configure users and their rights, administer the servers, monitor performance, etc. The BPMS uses the Enterprise Services Infrastructure to access the underlying applications and databases. These applications and Databases themselves expose their functionality in the form of services, which are managed by the Service bus, and

combined in various ways to create composite services.

9.1When to Use Business Process Management Systems The key advantage of a BPMS is agility - processes can be created and managed with minimal changes to application code, and new processes can be rapidly and easily created. The other primary advantage is conservatism: Past investments in business logic and applications can be reused to create new, composite, processes. Consider implementing a BPMS whenever :

Business processes need to be maintained in several versions, for different product categories or for different markets

Business processes need to be extremely mutable

There are opportunities that have been identified for existing applications to work with one another, but these include a huge element of custom code that cannot easily be moved into an ERP In fact, any occasion where you are considering implementing a new process, or redefining an existing process, is an opportunity to consider moving to a new “process platform”

43

9.2 How to Evaluate Business Process Management Systems

A BPMS needs to be evaluated based on its capabilities over the entire lifecycle of business processes. We need to consider its capabilities in the following:

Requirements management:

• Ability to integrate with requirements management tools already in use • Ability to document process requirements and SLAs within the tool • Ability to trace requirements through the process lifecycle • Ability to model business organizations

Process design:

• Ability to use standard modeling languages like UML

• Capabilities of the graphical process designer: ability to depict different organizational structures and process flows (role-based routing, relationship-based routing, ad-hoc routing)

• Ability to reuse processes from other modeling exercises

• Ability to depict both synchronous and asynchronous process calls

• Capabilities of the business rules engine

• Whether the product includes a forms designer, and whether it can work with other forms Products

• Process simulation capabilities

Process deployment and execution: • Ability to work with a variety of EAI products without extensive programming • Support for XML over JMS and XML over HTTP(S) • Provision for the process to be deployed centrally, without the need for any changes at the client end • Queue administration

44

• Roll-back capabilities • SLA monitoring and escalation • Exception handling • Process metrics and reporting • Scalability

System administration • Ability to work with a variety of EAI products without the need for extensive programming • The ease with which end users can be created and authenticated • Backup and recovery • Process configuration management

Cost

• License cost • Requirement of Third party software The BPMS market is now in a highly fluid phase, as vendors wage war over standards and technologies. The final details may not yet be defined, but the overall direction of BPM is very clear. IT organizations will find that they are being called on yet again - to lead, follow, or get out of the way.

45

10. Structuring AS-IS and TO-BE Process

Improvement

In a process improvement project, the analysis team needs to model and examine several aspects of the current (AS-IS) value chain under study. The purpose of the analysis is to create a visual diagram of the value chain along with its associated text and metrics and determine if there are possible areas of improvement (e.g., reductions in cost or time). If improvements are identified, the team constructs a modified value chain model (TO-BE) with the improvements and then conducts a gap analysis on how to transition to the new value chain. This article focuses on the analysis of the current value chain by providing a method for structuring the AS-IS and TO-BE process improvement discussion.

After an analysis team builds the AS-IS model using techniques such as simple flowcharting, the United Modeling Language (UML), or Business Process Model and Notation (BPMN)*, they need to examine what process improvements are possible to support a credible business case to justify a TO-BE implementation.

The AS-IS and TO-BE analysis needs to be organized to ensure a comprehensive study. One method is to use an iterative adaptation of the fishbone or Ishikawa diagram (1) commonly used for root cause analysis. Essentially the use of the fishbone is expanded to not only determine root cause, but also to identify improvement opportunities.

Business always looks for ways to maximize profitability. In the broadest sense, business usually aims to achieve that by trying their best to minimize the cost or to maximize the revenue or probably both. So, companies are highly encouraged to improve how business runs in hopes of improving productivity or to deliver services more efficiently.

Business process improvement may come in some common forms as below:

1. Technology adoption. For example, old-style stores perform operations by human. If we computerize a business for higher efficiency, it is very likely that the process need to be re-engineered in the future in order to reap the benefit from adding the computer system.

2. Changes in supplier/manufacturer/customer relations require business process re-engineering. Perhaps customers are dissatisfied with the slow courier service, so you must change the courier company to avoid losing customers. Another case might be that the previous supplier which used to deliver goods to you weekly cannot accommodate your new daily schedule and leaves you with no choice but to seek a new supplier that does. In addition, it would probably call for a process change in order to work with the new supplier.

3. Change of management direction and process obsolescence. Perhaps the management wants to close down a department. If a process relies on that department, you have no choice but to modify the process.

Attempt to improve a process begins with understanding how it works currently. Why not describing the process visually using graphical notation of a widely adopted industry standard? A visual representation with a common ground means less

46

confusion and saves more time for the actual re-engineering part and that standard is called Business Process Modeling Notation (BPMN). In BPMN, the current process to be enhanced is called as-is process. After it gets re-designed, we call it to-be process.

10.1 “As Is” Business Process

An “as is” business process defines the current state of the business process in a organization. Typically the analysis goal in putting together the current state process is to clarify exactly how the business process works today, kinks and all.

An “as is” business process contains all of the sections in a typical business process model – a description, list of roles, list of steps and exceptions, etc.

When putting together an “as is” process, access to business stakeholders who perform the business process is key. Secondarily, access to business stakeholders who understand the process (such as a manager or subject matter expert) can be helpful, even if these individuals do not routinely perform the business process.

You’ll need at least one stakeholder to represent each role in the process. For example, for a process describing how a new customer gets set up, you may need representatives from sales, customer service, and fulfillment.

Once you determine who needs to be involved, you can elicit information about the current state using a variety of different methods. Interviews and observation tend to be the best elicitation techniques to understand the current state process. Once you are able to put together a draft, a document review can be used to confirm your understanding and fill in any knowledge gaps.

10.2 When “As Is” Business Process Analysis is Appropriate

It’s not always necessary to document the current state, but it can be extremely helpful in giving your project team a foundation from which to build new enhancements or make business process improvements. Here are some scenarios when starting with the current state is particularly appropriate: There are known issues with the current state, such as orders not getting processed or customers being frustrated with your organization’s level of service. Business users are confused about what the right process is or what steps to take in what situations. Your organization wants to automate or streamline the current processes, but the current state is not well understood or documented. Often in bringing together stakeholders and analyzing the current state processes, you can’t help but improve them, at least slightly. The clarity that comes from good business process documentation can, on its own, sometimes resolve confusions and fill in the gaps that are causing issues. But many times, documenting the current state is an interim analysis step to improving the current state by creating a new “to be” or future state process.

47

10.3 “To Be” Business Process A “to be” business process defines the future state of a business process in an organization. Typically the analysis goal in putting together the future state process is to clarify how the business process will work, at some point in the future, once changes are made. Those changes, as we’ll see, could be technology changes or business process changes. A “to be” business process contains all of the sections in a typical business process model – a description, list of roles, list of steps and exceptions, etc. (By the way, we address business process analysis techniques in detail in our Business Process Analysis virtual course.) “To be” business process documentation rarely exists in isolation, nor is it conducted as a stand-alone activity. It is typically one deliverable on the path to creating change within your organization, which means it exists as part of a project. Since a “to be” process is completed as part of a project, you’ll want to lead a team of stakeholders through the entire business analysis process – starting with getting oriented (perhaps by analyzing or reviewing the “as is” business process documentation, continuing with defining business objectives and scoping the change, and with creating your business analysis plan (particularly important if there is more than one inter-related process to document) and then creating your “to be” process documentation. These steps might seem overwhelming, but they can be completed relatively quickly to implement a small improvement – perhaps even within one or two very focused meetings. On the other hand, they may happen over the course of several weeks or months for a large scale business process improvement effort that involves supporting technology changes. When “To Be” Business Process Analysis Is Appropriate Here are some scenarios when working towards a “to be” or future state business process documentation is appropriate: In short, if your project creates change, consider creating one or more “to be” business processes to clarify what the change means to the members of the business community. The clarity you create will help the business users embrace the change more fully, enabling your team to create a positive impact within your organization.

48

10.4 Project

A number of mergers have resulted in One97 Communication being the largest

Vas service and Ecommerce company in India They Provide the different services

to the Telecom Operator and Newly Emerged Product Pay tm is the leading

Ecommerce Company

The company has a vision it wants to be a leading service provider delivering

reliable service and continuously supplying against lowest possible costs. In order

to achieve this, it is important that the company has efficient processes, which

ties to the business process management.

10.5 Objective BPMS project The department Customer support of One97 (Pay tm) wants to improve the

service Quality and efficiency of operations constantly resulting in better customer

Satisfaction and lower time and cost

.

This is why the department started in 2008 with Business Process Management

(BPM) . This project is a part of the roadmap for the department Support

Aiming to reduce cost and to accomplish customer-oriented approach. This

Project is aimed at analyzing and optimizing processes so that processes can

Be more manageable, other strategic benefits of the department wish for

Through this project follow:

From functional task-oriented to process-oriented

Continuous improve processes and increase quality of customer contact

Optimization between process and operation

Reduce transfer times of work

Multi employability (reduction of FTE)

The goal of this project is to implement a Business Process Management

System (BPMS) supported by BPMS software Process Manager. As described in (figure 3), the project consists of 3 phases, namely Customer Registration and Cancelation, Customers Relationship Management and

49

Usage, Invoicing & Cash Collection. In this paper, we focus on the Customer Registration Process.

This project is done by applying Agile methodology in which the demands/ Wishes, process modeling and testing are intermingled. By means of this Methodology, the business requirements and system dependencies can be

aligned.

This paper describes only one process, namely Customer Registration of Department Customer & Billing of One97 (Pay tm), which is one of the key processesof the BPMS implementation project. The project is initialed by

department Customer & Billing of One97 (Pay tm), aimed at analyzing and optimizing processes for More manageable processes

During the project, a process team is created. These process team members are the key users of the BPMS. During the project

implementation phase, if the current activity or process must be adjusted, the process team members are those that describe, request and test the

changes. They will be part of the project to cooperate with the developers, business analysts’ en project managers. When the project is completed, they are able to support and train end-users.

Some responsibilities of process teams are shown below:

• Analyze current processes

• Responsible for documentation, work instructions, KPIs, process Measurements, etc. • Initialize improvements proposals (business case) • Initialize new process design (BPR)

50

• Monitor Processes • Manage process documentation • Communicate process changes Moreover, these process team members are responsible for testing together With some future end-users. At the end of project, built functionalities will be Tested by them through acceptance testing. By approving the outcome of This test and the test underlying test scripts, the acceptance will take place. 10.6 As-is (previous situation) The following list summarizes the issues of the previous situation insideOne97 (Pay tm) concerning business process:

■ Business 1. High labor cost to execute activity 2. Inconsistency of work quality between workers 3. Inaccurate prediction of work completion 4. Difficult to give status reports 5. Failure to effectively manage process and performance 6. Informal tasks and communication (lots of paper and email). Incomplete or

inaccurate data flow between systems 7. Insufficient understanding of the performance of the process

■ IT

1. Frequent change requests to deal with exceptions in the process 2. Frustration about the constant changes in business requirements 3. Press to shorten the development cycle 4. It is not possible to keep the speed of change

Considering the Customer Registration Process, for example, a new customer with a new connection, which may involve execution of transactions such as customer registration, creating a new connection, registration of the new customer on the newly created connection and generation billing document in an ERP system. In practice, these four transactions may be performed by four different workers from Customer Service, Connections, Customer Moving and Accounts department respectively. ERP systems obviate the need for duplicate data entry, however, they never alert Department Connections that the previous activity has been completed and it is their turn to complete the transaction when Customer Service has handled the call from customer. As a result workers are needed to be prompted externally (manual intervention) to accomplish these tasks/activities assigned.

51

An activity of a business process executed in a "non BPMS" environment is neither

visible to activity owner nor to their manager. As stated above, workers of

Department Connections do not know when work gets assigned to them to create

a new connection, and also the priority and analogously, process manager is not

aware of the bottlenecks, delays, exceptions, etc, process manager thus tend to

be reactive.

52

10.7 To-Be (desired situation)

Figure 5 illustrates the desired situation by using BPMS which: Automatically routes and prioritizes work Helps and guides users in making decisions Provides a

standardizing of solving problems automates some activities Offers real-time visibility and control of processes

As stated before, by identifying and documenting business process, a clear detail of the business process could be revealed. Based on documentation obtained from the analysis, the Business Analyst start drawing up the desired process diagrams together with process teams of One97(Paytm) . With the aid of an appropriate modeling of the business processes, the essentials of the processes can be understood. It is ideal that The model of processes can be understood as much as possible by the people involved in the project, in particular the business. This could be achieved through The use of graphical representations of the process.

53

10.8 Process teams

By identifying process, workers will get a better insight into their work. This ensures uniformity

in the workplace and will bring problems to light easier. Moreover, since the most processes

are cross-department, therefore it offers an improved communication between different

departments. The idea is that it is more efficient for all activities to act correctly at once. This

saves the organization time for corrections. This kind of organization will eventually save

money. It is thus important to do the right things at the first time.

10.9 Development cycle

Implementation BPMS involves an agile approach using multiple iterations. Each iteration is a

mini project, and includes all necessary development cycle: planning, analysis, design,

implement, testing and documentation. In parallel with these, additional activities such as

documentation and mentoring will be taken place. This project is split into three iterations.

Each iteration delivers a working part of process that can be tested by the process team and

can be presented to several workers from the department during a so-called playback

sessions. Output of these sessions may be used in the following iterations.

In addition, each iteration should contain the necessary (integration) services in which the

necessary business logics are delivered. This is done in accordance with the documented

requirements so that it immediately can be tested by the process team and has the

opportunity to give feedback. These tests will focus on testing small pieces of functionality that

later will be tested as a coherent whole.

Employees from the business. Small group(s) of end users will get the chance to get

acquainted with the new system and provide feedback.

54

At the end of each iteration, evaluation will be made. Stakeholders will comment on the deliverables and

documents will be presented during the iteration. The team will hold a meeting to assess the responses

for the iteration. On this basis, improvement can then be made during the next iteration(s).

In the first iteration, the "Happy path" of the process will be built. It is generally the start of implementing a

process. It is the process flow if everything works as expected. This path is normally the simplest path of

a process. In the case of Customer Registration Process, the customer is known, the connection is

created, there is no invalid consumption of water, etc. The process is executed without any expectations.

When designing a process, it is common to start with the happy path, and gradually add the handling of more complex conditions or exceptions to it. Subsequent iteration could then capture the major exceptions, handle the Integration with other systems. Figure 6 presents the development cycle of this project. During the iteration 3, the exception paths build in iteration 2 will be "assembled" in to the iteration 1 which will make the process complete. Moreover, changes from previous iterations will be adjusted and optimizing request could also be fulfilled. When the implementation effort for this iteration is done, a true user acceptance test can begin. This eventually Leads to the creation of a very detailed process from a "rough" process.

55

10.9 Testing A principle of “test-first" will be used during the project. This means that the Building activity happens in small steps and there are direct interactions between project team members so that each small step can be immediately tested and based on the feedback then can be adjusted (and then retested, etc.). As ever a part of the process (e.g. a user interface, or an entire process step) Is ready, it can be tested by process team members. Based on these tests, Feedback is provided to developers who then - if necessary – make Adjustments, it then be tested again. This is repeated as often as is necessary in order to achieve the desired result. In practice this means a Close and direct cooperation between the developer and the business. The purpose of testing is to verify if the application meets the predetermined requirements before the application goes into production.

The test phase is parallel to the development phase. Daily a part process or components are offered to testing. The completed process should be subjected to various tests. This requires involvement of various parties inside and outside the process team. It must also be stated who, when, and what test or if preparation is need for a test. This allows people to prepare themselves well and to bring the test environment in order. For this project, a test flow is designed to ensure overall tests are

Figure: Test Flow

Unit and system test are tests to ascertain whether the functionality of the code or a specific part of the

code works as expected. They are performed by the developers themselves to test specific functionality

they have build. It prevents some faults caused by careless coding of the developers.

Functional test are typically performed at the functional level by those who have designed the functional

solution. It is determined whether the integrated components meet the functional requirements as

defined. The system test plan contains process test scripts. These scripts describe the entire process and

the possible exceptions and ensure that for every specific requirement as described is a relevant test

scenario to determine whether this requirement is completed. This ensures that all the system

functionalities will be tested.

Unit and

System Test

Functional

test

End user

preview Test

Technical Test End User

Preview Test

Production

Management

56

With end user preview test, intermediate test sessions of playbacks will be organized for various

employees from the business. Small group(s) end users will get the chance to get acquainted with the

new system and provide feedback.

Technical tests including:

1. Performance test: a response and a stress test will be performed. A baseline is determined against which performance is measured and compared.

2. Regression test: Performed on the whole process to verify whether the already working functionalities are failed, if the environmental factors or input/requirement changed

3. .Integration tests are also performed by the process team and serve to determine whether the communication and interaction of the various development components or cooperation with other system work as designed. This usually happens gradually after each component part to verify the correct solution and to solve individual problems quickly if necessary.

If building is completed and the whole process is implemented, a User Acceptance Test can begin. This User Acceptance Test is done on the basis of test scripts. These scripts describe the entire process and the possible exceptions. The test scripts are compiled on the basis of the process requirements document. After all, the whole system should be tested.

10.9.1 Communication Because of agile methodology emphasize direct communication, preferably Personal contact rather than written documentation, the process teams and development teams are housed in one location. A daily Scrum meeting will be held among team members to analyze the Status of the project. In this meeting the following key questions will be asked and answered by all team members:

What have you done since the last team meeting?

What kinds of issues are faced?

What do you plan to do by the next team meeting? During this brief session, team members inform each other what they did The previous day, what they plan to do today, and what kinds of issues they Are facing to if applicable. Furthermore, daily feedback session takes place. A feedback session lasts Half hour maximum, including feedback of results. During the feedback Session, the solution of issues mentioned in the scrum meeting will be tested. During this session, the following agenda will be followed:

57

Feedback from the results of the previous test;

Testing of the newly build functionalities;

Discuss the results and wishes;

Capture the test results and feedback to the developer Communication about the project will take place in two areas. In the first Place; there is communication between the project team members. Secondly, It is important to regularly communicate the business about the changes That will take place. 10.9.2 Communication within the project team: The members of the various project groups (process team, business analysts, developers etc.) will work closely together throughout the project, so Communication will frequently occur during the project. Nevertheless, it is Important to organize a regular meeting where the progress and problems Can be discussed. Hence it is necessary to have a weekly meeting.

10.9.3 Communication to the business: During the project it is very important that communication to the business is carefully taken, in particular to manage expectations. By regular updating about the progress and explaining what has already been built and how the final solution will eventually work, the business will get used to the coming change and the acceptance of the new system will easier be realized. An important form of communication is giving playbacks. During a playback, a (part of) process is presented to a group of stakeholders from the business. Since its initial playback generally is taking place quite soon after the start of the building, it is not intended to show a completely finished process but separate piece of functionalities. The final playback, however, can be Organized to show the end-to-end process before User Acceptance Test starts. In this way, the participants of the playback will progressively get a better picture of what is built and get a possibility to give feedback.

58

10.10 Project outcomes Reduced delivery schedules Automation of process or redesign of process can lead to less time to complete a process which generates significant cost savings in terms of optimized resource utilization. By shorting cycle time, it also increases productivity, with the same time and the same resources, more instances can be completed with BPMS. The following table indicates the improvement BPMS has achieved for Customer Registration Process:

Process before BPMS : 240 seconds

Process with BPMS : 90 seconds

Difference : 150 seconds (1 call)

It has resulted in a reduction of 52.000 calls between front office and back office which obviously increases the satisfaction of customers for faster handling.

59

11. Conclusion

The ultimate purpose of BPMS is to help a business organization to improve and optimize the process in cost, time, and quality. Furthermore, with BPMS, One97 Communication (Pay tm) is no longer running behind the facts. BPMS provides a real-time and historical insight to all processes within One97 (Pay tm). How the departments and processes are actually functioning can easily be monitored by BPMS .Agile software development provides a structured approach to implement a BPMS including identify, document, analyze, measure and improve the business processes, characterized by principles of iterative and incremental development, continuous testing, and frequent re-planning based on current reality. It serves as a proper methodology in a BPMS implementation project where the need for flexibility and adaptability of the organization is ingratiated, and where benefits such as cost savings and greater customer satisfaction are achieved. The Agile methodology is therefore considered to be successful suiting the business and IT needs of Business Process Management System implementation project for One97 (pay tm ) core process Customer Registration. Nevertheless, the project demonstrates some weaknesses of agile methodology in a BPMS implementation project. One vital weakness indicates that an accurate planning is hard to achieve due to a true nature of short iterations and the adaptive planning characteristic of the methodology. Recommendation towards this issue might be a precise and careful analysis Prior to iterations in the project initiation phase.

60

References

https://en.wikipedia.org/wiki/Business_process_management

http://one97.com/about-one97

https://paytm.com/

http://www.visual-paradigm.com/tutorials/as-is-to-be-business-process.jsp

http://www.nesscomp.com/learn-about-bpm/bpm-project-example/

Implementing a business process management system by Gongyao Zheng