Configuration of complex products

Making a configuration of a complex product in the course of a sales process is a difficult matter. A sales-support information system (SSIS) can be a useful help for sales men. An SSIS should give support in two problem areas. The first area concerns the problem of getting a valid product specification, i.e. a specification of a product which falls within the product assortment. The second area concerns the problem of getting the product that is the best solution for the problem of the customer. Such an SSIS must be able to communicate in three different languages. These languages are called user-language, functional language and technical language. In this paper the problem of specifying a product in technical language is treated. With the building of a prototype of such an SSIS it is demonstrated that it is possible to give a salesman sufficient support for the problem of getting a valid product specification. The proposed solution for the second problem area has not been processed into the prototype

Configuration of complex products

Making a configuration of a complex product in the course of a sales process is a difficult matter. A sales-support information system (SSIS) can be a useful help for sales men. An SSIS should give support in two problem areas. The first area concerns the problem of getting a valid product specification, i.e. a specification of a product which falls within the product assortment. The second area concerns the problem of getting the product that is the best solution for the problem of the customer. Such an SSIS must be able to communicate in three different languages. These languages are called user-language, functional language and technical language. In this paper the problem of specifying a product in technical language is treated. With the building of a prototype of such an SSIS it is demonstrated that it is possible to give a salesman sufficient support for the problem of getting a valid product specification. The proposed solution for the second problem area has not been processed into the prototype

Logistics control enabled by IT, a window in the future

When we look at historic developments in logistics organization and control concepts, we can conclude that the past shows an ongoing trend towards a more integral approach to achieve logistical coordination. The decentralized reorder point techniques used in the fifties gradually changed from MRP-I (sixties, seventies) to MRP-II (eighties, nineties). This trend is now extending beyond the walls of an individual factory. Companies feel a need to cooperate in the areas of logistics structures, forecasting, master scheduling and ordering. When we look to this integration challenge we can conclude that a different approach than used in the past is necessary. Since implementing a centralized control concept across companies is not possible, new developments are required in the area of decentralized control. We foresee that future control systems are able to communicate with supplier and customer control systems. Furthermore, we expect that these developments will also influence the setup of decentralized control systems within the company. Instead of having one control system with a scope that covers the entire production chain within the company, we will see a more modular approach where each sub control system covers only a part of the production system, e.g., a department. The expected benefits of this approach is that such an architecture provides departments with better opportunities to incorporate their specific planning requirements in the control system

The value of rescheduling functionality within standard MRP packages

One of the basic functions of an MRP system is to issue rescheduling messages that urge the planner tospeed up or slow down open orders. It seems in practice that these messages are not used at all by planners. This is mostly due to the inaccuracy of MRP, that more or less ignores safety time, safety stocks and lotsize flexibility in the calculation of reschedule-in messages. Reschedule-out messages are usually ignored because planners do not see the value of the message. Other reasons for not adhering to rescheduling messages are a lack of maintenance of MRP parameters or simply the wrong use of the MRP function. In the future, MRP rescheduling functionality will be used even less than today, due to the changing role of MRP within the planning framework. With the uprise of finite capacity scheduling packages, MRP is being pushed one level upward in the planning hierarchy. This means that rescheduling functionalities for the short term will become completely obsolete in MRP systems

A review of capicity planning techniques within standard software packages

This paper gives a review of capacity planning techniques from which today's standard software packages for production control make their choice. The following techniques are discussed in the paper: four variants of the rough cut capacity check, capacity requirements planning with infinite and finite loading, input/output planning without and with individual work orders, and a number of sequencing techniques. An important issue throughout the paper is the concept of robustness and nervousness of planning techniques, Aspects of interaction between techniques and human planners arc given. The human planner is still an important factor in capacity planning