Improving the use of production planning and scheduling systems

(1)

Improving the use of

production planning and

scheduling systems

Master's thesis Technology & Operations Management

June 2015

Student: Angèle Croes

Student nr: 1854895

(2)

Abstract

There is not enough research on how the performance of information systems in use can be improved. Even if an information system has been designed to maximize value, it is often not used as was intended or the situation has changed and the design does not reflect the changes. The design-actuality gap model is one model that shows the relationship between the reality and the design, however it was never researched how this model can be used when trying to make improvements. This research designed an improvement framework that incorporated the gap model. The scope was limited to improvement of operational planning systems. The framework was developed based on literature and put into practice at The Coatinc Company Groningen.

The framework includes analysing the system itself as well as the manner in which it is used, followed by defining possible improvement projects. From the projects, one is chosen based on a cost-value analysis. The chosen project, which includes a system and/or process redesign, is implemented and evaluated. For this research a prototype was designed instead of implementing the changes. The evaluation of the prototype indicated that the suggested changes should indeed be implemented.

(3)

Preface

(5)

1 Introduction

The Coatinc Company in Groningen (TCCG) is part of a larger holding company comprising several other companies that provide surface treatments. TCCG specializes in hot-dip galvan-ization, although their customers can also make use of surface treatments provided by other companies within the holding. They pride themselves on honouring agreements internally as well as externally. Therefore, it is important that their customers’ products are completed by the agreed upon due date. The planner at TCCG is the one who makes decisions on when orders have to be processed. In order to achieve this, he is supported by the planning module of a larger information system TCCG has developed. However, the management of TCCG is of the opinion that the planning module is not living up to its full potential, since some functions are not being used or other are being used incorrectly.

The issue of a system not being used in a manner that maximizes its value is not limited to planning systems, but is also present in other types of information systems. Braley Consulting Services [1] is a firm that has done research among their customers and found that information systems of many companies do not add value and can even impair the company’s operations due to the manner the systems are used. This issue has not been identified in scientific researches. This may be because research on information systems tends to focus on the development and implementation stages. As Botta-Genoulaz et al. [2] mentioned, there is a lack of research that focuses on systems that are already in use. This research attempts to bridge this literature gap by looking into how information systems used for planning purposes can be improved upon. Next, the relevant literature is briefly discussed.

Kositanurit et al. [3] determined that the reason information systems do not live up to expect-ations is due to poor user performance. They also show that user performance is related to the task technology fit. The task technology fit model of Goodhue and Thompson [4] is based on the notion that characteristics of the task and of the system should fit together in order for the system to successfully assist the user in completing his tasks. This model has been applied numerous times to different technologies, such as data warehouses [5], software maintenance tools [6] and mobile information systems [7]. Another model that agrees the fit between technology and task is important, is the design-actuality gap introduced by Heeks [8]. The difference between the two models is that Heeks’s model does not only look at the task, but also the context in which the system is used. It was developed to determine success or failure of information systems in developing countries [8], but since then has been applied to determining performance of health information systems [9] and of call center information systems [10] among others. Based partly on the latter two researches, this paper aims to apply the design-actuality gap to planning systems. Determining what is causing the performance of an information system to be lower than expected is only one step towards improving the use, addressing the causes is also required. Most of the literature on this subject focuses on standard systems such as enterprise resource planning (ERP) systems, since these kinds of systems almost never fit perfectly with the business context they are placed in [11]. Researches such as the one from Luo and Strong [12] classify the different approaches one can use to improve the fit between an ERP system and business context. Even though ERP systems cannot be equated to planning systems, the underlying ideas still apply since the goal remains the same: to create a better fit between the system and business context. A more in-depth discussion of the literature is provided in the next section.

(6)

concurrently by researching TCCG’s production planning system. The main objective of this paper is to answer the following research question:

How can the use of operational planning systems be evaluated and improved upon by using the design-actuality gap model?

In the next section a theoretical framework is provided for the research and the research question is divided into sub-questions. Next, the research methodology is given followed by the findings from the research at TCCG. In the discussion section these findings are discussed and compared to existing literature. Finally, a brief summary of the contributions of this research along with its limitation are provided in the conclusion section. This last section also gives direction for further research on this subject.

2 Theoretical background

This section elaborates on the concepts of production planning and scheduling systems and information system utilization. Additionally, the design-actuality gap and relevant system im-provement frameworks are discussed. Based on prior literature, sub-questions are formulated to indicate how the main research question can be answered. Finally, the regulative cycle from van Strien [25] is briefly described as an alternative manner to (re)-design a system or process.

2.1 Production planning and scheduling system

Planning and scheduling concerns the allocation of resources. Planning is often used to indicate the long term variants, which are tactical and strategic planning. Scheduling is the short-term variant, also known as operational planning [13]. In this research, the focus lies on operational planning. Operational planning often begins when an order has been received. At TCCG they only plan the date on which an order has to be produced. Other operational planning decisions may include batching of orders and assigning orders to a specific machine or employee [14]. Operational planning is considered one of the most important planning processes, since it has a direct effect on a company’s actual performance [14]. It can also be quite complex, especially when there is a high degree of detail required. This complexity is why many use an information system to facilitate the operational planning process.

All planning systems are considered decision support systems, in the sense that their primary function is always to support the planner. Nonetheless, there is still a clear distinction to be made between planning systems. Some systems only provide the planner with tools to help him make decisions and others computerize the whole planning process and the role of the planner is reduced to controlling the plan before execution. Often these advanced planning systems are interfaced with an execution system that can set the plan in motion once approved [14].

2.2 Information system utilization

(7)

utilization as using features that were developed and paid for. Thus, the only way to get the maximum value out of a system is to fully utilize it.

Maximum system utilization, which is synonymous with maximum system performance, is the goal. Both the design and the user can be the reason why maximum system performance is not achieved. This is where models that incorporate these elements come into play. The task-technology fit model of Goodhue and Thompson [4] considers the fact that not only should the user utilize the technology, but the technology has to fit the task it was designed for as well. This model looks at task, technology and individual characteristics when assessing if there is a fit. The limitation of this model is that it bases the evaluation on a limited number of characteristics. For example, individuals are only characterized by their computer literacy [17]. Even though the characteristics are validated, they cannot be used to improve the systems since there are many things not considered. Heeks [8] also recognized that system performance is dependent on both the design and the user and incorporated this in his design-actuality gap model. While the task-technology fit model focuses on the fit that exists, the design-actuality gap model focuses on specific things that are causing the gap. This is the reason that the design-actuality gap model is better applicable when trying to make improvements, which is the objective of this research.

