Within this context, and although new technologies are still crucial for the companies' competitiveness, it becomes more difficult to get a competitive advantage based solely on the adoption of new technologies. To be able to cope with environmental change, one must also consider new organisational concepts like telework.
The new ICT, however, do offer many opportunities to improve the companies’ competitiveness. For example, the implementation of CIM (Computer Integrated Manufacturing) and subsequent concepts helped to increase productivity in the manufacturing industries, in the past decades. Business process support technology, also, has already a long tradition. Information systems have tried to cope with this issue by transaction processing. However, previous attempts to automate office work and increase office productivity failed, mainly because individual activities were automated without an understanding of how they fit into the entire business processes.
Based on the previous experience in procedure automation systems, new software products and enhanced office information systems are being developed which fall into the category of workflow management. It is not a new technology for procedure automation, but takes the formal part of procedure processing applications and combines it with general communication and information sharing facilities.
Telework, being an innovative work organisation form for new decentralised organisational structures, calls for the use of workflow management technology.
This added value to traditional office automation results from the fulfilment of today’s requirements for co-operative work. Computer systems must support, and not necessarily automate, predictable and highly structured business processes; as well as cope with so-called ad-hoc processes, unanticipated contingencies, dynamic change and breakdowns; so as to achieve the final objective of customer satisfaction.
The flexibility of telework in the dimensions time and location of task execution, within a clear legal framework for employment contracts, must make it possible to take advantage of this work organisation for the companies’ competitiveness.
Today, telework is mainly used for isolated tasks and those with fewer cross-references to others. The individual teleworker can use an uncountable number of ICT solutions to have support for the fulfilment of those isolated tasks. But the fact is that most business processes are co-operative processes. It is becoming clear that telework will only achieve its full potential if attention is given to that fact. The increasing need for telework co-ordination and monitoring is seen to be one of the main obstacles to the spreading of co-operative telework.
COBIP pilot sites were chosen to ensure a broad range of target users, whilst keeping a focus on the needs of small and medium sized enterprises working together with individual teleworkers.
Inputs from pilot sites were used for requirements gathering, as well as for the subsequent test and validation activities.
This demonstration project contributes to encourage companies to implement telework as an accepted innovative organisational practice. This should help to create new kinds of (tele) jobs throughout Europe and support the consolidation of the European internal labour market and the compensation of labour between urban and rural areas.
The main objective of the COBIP project was therefore to improve the productivity and competitiveness of companies with organisational structures based on telework. COBIP facilitates the management of virtual departments and teams through telework, by providing the adequate telework support services.
This paper presents the COBIP approach to building a workflow management system that supports the co-ordination of decentralised telework activities through activity chain model execution.
The system is based on the Windows NT platform, using Internet technology and distributed architectures (TINA / CORBA) over broadband networks. Telework visual interaction is based on standard video-conferencing services. A digital library is provided that allows the storage and retrieval of multimedia documents handled and exchanged by the teleworkers as well as management facilities.
The engineering of the telework enterprise may follow the Purdue Enterprise Reference Architecture life cycle. Figure 9 illustrates the phases of the engineering project life-cycle, according to the so-called Purdue Enterprise Reference Architecture (PERA).
The life-cycle starts with the Identification phase of the Enterprise Business Entity, leading to the first description of the management mission, vision and values for that Entity, plus any further philosophies of operation or mandated actions concerning it, such as choice of processes, vendor selection, etc. From the management mission, vision, etc., the operational policies for the units in all areas of potential concern are derived in the Concept Phase. The earlier prescription and selection of possible options by the management leads to the establishment of operational requirements for the manufacturing plant, which in turn lead to a statement of the requirements for all equipment and for all methods of operation which are developed along the Definition Phase. It should finally be noted that there are only two types of requirements, those defining information processing tasks and those defining physical operation tasks. These tasks become collected into modules or functions, and these can in turn be connected into networks of information or of material and energy flow, resulting in the Information Functional Network or in the Operations Functional Network.
No consideration of the place of the humans in the system has yet been made. PERA nevertheless recognises that in any enterprise development program, the human and organisational system is as important as the information system and the physical components. This means that, once the implementation has been considered, the first need is to define which tasks on either side of the overall architecture will be performed by people. Accordingly, three Implementation or Physical Architectures are introduced into the telework-engineering project. These are:
Having in mind all these aspects, the modelling tool may be used to capture the inherent co-operative business processes for telework. Further model refinement will lead to the construction of the so-called executable model. Upon its release, this model will be executed on top of the so-called Enterprise Model Execution and Integration Services (EMEIS in Figure 9.
Figure 9: Telework Engineering Life-cycle
Figure 10: Physical Architecture for Telework
As presented above, we consider the following Implementation Architectures in this telework enterprise engineering project:
Within the scope of this project we aim to address the enterprise workflow modelling issue, having in mind:
Figure 11 illustrates the Conceptual Application Architecture for Telework Support. Once developed, the business process model is released for execution on the Model Execution and Co-ordination layer. This layer uses standard operating and database services, as well as special multimedia and videoconference services. As described in this scenario, the actual model execution uses underlying services, such as the videoconference, which will allow two teleworkers to meet and discuss relevant issues.
An Information Services interface layer is used, thus providing the system with the ability to cope with the permanent change that characterises today’s information services, like the Internet. Plug-and-play standard modules can easily be added or removed from the system, also allowing for scalability and reduction of the basic system’s cost. In this way, an SME (Small Medium Enterprise) may start with a basic system (e.g. without videoconference services) and later add further services as necessary.
Figure 11: Conceptual Application Architecture for Telework Support
Previous Research, carried out by the AMICE Consortium on CIMOSA , by the GRAI Laboratory on GRAI and GIM , and by the Purdue Consortium on PERA , produced reference architectures meant to organise all enterprise integration knowledge and serve as a guide in enterprise integration programs.
The IFIP/IFAC Task Force analysed these architectures and concluded that, even if there were overlaps, none of the existing reference architectures was totally contained in the others; each of them had something unique to offer. The recognition of the need to define a generalised architecture was the outcome of the Task Force work, leading to the definition of the so-called "GERAM" (Generalised Enterprise Reference Architecture and Methodology). GERAM comprises the methods, models and tools which are needed to build and maintain the integrated enterprise, be it part of an enterprise, a single enterprise or a network of enterprises (virtual enterprise or extended enterprise). GERAM defines a tool-kit of concepts for designing and maintaining enterprises through their entire life span, and provides the means of organising existing enterprise integration knowledge.
Figure 12: GERAM Framework for Enterprise Integration
The GERAM framework presented in Figure 12 provides the necessary guidance for the modelling process and enables semantic unification of the model contents.
The framework identifies the set of components necessary and helpful for enterprise engineering. The general concepts identified and defined in the reference architecture consist of the life cycle, life history and model views, among others. These concepts help the user to create and maintain the process models of the operation and use them in her/his daily work. The modelling tools will support both model engineering and model use by providing the information on functionality and dynamic behaviour needed for efficient operation. Operational models cover both the intra and inter organisation operation and thereby allow the modelling of interactions with customers, suppliers or supporting organisations (e.g. banks, distributors, etc.).
The GERAM framework provides the best background for the tool construction project. The Telework Enterprise Partial Model is built based both on partners' experience, and on the analysis of three telework pilots, including a major European car manufacturer, a system integrator company and an advertising firm.
Iterative analysis of these models will provide an early definition of a telework activity library, and a glossary defining the actual modelling constructs. Further examination of these models will allow the Telework Enterprise Modules derivation: human skills and infrastructure functional operations. As a result of this approach, we will have a library of telework activity partial models, as well as a library of infrastructure functional operations supporting model execution. Combined, these libraries will allow the construction of a model based telework planning and co-ordination infrastructure which may be installed and demonstrated at the pilot sites.
Models are built using PEMs (Partial Enterprise Models in Figure 12) as building blocks (in a ‘LEGO’ or plug-and-play fashion) in the EET (Enterprise Engineering Tools in Figure 12) this project aims to develop. In the beginning, the PEMs library should be based on a standard industry-wide reference models' library, being enriched over time with other locally built PEMs. In the implementation phase PEMs are mapped to EMOs (Enterprise Modules in Figure 12) at the operational level, either directly (one-to-one relationship), or through EMO aggregations (one-to-many), as it is most often the case. EMOs development will probably be left to software/equipment vendors and only in very special cases could be home made, at least in SMEs.
In order to derive some kind of coherence from the complete model, several partial views should be generated for analysis (functional diagrams of business processes [e.g. DFDs], resources hierarchy [e.g. organisation charts] and relations, workflow diagrams, workload diagrams, etc.). This way, business process re-engineering can be fostered without major disruptions, as changes occur most often at the function/resource relation (e.g. function F1 executed by resource X1 from business unit BU1 is replaced by function F2 executed by resource X2 from business unit BU3, and by function F2 executed by resource X2 from business unit BU5) and propagated smoothly through the model structure. When executing the model, the state of each block should be always available for management monitoring.
Telework, as an innovative work organisation-form for new decentralised organisational structures, additionally calls for the use of workflow management technology. Currently there is no co-ordination tool with specific planning functionality for this purpose. In this chapter we presented the approach taken to the engineering of a workflow management system, supporting the co-ordination of decentralised telework activities through telework activity chain model execution. A telework engineering life cycle was proposed, based on the Purdue Enterprise Reference Architecture (PERA). Furthermore, the development and use of the tool the COBIP project aims to create was clearly identified using the GERAM Framework for Enterprise Integration.
Contact Details:Jörg Goletz, Dipl.-Kfm.
The next section of this document: Gestalt - On-line Education and Training - State of the Art