I MPLEMENTATION PLAN

In this section, both aspects (technical and organizational) are considered to determine how to implement the algorithm in the workflow management system of APG (GPS2). First, the action plan for implementation is described in several steps. After that, a generalization of the action plan is suggested.

5.4.1 Action plan for implementation

Three steps are defined for the implementation plan of the algorithm. These steps are test, part implementation, and full implementation of the algorithm.

• Step 1: test

Since the result of the pilot-run is based on 5 days, the first step is to carry out the pilot for a longer period to conclude if the algorithm performs as expected and desired. E.g., the designed algorithm could be tested for 2 months, so the performance of the algorithm is also tested in weeks of “lussluiting,” and to check an improvement in the lead times of the items.

For user acceptance, the test could be performed in team SVP, because the employees have participated in the pilot, which is executed without big problems. The distribution is performed by an AK, so no additional distributor (and thus ‘to allocate stock) is needed.

During the pilot, a prototype of the algorithm is tested and all the required data is gathered by hand and copied into the tool. To avoid errors and for support of the distributor, the prototype is not suited to perform the test.

• Step 2: part implementation

When the results of the test are as expected, the tool could be implemented in the WFM system: GPS2. All the decision factors are automatically ‘read’ by an application that

provides the distribution. Since not all the decision factors are supported in GPS2, some tailor made applications are needed. For the decision factor ‘presence’ registration is needed that could be performed using the SAP software. In addition, the decision factor authorization is partly supported by GPS2. Authorization per process and for some teams, difficulty per work item is required. Finally, the distribution itself to the employees has to be created in an application, which ‘reads’ the required input and performs the allocation to the employee.

For user acceptance, the current distribution interface is still used, but added is just one column to support the distributor. In this column, the proposed employee’s name, based on the algorithm is copied. When the distributor starts with the distribution of work items, an employees’ name is proposed and could be used to distribute the items. Moreover, the distributor is still able to use his/her personal decision factors to whom the work item is allocated and so overrule the suggestion of the system. Of course, the aim is the use of the suggested employees’ name for the arrived work item.

• Step 3: full implementation

Since the target is to replace the distributor by the automated system, the distributor has to be removed. The work items are then distributed according to the algorithm without interrupting of the distributor by hand. To achieve this goal, the number of times the distributor follows the algorithm or ignores it, could be measured. When the percentage of applying the algorithm is high enough (e.g. 80%), the distributor could be removed, and the algorithm performs the distribution.

5.4.2 Generalization of the action plan for APG

The proposed plan is a setup of how to implement the algorithm in the organization

considering the user acceptance and the shortcomings of the technical side. In this section, a generalization of the action plan is described.

During the execution of this project, GPS2 is investigated for the support of the decision factors of the tool. At this moment, for AKP (one product in a sub-team of SVP) GPS2 is under development. Further development of GPS2 for the other teams will take more time than expected. In addition, the current distribution of work items is performed with GPS1.

Since the lead time of work items is improved in the pilot and expected is that it will during the test (step 1), the suggestion is to implement the algorithm in GPS1. Because the

architecture of GPS1 is much more difficult and the investigated support of the decision factors in GPS2 could not copied to GPS1, the implementation will take a bit longer using GPS1. When a general service is built which could be used by both GPS systems, GPS1 users

could use the service for distribution, and when GPS1 is replaced, the service is ready for GPS2.

In section 5.4, scenario 2 is implemented in a three steps approach. In the first step is determined that the test is executed at team SVP. In section 4.5 is described that only for team SVP a conclusion could be drawn, and for the other teams just expectations could be described. These points are considered in determining the sequence of implementation:

• The suggestion is to start a test with team SVP to check if the results are as expected, based on the Excel sheet. When the results are as desired, the algorithm needs to be programmed in a service called ‘distribution’ which could be used in GPS1 and GPS2. The algorithm has to be programmed in such a way it could be used in other teams as SVP as well.

• For user acceptance, the service ‘distribution’ is first implemented at team SVP, because the pilot has been tested in this team. As second, the algorithm could be implemented in ‘Register partner’ of team SPS. In this team, the distribution is performed by a trainee and the number of different processes is low. This team is classified as quantity, and scores low on the quality aspects. When the distribution is as expected in this team, for teams KTD, CBV-GBA, SBG-VUPO, SBG-Do and SBG-WO-uit the distribution mechanism could be implemented. All those teams are classified in the quantity group.