2.3 Design-actuality gap

The design-actuality gap was first used by Heeks [8] in order to assess risk of information system projects in developing countries. He later showed that the same model can also be applied post-hoc to determine how well the system is used [9]. The model is used to determine the gap between what was designed for and what the current situation is. This is done through comparing the design and the reality on seven dimensions. These dimensions, known as the ITPOSMO dimensions, are shown in figure 2.1.

(8)

A short, general description of each dimension is given below. However, these are very broad definitions. What exactly these dimensions include and how they should be measured is dependent on the type of information system to be studied. Heeks [9] for instance specified them for health information systems, just as Baraka et al. [10] specified them for call center systems.

1. Information: the quantity and quality of formal information as well as informal information 2. Technology: the performance of the hard- and software associated with the system, as well

as any extra technology that is necessary

3. Processes: activities of users and others; information-handling and decision-making 4. Objectives and values: manifestation of culture and politics

5. Staffing and skills: quantitative and qualitative aspects of competencies

6. Management systems and structures: formal and informal system in place to aid manage-ment as well as the organizational structure

7. Other resources: mostly time and money

Before the design-actuality gap model can be applied to operational planning systems, the dimensions have to be specified in more detail. Thus, that is the first objective of this research: Sub-question 1. What definitions of the ITPOSMO dimensions are appropriate when assessing operational planning systems?

While Heeks [9] defined the dimensions as they pertain to health care systems and used those dimensions to analyse the gap, Baraka et al. [10] took another approach that is more generalizable. This approach consists of designing survey questions that can then be used to give each dimension a score. The current research aims to determine a generalizable way that the design-actuality gap can be used, thus the dimensions should be scored. Sub-question 1 not only has to define the dimensions but also provide a scoring model that is used for answering sub-question 2.

Sub-question 2. How do the design and the actuality score on the ITPOSMO dimensions? The power of the design-actuality gap lies within the systematic identification of areas that cause a decrease in performance or failure of the information system. Following this train of thought, it is these areas that require improvement. Thus once the dimensions are scored, the next task entails identifying what causes the gap. This leads to the next sub-question.

Sub-question 3. Based on the ITPOSMO dimensions, what are the areas of improvement?

2.4 System or process improvement

As mentioned earlier the theoretical contribution of this research is not limited to adapting the design-actuality gap for planning systems, but also to design a method that can lead to better system performance. This includes selecting which improvement project to continue on with, executing the project and performing an evaluation afterwards.

Improvement selection

(9)

framework was developed by incorporating several propositions, some of which are also valid for single project selection. The first relevant proposition is that all projects have to be evaluated in the same manner in order to promote fairness. Also both resources and their time-dependent nature should be taken into account. While these are general guidelines, this still does not lead to a selection. Chan et al. [19] on the other hand did go into more detail, but their work was based on choosing an integrated system. Though an investment decision is a bigger decision, insights from their research show what should be taken into account when selecting a project. What becomes clear is that the importance of the outcome is one of the essential factors. Not only should it be important to the user, but to everyone who is affected by the planning. This includes management, who has to safeguard the company’s bottom-line, and people from the production department, who have to execute the actual planning.

Sub-question 4. What is the value of each improvement project for the stakeholders?

The expected value is not enough to base a decision on. Every project requires resources to be invested, as was pointed out by Archer and Ghasemzadeh [18]. These resources include time, which is how long it takes before the project is completed and also the effort that has to be exerted in order to complete the project.

Sub-question 5. How much time and effort would be needed to complete each improvement project?

Taking both the value and the cost into account hopefully leads to significant and fast im-provement in system performance.

Improvement method

While looking at the improvement project, it should also become clear what kind of improvement is necessary. The goal is to remove or decrease the mismatch between the system and the reality in which the system is used. As mentioned in the introduction, the literature available is based on ERP systems. There is consensus among researchers that ERP systems can either go through technical customization or the organization can adapt through process customization [12]. While technical customization is subdivided into different types of customization that are specific to ERP systems [20], the two main types of customization are applicable to all information systems. Some problems are best solved by changing the system and others by changing the process in which the system plays a role.

Sub-question 6. Is technical or process improvement the best course of action?

It does not have to be one or the other, and at times a combination of the two is most suitable. Either way, any change starts with setting up requirements. In the case of technical improvement, where improvement can be viewed as software development, it is common to start off the project with requirements engineering. Requirements engineering entails documenting what capabilities the proposed system should have [21]. The same technique can and should be applied for business process (re-)design as well according to Poels et al. [22].

Sub-question 7. What are the requirements for the improvements?

(10)

Improvement evaluation

Part of any (re)-design project is evaluation of the designed artefact [23]. This is needed to determine if the outcome has lived up to expectations. As that is the goal of the design-actuality gap model, the best evaluation method is to perform the gap analysis once again. Although this time, it would suffice to only update the scores from the previous analysis.

Sub-question 8. To what extent has the improvement project closed the gap?

According to Vaughan [24], no organizational change can happen without secondary con-sequences, which are changes that were not planned for and can counter the planned change in some cases. Organizational change ranges from major changes like mergers and restructuring to minor changes such as changes to the information system and processes. Therefore, these secondary consequences are of interest when trying to close the gap as well and should not be ignored but addressed during the evaluation phase.

Sub-question 9. What are the secondary consequences of the improvement?

2.5 Research framework

Based on the theory provided in this section, a research framework is developed. The framework is shown in figure 2.2.

Figure 2.2: Research framework of continuous system improvement

The framework depicts a continuous cycle, because the gap cannot be closed with only one improvement project, therefore smaller improvement projects are defined. Improvement selection leads to implementing the easiest and most valuable changes first. There may come a time when the effort required to implement change is deemed too high compared to the benefits. Even then, the gap analysis should be performed after some time again since the situation can change. Due to time constraints, this research did not go through the improvement cycle multiple times, but only once. If one cycle can lead to improvement, logic dictates repeating the cycle can also lead to improvement.

2.6 Regulative cycle

The framework is proposed as a new method to make improvements to planning systems and/or process. However the ideal system and accompanying process can also be retrieved by using the regulative cycle proposed by van Strien [25]. This cycle, shown in figure 2.3, can be used to solve design problems.

(11)

Figure 2.3: The regulative cycle from van Strien [25] Design problem

• Who are the stakeholders?

• What are the goals for each stakeholder?

• What are the critical success factors (CSFs) for each goal? Diagnosis/analysis

• What are possible causes of the difficulty of resolving a CSF? • What are the quality attributes?

