Do the textbook exercise 8.17. You do not need to apply all heuristics, but for every heuristic you apply, you should describe where and how you apply it to the process, why you apply it, and what are the benefits and drawbacks of applying this heuristic (think in terms of the "Devil's quadrangle"). You may therefore combine parts (a) and (c) of this question in one discussion. (20 points)

Exercise 8.17: Consider the equipment rental process described in Example 1.1 and the corresponding issues documented in Example 6.5 (a) Apply the redesign heuristics from Appendix A in order to address the issues documented in Example 6.5. (b) Capture the resulting to-be model in BPMN. (c) Explain the impact of the changes you propose in terms of the performance dimensions of the Devils Quadrangle.

Example 1.1 Equipment rental at BuildIT. BuildIT is a construction company specialized in public works, such as roads, bridges, pipelines, tunnels and railroads. Within BuildIT, it often happens that engineers working at a construction site (called site engineers) need a piece of equipment, such as a truck, an excavator, a bulldozer, a water pump, etc. BuildIT owns very little equipment and instead it rents most of its equipment from specialized suppliers. The existing business process for renting equipment goes as follows. When site engineers need to rent a piece of equipment, they fill in a form called Equipment Rental Request and send this request by email to one of the clerks at the companys depot. The clerk at the depot receives the request and, after consulting the catalogs of the equipment suppliers, selects the most cost-effective equipment that complies with the request. Next, the clerk checks the availability of the selected equipment with the supplier via phone or email. Sometimes the selected option is not available. In these cases, the clerk has to select an alternative piece of equipment and check its availability with the corresponding supplier. After finding a suitable and available piece of equipment, the clerk adds the details of the selected equipment to the rental request. Each rental request has to be approved by a works engineer, who also works at the depot. In some cases, the works engineer rejects the equipment rental request. Some rejections lead to the cancelation of the request, i.e., no equipment is rented at all. Other rejections are resolved by replacing the selected equipment with another equipmentsuch as a cheaper piece of equipment or a more appropriate piece of equipment for the job. In this latter case, the clerk needs to lodge another availability request. When a works engineer approves a rental request, the clerk sends a confirmation to the supplier. This confirmation includes a Purchase Order (PO) for renting the equipment. The PO is produced by BuildITs financial information system using information entered by the clerk. The clerk also records the equipment rental in a spreadsheet that is used to monitor all ongoing equipment rentals. In the meantime, the site engineer may decide that the equipment is no longer needed. In this case, the engineer asks the clerk to cancel the request for renting the equipment. In due time, the supplier delivers the rented equipment to the construction site. The site engineer then inspects the equipment. If everything is in order, the site engineer accepts the engagement and the equipment is put into use. In some cases, the equipment is sent back because it does not comply with the requirements of the site engineer. In this case, the site engineer has to start the rental process all over again. When the rental period expires, the supplier comes to pick up the equipment. Sometimes, the site engineer asks for an extension of the rental period by contacting the supplier via email or phone 1 to 2 days before pick-up. The supplier may accept or reject this request. A few days after the equipment is picked up, the equipments supplier sends an invoice to the clerk by email. At this point, the clerk asks the site engineer to confirm that the equipment was indeed rented for the period indicated in the invoice. The clerk also checks if the rental prices indicated in the invoice are in accordance with those in the PO. After these checks, the clerk forwards the invoice to the financial department. The financial department eventually pays the invoice.

Example 6.5 We consider again the equipment rental process described in Example 1.1 and the stakeholder analysis summarized in Example 6.4. As a result of the stakeholder analysis, the analyst concluded that the issues raised by the process owner were echoed by the customer (site engineer) and the other process participants. The analyst also found three other perceived issues: one raised by the site engineer (delays in the rental process) and two by the clerk (unclear site engineer requirements and inaccurate or incomplete catalog data). The analyst decided not to include these perceived issues in the initial issue register, because they appeared to be possible causes of the issues raised by the process owner, rather than top-level issues on their own. Accordingly, the analyst proceeded to analyze the issues raised by the process owner by gathering additional data about their frequency and the impact of each occurrence of those issues. Based on the collected data, the analyst prepared the issue register Question Issue or factor? An issue register may contain a mixture of issues that have a direct impact business performance as well as other issues that are causal or contributing factors of issues that then impact on business performance. In other words, the issue register contains both issues and factors. For example, when preparing the issue register of the equipment rental process, one could be tempted to include entries such as the following ones: Clerk misunderstood the site engineers requirements for an equipment. Clerk did not select the correct equipment from the suppliers catalog due to inattention. Clerk indicated an incorrect delivery date in the PO. Supplier did not deliver the equipment that had been ordered. Delivered equipment is faulty or is not ready-for-use. Supplier delivered the equipment to the wrong construction site or at the wrong time. The equipment arrived five working days after the site engineer had requested it, but the site engineer needed the equipment earlier. All of the above issues are possible causal or contributing factors of a top-level issue, namely Equipment is rejected by the site engineer. The fact that the site engineer rejects the equipment creates a direct impact for BuildIT, for example in terms of delays in the construction schedule. Meanwhile, the issues listed above have an indirect business impact, in the sense that they lead to the equipment being rejected and the needed equipment not being available on time, which in turn leads to delays in the construction schedule. When an issue register contains a combination of issues and factors, it may be useful to add two fields to the register, namely caused by and is cause of, that indicate for a given issue, which other issues in the register are related to it via a cause-effect relation. This way it becomes easier to identify which issues are related between them so that related issues can be analyzed together. Also, when an issue X is a factor of an issue Y, instead of analyzing the impact of both X and Y, we can analyze the impact of Y and in the qualitative and quantitative impact fields of X we can simply refer to the impact of Y. For example, in the impact field of issue Clerk misunderstood the site engineers requirements we can simply refer to the impact of Equipment is rejected by the site engineer. Alternatively we can adopt the convention of including in the issue register only top-level issues, meaning issues that have a direct business impact, and separately, we can use why-why diagrams and cause-effect diagrams to document the factors underpinning these top-level issues. This convention is followed in the rest of this chapter, meaning that the issue registers shown below only contain top-level issues rather than factors. The analysis and documentation of the causes of each issue is undertaken outside the issue register by means of root cause analysis techniques, which we will discuss later in this chapter. Hence, for each issue we put in an issue register, there is at least one stakeholder who is directly impacted by the issue, and hence we can do an impact analysis of each issue. In the above example, the number of issues is small. In a large organization, a stakeholder analysis of a core process can lead to dozens of issues. Moreover, when we engage in a BPM program covering many processes, the number of issues across all processes can be in order of hundreds. In these cases, it pays off to use an Issue Tracking system to maintain the issue register. An issue tracking system is a collaboration tool that allows its users (among other things) to create, document, edit, and comment on issues, and to generate filtered and sorted lists of issues according to a range of criteria.

