Agile bpsdm

Editor's Notes

• #10: We examined the business processes in our organization. The findings are: A task which is automated does not completely fulfill the actual task. Therefore, some parts of the task should be completed manually. Some tasks are not automated because they are not specified enough. The interactions between tasks are not automated because each task may have a different data exchange format. There are no workflow automations for the cases because the workflow implementation takes very long time. In addition, even if it has been implemented before the implementation is not used because it does not adapt to the fast changing environment.
• #11: We implemented some workflows using the waterfall method in our organization. Each of them took approximately 1-year development time. During the development we encountered some problems. These are: The main problem was the missing requirements. Actually we noticed this problem when we wanted to go live. At that time, some ignored actors in the process or unknown actors of the process appeared. This caused the review of the requirements specification, redesign and reimplementation. Another problem was that some additional tasks were required to be added to the processes. Also, roles of the tasks changed. Requirements changed at live
• #12: Adapting to the changing environment is a must for business processes. Traditional technologies such as workflow systems lack the flexibility and agility that modern business processes need. Therefore, business process management should be agile and flexible.
• #13: We tried to implement some business processes using agile methodologies. However, we realized that some problems occur because of the characteristics of business processes and our organization. The basic problems of using agile methodologies are: Business process automations are usually more complex than standard software automations. Therefore, a 2 or 3-week iteration times do not fit to business processes. A bit longer period seems to be suitable for them. In our organization a person deals with more than one project at a time. For example s/he can be involved in three projects. Then daily meetings are time consuming and confusing. Its period and structure need some arrangements.
• #14: An Agile Methodology for Business Process Development A special development methodology is needed. Requirements should be gathered better. The methodology may include some prototyping. Agile approaches may be included to determine the actual requirements of the process. Agile approaches will probably decrease the development time. Template usage Role modeling Site inspection The encountered problems and the customer requirements address that a development methodology is needed. Since missing requirements can cause reimplementation, gathering of the requirements is very important. Therefore: The methodology may include some prototyping. Agile approaches may be included to determine the actual requirements of the process. Agile approaches will probably decrease the development time. In conclusion, we decided to develop an agile methodology for business process development. Agile approach Fast development, better requirements Prototyping Fast development, better requirements Template usage Fast development Role modeling Better requirements Site inspection Better requirements
• #16: In this methodology, going to pilot is taken as a stage. Because, we have seen that pilot application is very important for developing processes. Basically, it provides: a preparation for live and increases the success of the implementation. Moreover, it provides real problems to development and gives time to solve these problems in a relatively low stressed condition.
• #19: Role Modeling In the analysis stage, the most important work task for the business process automation is the determination of all the roles of the business process. All roles should be determined as much as possible. Otherwise missing roles can cause redesign of the process and increase the total development time. On the other hand, site inspection may help to determine missing roles. Site Inspection and Roles The requirements and the problems should be inspected in their own places. Site inspection assists to build quality requirements. In business process development, determining of all the roles is important. Site inspection may also help to determine missing roles. Use Cases Requirements are gathered through use case diagrams. We employ use cases because: They are simple. All the stakeholders can understand them easily. They show actors and use cases. The optimal roles of the process can be derived from the actors of the use cases. Moreover, the optimal activities of the process can be derived from the use cases. Templates and Their Usage Sub-process templates are like general purpose functions. Common parts of processes are combined and developed as a template. Then the template is used for the related part of a process. Process templates are used to develop a family of processes. These are general-purpose business processes designed for similar cases. For example, a template can be prepared in which a read-only form can be approved by a few actors. Any kind of template usage is encouraged because templates can accelerate the development process. In construction stage, sub-process templates and process templates can be used if suitable. In other stages of the life-cycle other templates may be employed. For example, if a template for gathering requirements was constructed, it would be used in analysis stages of different projects. Spike Solutions We have seen that spike solutions speeds up development. Actually they train the stakeholders and provide to gather requirements better. Main Input Output Screen For the fast implementation of the process model, it is assumed that a common screen is used in all the steps of the process model. In small-team meetings, basic input output requirements are determined with the process owner department. We will call this screen as main input output screen. At that time a spike solution may be implemented through the main input output screen. Sponsorship This methodology requires sponsorship. Actually, sponsorship is very significant in all projects. Especially, for business processes sponsorship is a must. Because, usually many organizational units are included in business process development and the number of the stakeholders is plenty. This increases the complexity of the project and the conflicts should be solved by the sponsor when needed.
• #20: Process Modeling We use Business Process Diagram (BPD) of Business Process Modeling Notation (BPMN) to model the processes. Because, according to our analysis the model should be simple and should be understood easily by all the stakeholders of the process. Also, the model should simply represent the parallel and optional branching of processes. This also is held by the BPD using the parallel and xor branch symbols. Advantages of BPD BPD has the following advantages over the other modeling methods: It is designed for business process modeling. It s simple. It shows parallel executions simply. It shows serial executions simply. It does not contain formal steps so it is easy to understand. For example, in Petri nets there are states and in EPC diagrams there are events. All the stakeholders can understand it easily. The Initial BDP The initial BPD is firstly reviewed with the process owner department in the small-team meetings. Then BPD is revised with the other roles of the process model. After obtaining a mature process model, it is reviewed by all the stakeholders. Namely, it is reviewed in a whole-team meeting. EPC: Aris Event-driven Process Chains (EPC)
• #21: Umbrella Activities In addition to the framework activities, there are umbrella activities which are spread over the entire methodology. In other words, umbrella activities are related to nearly all the framework activities. The umbrella activities are: Project management, Training, Keeping history. Light Project Management This methodology encourages a light version of project management. Actually, the project is managed by a project leader. The main job of the project leader is to track the backlog list and activate the iteration bases with teams. Project leader also deals with sponsorship. He tries to keep alive the sponsorship for the whole project. Project leader also organizes the whole-team meetings. Training Training is important so that first parts of the meetings are used for training. The followings are the important reasons: Training improves the gathering of quality requirements. Training informs people about the process and decrease the development time. Training remembers the decisions taken before, and people do not need to solve again the solved problems. Keeping History History of the business process automation is important. This history is kept in the Iteration Base 0 document. This document is also called history document. Main activities of the automation, and the relations and the interactions between the iteration bases are recorded. Each team can add items to this document. Keeping history has the following advantages: It shows the state of the automation. Therefore all stakeholders can track the automation by following the history document and can adapt themselves to the new conditions. Different team members can use it as a means of communications. One team member provides information about their iteration base and members of other teams can access this information. The history document shows the relations and the interactions between all the iteration bases.
• #23: Documentation Each iteration base has at least one document with the same name with the iteration base. This document is called iteration base document. Being the first iteration, Iteration Base 1 document keeps the project plan of the automation and very first requirements of the automation. In this iteration base, nearly all the work is done within the department of the process owner. Although a business process crosses over many organization units, the process owner department is very important for the automation. The motivation of the process owner to execute the business process plays a key role in the success of the automation. In training parts of the meetings, people are informed about the business processes. Especially, the process being developed is shown to them. If the process has not been developed enough, then prototypes of the process can be shown. If both of them are not available, then other processes can be demonstrated. In the training part, the decisions taken before are repeated also. The aim of this training part is to reduce the total development time.
• #24: The Lifecycle of The Methodology The lifecycle has 6 stages. These are analysis, design, construction, going to pilot, going to live, and diagnosis. The transition from one stage to another is not strict. In other words, the boundaries between the stages are not precise. For example, when the analysis stage has not been totally finished, the design stage can begin, and also construction stage can be started. Namely, concurrency is allowed. The Stages and Tasks of The Methodology The stages and their interactions with iteration bases are shown in the following figure. Tasks of the stages are handled in iteration bases. Each iteration base is conducted with a small team including customer. Training the customer is important as well as sponsorship, keeping history and project management. At the end, the product is developed that results in customer satisfaction. Iteration Base List & The Backlog List Like Scrum, the list of requirements is kept. For each iteration base, a subset of the list is implemented, which is called as an iteration base list. In other words, an iteration base list is the set of tasks in the iteration base. An iteration base list is determined before an iteration base or in the first week of the iteration base. All the tasks of a project form the project task list. The remaining tasks of the project form the backlog list. In the beginning of the project, the project task list and the backlog list are the same. New tasks can be added to the backlog list and some tasks are dropped from the backlog list if they have not been needed so far. An iteration base can take some tasks from the backlog list and uncompleted tasks remain it puts those tasks to the backlog list again. In time the backlog list diminishes. If the backlog list is finished, the project has also finished. The Number of Iteration Bases More than one iteration base can be activated at the same time. A person would attend more than one small-team meeting in a week. According to our experiences, more than three meetings in a week are excessive and decrease the development efforts. For this reason, the project leader should not activate more than three iteration bases related with the same person. Second Increment Usually the detailed analysis of the requirements is conducted in the iteration bases related with the second increment. For each organization unit or a group of organization units, an iteration base can be started in the second increment. Use cases are detailed in these iteration base 2.X’s. Especially, the input output requirements of the use cases are determined. Iteration Base 3 Generally, the consolidation of the requirements is done in Iteration Base 3. In this iteration base, the work products of the Iteration Base 2.X’s are used, all the use cases are consolidated, and the process model is drawn. Moreover, the basic input output requirements of a step in the process model are determined. Iteration Base 0 An iteration base document describes the related iteration base. In an iteration base document, everything important in that iteration base is expressed. If that iteration base uses other documents, they are also referenced in the iteration base document. There is also a general document called “Iteration Base 0”. This document keeps the history of the automation. In other words, every item is added to this document with a date. This document also glues all the iteration bases in the automation. In other words, the relations and interactions between the iteration bases are explained in this document. Iteration Base 0 Document General information about the automation is also kept in the Iteration Base 0 document. For example, the storage locations of the documents for the projects are kept in that document. In addition to this, which tools are used and for what purposes they are used are kept in the document. Also the document names holding use case are held in the document. The place of the process model diagram is another item for the document. The development tool and the place of the source codes of the automation are held further in the iteration base 0 document. The Iteration Base 0 document can be a means of communication if there is more than one team in the automation. All the teams can track the automation by following the Iteration Base 0 document.
• #25: Whole-team Meetings There are also whole-team meetings. Nearly all the stakeholders attend to these meetings. These meetings are also structured as training and discussion parts. The whole-team meetings are conducted for consolidation purposes. Different dimensions of a subject are consolidated in whole-team meetings. Actually, each different dimension is conducted in an iteration base and an iteration base is activated for consolidation of the different dimensions. In these consolidation iteration bases, whole-team meetings are organized and take common decisions about the process. The whole-team meetings are usually two times longer than small-team meetings. In other words, 30 minutes are used for training part and 90 minutes are used for discussion. Totally, a whole-team meeting takes two-hour period. Properties of Whole-team Meetings Number of the whole-team meetings should be less. In other words, these meetings should be organized when consolidation is needed or when the project needs a refreshment, i.e. drawing attention to the project again. We recommend a whole-team meeting in every 5-week period. This is because an iteration base lasts nearly 5 weeks so at the end of the parallel iteration bases a consolidation would be required.
• #27: Construction of the Estimation Formula The formula should be simple in order to estimate the development efforts more accurately, and in order to avoid biasing. Therefore, we use only two parameters to represent business process automation effort. Actually these two parameters are used to express the size of a business process. From this point of view, we can consider this formula as a one parameter formula. The simple value showing the size of a business process is the number of steps in the business process. Therefore, the first parameter is the number of tasks in a business process. The second parameter is used to represent complex business processes. Complex tasks in a business process increase the efforts. Usually, tasks which require data input from users other than simply selecting an action are complex. We will call these tasks as interactive tasks throughout this work. Therefore, for interactive tasks we use the second parameter. In summary, we build an estimation formula with only one parameter. This parameter is simply the addition of the number of steps and the number of interactive steps in a process. Namely, this formula takes the size of the business process as a parameter and gives the effort spent for the business process.
• #28: Developed Business Processes using the Classical Methodology We have developed four business processes: The first one is for the approval of purchase requisition. The second one is for insurance claim. The third one is for material request from warehouse. And the last one is for the approval of purchase order. Estimate the Development Effort We have kept the manpower values spent for the development. And we have kept the models of the business processes. From these data, we tried to derive a formula to estimate the development effort. Using this formula, we can estimate the development effort of a business process as if the business process was implemented using the old methodology. The Estimation Formula (I) The table shows the number of steps in the implemented business processes. It shows also the number of interactive steps in the processes. The last column shows the total implementation effort in person-days. According to the table a simple estimation formula is derived using least squares approach. The sum of the number of steps and the number of interactive steps is taken as an explanatory variable of the simple linear regression. The most important characteristic of a business process is the number of the steps in that business process. Therefore, number of the steps is used in the line equation. Complexity of a business process affects the effort spent. For this reason, again the number of steps is used in a similar way in order to reflect the complexity to the line equation. In other words, number of the interactive steps is added to the explanatory variable of the equation.
• #29: Magnitude of Relative Error The effort estimation formula can be analyzed using MMRE. The formula for the Magnitude of Relative Error (MRE) is: MRE = |actual_effort – estimated_effort| / actual_effort MMRE = average percentage of MRE PRED(N) Another analysis method for estimation accuracy is PRED(N). The formula of PRED(N) is: For PRED(30), the accuracy of the estimation formula is calculated. The result is below. This means that all the estimates are within 30 percent of the actual. PRED(30) = 100%