• Is there an order-dependency in which the CSFs should be treated in order to achieve a properly working solution?

Design solution

• Which solution alternatives are available?

• Can old solutions be assembled to build a new solution?

• Can (and must) a new solution be invented completely from scratch? Implementation

No questions were formulated for this phase, since this is the execution step. Validation

(12)

• Are all of the CSFs met?

– If not, what are the trade-offs?

• How scalable is the solution/implementation? • How well does the solution perform?

• Were any new CSFs encountered in the implementation result?

The regulative cycle is a proven method, therefore the proposed framework is compared to it in the discussion section. It is also discussed if the differences can be considered a strength or a weakness.

3 Methodology

Based on the framework and the questions provided in the last section, this section discusses what data was collected and how they were collected. Some of the methods used to analyse the data is also elaborated upon. Finally, it is also specified how the methodology contributes to the research quality.

3.1 Data collection

Most of the data that needed to be collected was for the gap analysis. In order to analyse the design, data was collected in two different ways. First, the planning module was examined. This led to identification of the system’s planning functionalities. Next, the person in charge of main-taining and updating the system was interviewed. The people who designed and implemented the system were not working for Coatinc anymore, therefore, the system engineer could not provide in-depth explanations of design choices. For the actuality analysis, the planner was observed while working with the system. Afterwards, an interview with the planner was conducted to confirm conclusions made during observation and also to elaborate on the details of the planning process.

Next, data was collected for the selection process. The values for the stakeholders were deduced from the analysis. Information obtained through conversations with the planner, man-agement and the team leader of the production crew was used to complete the value analysis. For the cost dimension, the system engineer was asked to estimate the effort needed for each improvement project. If the project included a process redesign, the score was adjusted based on estimates made by the researcher.

There was not enough time to attempt implementing the requirements in TCCG’s actual system. Therefore, it was opted to develop a working prototype that can show all the desired functionalities. Data collection was not needed during the development step, since the data gathered during the previous steps was enough.

For the evaluation of the prototype, the planner was asked to provide feedback on the pro-totype after getting a demonstration of the features. A new planner was hired during the im-provement project, thus he was also able to provide feedback. Due to time constraints as well as difficulty extracting data, it was not possible to use actual data during the demonstration.

3.2 Data analysis

(13)

and 5 indicating a perfect fit. The scoring model also indicated what the scores of 1, 3 and 5 mean for each component. Finally, the scores were averaged per dimension and presented in a radar chart.

Based on the issues found during the gap analysis, three different improvement projects were defined. The projects were only used to show how one such improvement project can address several issues on different dimensions and is in no way an exhaustive list of all the possible projects. Each project was again scored on value and cost. These two scores were plotted to show that one project had the best value-cost ratio.

For the prototype development, requirements had to be engineered. These requirements were based on the gaps that needed to be closed as well as what would work best for the user.

Using the feedback received during the prototype demonstration, the gap analysis was revis-ited. If the planners indicated a change, this change was related to one of the seven dimensions. Next, those dimensions that were affected were scored again using the scoring model. At the end, another radar chart was constructed to present both the old and the new gap analysis.

3.3 Quality of research

According to Croon [27], good research has to ensure validity of the approach. Validity itself can be measured by dimensions, these dimensions are addressed next. Internal validity is met through the use of methods triangulation such as using both interviews and observation. Also data triangulation was used by asking for feedback from both the old and the new planner. To increase construct validity, a scoring model was developed that clearly shows how each dimension is represented. By asking the interviewees to confirm the conclusions made, interpretive validity is obtained. Lastly, theoretical validity was addressed partly by letting the interpretations be reviewed by peers.

Nonetheless, some dimensions of validity are not addressed as well. First, the external validity is limited because only one system was researched. This limitation is dealt with by discussing what sets the situation at TCCG apart from others in the discussion section. Also, using only one researcher to collect, analyse, and interpret the data affects the descriptive validity. To counter this, extra attention was paid to explain how conclusions were made.

4 Findings

The research framework contains four elements as can be seen in figure 4.1, the findings for each one of these elements are discussed in their own subsection. The section starts with a brief description of the company and its planning system.

(14)

4.1 Description of current planning process TCCG

As mentioned before, TCCG is a hot-dip galvanizing company located in Groningen. Their customers are provided with other kind of surface treatments as well, but TCCG outsources these other services to other companies within the holding company. TCCG has a transport planner who is in charge of making sure outsourced orders are delivered to the outsource company and returned to the client or TCCG, but this is outside the scope of this research. They also have one planner who is in charge of operational planning. His job is to assign production dates to orders so that the production department knows which orders have to be processed on which day. On the production floor, a forklift driver picks up items which are planned for that day. Next, there are employees who consolidate items into batches and hang them on a traverse. From there on out, there is a crane system which picks up the traverse and moves it throughout the process. This process starts with a pre-treatment before it arrives at the zinc bath, where the galvanization takes place. When the process is completed, the traverse is moved to a workstation where the galvanized items are removed from the traverse.

TCCG has developed their own system, called the NGS system, for various business functions. There is one IT department for all the companies located in the Netherlands and they are the ones responsible for the maintenance and updating of the NGS system. Part of the NGS system is the planning module. The main objective of this module is to assign orders to production dates so that each morning the forklift driver can print an overview of all orders that were assigned to that day. While the planner is tasked with making the planning in such a way that all orders are completed by their due date, there are other objectives as well. First, there is a weight-quota to be met each day. In theory, the weight is positively correlated to profit and in order to break even production has to process x kg of material each day. The other important objective is to keep the production flowing. Each traverse is assigned a recipe by the operator. A recipe includes the workstations the traverse has to pass as well as the processing times. If there are too many orders that have long processing times for pre-treatment, the zinc bath is starved for a large portion of the day and the weight-quota cannot be met.

In the next subsection this process is analysed in more depth.

4.2 Gap analysis

The gap analysis was performed by using the scoring model in appendix A to obtain a score for each dimension. The components described in the scoring model were chosen specifically for operational planning systems. Sub-question 1 is addressed by creating the scoring model and sub-question 2 is answered in this subsection.

Information

(15)

Next, the component of information quality is discussed. This requires an analysis of the content provided by the system. The majority of the information that the system provides to the planner is information that has been obtained through user input and the accuracy depends solely on the user’s accuracy. The system is also capable of generating data, although not a lot. The production date is one attribute calculated by the system. However, the algorithm used rarely leads to feasible planning and in most cases has to be manually changed. Thus, while the quality of information simply copied is sufficient, that which is generated by the system is not. Yet the planner does not expect the system to provide him with a feasible production date and that was not the intention of the design either. Thus, the quality can be improved upon but does not cause problems during the planning process. This led to a score of 3 out of 5.