Example 6.4 Consider the equipment rental process discussed in previous examples. The owner of this process is BuildITs purchasing manager. The purchasing manager is concerned by the growing volume of equipment rental expenses. In the past year, these expenses have grown by 12% whereas the overall volume of construction activity (measured by revenue) has grown by only 8%. The purchasing manager launches an improvement effort to bring down the rental expenses by 5%. This objective is in line with overall target set by the CFO of 5% of company-wide cost reductions. An analyst is asked to review the rental process. The analyst identifies the following stakeholders: Customer: the site engineers. Process participants: the clerks, the works engineers and the accounts payable team at the financial department (who handle the invoice). Process owner and operational managers: purchasing manager, construction project managers, accounts payable team lead. Upper management: the CFO, acting as the business sponsor as part of the broader mandate for cost reduction. External party: the equipment rental suppliers. After interviewing the process owner, the analyst notes two perceived issues in the process: Equipment is often hired for longer than needed, leading to inventory waste. Penalties are often being paid to the suppliers due to: (i) equipment being returned upon receipt because it was not suitable for the job; and (ii) late invoice payments. In both cases, these penalties arise from wastes of type defect. The above observations illustrate that oftentimes, issues raised during the stakeholder analysis (particularly issues raised by the process owner and the process participants) are associated with wastes. Hence, the output of waste analysis can be helpful when engaging in a stakeholder analysis. The analyst decides to start by gathering data from the site engineer, the clerk and the works engineer, given their central role in the process. He proceeds with interviews in order to derive deeper qualitative insights. The interviews are partly driven by the waste analysisin particular transportation, waiting, and defects, as well as the inventory waste raised by the process owner. After interviewing three site engineers, the analyst retains that the main concern of the site engineers is the delay between the moment they create an equipment rental and the moment the corresponding equipment arrives. The analyst determines that this delay is of 3.5 working days on average (sometimes three, sometimes 4 days, rarely less or more). The site engineer also confirmed that sometimes they have to reject equipment when they receive it because the equipment is not suitable for the jobeven though they claim that in their requests, they clearly indicate what type of equipment is needed and for what purpose. On the other hand, the clerks main concerns are: Lack of clarity in the requirements they receive from the site engineers, which somehow contradicts the viewpoint of the latter. Inaccurate and incomplete equipment descriptions in the catalogs of the site engineer vendors. Slow turnaround times when asking the works engineers to approve the rental requests. The works engineers echo the concerns of the purchasing managers that site engineers are sometimes retaining the rented equipment for longer than strictly needed (inventory waste). They are aware that sometimes the delivered equipment does not match the requirements of the site engineers and is hence returned, but they do not perceive that this is a major issue. The accounts payable team claims that they are aware of the fact that penalties are being paid for late invoice payments. However, they claim that it is not their fault. In 98% of cases, invoices are being paid at most three working days after their internal approval. The accounts payable department claims that it is not possible to do faster, and that in any case, the penalties of late invoices would still occur even if they could reduce the payment time from 3 days to 2 days. The analyst also interviewed two suppliers, who echoed the fact that sometimes the delivered equipment was rejected by the site engineer, and that invoices took too long to be paid. The suppliers additionally perceived that there is a lack of integration between their systems and the ones used internally at BuildIT. A supplier commented that this lack of integration could be one of the reasons why mistakes were being made along the way. The analyst retains that the issues raised by the process owner are being echoed in several ways by other stakeholders. The analyst also takes note of the slow cycles times reported by the site engineer, and the misunderstandings and data quality issues raised by the clerk.