لطفا منتظر باشید ...
19.4 Discussion
19.4.1 Evaluation of the Solution
The proposed solution fulfills the requirements developed in the analysis section above: it reduces the knowledge-transfer problem by 'unsticking'the process design knowledge and providing high-level process-based operations, understandable to an end-user. Furthermore it offers a repository of available high-level building blocks, which are structured in a nonspecialist accessible fashion (in our implementation a template hierarchy). It thus enables end-users to take flexible building blocks from the process handbook database and flexibly reassemble them according to the needs of a particular customer. We therefore think that it supports the rapid incremental development and mass-customization of production processes. We also believe that it could consequently support the enactment of processes in highly flexible organizations.In some cases a production process may require strictly transactional behavior in one part of its enactment, which can be supported by a transaction monitor. But in another part it may also rely on a loosely coupled succession of activities, which are best supported by a groupware discussion database as a coordination mechanism. Therefore we believe that our system's ability to export to multiple enactment support environments will make it more suitable for the support of mass-customization than work flow–management systems (WFMS), which usually only support their own system as enactment support.Furthermore our system proposes to close the gap between high-level concepts and low-level program code generation by focusing on business processes and an inheritance framework of components, which offer a better abstraction than traditional CASE tools. Therefore we believe that the system will be usable by end-users and not only by specialists.The Product Workbench does, however, forgo some of the flexibility of CASE systems and WFMS by using a component-based approach, in which the end-users can only assemble their production processes out of existing components. Developing good and useful product components is a key success factor for such a system. This cannot be accomplished by domain specialists alone, but must involve information systems specialists in order to integrate the components with the back-end systems.[6]
19.4.2 Future Work
There are a variety of open questions in connection with the Product Workbench. The next step is to compose a library of real-world components. This library, and an integration of the Product Workbench into a standard corporate work environment, could be used to explore the practicality of this tool in an actual setting.
A parallel avenue of investigation explores alternate uses of the enactment scripts. One could, for example, use the script to estimate its cost and then price it. This estimate could be improved by connecting the simulation engine to real-world pricing and scheduling information about internal and external resources involved in the production process. Thus an account manager could quote the price and a planned delivery date (using the scheduling information) for a mass-customized product before the firm would have to invest in the enactment of its production.[6]The system will face the usual challenges of component-based systems like integration problems with the transactional behavior of a collection of components, which may lead to deadlocks. While there are extended transaction mechanisms to deal with complex nested transaction schemes, component developers will have to document all potential side effects (i.e., dependencies to other resources and activities) of their components to ensure the correct application of those mechanisms.