The last component of the information dimension is the manner in which information is presented to the user. The system at TCCG does provide a good presentation of the orders, however not of the relevant key performance indicators (KPIs). If the KPIs were presented in a better way, the planner can attempt to make planning decisions that positively affect the KPIs. For instance, the planner can only know the number of orders that cannot be completed by their due date by counting them himself. There is definitely a gap here, but there is still a lot of the information that is properly presented and the process is not negatively impacted in a big way. All things considered, this component deserves an average score of 3 out of 5.

Technology

The technology dimension has speed as its first component; a good fit on this component indicates the system can deliver with the speed required during the planning process. Speed of the NGS system while navigating it was a non-issue as well as when having to update through the network. The only issue associated with speed is caused when the planning is updated once it has already been sent to production. The planner has to let production know that the planning has changed, so that the forklift driver can print the updated planning and continue working with that. This may be an inconvenience but has not caused any problems in the past, so the speed component is still awarded a 4 out of 5.

The second component, which is outages, sees if the system was designed reliable enough. In the past TCCG has experienced outages, but not to the point that they are considered a problem. Since the planning system is part of a larger enterprise system, an outage of the planning module is caused by outage of the entire system. Not being able to make or update a planning is not the most pressing matter during outages. It is for this reason that the outages component gets a 4 out of 5.

(16)

Processes

The first component of this dimension looks at how many of the operational process stages are supported by the system. The system only provides the planner with the ability to assign orders to due dates. Decisions concerning the sequence of the traverses or the processing times is not made by the planner and also not supported by the system. Considering the production flow might have been better if these decisions were planned, this component gets a 2 out of 5.

As mentioned in subsection 2.1, planning systems can either automate or only support the planning decisions. Automation is not necessarily the better option, although whichever one is decided upon should fit with what is needed in reality. The second component is defined as the degree to which the support provided by the system is appropriate. The planning module only provides support and does not automate any decisions. However, the system is not auto-mated enough since the planner still has to do a lot by hand. A lot of these manual operations are simple things that are better done by computer to avoid human error. The system does fulfil its supporting role in other ways, such as making sure the planner can see all the orders and disallowing scheduling of orders whose payment details are incomplete. Therefore the type component is between the best and the worst case, which is a 3 out of 5.

Finally, the alignment between the actual process and the process depicted by the system is scored. Currently, the processes do seem to be aligned to a certain degree. The orders come in and they can be provided with a production date, which is used to move on to the next step. However a closer look reveals that in reality, some orders cannot be processed on the same day and thus require different production days. Also the production department can currently request changes, however this is not supported by the planning system and can only be done through communication between the production leader and the planner. Again, this is scored right in the middle because there is a workaround where the processes deviate. The alignment of the planning system process and the actual process is scored a 3 out of 5.

Objectives and values

The objectives part of this dimension is split into two components. The first one is the degree to which objectives of stakeholders are acknowledged. The NGS acknowledges some of the objectives of the planner and management, but almost none of the production department. The objective of the production department is to maximize utilization of the zinc bath, but the system does not offer any way to estimate utilization. The score given is a 2 out of 5.

The other component concerns the representation of the objectives that are acknowledged. One objective of the planner is to meet all due dates, but the system does not calculate how many due dates are not met. Also management wishes for a weight-quota to be met each day, but the planner has to calculate this himself. This component gets a score of 3 out of 5, because there are still ways for the objectives to be taken into account even though they are misrepresented.

Lastly, there is also the values component. There was nothing to indicate the system works against the personal values of the planner or the organizational values of TCCG. Therefore, it is awarded a 5 out of 5.

Staffing and skills

(17)

The next component is for determining if the planner has the skill needed to operate the system and complete the planning process. Though the planner can operate the system and make the necessary planning decisions, he is not able to transform all information into usable information. For example, some production objectives might have been taken into account if the planner (or the system) was able to transform an item’s dimension into an estimation of how long the processing time can be. All in all, the lack of the skills is not the main reason why objectives set by the production department cannot be taken into account and the skills component is still awarded a 4 out of 5.

The last dimension is the knowledge the planner possesses. At TCCG, the production floor employees possess a lot of tacit knowledge that might be of use to the planner. If the system enabled them to record this tacit knowledge, the planner can also take production objectives into account. The reliance on tacit knowledge is a slightly more important reason why the objectives of the production department cannot be taken into account. This leads to a slightly lower score than the skills component, thus a 3 out of 5.

Management systems and structures

This dimension only consists of two components. Management system is the first one. The NGS system does not seem to contradict the management system in place. The planner is urged to accept all orders and customer requests, which can lead to changes to the schedule mid-day. The system does not allow for the planner to easily view how feasible a customer request is either and sometimes this leads to problems later on. However, for the most part the management system works well with the NGS system and is scored a 4 out of 5.

The other component is the organizational structure. TCCG’s structure makes the neces-sary communication possible and also provides the production department with final say on the schedule. Due to the complementary nature of the structure, this component scores a 5 out of 5. Other resources

The last dimension also has two components. The first one is the planning time. The planner at TCCG feels that sometimes the process can be more efficient, but there is no indication that it is too slow. Because the system never causes the planning task to not be completed in time, the score of the time component is 4 out of 5.

Cost also falls under other resources, but at TCCG this is seen as a non-issue. The costs are well within the range of what is expected and budgeted for. This component is scored a 5 out of 5.

Results gap analysis

The results of the scoring can be seen in table 4.1, which shows the averages for each dimension as well. There are clear differences among the different dimensions. However there are some overlapping problems, such as neglecting objectives of the production department, which affect several components. The next section defines some improvement projects that could address several components at the same time.

(18)

Table 4.1: Summary of component scores for gap analysis Information 2.7 Quantity 2 Quality 3 Presentation 3 Technology 3.3 Speed 4 Outages 4 Extra soft-/hardware 2 Processes 2.7 Completion 2 Type 3 Alignment 3 Objectives and values 3.3

Acknowledgement 2 Representation 3 Values 5 Staffing and skills 4 Quantity 5 Skills 4 Knowledge 3 Management systems and structures 4.5

Systems 4 Structures 5 Other resources 4.5 Time 4 Cost 5

4.3 Improvement selection

The gap analysis has shown several issues with the planning system. Based on these issues, three improvement projects were defined (sub-question 3). In this subsection, the projects are intro-duced and also scored on cost and value (sub-questions 4 and 5). At the end, one improvement project is selected based on the scores.

