An assessment tool within the customer/sub-contractor negotiation context A. LETOUZEY, L. GENESTE, B. GRABOT LGP/ENIT Avenue d'azereix - BP 1629 F-65016 TARBES Cedex FRANCE Abstract: - In the current competitive context, an increasing pressure is put upon Small and Medium Enterprises (SMEs) involved in the production process, especially when they act as sub-contractors for bigger companies. During the negotiation process with their possible customers, one of their major needs is to be able to propose a realistic lead time and to assess immediately the consequence of any change in an order (quantity, nature, delay). Another need is to test different ways to process the order within the workshop in order to find the best solution in a given situation. ASPIRE is a CRAFT project, funded by the European Union, aiming at providing a software package in order to support this negotiation process. The different modules of the ASPIRE tools are presented, and the focus is given on the assessment tool. Key-words: - Manufacturing, sub-contractor, scheduling, negotiation, performance assessment. 1 Introduction The overall trend in the manufacturing industry is to produce faster and cheaper. At the bottom of the industrial pyramids, the suppliers and the sub-contractors, usually SMEs, have to organise themselves to tackle this new context of tighten supply chain, which usually implies shorter but also more predictable and reliable delivery times. For a small and medium enterprise, a response to this stands in anticipating its production schedule. This requires some access to the key information that allows to establish a schedule forecast, itself being used to negotiate lead times with customers. The faster the information is available, the easier is the negotiation. The purpose of the ASPIRE-CRAFT project is to deliver this information on time, through a dedicated decision support system providing: - the expected lead time for processing an order, - tests of production scenarios that should allow to meet the customers demands. These scenarios are linked to the routings (choice of the operations or machines), to the management of the operators (working hours) and to the possibility to sub-contract a part of the load. - the ability to reinforce the degree of confidence of those scenarios through simulation, - the assessment of the scenarios in order to classify them according to the satisfaction of the manufacturing objectives that they provide. In order to develop this DSS, an international consortium has been built that groups: - SMEs from various production areas (mechanical parts for aeronautics (MAP, F), other mechanical parts (De Nadaï, F), cutting tools (Ebay, E), technical textiles (Textinap, F), off-set printing (Krammer, A), - Research laboratories (BIBA, D; LGP, F) - Information Technology vendors (Robotiker, E; IXI, F). Within the consortium, the role of the SMEs was to express their requirements, then test and validate the system while the research laboratories and IT vendors had to specify, design and develop the software package. The existing tools or techniques which could satisfy part of the required functions
are described in section 2. The different modules of the ASPIRE tools are listed in section 3, and the assessment module is described with more details in section 4. The present state of the project and the following steps are discussed in the conclusion. 2 Positioning of the ASPIRE tools The first goal to be achieved by the ASPIRE tools is to propose a realistic delivery date to the customer. This could be considered at first glance as performing a schedule, by testing the introduction of a new manufacturing order in the set of the already planned orders. Any industrial scheduler could be used in that purpose. The industrial reality is slightly different, since: - precise routings are seldom available at this stage of the negotiation process, since the expected order may concern new parts, - alternatives can be possible in the way to process a part, - for a sub-contractor, the middle term load (1 to 3 months) is usually composed of very different types of data: - planned orders, corresponding to already accepted parts, - expected orders, i.e. orders under negotiation that will either be cancelled or confirmed, - capacity booking, corresponding to a regular load from a customer which has not yet been associated to precise parts. A first consequence is that it must be possible to attach a rough routing to an order, describing only the use of the critical resources that may condition the lead time. This routing will be changed in a precise one once the order will be released. Moreover, routings should integrate the alternatives describing the degrees of freedom in the manufacturing process that could be used during the negotiation or while processing the order. This is not possible in most of the existing schedulers: several routings can usually be associated to an order, but once the first operation has been planned, it is not anymore possible to shift to another routing. Exceptions are the scheduler developed within the ESPRIT 2457 project [1] and the industrial scheduler Cadplan [2] in which routings can be described as networks of activities. A second consequence is that the scheduler should be able to deal with uncertain orders. Fuzzy logic has been suggested for a long time in order to deal with imprecision or uncertainty in scheduling [3]. Nevertheless, uncertainty is always linked to the occurrence of unexpected events like failure, and not to the possibility that orders are cancelled [4]. The robustness of a scenario is a part of its interest, especially if the processing times are imprecisely known at the beginning of the negotiation process. As a consequence, it can be interesting to test the influence of variations of processing times on the delivery date. Simulation tools may allow to do this, but their use remains a matter of specialist. The choice between several possible solutions requires that the manager defines his objectives, links these objectives with assessment criteria, and evaluates each solution according to these criteria. Many examples of performance criteria can be found in the literature (see for instance [5] or [6]), but since the global satisfaction provided by a solution is a matter of compromise between elemental objectives, it is important to be able to define hierarchical structures of objectives as defined in [7] or [8]. Nevertheless, few generic tools are provided with schedulers in order to assess a solution [9] since the objectives and criteria may vary from one company to another. Tools allowing to build queries on data bases can be found on-the-shelves but their use can be difficult for end-users like workshop managers. Moreover, they can hardly be used for building objective structures. We shall see in next section how the ASPIRE tools allow to cope with these difficulties. 3 Description of the ASPIRE modules The architecture of the ASPIRE tool is shown in Figure 1. The system is composed of four modules:
- the repository module is mainly made of a database allowing to store the workshop description (machines, operators), its current state (already planed orders, resource state), the technical data (bills of materials, routings), the orders (possibly coming from a MRP system) and the output result of the others ASPIRE modules. - the macro-scheduler allows to define a sequence of manufacturing operations on the resources, depending on a manufacturing context (routings, resources...) and on schedule hypothesis (priority rules, open hours...). This macroscheduler allows to associate rough or precise routings to manufacturing orders, these routings being defined as nets of operations. Capacity booking is also possible for expected but not confirmed orders. - the simulation module allows to take into account more accurate data on the manufacturing operations (transportation, set-up time, additional resources, etc.) and to test the robustness of the schedule regarding unexpected events (machine breakdowns) or processing times deviating from their expected value. - the assessment module permits to evaluate the candidate solutions in accordance with a dashboard of pre-defined indicators. The assessment module can be used in order to assess a macro-schedule or the precise result of a simulation. 4 Description of the assessment module 4.1 General specification Within the ASPIRE tools, the role of the assessment module is to support the workshop manager for the comparison of several scenarios, but also for making a diagnosis in order to define improvement actions on the current schedule. This assessment requires the definition of an objective function that defines and explains how the satisfaction of the manufacturing objectives can be estimated. Objective functions have been used for a long time as optimisation criteria in Operational Research, however multicriteria approaches require very restrictive hypotheses that do not reflect the shop floor complexity. At the workshop level, the elemental manufacturing objectives or the performance criteria to define are discussed in many papers, but most of the studies focus on simple criteria like job lateness, resource utilisation, inventory levels or workshop description products description actual state of the workshop new manufacturing orders input data schedule Macro scheduler production scenario additionnal information for simulation dashboards définition Repository schedule/simulation schedules +scenarios delivery dates robustness performance assessment Simulation robustness bottlenecks WIP... Assessment performance assessment (dashboards) user system Figure 1: General structure of the ASPIRE tools
cycle times for scheduling. The solution that we suggest aims at solving two main problems: - the aggregation of the satisfaction of elementary criteria, by suggesting a hierarchical structure of objectives allowing a global, then precise assessment of a planning. This step is mandatory since the elementary manufacturing objectives are often partially conflicting (e.g. maximisation of the resource use and minimisation of the work in progress): a hierarchical approach is then required in order to define what is a satisfactory compromise between the conflicting objectives [10], [11]. An example of hierarchical structure of objectives is provided in Figure 2. As suggested in [7] and [12], internal and external objectives are distinguished: the first ones aim at optimising the use of the internal resources while the others aim at satisfying the customer. - the adaptation of this structure, by allowing the workshop managers to choose both the elementary objectives used, then the way their aggregation will be performed. The user may use the assessment module as follows: - define an indicator (elemental or aggregated) - define a context (which objects, e.g. machines, orders, are concerned by the evaluation), - define a visualisation (association of an indicator, a context and a visualisation mode, i.e. bar-graphs, pie chart, curve...) - define a dashboard (set of visualisations with their locations and sizes on the screen) - use a dashboard (load and activate a dashboard in an appropriate context). 4.2 Description of the assessment module Definition of an indicator An indicator is defined as an ordered set of elementary indicators. An elementary indicator is an expression made of attributes of schema of the database tables, other indicators, operators, constants. For each elementary indicator, an aggregation operator may be defined in order to compute a value such as the average, the sum on the list of results when the expression is evaluated on the tuples of the context. The user is allowed to build indicators by selecting interactively the relevant attributes, indicators, operators and by defining the constants. Most of the time, it is more relevant to define relative indicators (i.e. implicitly compared to required values) than absolute ones. For instance, the lateness of an order is an absolute indicator. Nevertheless, a lateness of 10 hours has a different meaning if the cycle time of the order is 20 days or 1 day. The ratio between the lateness and the cycle time allows to define a relative indicator, easier to interpret and to compare with other orders. Definition of a context A context is a limitation of the objects of the database tables that are used for the evaluation of an indicator. The default satisfy manufacturing objectives satisfy internal objectives satisfy external objectives optimize process optimize operation meet due dates meet quality meet quantity inventories optimize flow optimize use of resources maximize machining performance maximize utilisation maximize availability raw material inventory cycle time set-up time rework work in progress end product storage lead time optimize resource loading scraps Figure 2 : Hierarchical structure of objectives
context is defined by all the objects of a given type contained in the database (e.g. all the machines, all the manufacturing orders, etc.). The user can refine a context by several ways: - a first way is to define a boolean expression made of attributes of the tables, operators and constants. The context is in this case defined by the tuples of the database for which the evaluation of the expression is true. - a second way is to define whether a list of tuples that determines the context or a list of tuples that should not be in the context. Definition of a visualisation A visualisation may be defined as the association of a visualisation mode (such as a bar-graph, a pie chart ), an indicator and a context of evaluation. Definition of a dashboard A dashboard is a set of visualisations with their positions on the screen. The user can build his own dashboard by selecting one of the visualisations and defining their locations on the screen, then by selecting a context of evaluation. The activation of a dashboard will lead to the evaluation of its indicators in the specified context and to the visualisation of the result according to the selected visualisation mode. Aggregation The aggregation of elemental performance indicators requires that relative indicators are defined. We have chosen to aggregate indicators varying between 0 and 1. The definition of an indicator (which applies operators to objects of the database of to already existing indicators) already allows to aggregate indicators using classical operators (sum, product, minimum, maximum, etc.). According to the first experiments performed within the ASPIRE SMEs, other operators allowing to express an "expert" point of view on this aggregation can also be necessary. We have so chosen to also implement operators originally defined in the context of fuzzy logic. Two types of operators have been implemented: - weighted aggregation with threshold [13]. In that case, a weight w, between 0 and 1, is affected to each criterion. The aggregation of n criteria is given by formula (1): R = min [max i (1-wi, r i )] (1) the r i being the values of the n criteria to be aggregated. As we can see, (1-w i ) acts as a threshold under which the value of the corresponding criterion is not anymore considered in the result. It allows to express that even if some criteria are not at all satisfied, the result can be different from 0 if these criteria are of secondary importance. - Ordered Weighted Average (OWA). This class of operators has been introduced in [14]. The criteria to be aggregated are first ranked by decreasing order; n weights w i so that Σ i w i =1 are affected to places in the resulting vector. The aggregation is then defined by formula (2): OWA(r 1,..., r n )= Σ i (w i. y i ) (2) where y i is the value of the i-th criterion of the vector. It is clear that: - if w i, w i =1/n, OWA = arithmetic average, - if only one weight w 0, this weight must be equal to 1. If i=1, OWA=max, and if w=1, OWA=min. Depending on the number of weights and on the rank where they are applied, OWA can so implement intermediate values between min and max. The main difference with the previous operator is that a weight is not anymore associated with a criterion but with a rank in the ordered vector. The development of other types of aggregation operators is in progress, in relationship with the ASPIRE SMEs. Three levels have been defined for using the Assessment tool: Level 1: the user can only use pre-defined indicators, chosen in lists. Level 2: the user can define his own indicators and their aggregation using a graphical-user interface (GUI) (by selecting attributes of the database and operators in menus) Level 3: when very specific operators have to be defined that can not be described using the pre-defined functions of the GUI, the indicators and their aggregation can directly be defined using SQL queries. 5 Conclusion The development phase of the ASPIRE tools is now finished, and the implementation in the SMEs of the consortium will now begin. It is clear that
the main difficulty of the project was to define generic models so that the result could be applied in very different companies. The diversity of the ASPIRE SMEs has been a difficulty during the synthesis of the specifications coming from each partner, but it permits to think that the result is generic enough to be used in a wide range of companies. New developments are already planned, regarding recent requirements coming from the SMEs: - explicit use of the uncertainty linked to the manufacturing orders in order to define an expected load at middle term. An experimental version of a scheduler developed in the LGP, called TAPAS, has shown very encouraging results in that context [4], - possibility to use an a-priori knowledge on the lead times, coming from past expertise. Techniques like Case-Based Reasoning could be very useful in that context, with the condition that an ad-hoc information is stored concerning past experiences. This information should gather a description of the orders (nature of the parts, orders in progress, routings...), of the workshop situation (load level, machines out of orders, etc.) and a description of the real lead times of the orders. When a new lead time is required, the problem would be to find a comparable case in the data-base, and eventually to modify it according to the difference with the current situation. These two new directions correspond to a higher level of maturity of the ASPIRE tools users, and will be explored in parallel with the tests of the present version of the ASPIRE package. References: [1] FLEXPLAN, Knowledge Based Planning and Control in Manufacturing Environment, ESPRIT Project 2457, Final Report, 1992. [2] Access Commerce, 2000, Home Page: http://www.access-commerce.com/ [3] Kerr, R. M., Walker, R. N., A Job Shop Scheduling System based on Fuzzy Arithmetic. In Proc. of the 3 rd Int. Conf. on Expert Systems and the Leading Edge in Prod. and Op. Managt. Hilton Head Isl., South Carolina, USA, 1989. [4] Geneste, L., Grabot, B., Moutarlier, Ph., Scheduling of heterogeneous data using fuzzy logic in a customer-subcontractor context; in Scheduling under fuzziness, Ed. by R. Slowinski and M. Hapke, Springer-Verlag, 2000. [5] AIT, Advanced Information Technology in Design and Manufacturing, Subtask 4.2.1, Manufacturing Indexes and Performance Indicators. AIT Vendor Workshop on Production Control and Logistics, Stuttgart, October 12, 1994. [6] Gelders, L., Mannaerts, P., Maes, J., Manufacturing strategy, performance indicators and improvement programmes. International Journal of Production Research, vol. 4, n 32, 1994. [7] Zülch, G., Grobel, T., Jonsson, U., Indicators for the Evaluation of Organizational Performance. IFIP WG 5.7 workshop on Benchmarking - Theory and Practice, Trondheim, Norway, June 16-18, 1994. [8] Alacorn, I., Gomez, P., Campos, M., Aguilar, J.A., Romero S., Serrahima, P., A holistic approach to intelligent automated control, in Balanced Automated Systems: Architecture and Design Methods, Ed. by L.M. Camarinha-Matos and H. Afsarmanesh, Chapman & Hall, 1995. [9] Grabot, B., Objective satisfaction assessment using neural nets for balancing multiple objectives, International Journal of Production Research, vol. 36, n 9, 1998. [10] Van der Pluym, B., Knowledge-based decision making for job-shop scheduling, International Journal of Integrated Manufacturing, n 3, 1990. [11] Smith, S.F., Knowledge-base production management: approaches, results and prospectives, Production Planning and Control, n 3, 1992. [12] Farhoodi, F., A knowledge-based approach to dynamic job-shop scheduling, Int. Journal of Computer Integrated Manufacturing, n 3, 1990. [14] Dubois, D., Prade, H., Testemale, C., Weighted Fuzzy Pattern Matching, Fuzzy Sets and Systems, vol. 28, n 3, 1988. [15] Yager, R. On general class of fuzzy connectives, Fuzzy Sets and Systems, n 4, 1980.