• The other teams of quantity: team IPHPT, MPG and VPS have their own workflow diagram. For teams MPG, a specific algorithm is designed, which is based on multiple contacts during a period with one client. Since scenario 2 does not consider the history, scenario 2 could not be used in team MPG. In addition, team VPS has split its team in two groups: “dagagenda” and “oud voorraad”. In the former group, the algorithm could be used, since a distributor allocates the items, whereas in the latter, the employees pull the ‘old’ work items, and so the algorithm is unsuitable. Finally, although team IPHPT distributes on the client number, scenario 2 could be used to allocate the work items to the employees. The employees of this team receive a wider range of clients (i.e., not only clients in a specific range). In practice this means, the decision factor last employee is not used.

• The scenario is created for the quantity teams. When standardization is required over all the teams, the scenario has to be used by the - as classified - quality teams. The scenario is unsuited for those teams but, an option could be that the quality teams will more focus on the quantity side. If this shift in performance for the quality teams is a realistic one, is material for future research.

5.5 Conclusion and limitations

In this section, the conclusion and the limitations of the implementation are discussed.

Concluded from the implementation section is that scenario 2 could be implemented in GPS2, even though some tailor made applications are needed.

The section 2.5, the model of WfMC is used as reference model for the products (Websphere Suite) used at APG for GPS2. In addition, the decision factors of the tool are mapped to this reference model and concluded is that the factors presence and authorization are not fully supported. Tailor made applications are needed to perform the distribution of work items as is designed in scenario 2. On the other side, organizational aspects are considered. APG scores low on the degree of adaptability of the organization, due to the structure, and for the impact of changes in the work distribution, an implementation method based on steps is used. The implementation consists of three steps: a test in team SVP to check if the results obtained in the test are as expected. The second step is to implement a service ‘distribution’ (which could be used in GPS1 and GPS2), that suggests an employees’ name, based on the designed

scenario 2. The distributor is at moment supported. The final step is to replace the distributor by the system, when the distributor does not overrule the system.

One of the limitations is that GPS2 is examined for the implementation of the scenario, while at this moment, nearly all teams use GPS1 as WFM system. In this project, GPS1 is not investigated to determine if scenario 2 could be implemented.

In addition, some of the decision factors are not supported by GPS2. This means - as is presented in the quadrant see Figure 19 - the implementation is difficult, and will take some time before the scenario could allocate the work item to the employee.

The decision factor ‘last employee’ is not taken into account, when work items distributed.

The quality and the lead time of the work item could be improved, when the employee knows the case and thus last employee is used as decision factor. During the test, an investigation is needed if this factor is important for the quantity teams.

Finally, the implementation plan is determined based on expected results. When the results of the executed test (i.e., the first step of the implementation plan) are not as desired, an

additional plan is not provided. In such a situation, future research is needed to identify the current distribution of work and if support for the distributor is still needed.

5.6 Summary

In this chapter, the reference model of a WFM system is used to map the products of the IBM Websphere Suite (used at APG for GPS2) and the four decision factors from the algorithm programmed in the tool. Further, a plan of action was described how to implement the scenario in the WFM system of APG. The research question at the start of this chapter was:

Q4: How will the designed algorithm be implemented in the workflow management system of APG?

In this chapter, the technical as well as the organizational aspect were studied. First, the technical aspects of (i) the IBM Websphere products used at APG and (ii) the factors of the designed algorithm were examined. Two factors of the algorithm were not fully supported by IBM Websphere (used for GPS2): the availability registration of the employees (i.e. the presence factor) and the authorization for each unique process ID. On the organizational side, the degree of adaptability of the organization was discussed and was assessed as low.

Changes in the organization do not fit the structure of APG. In addition, the impact of a change in the distribution was described, and was low. The presence of the employees has to be registered, which could be performed by management of the employees. For the

implementation, three steps were determined. First, suggested was to execute a test, which verifies the obtained results during the pilot-run. If the desired improvement is achieved, (part) implementation of the scenario in WFM could be started. As final step, the distributor could be replaces by the system, when the system provides the distribution without overrule of the distributor. For user acceptance, the current interface is used, but added is a column with the suggested employees’ name, to support the distributor.

Moreover, there was suggested to provide a service ‘distribution,’ which could be used by GPS1 and GPS2, because GPS2 is under development and the improvement in the lead time could be reached when it is implemented and used directly.