Different KPIs

The first improvement suggested is to implement support for different KPIs, since in reality there are different relevant KPIs that need to be taken into account. It includes taking into account KPIs that are important for production, since it leads to a smoother flow. This is mostly associated with the information dimension as it improves the score by increasing information quantity and changing the manner of presentation. It also closes part of the gap of the objectives and values dimension.

(19)

Figure 4.2: Radar chart showing the average scores of each dimension

The system engineer has scored this project a 3 out of 5. According to him the calculations necessary are not difficult to implement, all the effort lies in changing the graphical user interface (GUI). Considering all the effort lies in the system redesign, taking process redesign into account does not change the score.

Detailed scheduling

The second suggested improvement is to make a detailed schedule upfront using the system. Not only will the planner plan which orders are produced on a specific day, but also the batching of items, the sequence of hanging the traverses and ultimately also the processing times. Just like the previous suggestion, this is also a way to make sure the objectives of the production department are taken into account earlier on. It also creates a better fit on the dimension of processes, because more of the planning process will be supported.

The greatest value of this improvement is to the production department. By making sure to set the right objectives for the planner, the production department does not have to worry about keeping the production flowing. Working out the detailed scheduling is also the best way to make use of TCCG’s resources and will lead to lower cost and higher revenue. The perceived value for the planner himself may be limited, because it would be more work. The overall value would be lower than the previous suggestion. Since the first project was scored a 4 out of 5, this one is scored 3 out of 5.

(20)

Production date algorithm

The third and final suggestion that is discussed here is improving or optimizing the algorithm that calculates the production date. The current algorithm is too simple and often leads to production dates that cannot be used. However, by making an algorithm that takes all the relevant objectives into account the production date generated by the system can be used most of the time and only be changed as an exception. This project would close the gap through the information and the objectives dimension. Also the processes dimension is affected, since it would lead to automating the planning decision.

This option would result in a value comparable to the first one; it might even be more time-efficient. However, the value depends on how good the algorithm can become. A good algorithm would reduce the planner’s job to controlling the output of the system. The schedule would decrease the production cost and increase due date adherence. Thus, in the best case scenario the value would be higher than the other two projects and is scored a 5 out of 5.

Not only is the estimated value of this project the highest, the estimated effort as well. The system engineer scored it a 5 out of 5, citing the contradictory nature of some of the objectives as the reason. He is not sure he is able to incorporate all the objectives into an algorithm himself. This option would also require a small process change, but that does not cost time or effort and does not affect the score given by the system engineer.

Results selection

While there are other possible improvements, these three show there are many projects that can close the gap in different ways. Figure 4.3 presents the scores that were given to the value and cost of each project.

Figure 4.3: Plot showing value and cost of the improvement projects

(21)

instead implemented in a prototype that has the minimal functions necessary to demonstrate the suggested improvements. The next subsection goes into more detail on how the prototype was developed.

4.4 Prototype development project

Before making a prototype, or before implementing the actual system, a set of (functional) requirements has to be drawn up. The requirements along with the link to the gap analysis are given in the first part, this relates to sub-question 7. Next, the design of the prototype is discussed as well as a demonstration of what the prototype is capable of.

Requirements

The improvement is especially aimed towards closing the large gap of the objectives and values dimension. The first and most important objective to the planner and company is the meeting of due dates. The current system does acknowledge this objective, yet there is not a clear representation of it by the planning module. Therefore, the representation score can be improved upon by keeping the user informed on his main objective.

Requirement 1. The numbers of orders that are not completed before their due date should be visible at all times.

KPIs should be taken into account when making the planning, however if orders are assigned a production date by the system there is no distinction between what is planned by the planner and what is not. Especially since the generated production dates are mostly just placeholders until the planner assigns a production date himself, their effect on the different KPIs is misleading. The solution to this is to remove the default production date altogether and let the planner be the only one able to assign a production date. This change has a positive effect on the score of the information dimension since it eliminates information that was not being used. The danger of removing the generated production dates though is that some items or orders may be overlooked. Therefore, it is important to have a clear overview of orders and show what still needs to be planned.

Requirement 2. An overview of all orders and their status should be provided.

The production department has complained that they often do not have flexibility due to large quantities of rush order, which are orders that have to be finished later that same day or by the next day. Instead of coming up with a sequence that improves the flow, they usually have to resort to the earliest due date rule. How many days there are left before an order’s due date or how many days an order is already late is called the slack. The planner has no indication how many orders are turned into rush orders because of his planning decisions. A histogram would show how many items are rush orders and would give the planner incentive to not leave too many orders to the last minute.

Requirement 3. The items should be grouped according to slack and a histogram should show the frequency of each group.

(22)

Requirement 4. A user should be able to add a category to each item type within an order. If each item is assigned a category, the planner can use the number of items within a category as an indication of how the distribution of processing times is. The more KPIs the planner needs to observe, the harder the task becomes. Therefore it is assumed the planner has the skills to make decisions by weighing the pros and cons.

Requirement 5. A pie chart should show the user how the distribution of processing times is per production day.

One last KPI is needed, which is the total weight. This not only acknowledges the fact that this objective exists, but it also leads to better presentation of the information. For this and all other KPIs, it is necessary to show them for multiple days at the same time. Humans are better at judging differences between two values than absolute values. Showing the KPIs per production day for the next three days should be enough, since the planner does not often plan ahead more than that.

Requirement 6. A 100% stacked bar chart should show the user how much of the weight capacity is assigned per production day.

Finally, there is one last requirement which does not necessarily address the gap caused by neglected objectives, but can still lead to better planning. Assigning one production date per order makes the planning inflexible. For instance, the KPI viewer can show that on a particular day there have been too many items with long processing times scheduled, and items with short processing are needed in order to avoid starvation at the zinc bath. The planner still has one order which contains 20 items with short processing times that he can schedule. The problem here is that there are also 20 items with long processing times in the order and assigning the whole order will have limited effect. By being able to assign production dates to part of orders, the planner can assign the items with short processing time and schedule the other items on another day. While this does not guarantee it will always lead to better results, at the very least the planner has more flexibility when taking KPIs into consideration.

Requirement 7. Each item type should be able to get assigned different production dates, as well as being divided into groups with different production dates.

Prototype

The requirements were implemented in a stand-alone application using the Eclipse 4 Application Platform, which uses SWT Widgets for the GUI. While the prototype is a functioning one, the aim was to show how the different requirements can be implemented. The prototype is a minimal functional application, which means that only the functionalities that are needed to show how it works were implemented. An example of a functionality that was not added is the ability to make an overview of the items that are planned on a day and their location in the courtyard. This functionality already exists in the current system and it is therefore not needed to replicate it.

(23)

Planning object, but only process the relevant information (KPI-related). The class diagram of the back-end model is provided in appendix B.

The Eclipse 4 Application Platform distinguishes between the GUI elements and the applica-tion model. The applicaapplica-tion model contains the parts among other things, which are the panels visible in figure 4.4. The GUI elements, such as text boxes and tables are added to the parts of the application model.

Figure 4.4: The structure defined in the application model.

Now that the back-end and the overall application model have been explained, the GUI itself is explored through means of a hypothetical situation. It shows how the planner can use the prototype to assign a production date to a group of items. Screenshots are used to show different parts of the prototype. For more screenshots, see appendix C.

Figure 4.5 shows that the planner still needs to schedule one order that is due on June 24 (Customer 5). Not all 9 items of type Item5A have been assigned a production date. Double-clicking that item has opened the item view for this specific item type. The item view shows the planner information such as order ID, number of items, weight and category. There is also a production table that shows when items of this type have been scheduled. The planner can now see that 4 out of the 9 items have been scheduled for June 22. In the KPI view, the weight tab is opened showing the planner that production on June 22 is almost at capacity.

Next, the planner switches the KPI view to the category tab (Figure 4.6). Here he sees the distributions are almost the same for June 22 and June 23. Seeing as Item5A is due June 24 and it can be planned on the 23rd without maxing out capacity or creating an uneven distribution, the planner decides to assign the remainder of the items to June 23. In this case the planner does not need to check to see if the day is already filled with rush orders, because assigning it on June 23 will create slack of one day.

(24)

Figure 4.5: Item view of item that still needs to be assigned a production date

Figure 4.6: KPI view shows the distribution of the estimated processing times make the assignment of the group of items to the date concrete by clicking the add button.

(25)

Figure 4.7: Item view after last of the items have been assigned to Tuesday June 23 is shown in figure 4.7. Also, the group that contains the amount, data and add button become disabled, meaning they become greyed out and do not respond to mouse clicks or key presses. The KPIs are also updated immediately and now there are relatively more items with short processing times planned for tomorrow. The overview is changed as well to reflect the changes. It shows that all items of type Item5A are now assigned. The top bar shows the planner that there are no incomplete orders left, meaning they have all been scheduled.

4.5 Prototype evaluation

(26)

but between intake and processing the item may have switched categories due to oxidation for example (more oxidation equals longer processing time).

On the other hand, it was especially the categorization that the new planner found the most appealing function. He thought that way he can plan batches ahead and possibly also traverse sequence. This would increase the completion component of the process dimension since more of what is usually considered planning can be supported by the system. This is an example of a positive secondary consequence, since it was not the aim of the improvement project. The reason the planner can make more planning is because knowledge previously residing with the production employees is now available to him. Although he was also convinced of the efficiency gains the old planner mentioned, he wishes to see more automation as he believes the efficiency can still be greatly improved.

Based on the feedback received from both planners, the implementation of the requirements would result in different scoring of some components. The pre-implementation and the likely post-implementation scores are provided in table 4.2.

Table 4.2: Differences between old and new scores of components

Dimension Component Before After Information Quantity 2 3

Presentation 3 4 Technology Extra soft-/hardware 2 4 Processes Completion 2 3 Alignment 3 4 Objectives and values Acknowledgement 2 4 Representation 3 4 Staffing and skills Knowledge 3 4 Other resources Time 4 4*

* Even though both planners cited efficiency gains, planning time can still be improved upon. The new average scores per dimension is presented in an updated radar chart in figure 4.8, with the original plot also provided as comparison. Based on the users’ feedback on the prototype, there are several dimensions that can be improved upon if the requirements for the prototype were implemented in the NGS system. There still exists a gap though, as was expected since there are other improvement projects that address different problems.

(27)

Figure 4.8: Radar chart showing average scores before and after improvement

5 Discussion

Based on the results presented in the previous section, a couple of subjects are discussed more in depth in this section. This includes discussing the representativeness of TCCG for other production companies with planning systems and the implications of evaluating a prototype versus an actual implementation. Also, the main research question is addressed by discussing the applicability of the design-actuality gap model for analysing and improving operational planning systems. Finally, the strengths and weaknesses of the developed framework is discussed by comparing it to the regulative cycle.

5.1 The TCCG context

The research was performed at TCCG with the underlying idea that if one operational planning system or its use can be improved upon, then it would presumably also lead to the same at other companies. Operational planning-wise, TCCG has a relatively simple process since a lot of what are considered operational planning decisions are left up to the production floor employees. A simple process does not require a complex system, which is probably why TCCG’s planning system barely generates information. The inclusion of the stages in the planning process is simply a part of the gap analysis, meaning the analysis can still be performed on more complex systems. However, it can safely be assumed that more complex systems will take more time and effort to analyse.

(28)

itself and the results.

Finally, it should be mentioned that TCCG’s holding has employed someone to maintain and add/change functionalities of the NGS system when the need arises. Having a system engineer facilitates system redesign, whereas other companies who will need to outsource this may prefer process redesign purely because it is the cheaper alternative. This would manifest in the cost-value analysis.

5.2 Evaluation of prototype

In the last part of the previous section the prototype was evaluated by translating the feedback received during demonstration of the prototype to improvement of several components in the design-actuality gap model. It should be noted that during a demonstration users are more inclined to see the potential, while if giving feedback on a system they have gotten the chance to work with the feedback received might have been slightly less positive. Therefore, the evaluation can be seen as providing an indication of what the system can achieve. If it is decided to go through with the project, then the implementation details determine if the final product has reached its potential. Evaluation of the prototype is also less likely to reveal possible secondary consequences, since the researcher is focused on the intended consequences and may inadvertently influence the users to not look further. When working with prototypes, the development and evaluation is simply considered an intermediate step. If implemented, then another evaluation has to take place to confirm what was suspected. Thus, the evaluation of a prototype can either lead back to the improvement selection phase or to the implementation and evaluation of the system itself. This process is depicted in figure 5.1.

Figure 5.1: Use of prototype evaluation

The higher the costs associated with a project are, the more confirmation is needed that it will indeed be an improvement. In that case the prototype can be evaluated by letting users perform a task with both the current system and the prototype. However, in TCCG”s case a simple demonstration was deemed sufficient since the implementation costs were not estimated to be very high.

5.3 Applicability of the design-actuality gap model

(29)

the management systems in place. Using the semi-structured interview format led to discussion of the management systems which in turn led to discovering management promotes acceptance of all orders without taking into account what it would mean for the planning. A more structured approach, meaning the use of more quantitative data, would probably be even more efficient while analysing an operational planning system. However, the effectiveness of those approaches is dependent on how the tools were developed and if they were validated. Baraka et al. [10] have developed a structured way of calculating the gap index by using indicators for each dimension. Their indicators include hours of operation, transfer rate and user retention rate. Their research focused on validating their gap index calculations. However, when the aim is to use the gap analysis for improvements, developing and using a set of non-validated indicators would not have identified all the problems.

The gap model’s applicability in the other stages of the improvement cycle is less pronounced. For project selection, it is not enough to only look at which project would close the biggest gap since stakeholders may place value on other aspects. Most importantly, some gaps can be closed with much less effort than others. Therefore the objective of closing the gap should be combined with stakeholder value and cost. During the improvement approach, the gap model should be used while defining the requirements. The requirements should target specific aspects of the system/process that are causing a gap. Lastly, during evaluation the gap analysis is revisited to indicate if any of the dimensions’ scores are changed.

5.4 Comparison of framework and regulative cycle

The last subsection discussed how the gap model can be applied in the different stages of the proposed framework. However, the framework itself is also evaluated. As mentioned earlier this is done by comparing the proposed framework with the regulative cycle of van Strien [25]. Subsection 2.6 stated which steps the regulative cycle has as well as what is important during each step.

The regulative cycle starts with identifying stakeholders and their goals, whereas the proposed framework starts with a complete gap analysis. This difference is caused because the framework was developed under the assumption that the system should fit the current situation and not only the goals of stakeholders. In the gap analysis the goals of several stakeholders were also discussed, but by looking at more dimensions the situation was better described. In the regulative cycle CSFs are determined for each goal during the first step as well. CSFs can be seen as what was introduced in the proposed framework as requirements, therefore they are used interchangeably for the remainder of this section. Requirements are defined in the improvement project stage of the framework, which is one of the main differences with the regulative cycle.

Once the CSFs are known, the regulative cycle continues with a diagnosis of these CSFs by looking at causes of difficulty, quality attributes and interdependencies. In the framework different projects are defined based on the analysis of the situation (including stakeholders’ goals). These projects and their goals are then diagnosed by looking at causes of difficulty, but also the value of each. At this point trade-offs are made in the proposed framework and only one project and its associated goals is selected.

(30)

was developed with the goal of meeting most if not all the goals.

At this point in the regulative cycle a solution is chosen and implemented, however in the proposed framework the requirements are engineered during the improvement project itself. The regulative cycle can be applied during the improvement project, since the proposed framework does not elaborate on how the improvement project should be executed. If the regulative cycle is applied then the solution only has to address the goals that are specific to the current improve-ment project and not the whole system. Regardless of how the improveimprove-ment project is executed, a system or process redesign is the result. Thus the improvement project stage of the proposed framework achieves the same result as the implementation step of the regulative cycle.

Finally, the regulative cycle ends with a validation step which can be compared to the eval-uation stage of the proposed framework. It is at this point in the regulative cycle that the CSFs are tested and the trade-offs discussed. In the proposed framework, the evaluation stage only checks if the goals are met. Since CSFs are more precise, it is easier to check if they are met than checking goals. This can be considered a weakness of the proposed framework, but on the other hand the evaluation gives a clear picture of the before and after situation by using the same analysis method before and after.

It is clear that there are many differences between the proposed framework and the regulative cycle. By choosing a project before requirements engineering, the proposed framework has less requirements to keep track off. However, this does mean that more can be achieved when using the regulative cycle. The proposed framework was developed specifically for small improvements and not for a complete (re-)design of a system, thus that is why the regulative cycle can lead to bigger solutions. In terms of scalability, the proposed framework analysis can become quite complex if the system is too big. However, by making the scoring model more specific and automated when possible, the complexity can be managed.

6 Conclusions

This research attempted to contribute to existing literature on improving performance of in-formation systems, more specifically inin-formation systems used for operational planning. The perspective taken was to address the mismatch between the system and the planning process, for which the design-actuality gap model designed by Heeks [8] was used. A research framework was developed and put into practice at TCCG. Based on the evaluation of the feedback, it was found that the gap analysis did indeed identify ways in which the system and process can be improved. TCCG was given recommendations to implement the requirements engineered during this research to update their planning system. Also, it was recommended to keep on performing small improvement projects to bring their system design and reality closer together.

The scoring model developed for TCCG was developed for use with other planning systems as well, though it has not been validated. What can be concluded from the research is that if the gap analysis is performed correctly, then the subsequent stages can benefit by constantly linking back to the analysis. This also implies that the type of system does not matter, since only the design-actuality gap model is adapted for a specific type of information system and not the whole framework. Therefore, if one was to adapt the gap model to fit with the type of system, then the results of the analysis can be used to bring about improvements.

For operational planning systems, the components defined for each of the dimensions may be used along with the scoring model. As it was not validated though, they are better viewed as starting points and should be reviewed if they are indeed the best for the situation.

(31)

the details and the regulative cycle proposes everything be worked out before making any trade-offs. The comparison also showed that there are many important aspects that are not explicitly part of the proposed framework, but that can still be incorporated. For instance, the quality attributes and performance check are not mentioned or used in the case at Coatinc but they are important and should not be neglected during the execution of a real improvement project. As was mentioned, the proposed framework is best suitable when a company aims to make small improvements over a longer period of time (continuous improvement). If a big change is needed, then an approach like the regulative cycle can lead to a solution that addresses more stakeholder goals.

6.1 Limitations

Limitations of this research include the use of only one case. Therefore, it was not validated that the elaboration of the gap dimensions is indeed sufficient to evaluate the use of all operational planning systems. Furthermore, even though the effect of a single researcher was attempted to be minimized, this research does still have subjective elements.

Also, the improvement project was not completed but only up to and including the evaluation of the prototype. No actual improvement was observed because of this, though the feedback did provide a fair estimate of the potential improvement. This also failed to prove if secondary consequences should indeed be part of the framework.

Finally, during this research the gap dimensions were scored using unweighted averages of their components, but it is likely some components are more important than others. The dimension scores might have been influenced by the decision to not use weighted average, although this does not affect how problems are found but only the importance they are given.

6.2 Further research

This research can be extended upon by validating the data collection and analysis methods. Whether these are surveys or interview questions, it would contribute to literature a proven way to analyse operational planning system. Also, the framework can be transformed in its own decision support system (DSS). For instance, such a system can ask for scores on each component and then give the average score. It can also determine which improvement project is the best choice based on cost and value. By recording information, the one responsible for the improvement process does not have to re-enter all information every time the cycle is executed, but only indicate if something has changed compared to the last recorded situation.

(32)

References

[1] Braley Consulting Services. Underutilization of information systems: Why aren’t you getting your moneys worth? Retrieved from http://www.braley.com/ArticlesOther/under.htm. [2] V. Botta-Genoulaz, P. Millet, and B. Grabot. A survey on the recent research literature on

ERP systems. Computers in Industry, 56(6):510–522, 2005.

[3] B. Kositanurit, K Osei-Bryson, and O. Ngwenyama. Re-examining information systems user performance: Using data mining to identify properties of IS that lead to highest levels of user performance. Expert Systems with Applications, 38(6):7041–7050, 2011.

[4] D.L. Goodhue and R.L. Thompson. Task-technology fit and individual performance. MIS quarterly, 19(2):213–236, 1995.

[5] R. McCarthy, K. Lindsey, J. Aronson, M. Frolick, and G. Claffey. Task-technology fit in data warehousing environments: Analyzing the factors that affect utilization. AMCIS 2002 Proceedings, (8):40–46, 2002.

[6] M.T. Dishaw and D.M. Strong. Assessing software maintenance tool utilization using task– technology fit and fitness-for-use models. Journal of Software Maintenance: Research and Practice, 10(3):151–179, 1998.

[7] J. Gebauer, M.J. Shaw, and M.L. Gribbins. Task-technology fit for mobile information systems. Journal of Information Technology, 25(3):259–272, 2010.

[8] R. Heeks. Information systems and developing countries: Failure, success, and local impro-visations. The Information Society, 18(2):101–112, 2002.

[9] R. Heeks. Health information systems: Failure, success and improvisation. International Journal of Medical Informatics, 75(2):125–137, 2006.

[10] H.A Baraka, H.A. Baraka, and I.H. EL-Gamily. Information systems performance eval-uation, introducing a two-level technique: Case study call centers. Egyptian Informatics Journal, pages 1–14, 2014.

[11] L. Brehm, A. Heinzl, and M.L. Markus. Tailoring ERP systems: a spectrum of choices and their implications. In Proceedings of the 34th Annual Hawaii International Conference on System Sciences, 2001., pages 1–9. IEEE, 2001.

[12] W. Luo and D.M. Strong. A framework for evaluating ERP implementation choices. IEEE Transactions on Engineering Management, 51(3):322–333, 2004.

[13] D.E. Shobrys and D.C. White. Planning, scheduling and control systems: why can they not work together. Computers & Chemical Engineering, 24(2):163–173, 2000.

[14] H. Stadtler. Production planning and scheduling. Springer, 2008.

[15] S.R. Barkin and G.W. Dickson. An investigation of information system utilization. Inform-ation & Management, 1(1):35–45, 1977.

(33)

[17] S. Cane and R. McCarthy. Analyzing the factors that affect information systems use: a task-technology fit meta-analysis. The Journal of Computer Information Systems, 50(1): 108, 2009.

[18] N.P. Archer and F. Ghasemzadeh. An integrated framework for project portfolio selection. International Journal of Project Management, 17(4):207–216, 1999.

[19] F.T.S. Chan, M.H. Chan, H. Lau, and R.W.L. Ip. Investment appraisal techniques for advanced manufacturing technology (AMT): a literature review. Integrated Manufacturing Systems, 12(1):35–47, 2001.

[20] T.H. Davenport. Putting the enterprise into the enterprise system. Harvard Business Review, (76):121–31, 1998.

[21] I. Sommerville and G. Kotonya. Requirements engineering: processes and techniques. John Wiley & Sons, Inc., 1998.

[22] G. Poels, K. Decreus, B. Roelens, and M. Snoeck. Investigating goal-oriented requirements engineering for business processes. Journal of Database Management, 24(2):35–71, 2013. [23] K. Peffers, T. Tuunanen, M.A. Rothenberger, and S. Chatterjee. A design science research

methodology for information systems research. Journal of Management Information Sys-tems, 24(3):45–77, 2007.

[24] D. Vaughan. The dark side of organizations: Mistake, misconduct, and disaster. Annual Review of Sociology, 25:271–305, 1999.

[25] P.J. van Strien. Towards a methodology of psychological practice - the regulative cycle. Theory & Psychology, 7(5):683–700, 1997.

[26] H. Balsters. Design methods: Building utility-driven artifacts. Lecture slides, 2014. [27] S. Croon. Introduction to research methodology in operations management. In C. Karlsson,

(34)

Appendices

A

Scoring model gap analysis

For each component of the dimensions, the scores of 1, 3, and 5 are elaborated upon. These correspond to low, average, and high scores. The scores 2 and 4 are not described, as they are chosen when the analysis does not place it directly into one of the three descriptions provided.

A.1 Information

Quantity: the degree to which the amount of generated information matches the required amount, taking into account generated information that is not needed

1 - Almost none of the required information is provided nor is the provided information used to the point where it severely hinders the use of the system

3 - Some of the required information is generated, but not all and there is also information being provided that is unnecessary. It has a negative effect on the planning process 5 - All required information is provided and no extra unneeded information is being provided Quality: the degree to which the content of generated information matches the required content

1 - The information is of such bad quality that it cannot be used

3 - Some of the information is not of enough quality, while there is also information of sufficient quality made available. The quality of information can lead to ineffective planning 5 - The quality is high enough for correct use of the information, but not that high that too much was invested in the system without having use

Presentation: the degree to which the presentation form of information matches the required form

1 - The information is presented in a way that cannot be interpreted by the planner, thus cannot be used

3 - While there is enough information being presented properly, there are a few that are not and that leads to misinterpretation

5 - The information is presented in such a way that the planner can interpret and use it in order to make the best planning possible with available information

A.2 Technology

Speed: the degree to which the processing and networking speed matches the speed required 1 - The speed is lacking and is causes problems in daily use of the planning system 3 - The speed is not always as is expected and required and intermittently causes problems 5 - The speed never causes problems are is identified as a problem, without having invested in speed that is not necessary

Outages: the number and duration of system outages compared to what is possible without loss of function

1 - The system experiences a lot of outages which severely impairs the planning process 3 - There are outages that hinder the planning process, but they are limited

Improving the use of production planning and scheduling systems