Workflow Automation in Four Administrative Organisations

Transcription

Workflow Automation
in Four Administrative Organisations
highlighting Organisational Applicability
Gaston J.A. Aussems
November 1, 1994
Master’s thesis
Design Methodology Group
Section Information Systems
Department of Computer Science
Committee:
dr. J.N. Brinkkemper
dr. ir. S.M.M. Joosten
dr. ir. R.G.R. Engmann
University of Twente
P.O. Box 217
7500 AE Enschede
The Netherlands
Preface
The report you find before you concludes seven months of reading, writing, traveling, discussing
and thinking. Working at this graduation assignment is something I have done with great pleasure. I hope it is reflected in it’s contents.
This report also concludes five years of study at the Department of Computer Science of the
University of Twente. I hope the years to come will at least be as joyful as those behind me.
The completion of this report would not have been possible without the cooperation of a large
number of people. Some of them, I want to thank personally: Stef Joosten for the excellent
accompaniment, Cees de Widt, Jan Keur, Leo Dols, John Hoogland, Ton van der Stap, Roel de
Regt and Gert Berghorst for the fruitful discussions and their support and cooperation when
exploring the organisations. Of course I want to thank Matthijs Duitshof, Erik Mulder and
Richard Huffmeijer for the pleasant cooperation during the whole WA-12 project, and Arjan
Bulthuis, other friends and the residents of Huize Quinquepertitus for the necessary distractions
and support in the past months. Last but not least, I want to thank my parents for their support
through the years.
Gaston Aussems
Enschede, June 30, 1994
Document Preparation by LATEX
Cover Design by Reginald Kruger
Abstract
With the increasing possibilities of information technology, organisations recognise that information systems are able to provide support for integral business processes, from customer request
to product or service. Focus shifts from individual activities in a business process to the entire
workflow. A workflow is a system of activities related by a trigger relation. An individual
workflow is triggered by a particular event from outside the system.
Workflow is an emerging technology. There are a large number of publications about the topic,
and new tools are appearing on the market. There exists little scientific research on workflow.
This report contains the results of an investigation of workflow systems in four different organisations. It is an empirical study with emphasis on design methods and implementation aspects.
The empirical results partly support existing opinions about workflow, and partly reveal new
insight in different aspects of workflow.
Workflow offers great possibilities for organisations. However, not every organisation is suitable
to be supported by a workflow system. A specialisation study to organisational applicability of
workflow systems is also part of this report. This specialisation contains a theoretical and an
empirical part.
The report as a whole provides a thorough overview of what is written about workflow, generalisations of the experiences of four organisations with workflow, and insight in the organisational
applicability of workflow.
i
Contents
1 Introduction
1.1 Purpose : : : : : :
1.2 Scope : : : : : : :
1.3 Intended Audience
1.4 Structure : : : : :
1.5 Terminology : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
2 Research Plan
2.1 Context : : : : : : : : : : : : :
2.2 Research Problem : : : : : : :
2.3 Goal : : : : : : : : : : : : : : :
2.4 Method : : : : : : : : : : : : :
2.5 Proceedings : : : : : : : : : : :
2.5.1 Start-up : : : : : : : : :
2.5.2 Data Collection : : : : :
2.5.3 Information Processing
2.5.4 Finishing : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : :
3 Workflow Theory
3.1 Definitions : : : : : : : : : : : : : :
3.1.1 Terminology : : : : : : : : :
3.2 Perspective : : : : : : : : : : : : : :
3.2.1 History : : : : : : : : : : : :
3.2.2 Groupware and CSCW : : :
3.2.3 Document Imaging : : : : :
3.2.4 Administrative Organisation
3.2.5 Business Process Redesign :
3.2.6 Logistics : : : : : : : : : : :
3.2.7 Telematics : : : : : : : : : : :
3.3 Functionality : : : : : : : : : : : : :
3.4 Architecture : : : : : : : : : : : : : :
3.5 Business Implications : : : : : : : :
4 Observations
4.1 Introduction : : : : : : : : : : :
4.2 Workflow Automation at InfTech
4.2.1 Introduction : : : : : : :
4.2.2 Project Description : : : :
4.2.3 Process description : : : :
4.2.4 Analysis and Design : : :
4.2.5 Implementation : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : :
1
1
1
1
2
3
5
5
6
6
6
7
7
8
8
8
9
9
11
13
13
13
14
14
15
15
15
15
16
18
21
21
22
22
22
26
26
28
ii
Contents
4.3
4.4
4.5
4.2.6 System Evaluation : : : : : : : : : :
4.2.7 Project Evaluation : : : : : : : : : :
4.2.8 Conclusion : : : : : : : : : : : : : :
Workflow Automation at MedIns : : : : : :
4.3.1 Introduction : : : : : : : : : : : : :
4.3.2 Project Description : : : : : : : : : :
4.3.3 Process Description : : : : : : : : :
4.3.4 Analysis and Design : : : : : : : : :
4.3.5 Implementation : : : : : : : : : : :
4.3.8 Conclusions and Recommendations
Workflow Automation at ChamCom : : : :
4.4.1 Introduction : : : : : : : : : : : : :
4.4.5 Implementation : : : : : : : : : : :
4.4.8 Conclusion : : : : : : : : : : : : : :
Workflow Automation at InvCom : : : : :
4.5.1 Introduction : : : : : : : : : : : : :
4.5.5 Implementation : : : : : : : : : : :
4.5.8 Conclusion : : : : : : : : : : : : : :
5 Comparison and Generalisation
5.1 Introduction : : : : : : : : : : : : : : :
5.2 Projects : : : : : : : : : : : : : : : : : :
5.2.1 Causes : : : : : : : : : : : : : :
5.2.2 Project Organisation : : : : : : :
5.2.3 Proceedings of the Projects : : :
5.3 Processes : : : : : : : : : : : : : : : : :
5.3.1 Goal : : : : : : : : : : : : : : : :
5.3.2 Preconditions : : : : : : : : : : :
5.3.3 Functions : : : : : : : : : : : : :
5.3.4 Process Flow : : : : : : : : : : :
5.3.5 Control : : : : : : : : : : : : : :
5.4 Analysis and Design : : : : : : : : : : :
5.4.1 Purpose : : : : : : : : : : : : : :
5.4.2 Requirements : : : : : : : : : : :
5.4.3 Methods, Techniques and Tools :
5.4.4 Design : : : : : : : : : : : : : : :
5.4.5 Use of the Design : : : : : : : :
5.5 Implementation : : : : : : : : : : : : :
5.5.1 Choices : : : : : : : : : : : : : :
5.5.2 Steps : : : : : : : : : : : : : : :
5.5.3 Execution of the Steps : : : : : :
5.6 System Evaluation : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : :
28
28
28
29
29
29
30
31
33
34
35
35
36
36
36
37
38
39
41
41
41
42
42
42
43
44
45
47
47
48
49
49
49
49
51
53
56
56
57
58
58
59
59
60
60
61
66
66
67
67
67
67
69
iii
Contents
5.7
5.8
5.6.1 Users : : : : : : : :
5.6.2 Organisation : : : :
5.6.3 Efficiency : : : : : :
5.6.4 Improvements : : :
Project Evaluation : : : : :
5.7.1 Goals : : : : : : : :
5.7.2 Method : : : : : : :
5.7.3 Appreciation : : : :
5.7.4 Improvements : : :
Conclusion : : : : : : : : :
5.8.1 Project : : : : : : : :
5.8.2 Process : : : : : : :
5.8.3 Analysis and Design
5.8.4 Implementation : :
5.8.5 System Evaluation :
5.8.6 Project Evaluation :
5.8.7 Overall Conclusions
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
6 Organisational Applicability
6.1 Introduction : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
6.1.1 Purpose : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
6.1.2 Structure of this Chapter : : : : : : : : : : : : : : : : : : : : : : : : : : : :
6.2 Application Domain of Workflow Systems : : : : : : : : : : : : : : : : : : : : : : :
6.2.1 Introduction in Three Approaches : : : : : : : : : : : : : : : : : : : : : : :
6.2.2 Mintzberg : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
6.2.3 Leifer : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
6.2.4 Empirical : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
6.3 Introduction in Organisation Theory : : : : : : : : : : : : : : : : : : : : : : : : : :
6.3.1 Organisations as Systems : : : : : : : : : : : : : : : : : : : : : : : : : : : :
6.3.2 Closed and Open Systems and the IPO Paradigm : : : : : : : : : : : : : : :
6.3.3 Organisational Subsystems : : : : : : : : : : : : : : : : : : : : : : : : : : :
6.3.4 Dimensions of Organisations : : : : : : : : : : : : : : : : : : : : : : : : : :
6.4 An Organisational Approach : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
6.4.1 Mutual Adjustment and the Adhocracy : : : : : : : : : : : : : : : : : : : :
6.4.2 Direct Supervision and the Simple Structure : : : : : : : : : : : : : : : : :
6.4.3 Standardisation of Work and the Machine Bureaucracy : : : : : : : : : : :
6.4.4 Standardisation of Outputs and the Divisionalised Form : : : : : : : : : : :
6.4.5 Standardisation of Skills and the Professional Bureaucracy : : : : : : : : :
6.4.6 Conclusion : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
6.5 An IT-approach : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
6.5.1 Adhocracy and Decentralised Systems : : : : : : : : : : : : : : : : : : : : :
6.5.2 Simple Structures and Stand-Alone Systems : : : : : : : : : : : : : : : : : :
6.5.3 Machine Bureaucracy and Centralised Systems : : : : : : : : : : : : : : : :
6.5.4 Divisionalised Form and Centralised, Distributed and Decentralised Systems
6.5.5 Professional Bureaucracy, Centralised and Distributed Systems : : : : : : :
6.5.6 Organisational Impact : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
6.5.7 Positioning of Workflow Systems : : : : : : : : : : : : : : : : : : : : : : : :
6.6 The Empirical Results : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
6.7 Causes : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
6.7.1 Introduction : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
6.7.2 Throughput : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
6.7.3 Client Focus : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
6.7.4 Flexibility : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
6.7.5 Archiving : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
69
69
70
70
70
70
70
70
71
71
71
71
71
72
72
72
72
73
73
73
73
74
74
74
74
75
75
75
75
76
77
79
81
82
83
84
86
87
88
88
89
90
91
92
93
93
94
95
95
95
97
97
98
iv
Contents
6.8
6.9
6.7.6 Integration : : : : : : : : : : : : : : : :
6.7.7 Control over Process : : : : : : : : : : :
6.7.8 Quality of Data : : : : : : : : : : : : : :
6.7.9 Management Information : : : : : : : :
6.7.10 Malfunctioning System : : : : : : : : :
Logistic Principles and Workflow Automation
6.8.1 Introduction : : : : : : : : : : : : : : :
6.8.2 Definitions and Terms : : : : : : : : : :
6.8.3 Service versus Manufacturing : : : : :
6.8.4 Logistic Goals : : : : : : : : : : : : : :
6.8.5 Logistic Topics : : : : : : : : : : : : : :
6.8.6 Logistic Modeling of the Process : : : :
6.8.7 Manufacture and Supply : : : : : : : :
6.8.8 Transport and Service : : : : : : : : : :
6.8.9 Logistic Improvements : : : : : : : : :
Conclusions : : : : : : : : : : : : : : : : : : : :
6.9.1 Organisation theory : : : : : : : : : : :
6.9.2 Causes for Workflow Systems : : : : : :
6.9.3 Logistics and Workflow Systems : : : :
7 Conclusions
7.1 Introduction : : : : : : : : : : : : : : :
7.2 General Conclusions : : : : : : : : : : :
7.2.1 Theory : : : : : : : : : : : : : :
7.2.2 Technology : : : : : : : : : : : :
7.2.3 Types of Workflow : : : : : : : :
7.3 Organisational Applicability : : : : : :
7.3.1 Organisation Theory : : : : : : :
7.3.2 Causes for Workflow Systems : :
7.3.3 Logistics and Workflow Systems
7.4 Recommendations : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : :
A Research questions
A.1 Algemeen / aanleiding : : : : : : : : : : :
A.2 Beschrijving van het administratieve proces
A.3 Analyse en ontwerp : : : : : : : : : : : : :
A.4 Invoering in organisatie : : : : : : : : : : :
A.5 Evaluatie van het WFM-systeem : : : : : :
A.6 Evaluatie van het project : : : : : : : : : : :
B Het WA-12 rapport van InfTech
B.1 Inleiding : : : : : : : : : : : :
B.1.1 Bedoeling van de tekst :
B.1.2 Bereik : : : : : : : : : :
B.1.3 Doelgroep : : : : : : : :
B.1.4 Structuur : : : : : : : :
B.1.5 Terminologie : : : : : :
B.2 Projectbeschrijving : : : : : : :
B.2.1 Probleemomschrijving :
B.2.2 Workflow bij InfTech : :
B.2.3 Typen workflow : : : :
B.2.4 Voor- en nadelen : : : :
B.2.5 Projectafbakening : : :
B.3 Procesbeschrijving : : : : : : :
: : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : :
99
99
100
100
101
101
101
101
102
103
104
106
108
109
109
113
113
114
114
117
117
117
117
118
118
119
119
119
120
120
121
121
121
121
122
122
123
125
125
125
125
125
126
126
126
126
127
128
130
132
133
v
Contents
B.3.1 Doel : : : : : : : : : : : : :
B.3.2 Voorwaarden : : : : : : : :
B.3.3 Controlemaatregelen : : : :
B.3.4 Functies : : : : : : : : : : :
B.3.5 Procesverloop : : : : : : :
B.4 Analyse en ontwerp : : : : : : : :
B.4.1 Eisen : : : : : : : : : : : :
B.4.2 Tools : : : : : : : : : : : : :
B.4.3 FlowPATH : : : : : : : : :
B.4.4 Ontwikkelmethode : : : :
B.4.5 Gebruik van het ontwerp :
B.4.6 Workflow componenten : :
B.4.7 Implementatie : : : : : : :
B.5 Invoering : : : : : : : : : : : : : :
B.5.1 Keuzes : : : : : : : : : : :
B.5.2 Stappen : : : : : : : : : : :
B.5.3 Hardware : : : : : : : : : :
B.6 Conclusies en aanbevelingen : : :
B.6.1 Verloop van het onderzoek
B.6.2 Conclusies : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : :
C Het WA-12 rapport van MedIns
C.1 Inleiding : : : : : : : : : : : : : : : :
C.1.1 Bedoeling van de tekst : : : : :
C.1.2 Bereik : : : : : : : : : : : : : :
C.1.3 Doelgroep : : : : : : : : : : : :
C.1.4 Structuur : : : : : : : : : : : :
C.1.5 Terminologie : : : : : : : : : :
C.2 Projectbeschrijving : : : : : : : : : : :
C.2.1 Doel : : : : : : : : : : : : : : :
C.2.2 De MedIns : : : : : : : : : : :
C.2.3 Probleemomschrijving : : : : :
C.2.4 Projectverloop : : : : : : : : :
C.2.5 Projectorganisatie : : : : : : :
C.2.6 Conversie van oude dossiers :
C.3 Procesbeschrijving : : : : : : : : : : :
C.3.1 Doel : : : : : : : : : : : : : : :
C.3.2 Procesverloop : : : : : : : : :
C.3.3 Functies : : : : : : : : : : : : :
C.3.4 Controlemaatregelen : : : : : :
C.4 Analyse en ontwerp : : : : : : : : : :
C.4.1 Doel : : : : : : : : : : : : : : :
C.4.2 Eisen : : : : : : : : : : : : : :
C.4.3 Tools, methoden en technieken
C.4.4 Het dossier : : : : : : : : : : :
C.4.5 Deelprocessen : : : : : : : : :
C.4.6 Overige functies : : : : : : : :
C.4.7 Gebruik van het ontwerp : : :
C.5 Invoering : : : : : : : : : : : : : : : :
C.5.1 Keuzes : : : : : : : : : : : : :
C.5.2 Stappen : : : : : : : : : : : : :
C.5.3 Realisatie : : : : : : : : : : : :
C.6 Evaluatie systeem : : : : : : : : : : :
C.6.1 Effecten op gebruikers : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : :
133
133
133
133
133
134
135
135
138
141
142
142
142
142
143
143
145
145
145
145
147
147
147
147
147
148
148
148
148
149
149
150
151
151
151
151
152
153
154
154
154
154
154
154
155
160
161
161
161
161
162
163
164
vi
Contents
C.6.2 Effecten op de relatie met klanten
C.6.3 Totaaloordeel : : : : : : : : : : : :
C.6.4 Mogelijke verbeteringen : : : : : :
C.7 Evaluatie project : : : : : : : : : : : : : :
C.7.1 Realisatie van doelen : : : : : : :
C.7.2 Toepassing van de methode : : : :
C.7.3 Totaaloordeel : : : : : : : : : : : :
C.8 Conclusies en aanbevelingen : : : : : : :
C.8.1 Verloop van het onderzoek : : : :
C.8.2 Conclusies : : : : : : : : : : : : :
C.8.3 Aanbevelingen : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
D Het WA-12 rapport van ChamCom
D.1 Inleiding : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
D.1.1 Bedoeling van de tekst : : : : : : : : : : : : : : : : : :
D.1.2 Bereik : : : : : : : : : : : : : : : : : : : : : : : : : : :
D.1.3 Doelgroep : : : : : : : : : : : : : : : : : : : : : : : : :
D.1.4 Structuur : : : : : : : : : : : : : : : : : : : : : : : : :
D.1.5 Terminologie : : : : : : : : : : : : : : : : : : : : : : :
D.2 Projectbeschrijving : : : : : : : : : : : : : : : : : : : : : : : :
D.2.1 De Kamer van Koophandel : : : : : : : : : : : : : : :
D.2.2 Geschiedenis van de automatisering bij de ChamCom
D.2.3 Projectdoelen : : : : : : : : : : : : : : : : : : : : : : :
D.2.4 Projectorganisatie : : : : : : : : : : : : : : : : : : : :
D.2.5 Projectverloop : : : : : : : : : : : : : : : : : : : : : :
D.2.6 Conversie : : : : : : : : : : : : : : : : : : : : : : : : :
D.3 Procesbeschrijving : : : : : : : : : : : : : : : : : : : : : : : :
D.3.1 Doel : : : : : : : : : : : : : : : : : : : : : : : : : : : :
D.3.2 Voorwaarden : : : : : : : : : : : : : : : : : : : : : : :
D.3.3 Afdelingen en bezettingen : : : : : : : : : : : : : : :
D.3.4 Procesverloop : : : : : : : : : : : : : : : : : : : : : :
D.3.5 Functies : : : : : : : : : : : : : : : : : : : : : : : : : :
D.3.6 Knelpunten : : : : : : : : : : : : : : : : : : : : : : : :
D.4 Analyse en ontwerp : : : : : : : : : : : : : : : : : : : : : : :
D.4.1 Doel : : : : : : : : : : : : : : : : : : : : : : : : : : : :
D.4.2 Eisen : : : : : : : : : : : : : : : : : : : : : : : : : : :
D.4.3 Tools, methoden en technieken : : : : : : : : : : : : :
D.4.4 Functioneel Ontwerp : : : : : : : : : : : : : : : : : :
D.4.5 Basisontwerp : : : : : : : : : : : : : : : : : : : : : : :
D.4.6 Afbakening context : : : : : : : : : : : : : : : : : : :
D.4.7 Decompositie in hoofdactiviteiten : : : : : : : : : : :
D.4.8 Beschijving van de workflows : : : : : : : : : : : : :
D.4.9 Gebruik van het ontwerp : : : : : : : : : : : : : : : :
D.4.10 Implementatie : : : : : : : : : : : : : : : : : : : : : :
D.5 Invoering : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
D.5.1 Stappen : : : : : : : : : : : : : : : : : : : : : : : : : :
D.5.2 Schaduwdraaien : : : : : : : : : : : : : : : : : : : : :
D.5.3 Architectuur : : : : : : : : : : : : : : : : : : : : : : :
D.6 Evaluatie systeem : : : : : : : : : : : : : : : : : : : : : : : :
D.6.1 Effecten op gebruikers : : : : : : : : : : : : : : : : : :
D.6.2 Effecten op de organisatie : : : : : : : : : : : : : : : :
D.6.3 Effecten op de efficiëntie : : : : : : : : : : : : : : : : :
D.6.4 Totaaloordeel : : : : : : : : : : : : : : : : : : : : : : :
D.7 Evaluatie project : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : :
: : : : : : : : : : : :
: : : : : : : : : : : :
: : : : : : : : : : : :
: : : : : : : : : : : :
: : : : : : : : : : : :
: : : : : : : : : : : :
: : : : : : : : : : : :
: : : : : : : : : : : :
: : : : : : : : : : : :
: : : : : : : : : : : :
: : : : : : : : : : : :
: : : : : : : : : : : :
: : : : : : : : : : : :
: : : : : : : : : : : :
: : : : : : : : : : : :
: : : : : : : : : : : :
: : : : : : : : : : : :
: : : : : : : : : : : :
: : : : : : : : : : : :
: : : : : : : : : : : :
: : : : : : : : : : : :
: : : : : : : : : : : :
: : : : : : : : : : : :
: : : : : : : : : : : :
: : : : : : : : : : : :
: : : : : : : : : : : :
: : : : : : : : : : : :
: : : : : : : : : : : :
: : : : : : : : : : : :
: : : : : : : : : : : :
: : : : : : : : : : : :
: : : : : : : : : : : :
: : : : : : : : : : : :
: : : : : : : : : : : :
: : : : : : : : : : : :
: : : : : : : : : : : :
: : : : : : : : : : : :
: : : : : : : : : : : :
: : : : : : : : : : : :
: : : : : : : : : : : :
164
164
164
165
165
165
165
165
165
166
166
167
167
167
167
168
168
168
169
169
170
171
171
172
178
178
178
178
179
179
180
180
181
181
181
181
181
182
182
182
184
188
188
188
188
190
190
192
192
193
193
193
193
vii
Contents
D.7.1 Realisatie van doelen : : : : : : :
D.7.2 Toepassing van de methode : : : :
D.7.3 Waardering binnen de organisatie
D.7.4 Toekomst : : : : : : : : : : : : : :
D.7.5 Totaaloordeel : : : : : : : : : : : :
D.8 Conclusies en aanbevelingen : : : : : : :
D.8.1 Verloop van het onderzoek : : : :
D.8.2 Conclusies : : : : : : : : : : : : :
E Het WA-12 rapport van InvCom
E.1 Inleiding : : : : : : : : : : : : : : : : : :
E.1.1 Bedoeling van de tekst : : : : : : :
E.1.2 Bereik : : : : : : : : : : : : : : : :
E.1.3 Doelgroep : : : : : : : : : : : : : :
E.1.4 Structuur : : : : : : : : : : : : : :
E.1.5 Terminologie : : : : : : : : : : : :
E.2 Projectbeschrijving : : : : : : : : : : : : :
E.2.1 Doel : : : : : : : : : : : : : : : : :
E.2.2 InvCom : : : : : : : : : : : : : : :
E.2.3 Aanleiding : : : : : : : : : : : : :
E.2.4 Projectverloop : : : : : : : : : : :
E.2.5 Projectorganisatie : : : : : : : : :
E.2.6 Problemen : : : : : : : : : : : : :
E.3 Procesbeschrijving : : : : : : : : : : : : :
E.3.1 Doel : : : : : : : : : : : : : : : : :
E.3.2 Voorwaarden : : : : : : : : : : : :
E.3.3 Levensstadia van een hypotheek :
E.3.4 Procesverloop : : : : : : : : : : :
E.3.5 Functies : : : : : : : : : : : : : : :
E.3.6 Aantallen : : : : : : : : : : : : : :
E.3.7 Controlemaatregelen : : : : : : : :
E.4 Analyse en ontwerp : : : : : : : : : : : :
E.4.1 Doel : : : : : : : : : : : : : : : : :
E.4.2 ICflow en ICgiro II : : : : : : : : :
E.4.3 Eisen : : : : : : : : : : : : : : : :
E.4.4 Tools, methoden en technieken : :
E.4.5 Ontwerp : : : : : : : : : : : : : :
E.4.6 Het Dossier : : : : : : : : : : : : :
E.4.7 De Workflow : : : : : : : : : : : :
E.4.8 Rappelering : : : : : : : : : : : : :
E.4.9 Context : : : : : : : : : : : : : : :
E.5 Invoering : : : : : : : : : : : : : : : : : :
E.5.1 Planning : : : : : : : : : : : : : :
E.5.2 Architectuur : : : : : : : : : : : :
E.6 Evaluatie systeem : : : : : : : : : : : : :
E.6.1 Effecten op gebruikers : : : : : : :
E.6.2 Effecten op de organisatie : : : : :
E.6.3 Effecten op de efficiëntie : : : : : :
E.6.4 Totaaloordeel : : : : : : : : : : : :
E.6.5 Mogelijke verbeteringen : : : : : :
E.7 Evaluatie project : : : : : : : : : : : : : :
E.7.1 Realisatie van doelen : : : : : : :
E.7.2 Toepassing van de methode : : : :
E.7.3 Waardering binnen de organisatie
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
193
194
194
194
195
195
195
195
197
197
197
197
197
198
198
198
198
198
199
199
201
201
202
202
202
202
204
208
209
209
209
209
209
210
210
210
211
213
216
217
218
218
219
221
221
221
222
222
222
222
222
223
223
viii
Contents
E.7.4 Totaaloordeel : : : : : : : :
E.7.5 Mogelijke verbeteringen : :
E.8 Conclusies en aanbevelingen : : :
E.8.1 Verloop van het onderzoek
E.8.2 Conclusies : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : :
223
223
223
223
223
ix
List of Figures
3.1
3.2
3.3
ER Model of Concepts : : : : : : : : : : : : : : : : : : :
Group Process Taxonomy with Examples : : : : : : : :
A Generic Architecture for a Workflow Support System
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
4.10
4.11
Logistic versus Procedural Workflow Dimension : :
Routing versus Task Oriented : : : : : : : : : : : : :
Architecture of the IT-2000 System : : : : : : : : : :
Process at MedIns : : : : : : : : : : : : : : : : : : :
Infrastructure at MedIns : : : : : : : : : : : : : : : :
Context of FLUSH (step 1) : : : : : : : : : : : : : : :
Main Activities in FLUSH (step 2) : : : : : : : : : :
Example of a Workflow Diagram in FLUSH (step 3)
Infrastructure at ChamCom : : : : : : : : : : : : : :
Life stages of a Mortgage at InvCom : : : : : : : : :
Context of the ICflow System : : : : : : : : : : : : :
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
5.9
5.10
5.11
5.12
The Life Cycle of a Mortgage at InvCom : : : : : : : : : : :
MedIns Process Schema Technique : : : : : : : : : : : : : :
Method Process Model of the InfTech Method (Level 0) : :
Method Process Model of the InfTech Method (Level 1) : :
Stepwise Workflow Construction in the InfTech Method : :
Method Process Model of the MedIns Method : : : : : : : :
Method Process Model of the ChamCom Method (Level 0)
Method Process Model of the ChamCom Method (Level 1)
Method Process Model of the InvCom Method (Level 0) : :
Method Process Model of the InvCom Method (Level 1) : :
Method Data Model at the Four organisations : : : : : : : :
The Introduction at InfTech : : : : : : : : : : : : : : : : : :
6.1
6.2
6.3
6.4
6.5
6.6
6.7
6.8
6.9
6.10
6.11
6.12
6.13
Mapping of Workflow Systems on the Organisational Typology
The Input-Process-Output (IPO) Paradigm : : : : : : : : : : :
An Open System and its Subsystems : : : : : : : : : : : : : : :
Horizontal and Vertical Task Division : : : : : : : : : : : : : :
The Coordination Mechanisms According to Mintzberg : : : :
Flow of Information in an Adhocracy : : : : : : : : : : : : : :
Flow of Information in a Simple Structure : : : : : : : : : : : :
Flow of Information in a Machine Bureaucracy : : : : : : : : :
Flow of Information in a Divisionalised Form : : : : : : : : : :
Flow of Information in a Professional Bureaucracy : : : : : : :
Adhocracy and Decentralised Systems : : : : : : : : : : : : : :
Simple Structure and Stand-Alone Systems : : : : : : : : : : :
Machine Bureaucracy and Centralised Systems : : : : : : : : :
: : : : : : : : : : : : : : :
: : : : : : : : : : : : : : :
: : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : :
: : : : : : : : : : : : :
: : : : : : : : : : : : :
: : : : : : : : : : : : :
: : : : : : : : : : : : :
: : : : : : : : : : : : :
: : : : : : : : : : : : :
: : : : : : : : : : : : :
: : : : : : : : : : : : :
: : : : : : : : : : : : :
: : : : : : : : : : : : :
: : : : : : : : : : : : :
: : : : : : : : : : : : :
: : : : : : : : : : :
: : : : : : : : : : :
: : : : : : : : : : :
: : : : : : : : : : :
: : : : : : : : : : :
: : : : : : : : : : :
: : : : : : : : : : :
: : : : : : : : : : :
: : : : : : : : : : :
: : : : : : : : : : :
: : : : : : : : : : :
: : : : : : : : : : :
: : : : : : : : : : :
11
14
16
23
26
28
32
33
38
39
39
40
44
45
58
59
62
62
62
63
63
63
64
64
65
68
74
76
76
80
80
81
82
84
85
86
89
90
90
x
List of figures
6.14
6.15
6.16
6.17
6.18
6.19
6.20
6.21
6.22
6.23
6.24
6.25
6.26
6.27
6.28
6.29
6.30
Divisionalised Form and a Distributed System : : : : : : : : :
Professional Bureaucracy and a Distributed System : : : : : : :
Multi-Dimensional Categorisation of the Twelve Organisations
Flexibility as a Result of the Workflow Approach : : : : : : : :
The Systems Approach versus the Workflow Approach : : : :
The Continuous Process of Quality Care : : : : : : : : : : : : :
Logistic Concept of an Administrative Organisation : : : : : :
The Building Blocks for a Logistic Workflow : : : : : : : : : :
Stock and Queue : : : : : : : : : : : : : : : : : : : : : : : : : :
Basic System Structures for Manufacture and Supply : : : : : :
Basic System Structures for Transport and Service : : : : : : :
Elimination of Workflow Activities (example) : : : : : : : : : :
Integration of Workflow Activities (example) : : : : : : : : : :
Broadening of the Workflow (example) : : : : : : : : : : : : :
Parallellisation of the Workflow (example) : : : : : : : : : : : :
Increasing the Capacity of a Workflow Activity (example) : : :
Increasing the Effectivity of a Workflow Activity (example) : :
B.1
B.2
B.3
B.4
B.5
B.6
B.7
B.8
B.9
De workflowvisie van de InfTech/Pallas Athena
De oude situatie en die in de pilot : : : : : : : :
Routeringsgeorienteerde workflow : : : : : : : :
Taakgeorienteerde workflow : : : : : : : : : : :
Het FlowPATH-model : : : : : : : : : : : : : : :
De opbouw van het systeem : : : : : : : : : : :
De implementatie : : : : : : : : : : : : : : : : :
Het invoeringstraject : : : : : : : : : : : : : : : :
De pilot hardware-opstelling : : : : : : : : : : :
C.1
C.2
C.3
C.4
Postverwerking binnen het MI2-systeem : : : :
Het statusdiagram van een inkomend poststuk
Het statusdiagram van een uitgaand poststuk :
De infrastructuur van het MI2-systeem : : : : :
D.1
D.2
D.3
D.4
D.5
D.6
D.7
D.8
Context afbakening : : : : : : : : : : :
Hoofdactiviteiten in FLUSH : : : : : : :
Workflow controleren & deponeren : :
Workflow corrigeren deponering : : : :
Workflow aanmaken V-formulier : : : :
Workflow reproduceren documenten : :
Workflow reproduceren voor abonnees
Opbouw van het netwerk : : : : : : : :
E.1
E.2
E.3
E.4
E.5
E.6
E.7
E.8
De levensstadia van een hypotheekdossier
Eerste deel van de procesbeschrijving : : :
Tweede deel van de procesbeschrijving : :
Derde deel van de procesbeschrijving : : :
Het doorhalen van een hypotheekakte : : :
De verwerking van de post : : : : : : : : :
De goedkeuringsprocedures : : : : : : : : :
De context van het ICflow-systeem : : : : :
: : : : : : : : : : :
: : : : : : : : : : :
: : : : : : : : : : :
: : : : : : : : : : :
: : : : : : : : : : :
: : : : : : : : : : :
: : : : : : : : : : :
: : : : : : : : : : :
: : : : : : : : : : :
: : : : : : : : : : :
: : : : : : : : : : :
: : : : : : : : : : :
: : : : : : : : : : :
: : : : : : : : : : :
: : : : : : : : : : :
: : : : : : : : : : :
: : : : : : : : : : :
: : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : :
91
92
94
97
99
100
104
107
107
108
108
109
110
111
112
112
113
127
134
136
137
139
143
143
144
145
156
157
159
162
183
183
184
186
187
188
190
193
203
205
206
207
208
213
215
218
xi
List of Tables
2.1
Duration of a (Sub)Project
4.1
4.2
4.3
4.4
4.5
Characteristics of the Three Workflow (Environments) :
Proceedings of the MI2 Project : : : : : : : : : : : : : :
Steps in the FLUSH Project : : : : : : : : : : : : : : : :
Costs and Benefits Estimate for the Reports Application
Project Proceedings at InvCom : : : : : : : : : : : : : :
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
5.9
5.10
Causes for Developing a WF-system at the Four Organisations
Project Organisation at the Four Organisations : : : : : : : : :
Functional Involvements at the Projects : : : : : : : : : : : : :
Steps in the Projects of the Four Organisations : : : : : : : : :
Characteristics of the Three Processes : : : : : : : : : : : : : :
Requirements for the Analysis and Design Step : : : : : : : : :
Analysis Activities : : : : : : : : : : : : : : : : : : : : : : : : :
The SDM phases at ChamCom and InvCom : : : : : : : : : : :
Hardware Platforms in the Four Projects : : : : : : : : : : : : :
Hard- and Software Use in the Four Projects : : : : : : : : : : :
6.1
6.2
6.3
6.4
6.5
6.6
6.7
Structural and Contextual Dimensions of Organisations : : : : : : : : : : : : : : : 78
The Structural Dimensions of Standardisation Based Coordination : : : : : : : : : 87
Conformations between Organisational and Information Systems Typology : : : : 88
Causes at all Organisations : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 96
Service Technology versus Manufacturing Technology : : : : : : : : : : : : : : : : 102
Structural Characteristics of Service Organisations versus Product Organisations : 103
Effects of Improvement Techniques : : : : : : : : : : : : : : : : : : : : : : : : : : : 110
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
B.1 De drie verschillende workflow(omgevingen)
C.1 De afdelingen van MedIns : :
C.2 Het verloop van het project :
C.3 Voorbeeld van een indexatie :
D.1
D.2
D.3
D.4
: : : : : : : : : : : : : : :
: : : : : : : : : : : : : : :
: : : : : : : : : : : : : : :
: : : : : : : : : : : : : : :
: : : : : : : : : : : : : : :
: : : : : : : : : : :
: : : : : : : : : : :
: : : : : : : : : : :
: : : : : : : : : : :
: : : : : : : : : : :
: : : : : : : : : : :
: : : : : : : : : : :
: : : : : : : : : : :
: : : : : : : : : : :
: : : : : : : : : : :
24
30
36
37
43
50
51
53
54
57
60
61
65
68
69
: : : : : : : : : : : : : : : : : : : : :
129
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
149
150
157
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
Stappen in het project : : : : : : : : : : : : : : : : : : : : : : : :
Verwachte kosten en besparingen voor de applicatie jaarstukken
Beknopte datadictionary : : : : : : : : : : : : : : : : : : : : : : :
Software : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
E.1 Aantallen
7
: : : : : : : : : :
172
176
189
192
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
209
: : : : : : : : : :
: : : : : : : : : :
: : : : : : : : : :
xii
List of tables
1
Chapter 1
Introduction
Summary
This chapter contains general information about the report. The purpose of the document, its
scope, intended audience, structure, and terminology are dealt with. This chapter is meant to
inform the reader about the report, rather than its contents.
1.1 Purpose
The purpose of the report is to describe an empirical study of workflow systems in four administrative organisations. Much literature has been written about workflow and workflow
management systems. Many publications are based on experience of people active in IT industry or consultancy. Many publications contain opinions rather than scientific information on
workflow systems (refs). This report describes a structured investigation.
1.2 Scope
A general explanation of workflow and workflow management is given before the descriptions
of the experiences. The foundation of this report is laid by the experiences of four organisations
with workflow management. Generalisations of the observations placed in the framework of the
available theory form the result of this report.
1.3 Intended Audience
In the first place, this report is a master’s thesis. In this respect the intended audience is the staff
of the Design Methodology Group of the Department of Computer Science of the University of
Twente. Secondly, the report contains a description and comparison of workflow in four different
organisations. This makes it of interest for the people in these organisations who are involved
with workflow. Finally, the results come from generalisations of empirical data on experiences
with workflow, linked to existing theory. That means anyone with general interest in workflow
may find useful information in this report.
The full description of the assignment is:
‘This research is a comparative study of four workflow systems in as many different
organisations. Purpose of the research is to gain insight in the design and implementation of workflow systems, through descriptive empirical research. After a month
of starting up, collection of data takes place for three months. Next, two months are
devoted to a comparative study, in which a specialisation on a specific aspect takes
2
1. Introduction
place. The last month is meant to finish the work. The research results in a report
for every participating organisation and a master’s thesis. This research is part of the
WA-12 project.’
The graduation committee consists of the following staff members of the Department of Computer
Science of the University of Twente:
Dr. J.N. Brinkkemper
Dr.ir. S.M.M. Joosten
Dr.ir. R.G.R. Engmann
This research is one of the four subprojects of the WA-12 project. Each subproject is an research
of four workflow systems in organisations. Researchers of the WA-12 project are:
Stef Joosten
Matthijs Duitshof
Erik Mulder
Richard Huffmeijer
Gaston Aussems
1.4 Structure
This report consists of three main parts. It starts with a theoretical part (chapter 3). Next an
empirical part (chapters 4, 5 and 6) is presented. The report is concluded (chapters 5, 6 and 7)
with results in the form of a comparison, a specialisation and finally conclusions. In the appendix,
the research questions and the organisation reports are included.
Each chapter will be discussed briefly.
1. Introduction
The introduction describes the report, and introduces the reader to the WA-12 project.
2. Research Plan
This chapter presents a justification of our way of investigating.
3. Workflow and Workflow Management
The chapter on workflow and workflow management presents the view on workflow that
can be obtained from literature. In chapter 4 and in the first part of chapter 6 the empirical
part of the research appears. The results can be found in chapter 5, in part of chapter 6 and
in the conclusions.
4. Observations
This chapter consists of abstracts of the organisation reports produced during the data
collection phase of the research. The original reports are included as appendices. The
abstracts have the same structure as the original reports. That structure appears once more
in chapter 5.
5. Comparison and Generalisation
The comparison chapter is structured like the organisation reports until the level of subsections. In each subsection the situation for each organisation is repeated shortly. In that way
the organisations are compared point for point. Generalisation is achieved by recognising
trends, similarities and differences between the four organisations.
1.5. Terminology
3
6. Organisational Applicability
This chapter is not limited to the four organisations. All twelve administrative organisations
that have participated in the WA-12 project are compared here, and the observations are
placed in a framework of organisational theory. Purpose of this specialisation chapter is
to determine the kind of organisations and the kind of processes that have the right fit to
be supported by a workflow system. Also the topics of the causes leading to a workflow
solution and the applicability of logistic principles are addressed. Each WA-12 subproject
has a different specialisation.
7. Conclusions
This final chapter contains conclusions about the observations, the results of the empirical
study, the specialisation and the theory.
1.5 Terminology
The purpose of this section is to introduce terminology that is considered familiar in the rest of the
document. Definitions of notions like workflow, workflow management, workflow automation
and workflow systems are not given here but in chapter 3.
4GL
Fourth Generation Language. 4GL’s offer high level data manipulation constructs.
BPR
Business Process Redesign/Re-engineering
C/S
Client-Server, an information system architecture with central data storage, local data processing, and communication facilities.
CASE
Computer Aided Software Engineering
Case
Case folder, a set of documents relevant for a certain case.
DDE
Dynamic Data Exchange, communication protocol for heterogeneous applications from
Microsoft.
DIS
Document Imaging System
Imaging
The electronic storage and processing of documents.
Implementation
Set of activities with the purpose of making an information system operational in the
organisation.
Method
Approach, based on a certain way of thinking, to carry out an information systems development process, consisting of directions and rules structured according to a systematic
ordering of development activities and corresponding development products.
OM
Research group of the Information Systems group of the faculty of Computer Science,
specialised in development methods for information systems.
4
1. Introduction
Realisation
Set of activities with the purpose to construct an information system, in other words to
realise the design of that information system.
Server
Device, such as a shared hard disk printer, that serves two or more users in a local area
network.
Technique
The manner in which and the notation with which a part of information system development
must take place.
Tool
A possibly automated means to carry out a part of an information systems development
process.
WA-12
Workflow Analysis in Twelve Organisations.
5
Chapter 2
Research Plan
Summary
This chapter describes the research plan for the WA–12 project, an analysis of workflow management in twelve organisations. Is starts with an outline of the context of the project. The
chapter continues with the goal of the research, followed by the research problem. The previously planned research method is outlined and finally the proceedings of the research are
described.
2.1 Context
The University of Twente is a university for technical and social sciences. Computer Science is
one of its technical faculties. This faculty consists of four groups:
IS
Information Systems
TIOS
Tele Informatics and Open Systems
SPA
System Programming and Architecture
SETI
Software Engineering and Theoretical Informatics
The Information Systems group is active in research in Knowledge Based Systems, Database
Systems and Development Methods. This report is one of the results of WA–12, a project in the
last group. The research of development methods includes the following aspects:
Empirical research
Investigating the state of the art of workflow management together with organisations.
Normative research
Developing a method for analysis, design and implementation for workflow systems.
Instrumental research
Designing and developing prototype tools.
The WA–12 project is a part of the empirical research.
The researchers in the WA–12 project are assisted by DCE Nederland BV. DCE Nederland BV
is an independent consultancy bureau for management, organisation and information. DCE
participates in the WA–12 project as part of their R&D activity.
6
2. Research Plan
2.2 Research Problem
The area of workflow management is young and unstable. Tools from a lot of (large) software
vendors appear on the market. There is no commonly accepted framework or terminology for
the area. Publications on experiences with workflow management tend to be informal, and the
few scientific publications lack empirical foundation [MJ94].
An empirical study of experiences with workflow systems can build a bridge between the workflow software industry and the workflow research world. Industry sees the things that research
has to offer, and research sees areas where a more formal approach would help.
The problem is that there is no formal framework yet. Workflow lacks a theoretical foundation.
This leads to incompatible systems. Incompatibility is not desirable, especially for workflow
systems which, by nature, will cross departmental or organisational boundaries.
The situation can be compared with the situation of databases in the seventies. Before the
entity-relationship model emerged as the main standard, different incompatible models coexisted
(hierarchical, network, file-oriented). These models divided the database world.
A formal theory or framework is also desired for workflow systems. Such a framework can be
used to design a development method and to be able to determine the feasibility of a workflow
management system depending on the situation in an organisation.
2.3 Goal
The goal of the research has the following three aspects:
1. Analyse twelve administrative processes in different organisations.
2. Gain insight in the analysis of an administrative process in terms of workflows.
3. Gain insight into the effect of workflow management in the organisation.
Structured analysis of practical experience with workflow systems in administrative organisations
is a way to obtain such knowledge.
Describing how administrative processes are modeled in terms of workflows may result in knowledge of general modeling techniques.
Insight in the effect of workflow management in organisations can be used to compose a general
development method for workflow systems.
2.4 Method
To collect empirical data on workflow management systems the situation in twelve organisations
will be compared. Organisations have been selected on a number of criteria. The organisations
should have an administrative process designed or redesigned with workflow management. This
administrative process should:
be hybrid (partly human and partly automated)
contain both structured and unstructured aspects
contain routine tasks
not too small
The project consists of four subprojects in each of which the situation at three organisations is investigated by one researcher. Each subproject results in a report like this one, and these documents
are input for an overall empirical study in which all twelve organisations are compared.
The duration of the (sub)project is shown in table 2.1. The steps are described below in greater
detail.
7
2.5. Proceedings
Start-up
The first month should be used for a literature investigation. When sufficient knowledge
of workflow has been collected, preparation of the next phase must be carried out. This
preparation consists of composing a structured list with relevant questions, collecting documentation from the organisation and making appointments with the organisations.
Data collection
During data collection the organisations should be visited a number of times, and all
relevant parties involved with workflow should be interviewed. This way, objectivity and
completeness must be guaranteed.
Information processing
After collecting sufficient data, the gathered information should be processed. This should
result in a separate report with a uniform structure for every visited organisation. At this
moment, organisation visits should be aimed at filling the blank spots in the organisation
reports.
Finishing
The last month of the subproject must be devoted to writing the final report. The organisation reports serve as input for the final report, and their contents should be compared in
order to obtain general results.
Nr
Step
Period
Duration
1.
2.
3.
4.
Start-up
Data collection
Information processing
Finishing
December
January - March
April - May
June
1 month
3 months
2 months
1 month
TOTAL PROJECT
December - June
7 months
Table 2.1: Duration of a (Sub)Project
2.5 Proceedings
The scope of this section is limited to the proceedings of the subproject of WA–12 described in
this report. Proceedings of the rest of WA–12 are not relevant here.
2.5.1
Start-up
In the start-up period, a risk analysis was made. Threads for the WA–12 project were analysed
and ordered. Possible actions to avoid them from manifestating or to minimise their effects were
described.
Relevant literature was collected. It appeared that most publications on workflow were not
scientific. Typical articles found were descriptions of experiences with workflow in a specific
organisation, or experiences of consultants or software manufacturers. The few scientific articles
found often present a model without bothering about empirical support of the theories. The
literature investigation is described in [MJ94]. A list of abstracts of a selection of publications is
included in that document, and a list of references is made for later use in WA–12 documents.
New articles were added to the reference list, but the document with abstracts was no longer
updated.
Further, the research method for subprojects was refined [HD93]. In that document, actions to
be taken in the four distinguished phases are specified, and some viewpoints for the questions
8
2. Research Plan
to ask are listed. The final result of this exercise was a list of relevant questions. This list with
explanation is given in appendix A.
2.5.2
Data Collection
In the data collection phase each organisations was visited a number of times. Often, the first visit
meant orientation on the situation in the organisation. The question list produced in the start-up
phase was used as guideline for a conversation with the contact person. The result of the first
contact was a list of answers to these questions, a list of documentation that is relevant for the
investigation and a name list of other people involved in the workflow project. Appointments
for a next visit included appointments for conversations with a selection of these people.
After each visit, notes of the conversations were processed into a log-file. This log is extended
after every new visit. In this way the proceedings of the investigation are stored so that all relevant
data can be traced when it is needed in a later phase.
2.5.3
Information Processing
The rough data in the form of conversation reports was not suitable for the purpose of our
empirical study, the comparison. A format in which the different organisations can be compared
in a structured way was needed. During the data processing phase, a general structure for reports
of individual organisations was developed for this purpose. DCE reviewed a draft version of
this general structure. The information of the conversation reports was used as a source for the
construction of the organisation reports.
Different versions of the organisation reports were presented to the organisations. In this way,
the people involved in the organisation were able to give feedback on our observations. This
feedback, in the form of comments and extensions, was used to make the reports correct and
complete.
2.5.4
Finishing
Each organisation report describes the situation at a specific company. The purpose of WA–12
was to compare existing experiences in order to discover more general features of workflow and
workflow management. The final report of each subproject is a comparison of three organisations.
In this report the different organisations are compared pointwise. This technique results in a lot
of generalisations. These generalisations must be integrated into a kind of framework in order to
be useful.
Since there are four WA–12 subprojects with the same purpose, a differentiation of the results was
needed in order to be able to judge every participating researcher on an own piece of work. For
this purpose each of the four participating student has formulated a unique specialisation.
9
Chapter 3
Workflow Theory
Summary
This chapter gives an overview of the area of workflow, intended for those readers who are
relatively unfamiliar with the subject. The text starts with a set of definitions in section 3.1.
Section 3.2 gives a perspective on workflow from different angles. This allows the reader to
determine the relative position of workflow. The next section gives insight in the functionality
that is to be expected from a workflow system. This is followed, in section 3.4, by a generic
description of the architecture of workflow tools. The last section gives an overview of the
business implications of workflow.
3.1 Definitions
Terminology is a characteristic aspect of any field of interest. The words people utter are often
enough to identify their field of expertise. That is why we give an elaborate account of the
definitions used in this report. The workflow-concepts are defined in terms of the following basic
notions:
event
something that happens; something that occurs
(example: the occurrence of a letter being posted)
actor
one that acts
(example: the person posting a letter)
object
something that is or is capable of being seen, touched, or otherwise sensed
(example: the letter)
These notions are used as the conceptual building blocks of the definitions that follow. The
internal structure of events, actors and objects is not considered relevant. The meanings of these
notions are taken from [Mer63], because we want to use these words in their ‘conventional’
meaning. All other notions are ultimately defined in terms of events, actors and objects.
This section contains the definitions for the notion of workflow and related notions as used in the
WA-12 research project.
Definition 3.1 (activity) An activity is a set of events that occur under the responsibility of one
actor.
10
3. Workflow Theory
This definition emphasises the responsibility for an activity, rather than performing the activity.
The definition allows an activity to be performed by several people, as long as one actor is
responsible. For example, sending out a letter may involve secretaries, delivery services, etc., but
it is considered an activity when those acts are performed under responsibility of the sender.
The verb perform is used with respect to an activity. An activity is performed if the events in the
activity occur. There must be one or more actors to make these events happen. Wherever the
distinction between performance and responsibility is relevant, but not clear from the context, the
phrases responsible actor and performing actor are used. This distinction appears to be important
for the analysis of a workflow system.
Actors can either be human or automated. Both types of actors are treated on the same level of
abstraction in order to model the interaction properly. This hybrid nature (i.e. both human and
automated aspects) is a characteristic of workflow systems.
An event is carried by an object. For example, a damage claim form can carry the event of
submitting a damage claim. Objects can have any physical form, for example a telephone call, a
letter, a note, a form, an electronic message. Objects may have information content as well.
An event occurs as a result of performing an activity. In turn, activities are performed as a result
of the occurrence of events. For example, the submission of a damage claim (event) can occur as
a result of assessing a particular damage (activity). In turn, submission of that claim causes the
insurance company to start processing the claim (activity). This behavior is called triggering.
Definition 3.2 (trigger) An event
performed.
e
triggers an activity
a
if the occurrence of
e
causes
a
to be
In everyday language, the verb is used in three grammatically different ways. In the sentence:
a triggers b, a can be an event, an activity or an actor, but b is always an activity. Each of these
three ways can be interpreted as a grammatical variation of definition 3.2. Consequently, it is not
necessary to provide definitions for each of the alternatives. The alternatives are illustrated by
means of the following examples. The word trigger is also used as a noun. In that case, a trigger
triggered by:
Sample sentence
event
Arrival of the damage claim form triggers the claim registration
procedure.
Submitting the damage claim form triggers the claim registration
procedure.
The customer triggers the claim registration procedure.
activity
actor
is the object that carries a triggering event. For example, the damage claim form can be called a
trigger.
Definition 3.3 (process) A process is a set of activities that share a common purpose.
Processes are defined to give a name to a set of activities that are related in a way that makes
sense in a specific situation. Processes can be divided in subprocesses, which corresponds to the
subset relation between sets. The distinction between a process and an activity is motivated by
the difference in responsibility. An activity has one actor that bears responsibility for performing.
A process may involve different responsible actors.
To illustrate the definitions, we give an ER-diagram that represents the relation between the
notions event, object, activity, process and actor, in the notation according to [EN89] (figure 3.1). This
figure can be skipped safely by readers who are unfamiliar with Entity-Relationship modeling,
because the text contains the same information.
Definition 3.4 (workflow) A workflow is a system whose elements are activities, related to one
another by a trigger relation, and triggered by external events.
11
3.1. Definitions
object
process
carries
performs
event
activity
triggers
actor
responsible
Figure 3.1: ER Model of Concepts
Examples are: the set of activities in an insurance company caused by a damage claim; the work
caused in a hospital when a new patient is admitted and the activities triggered in a bank by a
loan request. A workflow system contains a workflow, all actors and all structures and the means
involved in that workflow. The notion of workflow system does not refer to the technology alone,
but includes all related elements.
Since a workflow is defined as a system, it follows that there are internal and external activities.
Events are therefore implicitly divided in internal and external events, because an event is an
element of an activity. All events that are not element of an activity within the workflow are
external events!!.
3.1.1
Terminology
This section discusses the terms as they were encountered in the organisations that participated
in WA-12. In some organisations (ResLab and InfTech) there is a list of terms. The definitions of
vendors are frequently used in the organisation (organisations BankIns, LeasCom and MortIns).
Other organisations, such as GovLice, use very little specific terminology, but describe it in
conventional terms. None of the organisations has a complete documented set of definitions.
Action
In organisation LeasCom this term denotes the automated triggering and routing of work
by the workflow tool. In this interpretation the term is not synonym for activity, because an
activity is defined as a general set of events.
Case folder
This term was used exclusively in organisation BankIns. It denotes the electronic file on
the documentary information system. The term originates from the DIS tool. It can be
interpreted as a set of objects.
Electronic file
This term was encountered in all organisations that have a DIS based workflow system. It
is an example of an object.
Full case handling
Handling one case by a group of people is denoted as case handling. If a case is dealt with by
a single person, this is called full case handling. This is considered important for improving
customer service. This notion is used in organisations BankIns, CredIns, InvCom, InfTech.
In other organisations, the issue is relevant but the terms case handling/full case handling
are not used. In organisation CredIns case handling is seen as a complementary notion to
workflow management, which is seen as a routing tool.
12
3. Workflow Theory
Function
This word was used in organisations LeasCom and GovFin to denote an actor.
Form/Screen
In organisation SocIns the words form and screen are important, because this organisation
is a "form processing organisation". The paper version is called form, and the electronic
version is called screen. It is an example of an object.
Indexing
Every object is identified for later reference in a DIS. This is called indexing. It is used in all
organisations where imaging is applied.
Logistic workflow
This word was used exclusively in organisation InfTech to denote the physical transport of
work (routing).
Network plan
This term was used exclusively in organisation ResLab. It denotes a modeling technique,
that represents the structure of actions triggered by an event. Therefore it can be seen as a
representation of a workflow.
Procedural workflow
This word was used exclusively in organisation InfTech to denote the support of tasks on
the workplace.
Role
This term is used in organisations BankIns, ResLab, LeasCom, MedIns, InfTech to denote
an actor. Many tools also use the word role to denote an actor.
Step
This term denotes a sequence of actions that can be performed without interruption by the
same function (i.e. role). This meaning was encountered in organisation LeasCom. It is
used as synonym for activity. Other synonyms are action or task.
Workflow
In organisations SocIns, MedIns, MinSub, GovLice, the notion of workflow was hardly
used at all. In organisation MortIns, discussions focus around DIS instead of workflow.
Organisation ResLab has defined workflow as the order of activities initiated by an event,
that must be followed in order to deliver a product or a service. Organisation BankIns sees
workflow as a set of tasks that are to be conducted in a fixed order. The terms process and
procedure are often used as synonyms for workflow.
Workflow automation
This term was used only in organisation GovFin, denoting the implementation of workflow
management by automated means. This meaning is generally acknowledged.
Workflow management
In organisation GovFin, there are two definitions of workflow management. The first is
a control mechanism to route documents through the organisation. The second definition
denotes workflow management as a means to execute tasks, depending on a certain state.
Organisation ResLab defines workflow management as coordination, planning and steering
of workflows; allocating activities to groups of employees; determining the conditions
for the execution of an activity; consolidation of the activity and checking results and
performance. This organisations uses process management and operational management
as synonym. Organisation CredIns sees workflow management as controlling the logistic
flow. In organisation ChamCom, workflow management denotes all software to control and
support administrative processes. Workflow management is seen as advanced queuing.
3.2. Perspective
13
Workflow management does not have to be carried out by automated means. Only one
definition was encountered that uses software.
3.2 Perspective
In this section workflow is put in perspective. The section starts with a historical perspective.
Then, the relation with various other fields is briefly described in subsequent subsections.
3.2.1
History
For a long time many offices have used information technology to support their organisation.
This is not surprising since office work exists for a large part of the processing of data. A
lot of data carried on paper is numerical or textual. The first office applications focused on
numerical data. Computers were used as powerful calculators. Accounting programs and
financial administrations on mainframes were typical office information systems.
In the seventies relational databases evolved rapidly because of the demand pull from the business
world. Memory and processing power increased, which meant that new types of data could be
processed automatically. Since the 80s PC workstations entered the office, together with desktop
applications like word processors and spreadsheets. With these tools, several standard office activities were automated. Soon, the need for information exchange emerged. Data communication
through local and wide area networks became more common.
In many office organisations these trends have led to rather sophisticated hardware platforms.
Many organisations are aware of the potential of these platforms for automated support of entire
processes instead of separate activities. Workstations are connected with each other and with
servers throughout networks. With these platforms it is possible to access information from
any place in the organisation, which enables a far reaching integration of work. In order to
achieve this integration, explicit information about work must be available. Workflow systems
monitor and manipulate this information about work in a client-server environment, in order
to manage, coordinate and control work more efficiently and effectively. This type of support
is called workflow automation. This is not a completely new concept, because information about
work is being stored and operated upon a long time. New about workflow is that it is put into
a new perspective, in which work is the central concept, as opposed to (for example) the dataor process oriented view. The integral view on work and the explicit availability of complete
information makes true workflow management feasible.
The advance in technology makes it possible to handle new types of data electronically, such as
images and sound. The technology is available to store files with photographs, bills, scraps of
paper etc. on electronic media. Being electronically accessible, the consistency and accessibility
can be controlled automatically rather than by complicated office procedures. As a consequence,
major simplification of office procedures can become possible.
3.2.2
Groupware and CSCW
Groupware is a collection of tools to facilitate the cooperation within an organisation. These
tools have lead to the creation of a specialised field named Computer Supported Cooperative Work
(CSCW). A groupware system, or a cooperation support system, is defined as a computer-based
system that supports groups of people engaged in a common task (or goal) and that provides an
interface to a shared environment [EGR91].
A significant part of a person’s work occurs in a group rather than an individual context, which
makes group support an important issue. Coordination, communication and cooperation are the
cornerstones of group activity. Workflow automation is a part of this discipline, due to the fact
that the purpose of workflow automation is facilitating and coordinating activities of groups.
There are many types of groupware. Figure 3.2 shows a taxonomy for group processes. Synchronous group processes require all participants to share time. Interactive conversations are typical
14
3. Workflow Theory
local
distributed
synchronous
meeting
telephone conversation
asynchronous
bulletin board
workflow system
Figure 3.2: Group Process Taxonomy with Examples
synchronous group processes. Asynchronous means that members of the group can participate
in the group process at different moments. The distinction between a local and a distributed
group process completes the matrix.
Like group processes, groupware can be ordered in the same taxonomy. An example from the field
of group decision support systems is the electronic decision room. It supports a local, synchronous
group process, in which decision making is improved by letting a group of people interact more
intensively than in an unsupported meeting. Teleconferencing (distributed, synchronous) is also an
example of groupware, in which a meeting is held on different locations at the same time. Other
groupware, such as Lotus Notes, is primarily intended to support distributed asynchronous
group processes, such as data-sharing, off line discussions and e-mail.
From a technological point of view, workflow is seen as a relatively simple type of groupware.
It supports distributed, asynchronous interaction. Some workflow products focus on structured
group processes, while others support unstructured group processes. The development in workflow tools shows a merging of the two.
3.2.3
Document Imaging
Document imaging concerns the storage and distribution of documents by electronic means.
Simple document image systems (DIS) store information about documents, with the intention
of improving the retrieval of documents or reducing the number of document retrievals. More
sophisticated systems store the documents themselves electronically, mostly on optical discs. The
latter is more expensive in terms of equipment (juke-box, graphical user interfaces), but also in
terms of communication bandwidth.
Workflow automation is often confused with document imaging. Many organisations that participate in WA-12 have combined support for imaging and workflow. Nevertheless, we think that
it is important to make the distinction, because a workflow essentially consist of work. The fact
that documents are an important part of that work means that the two can make a useful combination. It does not mean that they are identical. For example a telephone conversation, a spoken
word or an unwanted situation can trigger work just as well as a document. Furthermore, the
functionality of workflow tools contains components that go beyond the technology of document
imaging, such as the monitoring of a workflow.
We feel that the advantages of both technologies should not be confused either. Advantages of
document imaging are file consistency and fast and unlimited access of document files. Advantages of workflow management are possibilities for monitoring the status of the work process,
optimising the work and increasing the throughput as result of the optimisation.
3.2.4
Administrative Organisation
Workflow management is a specific form of administrative organisation, in the sense that work
is a key concept rather than procedures. It focuses on the interaction of actors rather than the
activity of individual actors, whether the actors are human or automated.
3.3. Functionality
3.2.5
15
Business Process Redesign
Business Process Redesign (BPR) is closely related to workflow. BPR may cause major changes
of the organisation, because business processes are subject of discussion. Workflow management
deals with the organisation of business processes, without disputing the business process itself.
Workflow automation has its main effect on the operational management. It enables improvement of tactical and strategic management because managers spend less time on operational
management tasks. Furthermore, work processes can be simplified and monitored quantitatively, which enables improved job scheduling, shorter feedback loops and improved insight in
the work process.
3.2.6
Logistics
The resemblance between workflow management and logistics is obvious. In both areas processes
must be streamlined regarding throughput and supplies. The fact that logistics are mostly associated with production and workflow management is associated with administrative processes
does not alter the case; none of both disciplines is restricted to production or administration. The
term ’office logistics’ seems to be appropriate in this context. It is associated with the situation
where actors are processing flows of information.
3.2.7
Telematics
Workflow automation is only feasible when an organisation is already utilising data communication such as local networks, which provide electronic-mail, file sharing or database servers. The
association with telematics is prominent, because the advantages of workflow highly depend on
the advantages of improved communication, better access of information and the simplification
of procedures, because information can be retrieved fast and consistent on the right place. Besides
data communication, multi-media is an important telematics aspect related to workflow. Due to
the fact that a lot of information consists of images or even speech, multi-media facilities often
are a part of workflow automation.
3.3 Functionality
Workflow systems offer a set of functionalities, depending largely on the organisation of the
workflow and the tools that support it [Mar92]. Many of the functionalities mentioned in [Mar92]
are very similar. The functionalities are therefore combined into five groups.
1. Routing
2. Monitoring & Control
3. Notification
4. Actor Assignment & Authorisation
5. Procedure Management
These five main functionalities are described in the following paragraphs in more detail.
Routing means that workflow systems can transport information objects like images, documents,
files, etc. automatically between applications on different locations. Routing can be sequential;
i.e. when one actor is ready with an object, this object will automatically be sent to the next actor,
according to a predefined list, or rule-based, where routing is performed depending on certain
criteria. With parallel routing, the object can trigger two or more different activities in which
non-conflicting operations can be performed. Not all tools on the market support parallel routing
(yet) although this is clearly necessary for workflow support.
16
3. Workflow Theory
Monitoring & control functions provide information about the workflow. Monitoring refers to
statistical information about many workflow instances, which enables managers to use quantitative information to adapt the workflow. Tracking refers to a query on the current status of a
specific workflow, which enables the organisation to give instant answers to customers about the
status of work. An audit trail is a log of a workflow. Monitoring and control is technically simple,
because a workflow system has each workflow instance explicitly represented in a database.
To coordinate work also means that the system notifies users or other workflow servers of tasks
and deadlines. This can be done by putting a job in a to-do-list, by sending e-mail or even by
sending out a fax. This functionality requires that each activity can be given a deadline or a
limited duration.
Actor Assignment means that activities can be assigned to people in a flexible way. This functionality implicitly demands an authorisation facility. For instantiations of actors like an individual
user, role or group, access rights and modification rights should be uniquely defined. Rights can
be assigned at workflow level and at activity level.
A mechanism is needed which observes that a certain actor within a group has claimed the activity, and who that individual is. The mechanism should also notify other group members that the
activity is being handled.
Procedures in the business are subjected to continuous change. Increasing demands to react
quickly on changes make it necessary that procedure management is done “on the floor”, without
any programming effort. Procedure management is therefore treated as a separate functionality
of the system. It requires high ergonomic requirements, because procedures may be altered by
almost any (properly authorised) person. A workflow system must provide end-users means
for (re)defining workflow steps, the sequence of these steps, the routing along certain steps and
conditions containing the rules on which the route is determined. As a result, procedures can be
modeled in a flexible manner. Once defined in the system the procedures can be changed and
modified as answer to new demands from the organisation.
Non-electronic steps have to be supported as well.
3.4 Architecture
LEGEND
Client
component
Active
component
Worker
Developer
Manager
Storage
component
Interface
processor
Event
manager
Workflow
manager
Definitions
Transactions
Observations
Figure 3.3: A Generic Architecture for a Workflow Support System
Figure 3.3 gives a generic tool architecture, which is essentially a client/server architecture. It
is generic in the sense that each of the components can occur multiply in different guises. It is
3.4. Architecture
17
also generic with respect to the concrete machines on which the components are located. Any
component can be mapped on any machine, which includes the possibility of combinations of
components on one machine.
Three different storage components are distinguished: a definition store, a transaction store
and an observation store. The definition store contains the structure of workflows. It is filled
and maintained by a workflow developer, most likely supported by a workflow design tool. The
transaction store keeps track of all activities performed in a workflow-instance. This store contains
the information about the current status of particular workflow instances, which is needed for
instance to inform a customer on the whereabouts of his or her case. The observation store
contains information that is collected by monitoring workflows. It is used for workload balancing,
productivity measurement, accounting, etc. The observation store only contains information about
workflows.
There are three different types of active component in a workflow support system: interface
processors, event managers and workflow managers. An interface processor links applications
to the workflow system. For shrink-wrapped software, interface processors may be obtained
from the shelf. For custom applications however, interface processors may have to be tailormade. Event managers keep make sure that the computer takes the initiatives necessary to keep
work going. The event manager maintains a list of work to be done autonomously. By this
mechanism, the system guards deadlines and work conditions, notifying other actors (whether
human or automated) of work to be done. A workflow manager coordinates within workflows,
spawns and monitors other workflows, and communicates with other workflow managers when
necessary.
The clients occur in three different roles: workers, developers and managers. They are distinguished because they require different functionality from a workflow support system. In practice,
combinations of these roles are not uncommon. The worker has a to-do list with work to be done.
Work can be supported by supplying all the information needed to perform a specific activity, by
putting the required tools in place automatically and to make sure that human workers only do
work with added (human) value. Developers have to design and implement workflow support,
which requires development tools. An important selling point of workflow tools is flexibility,
which means that changes to the workflow can be made easily without intervention of application
programmers. The developer will interact with users (both workers and managers) which results
in changes in the definition store. Of course this may have a profound effect on the structure
of the other two stores. The third client role is a manager. In order to control the flow of work,
information about the workflows is used. A manager must be able to put monitors on certain
parts of a workflow system, in order to investigate problems to account for the work done and to
make tactical decisions.
The client/server architecture is an obvious choice, because different employees at different places
contribute to a procedure. The tasks of an employee are preferably done locally, on his or her
workstation. Procedure control, data storage, routing and task allocation are central functions
[HL91].
A workflow client must include a user interface, task execution support and communication
facilities An easy-to-use interface is essential because all kinds of employees have to work with
the system. Since task integration is an important issue in workflow, a graphical multi-tasking
workstation (for example DOS/Windows, OS/2 or Unix) is required in most cases. There are
however tools that support workflow for character terminals as well (e.g. Staffware), which can
sometimes save or postpone large scale investments in graphical workstations. Task execution
support is the core of the client application. The actual processing takes place here, possibly
aided by other applications. Communication to and from the server is necessary. The client must
receive tasks from the server and send them back after processing.
Workflow tools do not add functionality to applications, but focus on the coordination of work
between those applications.
18
3. Workflow Theory
3.5 Business Implications
Workflow and workflow-management are advocated as promising techniques for office automation. The literature gives many business implications both positively and negatively. Both
categories are discussed here.
The following list summarises the positive business implications.
Elimination of delay
Automated routing and work division eliminates unnecessary delays in the process. This
leads to increase of throughput.
Fewer failures
Smaller parts of the process are controlled by the system. Validations checks are easy to
implement.
Increased productivity
Productivity can rise due to the increased throughput. More cases can be processed in the
same amount of time.
Improved service to clients
In case of questions, all essential information concerning a certain client is at hand. Also,
the system can easy be configured to provide new services to anticipate market signals.
Reducing costs
Cost reductions can be found in personnel costs, use of paper and printers. Due to the
increased throughput the costs per case can decrease.
Increasing joy of work
Reducing the number of routine tasks, task integration (with increased responsibilities),
procedures that work and the deployment of increased flexibility to meet user suggestions
can have a beneficial effect on the appreciation of people’s work. Frustrations of files which
are lost or hard to find belongs to the past. Work pressure diminishes due to a more
structured way of working. These factors all contributes to the increase of the joy of work.
Reducing vulnerability
Increased knowledge of the work process, easy ways to reschedule work and the possibility
to defer work provide instruments to reduce the vulnerability of work.
The following weaknesses and drawbacks are reported:
More rigid procedures
The system can prescribe the way of working and the order in which activities are executed.
Workflow can be used to force people in a straight jacket.
Too much a paper factory
If the units of work are to small, workers are forced to execute very small parts of the total
process in high quantities. This reduces motivation and the joy of working.
Too much management inspection (big brother is watching you)
Every worker can be monitored with respect to his speed and way of working. The use of
such information may jeopardise a good working atmosphere.
Underestimating the current procedures
Formalisation, modeling and automation is not possible for every process or step in a
process. Workflow support requires a tersely designed balance of formal and informal
steps.
3.5. Business Implications
19
No way back
The implementation of a workflow system requires a lot of the organisation, bringing about
large changes. A workflow project can be designed such that the the way back is cut off.
This can be a serious problem if the workflow project fails.
A workflow project should be designed to bring out all the advantages, and prevent the drawbacks. Several precautions can be taken to increase the chances of success:
Preliminary investigation
Inventory formal and informal communication circuits
Multi-disciplinary team
Evolutionary development
User participation
Use a pilot or fall-back scenario
20
3. Workflow Theory
21
Chapter 4
Observations
Summary
This chapter is built around the observations at four administrative organisations; an information systems developer, a (medical) insurance company, a Chamber of Commerce and an investment company. During the observations the attention was focussed on the way of modelling in
each organisation, and on the organisational aspects of introducing workflow technology. The
material collected is used in the comparative study, which can be found in the next chapter.
4.1 Introduction
The purpose of this chapter is to describe experiences with workflow automation in four organisations. These organisations all operate in very different branches and therefor they all have their
own characteristics.
InfTech
The project at InfTech, a developer of information technology, shows a profound vision on
workflow and has initiated the IT-2000 pilot to learn by experience.
MedIns
At MedIns, the development of the MI2 workflow system was initiated from a need for an
DIS system
ChamCom
ChamCom went straight for the workflow solution combined with DIS in their FLUSH
projects for their problems with archiving and throughput.
InvCom
InvCom is another example of a typical entrance to workflow through a need for an archiving
solution. In contrast to the problem at MedIns, the ICflow system has a more procedural
nature.
These organisations are described according to a uniform structure. The scope of this chapter
is limited to four organisations in order to achieve descriptions with sufficient detail. Attention
was focussed on the way of modelling in each organisation, and on the organisational aspects of
introducing workflow.
The chapter consists of abstracts of reports of four organisations that participate in the WA-12
investigation. A separate section is devoted to each organisation. For each organisation relevant
observations of project, process, analysis, design and implementation are presented. Furthermore,
evaluations of these observations are given for each organisation. The full texts in Dutch can be
found in the appendices B, C, D and E.
22
4. Observations
4.2 Workflow Automation at InfTech
4.2.1
Introduction
This section describes the workflow project IT-2000, which is under development at InfTech,
an information systems developer in the eastern part of the Netherlands. This project differs
from the other projects in the WA-12 research in the way that it is not the implementation of a
specific process that is important, but the vision of InfTech on workflow automation and workflow
management in general. This due to the fact that InfTech is above all a supplier of information
technology and not an user.
In this chapter the basic structure for all project in this research project is used. Paragraph 4.2.2
gives a description of the IT-2000 project. The underlying process will be discussed in paragraph
4.2.3 and paragraph 4.2.4 continues with the analysis of the process and the design of the system.
In paragraph 4.2.5 the introduction of the system is discussed. Paragraph 4.2.6 en 4.2.7 continue
with an evaluation of the system and the project and paragraph 4.2.8 closes with conclusions.
4.2.2
Project Description
InfTech
InfTech is part of a big information system contractor and focuses on a very distinct part of
the total market for information system users; the market for health care insurance companies.
The clients of InfTech were semi-government organisations with a specific protected geographic
region of clients. But due to the overall commercialisation they have to live up to the standards of
a commercial competitive market where they have to struggle for life. Of course this puts higher
demands on efficiency, effectivity and flexibility. InfTech is using workflow technology as a tool
to built systems that can provide the solutions to these problems. Workflow knowledge is not
present at InfTech. It has therefore contracted workflow consultancy Pallas Athena to supply this
knowledge.
The IT-2000 Project
The IT-2000 project is mainly focused on learning by experience. InfTech has developed a profound vision on workflow, which will be described in this paragraph. InfTech makes a distinction
in the workflow itself; a logistic dimension of the workflow and a procedural dimension of the
workflow. Next to this, different types of workflow and workflow environments are discussed
and the paragraph concludes with an overview of the strengths, weaknesses, opportunities and
threats (SWOT-analysis) of this technology as well as the measures that can be taken to anticipate
the weaknesses and threats. This vision has also been one of the sources for chapter 3.
Logistic and Procedural Workflow
A workflow is a concept of two distinct dimensions, as figure 4.1 shows; the horizontal or logistic
dimension and the vertical or procedural dimension. These dimensions are described below in
greater detail.
Logistic dimension
Workflow management in the literature often just refers to the logistic dimension of this
technology. The important aspect in this dimension is moving information and data from
one worker to another. Indeed, this is an important functionality of the workflow system,
but there is more.
Procedural dimension
The procedural dimension refers to activity support supplied by the workflow system. Not
the actions taken to get the information from one worker to another are important, but what
23
4.2. Workflow Automation at InfTech
Logistic workflow
D
A
B
C
C
A
Procedural workflow
A
Step B
1
2
3
4
5
6
7
Figure 4.1: Logistic versus Procedural Workflow Dimension
is done at a specific destination (the actual activity). The important aspect in this dimension
is controlling and coordinating the activities of the individual worker.
As figure 4.1 shows, the structure and possibilities for control are similar in the logistic (horizontal)
and the procedural (vertical) workflow. Implementing this notion in the development of a
workflow system, an important question arises. What are the smallest activities or the Basic Units
of Work (BUWs) which constitute the total (procedural) workflow? A simple rule is to identify
activities in a way that completing a certain activity results in considering what activity to execute
next. Though this seems quite obvious, it can be difficult from case to case. This way, workflow
enables one to anticipate to changing operational demands.
Types of Workflow (Environments)
In relation with the characteristics of the underlying processes InfTech distinguishes three types
of workflow environments, which are summarised in table 4.1 and will be described below.
1. Ad hoc workflow
This type of workflow is often encountered in environments where a lot of ad hoc work or
work on a low frequent basis is done. Processes are initiated and specified by the end-user.
The processes are often informal. Demands on efficiency and effectivity are low. A number
of people work on a specific case. Examples can be found in review processes or processes
of creating a specific document with a number of people.
2. Structured workflow
This type of workflow is often encountered in administrative environments where processes
are well defined. There are a lot of cases with very few exceptions. There are a number of
employees, often entire departments, available for a certain type of process. An example
can be found in the processing of account mutations.
3. Flexible structured workflow
The flexible type of workflow supports the work processes that are well defined and often
executed but at the same time have a lot of exceptions. These exceptions often consist of
skipping activities, re-processing activities or adding new information to the product. An
example can be found in the processing of an insurance claim.
24
4. Observations
Type of workflow (environment)
Quantity of the process
Level of structuring of the process
Exceptions to the process
Ad hoc
Structured
Flexible structured
few cases
per year
high
high
low
high
high
every case
is unique
none
many
Table 4.1: Characteristics of the Three Workflow (Environments)
Like every (new) technology, workflow management and workflow automation has its advantages, but also its drawbacks. To get some insight in this matter, a SWOT-analysis (Strengths,
Weaknesses, Opportunities and Threats) is made by InfTech.
Strengths and Opportunities of Workflow
InfTech sees the following strengths and opportunities when introducing workflow technology
to the organisation.
Increasing throughput
Automated routing and work division eliminates unneccesary delays in the process. The
transport of information takes up little time when using images. Other possibilities for
increasing the throughput can be realised through recall and monitor functions of the
workflow system.
Less failures
Smaller parts of the process are controlled by the system. Validations checks are easy to
implement that way. Due to the fact that paper documents are substituted by digital images,
no information can get lost.
Increased productivity
Productivity will rise due to the increased throughput. More cases can be processed in the
same amount of time.
More service to the clients
In case of questions, all essential information concerning a certain client is at hand. Also,
the system can relatively easy be configured to provide new services to anticipate to market
signals.
Reducing costs
Workflow systems can provide an attractive reduction of the organisational costs. These
cost reductions are reflected in personnel costs due to the fact that the same amount of
cases can be handled with less employees. Mostly a client wants to process more cases with
the same number of employees. Due to the increased throughput the costs per case will
decrease. Other cost reductions are found in less use of paper and printers.
Increasing joy of work
In the past, employees tended to be frustrated due to the fact that files are lost or hard
to find. In the new situation, all information is at hand at all time. No more time is lost
searching for files. Work pressure is less due to a more structured way of working. All these
improvements contribute to a more joyful way of working.
Reducing vulnerability
Disturbing factors from outside are less harmful to the process. For example, a sick employee
no longer causes delays in the processing of his cases.
25
There are a number of other advantages, which are not as obvious at first sight. Workflow systems
are attractive in terms of integration with present hard- and software. This ensures that workflow
systems upgrade the present information systems (value adding) and current investments are not
lost (asset protection). Also the commitment of the whole organisation is ensured in developing a
workflow system. Management, information analysts as well as end-users have to sit around the
table to get a system suitable for the given situation and conforming to everyones wishes.
Weaknesses and Threats of Workflow
Like every technology, also workflow has it’s drawbacks. When this technology is implemented
without taking the necessary precautions the following dangers are present:
More rigid procedures
The system is dictating the way of working and the order in which the activities within a
procedure are executed. This makes it harder for an individual worker to put creativity in
the work.
To much a paper factory
If the BUWs are to small, employees could be forced to execute very small parts of the total
process in high quantities. This reduces motivation and the joy of working.
To much management inspection
The famous ’big brother is watching you’-symptom. Every worker can be monitored with
respect to his speed and way of working. If this information is not used wisely, a good
working atmosphere is put at risk.
Underestimating the current procedures
Formalisation, modelling and automation is not possible for every process or activity in a
process. Some activities in a process are better executed manually. If one is not careful,
failure will be inevitable.
No way back
The implementation of a workflow system asks a lot of the organisation. The traditional
paper is substituted by digital images and the work division is electronic from then on. Of
course it is possible that this process fails, with all consequences.
Anticipating the Weaknesses and Threats
The dangers, as described above, are evitable by taking the necessary precautions:
Thorough pre-investigation
Preceding the project a thorough pre-investigation is necessary. One has to find the answers
to a number of questions; Which processes are suitable to be tackled by a workflow solution?
What results are to be expected? What changes are to be expected?
Inventory formal and informal communication circuits
The informal communication circuits are at least as important as the formal ones. Neglecting
this will result in a system, not suitable for the organisation.
Work with a multi-disciplinary team
Workflow in particular requires a multi-disciplinary development team. The system will
affect the entire organisation, so the entire organisation should be involved in the developing
process.
Adopt an evolutionary way of developing
Interacting with the end-users on a frequent base will ensure the participation and commitment of this group. This active participation will eventually result in a system conforming
to the demands of this group.
26
4. Observations
4.2.3
Make the final procedure design after choosing the solution
The tools, used to implement the system, have great impact on the system. Therefore the
final design should not be made before the final solution is chosen in terms of tools etc.
Use a pilot or fall-back scenario
Of course it is possible that the introduction of a workflow system fails. The way back is
hard, so it is important that one has given this some thought before the occasion arises.
Process description
The process underlying the pilot at InfTech is very simple and not important for the workflow
vision of InfTech. It concerns the enrollment and discharge of clients of an insurance company.
A lot of actions have to be taken before a client is submitted for a health insurance. The process
is implemented using full-case handling.
4.2.4
Analysis and Design
ROUTING ORIENTED
TASK ORIENTED
Figure 4.2: Routing versus Task Oriented
Orientation in Tools
As mentioned in 4.2.2 the choice of the solution is very important for the final design. InfTech has
contracted workflow consultancy Pallas Athena to conduct an investigation of available workflow
tools at this moment. In this investigation Pallas Athena, identified a difference in orientation of
the different tools. This is shown in figure 4.2. Tools can be either routing or task oriented. These
notions will be described below.
Routing oriented
In a routing oriented workflow tool the process is described in terms of geographic destinations. The tasks to be performed at these destinations are connected to them. The control
conditions are part of the routing. The order in which to execute the tasks (activities) at one
destination are not part of the routing.
Task oriented
In a task oriented workflow tool the process is described in terms of tasks (activities). The
destinations are related to these tasks, because a specific task has to be executed at a specific
place. The control conditions are part of the task definition. The routing is implicit.
This distinction leads to the following conclusions:
1. If the sequence of activities is an important part of the workflow and workers have to
execute more activities concerning one case at a time, many routing oriented tools don’t
offer enough support.
27
2. In a flexible structured environment full-case handling is often encountered. Routing plays
a minor part in this kind of systems.
3. In a structured environment not only full-case handling but also a paper factory way of
working can be found.
A routing oriented tool is therefore only suitable for structured environments with a paper factory
way of working. A task oriented tool can also be used there. In other structured and flexible
structured environments a task oriented tool is required. On basis of this vision, Pallas Athena
advised to the workflow tool FlowPATH from Bull.
The Developing Method
When developing a system, InfTech uses a non-formal method of nine steps. After every step
an evaluation is executed and an interaction with the client takes place. The nine steps of the
method are:
1. Activities inventory
Due to the distinction between a logistic and procedural workflow, the procedures and
the activities as building blocks of these procedures are key elements. In the first step, all
activities, which constitute the workflow are inventoried.
2. Sequence/Authorisation
Due to the use of scripts the activities are placed in the right sequence, in the way that input
is transformed to output. The authorisation of every activity is also added.
3. Adding data
In the third step the data is added in a way that every end-user has access to the right
information at the time he or she has to execute a certain activity.
4. Database structure
In this step, the database structure is designed, forming the base for the workflow system.
In this structure, ’work’ is represented and all stages in which this work can be.
5. Procedures on activity level
The activities inventoried in step 1 are put in the right sequence in step 2. In this step they
are grouped as procedures. In this way the logistic workflow is determined, as well as the
sequential activities which require routing.
6. Designing electronic forms
The electronic forms, which constitute the user interface are defined in this step. Of course,
interaction with the actual users is of crucial importance in this step. Neglecting this will
cause the design to backfire eventually.
7. Integrate with database, word processor, imaging, scanning, etc.
All parts come together in this stage. All (data) structures defined in the previous steps are
combined with the diverse applications.
8. Write script and integrate with mainframe
In this step, the actual integration with the mainframe is constituted. If necessary, the
technique of face lifting is used, with which the user is shielded from the mainframeapplication through the use of scripts.
9. Management info
In the last step the management info module is created. The information from the database,
concerning the stages of the work is processed to information concerning throughput, work
queues, bottle-necks, etc.
28
4.2.5
4. Observations
Implementation
Implementation/Architecture
emulator
MF-app.
script
activiteit
info
procedure
FlowPATH
ImageWORKS
Figure 4.3: Architecture of the IT-2000 System
The implementation of the system is shown in figure 4.3. In FlowPATH, the procedures are defined.
These procedures are built out of activities and an activity consists of a number of scripts. A script
combines data from the mainframe application (MF-app.) via the emulator using images through
ImageWORKS. The info-module registrates data concerning work queue’s and throughput for
the generation of management information.
Introduction in the Organisation
The implementation of the system is done in phases. Groups of about ten employees are slowly
getting used to doing their work with the workflow system. First for one month, they are trained
in using the system. Then, for the next three months, they are doing part of their activities
using the system and their other activities on the traditional way. The next three months more
activities are done using the system. This process is continued until all activities are done using
the workflow system.
4.2.6
System Evaluation
The pilot project is not implemented on site, so there is no feedback from the end-users. An
evaluation of the system, based on a developers view, will therefore not be meaningful.
4.2.7
Project Evaluation
For this paragraph, the same motivation goes as for the previous. The project is not yet completed,
so an evaluation is not meaningful.
4.2.8
Conclusion
Due to the cooperation with workflow consultancy Pallas Athena , a lot of know-how about
workflow systems is present at InfTech. This know-how is an important base for the method that
InfTech uses for the development of workflow systems. Next to the technological aspect InfTech
is also sensitive for the strategic and commercial wishes of its clients. The general character of the
developed method supplies InfTech with a profound tool to facilitate their clients with systems,
with which they can live up to the changing demands from the market. Up till now, the system
of InfTech is limited to a well functioning pilot. Operational use will have to show the strength
of the used method. Because InfTech is always focused on learning through experience, practical
experiences will contribute to the quality of the used method.
4.3. Workflow Automation at MedIns
29
4.3 Workflow Automation at MedIns
4.3.1
Introduction
This section describes the workflow project MI2, which is implemented at MedIns, an insurance
company in the central part of the Netherlands. In this chapter the basic structure for all the
projects in this research project is used. Paragraph 4.3.2 gives a description of the MI2 project.
The underlying process will be discussed in paragraph 4.3.3 and paragraph 4.3.4 continues with
the analysis of the process and the design of the system. In paragraph 4.3.5 the introduction of
the system is discussed. Paragraph 4.3.6 en 4.3.7 continue with an evaluation of the system and
the project and paragraph 4.3.8 closes with conclusions.
4.3.2
Project Description
MedIns
MedIns is a mutual insurance company for people with a medical profession. MedIns provides
life and damage insurances, financing of houses and practices as well as advise on subjects as
practice and retirement. MedIns is divided in a number of departments, which are working close
together.
The MI2 Project
Main goal of the MI2 project is improving the service towards the clients. For MedIns, a better
service is above all a faster service. This fast service was hard to achieve due to the archiving
problem accompanying paper files. Although the large paper archives are gone by switching
over to micro-filming, some problems have remained:
Files and documents are not accessible before micro-filming
The time between the moment that a document enters the organisation and the moment
the document is accessible for all employees is to large. This has two causes. During the
processing time of the document it is not accessible. At the end of the line, where the
documents are microfilmed, a stack is build until enough documents are available to ’shoot’
an entire film at once.
Files can be hard or impossible to find
When a file is not in the archive, but on someone’s desk, it is hard or even impossible to
find. There is no strict discipline in returning the files to the archive after using.
Many clients have more than one file at MedIns
Mainly due to the previous problem, a new file was made when the existing file cannot
be traced. This way, some clients have multiple files at MedIns, and none of these files is
complete.
Files are not accessible simultaneously
Files, on paper or film, are only accessible for the employee, who has the file in his or her
possession at that moment. Simultaneous access is therefor not possible.
Adding or changing files on microfilm is hard
Due to technical difficulties it is hard to change an already microfilmed file.
MedIns thought an automated file management system would eliminate these problems. The
steps that can be distinguished in the MI2 project are shown in table 4.2.
30
4. Observations
Step
Decision/Phase
Period/Moment
1
2
3
4
5
6
7
8
9
10
Proposition to the board of directors
Proposition to the board of commissioners
Site-visits and construction prototype MI1
Decision to pursue with complete system
Negotiations with WANG
Signing contracts
Development of the MI2 system
Begin testing in the first region
Implementing the system one region at a time
The system is fully implemented and operational
Feb 90
Mar 90
Apr 90-May 90
Jun 90
Jun 90-Aug 90
Sep 90-Oct 90
Nov 90-Jan 91
Feb 91-Mar 91
Jun 91-Jun 92
Jun 92
Table 4.2: Proceedings of the MI2 Project
Project Management
The development of the system has not been executed in a formally defined structure. The
initiator and motor of the project is the head of the IT-department, mr. J. Keur. For the rest of the
project, the development took place in a mixed team, consisting of:
4.3.3
Mr. J. Keur, head of the IT-department of MedIns
An employee with a double function (50
Some end-users, depending on the part of the system that is being developed
A programmer from WANG
Process Description
The process underlying the MI2 system is the processing of mail. It is relatively simple and
mainly determined by the actors in that process. These actors will therefore be used to describe
this process.
Administration
The administration also includes the mail room. Incoming mail is sorted in mail concerning the
activities of MedIns and other mail (bills, folders, etc.). Mail concerning the main activities of
MedIns can be sorted into two categories:
1. The document concerns one item within one department of MedIns
2. The document concerns more items and/or more departments of MedIns
Documents concerning more items and/or more departments within MedIns are complemented
with a routing note. They are not copied, but travel sequentially through the departments. Parallel
processing of this document is not possible, due to the fact that it requires simultaneous access,
which is not possible with paper documents. The documents are send to the client advisors at
the different departments.
Client Advisor
MedIns has divided the total area of the Netherlands into six distinct regions. Every region
has a number of client advisors and outdoor employees. When receiving the document, the
client advisor tries to retrieve the accompanying file. It is possible that the file can not be found
31
in the archive, but that another client advisor of possibly another department has it in his or
her possession. When the file is found, the client advisor continues with the processing of the
document. This can result in one or more of the following actions:
Visiting the client (by an outdoor employee)
Calling the client
Corresponding with the client
All actions result in a written report, which is send to the procurator.
Procurator
The task of the procurator is inspecting whether the document is dealt with in a correct manner.
This inspection is done using the cause for the treatment and the result of that treatment. For
example the application for a cost estimate results in an offering. This application and resulting
offering is assessed by the procurator. If the cause is not correctly dealt with, the document is
returned to the client advisor. If it is correct, there are two possibilities:
1. The document only referred to one item in one department. In this case, the document and
the generated report are stored chronologically in the file of the client. The (paper) file is
restored in the archive.
2. A routing note is connected to the document. In this case, the documents and the file are
send to the department and person mentioned on the routing note.
In this process, the procurators are responsible for a correct treatment as far as insurances are
involved. Management has little insight in the process, except for visual inspection of the proceeding of the primary process.
4.3.4
Analysis and Design
Demands
In this section the analysis and design of the MI2 system is described. MedIns formulated three
demands as to assure that the problems as described in 4.3.2 are solved:
1. The files have to be accessible on-line
2. The files have to be accessible simultaneously
3. Status information of the process has to be available
Tools
Supplier WANG did not have any specific tools to built a workflow system at that time. Therefore
the system is built using the PACE 4GL database environment in combination with the WIIS image
system.
Design
The total MI2 system can be divided in four processes. The two main processes, the processing
of incoming and outgoing mail is shown in figure 4.4. In this schema technique, the columns
represent the different actors in the system and the rows represent the activities in the process.
The four processes will be described below:
32
4. Observations
INCOMING MAIL
mail
Administration
Step 1
scanning
Step 2
indexing
incoming mail
Step 3
Step 4
Client
advisor
Procurator
agreeing
processing
processing
finished
assessing
Step 5
OUTGOING MAIL
good?
signing and
saving mail
Step 1
Step 2
indexing
outgoing mail
Step 3
Step 4
agreeing
send mail
Figure 4.4: Process at MedIns
status:
to be
processed
33
1. Processing incoming mail
This activity concerns the sorting and scanning of the incoming mail, the indexing of
the scanned documents and the agreeing with these indexes, the actual treatment of the
document and the inspection of this treatment. This part of the process is shown in the
upper half of figure 4.4.
2. Processing outgoing mail
This activity concerns the recording of the outgoing mail, the indexing of this outgoing mail
and the agreeing with these indexes. This part of the process is shown in the lower half of
figure 4.4.
3. Batch processing
Documents which have all indexes agreed with, can be copied to optical disc. These
documents all have the status To be copied to OD (Optical Disc). This batch job inhibits the
following activities:
Copying files to optical disk
Deleting magnetic disk files
4. Retrieving files
Files can be retrieved in a variety of manners. The most usual way is the retrieval of a file
of one specific cliënt. Within this retrieval, various selections are possible.
The system also includes a number of other functions concerned with the maintenance of the
system, the main structure and the authorisations.
4.3.5
Implementation
Hard- and Software
MedIns works with a WANG VS 5460 (network) system. The system consisted of a server with a
number of dumb terminals and a magnetical disc unit. This configuration is shown in figure 4.5.
On this server a Cobol application runs for the premium calculations, the calculations for offers,
etc. and the WPplus application for correspondence. For the sake of the MI2 system, a number of
supplements have been made. They are shown in figure 4.5 as dashed lines. These supplements
are:
Before MI2
WANG VS 5460
- Cobol appl.
- WPplus
With MI2
Magnetical
disc unit
WANG VS 5460
- Cobol appl.
- WPplus
- PACE
- WIIS
Terminals
Optical
disc unit
Magnetical
disc unit
Terminals
Image terminals
Scanner
Figure 4.5: Infrastructure at MedIns
1. Next to the existing applications, the PACE (Professional Application Creation Environment) 4GL database system is installed
34
4. Observations
2. The software WIIS (WANG Integrated Image System) is also installed for the support of
image facilities
3. The terminals have been substituted by 31 workstations (PC’s) with A4 displays and windows facilities
4. All scanned documents are stored on fifty 5,25 inch WORM discs, combined in a juke box
with storing capacity in the amount of 47Gb
Training
The training of the employees is done in groups. The most attention is given to the first three
activities: the scanning, indexing and agreeing. The reason lies in the fact that these activities are
very important to smoothly guide the document through the rest of the workflow.
4.3.6
System Evaluation
Considerations and Goals
The following considerations made MedIns decide to develop the MI2 system:
1. Improvement of the file management
The improvements in this area can be measured by the experiences of the employees.
2. Improvement of the competitive position
This can not be determined within the context of this research project.
3. Contributing to the professional image of MedIns
This is also a very subjective matter. Of course, on-line access to all relevant data concerning
a certain client contributes to a (more) professional image.
4. Realising a growth in the revenues with the same number of employees
MedIns has been able to provide more services and to process more cases with the same
number of employees.
Effect on the Employees
After the moment the system was fully operational, a questionnaire was taken under employees.
All users agreed that they had less freedom in their actions. This was not considered to be
a negative characteristic of the system. The working atmosphere remained unchanged. The
following advantages were mentioned:
Towards a more routine based working day
More efficiency
Cost reduction compared to micro-filming
More service towards the client due to fast access to data
The overall conclusion is that the MI2 system has led to inevitable changes in the organisation.
After the learning period the most problems and reservations were gone. The system has led to
improved service towards the client.
4.3.7
35
Project Evaluation
Before developing the system, supplier WANG has promised a number of advantages compared
to the previous situation:
A more efficient file management
Saving time due to faster file access
Cost reduction in archiving activities
More functionalities for the users
Savings on paper and printing equipment
The questionnaire has shown that these expectations are met. Especially, the imaging technique
has caused an enormous reduction in the retrieval time for files. On basis of the evaluation, the
MI2 project can be called a success. De demands are met, without considerable problems that
weren’t foreseen. By being a pioneer with this technology, the relation between costs and benefits
has been very positive, due to the low-cost development by the supplier.
4.3.8
Conclusions and Recommendations
Conclusions
The system is a success, because the intended goals are met. It is not a workflow system in
the since that the workflow can be changed close to the user. A PACE application programmer
is needed for this. The small flexibility, sensed by users is symptomatic for this characteristic.
The system is a schoolbook example of a need for workflow technology grown from archiving
problems. It is a very natural way to get to workflow via a DIS system.
Recommendations
Due to the fact that knowledge of the company process is gathered en due to the fact that an
electronic document infrastructure is present, there are opportunities for more flexibility and
diversification of the workflows. First step could be to inventory the strategic opportunities
by setting priorities. The present success offers MedIns a good starting position for further
commercial expansion.
36
4. Observations
4.4 Workflow Automation at ChamCom
4.4.1
Introduction
This section describes the workflow project FLUSH, which is implemented at ChamCom, a
Chamber of Commerce in the western part of the Netherlands. In this chapter the basic structure
for all the project in this research project is used. Paragraph 4.4.2 gives a description of the
FLUSH project. The underlying process will be discussed in paragraph 4.4.3 and paragraph
4.4.4 continues with the analysis of the process and the design of the system. In paragraph 4.4.5
the introduction of the system is discussed. Paragraph 4.4.6 en 4.4.7 continue with an evaluation
of the system and the project and paragraph 4.4.8 closes with conclusions.
4.4.2
Project Description
As mentioned above, ChamCom is used as abbreviation for a Chamber of Commerce in the
western part of the Netherlands. ChamCom is a public organisation for and run by the Dutch
enterprises and foundations. In the Netherlands, there are about 35 Chambers of Commerce,
which all cover a part of the country. This Chamber counts about 60.000 registered organisations
and has about 180 employees.
Ever since the 4th act of the European Committee, the Chambers have to keep file of the annual
(financial) reports of the registered commercial enterprises. This means that about 20,000 reports
are gathered every year. This counts for about 107.500 images. These have to be available at all
time to be consulted by the public, or by the employees of ChamCom themselves.
Storage in paper form is unpractical. Annual reports are hard to find, get lost, are not accessible
simultaneous and use up a lot of space. ChamCom searched for a solution and found one in
micro-filming. Imaging was also available, but was at that time (the late 80’s) not a mature
technology. The space problem was solved, but the other problems continued to exist. There was
need for a complete digitised system.
The project of developing the FLUSH system has taken 8 steps which are shown in figure 4.3.
These steps will be described below.
Nr
step
period
1
2
3
4
5
6
7
8
Conversations with end-users
Information sessions for all involved employees
Feasibility study
Decision to pursue workflow
The functional design
Selection contractor
Developing the system
Introducing the system
1989/1990
second half 1990
spring 1991
summer 1991
fall 1991
spring 1992
fall 1993
spring 1994
Table 4.3: Steps in the FLUSH Project
Knowing of problems with the administrative processing of several departments conversations
with end-users took place. The workflow solution was proposed and at that time commitment
was gained. In the next step the solution was proposed to the whole organisation and workflow
consultant agency DocWorld was hired to make a feasibility study. This feasibility study covered
four of the eighteen processes at ChamCom. With respect to the process of archiving and reproducing annual reports it concluded that a cost reduction of about half a million Dutch guilders
could be achieved if a document image processing system was implemented company-wide. The
summarised results are shown in table 4.4. The decision to pursue with the workflow technology
was made and ChamCom’s IT-department wrote the functional design with participation of the
end users.
37
4.4. Workflow Automation at ChamCom
system size
Full size system
Pilot system
investment
costs per year
benefits per year
result per year
800.000
1.600.000
297.000
796.000
239.000
1.275.000
- 58.000
+ 479.000
Table 4.4: Costs and Benefits Estimate for the Reports Application
The project continued with a selection of the contractor. This was a lengthy process in which one
contractor was selected from a list of seventeen. None of the contractors had any experience,
building a system like this, so it was very important that the selection committee had enough
confidence in the remaining contractor. At the end a list of three contractors remained which,
according to the selection committee, were all capable of building the system. Nevertheless, the
selected contractor failed, and ChamCom continued with number two on the list. Having build
a more or less similar system already, this contractor succeeded and the system was delivered
in time. The project was organised using a control group and project group. Both groups were
staffed with representatives from ChamCom and the contractor. The tasks of the control group
consisted of:
Assessing the mile stone products delivered by the project group
Inspecting the proceedings of the project
Deciding where the responsibility of the project group ends
Determining starting points
Assessing the consequences of the taken decisions for the contract
The project group is responsible for the direct execution of the project.
4.4.3
Process Description
The process underlying the workflow system is the process of receiving, checking, archiving
and reproducing of (financial) annual reports of Dutch organisations. ChamCom registers the
arrival of an annual report and warns the organisation if after 13 months such a report is still
not available. ChamCom is obliged to grant the public access to these reports when available.
The department Financial Administration uses the reports to categorise the organisations in tariff
groups as to determine the annual contribution each organisation has to make. After use, the
reports are send to the computer department of ChamCom’s for central registration.
The process of registration, categorisation and reproduction can be divided into 4 subprocesses:
1. Processing incoming reports
The report is received and it is checked of the organisation is registered at this ChamCom.
If so, the report is compared with the legislation concerning annual reports. If incorrect, the
report is put aside, until a correction or supplement is received.
2. Processing incorrect reports
By some mean of communication the organisation is informed about the incorrect report
and summoned to supply a correction or supplement.
3. Processing V-forms
After registration and inspection the report goes to the department Financial Administration, which categorises the organisation according to the invested capital.
4. Reproduction of reports
Triggered by the public or an employee of ChamCom, a reproduction of a report is made.
38
4. Observations
The process inhibits a number of bottle-necks and problems, when based on micro-filming;
Reports are not available until microfilmed, films can not always be found, the machine for
printing films is often occupied, returning the films by the public is not checked, the work of
processing and filming is to much for the employees so that other activities of ChamCom are
understaffed due to the previous problem.
After the introduction of a digitised workflow systems these problems have to belong to the past.
4.4.4
Analysis and Design
ChamCom asked Data General to design a DIP system (Document Image Processing) with workflow functionalities to support the total process of the registration and inspection of the reports
as they were offered at ChamCom. In advance, ChamCom formulated a number of requirements
for the design of the system:
The starting point for the development is the functional design of ChamCom
The completeness of data has to guaranteed
Single input of data for the data system as well as the DIP system
At all time there has to be a backup of the information carrier
Authorisation of functions and workstations
The system has to be implemented with a link with the present IBM AS/400
For the developing of the system the SDM II fasing is applied in combination with the ERD and
DFD (Yourdon) technique for the descriptions. The actual design of the system is done in three
steps. At first the context of the systems is determined (figure 4.6. The system is considered a
black box. All interactions between the system and third parties are shown. In the next step the
main activities of the system are distinguished (figure 4.7). In this step the FLUSH system is
decomposed into 5 main activities:
Actor 1
Actor 3
FLUSH
Actor 2
Actor 4
Actor 5
Figure 4.6: Context of FLUSH (step 1)
1. Activity 1: Inspecting and depositing
In this activity the deposition is inspected, the data entry for the RMP is made and the
deposition is indexed and parted in subdocuments. Agreeing this actions as well as checking
the entry in the Staatscourant is part of this activity.
2. Activity 2: Correcting deposition
This concerns the generation and production of a correction letter, in which the depositor
is asked to correct the deposited report. Recalling this letter and processing the incoming
corrections is also part of this activity.
39
3. Activity 3: Generating V-forms
This activity concerns filling and producing the V-forms and recalling this forms when they
are overdue.
4. Activity 4: Reproducing for subscribers
The reproduction of new deposits for the subscribers as well as the generation of the invoice
data constitutes this activity.
5. Activity 5: Reproducing documents
At a request from the clients or ChamCom employees a reproduction of deposits with or
without correspondence can be made as well as the generation of the invoice data.
All interactions between these main activities are also shown. At this point the input is connected
to the output.
Actor 1
Activity
5
Actor 3
Activity
3
Activity
1
Actor 2
Activity
2
Activity
4
Actor 4
Actor 5
Figure 4.7: Main Activities in FLUSH (step 2)
The last step gives the workflow diagrams of each of the main activities (example in figure 4.8).
The most elementary activities are distinguished in this step. Doing this for all main activities,
41 basic activities can be distinguished which form the FLUSH system. Some of these activities
are functionally very close to each other. Efficiency can be gained in this perspective. Only 21
activities are implemented and calling these activities with the right parameters can trigger a
specific function.
Figure 4.8: Example of a Workflow Diagram in FLUSH (step 3)
4.4.5
Implementation
Architecture
The FLUSH system is a client/server application. It is constructed of client components which
make use of services supplied by the server components. The client and server components are
divided among different hardware platforms. The users have access to the client components of
FLUSH through the PC workstations as well as the AS/400 terminals.
Next to that, FLUSH is a workflow application. The system is built out of relatively independent
components sending each other messages (work) through the workflow. An important server
40
4. Observations
is therefore the workflow activity manager. This manager controls the flow of work between the
different activities.
Hardware
On a hardware level the system is constructed using the following components:
Minicomputer
IBM AS/400 model F/60 with IBM token ring network and cabling system. This AS/400
was already present at ChamCom and supports the regular register activities.
Server
Central server is an AViiON 4605 server, equipped with one processor and 64Mb internal
memory.
Magnetic storage
For storage of the system software and system data a CLARiiON disk array (9,6Gb: 6Gb for
images and 3,6Gb for system and standard software) is integrated.
Optical storage
For the storage of the reports in image format, a LMSI Rapid Changer (disk array with 5
optical WORM discs, total 28Gb) is applied in the system.
PC workstations (8)
Fax server (1)
23 Print server and printer (1)
AViiON
4605
AS/400
Printer
Fax server
Print server
16Mpbs
token ring
Bridge
16Mpbs
token ring
Sequelink
gateway
Scanner
PC Werkstations
Figure 4.9: Infrastructure at ChamCom
Software
On a software level the system is constructed using the following components:
41
Development
For the development of the FLUSH system, the contractor used Plexus 4GL development
environment as well as the Plexus FloWare development environment. At places where
this tools did not offer enough functionality as well as the part of the system that runs on
the server, the programming language C and C++ is used. For the AS/400 part, one uses
RPG/400 and Synon/2.
Use
The operating systems that are used are DG/UX 5.4R2.01, MS-DOS 6.0 combined with
Windows 3.1 and 0S/400 v.2 for respectively the server, the PC’s and the AS/400. The
database underlying the workflow system is Informix. For communication purposes one
uses Sequelink, LAN Workplace for DOS and Rumba for AS/400. The actual workflow
activities are coordinated by Plexus 4GL run-time.
Training
In the training stage 3 steps can be distinguished:
1. The system maintenance department was trained by the contractor
2. The end-users are trained by the contractor
3. The rest of the employees get a demonstration of the system.
4.4.6
System Evaluation
With the FLUSH system, ChamCom has gained possession of a complete and satisfying workflow
system. The realisation is in conformation with the wishes and demands formulated by ChamCom
in advance. The influence of the system on the way of working in the future is something that is
yet to be explored.
4.4.7
Project Evaluation
The CofC can look back on a successful and smooth project. This is due to the thorough preparation and early commitment of the employees. The experiences of this project are reason to see
the future, as far as the introduction of workflow is concerned, with confidence.
When this project is complete and evaluated, a next process will be tackled. This will probably be
the registration of delivery and paying conditions. The approach of other projects will not differ
much from this project. There will be strive for a faster and in-house development. Of course,
the speed will increase, due to the fact that the feasibility study and the selection of a supplier
can be eliminated. Other advantage is that the commitment from the organisation will be gained
even better.
4.4.8
Conclusion
The investigation of the workflow system implemented at ChamCom has led to the following
conclusions. With the FLUSH system, ChamCom is in possession of a combined workflow- and
DIS-system that lives up to the wishes and demands the organisation has formulated in advance.
The improvement in terms of efficiency and flexibility are yet to be explored. The combination
of a thorough preparation, early commitment of the end-users and a smooth project progression
gives confidence in the future introduction of this technology in ChamCom.
It can be said that the processing of annual reports is a highly structured and routine based
process. There are no high demands on flexibility of the system. This made this process the right
choice of a process to be tackled first. Projects to be tackled in the future are likely to demand
more flexibility of the automated workflow. Maybe this can give some surprises.
42
4. Observations
4.5 Workflow Automation at InvCom
4.5.1
Introduction
This section describes the workflow project ICflow, which is implemented at InvCom, an investment company in the western part of the Netherlands. In this chapter the basic structure for all
the project in this research project is used. Paragraph 4.5.2 gives a description of the MI2 project.
The underlying process will be discussed in paragraph 4.5.3 and paragraph 4.5.4 continues with
the analysis of the process and the design of the system. In paragraph 4.5.5 the introduction of
the system is discussed. Paragraph 4.5.6 en 4.5.7 continue with an evaluation of the system and
the project and paragraph 4.5.8 closes with conclusions.
4.5.2
Project Description
InvCom is one of the biggest investment companies in Europe. The core of the company is the
ICgiro account system. Everyone who wants to use the services of InvCom has to have an account
which is registered within ICgiro. This account enables him to make use of all the loaning and
investment possibilities offered by InvCom. One of the departments of InvCom is the Savings
departments, with it’s subdepartment Mortgages. This subdepartment is the topic of this project.
The investigated ICflow system is developed to support the total process of granting a mortgage.
The goal of the ICflow project is to develop a digital image processing (DIP) system, in which
the paper mortgage files which are now present on the Mortgage subdepartment are substituted
by a digital image processing system. A number of problems have stressed the need for the
development of the ICflow system:
File management
Up till the development of the new system, the mortgage files were kept in paper form.
Files that were lost or hard to find were common practice. Also the fact that the files were
not accessible simultaneously by more employees was a problem. When more attention
is given to service to the clients, it also has to be possible that all information is on-line
available, in case a client calls.
Guarding throughput
By implementing recall functions, it should be possible to minimise the passing time of a
mortgage file. The head of the department should be capable of inspecting the status of all
mortgage files.
Dividing work
A digital image processing system facilitates the division of work. The head of the department can assign new mortgage applications to the least busy employee.
Flexibility
A digital image processing system provides flexibility. The procedures, as they are used
at this specific department, are not eternally fixed in the system. The system can adapt to
a changing organisation and environment. Eventually, extra services can be added to the
system.
It is not the policy of InvCom to do the development in-house. The steps in the project are shown
in table 4.5. In the first step, the functional design was made by DocWorld, a consultant agency
specialised in document information systems and document processing systems.
The project was organised using a control group and project group. Both groups were partly
staffed with representatives from InvCom and the contractor. The tasks of the control group
consisted of:
Assessing the mile stone products delivered by the project group
Inspecting the proceedings of the project
43
4.5. Workflow Automation at InvCom
Nr
Step
Moment/Period
1.
2.
3.
4.
5.
6.
7.
8.
9.
Functional design
Selecting Contractor
Approach plan
Global design
Detailed design
Realisation
Implementation
Acceptance
Management and maintenance
October 1992
November 1992 -December 1992
continuously altered
August 1993
September 1993 - March 1994
April 94
April 94 uptil now
Table 4.5: Project Proceedings at InvCom
Deciding where the responsibility of the project group ends
Determining starting points
Assessing the consequences of the taken decisions for the contract
The project group is responsible for the direct execution of the project. The future users are also
involved in the project group. The project group consisted of four
4.5.3
Process Description
The process which takes place on the department Mortgages can best be described using the life
stage diagram of a mortgage, as shown in figure 4.10.
1. Request new mortgage
This is the first stage of every mortgage. The request enters the organisation and an empty
(paper) file is created with the request form as first document. Before a mortgage enters
stage 2, a number of requirements have to be satisfied. Is one of these requirements not
satisfied, then a mortgage is not granted and the mortgage goes (temporary) to stage 7.
2. Running mortgage
If a request is granted, the mortgage goes to stage 2, running mortgage. This is the only
stable stage in the life cycle. A number of changes can be made to the mortgage which may
or may not result in the transition to another stage. The mortgage does not go to another
stage, when the personal data of the client is changed, when the dedicated employee is
changed or when the running time of the mortgage is increased.
3. Extra attention
A mortgage file enters this stage e.g. when interest or pay off payments are overdue or
when the client is going to divorce. It is the choice of the dedicated employee to move the
mortgage file to this stage. It is his responsibility to determine how serious the circumstances
are and to get the mortgage back into stage 2, running mortgage, as soon as possible.
4. Request mortgage changes
The procedure followed here is roughly the same as the procedure followed when requesting
a mortgage. The difference lies in the fact that when the change is rejected, the mortgage
returns to stage 2, running mortgage.
5. Request abolish mortgage
An abolishment is requested when the real estate is being sold, when the client deceases or
when the bank cancels the credit. When the abolishment is complete the mortgage goes to
stage 6, abolished mortgage, or else returns to stage 2, running mortgage.
44
4. Observations
7.
Rejected/
delayed
mortgage
1.
Request
new
mortgage
3.
Extra
attention
2.
Running
mortgage
5.
Request
abolish
mortgage
4.
Request
mortgage
changes
6.
Abolished
mortgage
Figure 4.10: Life stages of a Mortgage at InvCom
6. Abolished mortgage
The mortgage is terminated. All documents within a mortgage file still exist and can be
accessed. The mortgage account number does not longer exist.
7. Rejected/delayed mortgage
A mortgage request can get into this stage as a result of two circumstances. First a request
is rejected according to the rules applied to InvCom. Secondly, not all documents necessary
to honor a request are available. The mortgage remains in this stage as long as the file is not
complete.
4.5.4
Analysis and Design
A number of requirements have formulated which should be met by the design of the system:
The design should be based on the functional design made by consultant agency DocWorld.
The development has to be made on basis of the existing infrastructure.
There has to be an integration with the ICgiro system. The codings from this system are
leading.
All workplaces have to be realised on basis of IBM-PCs using MS-Windows.
The global design has four parts:
1. The mortgage file
Looking from the present paper files, this part describes the construction of the DIP archive.
45
Next to the description of the construction of and access to the files also the life stages in the
life of a mortgage file is described.
2. The workflow
This part describes the workflow between the different employees of the Mortgage department. Especially the processing of the incoming mail and the approval procedures can be
supported by a workflow system.
3. The technical realisation
In this part the technical construction in terms of hard- and software is described. Also the
integration with the existing infrastructure is discussed. In this report, this part is discussed
in 4.5.5.
4. Definitions
This is the most comprehensive part of the global design. It uniquely defines the logical
data model of the file, the stages of a file and the different document types.
ICgiro
Scanning
operator
Cor
Systemsmanager
ICflow
Distributer
Board
executive
Employee
Head of the
department
Figure 4.11: Context of the ICflow System
4.5.5
Implementation
The implementation of the system consisted of eight steps:
1. Proceeding talks
During the proceedings of the project, on a two week basis proceeding talks are held in
which the members of the project team are informed about the status of the project.
46
4. Observations
2. Platform installation
This covers all activities necessary to create the platform on which ICflow will run. This
inhibits the installation and configuration of the AViiON server and the workstations until
the
3. Detail design and realisation
The detail design and the realisation of the different functions is going by a constant designbuilt-test pattern. Every module which is visible for the end-users will have be subjected to
a user test. The participation of the end users should be guaranteed this way.
4. Integration test (15 days)
During the integration test the cooperation of all system components is tested. This test
is done at Data General. Is the system approved there, then a similar test is conducted at
InvCom.
5. Documentation (25 days)
Writing the documentation takes up a lot of time and is therefore distinguished in the
implementation stage.
6. Introduction (11 days)
The installation of the software on the PC’s, the education of the maintainers and the users
and the acceptance test that has to be performed by InvCom constitute this phase.
7. Acceptance (14 days)
The acceptance is divided into three parts. First an acceptance of the functionality is done by
the head of the department. Next, a final acceptance is done by the head of the department
and a final acceptance by the end users.
8. After-care (14 days)
Data General shall be present up till two weeks after delivery of the system to correct
eventual malfunctioning and to assist the employees in the use of the system.
Architecture
The ICflow system is a client/server application. It is constructed of client components which
make use of services supplied by the server components. The client and server components are
divided among different hardware platforms.
Next to that, ICflow is a workflow application. The system is built out of relatively independent
components sending each other messages (work) through the workflow. An important server
is therefore the workflow activity manager. This manager controls the flow of work between the
different activities.
Database service
This is the core of ICflow and consists of the database where all mortgage files are stored.
Workflow service
FloWare offers a central activity manager which takes care of the appropriate processing of
the workflow.
Print service
The print service offers the users the possibility to share a printer. This service is especially
aimed at printing images fast.
47
Hardware
On a hardware level the system is constructed using the following components:
AViiON 4605 server with magnetic disc units for the index data and temporary storage of
documents and optical discs for permanent storage of documents
PC workstations (486SX/20)
Scanning station
Software
On a software level the system is constructed using the following components:
4.5.6
Development
For the development of the ICflow system, the contractor used Plexus 4GL development
environment as well as the Plexus FloWare development environment. At places where this
tools did not offer enough functionality as well as the part of the system that runs on the
server, the programming language C and C++ is used.
Use
The operating systems that are used are DG/UX 5.4R2.01 and MS-DOS 6.0 combined with
Windows 3.1 for respectively the server and the PC’s. The database underlying the workflow
system is Informix. For communication purposes one uses Sequelink, LAN Workplace for
DOS. The actual workflow activities are coordinated by Plexus 4GL run-time.
System Evaluation
A careful judgment can be made, when looking at the little experience of the users up till now.
In the accepting phase, the initiative of the employee was of great importance. Employees with
big enthusiasm have grasped the opportunity to get to know the system, others have approached
the system with some reservations. The experiences resulting from this accepting phase are
therefore quite divers. Fact is that the system is working according to the requirements and that
the employees have not encountered any problems that not come from another way of working
and will therefore disappear after a while.
The documentation of the design of the system has suffered from the lack of time. This can cause
problems in the future. The user manual, as it was initially made, did not suffice. It was written
by the designer en therefore did not took the ’unknowing’ employee as a starting point. This user
manual has to be written all over again.
4.5.7
Project Evaluation
Due to the problems with the ICgiro system, the ICflow system was delayed. The ICflow project
was also not without problems. The initial planning was not met, the requirements are changed
during the project and problems arose in the communication between the control group and the
project group. These problems have overcome and one can look back on a successful project.
With respect to future projects, it is recommended to involve the end-users more into the project.
Especially with respect to the implications of the system for their work. Also the end users should
be more involved with the design of their user interface. Workflow systems in particular, have
great impact on the way of working, even when the existing procedures are implemented in the
workflow system without changes. A lot of insecurity will disappear and the system will be
accepted with more enthusiasm.
48
4.5.8
4. Observations
Conclusion
ICflow provides InvCom with a good workflow system for the support and streamlining of their
activities. The fact that the procedures at this department are practically unchanged taken as base
for the system, will result in a relatively smooth accepting by the employees. This acceptance
could have been smoothened by letting the employees get more involved in the developing of
the system. The extend in which the advantages of this new system will show, is something that
is hidden in the future. Fact is that the system has a great impact on employment on the side of
the administration. Concluding: this project shows that a workflow system for the support of the
primary production can be very feasible.
49
Chapter 5
Comparison and Generalisation
Summary
This chapter contains an analysis of the observations made at the four organisations. The
observations are compared and analysed as to reveal both differences and similarities. The
structure of this chapter is the same as the structure of the abstracts in chapter 4. A separate
section is devoted to the following items: project, process, analysis and design, implementation
and evaluation.
5.1 Introduction
The purpose of this chapter is to compare the four workflow projects described in the previous
chapter. This chapter has the same structure as the abstracts and the full reports of the projects.
Every chapter will compare the four described cases and the way in which they are similar or
different. The observed results of the InfTech-case will mainly be used to put the other three cases
in perspective.
The structure of this chapter is as follows. In section 5.2 the project at the four organisations
is compared. Section 5.3 continues with a comparison of the three processes with their characteristics. In section 5.4 the analysis of the process and the design of the system at the four
organisations is put in perspective and section 5.5 described the implementation of the system.
The system and project are evaluated in respectively section 5.6 and section 5.7. The chapter is
concluded with section 5.8 where conclusions are drawn and generalisations are made.
5.2 Projects
This section deals with the different causes, project organisations, and proceedings of the observed
workflow projects
5.2.1
Causes
Introduction
The causes leading to the development of a workflow system at the four organisations are shown
in table 5.1. In this table, all the causes, as encountered during the WA-12 research are given.
For a more detailed description of these causes is referred to the next chapter. In this table, a
distinction is made between the notions of primary and secondary causes. A primary cause
refers to a problem that had to be solved as not to jeopardise the company’s primary activities. A
secondary cause refers to problems in the organisation that are not urgent or wishes that can be
fulfilled along the way when a new system is being build. The bullets () represent the primary
50
cause(s) and the circles () the secondary cause(s). These results will be discussed below in greater
detail.
Cause
Throughput
Client focus
Flexibility
Archiving
Control over process
Quality of data
Integration
Management information
Malfunctioning system
InfTech
MedIns
ChamCom
InvCom
Table 5.1: Causes for Developing a WF-system at the Four Organisations
The Causes at the Four Organisations
InfTech
As a supplier of information systems, InfTech is anticipating to problems of its customers.
The customers are health care insurance companies in the transformation process from semigovernment to commercial. This can be seen as a transformation from non-profit to profit.
Data and functions are relatively stable, but the products and with that the procedures
demand constant conformation with the wishes of the customers. The external goals stay
the same, but there is need for a more focus on the client. This stresses the need for more
emphasis on the internal goals; efficiency, effectivity and flexibility. A more efficient file
management and a higher throughput is in need. Due to the fact that the existence of the
clients of InfTech is on the line all causes mentioned before are primary causes.
MedIns
Problems with archiving were also present at MedIns. Not only are files not available before
micro-filming, but when microfilmed they are often hard to find or even impossible to find. If
these problems occured sometimes a new file was created, so no file in the archive concerning
a particular client was complete anymore. This stresses the need for more attention on the
quality of data. The fact that files are not accessible at the same time by different employees
was also an obstruction for high throughput. The primary cause therefore is the archiving
problem. Problems that obstruct a high throughput, cause bad quality of data or obstruct an
increased client focus are a result of this problem, and are therefore regarded as secondary
causes. All these causes were recognised at the beginning of the project and therefor is the
MI2 system not initiated to just solve the archiving problem. MedIns was looking for a total
file management system for total process and quality management.
ChamCom
At ChamCom a number of problems were motivations to develop a workflow system.
Like at MedIns, the main problem was the archiving problem. Initially the annual reports
were stored in (original) paper form. This situation became intolerable, so the technique
of micro-filming was introduced. The size of the archive was no longer a problem, but
the accessibility and availability of the archive. Reports were not accessible before microfilming and films were not always returned by the public after use. Like at MedIns, this also
had it’s impact on the throughput in the organisation and the service towards the clients.
Archiving is again the main problem and all other problems are linked to this problem.
InvCom
InvCom’s archiving problem was also the main cause for the development of a workflow
51
5.2. Projects
system. The organisation also saw the accompanying advantages of a higher and more
constant throughput, an easier and more efficient division of work and the improvement in
terms of flexibility. Next to that, InvCom has always been trying to adapt the most recent
information technology. Switching to imaging and workflow is a natural activity in this
context.
Conclusion
Remarkable fact is that in all four organisations investigated in this report, the archiving problem
was the main cause or one of the main causes for developing a workflow system. This shows
that the fact that all researched systems have image facilities and are therefore a combination of a
workflow system and a document information system is not coincidently. Often, a solution was
needed for the archiving problem. This is found in the form of imaging. Via this entrance of DIS,
workflow came in sight. The synergy derived from the combination of a DIS and a workflow
system is recognised.
Digital storage of documents and files provides the solution necessary for solving the main
problems of these four organisations. All other problems are in some way or another linked to
this problem.
This conclusion is however not valid for all investigated projects in the WA-12 research. In other
organisations, other (primary) causes were mentioned to be a cause for initiating the development
of a workflow system.
5.2.2
Project Organisation
Introduction
With regard to the duration of the project, a distinction is made between the organisation of the
project before the actual development of the system and the organisation of the project during
the development and introduction.
This distinction is made because of the following reason. In the part of the project before the
development of the system there were often no third parties involved. The project is carried by
the initiators. Sometimes one uses the services of a (workflow) consultant agency to assist in the
decision making.
During the development a larger part of the organisation is involved. Also, the contractor - when
used - plays a big role in the project organisation. The organisation of the project in these two
phases at the four organisations is shown in table 5.2 and described below in greater detail.
Project organisation
before development
Project organisation
during development
InfTech
-
MedIns
head of the
IT-department
representation of the
whole organisation
management
development at InfTech with
continuous interaction with client
representation of the whole organisation
depending on the part of the system
steering group/project group
both half organisation/half contractor
steering group/project group
both half organisation/half contractor
Organisation
ChamCom
InvCom
Table 5.2: Project Organisation at the Four Organisations
52
Project Organisation at the Four Organisations
InfTech
At InfTech, one can not really speak of a formal project organisation where contractor
and client work together to create the product only suitable for the given situation. The
development of the system has a very general character, so it can be adapted to various organisational situations within the (health care) insurance business. The client does not play
a role in providing contextual information, but more in providing the structural information. Contextual information refers to the size, environment and culture of the organisation,
whereas the structural information refers to the level of formalisation and complexity. This
distinction between contextual and structural dimensions of an organisation will return in
the next chapter.
MedIns
When hired by the organisation, the head of the IT-department of MedIns started developing
the plans for a system like this. He was alone until the moment when the negotiations with
the contractor took place. In the period of developing the pilot and the system, they worked
in a team staffed with an employee with a split job (working half at the IT-department
and half as a client advisor), some users (depending on the part of the system that was
developed), a programmer from WANG and the head of the IT-department himself.
ChamCom
At ChamCom a clear distinction is made between the organisation of the project before the
choice of the contractor and the organisation of the project after the choice of the contractor.
In this situation, the moment where the contractor is chosen is similar to the point where
the development starts. In the first stadium, the organisation consisted of a mixed team of
members of all involved departments complemented with an external consultant. In the
second stadium, a steering group/project group structure was used. The steering group was
mainly staffed with representatives of the management of both ChamCom and the supplier
complemented with the same consultant. The project group consisted of representatives of
all involved departments of ChamCom and the project leader and analyst of the supplier.
InvCom
InvCom has a very similar construction as ChamCom. The decision to pursue the workflow
solution was made by the management, confronted with the archiving problems and having
experience with digital storage of files. Before the development of the system the management contracted workflow consultant agency DocWorld to make the functional design of
the system. They also selected the supplier. After this selections the project organisation
was also handed to the contractor who uses the steering group/project group construction.
Conclusion
The four described cases show that there are very divers structures possible to organise a (workflow) project. At MedIns a very close cooperation between contractor and client took place. This
was due to the fact that both parties were not sure, what the result would be. Both ChamCom
and InvCom knew exactly what they wanted, and the steering group/project group construction
seems more appropriate for this kind of situation. The responsibilities are clear and there is
nothing to prevent the project from going smooth.
Although the project management at the three ’user’-organisations are very divers, there are some
similarities. Three main parties are identical:
System development
Management participation
User participation
53
5.2. Projects
The parties listed above are applied to the organisations in table 5.3. The existence of the three
body types is not surprising. With large information development projects the involvement of
users, managers is next to the obvious involvement of the IT-department essential for a successful
project.
IT
Management
Users
MedIns
Development team
ChamCom
Project group
Organisation,
Management
Development team
Steering group
Project group
InvCom
Project group,
Steering group
Project group,
Steering group
Project group,
Steering group
Table 5.3: Functional Involvements at the Projects
It is positive to notice that user participation is a common thing nowadays. Eventually, the users
who have to work with the system. A system development without the active participation of the
users will result in a system not conforming to their wishes. The users will reject the system and
the project has failed. User participation can have simple forms. A representative in the project
group can suffice.
Support from the management is also necessary. Without their support to the development and
in the adaption of the organisation, the project will fail. This involvement can vary from active
system development to passive monitoring.
5.2.3
Proceedings of the Projects
Introduction
All described projects are system development projects. All systems are developed using the
traditional development according to the waterfall-model, which identifies analysis, design and
implementation as separate phases in the development process. This is also the case in the three
described ’user’-cases.
The steps that can be distinguished in these three cases are summarised in table 5.4. In this
section, the InfTech project is not considered, due to its structural different character. The steps
in the different projects are described below.
Description of the Steps
1. Feasibility study
The only organisation which conducted a feasibility study was ChamCom. They hired
workflow consultant agency DocWorld to conduct this feasibility study. This study was
made, not only to asses the possible (financial) results for this specific process, but also to get
insight in the consequences of the introduction of this technology in the whole organisation.
Typical cost factors are:
Hardware (server, network, workstations, network infrastructure)
Software (operating system, development tools, etc.)
Development (manpower, project organisation)
Operational costs (depreciation, interest and maintenance)
Typical benefits were:
Savings in employee (salaries)
54
Nr.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Step
Analysis
Feasibility study
Selection contractor
Site-visits
Negotiations with contractor
Pilot system
Design
Functional design
Development
Implementation
Implementation
Operational system
Backlog
MedIns
ChamCom
InvCom
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
Table 5.4: Steps in the Projects of the Four Organisations
Savings in the use of microfilm equipment
Savings in space
Other savings of a more speculative nature (quality, effectivity, completeness)
The study concluded with the result that a workflow system is indeed feasible, but only
when a total system is developed. The benefits would be in the amount of half a million
guilders a year.
At MedIns the system ’only’ concerned the coordinating process of mail distribution. The
results that can be achieved with digital document transportation were so obvious that a
feasibility study did not cross anyones mind.
At InvCom, a feasibility study was considered, but due to the fact that the Mortgage department is a fast growing department the results will not be comparable in time. Prospects
would not be reliable and if it would be possible to handle a lot more mortgage cases with
the same number of employees, the results are obvious.
2. Selection contractor
The selection of the contractor was the most intense at ChamCom. This selection was guided
and supported by workflow consultant agency DocWorld. In ten steps a list of seventeen
possible contractors was shortened to a list of three contractors of which ChamCom was
sure that they all were possible to built the system. The list of ten was narrowed down to
six before the site-visits were made. However lengthy and thorough, ChamCom could not
anticipate the failure with the selected contractor. ChamCom continued with the next on
the list, who succeeded.
MedIns did not make a selection out of the possible contractors active in this market. They
were satisfied with the services of their present supplier that the choice was obvious.
InvCom did do a selection process. This was not as thorough as at ChamCom. There were
only four potential contractors, which was narrowed down to two before the site visits were
made. Remarkable fact is that both at ChamCom and InvCom, the ’regular’ supplier took
very little effort in getting the contract. Often they thought, they naturally would get the
contract.
3. Site-visits
All three organisations who have worked with a contractor have made some site-visits. This
was often quite hard, due to the fact that comparable systems are hard to find.
5.2. Projects
55
MedIns has been able to visit some sites, but could not find a system that came close to the
system they wanted. When the MI2 system was fully operational, this system is used by
their contractor as site for workflow systems.
As a part of the thorough selection process of ChamCom, two trips were made to visit the
head offices of the remaining contractors and some sites. The first trip went to the the
United States and they visited, next to the head offices of the contractors, three sites with
comparable systems as wanted by ChamCom. The systems were not all operational and
none of them contained workflow. The second trip went to the United Kingdom. Here only
sites were visited, but they also didn’t have workflow. InvCom visited also two sites, due
to the fact that only two contractors were left at that moment. Here also, no comparable
systems were found.
One of the possible contractors was present in both the list of ChamCom as in the list of
InvCom. Both organisations were astonished that this contractor offered them the same
second hand (not-suitable) system for an amazingly high price.
4. Negotiations with contractor
Remarkable fact, but not strange for a new technology like workflow, was that the systems
were almost without exception developed under very good conditions with the contractor.
The system at MedIns was developed free of charge, under the condition that it could be
used as a site for potential clients. Upgrading and changes to this system, would of course
not be free.
The system at ChamCom was not developed free, but due to the fact that there are about
34 more ChamCom’s in the Netherlands, the negotiated a deal, where ChamCom gets a
refund for every system sold to another ChamCom. Looking at the number of ChamCom’s
in the Netherlands, this ChamCom will probably not regret being a pioneer for this new
technology.
5. Pilot system
There was only one organisation that conducted a pilot project. This was MedIns as table
5.4 shows. Due to the new nature of this technology, MedIns wanted to see if it was feasible
and if it really improved the situations.
6. Functional design
Making a functional design is the second phase of the System Development Method. In this
phase an user-oriented design of the total system is made. All functions which the system
should offer are determined and described in great detail. Also, process descriptions should
be made, with emphasis on the actions that have to be taken by humans in the system [Uij81].
This functional design as a very common step in (Dutch) system development. A functional
design was made at ChamCom by the IT-department itself. All functionalities that the
system should offer are described in great detail. Also the functional analysis contained
DFD’s to illustrate the process. InvCom hired workflow consultant agency DocWorld to
make a functional analysis. Both organisations have made the functional analysis one of
the requirements for the system and a starting point for the contractor.
7. Development
The development at MedIns had a very evolutionary character. A programmer from WANG
was stationed at MedIns to construct the system, in cooperation with the head of the ITdepartment and the rest of the organisation, depending on the part of the system that was
designed at that moment.
Both at ChamCom and InvCom the development took place at system integrator Data
General. Every two weeks there were proceeding talks as to inform the organisation about
the way things were going. At ChamCom the planning was better met than at InvCom.
This was probably due to the fact that ChamCom had made very strict arrangements as
a consequence of bad experience with the first contractor, who failed. Also, at InvCom
56
the requirements of the system changed during development. At both organisations, the
development went (relatively) smooth.
8. Implementation
The implementation phase can not clearly be distinguished at MedIns. The system development and system implementation went along side.
At the other organisations, ChamCom and InvCom, an implementation phase has been put
in the planning. The implementation did not take place until the system was completely
ready. The system was built completely at the contractors place. Only the tuning part of
the system is done on-site.
9. Operational system
All three organisations have succeeded in developing a system, meeting the demands
previously defined. This proves that it is possible to built a successful workflow system
with the technology and know-how, currently present in the IT-market.
10. Backlog
Most of the organisations considered the conversion of old paper or microfilmed files. Only
InvCom has decided to actually do the conversion of old files, due to the fact that all stored
files have to be retrieved once in a while. When part of the archive remains on micro-film,
the full potential of the system will not be used. Next to that, the Mortgage department is
fast growing, and conversion will be more expensive, the longer it is posponed.
ChamCom did not go through with a conversion of the old files. The reason for this is
simple. ChamCom stores annual reports, which are renewed every year. The demand
for old annual reports is very low and a cost/benefit analysis would give a very negative
outcome.
At MedIns, conversion resulted in technical problems. The quality of the microfilmed files
was very divers. For each file, the scanner would have to be tuned again. This resulted in
the fact that a conversion would be a very lengthy and so very costly process.
Conclusion
First and maybe obvious conclusion is that it is possible to realise a workflow system with
the know-how and hard- and software currently available. All three ’user’ organisations have
managed to get the workflow system, conforming to their needs and wishes. The steps taken
at the three organisations do not differ much. At ChamCom the analysis phase was much more
extensive then at the other organisations. ChamCom has proven that a detailed feasibility study
concerning a workflow system is possible, in contrast to the other organisations who thought that
it would not provide a reliable result. Only MedIns has developed a pilot before developing a
full system. This shows that building a pilot is not an essential condition for a successful system.
5.3 Processes
In this section the processes of the four organisations are discussed. These processes are all of
an entire different nature, but an attempt is made to compare these processes to the best extend
possible. Some of the characteristics of the processes are shown in table 5.5.
5.3.1
Goal
Goals at the Four Organisations
InfTech
The process which forms the basis for the system at InfTech is the subscription and mutation
of client data of a health care insurance company.
57
5.3. Processes
Process item
MedIns
ChamCom
InvCom
Goal
processing incoming
mail
-
inspection and registration
of annual reports
bound by governmental
rules
administration employee
financial administration
clients
granting mortgages
Preconditions
Functions
administration
client advisor
procurator
administration
mortgage employee
head of the department
Table 5.5: Characteristics of the Three Processes
MedIns
MedIns has applied the system to process all mail concerning the primary process; insurances in the medical society.
ChamCom
At ChamCom the process concerns the inspection and registration of annual reports supplied by the registered companies.
InvCom
InvCom has submitted the process of granting mortgages to the public.
Discussion
At first sight, these are indeed very different processes, but there are obvious similarities. All
processes are triggered by a document. This document can concern the mutation of personal
data (InfTech), a question concerning or request for an insurance (MedIns), a new annual report
(ChamCom) or an application for a mortgage (InvCom). These documents are then routed to one
or more employees and the process results in the processing of this document and the storage
in the system. Between the moment that the document is presented to the organisation and the
moment that it is stored in the system, a lot of actions can take place, resulting in incoming and
outgoing mail.
5.3.2
Preconditions
InfTech
An important condition at InfTech is the fact that the organisation of full-case handling is
applied. This has to be consolidated even after automating the process. The automation of
the process will already be an enormous change for the employees. Breaking the process
apart and automating it at the same time will result in problems with the acceptance of the
system at time of implementation.
MedIns
MedIns puts no special preconditions to the process. The process as it is currently been
executed is the starting point for the development of the system. Of course, the preconditions
for the process are reliability and timely availability of the relevant information.
ChamCom
At ChamCom there are only preconditions concerning the process itself. ChamCom is
bound by governmental rules to execute the process in a particular fashion. Therefor,
ChamCom has to assure that all registered organisations supply a report once a year, and
that the financial categorisation of the organisations is checked at all times. The process at
ChamCom has not been changed, but rather extended. New services, long wanted, but not
possible due to the already enormous working pressure of the process are now possible.
58
ChamCom offers individuals and companies the option to take a subscription to all reports
supplied by the companies. When submitted and inspected, the reports will automatically
be send to the subscribers.
InvCom
At InvCom the process is not changed but taken as starting point for the system. The process
of granting a mortgage is very well defined. The process can be very much described in
terms of life status. The description of this process will return in the next paragraph.
5.3.3
Functions
The functions encountered at the organisations are quite different. Similar is that in all workflow
systems the organisational functions are modeled in terms of roles. The term role is used here
as it is defined in chapter 3. The roles involved in the observed processes are listed in table
5.5. All organisations have a number of employees who fulfill the administrative functions as
scanning and indexing. Also the organisations have a number of employees responsible for the
real processing of the document. Further, the functions that are involved in the processes have
no clear similarities.
1.
Request
new
mortgage
7.
Rejected/
delayed
mortgage
Steps supported
by a structured
workflow
2.
Running
mortgage
4.
Request
mortgage
changes
3.
Extra
attention
5.
Request
abolish
mortgage
Steps supported
by a structured
workflow
6.
Abolished
mortgage
Figure 5.1: The Life Cycle of a Mortgage at InvCom
5.3.4
Process Flow
Introduction
The flow of the process was not well documented in the organisations before the development of
the workflow system. The flow, as it is taken as a starting point for the system is considered here.
Process Flow at the Four Organisations
MedIns
The process flow at MedIns is relatively simple as far as the process of distributing mail
is concerned. This process schema technique is shown in figure 5.2. In this technique,
the columns denote the roles in the process, the rows denote the different steps and the
59
5.4. Analysis and Design
rectangles denote the activities. Every activity belongs to a certain step and a certain role.
An activity is triggered by an other activity.
At MedIns, this is the only schema technique used to describe the process. The schema
describes the routing and triggers of the process.This already reveals much about the nature
of the system. A lot of routing is required, but task support will be of minor importance.
ChamCom
The process at ChamCom is concerned with the registration of annual reports. Depending
on the correctness of the reports, they can make a long or a short way from admission to
permanent storage. The process is defined in terms of activities and routing is implicit.
There can be a lot or routing, but this is not necessary. The process is described using DFD’s
InvCom
The process at InvCom is described in terms of life stages of a mortgage. The parts of the
process which have to be executed according to the procedure are given in DFDs. As shown
in figure 5.1 only the transitions from stage 1 to stage 2 and the transition from stage 5
to stage 6 are strictly defined. All other transitions are a choice of the user (of the system)
and when a mortgage gets into such a stage it is intended to go to another stage as soon as
possible. In fact only the stages 2 and 6 are stable. The stages 1 and 5 are only a starting
point for a procedure. This structure will be reflected in the system.
Role 1
Step 1
Role 2
Step 2
Activity 2
Step 3
Activity 3
Step 4
Step 5
Role 3
.....etc....
Activity 1
Activty 4
Activity 5
Step m
Activity n
Figure 5.2: MedIns Process Schema Technique
5.3.5
Control
The control over the process was minimal at all organisations. Management could gain insight
in the throughput and bottle-necks of the process by consulting the archive and the employees
themselves. There is much room for improvement there.
5.4 Analysis and Design
In this section the analysis and design process of the four organisations are compared.
60
Requirements
MedIns
ChamCom
InvCom
Functional
requirements
1. On-line retrieval
of files
1. Design on basis of
ChamCom’s functional design
1. Design on basis of
the functional design
2. Simultaneous access
to files
2. Single data-entry for
existing and DIP system
3. Availability of
status information
a. Realisation with
existing hardware
with only necessary
additions
3. Authorisation for
functions and workstations
a. Connection with AS/400
Technical
requirements
a. Realisation on
existing infrastructure
b. Backup of information carrier
b. Integration with ICgiro
c. Clients on basis of
IBM-PC’s/MS-Windows
Table 5.6: Requirements for the Analysis and Design Step
5.4.1
Purpose
Generally stated, the purpose of the analysis and design step in the projects is to analyse the
processes as described above in terms of workflows and to design a system accordingly. Nevertheless, the way in which this is done is very divers. This is not in the last place the result of the
different characteristics of the processes.
5.4.2
Requirements
Introduction
The requirements as formulated by the organisations preceding the development are of a divers
nature. This was mainly with respect to the archiving problems they had before. These requirements would have to guarantee that this primary problem was solved.
Requirements at the Four Organisations
MedIns
MedIns stated requirements with respect to the functionality of the system. They were
mainly focussed at solving the archiving problem. The files had to be retrieved on-line,
simultaneously. Also there has to be status information concerning the process. With
respect to the technical infrastructure, there were no explicit requirements. It was intended
that the system would operate on the existing infrastructure, with an additional scanner
and optical disc array.
ChamCom
ChamCom came up with a number of functional and contextual requirements. First and
important requirement was the demand that the system was build on basis of the functional
design as made by ChamCom. This requirement specifies the functionality of the system
in great detail. Other demands were made with respect to the security and completeness
of the data stored by the system and the relations with the existing hardware platform at
ChamCom.
InvCom
The situation at InvCom was very much like the situation at ChamCom. The functional
61
Approach
Phases
InfTech
MedIns
ChamCom
InvCom
Bottom-up
Event/Action modelling
Authorisation modelling
Data modelling
Bottom-up
Intuition based
process modelling
Top-down
Process decomposition
Context analysis
Functional modelling
Data Flow diagramming
Top-down
Goal formulation
Context analysis
Functional modelling
Process modelling
Table 5.7: Analysis Activities
design as produced by consultant agency DocWorld was an important requirement as to
unambiguously specify the functionality of the system. The other requirements were of a
technical nature. The system had to be built on the existing infrastructure at InvCom. The
system had to integrate with the ICgiro system and the realisation had to be made on basis
of IBM-PC’s using MS-Windows.
Discussion
The fact that the requirement are mainly aimed at solving the primary problems within the
organisation seem obvious. This is not always the case. There are a number of examples where
state of the art systems are proposed and eventually built by a contractor, where the primary
problem remains unsolved. The fact that this is not the case at these projects shows the fact that
the IT-industry has grown up.
Furthermore, ChamCom and InvCom have made a detailed functional design as to specify the
functionality of the system in great detail. This functional design was made by the organisation
itself or by an independent agency. When the functional design would be made by the contractor,
there is always the danger of a conflict of interests between the two parties.
5.4.3
Methods, Techniques and Tools
Methods
In order to compare the phases of the methods used, they are represented as Hierarchical Process
Decompositions [EN86]. Temporal ordering of the processes in each layer is not expressed in this
model. When insight in the temporal order is desired, the processes of each layer can be included
in a Detailed Process Schema [EN86]. A representation of the phases of a method is called Method
Process Modeling [Bri90].
The phases of the overall development path are listed in table 5.7.
In this paragraph the method is described, which is used to develop the system at the four
organisations. Not always is this method well defined or formally described. Often one acts on
basis of intuition.
Methods at the Four Organisations
InfTech
The method used at InfTech is quite clear, although not formally defined. InfTech emphasises
the need for an evolutionary way of developing. This is reflected in the applied method.
The level 0 hierarchical process decomposition diagram of the method is shown in figure
5.3. This method will be used at every client of InfTech. InfTech’s goal is to built a library
of system modules. On basis of the requirements planning, and the existing experience
reflected in the modules, a system can be composed quickly.
The development step requires studying in greater detail. It is specially designed for the
construction of workflow systems. Due to time constraints, the systems is (unfortunately)
62
Information
system
development
Requirements
planning
Functional
analysis
Development
Implementation
Production
Figure 5.3: Method Process Model of the InfTech Method (Level 0)
Functional
analysis
Event/Action
modeling
Authorisation
modeling
Data
modelling
Development
Event/Action
construction
Sequence/
Authorisation
Adding
data
Database
structure
Procedures
on action
level
Design
electronic
forms
Integration
with DB
Scripts
generation
Management
info module
Figure 5.4: Method Process Model of the InfTech Method (Level 1)
not documented. It consists of nine steps in which a bottom-up approach is used. In the first
step the activities are inventoried and implemented. At this moment the separate activities
can be demonstrated. In the second stage the correct sequence is added to the unstructured
set of activities. This process goes on. At all times, the system can be demonstrated as to
ensure interaction with and feedback from the client. This ’evolutionary’ development of
the system is demonstrated in figure 5.5
Activity 1
Activity 1
Role 1
?
Activity 1
Activity 3
?
Activity 2
Activity 2
?
Role 3
Activity 4
?
Activity 3
Activity 4
Activity 3
Activity 4
?
Activity 2
Role 2
?
Activiy 5
Activiy 5
Activiy 5
?
Role 4
Activity 6
Activity 6
Figure 5.5: Stepwise Workflow Construction in the InfTech Method
MedIns
MedIns did not use a formal method. The SDM method was kept in the back of their minds,
but it was not used. Nevertheless, the Method Process Model is given in figure 5.6. System
development is carried out by a programmer from WANG and the internal IT staff.
ChamCom
The level 0 Method Process Model of ChamCom is shown in figure 5.7. The development
is done by Data General, who uses the SDM II phasing [Vre91]. This phasing consists of the
following steps:
1. Information Planning
63
Information
system
development
Requirements
planning
Proposal
Functional
analysis
Development
Implementation
Pilot
system
Testing
Full
system
Production
Figure 5.6: Method Process Model of the MedIns Method
Information
system
development
Requirements
planning
Feasibility
study
Proposal
Functional
analysis
Supplier
choice
Development
Implementation
Figure 5.7: Method Process Model of the ChamCom Method (Level 0)
Feasibility
study
Goal
formulation
Description
current
situation
Solutions
inventory
Cost/Benefit
analysis
Advice
formulation
Functional
analysis
Process
decomposition
Context
analysis
Functional
modelling
Data Flow
Diagramming
Figure 5.8: Method Process Model of the ChamCom Method (Level 1)
Production
64
2. Definition Study
3. Global Design
4. Detailed Design
5. Realisation
6. Implementation
7. Use and Maintenance
The way in which these steps are executed in the total design is shown in table 5.8. Mostly,
the organisation self executes some of the initial steps. An important step in this project
phasing is the third step, the global design. The contractor uses a three step method.
1. In the first step, the context of the system is defined. All interactions of the system
with the environment are inventoried.
2. In the second step, the main activities in the system are distinguished. These main
activities connect the inputs and outputs with the external environment.
3. In the third and last step the workflows within these main activities are described. This
method us obviously a top-down approach.
Initially the system is considered a black-box. From there the design gets more detailed every
step. The design of the system is done using Yourdon DFDs and ERDs.
InvCom
Information
system
development
Requirements
planning
Proposal
Functional
analysis
Supplier
choice
Development
Implementation
Production
Figure 5.9: Method Process Model of the InvCom Method (Level 0)
The InvCom method is very much alike the ChamCom method. This is due to the fact that
the same consultancy agency (DocWorld) and the same system developer (Data General).
The Method Process Models level 0 and 1 are given in figure 5.9 and 5.10.
Functional
analysis
Goal
formulation
Context
analysis
Functional
modelling
Process
modelling
Figure 5.10: Method Process Model of the InvCom Method (Level 1)
Discussion
The Method Process Models clearly and comparable depict the methods used at the four organisations. A comparison of the models learns that all methods are rather traditional. Often the
SDM framework is kept in the back of mind and the according waterfall model of analysis, design
and implementation is applied.
In [Bri90] three types of techniques are distinguished: formal, structured and informal techniques.
The observed techniques for workflow modelling can be catagorised as structured.
In order to compare the concepts that are modelled with techniques, they are represented as
Entity-Relationship Diagrams [EN89]. A formal representation of the static aspects of a method
65
Nr.
1.
2.
3.
4.
5.
6.
7.
SDM phase
Information Planning
Definition Study
Global Design
Detailed Design
Realisation
Implementation
Use and Maintenance
ChamCom & InvCom
Requirements planning
Proposals
Functional analysis
Development
Development
Implementation
Production
Table 5.8: The SDM phases at ChamCom and InvCom
is called a Method Data Model. Method Data Models are formal descriptions of concepts used
in the techniques of a method. Figure 5.11 show the Method Data Models of the techniques
encountered at the four organisations. The elements of this Method Data Model will be described
below.
1
trigger
N
N
1
N
activity
role
N
actor
N
1
N
1
decision
Figure 5.11: Method Data Model at the Four organisations
Triggers
As identified in the theory, activities can trigger other activities and external triggers trigger
a workflow. This trigger relationship is always present, although not always identified by
the organisation them self.
Activity
An activity is a set of events that occur under the responsibility of one actor in a specific
role. More than one activity can be connected to a certain role, but an activity can not be
connected to more than one role.
Actor
An actor is no more than one that acts. It is an instantiation of a role.
Role
An actor can have one or more roles. As said before, an actor is an instantiation of a role.
Decision
At all the organisations decisions are distinguished. In this Method Data Model, the decision
is considered a separate activity.
Tools
The tools used at the four organisations are divers. At InfTech, a tools selection was conducted
by workflow consultant agency Pallas Athena. Making a distinction in a number of workflow
environments and routing and task oriented workflow tools, they concluded that FlowPATH
from Bull was the most suitable tool for all environments.
66
At the moment when MedIns was developing their system, supplier WANG did not have any
tools available for a workflow system. They did have a PACE database and a matching PACE
4GL environment to built a tool themselves.
Both InvCom and ChamCom have built their system using FloWare. Both organisations have
visited a number of exhibitions of workflow and DIS tools before selecting a tool. FloWare is a
total package with a 4GL application builder and image facilities. FloWare is also preferred by
their contractor, Data General.
None of these organisations has used a design tool as SDW.
5.4.4
Design
There is a big difference in the design of the three systems. This difference can be illustrated by
the categorisation as made by InfTech. InfTech distinguishes routing oriented and task oriented
workflow systems.
MedIns
The system at MedIns is mainly defined in terms of destinations. The actions taken at that
specific destination are not specified in great detail. Routing is therefore a very important
factor at MedIns. This system is an example of a routing oriented system. For the design, it is
divided into four different subsystems. Two of these subsystem, the processing of incoming
and the processing of outgoing mail are workflow systems. The other two subsystems,
batch processing and the retrieval of files are ’normal’ system functions.
ChamCom
The design of the FLUSH system at ChamCom is a natural result of the top-down decomposition development. The total system is first decomposed into five main activities. These
activities are implemented as a workflow. These five workflows are the decomposed into
41 separate activities which are categorised into 21 activity types. These activity types are
programmed and put into an activity library. The five workflows can access this library to
execute the needed activities according to the contextual demands. The ChamCom system
is defined in terms of activities and procedures and is therefor more task oriented.
InvCom
The system at InvCom is defined in terms of action belonging to a certain procedure. This
causes task support to play a big role in the system. This system is therefor also task
oriented. Routing plays a small part, due to the fact that InvCom implements full case
handling, so the total case is processed by one assigned employee. The system is built
around the different states in which a mortgage can reside.
In general, the systems do not differ much from ’traditional’ information systems. In the cases
where a tool is used, it has great consequences for the design of the system. This was also noticed
by InfTech. At all these organisations, the tool in which it would eventually be built was known
before the design phase.
All systems show a distinction in the workflow functionality on one side and the different applications related to the workflow on the other side. The workflow or core application refers to
central data storage, communication, routing and administrating management information. The
biggest part of this core application is implemented at the server side of the system. The other,
task supporting, applications are mostly implemented on the client part of the system.
5.4.5
Use of the Design
Both in InfTech and MedIns there was no formal approved design before the realisation started.
The development of the system was evolutionary. When a part of the system is complete, feedback
with the client takes place to get approval.
5.5. Implementation
67
At ChamCom and InvCom, every stage in the analysis and design process has it’s starting and
ending point. The products of these steps are delivered by the project team to the steering team
and have to be approved. In both cases, the global design was the starting point for further
realisation. The global design did not have to be complete before realisation was started. When
part of the global design was ready and approved of, realisation would start.
5.5 Implementation
5.5.1
Choices
There were not many formal choices where the implementation of the system was concerned.
MedIns chose to train the employees in-house. This because all knowledge concerning the
system was present within the organisation. ChamCom and MedIns left the implementation to
the contractor, Data General.
5.5.2
Steps
InfTech
The implementation at InfTech is divided in a number of phases. Next to the installation
of the hardware platform and the tests an introduction to the users takes place. InfTech
chooses for an introduction in phases. This of course depends on the size of the organisation
at which the system is to be implemented. A system like the one described here is introduced
in four phases. These phases will be described in the next subsection.
ChamCom
At ChamCom there were only three steps, as far as the training of the personnel was
concerned. At first the department of system management took a course at the contractor,
Data General. They were already trained in the maintenance and management of a system
like this, but this was almost a year ago and with another contractor. As soon as the system
was ready, all users went on course at Data General. Everyone was trained in using their
part of the system. Finally, a demonstration of the system was given to the rest of the
employees at ChamCom. This was very important, because of ChamCom’s intentions to
introduce workflow technology in the whole organisation.
InvCom
The implementation at InvCom can be divided in a number of phases. Next to the installation of the hardware platform, an integration test, the actual introduction, the acceptance
and the after care takes place. During the actual introduction all users and maintainers are
trained. Following this introduction, InvCom has to do an acceptance test for two weeks.
After this acceptance, Data General will supply support for two weeks. Further support is
not included in the contract.
5.5.3
Execution of the Steps
The approach of InfTech is quite different from the other approaches. InfTech has built the system
in-house and then implements it at the client. InfTech uses the training strategy as shown in
figure 5.12. The total group of people of people that are to be trained are divided into groups
of for example ten people. They make sure that the most ’stubborn’ people are part of the first
group. They are slowly trained in the way that they smoothly move their activities to the system.
First for one month, they are trained. The next three months, they execute one third of their
activities with the system, in the next three months two third and in after this period, they execute
all activities with the system. This is a good but lengthy process.
In general, the steps in the implementation phase as encountered in InvCom and ChamCom can
be divided into a number of categories:
68
70
60
50
...etc....
40
M
M
M
30
M
20
M
M
10
M
M
0
0
1
M
M
2
M
3
4
M
5
6
7
8
9
10
11
12
13
14
TIME (MONTHS)
Training
Procedure enrolement
Procedures enrolement and discharge
Procedures enrolement, discharge and mutations
Figure 5.12: The Introduction at InfTech
1. Installation of the technical infrastructure
2. Installation of the actual system
3. Training of the users and maintainers
4. Acceptance by the organisation
5. After care
Hardware
Item
InfTech
MedIns
ChamCom
InvCom
Architecture
Server
Clients
Network
Client/Server
Bull DPX/20 (RS/6000)
PC
Ethernet
Client/Server
Wang VS 5460
PC
WANG
Client/Server
AViiON AV/4605
PC
Token ring
Client/Server
AViiON AV/4605
PC
Ethernet
Table 5.9: Hardware Platforms in the Four Projects
The characteristics of the hardware realisation are given in table 5.5.3. All systems are based on
a client/server architecture. This is due to the fact that a workflow system is a combination of
centralised control and local interactive processing and is hence, ideally suited for a client/server
architecture [HL91]. All clients are based on standard PCs varying from a 286 to 486 processors.
All clients are equipped with additional hardware depending on their intended use. When the
client is used to display images, they are equipped with (double) A4 displays and accompanying
graphical capabilities. The servers used are quite divers. All the organisations have the hardware
products of the supplier of the system.
The server at MedIns was initially only meant to run the insurance utilities and the word processing program. The MI2 system was added and due to the expansion of the organisational activities
the server is at it’s maximum capability. The server has to be substituted by a faster system.
69
5.6. System Evaluation
Software
Item
InfTech
MedIns
ChamCom
InvCom
OS server
OS client
WF tool
Unix
DOS/Windows
FlowPATH
DG/UX 5.4R2.01 (Unix)
DOS/Windows
Plexus/FloWare
DG/UX 5.4R2.01 (Unix)
DOS/Windows
Plexus/FloWare
Database
Image
Oracle
ImageWorks
WANG VS
DOS
Self built in
PACE 4GL env.
PACE
WIIS
Informix
Plexus XDP
Informix
Plexus XDP
Table 5.10: Hard- and Software Use in the Four Projects
The applied software gives no surprises. The servers use Unix or an altered Data General Unix
for their operating system. MedIns uses the VS operating system of supplier WANG. All clients
are based on MS DOS sometimes combined with MS Windows. The system at MedIns was built
before the introduction of Windows and therefor uses a window structure inhibited in the system
itself.
The most recent systems use a ready workflow tool like FlowPATH and Plexus/FloWare. Both
implementations require a separate image application.
5.6 System Evaluation
This section discusses the evaluation of the observed systems at the organisations. The observations show that there is not much information available concerning the evaluation. Except
for MedIns, the investigated systems have not been running for a long time that an evaluation
would supply much data. At InfTech, the pilot has just been running at InfTech itself, so feedback
from the eventual end-users is not available. The system at MedIns has been completed about a
year and a half ago and an evaluation has taken place a couple of months after the introduction.
ChamCom and InvCom have completed their system in the first half of 1994. Only at InvCom an
questionnaire among the users has been taken.
5.6.1
Users
At MedIns, all users agreed on the fact that they had less freedom in the way they executed their
work. One did not considered this to be negative. They were all sure that the system could assist
them on their way to a more efficient working pattern. At ChamCom the system was welcomed
with great enthusiasm. The people who have worked with it already are very positive and come
up with ideas for new applications which could be added to the system. The employees at
InvCom were quite neutral. They did not ask for the system in the first place, so they are not sure
what the introduction of the system means for the execution of their tasks.
5.6.2
Organisation
The effects for the organisation are obvious at the MedIns, where the system is running the
longest. They have been able to do more work with the same number of employees. At this
moment they are capable of answering 95% of the incoming mail the same day. At InvCom
the effects on the organisation are quite painful. The employees working at the administrative
part of the department are losing many of their activities to the system. Their task is reduced
to the scanning of (mail) documents in the morning. The head of the department is looking for
other activities for these employees. Hard as it sounds, for this department cost reduction can be
measured in terms of less personnel.
70
5.6.3
Efficiency
No numbers are available to illustrate the benefits in terms of efficiency due to the new system.
The benefits at the four organisations can generally be summed:
5.6.4
Document management is improved by the introduction of imaging technology.
Internal transport of files is gone.
Files are on-line available.
Correct and in-time execution of procedures is improved.
Responsibilities are unambiguously determined.
(Middle-)management can focus more on their actual task. With the availability of more
information, managing will be more effective.
Improvements
One of the great advantages of workflow technology is flexibility. This flexibility is not
always guaranteed in the system.
5.7 Project Evaluation
5.7.1
Goals
The goal in all organisations were more or less defined. The goals were primarily aimed at solving
the problems in the organisation. Next to this, a number of other goals are set. These were often
aimed at increasing the professional image of the organisation of increasing the level of service.
These goals are hard to measure.
It can be stated that in all organisations the goals are met. The primary cause, the archiving
problem, is solved due to the fact that files are stored digitally. The workflow application
provides the organisations with the information concerning the process, which solves most of the
secondary causes.
5.7.2
Method
Although the used methods are quite divers, the result is satisfying. InfTech has developed a new
method, but did not formally document it. It is mainly used on basis of intuition. Formalisation
and documentation have been neglected due to lack of time. Due to the evolutionary attitude of
InfTech, the method is likely to change due to future experiences.
MedIns did not use a method. All parties in the development process are familiar with the SDM
framework and this has been kept in mind during the development of the system.
ChamCom and InvCom both covered the pre-development phase them self. Both with the help
of workflow consultant agency DocWorld. They have contracted Data General to develop and
implement the system. Data General develops systems according to the SDM II framework. The
techniques used are the well-known Data Flow Diagrams and Entity Relation Diagrams.
5.7.3
Appreciation
The system is appreciated by the employees, especially when the employees have been involved
in the development of the system at all times. This was the most obvious at MedIns where the
users and developers literally sat around the terminal to construct the system. At ChamCom
the personnel was always informed and involved in the development. The introduction went
quite smooth this way. At InvCom there is room for improvement. Especially at the side of the
administration, there was insecurity as where there employment was concerned.
5.8. Conclusion
5.7.4
71
Improvements
From the study of the four projects, a number of improvements can be formulated:
User participation should be taken more seriously (InvCom)
Project management can be more professional (MedIns, InvCom)
Internal organisational communication should be improved (InvCom)
Introduction to the users should not suffer from lack of time (InvCom)
5.8 Conclusion
From the comparison made in this chapter, the following conclusions can be drawn.
5.8.1
Project
Within each organisation, the goals of the workflow project were clearly defined. Obviously, the
goals were set to solve the problems within the organisation. These are referred to as causes.
The causes that have led to the developing of a workflow system are mostly of an archiving nature.
The reason for this is that workflow technology is not very well-known, so the entrance through
the document information system (DIS) technology is very natural. This will surely change in the
future, due to the fact that workflow technology is widely published of. Both workflow and DIS
are identified as mature separate technologies and the synergetic effect gained by a combination
are recognised.
5.8.2
Process
The investigated processes are of an entirely different nature. Two extremes can be distinguished
among the investigated organisations. At MedIns it is not the primary process, the processing of
requests concerning insurances, that is important, but the support process of distributing mail,
checking the correct treatment and taking care of outgoing mail. This causes the workflow to be
defined in terms of destinations with great emphasis on routing. The other extreme is at InvCom.
The distributing of mail is limited to routing to the correct employee for a certain case. The
execution of his tasks, the procedural part of that workflow, is described in great detail in the
system. The workflow system at ChamCom is a mixed form. Both routing and task support are
important.
5.8.3
Analysis and Design
There are different techniques that have proven to work quite well. The description of the
process, with Data Flow Diagrams, as part of the functional design has been done at ChamCom
and InvCom. Remarkable fact is that all organisations, except for InfTech, use the phases of SDM
themselves, but the contractor uses another phasing.
The only organisation where no method is used was MedIns. The development was evolutionary with the SDM phasing in mind. Nevertheless a successful system was built. Quite an
achievement, considering the technology and know-how present at that moment.
At InfTech, a newly developed method was used. This method puts the activities (the Basic Units
of Work) in a central position. This is clearly a bottom-up approach. Applying this method, a
working system can be shown at all times, due to the fact that functionality is continuously added
after once the activities are implemented. This is meant by the evolutionary way of development.
The client always has insight in the development of the system and thereby ensures a system,
living up to the required standards.
72
The method applied at ChamCom and InvCom is clearly top-down. In a number of steps the
design progresses from a black-box to a detailed description of the activities and communication
lines that constitute the workflow.
None of the organisations used any modelling tools.
5.8.4
Implementation
The implementation was not very different at the four organisations. All organisations used the
client/server system architecture which seems perfectly suited for a workflow system. InfTech
used the workflow tool FlowPATH, ChamCom and InvCom both used Plexus/FloWare to realise
there workflow system.
5.8.5
System Evaluation
Due to the recent character of this kind of systems, the evaluation did not provide much information. The most extensive evaluation was found at MedIns, where a HEAO-student has dedicated
herself to this task. At InvCom the author of this report held a questionnaire. The result of the
evaluation is that the employees have less freedom in the execution of their tasks, but they all
agree that the system enables them to work more efficiently.
5.8.6
Project Evaluation
Like the evaluation of the system, the evaluation of the project is also hard. Most projects were
hardly finished, at the moment when the author entered the organisation. A cautious observation
is that the projects all succeeded and that both contractor and organisation are satisfied with the
system. The costs and the planning are conform the contracts.
5.8.7
Overall Conclusions
Going on the observations made at the four organisations a number of conclusions can be drawn:
Workflow automation can be successful with the technology and know-how currently available.
The primary causes for building workflow systems at the four organisations investigated
in this report are of an archiving nature.
Workflow combined with imaging (DIS) provides synergetic advantages.
The feared ’big brother’ effect can be prevented by using the information concerning the
process and employees wisely.
A bottom-up approach (InfTech and MedIns) as well as a more traditional bottom-up
approach (ChamCom and InvCom) can be successfully used.
User participation is getting more common.
Flexibility of the system is not alway close to the user.
73
Chapter 6
Organisational Applicability
Summary
Although workflow is currently a widely discussed issue in administrative automation, little is
known about the type of problems for which workflow is a solution. In this chapter an attempt
is made to bring some clearance in this area.
This chapter contains three main parts. In the first part the application domain of workflow
systems is discussed. This is done using an organisational approach (theory of Mintzberg), an
information technological approach (theory of Leifer) as well as an empirical approach (results of
the WA-12 research). In the second part the causes leading to a workflow solutions are discussed.
In the third part the logistic principles, known from the manufacturing technology, are applied
to workflow systems. How can the administrative process be modeled and streamlined from
a logistic point of view? The chapter will close with conclusions that can be drawn from these
topics.
6.1 Introduction
6.1.1
Purpose
The purpose of this chapter is to place workflow systems in an organisational context. The biggest
part of this chapter is devoted to a discussion about the types of organisations and processes that
have the right fit for a workflow solution. This will be done using an organisational approach, an
information technological approach as well as an empirical approach.
Another topic of this chapter refers to the causes that led to the development of a workflow
system. In the WA-12 research, nine main causes have been encountered. In this chapter these
nine causes are described in greater detail. Why do these causes occur at these organisations and
what are the backgrounds and possible solutions of these causes.
Another frequently asked question involves the relation between the relatively unknown field
of workflow automation and the already explored field of (manufacturing) logistics. It is worth
investigating what the similarities are and what the differences are between these fields. The most
important question is: what lessons can be learned from decades of experience with logistics.
6.1.2
Structure of this Chapter
In this paper the following structure is used. The discussion among the application domain of
workflow systems is dispersed over five subsequent sections. In section 6.2 a general introduction
is given in the application domains and the three approaches are described. Section 6.3 gives a
global introduction to the organisation theory. In section 6.4 an organisational approach is given
based on the organisational theory of Mintzberg. An information technological approach is given
in section 6.5 based on the theory of Leifer. In section 6.6 the empirical results of the WA-12
74
research are discussed with respect to these theories. Section 6.8 continues with the relation
between the known field of (manufacturing) logistics and workflow automation. The analysis
and optimisation of the logistics of an administrative process is discussed. The chapter closes
with conclusions in section 6.9.
6.2 Application Domain of Workflow Systems
6.2.1
Introduction in Three Approaches
In the next five sections an attempt is made to discuss the kind of organisations and processes
suitable for a workflow solution. The key element in these sections is formed by the organisational
typology as proposed by Mintzberg [Min79]. The foundation of the theory presented in the
following sections is formed by three pillars; the theory of Mintzberg, the theory of Leifer and the
empirical results of the WA-12 research. This is shown in figure 6.1
WORKFLOWSYSTEM
Coordination
mechanism
typology
(Mintzberg)
Information
systems
typology
(Leifer)
Empirical
results
(WA-12)
ORGANIZATIONAL
TYPOLOGY
(Mintzberg)
Figure 6.1: Mapping of Workflow Systems on the Organisational Typology
6.2.2
Mintzberg
Through the years a number of organisational typologies have been introduced by among others
Daft [Daf92], Woodward [Boe89] and Mintzberg [Min83]. In this chapter the last typology is
chosen. Although Mintzberg’s work is not the most recent one, it is still considered one of the
most valid theories on organisations. Especially, because he describes the most basic elements
of an organisation where most other theories find their roots. The base for Mintzberg’s theory
is formed by the coordination of activities in an organisation. Other typologies refer to the
contextual characteristics of the production system in terms of complexity or quantity of type of
product.
In this chapter it will be shown that Mintzberg’s theories can even be applied to the new field of
workflow systems, due to the fact that these systems have a big organisational impact and depend
very much on the way coordination throughout the organisation is implemented. This theory
of coordination mechanisms and its effect on information technology in relation with workflow
systems is discussed in section 6.4.
6.2.3
Leifer
In section 6.5 another approach is used. Leifer [Lei88] introduced an information systems
typology, based on an information systems topology, the organisational typology of Mintzberg
and the information needs of these organisational types. By placing workflow systems in this
6.3. Introduction in Organisation Theory
75
information system typology, the link between workflow systems and Mintzberg’s organisational
typology can be established in an information technological atmosphere.
6.2.4
Empirical
Both presented links are complemented by the results of the WA-12 research in section 6.6. The
validity of both previous mappings is assessed in an empirical context. All twelve organisations
will be placed in the organisational typology on basis of the observations made on site. The
conformation of this categorisation will be compared with the categorisation made in the other
two approaches.
6.3 Introduction in Organisation Theory
6.3.1
Organisations as Systems
To get a full understanding of the theories presented in the next sections, a general introduction
in the organisation theory is given in this section. Key issue is the perception of organisations as
systems as proposed by Daft [Daf92]. A system is a set of interacting elements that acquires inputs
from the environment, transforms them, and discharges outputs to the external environment. The
need for inputs and outputs reflects dependency on the environment. Interacting elements mean
that people and departments depend upon one another and must work together [Daf92].
In essence, workflow systems apply with this vision due to the fact that they act as such a system.
Raw material is transformed to the final product in a sequence of steps. The raw material in the
considered processes often consists of information rather than physical goods.
6.3.2
Closed and Open Systems and the IPO Paradigm
Closed and Open Systems
One significant development in the study of organisations is the distinction between closed
and open systems. A closed system does not depend on its environment; it is autonomous,
enclosed, and sealed off form the outside world. Although a true closed system cannot exist,
it can be represented by the internal workings of an organisation. Early management concepts,
including scientific management, leadership style, and industrial engineering, were closed system
approaches because they took the environment as a constant factor. The primary management
issue is to run things efficiently. However, the environment has great impact on organisations.
Therefore, nowadays the open systems perspective prevails [Daf92].
An open system must interact with the environment; it both consumes resources and exports
resources to the environment. It must continuously change and adapt to the environment.
Internal efficiency is just one issue, and is sometimes a minor issue. The organisation has to find
and obtain needed resources, interpret and act on environmental changes, dispose of outputs, and
control and coordinate internal activities in the face of environmental changes and uncertainty
[Daf92].
The IPO Paradigm
A well known way to model organisations as systems is through the Input-Process-Output (IPO)
Paradigm [GL94]. The IPO paradigm is used to model the (workflow) production processes. The
structure of the IPO paradigm is shown in figure 6.2. The workflow is regarded as a chain of
activities that takes information and material as input and produces information and material as
output. Complex activities can be decomposed into simpler and more structured activities. The
management of the workflow chain is realised by control to and feedback from the process. In
an IPO model it is expected that inputs, transformations and outputs are well defined and the
IPO paradigm is suitable for modeling workflows in repeatable procedure based processes. The
76
Control/
Feedback
Information/
Material
Information/
Material
Process
Input
Output
Decomposition
Figure 6.2: The Input-Process-Output (IPO) Paradigm
commitments among the workers and in particular between the business and its customers in
order to carry out the work is not explicitly described in IPO models [GL94].
6.3.3
Organisational Subsystems
Environment
Raw materials
People
Information
resources
Financial
resources
Subsystems
Input
Boundary
spanning
Transformation
process
Production, maintenance,
adaption, management
Output
Products
and
Services
Boundary
spanning
Figure 6.3: An Open System and its Subsystems
An organisation is composed of several subsystems. The specific functions required for organisational survival are performed by departments that act as subsystems. According to Daft [Daf92],
organisational subsystems perform five essential functions, which are shown in figure 6.3 and
described below in greater detail.
1. Boundary spanning
Boundary subsystems handle input and output transactions; in other words, they are responsible for exchanges with the environment. On the input side, boundary departments
acquire needed supplies and materials. On the output side, they create demand and market
outputs. Boundary departments work directly with the external environment.
2. Production
The production subsystem produces the product and service outputs of the organisations.
This is where the primary transformation takes place. This subsystem is the production
department in a manufacturing firm, the teachers and classes in a university or the medical
activities in a hospital.
3. Maintenance
The maintenance subsystem is responsible for the smooth operation and upkeep of the
organisation. Maintenance includes the cleaning and painting of buildings and the repair
and servicing of machines. Maintenance activities also try to meet human needs, such as
morale, compensation and physical comfort.
6.3. Introduction in Organisation Theory
77
4. Adaption
The adaptive subsystem is responsible for organisational change. The adaptive subsystem
scans the environment for problems, opportunities, and technological developments. It is
responsible for creating innovations and for helping the organisation change and adapt.
5. Management
Management is a distinct subsystem, responsible for directing and coordinating the other
subsystems of the organisation. Management provides direction, strategy, goals, and policies for the entire organisation. In addition, the managerial subsystem is responsible for
developing organisation structure and directing activities within each subsystem. According to Bots [BJ93], management has three key functions, within an organisation:
(a) Guiding the organisation
(b) Letting the organisation function well
(c) Reporting
These three management tasks will return in rest of the chapter.
Dividing an organisational system into a five subsystems arises a question; which subsystems
can be part of a workflow system? In general some subsystems are more suitable to be supported
by a workflow system than others. In this context it is important to make a distinction in the
kinds of information constituting a workflow system. Jablonski [Jab94] distinguishes two kinds
of information flows when workflow systems are concerned. Data flow concerns the information
in the flow. This flow can be seen as the horizontal flow in the IPO paradigm. The other kind
of flow is the control flow. The IPO diagram shows this flow in a vertical way. The control flow
concerns information about the flow.
The two types of flow are not fully interdependent. A system can consist of just data flow, but
a lot of the potential of a workflow system is left unused. A system can consist of only control
flow, but then the control information has to be entered in the system apart from the other work.
This way the feedback in terms of steering signal will not have much effect. It shall be clear that
when both types of flows are combined, a synergetic advantage is gained.
Concerning this kinds of flow, the following can be stated. The data flow supported in a workflow
system will cover (part of) the transformation process from input to output. It is most likely that the
production subsystem is the core of the workflow system. Also boundary spanning subsystems
can be part of this system when clients trigger the a workflow directly, in case of an insurance
claim. Management is mostly not part of the workflow in the way that they participate actively,
but rather that they exercise control over the workflow. In an administrative environment, the
border between a production subsystem and a boundary spanning subsystem can be vague or
even absent.
6.3.4
Dimensions of Organisations
The systems view pertains to dynamic, ongoing activities within organisations. The next step
for understanding organisations is to look at dimensions that describe specific organisational
characteristics. These dimensions describe organisations much the same way that personality
and physical characteristics describe people.
According to Daft [Daf92], organisational dimensions fall into two types: structural and contextual. This is shown in table 6.1. Structural dimensions provide labels to describe the internal
characteristics of an organisation. They create a basis for measuring and comparing organisations.
Contextual dimensions characterise the whole organisation, including its size, technology, environment, and goals. They describe the organisational setting that influences the structural
dimensions. Contextual dimensions can be confusing because they represent both the organisation and the environment as the context within which the structural dimensions occur. Both
structural and contextual dimensions are necessary to evaluate and understand organisations.
For comparing purposes, only the structural dimensions will be used.
78
Structural dimension
Contextual dimension
1.
2.
3.
4.
5.
6.
7.
8.
1. Size
2. Organisational technology
3. Environment
4. Goals and strategy
5. Culture
Formalisation
Specialisation
Standardisation
Hierarchy of authority
Complexity
Centralisation
Professionalism
Personnel ratios
Table 6.1: Structural and Contextual Dimensions of Organisations
Structural Dimensions
1. Formalisation; Formalisation pertains to the amount of written documentation in the organisation. Documentation includes procedures, job descriptions, regulations, and policy
manuals. These written documents describe behavior and activities. Formalisation is often
measured by simply counting the number of pages of documentation within the organisation. Universities, for example, tend to be high on formalisation because the have several
volumes of written rules for things as registration, drop and add, student associations, dormitory governance, and financial assistance. A small, family-owned business, in contrast,
may have almost no written rules and would be considered informal.
2. Specialisation; Specialisation is the degree to which organisational activities are subdivided
into separate jobs. If specialisation is extensive, each employee performs only a narrow
range of activities. If specialisation is low, employees perform a wide range of activities in
their jobs. Specialisation is sometimes referred to as the division of labor. This notion will
return in the next section where the theory of Mintzberg is discussed.
3. Standardisation; Standardisation is the extent to which similar work activities are performed
in a uniform manner. In a highly standardised organisation like McDonald’s, work content
is described in detail, and similar work is performed the same way at all locations. This
is an important notion concerning workflow systems. Standardisation will be extensively
discussed in the next section.
4. Hierarchy of authority; The hierarchy of authority describes who reports to whom and the
span of control of each manager. The hierarchy is depicted by the vertical lines on an
organisation chart. The hierarchy is related to span of control (the number of employees
reporting to a supervisor). When spans of control are narrow, the hierarchy tends to be tall.
When spans of control are wide, the hierarchy of authority will be shorter.
5. Complexity; The complexity of an organisation refers to the number of activities or subsystems within the organisation. Complexity can be measured along three dimensions:
vertical, horizontal, and spatial. Vertical complexity is the number of levels in the hierarchy.
Horizontal complexity is the number of job titles or departments existing horizontally across
the organisation. Spatial complexity is the number of geographical locations.
6. Centralisation; Centralisation refers to the hierarchical level that has authority to make a decision. When decision making is kept at the top level, the organisation is centralised. When
decisions are delegated to lower organisational levels, it is decentralised. Organisational
decisions that might be centralised or decentralised include purchasing equipment, establishing goals, choosing suppliers, setting prices, hiring employees, and deciding marketing
territories
6.4. An Organisational Approach
79
7. Professionalism; Professionalism is the level of formal education and training of employees.
Professionalism is considered high when employees require long periods of training to hold
jobs in the organisation. Professionalism is generally measured as the average number of
years of education of employees, which could be as high as twenty in a medical practice
and less than ten in a construction company.
8. Personnel ratios; Personnel ratios refer to the deployment of people to various functions and
departments. A personnel ratio is measured by dividing the number of employees in a
classification by the total number of organisational employees. Personnel ratios include the
administrative ratio, the clerical ratio, the professional staff ratio, or the ratio of indirect to
direct labor employees.
Contextual Dimensions
1. Size; Size is defined as the number of people in the organisation. It can be measured for
the organisation as a whole or for specific components, such as a plant or division. Other
measures such as total sales or total assets also reflect magnitude, but they do not indicate
the size of the human part of the social system.
2. Organisational technology; Organisational technology is the nature of the productions subsystem, and it includes the actions and techniques used to change organisational inputs
into outputs. An assembly line, a college classroom, and an oil refinery are technologies,
although they differ from one another.
3. Environment; The environment includes all elements outside the boundary of the organisation. Key elements include the industry, government, customers, suppliers, and financial
community. Environmental elements that affect an organisation the most are often other
organisations.
4. Goals and strategy; The organisation’s goals and strategy define the purpose and competitive
techniques that set it apart from other organisations. Goals are often written down as
an enduring statement of company intent. A strategy is the plan of action that describes
resource allocation and activities for dealing with the environment and for reaching the
organisation’s goals. Goals and strategies define the scope of operations and the relationship
with employees, clients, and competitors.
5. Culture; An organisation’s culture is the underlying set of key values, beliefs, understandings, and norms shared by employees. These underlying values may pertain to ethical
behavior, commitment to employees, efficiency or customer service, and they provide the
glue to hold organisation members together. An organisation’s culture is usually unwritten
but can be observed in its stories, slogans, ceremonies, dress, and office layout.
The thirteen contextual and structural dimensions discussed here are interdependent. For example, large organisation size, a routine technology, and a stable environment all tend to create an
organisation that has great formalisation, specialisation and centralisation.
6.4 An Organisational Approach
In the previous section a short introduction was given in the organisation theory. It was stated
that especially the structural ’framework’ of an organisation is interesting when discussing a
workflow system which appeals to the most basic characteristics of an organisation. A lot of
research in these basic characteristics has been done by Henri Mintzberg. His theory in relation
with workflow systems will be discussed in this section.
Each and every organisation, or rather, each and every organised activity of people has to satisfy
two contradictory requirements; the division of labour in a number of activities and the coordination of these activities. Looking at organisations this way, the structure of an organisation can
80
Vertical task division
simply be defined as the complex of the different ways in which the labour is divided and the
way in which these activities are coordinated [Min83]. These two topics will be discussed in this
section. Most emphasis is put on the coordination mechanisms as proposed by Mintzberg. These
coordination mechanisms are the key element in his organisational typology. This organisational
typology will be discussed along with these coordination mechanisms. But before this, the notion
of division of labour will be discussed in greater detail.
......
....
....
Horizontal task division
Figure 6.4: Horizontal and Vertical Task Division
When an organisation grows, the primary process can no longer be controlled by one person
only. The work has to be divided into different activities. This division of labour has two
dimensions. The first is the ’width’-dimension; in how many different activities with related
disciplines is the work divided and how big or small are these activities (tasks). This dimension
is referred to as horizontal task division . Related notions are horizontal task specialisation,
when an employee eliminates activities from his job and focuses on one or more disciplines,
and horizontal task enrichment, when an employee adds disciplines to his job. The second is
concerned with the ’depth’-dimension; to what extent is the execution and the control over the
work divided. This dimension is referred to as vertical task division . Related notions are
vertical task specialisation, when an employee goes from executing and controlling the work to
just executing or just controlling the work, and vertical task enrichment, when an employee not
only executes the work but also takes control over it. These notions are shown in figure 6.4.
M
M
Manager
M
Analist
A
O
Operator
A
O
O
Operator
(a) Mutual adjustment
A
O
O
Input
skills
(b) Direct supervision
Workprocesses
O
Output
(c) Standardisation
Figure 6.5: The Coordination Mechanisms According to Mintzberg
When labour is divided in activities there is need for the coordination of these activities. Mintzberg
[Min83] discovered that the basis for an organisational typology, but in fact for an organisation,
is formed by the coordination mechanisms on which that organisation is built. He distinguished
81
five coordination mechanisms. These mechanisms explain the fundamental way organisations
coordinate their activities. They can be seen as the most basic elements of an organisation; the
’glue’ that keeps an organisation together. These five coordination mechanisms (see figure 6.5)
and the organisational type in which it is most commonly found are:
1. Mutual Adjustment and the Adhocracy
2. Direct Supervision and the Simple Structure
3. Standardisation of Work and the Machine Bureaucracy
4. Standardisation of Outputs and Divisionalised Structure
5. Standardisation of Skills and the Professional Bureaucracy
These different notions will be discussed in greater detail in the next five subsections.
6.4.1
Mutual Adjustment and the Adhocracy
Mutual Adjustment
When the mechanism of mutual adjustment is applied, the work is coordinated by the simple process of informal communication. This concept is shown in figure 6.5a. The control over the work
is in the hands of those who do the work. It is quite obvious that this coordination mechanism is
only suitable for very simple organisations, due to its natural and simple characteristics. Remarkable fact is that this coordination mechanism is also encountered in very complex organisations.
Especially when developing a complex product or service, for example launching a space shuttle,
which has never been done before, this mechanism occurs. The knowledge develops along the
way. The success of such an operation depends very much on the ability for specialists to adjust
to one another.
Figure 6.6: Flow of Information in an Adhocracy
The Adhocracy
The coordination mechanism of mutual adjustment is found in every organisation and on every
level. The formation of departments causes this to appear. Within a department the activities are
mostly coordinated by communicating informally. But, aside from the fact that this mechanism
is found in every organisation, it is most typical for the adhocracy. See figure 6.6.
Being small and having the characteristics of a young organisation, the adhocracy operates
effectively as a cohesive group working together. The adhocracy relies on highly trained and
specialised experts. These experts must work together to accomplish the organisation’s goals.
For this reason mutual coordination and cooperation are critical, and cause these organisations to
behave like project teams [LT87]. The structure of these teams is organic with little formalisation
of the behavior. They can reside on different places within the organisation and are composed
of different combinations of line managers, staff employees and execution specialists. Examples
might be an advertising agency or a factory making complex prototypes [Min83].
82
Discussion
Adjustment is the key word in this coordination mechanism. Adjustment is a process of interaction, and necessary when executing activities simultaneously, as to assure that ’all noses are in the
same direction’. In an adhocracy there is no previously defined information system. In advance,
one does not know what information will be necessary, or if this information is present within
the organisation or has to be gained from outside. Every information system that determines and
plans all activities in advance jeopardises the flexibility of the adhocracy [BJ93].
Within a workflow system, activities are distinct and previously defined. The organisational
strategy was implicitly defined when the workflow was defined. The way in which to transform
input to output, and so achieving the organisational goals are predefined, so mutual adjustment
is not very suitable to be supported by a workflow system.
If facilitating the cooperation and coordination is important, groupware is a more appropriate
solution. Groupware makes it possible for a number of people to work simultaneous and realtime, each from their own workstation, at a document or other kind of product.
6.4.2
Direct Supervision and the Simple Structure
Direct Supervision
When an organisation grows a functional disaggregation has to made. No first line employee
is able to oversee the total process. The coordination mechanism of mutual adjustment will no
longer be sufficient. The coordination mechanism of direct supervision comes in.
When using direct supervision, the coordination is gained in the way that one person takes
responsibility for the work of others. He gives them instructions and guards the execution of
the activities. This concept is shown in figure 6.5b. An important notion is activity division.
Every employee has his own distinct activities. Due to this division, mutual adaption is not
longer enough to coordinate the activities of the employees. There is need for a leader. Someone
who has an overview of the (total) process, from input to output. Consider, for example, a car
dealer. There is mostly one manager/owner. Task division is implemented in a way that there
is a mechanic, an administrator and a salesman. When the salesman sells a car he reports this to
the manager, who orders the car at the factory. He also instructs the administrator to keep file of
this sale and to generate the invoice. The manager also instructs the mechanic to anticipate the
arrival of a new car which has to be prepared before a specific date. Obviously, the mechanic, the
administrator and the salesman do the work directly related to the primary process, while the
manager coordinates and supports these activities.
Figure 6.7: Flow of Information in a Simple Structure
The Simple Structure
The coordination mechanism of direct supervision is found in every organisation where there are
departments and hierarchical authorities. Direct supervision however is the most dominant in
the simple structure organisational type.
83
Simple structures are characteristic of both young, start-up, entrepreneurial organisations and
well-entrenched autocracies. They are generally small, operating in a market niche within a dynamic environment with few rules, but are centralised in the sense that the founder entrepreneur
makes most or all of the important decisions. Competitive advantage lies with either a unique
product service or fast response to environmental demands. Examples of simple structures include an automobile dealership with a flamboyant owner, a new government department, a
middle-sized retail store, a corporation run by an aggressive entrepreneur, or a school system in
a state of crisis [LT87]. The entrepreneur takes charge. He determines what is to be done and by
whom. The entrepreneur is concerned with all activities within the organisation. The communication is this type of organisation is informal. The most information interchange is between the
man at the top and the individual employee in the operating core. The employees themselves do
not exchange much information. See figure 6.7.
All information exchange with the environment is done by the man at the top. External information is the most important guideline for him to establish the organisation’s goals. There is the
most attention for the first management task as mentioned in 6.3.3 [BJ93].
Discussion
The entrepreneur is in the center of all information flows. Only he has access to all the information
concerning the organisation. The fact that this information is often not stored on paper, makes
this kind of organisation very vulnerable. When the top of the organisation is absent for a certain
reason, the organisation is totally out of control. This vulnerability can be reduced by introducing
formal information systems to store, at least the most essential information, but this is another
discussion.
The coordination mechanism of direct supervision seems not well suited to be tackled with
a workflow solution. Not only, because a formal information system is new for this kind of
organisation, but implementation in this structure would require all work to be routed to the
supervisor after finishing by an employee. He should inspect this work, and if it lives up to
the standards, the supervisor can send it to the next employee. In a way, the supervisor has
the role of the workflow activity manager. This coordination mechanism is therefore most often
found in small companies where the supervisor is still capable of coordinating and inspection
the execution of activities. If the organisation grows, the supervisor will be the bottleneck in the
process. Another coordination mechanism has to be introduced and this will probably be one of
the following.
6.4.3
Standardisation of Work and the Machine Bureaucracy
Standardisation of Work
Work can also be coordinated without using mutual adjustment or direct supervision. It can be
standardised. This way, the coordination is not anymore a ’run-time’-notion, but was guaranteed
at the time the organisation was designed. Substituting direct supervision by standardisation - a
process known as institutionalising the work of the manager - the control of managers over the
workers as well as the control of workers over their own work is reduced. This is similar to the
situation when mutual adjustment was substituted by direct supervision [Min83].
Standardisation can be achieved in three different ways. Standardisation of work processes,
standardisation of output and standardisation of skills. These ways of standardisation are shown
in figure 6.5c.
Work processes are standardised if the content of the work is specified or programmed. The way
on which the work is done is prescribed. The assembly-instructions accompanying toys are an
example of this mechanism. The manufacturer standardises the working process of the parents,
who assemble the toy. When applied to an organisation, the sequence of activities constituting
the work is described in great detail. Reading a manual, every human being should be able to do
that particular work.
84
Figure 6.8: Flow of Information in a Machine Bureaucracy
The Machine Bureaucracy
The mechanism of standardisation of work processes is mostly found in the configuration of
machine bureaucracies. Machine bureaucracies are characterised by standardisation, functional
structural design, and large size. These structures are generally differentiated both horizontally
and vertically, and are naturally associated with mass production technology where the products,
process and distribution are rationalised around repetition and standardisation. These rationalisation efficiencies find expression in the standardisation of functions and processes, utilising
rules and policies to underline the management’s obsession for control [Lei88]. Even though
current notions of organisations find bureaucracy out of favor [NA85], continuing requirements
for mass produced goods and services make this type of organisation the most prevalent of the
configurations. Examples of this type of organisation are mostly found in the governmental area
and very large companies [Min83].
Discussion
Coordination through standardisation of the work processes has consequences for the information
supply. The information in the machine bureaucracy will not be exchanged fast and informally.
In these configurations, the possibilities arise to construct a lasting (and maybe non-flexible)
information system. All subjects about which information is needed have to be inventoried and
categorised. The most emphasis is on the second function of the management as identified in the
previous section; letting the organisation function well [BJ93].
Standardisation of work seems very much suited to be tackled by a workflow solution. The
prescribed procedure has to be programmed in the system completely to assure the correct
execution. Every activity in a transformation process has to be supported by the system. There
will not be much room for the employee to change the process the way he would like it to be. The
employee is forced into a straight jacket and will not be most happy. The ’big brother is watching
you’-danger is very real in this kind of environment. If a company has a paper factory approach,
the process is dispersed along a lot of employees and a lot of routing is required. If the company is
very much service oriented and therefore chooses to implement full-case handling, there will be
high demands on the functionality of the workflow tool. Especially activity support is required,
due to the fact that routing is of minor importance. In all cases, demands on flexibility are low,
and a lot of efficiency can be gained by introducing a workflow system.
6.4.4
Standardisation of Outputs and the Divisionalised Form
Standardisation of Outputs
Output is standardised when the results of the work, for example the measures of a product or
the characteristics are specified. It is not said how the work must be done, as in the machine
bureaucracy, but rather what the result of the work must be. For example, a taxi driver is not told
how to drive through the city, as long as he gets the client where he wants to go [Min83].
85
Figure 6.9: Flow of Information in a Divisionalised Form
The Divisionalised Form
On organisational level, the coordination mechanism of standardisation of outputs is most often
encountered in large organisations with small top management and independent divisions. But
also other organisations, for example the government, try to use this mechanism. It embodies
itself in terms of self-management, contract-management and making organisations independent.
The divisionalised form in contrast to the professional bureaucracy, is an integrated set of semiautonomous entities loosely joined by an administrative framework and is characteristic of older,
more mature, very large organisations. The semi-autonomous entities, often referred to as Strategic Business Units (SBU’s), determine the strategic portfolio of the organisations. Divisionalised
structures might operate in two ways, which will be referred to as Form A and Form B [Lei88].
Form A, as discussed by Mintzberg [Min81], is a market-based set of divisions - decentralised from the perspective of the total organisation, but centralised within the division.
In this form, divisionalisation might be composed of multiple machine or professional bureaucracies. In short, this organisation might be seen as a set of small bureaucracies held
together loosely by a formalised set of budgets or goals as performance control systems.
Examples are usually drawn form the private sector of the industrialised economy - the vast
majority of the Fortune 500.
Form B, not discussed by Mintzberg, can also be viewed as a set of semi-autonomous
divisions. However, rather than being loosely tied together by performance control systems,
they are bound together by a strong culture. While the semi-autonomous units develop
in response to product or geographical diversity, they are tightly coupled to each other
through strong values, beliefs, shared perceptions and meanings [DK82] [PW82].
This theory on the divisionalised form on organisation level can be generalised to the individual
employee. When an organisation or department coordinates its activities on basis of standardisation of output, the way in which the employee executes his activities is not important. The
important thins is that he gets the work done, with a result living up to the standards set by the
organisation.
Discussion
The way of coordinating through standardisation of outputs has clear consequences for the
information supply functions. In contradiction to an organisation where the standardisation of
work processes is dominant, top management does not have to be informed continually about
the internal functioning of the division. This informing can be done on a low frequency base,
so the management can check whether the predefined goals are met. Often, there are explicit
deals about the kind and frequency of this information. In this type of organisation there is much
86
emphasis on the third task of the management as identified in the previous section; the reporting
task [BJ93].
On an individual level, standardisation of outputs is one of the coordination mechanisms well
suited for a workflow solution. The type of work flowing between the different actors is predefined. By defining what kind of work an employee expects to get the kind of output the preceding
employee has to make is also defined. The way in which the work is done is of minor importance.
Routing and the work that is routed is very important when applying a workflow system in an
organisation. Task support is of minor importance. This reminds of a paper factory kind of
organisation where a routing oriented workflow tool will be most appropriate.
6.4.5
Standardisation of Skills and the Professional Bureaucracy
Standardisation of Skills
Skills (and knowledge) are standardised if the kind of training that is required for the execution
of the work is specified. This mechanism is applied when it is possible to standardise nor the
work, nor the output. In a way, the employee is standardised [Min83]. The standardisation of
skills leads indirectly to the same result as standardisation of work or output. Each employee
knows what is expected from him and what to expect from others [Min83]. An example is found
in the process of a surgery. The surgeon knows what his tasks are and what to expect from for
example the anaesthesist. This doesn’t have to be discussed in advance. The employees, selected
on skills and attitude are called ’professionals’.
Figure 6.10: Flow of Information in a Professional Bureaucracy
The Professional Bureaucracy
Professional bureaucracies rely on standardisation of skills as the basis for coordination. The
emphasis is on the ones who execute the primary process: the professionals. While the product of
machine bureaucracies often has a high physical component, the product of professional bureaucracies have a high informational component. Since these product depend for their effectiveness
on skilled people who must be given considerable control over their own work, the organisation
must be decentralised down to those professionals responsible for carrying out the organisation’s
tasks. As a result of their training, professionals act rather independently, but are consistently in
accordance with the goals of the organisation, requiring few formal rules and policies. Independence of action is productive if no concerted action is required by organisation members to act
as a whole. Examples can be found in practices of lawyers, doctors, consultants or other kind of
specialists [LT87].
Discussion
Most professionals act as islands in the organisation. Each professional has his own cases. The
information is dispersed and decentralised, but present within the organisation. The specialists
all have their own administration with all the data needed for the execution of their practice. All
87
specific information is kept to themselves and the information that is exchanged, often mostly
concerns the expected revenues, the proceeding of their projects, etc. This information is often
exchanged verbal, and not registered in an information system [BJ93].
Sometimes, an organisation cannot allow itself to let the professionals function as islands. What
is considered right by the professionals themselves, would not necessary be considered right for
the organisation. The organisations provides guidelines for the functioning of the individual
specialists. In fact is the professional bureaucracy no more and no less than a mix of a divisional
structure and a machine bureaucracy.
It is important when building an information system to leave the individual professionals as much
alone as possible. For example, in a hospital, one should think of a central database for the data
concerning all patients which can be used by all specialists. A characteristic of the professional
bureaucracy is that most is invested in systems for the support of the know-how within the
organisation. In this organisation, one often finds large libraries with information, which can be
used by all professionals within the organisation.
Machine Bureaucracy
with
Standardisation of
Work
much formalisation,
bureaucratic
Divisionalised Form
with
Standardisation of
Skills
little formalisation,
bureaucratic
Professional Bureaucracy
with
Standardisation of
Outputs
much formalisation,
bureaucratic
much horizontal and
vertical specialisation
much horizontal
specialisation
some horizontal and
vertical specialisation
3. Standardisation
high
low
low
4. Hierarchy of authority
large
small
mediate
5. Complexity
high
low
mediate
6. Centralisation
limited horizontal
decentralisation
horizontal and
vertical decentralisation
limited vertical
decentralisation
7. Professionalism
little training and
indoctrination
much training and
indoctrination
some training and
indoctrination
8. Personnel ratios
large technostructure
large operating core
large middle line
Structural dimension
1. Formalisation
2. Specialisation
Table 6.2: The Structural Dimensions of Standardisation Based Coordination
In the past three sections, the different types of standardisation are discussed. To make these
more comparable, the structural dimensions of these three mechanisms are summarised in table
6.2.
6.4.6
Conclusion
The coordination mechanism on which an organisation is built has a lot of impact on the information needs throughout the organisation. The coordination mechanisms of mutual adjustment and
direct supervision are not well suited to be supported by a workflow system. This is much due
to the informal character of the organisation and the information exchange. Workflow systems
will therefore not be found in the conforming organisational types as the simple structure and the
adhocracy. The often small size of these organisations would make a feasible workflow system
hard to achieve. A coordination mechanism based on some kind of standardisation is more suited
to be supported by a workflow system. As the name reveals, a workflow system is designed to
support the workflow, but this workflow has to be more or less defined. This definition can be
done in terms of activities or destinations or both. The type of workflow system is therefore quite
88
divers with the different kinds of standardisation. Standardisation of output in a divisionalised
form mainly involves routing due to a definition of the work to be routed. It does not put high
demands on activity support. Standardisation of work in a machine bureaucracy does put high
demand on activity support. The routing is implicit. Standardisation of skills in a professional
bureaucracy can be a mix of both others. In this situation their is much freedom in the way the
system is designed. But there is also a danger in the fact that a workflow system will easily lead
to limitation of the freedom of the professionals.
6.5 An IT-approach
In the previous section the application domain of workflow systems was determined from an
organisational point of view. In this section the same will by done using an information technical
approach. The primary point is that an effective information system is one that fits the organisation’s culture and style. Appropriately, the mapping of information system will achieve balance
and harmony for the organisation if the characteristics of the organisation’s culture and style are
complementary [Bur85].
organisational structure
Simple Structures
Machine Bureaucracy
Professional Bureaucracy
Divisionalised Form
Adhocracy
Stand-Alone
PC’s
p
Centralised
Systems
Distributed
Systems
p
p
p
p
p
Decentralised
Systems
p
p
Table 6.3: Conformations between Organisational and Information Systems Typology
Similar to the typology of organisations, a typology of information systems can be made. In
this section four types of information systems are distinguished, according to [Bur85]. The basic
conformations between organisation structures and information systems types are determined
by Leifer [LT87] and are shown in table 6.3. They are:
1. Adhocracy and decentralised systems
2. Simple structures and stand-alone systems
3. Machine bureaucracy and centralised systems
4. Divisionalised form and centralised, distributed and decentralised systems
5. Professional bureaucracy and centralised and distributed systems
6.5.1
Adhocracy and Decentralised Systems
Decentralised Systems
Due to the fact that all units in a decentralised system are equal, they are often referred to as ’peer
networks’ [Dur87]. There is no central processor through which communications must pass,
and hence there are more degrees of freedom in communication. Although the workstations or
other systems communicate through bridges or gateways and require rules for connectivity, these
constraints are substantially less than for distributed systems.
Electronic mail, local area networks, telecommunications systems, group decision making systems, etc. allow messages to be sent through the network in an interactive mode. This results in
an increase in the quality, quantity, reliability an capability of the system to process information
89
6.5. An IT-approach
[LT87]. The ability to selectively communicate with particular individuals, groups, skill areas,
or those with needed information, allows the flexibility to build ad hoc, non-face-to-face groups
or work teams. This flexibility gives decentralised systems the capability to cope with a wide
variety of informational demands [Lei88].
Figure 6.11: Adhocracy and Decentralised Systems
Conformation with the Adhocracy
Adhocracies rely on team members working together to accomplish the organisation’s goals. For
this reason, high information processing capabilities are needed, which can be accomplished with
mutual coordination, task forces, and in addition, decentralised information systems.
In order for communications to flow throughout the organisation to where the expert knowledge
resides, communication means need to be widely dispersed and available. For this to occur
successfully the size of the adhocracy must remain relatively small. Adhocracies might be
divisions of divisionalised organisations, as discussed above, or may be internal entrepreneurial
units within large organisations, operating somewhat autonomously of organisational constraints.
As as way for organisations to manage uncertainty and change, they can divide themselves into
relatively autonomous divisions, each with its own general manager and its own staff heads for
each major function. The resulting information flows and unit flexibility means there is a relatively
flat organisation pyramid, allowing innovation and fast response to function and flourish [LT87].
The conformation of the adhocracy and decentralised systems is shown in figure 6.11.
Due to limited opportunities for face-to-face communication, decentralised information systems
should be perceived as being instrumental in increasing the volume, extent, and availability of
information. Decentralised information systems contribute and enhance the quality and quantity
of information, becoming a vital component of the adhocracy’s decentralised structure.
6.5.2
Simple Structures and Stand-Alone Systems
Stand-Alone Systems
Composed of stand-alone PC’s used in individual departments or as the information systems in
small organisations, stand-alone systems may function as the ’mainframe’ for those organisations.
since PCs are a relatively low-cost tool, most larger organisations do not plan for them [LaP87].
Further, their effect is on the work of individuals rather than on the organisation as a whole
[Lee86].
Conformation with the Simple Structure
Given that in such organisations the founder entrepreneur makes the important decisions, information processing capabilities are generally limited to his own information-processing capacity,
and most data gathering is done informally through personal contacts. Information systems in
90
Figure 6.12: Simple Structure and Stand-Alone Systems
simple structures are creed and informal [Mil86] and are predominantly stand alone systems,
either PCs or small system networked PCs. These systems are good information-processing solutions because of the organisations’ small size and limited needs for large amounts of information
processing. Most of the PCs are used to enhance individual job performance in such areas as
word processing, technical developments, sales, or inventory control rather than to contribute to
an overall management information system. Many small organisations, such as these use faceto-face meetings or the telephone for their information processing systems. In terms of routine
accounting needs or other more comprehensive activities, many small organisations probably
find it cost-effective to use local service bureaus [LT87]. This conformation between the simple
structure and stand-alone systems is shown in figure 6.12.
6.5.3
Machine Bureaucracy and Centralised Systems
Centralised Systems
Centralised systems are designed around a central processor or mainframe with ’dumb’ terminals, which allow interactive information processing activities, mostly of a transactional nature.
Centralised systems also include centralised mainframe installations, which are largely used for
batch processing or updating files. These systems are the basis of the term EDP [Bur85].
Figure 6.13: Machine Bureaucracy and Centralised Systems
6.5. An IT-approach
91
Conformation with the Machine Bureaucracy
The machine bureaucracy’s concern for efficiencies and rationalisation results in centralised decision making coupled with many rules and policies governing actions. Their computer based
information systems must be reliable and consistent in monitoring the organisations functions
and processes for enhanced control [Bur85]. Computer based information systems in a machine
bureaucracy is primarily concerned with the automation of the paperwork processes of the firm.
These activities range from accounting functions to systems aiding first line personnel, such as
online ordering systems or other transaction processing systems [RSM84].
Since many online computer based information systems’ activities are routine, such as data-entry,
centralised information system topologies are well suited to monitoring, control and routine data
processing and fit well into machine bureaucracies where control and monitoring are strategic
necessities [Mil86]. Implementing a centralised system in a machine bureaucracy requires few
changes on the part of the organisation [RSM84]. The centralised information system will tend
to not only reinforce the existing organisational structure and "way of doing things", but might
even drive units using the technology to be more formalised than units that are not computerised.
In summary, effective performance of centralised information system activities require rules and
policies that match the activities of the machine bureaucracy organisation.
6.5.4
Divisionalised Form and Centralised, Distributed and Decentralised
Systems
Distributed Systems
These systems, referred to as peer-to-host systems [Dur87], are designed as ’spokes’ or terminals
around a central processor or mainframe. Spokes might have their own processor, storage device
and terminals that have their own computing capabilities and data bases. Terminal users can
communicate with others but only through the central hub.
In contrast to the centralised processing of on-line systems, there is program data independence.
However, there is a similarity between centralised processing and distributed processing in
that both imply a form of central management, control and authority, requiring communication
with some other function or process and rules governing how that communication will take
place [Nac82]. In a distributed processing environment, some processing of data occurs in
multiple machines and results are exchanged, thus requiring rules. Ignoring or not realising this
dependence upon central management is what leads many corporations into difficulty.
Figure 6.14: Divisionalised Form and a Distributed System
92
Conformation with the Divisionalised Form
Form A Divisionalisation
Divisionalised organisations, composed of poorly integrated, loosely coupled, semi-autonomous
units, might have divisions that are machine bureaucracies, professional bureaucracies, or adhocracies, all coexisting within one corporate shell.
While Mintzberg [Min83] suggests the most obvious divisional form is the machine bureaucracy,
we should recognise that since divisions are loosely coupled to the strategic apex of the organisation, divisions might also be professional bureaucracies or adhocracies. These semi-autonomous
units (strategic business units or SBU’s) are large and homogeneous enough to exercise effective
control over most factors affecting their business, even though they exist within the umbrella
of the enterprise as a whole. The information system of these SBU’s reinforces the strategy and
structure of the SBU rather than the rest of the organisation. From the previous discussion, one
would expect a centralised information system if the SBU is a machine bureaucracy and a distributed information system if the SBU is a professional bureaucracy. Similarly, in an adhocracy
SBU, one would expect a decentralised information system.
Form B Divisionalisation
Form A divisions, operating semi-autonomously with separate information systems and databases, have the potential for inter unit distrust and competition. In Form B divisionalisation, there
is greater sense of inter unit cooperation and support, and use of cross-divisional information
systems. Increasing environmental turbulence will lead to an increase in organisational complexity. As organisational complexity increases there are increasing needs for greater information
processing capacity and capability. These needs can be accommodated by changes in information
systems architectures particularly telecommunications, LAN, voice-data integration, terminal
emulation and e-mail. Decentralised systems, by virtue of their flexibility and high information
processing capabilities, assist the organisation in adapting to environmental changes [LT87].
In summary, Form B divisionalised structures are associated with decentralisation, organisational
flexibility, and increased information processing needs, and would be best served by decentralised
information systems for increased information processing capabilities. An example of the conformation of the divisionalised form and a distributed system is shown in figure 6.14.
Figure 6.15: Professional Bureaucracy and a Distributed System
6.5.5
Professional Bureaucracy, Centralised and Distributed Systems
The professional bureaucracy can be described as consisting of semi-autonomousactors operating
in a stable yet complex environment with each person attending to a unique aspect of that environment. At first glance, informational needs of people in this organisational design might appear
to be high. Experience shows this is not the case. Whether it be a law firm, a consulting firm, or a
university, there is relatively little task oriented information processing among colleagues, except
perhaps when a particular skill base is needed by another professional to solve a problem. Most
coordination is accomplished by administrators, and most informations needs are related to the
6.5. An IT-approach
93
accumulated organisational history in the form of historical of specialised information/databases,
such as medical case studies, stock market activity, or legal briefs, is of greater value than internal
information databases. For these reasons, both centralised and distributed information systems
might be best suited for the professional bureaucracy.
6.5.6
Organisational Impact
If the information system is not matched with the organisation, the ability of the information
systems to change the organisational structures must not be ignored. What would happen if the
new information system routinised formerly decentralised decision making, such as portfolio
analysis models, aggregate production scheduling systems, or personnel selection models.
The distinction between informations system and organisational structure as independent or
dependent variables has not been made clear, but there has been an implicit assumption that
structure was the independent variable to which the information system should conform for an
acceptable match. This is largely because structure and culture have more influence on organisation members than does an information system, and since an information system costs less and
is more controllable than the cost of changing an organisation’s style and culture, it is easier to
modify an information system design than an organisational design. Keep in mind, however,
that there may be hidden costs attached to a new information system, often ignored by managers,
such as interruptions of established organisational routines or changes in organisational power
relations.
Management may choose an information system for strategic or competitive reasons, and in doing
so may even realise that it is not well-matched to the organisation. There are basically one of two
possible outcomes to such a mistake. Either the system will not be used as intended and hence
will not live up to managerial or user expectations, or the organisation will make the desired
change, ultimately resulting in an information system-organisation match.
Much has been written about the need for effective implementation programs so that catastrophic
outcomes associated with information system-organisation mismatch be avoided and that new,
successful information system-organisation matches be reached. These programs generally have
users involved in the design process and planning and promote effective communication between
designers and potential users. Another approach suggests linking the management information
system plan with the corporate strategy to ensure that the information system will be viewed
as valid and important. It seems reasonable to assume that unless the information system is
perceived by top management to be important in the achievement of organisational goals, any
support for changing the organisation to fit the requirements of the new information system will
surely fail [Lei88].
In fact, most of the organisational change and development literature suggests that for change to
be effective, it must be supported by top management. While the impact on organisations of information systems has not gone unnoticed, the dynamics of the process of changing organisational
structure and organisational culture have not been fully appreciated.
6.5.7
Positioning of Workflow Systems
A workflow system is a combination of centralised control and local interactive processing and
is hence, ideally suited for a client-server architecture. As shown in the previous chapter, this
architecture is being widely implemented today, in all types of organisations, as a result of two
trends:
a move to open systems, typically Unix systems
a move to right-size computer systems (i.e. adopt the most appropriate systems infrastructure for the application rather than necessarily take a monolithic approach, as has been
common in the past).
94
Many organisation already have in place the necessary workstation/LAN infrastructure to support workflow. Most of these use the PC/MS-DOS operating system. Hence, most workflow
products are designed for this [HL91].
The client-server architecture is an implementation of the distributed systems architecture. But
a workflow system can also be implemented on a centralised system. Especially because recent
trends indicate that the centralised systems are on the rise again, the centralised system based
workflow will probably be more important in the future.
6.6 The Empirical Results
In the previous sections it is shown that a workflow system is best matched with an organisational
type based on one of the standardisation mechanisms. But is this practice?
Leifer
Stand-Alone
Systems
Centralised
Systems
Distributed
Systems
Machine
Bureaucracy
SocIns
GovLice
LeasCom
BankIns
ResLab
GovFin
Professional
Bureaucracy
MedIns
MinSub
InvCom
ChamCom
CredIns
Decentralised
Systems
Mintzberg
Simple
Structure
Divisionalised
Form
MortIns
Adhocracy
Figure 6.16: Multi-Dimensional Categorisation of the Twelve Organisations
To compare the discussed theory with practice, the organisations or rather the organisational
processes have to be categorised in the same organisational typology of Mintzberg. This is not an
easy task. The types described by Mintzberg never occur in their pure form. Most organisations
are hybrid in the sense that the typology of the total organisation is different from the type of
the specific departments. Due to the fact that the processes are the central issue in this report,
the categorisation is made on basis of the typology of the departments where the specific process
takes place. This categorisation is given in figure 6.16. This categorisation is made on basis of
personal impressions and therefore arbitrary to a certain extend.
The results show that two organisational types are prominent. These are the machine bureaucracy
and the professional bureaucracy. This is not remarkable. As said before, the divisionalised form
is an integrated set of semi-autonomous entities loosely joined by an administrative framework.
These entities are most often machine or professional bureaucracy. Due to the fact that organisations are classified on basis of the type of the department where the process resides, and the
6.7. Causes
95
divisionalised form is most prominent on organisational level, this type will not be identified
frequently.
With respect to the technological implementation, the distributed system architecture is dominant. This is due to the following reasons. As said before, in the past decade the information
systems in general moved towards client/server (C/S) architectures. Although C/S is a conceptual architecture, not forcing the implementation to have a separate physical client and server
component, this is often the case. Recent trends indicate a revival of the mainframe due to it’s
more attractive cost balance. Therefore, the evidence for the statement that distributed systems
are more suitable for a workflow solution than centralised systems is quite weak.
Concluding, it can be stated that organisations and processes based on a coordination mechanisms
with standardisation have the best fit for a workflow solution. Nevertheless, the accents are
quite different. The machine bureaucracy is procedure oriented and therefore demands a lot of
functionality from the workflow tool in terms of task support. The benefits when implementing
a successful system can be very high in terms of increased throughput, flexibility and integration.
In a professional bureaucracy task support is not desirable. Mostly routing is required and
demands on functionality will not be very high. The divisionalised form is a hybrid form
consisting of machine bureaucracies and professional bureaucracies. For the central registration
and management a workflow system is not required. As far as the implementation is concerned,
distributed as well as centralised systems are suitable. Due to the fact that the former is most in
favor nowadays, this architecture is encountered most often.
6.7 Causes
6.7.1
Introduction
In this paragraph the causes for developing a workflow system are discussed. The different
causes discussed here are derived from the thirteen investigated organisations. These causes and
the organisations are shown in table 6.4.
Before discussing this causes more thoroughly it is important to describe the difference between
the external and internal causes present in an organisation. External and internal causes are
related to external and internal goals. The external goals are aimed at satisfying the demands
of the environment. They are part of the company strategy. Main goal is ’delivering in time’.
On time in terms of delivery time as well as reliability of delivery. An other important goal is
flexibility; the power to anticipate to changes in customer demands. This in terms of product
specifications, quantities or delivery times. The production of high quality products is also an
external goal, but primarily not of a logistic nature. Internal goals are aimed at the realisation of
the external goals at minimal costs. Factors like the size of the stock, the occupation rate of the
production means and the quality of employees are very important [Har92].
6.7.2
Throughput
Throughput is directly linked to the performance of the process. Measurement and monitoring of
performance within organisations is essential. Since the operating systems are likely to be a major
component of any organisation, the measurement of performance of such systems is an essential
aspect of any total performance measurement. Measurement of the extent to which resources
are utilised and the level of service provided are ingredients of such performance measurement.
They are, if not the principal responsibilities of operations managers, the means by which the
performance of operations managers is assessed by others, and thus are matters of considerable
importance to such managers [Wil89].
The function of operating systems is the satisfaction of customer wants. The provision of customer
service and the creation of customer satisfaction is a multi-dimensional problem. In performance
measurement, three principal factors can be identified:
96
p
p
p
p
p
GovFin
MinSub
MortIns
InfTech
p p p
p
p
p
p
MedIns
ChamCom
InvCom
46
16
16
8
8
8
GovLice
Internal causes
Archiving
Control over process
Quality of data
Integration
Management information
Malfunctioning system
p
CredIns
31
16
16
SocIns
External causes
Throughput
Client focus
Flexibility
LeasCom
%
ResLab
cause
BankIns
p p p p
p
p
p
p
Table 6.4: Causes at all Organisations
1. Specification
This refers to the provision of goods, movement or treatment as requested or specified by
the customer, or to a standard but acceptable specification;
2. Cost
This refers to the provision of goods, movement or treatment at a requested cost or at a
standard but acceptable cost.
3. Timing
The timing aspect refers to the provision of goods, movement or treatment at a requested
time or at a standard but acceptable time, and/or at an acceptable delay.
It shall be clear that the throughput appeals to the last aspect, the timing aspect. This aspect will
therefore be elaborated.
The aspect of timing can be subdivided. Consider first the cost of goods. Customers will take
into account the delay or wait between their expression of a want and the subsequent satisfaction
of that want. This delay or wait will normally be evident as the period of time between placing
an order and receiving the goods or services. This is clearly an important dimension of customer
service, since delay greatly in excess of that which is acceptable will give rise to reduced overall
customer satisfaction and loss of customers. Again, this is a dimension which is, to some extend,
within the control of the organisation [Wil89].
However, a further dimension is also important in these two functions. Both transport and
service are time consuming. In both cases, therefore, the customers consider their likely duration
or the time required for their performance, i.e. to move from source to destination, or to be
treated or accommodated. In assessing an organisation the customer will therefore consider
this dimension, and equally, in seeking to achieve customer service, an organisation will seek to
provide an appropriate or acceptable duration for its transport or service. The timing factor can
therefore be subdivided into the dimensions of delay and duration [Wil89].
There were four organisations which gave throughput as one of the reasons for adopting a
workflow solution. This makes this cause the most ’popular’ under the causes that obstruct an
optimal realisation of the external goals. The low throughput at these organisations is mainly
caused by other problems. In all these four organisations, the retrieval of the archive was the
main problem. The inaccessibility of the (often huge) paper file had a negative influence on the
speed of the working process.
97
6.7. Causes
6.7.3
Client Focus
When client focus is given as the main reason for adopting a workflow solution, mostly there
is no urgent problem within the organisation. More client focus will be part of a strategic plan.
The combination of the advantages of workflow technology such as flexibility, integration and
a higher throughput will facilitate the adaption of the organisation to the requirements of the
market.
There were two organisations which mentioned client focus to be a reason for the development of
a workflow system. The cause of client focus does not seem urgent, but in the case of InfTech, the
existance of it’s clients is on the line if they are unable to successfully execute the transformation
to a self supporting enterprise. This demands flexibility, supplied by the workflow system.
Therefore, the importance of this notion must not be underestimated.
Stable
Mission
Goals &
Strategies
Business
Administration
Critical Succes Factors &
Targets
Performance indicators
Organisation
Theory
WORKFLOWS
Dynamical
Activities
Information
Technology
Data
Stable
Figure 6.17: Flexibility as a Result of the Workflow Approach
6.7.4
Flexibility
One of the advantages that have lead to the rise of the workflow technology refers to the flexibility
of a workflow system. In ’traditional’ system engineering one often takes the system as starting
point. In that context, the information system is no more than a translation into automated
procedures of the process at that moment. Implicitly, one presumes that this process is stable and
will not change due to an unstable environment. But it is essential that an organisation adapts
itself to the environment, and therefore work processes are not stable. The consequence that after
a while the system has to be renovated or rebuild is inevitable.
It is much better to take the workflow as a starting point. Workflow management is an approach
of information technology where the workflows are central. This way, principles and techniques,
known from (manufacturing) logistics can be applied to administrative processes. The procedures
are no longer ’frozen’ in the system [BBS93]. The procedures can be changed in order to conform
to changing internal or external goals. In figure 6.17 this notion is shown. The three layers of an
information system are shown: the workflows, the activities and the data. The workflow forms a
central issue and controls the activities. Next to this, critical success factors are connected to the
workflow, as to provide information to the management concerning the status of the workflow.
This way, deviations from the desired way can be noticed. In this layer structure the workflows are
the most dynamical. They have to adjust to changing environmental conditions. The dynamics
of a certain layer increase when it is positioned closer to the workflow layer [BBS93].
However an important advantage of workflow technology, there were only two out of the thirteen
98
condition
Small
Complete
Fast
Simultaneous
accessible
paper
–
-
micro-film
o
-
image
+
+
+
+
organisations in the research project who said that this was a reason to adopt a workflow system.
However, most of the other organisations have recognised this advantage and saw it as just
another reason to pursue with this technology. InfTech supplies systems to its clients. Systems
that have to used for quite a long time. Next to that, InfTech wants to supply the product for a
long time and for a wide variety of organisations.
6.7.5
Archiving
With respect to causes that obstructs the realisation of internal goals, the archiving problem is the
most prominent. Ideally, an archive has to satisfy a number (sometimes) contradicting conditions,
like:
1. Small in size
An archive usually takes up a considerable amount of space. Due to the fact that most
organisations calculate an amount of money per square meter, the price of an archive is
directly related to the size. Considering the fact that some organisations have archives in
the amount of a couple of kilometers, this is no longer a trivial sum.
2. Complete
An archive has to be complete at all times. This condition seems obvious, but in practice,
(paper) files get (temporarily) lost. Sometimes one employee has a file in his possession and
during that time it is not accessible for other employees. Sometimes it even seems lost for
other employees, so a new file is created.
3. Fast accessible
Accessing the archive is often a lengthy process slowing the total process down.
4. Simultaneous accessible
Often a file is needed by more than one employee at the same time. If a file is simultaneously
accessible by a random number of employees, parallel processing can take place, increasing
the throughput of the process.
When the organisation owns a strictly paper file, there are a number of possibilities to improve
the situation. To name but a few:
Enlarge the accessibility of the archive
This can be achieved in a number of ways. For example, the size of the archive can be
decreased by throwing everything away, that is not directly relevant. In some organisations
this can lead to a 90% reduction in archive size. Another possibility is the improvement
of the storage in a way that files are easier and faster to find. A lot of other solutions are
possible. But still the problem remains that when a file is in use by one employee, it can
not be accessed by another employee. Also the transport of the file takes up a considerable
amount of time. Next to that, a new document can not be accessed before it is stored in the
file. But, on the other hand, these measures are relatively low cost and will not cause many
changes in the organisation.
Formulate more strict rules for archive storage and retrieval
99
6.7. Causes
?
?
?
?
A. Information technology with
the system approach
?
B. Information technology with
the workflow approach
Figure 6.18: The Systems Approach versus the Workflow Approach
Switch over to micro-filming
Micro-filming only gives a solutions for the volume of the archive. Still files are not accessible
simultaneously and sometimes can get lost.
Switch over to imaging
Imaging seems the solution. Storage on optical discs is small, complete, relatively fast and
simultaneous accessible. There are also drawbacks in the form of costs. Not only is a optical
disk array quite expensive, but the existing network infrastructure is often not capable of
transporting this amount of information.
With respect to the organisations in the WA-12 research can be mentioned that all companies have
chosen to substitute their paper or micro filmed file by an imaging storing system.
6.7.6
Integration
One of the big advantages of workflow technology is the possibilities for integration. In current
practice, many organisations take the system as starting point. The information system is a
translation into automated procedures [BBS93]. Information systems which cross the borders of
departments or business units are often dominated by the interests of the individual organisational
entities. This leads to bad coordination and unnecessary complex systems. As a result of this,
sometimes employees have to work with different systems. This is shown in figure 6.18A. But
workflow technology can change this. This is shown in figure 6.18B. There is a clear relationship
between the input and the output. The workflow is again the central issue and all other systems
are tuned to this central stream.
This gives the motivation why ResLab adopted workflow technology. Previously, they had
different systems for the different activities which had to be executed when a new employee
was hired. Nowadays, thanks to the workflow system, all systems are connected and from one
workstation the total process can be executed.
6.7.7
Control over Process
Control is, next to tasks as planning, coordinating and guiding, a management task of increasing
importance. Control is above all a management task, which asks for adequate information supply.
When one strives for an adequate control over the process, a number of conditions have to be
fulfilled:
Management has to set measurable goals, so the execution of the process can be compared
with the desired situation.
The management responsible for the process should have the instruments to actually influence the process.
When applying a workflow system, both conditions can be facilitated. The system provides a lot
of information so the comparison between the actual and the desired situation can be made on a
100
real-time basis. The instruments for influencing the process are (depending on the used tool) also
available.
6.7.8
Quality of Data
Awareness
Incidental
results and improvements
Control
Continuous improvement
Improvement
Figure 6.19: The Continuous Process of Quality Care
In the manufacturing, service as well as in the governmental area the attention for quality has
grown in the last couple of years. More and more it is seen as an essential instrument for the
strategy of an organisation [BJ93]. The care for quality is only meaningful, if its part of an integral
approach. Integral means that it refers to all parts of the organisation, from high to low, and from
sell to sales.
Quality care should be a continuous process, as indicated by Deming and shown in figure 6.19
[BB87]. Information technology in general can be a great help in establishing a continuous quality
improvement process. First, information technology can facilitate the awareness of the quality
problem, by supplying significant data concerning the process. Secondly is information supply
inevitable when guarding the quality goals.
In quality two aspects can be identified; the external aspect and the internal aspect. The external
aspect refers to the way the customer defines the quality of a product and the internal aspect
refers to the way the organisation defines the quality of the same product. There can be great
differences between these two aspects. When the external quality perception and definition is
not continually sensed, there can be a huge gap between these two. Information technology can
reduce this danger, especially when one invests in analysing client wishes [BJ93].
The quality aspect was identified in two organisations, SocIns and MortIns. Both organisations
detected insufficient quality where the processed documents were concerned. The lack of quality
was mostly due to the fact that (paper) files were hard to access and the work pressure was to
big. The first cause is solved by introducing imaging, and the second cause will be solved by a
more structured way of working.
6.7.9
Management Information
With respect to the throughput problem, it was already mentioned that in seeking to exercise
control over (parts of) the organisation. Management will therefore use certain performance
measurements. Two forms of measurement which might be employed in exercising management
control of the operations function [Wil89]:
1. the use of behavioral controls, in which the actual behavior of the system is measured and
compared with a required standard as a means of providing the management with control;
2. the use of output control, in which the output of the system is measured and compared with a
standard so that the system can be controlled.
6.8. Logistic Principles and Workflow Automation
6.7.10
101
Malfunctioning System
Of course, the simple reason of a malfunctioning system at this moment can be the cause leading
to the development of a system. The old technology may have failed and workflow technology
offers possible solutions. This reason is encountered at only one organisation.
6.8 Logistic Principles and Workflow Automation
6.8.1
Introduction
A number of research studies show that logistic principles, initially developed for trading and
production companies, can also be applied to organisations which primary process has an administrative nature, like the organisations studied in the WA-12 research. This way, the new field
of workflow automation and workflow management can benefit from decades of experience in
logistics.
Due to changing environmental demands administrative organisations are forced to put more
emphasis on efficiency and effectivity. Especially non-profit organisations have not been very
familiar with these notions. This section describes the way in which these logistic principles can
be applied to an administrative process, or if you want so, a workflow. This will be done by
first discussing some basic notions concerning production management and logistics along with
the differences between service technology and manufacturing technology. This way, the logistic
principles can be put into perspective.
6.8.2
Definitions and Terms
In this paragraph a number of definitions and terms will be introduced. These are mainly
terms associated with the field of logistic and production management. The necessity of this
introduction is to gain an understanding of these disciplines.
General Terms
To provide a general introduction in production and logistic management, some general terms
will be introduced. These terms are derived from [Har92].
Primary process; The primary process is the process where a system is specially designed for.
Its goal is the production of one or more specific goods or services.
Order; An order is an instruction to deliver.
Working order; A working order is an internal translation of the order placed by the world
outside the system. In a manual environment it is the document that guides the order on
its way through the production process.
Process capacity; Process capacity consists of the means to prepare or process objects.
Queue; A queue is a container in a stream of objects. A queue is located between the input
and the output of objects. The input can be interpreted as a demand for capacity. When this
capacity is available, one or more objects are removed from the queue.
Stock; A queue is a waiting list where the offering of objects is also the supply of objects.
As soon as demand is available, the stock decreases. The (important) distinction between
queues and stocks will be discussed later in greater detail.
Passing time; The passing time of an order-driven production process is the time passing
between the placing of the order and the delivering of the product. Passing time consists of
three components:
102
– preparation time
– waiting time
– transport time
The rule: (preparation time) = (passing time) - (waiting time) - (transport time)
Waiting time; The waiting time is the time that a (half-)product is waiting to be prepared or
processed. Causes that lead to waiting time:
– there is not enough capacity available at the next preparation stop.
– there is need of raw material, half-products or information form others, which is not
yet available.
6.8.3
Preparation time; The time that a (half-)product is actually being prepared or processed.
Disconnection point; The disconnection point is the point in a production process that marks
the beginning of an order-driven production. When in a production process the disconnection process is passed, there is produced for specific orders. Before the disconnection
point there is production on stock. In a manufacturing company, the disconnection point
can principally be anywhere in the process. In an administrative organisation, the process
is most often triggered by the client. Therefore the disconnection point is at the beginning
of the workflow. This notion, which is very important in the manufacturing theory, plays a
minor role in administrative theory.
Service versus Manufacturing
Prototypical
Service Technology
Prototypical
Manufacturing Technology
2.
3.
Simultaneous production
and consumption
Customised output
Customer participation
4.
5.
Intangible output
Labor intensive
Goods inventoried for
later consumption
Standardised output
Technical core buffered
from customer
Tangible output
Capital intensive
Nr.
1.
Table 6.5: Service Technology versus Manufacturing Technology
As stated before, logistic principles are basically derived from manufacturing organisations. It
is therefore important to investigate the basic differences between manufacturing and service
organisations.
Characteristics
Service technologies are defined based on the on the five elements in table 6.8.3. The first
major difference is simultaneous production and consumption, which means a customer and
an employee interact to provide the service. This also means that customers tend to receive
customised output and that customers participate in the production process. In manufacturing,
by contrast, goods are produced at one time and inventoried for sale and consumption at another
time; outputs tend to be standardised, and the production process tends to be removed and
buffered from customers.
Another major difference is intangible output in a service firm. A service is abstract and often
consists of information or knowledge in contrast with the tangible physical products made by
manufacturing firms. This typically means service firms are labor intensive, with many employees
103
needed to meet the needs of customers, while manufacturing firms tends to be capital intensive,
relying on mass production and continuous process [Daf92].
Customer contact
The feature of service technologies with a distinct influence on organisational structure and control
systems is the need for technical core employees to be close to the customer. The differences
between service and product organisations necessitated by customer contact are shown in table
6.8.3.
Nr.
Structure
Service
Product
1.
2.
3.
4.
5.
6.
Separate boundary roles
Geographical dispersion
Decision making
Formalisation
Employee skill level
Skill emphasis
Few
Much
Decentralised
Low
High
Interpersonal
Many
Little
Centralised
High
Low
Technical
Table 6.6: Structural Characteristics of Service Organisations versus Product Organisations
The impact of customer contact on organisation structure is reflected in the use of boundary roles
and structural disaggregation. Boundary roles are used extensively in manufacturing firms to
handle customers and to reduce disruption for the technical core. They are used less in service
firms because a service is intangible and cannot be passed along by boundary spanners, so service
customers must interact with technical employees [Daf92].
A service firm deals in information and tangible outputs and does not need to be large. Its
greatest economies are achieved through disaggregation into small units that can be located
close to customers. Doctors’ clinics, fast-food franchises, consulting firms and banks disperse
their facilities into regional and local offices. Manufacturing firms, on the other hand, tend to
aggregate operations in a single area that has raw materials and an available work force. A large
manufacturing firm can take advantage of economics derived from expensive machinery and
long production runs.
Service technology also influences internal organisation characteristics used to direct and control
the organisation. For one thing, the skills of technical core employees need to be higher. These
employees need enough knowledge and awareness to handle customer problems rather than
just enough to perform a single, mechanical activity. Thus, service employees need social and
interpersonal skills as well as technical skills. Because of higher skills and structural dispersion,
decision making often tends to be decentralised in service firms, and formalisation tends to be
low. Employees located in the regional and local outlets of the service firm make decisions and
react on their own to customer problems.
Understanding the nature of service technology enables managers to adopt an appropriate structure that is often quite different from the structure for a product-based or traditional manufacturing technology.
6.8.4
Logistic Goals
Let’s turn back to logistics. According to [Har92], an important distinction can be made between
logistic applied as marketing instrument, aimed at realising external goals and logistics applied
for reducing costs, for realising internal goals.
The external goals are aimed at satisfying the demands of the environment. They are part of the
company strategy. Main goal is ’delivering in time’. On time in terms of delivery time as well as
reliability of delivery. An other important goal is flexibility; the power to anticipate to changes
in customer demands. This in terms of product specifications, quantities or delivery times. The
104
External goals
delivery
in time
Internal goals
legitimacy
reliability
efficiency
organization
information
technology
why
LOGISTICS
how
arrang. prim.
process
control
Logistic topics
Figure 6.20: Logistic Concept of an Administrative Organisation
production of high quality products is also an external goal, but primarily not of a logistic nature.
As stated before, internal goals are aimed at the realisation of the external goals at minimal costs.
Factors like the size of the stock, the occupation rate of the production means and the quality of
employers are very important.
6.8.5
Logistic Topics
Up til now, the logistic principles were mainly focused on trading and manufacturing organisations. Lately, logistic principles are associated with administrative organisations. With administrative organisations is referred to the combination of humans, means, procedures and structures
focused on the production of information products; products built from information and as such
valuable for the client [Har92]. The topics discussed here are illustrated by figure 6.20.
External Goals
As far as external goals are concerned, it is necessary to make a distinction between profit and
non-profit organisations. Just like a manufacturing company, the demands of the customer are
the starting point for the definition of the external goals. Non-profit organisations are not mainly
focused on ’delivery in time’ but also on the fulfillment of internal goals. This has the following
reasons. A non-profit organisation
mostly has a monopolistic position.
is not just focused on the client but also on other parties, like politics and society.
sometimes produces goods that don’t need a speedy delivery (e.g. tax forms, speed tickets).
Internal Goals
The internal goals are aimed at effectivity and efficiency. At this point there are no fundamental
differences between an administrative organisation and a manufacturing company. Both are
striving for efficiency and effectivity. In traditional administrative organisations the primary
process is almost totally executed by humans, with raw material consisting of - not tangible -
105
data. In a manufacturing company the production machines form a great part of the primary
process, which also processes - tangible - raw material. The central problem, from a logistic point
of view, finding the balance between external and internal goals, stays the same.
Arrangement of the Primary Process
The arrangement of the primary process is constituted by the physical characteristics and facilities,
as far as these are of direct influence to the manufacturing, moving and storing of goods. Examples
are found in machine capacities, transport means, storage capacities and product characteristics.
Questions that are important here are: In what way are machines grouped as manufacturing
sites? How is the optimal lay-out of the manufacturing site and storage determined?
In this area, the most prominent differences between an administrative organisation and a manufacturing organisation are:
The distinction between the primary process on one side and information processing in favor
of the control of this process on the other hand is much harder to make at administrative
organisations than at manufacturing organisations.
With the design of an information system at an administrative organisation and the associated structure of internal control measures, the aspect of logistics is not often considered. In
the primary process of a manufacturing company there is much more emphasis on doing
things right the first time (’zero defects’) and is the aspect of logistics considered, especially
through performance measurement and reliability.
In a manufacturing company, the output of every (sub)process is clearly visible, making
an inspection possible in the proceeding of the process. In an administrative organisation
it is often hard to determine whether an activity is performed or not. After inspection, a
signature is added, and it is hard to determine whether this inspection is performed well or
not. Under time pressure, that is when priority is given to logistic goals, the inspection for
quality and so the reliability of the products are risked. The logistic control at administrative
organisations can affect quality, especially when the activities of employees concerned with
assessment activities are a bottle-neck in the process.
Control
The aspect of control has impact on the way in which the primary processes are controlled
and guarded. Important questions are: What method is used to convert the sales expectations
and customer orders to a global production schedule? Where in the production process is the
disconnection point? What method is used to plan the process across the different departments
and production sites?
Within manufacturing companies, two types of control can be distinguished:
1. Material coordination, with the responsibility that every manufacturing department has the
right raw materials at the right time at hand, and
2. Capacity coordination, aimed at securing that for every activity the right capacities of man
and machine are available.
Within an administrative organisation materials coordination is translated into the question: how
can be secured that a department has all data necessary for a certain process in time? Capacity
coordination concerns appointing employees to work orders in a way that unless fluctuations in
the quantity of work, the throughput stays controllable.
106
Organisation
After the control structure is determined, it has to be implemented in the organisation. Important factors are: How does an effective coordination between different functional departments
assured? How can activities, authorities and responsibilities divided in an effective way? What
disciplines are important meet changing marketing demands?
De most important differences between administrative organisations and manufacturing companies is the level on which the logistic function is executed. In manufacturing companies, there
is not only more logistic know-how present, also a more systematic way of reporting about the
logistic status is applied.
Information Technology
In administrative organisations information systems are far less used for total logistic control
than in manufacturing companies. The present IT-infrastructure is often aimed at supporting the
work of a certain distinct department.
Logistic control is not possible without, and puts high demands on the information system.
This also concerns the total process of developing an information system, from first information
planning until implementation. In manufacturing companies an right arrangement of the manual
administrative processes play a crucial role in the acquisition of good and reliable information.
6.8.6
Logistic Modeling of the Process
The function of an operating system is a reflection of the purpose it serves for its customer, i.e.
the utility of its output to the customer. Four principal functions can be identified [Wil89]:
1. Manufacture
The first principal function is manufacture in which the principal common characteristic is
that something is physically created, i.e. the output consists of goods which differ physically,
e.g. in form or content, from those materials input to the system. Manufacture therefore
requires some physical transformation, or a change in form utility of resources.
2. Transport
Transport is the second principal function in which the common characteristic is that a
customer, or something belonging to the customer, is moved from place to place, i.e. the
location of someone or something is changed. The system uses its resources primarily to
this end, and such resources will not normally be substantially physically changed. There
is no major change in the form of resources, and the system provides primarily a change in
place utility.
3. Supply
Supply, in which the principal common characteristic is that the ownership or possession
of goods is changed. Unlike manufacture, goods output from the system are physically the
same as those input. There is no physical transformation and the system is primarily one
of change in possession utility of a resource.
4. Service
The last principal function is the service, in which the principal common characteristic is the
treatment or accommodation of something or someone. There is primarily a change in state
utility of a resource. Unlike in supply systems, the state or condition of physical outputs
will differ from inputs by virtue of having been treated in some way.
These four principal functions can together be used in describing all operating systems and
their sub-systems. They provide basic language for operations management and permit the
development of a detailed definition of an operating system.
107
An operating system is a configuration of resources combined for the function of manufacture,
transport, supply or service.
Building Blocks
C
Flow of work
Queue
Operation
Customer
Check/Decision
Figure 6.21: The Building Blocks for a Logistic Workflow
When the administrative process in an organisation is regarded as a logistic process, it can be
modeled and improved relatively easy. To model a workflow, five different symbols of ’building
blocks’ are used. These symbols are shown in figure 6.21.
Stocks and Queues
Demand
Stock
Input
Ouput
Supply
Queue
Input
Ouput
Figure 6.22: Stock and Queue
A very important difference to be made is the difference between a stock and a queue. The cause
initiating the existence of a stock or a queue is found in the bad momentane matching of supply
and demand of objects. This difference is shown in figure 6.22.
After a while the demand is not equal to the supply. The problems can be described in the
following way:
Stock situations require that a stock is exhausted and a supplier has to provide additional
objects. This means the customer has to wait. This should be exception rather than rule.
Central question is therefore: "How large should the stock be?".
Queue situations can cause the situation that a customer arrives in front of an empty counter
and can be served right at that moment. This is exception rather than rule. Usually one
has to wait a certain time, before one gets served. The central question is so "How long do
queues have to be and what does that mean for the serving capacity?".
In both cases, the output is given fact and the input is a variable. In an administrative organisation,
stocks will not be encountered frequently. This is due to the fact that the client initiates the process
and all products are more or less customer specific. This problem will be addressed in the next
two subsections.
108
C
Manufacture or supply, from stock, to stock, to customer
C
Manufacture or supply from source, to stock, to customer
C
Manufacture or supply, from stock, to customer
C
Manufacture or supply, from source direct to customer
Figure 6.23: Basic System Structures for Manufacture and Supply
C
Transport or service from stock, and from customer
C
Transport or service from source, and from customer queue
C
Transport or service from strock, and from customer queue
Figure 6.24: Basic System Structures for Transport and Service
6.8.7
Manufacture and Supply
When only manufacture and supply systems are considered, four simple structures can be identified as shown in figure 6.23 [Wil89]:
1. Make from stock, to stock, to customer
All input resources are stocked and the customer is served from a stock of finished goods.
2. Make from source, to stock, to customer
No input resource stocks are held, but goods are produced to stock.
3. Make from stock, direct to customer
All input resources are stocked but goods are made only against and on receipt of customers’
orders.
4. Make from source, direct to customer
No input stocks are held and all goods are made only against and on receipt of customers’
orders.
109
6.8.8
Transport and Service
A slightly different situation applies in both transport and service. Those structures which require
function in anticipation or in advance of receipt of a customer’s order are not feasible, since no
physical output stock is possible. For example consider a bus service. It cannot perform its
function of transporting individuals before those individual customers arrive.
One further important structural difference is evident in the case of transport and service systems.
Since the function of transport and service is to ’treat’ the customers, the customer is a resource
input to the system. The beneficiary of the function is or provides a major physical resource input to the
function [Wil89]. Thus transport and service systems are dependent on customers not only taking
their output and in some cases specifying what that output shall be, but also for the supply of a
major physical input(s) to the function without which the function would not be achieved.
In other words, unlike manufacture and supply, transport and service systems are activated or
’triggered’ by an input or supply, The customers exert some ’push’ on the system, in that they pull
goods out of the system whether direct from the function. In transport and service, the customer
push the system: they act directly on input. In such systems therefore, some part of the resource
input is not directly under the control of the operations management. In these ’push’ systems
the customers control an input channel. Somewhat different structures are therefore required to
represent transport and service systems. Three structures can be identified as shown in figure
6.24 [Wil89]:
1. Function from stock, and from customer
Input resources are stocked, except in the case of customer inputs where no queuing exists.
2. Function from source, and from customer queue
No input resources are stocked although customer inputs accumulate in a queue.
3. Function from stock, and from customer queue
In this structure all inputs are stocked and or allowed to accumulate in stocks.
6.8.9
Logistic Improvements
The purpose of logistic modelling is to gain better insight in the workflow and to improve
or streamline it, using relatively simple techniques. These techniques have been identified by
[OPBS93]. The effect of every technique is valuated with regard to the following criteria:
1. Throughput
2. Costs
3. Quality
4. Flexibility
The effect of the six streamline techniques is shown in table 6.7.
Before
1
After
1
2
3
3
Figure 6.25: Elimination of Workflow Activities (example)
110
Elimination
Integration
Broadening
Parallellisation
Inc. capacity
Inc. effectivity
+
+/o/+
+/o
+
+/o/+/o/+/o
+/o/o/+
+/o
+
+/o/+/o
+/o
+
+/o/+/o/+/o
+/o
+/o/+
+/o
Criterion
Throughput
Costs
Quality
Flexibility
Table 6.7: Effects of Improvement Techniques
Elimination of Workflow Activities
A very simple technique is the elimination of one or more process steps. This is shown in figure
6.25. Steps in a workflow can be eliminated whenever they are unnecessary or repeating.
Elimination of unnecessary activities
This kind of elimination is shown in figure 6.25. Examples of unnecessary workflow steps
that can be eliminated are a quality check, where always all products pass or a physical
transport, which can be done electronically. The elimination of an unnecessary step will
directly result in a reduction in the passing time. Capacity, which was used for this step,
can be used for another part of the process.
Elimination of repeating activities
Another possibility is the elimination of repeating steps in a workflow. When an organisation grows, sometimes the activities are not distributed efficiently throughout the organisation. For example mail which is sorted in every layer of the organisation, where it also can
be sorted at once in the mail room.
Before
1
2
2
3
+
4
3
=
After
1
3
4
Figure 6.26: Integration of Workflow Activities (example)
Integration of Workflow Activities
Another way to optimise the workflow is to integrate steps in the workflow. This can be done in
a number of ways. These will be described below.
Integrate the execution of a business activity
In case there are a number of dispersed activities which change the status of a certain file
or document, they can be integrated. For example, consider a letter, where a draft version
is made in one activity and a final version in an activity further down the workflow. Often,
this situation is a result of the growth of the organisation. These activities can be integrated.
This way, the throughput increases. But when the activities are supported by automated
means, the costs can increase, when these systems are altered.
111
Integrating (subsequent) workflow steps
This technique of integration is shown in figure 6.26. It can be applied in a situation where
there is over-specialisation. Every employee fulfills a tiny activity in the process. The
overhead time is to much in contrast to the total passing time of the product. This technique
will increase the throughput and decrease costs. Again, when automated means have to be
altered, the costs could increase.
Integrating decision points
When responsibilities are dispersed among a large number of people, this technique can
improve the situation. Every activity in the process is checked. Improvement can be gained
by executing this check only once, at the end of the workflow. In general, costs will decrease
and throughput will increase.
Before
1
After
1
2
3
6
3
6
4
5
Figure 6.27: Broadening of the Workflow (example)
Broadening the Workflow
There are situations in which broadening of the workflow offers possibilities to improve the
performance. These situations will be described here:
Dividing workflow steps into controllable parts
When a workflow activity has a long passing time, a proper control is not feasible. By
analysing and dividing an activity like that control possibilities will improve. Especially
quality will benefit from the better control position. Early notice of problems will improve
throughput as well.
Introducing checks and/or decision moments
This technique can be applied in combination with the previous. Introducing new decision
moments can terminate a workflow in an early stage. The introduction of a new activity
will have negative consequences for throughput and costs but quality and flexibility will
benefit.
Realising a by-pass
This broadening technique is shown in figure 6.27. When work arrival time is very irregular,
queues will get long. By introducing an optional by-pass, this problem can be solved. In
case of great work pressure, the by-pass can enlarge total processing capacity. Throughput
will benefit, but a by-pass will increase costs. Flexibility and quality will increase from this
technique.
Parallellisation of the Workflow
Parallellisation is a technique especially suitable for processes with a lot of case distinctions.
A different or better timed categorisation offers possibilities for improvement. The different
situations are described below.
112
1
3
4
5
6
Before
2
2
5
1
4
3
After
6
Figure 6.28: Parallellisation of the Workflow (example)
Changing rendez-vous points
This kind of parallellisation is shown in figure 6.28. In this process there are two possible
cases. One case has to pass activity 2, 3 and 5 and the other case has to pass the activities 1,
3, 4 and 6. Obviously, the second workflow layout is better then the first. Throughput will
benefit, so will quality.
Changing sequence by changing decision points
Sometimes, decisions in the workflow are more or less the same. For example, when one
decision determines if a loan is higher or lower that Al. 100.000 and another decision
distinghuises high and low risk loans. If practice learns that almost all loans higher that f.
100.000 are high risk, these decisions can be integrated and a parallel workflow results of
high risk loans higher that fl. 100.000. Again, throughput cost and quality will benefit.
Adding initial or final check
An initial check can be introduced to establish better case distinction. Activities in the
workflow after this decision can be executed parallel rather than sequential. The same
argument goes for final checks.
Eliminating/changing or adding of independencies
The growth of an organisation sometimes introduces dependencies between activities. One
activity can not be executed, when the other is not finished. Sometimes the activity does not
need any output of the previous activity to be executed. This kind of dependencies should
be eliminated.
Before
1
2
3
cap=10
After
1
2
3
cap=25
Figure 6.29: Increasing the Capacity of a Workflow Activity (example)
Increasing the Capacity of Workflow Activities
Enlarging processing capacity
When the execution of an activity should be faster, the capacity of the executing body should
be increased. Often this comes down to hiring more employees, or shifting capacities within
the organisation. Throughput will benefit, but costs will increase.
Increasing efficiency
Automated support of the execution of a certain step will increase capacity and increase
throughput. This has negative consequences for the costs.
113
6.9. Conclusions
Automating
This technique is shown in figure 6.29. Automated execution of a certain step will increase
capacity and increase throughput. This has negative consequences for the costs.
30 times
Before
1
2
60%
3
40%
30 times
After
1
2
3
40%
1 time
60%
Figure 6.30: Increasing the Effectivity of a Workflow Activity (example)
Increasing the Effectivity of Workflow Activities
The last improvement technique involves increasing the effectivity of workflow activities.
Concentrating the responsibility of business activities
Sometimes in an organisation, the responsibilities are not unambiguous. Different views
on how the process should be executed are applied. To simply put the responsibility in
the hands of one party, the execution of the workflow will benefit. Especially quality will
benefit.
Concentrate execution of workflow step
Also when the execution of a workflow activity is dispersed over two departments, there is
room for improvement. Every group will have its own method of working. When execution
is concentrated, the most efficient way of working can be applied. Quality will improve.
Standardising and separating of workflow independent activities
This situation is shown in figure 6.30. A particular activity can sometimes be divided
into a standard part and a case specific part. By introducing some sort of standardisation,
throughput will increase. A very well know example is the standard letter for some cases.
Eliminate steps with business activities
When all other activities did not have the desired effect, one should look at the character
of the activities. Are they really value-adding? If not, (part of) the activity should be
eliminated.
6.9 Conclusions
6.9.1
Organisation theory
The organisational typology of Mintzberg [Min79] forms the basis of the comparison of the
organisations in WA-12 with respect to organisational applicability. This comparison draws from
three sources: the coordination mechanisms distinguished by Mintzberg, the different types of
information systems identified by Leifer [Lei88] and the information collected about the WA-12
organisations. Leifer’s information technical approach aligns with the organisational approach
of Mintzberg.
Although the five organisational types as described by Mintzberg almost never occur in their
pure form, they do provide a framework in which structural characteristics of (administrative)
organisations can be compared.
114
The first type, the adhocracy, is based on mutual adjustment of the participating actors in the process. Information needs are not predefined and every system which imposes a formal structure
restricts the flexibility of the organisation. Structured workflow systems are therefore unlikely
candidates for the support of work in an adhocracy. The second type, the simple structure is
based on the coordination mechanism of direct supervision. The communication in this type of
organisation is informal. Most of the information interchange is between one manager and his
or her subordinates. Due to the informal, unformalized and centralized structure, this type of
organisation does not fit in the conceptual structure of workflow automation. The other three
organisational types are based on a coordination mechanism which imposes some kind of standardization. The third organisational type, the machine bureaucracy, is based on standardisation
of work. It offers opportunities for a lasting (possibly inflexible) information system. The prescribed procedure is encoded in the system and therefore flexibility is low. The fourth type, the
divisionalised form, realises coordination on basis of standardisation of outputs. Routing is very
important in this situation, because predefined products are communicated between workers. In
the professional bureaucracy, the fifth type, skills are standardised. When a workflow system is
introduced here, the danger arises that employees loose their freedom. The conclusion is that
organisations based on standardisation are the most suitable to be tackled by a workflow solution.
The different characteristics of these types must be reflected in the system.
Workflow systems can be realised both in centralised and distributed systems. In the last decade a
shift from centralised to distributed systems has taken place. A recent development is rightsizing,
which means that centralised solutions are returning to organisations. Standardisation based
organisations are the most suitable for a workflow solution.
Both the organisational and the information technical approaches are complemented by the
results of WA-12. As recent trends indicate are most systems based on a standardisation based
organisational type. Almost half the organisations were identified as a machine bureaucracy
and the other half as a professional bureaucracy. The divisionalised form is identified at one
organisation only. This is due to the fact that this type consists of a combination of the other
two types and the fact that the categorisation is made on a process level. Eight out of the twelve
organisations have a distributed system and the other four have a centralised system. These
empirical results do not contradict the theory of Mintzberg and Leifer.
6.9.2
Causes for Workflow Systems
Workflow systems have many different causes. External and internal causes can be distinguished,
depending on the type of goals that are identified. External goals are aimed at satisfying the
demands of the environment and internal goals are aimed at internal effectivity and efficiency.
External causes are the demand of higher throughput, more client focus and more flexibility.
Internal causes are the archiving problem, the desire for more control over the process, quality
of data, integration, a malfunctioning system or more management information. The archiving
problem is dominant; it was encountered in 46% of the organisations.
6.9.3
Logistics and Workflow Systems
Manufacturing processes and administrative processes differ on a number of structural characteristics. This has consequences for the way in which principles from one field can be applied in
the other. In manufacturing processes, the distinction between the production process and the
information system to control and coordinate this process is clear. In administrative organisations, this distinction is often hard to make, because both systems process information. Workflow
management can be used to separate the control and coordination mechanisms from the primary
process. This yields insight in the (primary) process, helping to realise the promised advantages
of flexibility and integration.
None of the 12 processes in WA-12 has been modelled in a logistic manner. This is due to the
fact that the situation before workflow automation was not quantified. The introduction of a
6.9. Conclusions
115
workflow system will have a lasting effect on future innovations, because workflow support
yields the quantitative information to assess future innovations in detail.
116
117
Chapter 7
Conclusions
Summary
The conclusions of WA-12 show that workflow support is feasible, both technically and businesswise. There are good examples of businesses that have successfully implemented a workflow
system and achieved important improvements.
Workflow management is still in an early phase, so there is still a lot to be learned.
7.1 Introduction
In this report, the workflow practice of four organisations has been studied, and comparisons
have been drawn on the topics of organisational applicability, workflow causes and the relation
with logistics. In this last chapter, the conclusions of this report are given.
The conclusions are presented in two parts. The first part gives general conclusions about
workflow management, based on the empirical results of WA-12 and literature. In the second
part the conclusions about applicability of workflow support in organisations are presented.
7.2 General Conclusions
7.2.1
Theory
Most of the publications about workflow management originate from suppliers, focusing on
tools and case studies in support of those tools. Workflow is an emerging technology, likely to
be presented as a panacea for all business problems. This is mostly because specific workflow
methods are unknown to analysts who are faced with the challenge to implement the “workflow
promise”. There is confusion about the meaning of terms that are used in workflow projects.
These, and other observations justify the conclusion that workflow support lacks a theoretical
basis.
A number of methods and techniques exist to support workflow (Action Workflow, DCE, Bull). In
practice, methods and techniques are often chosen by convention or by the availability of CASEtools. The methods used do not always focus on the important issues in a workflow analysis,
such as the triggering dynamics of the system. This justifies the conclusion that a methodological
gap exists between theory and practice.
Triggering of activities is apparently one of the key concepts in workflow support. Furthermore,
ill defined responsibilities appear to be an important source of problems in workflow projects. A
theory of workflow support should therefore focus on triggering, activities and responsibility of
actors. The concepts defined in chapter 3 are a result of this conclusion.
118
7.2.2
7. Conclusions
Technology
In many situations, workflow support and document imaging are an obvious and successful
combination.
Workflow technology needs a mature electronic communication infrastructure, especially when
it is combined with imaging.
Due to the fact that a workflow system is a combination of centralised control and local interactive
processing, it is ideally suited for a client/server architecture. Many organisations have the necessary workstation/LAN infrastructure already in place. Most of these use the PC workstations
with MS-DOS/MS-Windows. Most workflow tools support this type of client. Due to the fact
that client/server are conceptual notions, a system can also be implemented on a centralised or
mainframe system, although few workflow tools explicitly support character terminals.
7.2.3
Types of Workflow
During this study, a number of distinctions in workflow have been encountered. These distinctions are useful as a starting point for the development of taxonomies for workflow support.
Ad Hoc versus Structured Workflow
This distinction is a characteristic of the process. Ad hoc workflow does not dictate a particular
way of working. Every case is different. This kind of workflow is appropriate for situations where
the process of creating the product is not predefined and inhibits a lot of ’creating’ elements.
In structured workflow the procedure is programmed in the system, without exceptions. This
type of workflow is encountered in organisations where routine administrative work is processed
or when there are strict regulations (e.g. by law) to be followed.
Trends indicate that the distinction between ad-hoc and structured workflow tools is fading.
This development is motivated by the observation that work processes in practice are always a
combination of the two, although the balance can vary from ad-hoc to structured.
Procedural versus Logistic Workflow
A useful distinction with respect to the analysis of the work process is procedural versus logistic
workflow. This distinction is also phrased as task vs. route oriented workflow (InfTech). In
procedural workflow, the activities in a procedure are the central issue. The locations on which
these activities are performed are assigned to the activities. In logistic workflow, the workflow
is defined in terms of locations. The activities at these locations are performed manually or
programmed in separate applications. In general, logistic workflow can be used for routine work
which is performed in large quantities. Procedural workflow offers more flexibility, which makes
it more suitable to support work of a diverse nature. In most WA-12 cases, procedural workflow
is the appropriate choice.
DIS versus Workflow
Workflow automation is often confused with document imaging. Document imaging systems
(DIS) store documents and information about documents. Thus, it becomes possible to make
documents accessible on multiple locations. In contrast, a workflow essentially consists of work.
Documents can be a substantial portion of the work, but the difference remains a fundamental
one. The coordination of work (routing, notification, guarding deadlines) is the typical workflow
functionality.
DIS tools are currently evolving towards workflow by incorporating workflow functionality.
Workflow tools, on the other hand, are evolving towards easier integration with applications of
all kinds (including DIS).
7.3. Organisational Applicability
119
Technology versus Organisation
Workflow support can be approached from a technological perspective and from an organisational
perspective. A purely technological perspective is too limited because workflow projects integrate
the work of different people in different departments. This is more complicated than “ordinary”
automation that limits the human-computer interface to the interaction between one screen and
one person. On the other hand, WA-12 shows that the purely organisational perspective is too
limited as well. Workflow support is not yet mature enough to offer off-the-shelf solutions.
WA-12 has led to the conclusion that workflow support requires a combined technological and
organisational perspective.
7.3 Organisational Applicability
7.3.1
Organisation Theory
The organisational typology of Mintzberg [Min79] forms the basis of the comparison of the
organisations in WA-12 with respect to organisational applicability. This comparison draws from
three sources: the coordination mechanisms distinguished by Mintzberg, the different types of
information systems identified by Leifer [Lei88] and the information collected about the WA-12
organisations. Leifer’s information technical approach aligns with the organisational approach
of Mintzberg.
The first two organisational types are based on informal communication and will therefor not
benefit from the introduction of a workflow system.
The other three organisational types are based on a coordination mechanism which imposes some
kind of standardization. The machine bureaucracy offers opportunities for a lasting (possibly
inflexible) information system. The prescribed procedure is encoded in the system and therefore
flexibility is low. Within the divisionalised form routing is very important, because predefined
products are communicated between workers. In the professional bureaucracy, the last type, skills
are standardised. When a workflow system is introduced here, the danger arises that employees
loose their freedom. The conclusion is that organisations based on standardisation are the most
suitable to be tackled by a workflow solution. The different characteristics of these types must be
reflected in the system.
Workflow systems can be realised both in centralised and distributed systems. In the last decade a
shift from centralised to distributed systems has taken place. A recent development is rightsizing,
which means that centralised solutions are returning to organisations. Standardisation based
organisations are the most suitable for a workflow solution.
Both the organisational and the information technical approaches are complemented by the
results of WA-12. As recent trends indicate are most systems based on a standardisation based
organisational type. Almost half the organisations were identified as a machine bureaucracy
and the other half as a professional bureaucracy. The divisionalised form is identified at one
organisation only. This is due to the fact that this type consists of a combination of the other
two types and the fact that the categorisation is made on a process level. Eight out of the twelve
organisations have a distributed system and the other four have a centralised system. These
empirical results do not contradict the theory of Mintzberg and Leifer.
7.3.2
Causes for Workflow Systems
Workflow systems have many different causes. External and internal causes can be distinguished,
depending on the type of goals that are identified. External causes are the demand of higher
throughput, more client focus and more flexibility. Internal causes are the archiving problem, the
desire for more control over the process, quality of data, integration, a malfunctioning system or
more management information. The archiving problem is dominant; it was encountered in 46%
of the organisations.
120
7.3.3
7. Conclusions
Logistics and Workflow Systems
Manufacturing processes and administrative processes differ on a number of structural characteristics. This has consequences for the way in which principles from one field can be applied in
the other.
None of the 12 processes in WA-12 has been modelled in a logistic manner. This is due to the
fact that the situation before workflow automation was not quantified. The introduction of a
workflow system will have a lasting effect on future innovations, because workflow support
yields the quantitative information to assess future innovations in detail.
7.4 Recommendations
The experience of the twelve organisations has proven to be a unique source of empirical material
on workflow. The enormous amount of information resulting from the WA-12 subprojects can
serve as a foundation for a theoretical framework of workflow. However, aggregation to a more
general level is necessary to make the results explicit.
Based on the results of the WA-12 project a design method with special workflow modelling
techniques should be developed. This design method should not only be technology oriented,
but pay much attention to organisational aspects of workflow management. In developing this
design method a formal foundation must be taken as a starting point, and the lessons learned of
the WA-12 project can be used to detail the activities, and as a consistency check. This way, the
resulting method will be both formal and based on experience.
The relation between the situation of organisations (its processes and its IT infrastructure) and
the use of workflow and design tools can be investigated. Maybe it is possible to construct a
taxonomy decision for tool selection for new projects.
121
Appendix A
Research questions
Summary
In deze appendix worden de vragen gegeven, zoals ze gebruikt zijn in het WA-12 onderzoek.
Middels deze vragenlijst kunnen alle relevante gegevens achterhaald worden. Tevens kan
deze lijst dienen has handvat voor de selectie van de personen in de organisatie die voor dit
onderzoek geı̈nterviewed zouden moeten worden.
Onderstaande vragen dienen een indruk te geven van hetgeen wij in het WA-12 onderzoek van
belang achten. Tevens kunnen ze helpen bij het selecteren van de personen uit uw organisatie
waarmee het nuttig is een gesprek te hebben.
A.1 Algemeen / aanleiding
Wat verstaat de organisatie onder workflow-management (WFM)?
Welke afkortingen of andere termen worden gebruikt?
Voor welk doel is WFM ingezet?
Welke redenen hebben de organisatie doen besluiten WFM toe te gaan passen?
Is er gereageerd op problemen in de organisatie of wordt er geanticipeerd?
Hoe is het project afgebakend?
Welke administratieve processen worden belicht?
A.2 Beschrijving van het administratieve proces
Wat is het doel van het proces?
Welke stappen zijn te onderscheiden binnen het proces?
Wat zijn de activiteiten binnen het proces?
Wat zijn de informatiestromen binnen het proces?
Welke functionarissen voeren welke activiteiten uit?
Hoe was de besturing vooraf geregeld?
Waren er controlemogelijkheden, normen, normtijden?
Wat waren de knelpunten?
Welke doelen zijn gesteld voor het WFM-project?
A.3 Analyse en ontwerp
Is er een risico-analyse uitgevoerd?
Is ervaring opgedaan met WFM-pakketten?
122
A. Research questions
Welke criteria zijn gebruikt voor de keuze tussen WFM-tools en eventueel zelf bouwen?
Hoe ging de afstemming met gegevens- en activiteiten-analyse en -ontwerp in zijn werk?
Is er een methode gebruikt (of vaste procedure) bij het ontwerpen?
Zijn er activiteiten geschrapt of gecreëerd? Welke?
Is de volgorde van activiteiten aangepast? Hoe?
Kunnen bepaalde activiteiten nu parallel uitgevoerd worden?
Zijn verantwoordelijkheden voor taken verlegd? Hoe? Waarom?
A.4 Invoering in organisatie
Welke stappen zijn onderscheiden? Waarom?
Welke maatregelen zijn genomen om WFM in te voeren?
Is er een pilot-project geweest?
Welke moeilijkheden kwamen naar voren tijdens het experiment?
Welke maatregelen zijn genomen om deze moeilijkheden bij de grootschalige invoering
te voorkomen?
Is er schaduwgedraaid met het systeem?
Personeel
Welke functionarissen waren betrokken? Waarom?
Heeft de ontwikkeling binnenshuis plaats gevonden? Hoe?
Heeft een adviesbureau danwel een softwarehuis geparticipeerd? In welke mate?
Was er sprake van vraag vanuit het personeel om WFM in te voeren?
Waren gebruikers gemotiveerd om met het WFM-systeem te gaan werken?
Wat is er gedaan om tegenstanders te overtuigen?
Is er geluisterd naar de argumenten tegen invoering van WFM?
Is er voorlichting gegeven gegeven aan personeel (ook tijdens het begin van het project)?
Hoe zijn gebruikers enthousiast gemaakt voor WFM?
IT
Welke hardware was voorhanden?
Welke netwerken worden gebruikt?
Welke applicaties waren in gebruik?
Was er al enige integratie tussen bestaande systemen?
Welke koppelingen met bestaande systemen zijn gelegd?
Hoe is de afstemming met deze systemen aangepakt?
Welke (des-) investeringen hebben plaatsgevonden voor hardware en software?
Is er een beleid opgesteld voor toekomstige IT-investeringen?
A.5 Evaluatie van het WFM-systeem
Hoe denken de betrokken functionarissen over het systeem?
(Managers, ontwerpers, gebruikers, beheerders)
Zijn er nieuwe controlemogelijkheden ontstaan door WFM?
Heeft de invoering van WFM onvoorziene gevolgen gehad?
(technisch, financiëel, organisatorisch)
Heeft WFM effect gehad op de efficiëntie? Welk?
Zijn er al besparingente constateren? Welke?
Welke functionaliteiten van WFM worden gebruikt?
Welke worden gemist?
Welke zijn overbodig?
Hoe is de nazorg geregeld?
A.6. Evaluatie van het project
A.6 Evaluatie van het project
In welke mate zijn de gestelde doelen gerealiseerd?
Hadden de doelen van te voren beter vastgelegd moeten worden?
Zal WFM in de toekomst voor andere processen ingezet worden? Welke?
Zal dan volgens een bepaalde methode te werk gegaan worden? Welke?
Welke zaken zouden een volgende keer anders gedaan worden? Hoe? Waarom?
Welke zaken worden bij een volgend project op dezelfde manier gedaan? Waarom?
123
124
A. Research questions
125
Appendix B
Het WA-12 rapport van InfTech
Summary
In deze appendix is het gehele rapport bevat, voor zover dit het IT-2000 project, zoals bij
InfTech in ontwikkeling is betreft. Het gaat hier om het rapport zoals dat naar de betrokken
organisatie is opgeleverd, met dien verstande dat deze versie is geanonimiseerd; de naam van
de organisatie is veranderd, evenals persoonsnamen. Voor de rest is de inhoud van het rapport
onveranderd gebleven.
Dit rapport kent een andere structuur dan de overige rapporten uit het WA-12 project. Dit
vanwege het feit dat InfTech in eerste instantie als een leverancier van informatiesystemen
kan worden opgevat en niet als een gebruiker daarvan. Hierdoor heeft het rapport meer een
theorievormend karakter. Hoe kijkt InfTech tegen workflow aan en hoe werkt deze visie door in
een pilot-systeem? De vertaling naar een concreet proces zal weinig aandacht krijgen, hoogstens
met als doel de geschetste concepten toe te lichten.
Dit rapport kent een achttal hoofdstukken waarin het gehele IT-2000 project wordt beschreven.
Aan bod komen onder andere: de aanleidingen voor de ontwikkeling van dit systeem, het
verloop van het project en de projectorganisatie, het proces wat ten grondslag ligt aan het
systeem en de analyse van dit proces en het ontwerp van het systeem. Ook de implementatie
en invoering van het systeem evenals de evaluatie van het gehele traject komen aan bod. Het
rapport wordt afgesloten met conclusies en aanbevelingen.
B.1 Inleiding
B.1.1
Bedoeling van de tekst
In het kader van het WA-12 project wordt de toepassing van workflowsystemen in 12 organisaties
beschouwd. Het doel van dit onderzoek is inzicht te krijgen in het ontwerp en de invoering van
dit soort systemen. Dit rapport beschrijft de visie op workflow en -systemen van systeemontwikkelaar InfTech.
B.1.2
Bereik
In dit rapport zal getracht worden een zo volledig mogelijk beeld te schetsen van deze visie.
Hierbij komen zaken aan de orde als problemen die leiden tot een dergelijk systeem, analyse en
ontwerp van een workflowsysteem en de organisatorische consequenties van de invoering van
een dergelijk systeem.
B.1.3
Doelgroep
De doelgroep van dit rapport bestaat uit de betrokkenen bij InfTech en de onderzoekers van het
WA-12 project aan de Universiteit Twente. Er zullen twee versies verschijnen van dit rapport.
126
B. Het WA-12 rapport van InfTech
Een versie voor InfTech en een versie voor de universiteit.
B.1.4
Structuur
Dit rapport kent een andere structuur dan de overige rapporten uit het WA-12 project. Dit
vanwege het feit dat InfTech in eerste instantie als een leverancier van informatiesystemen kan
worden opgevat en niet als een gebruiker daarvan. Hierdoor heeft het rapport meer een theorievormend karakter. Hoe kijkt InfTech tegen workflow aan en hoe werkt deze visie door in een
pilot-systeem. De vertaling naar een concreet proces zal weinig aandacht krijgen, hoogstens met
als doel de geschetste concepten toe te lichten.
In dit rapport wordt de volgende structuur gehanteerd. In paragraaf 2 wordt een beschrijving
gegeven van het project. Paragraaf 3 gaat verder met een procesbeschrijving voor het pilotsysteem, waarna in paragraaf 4 dieper in wordt gegaan op de analyse van het proces en het ontwerp
van een systeem en de invloed van de verschillende pakketten op het uiteindelijke systeem. Paragraaf 5 gaat over de invoering en het geheel wordt afgesloten met paragraaf 6, waarin conclusies
worden getrokken en aanbevelingen worden gedaan.
B.1.5
Terminologie
In dit rapport wordt zo veel mogelijk de terminologie van InfTech en Pallas Athena gehanteerd.
Deze wordt hieronder beschreven.
Afkortingen:
BUW Basic Unit of Work; de kleinste eenheid ’werk’, dat in een workflow kan worden
onderkend
InfTech Een Nederlands bedrijf wat diensten levert op het gebied van de Informatie Technology
WFM Workflow Management
Begrippen:
Workflow Management
Het principe dat bij de afwikkeling van een taak automatisch één of meerdere taken in
een procedure aan een of meerdere mensen wordt toegewezen. De bij een taak behorende
informatie wordt hierbij gerouteerd.
Image
De digitale weergave van één pagina in het systeem
Rol
Een rol is een bepaald autorisatieniveau. Een rol kan door een of meerdere personen vervuld
worden.
B.2 Projectbeschrijving
B.2.1
Probleemomschrijving
Zoals in voorgaande paragraaf al beschreven is, worden de klanten van InfTech met veranderende
markteisen geconfronteerd. Waar vroeger de situatie bestond dat mensen verplicht waren zich
bij een bepaalde ziektekostenverzekeraar aan te sluiten, nu moet iedere organisatie voor zijn
eigen bestaan vechten. Deze concurrentiedruk leidt ertoe dat er efficiënter en meer servicegericht
gewerkt moet worden.
Op dit moment worstelen veel klanten met het papierprobleem. Dossiers van verzekerden zijn
vaak moeilijk vindbaar of zelfs onvindbaar. Aangezien er sprake is van full-case handling treden
127
B.2. Projectbeschrijving
problemen op in verband met het verschil in ervaring de verschillende doorlooptijden en bij
vakantie van medewerkers. Duidelijk zal zijn dat dit een probleem is, indien de organisatie
ernaar streeft klantvriendelijker en doelgerichter te werk te gaan. Men heeft de workflow aanpak
gekozen als middel om in de toekomst deze eisen te kunnen voldoen.
B.2.2
Workflow bij InfTech
Workflowvisie
Door InfTech is het Eindhovense workflow-adviesbureau Pallas Athena ingeschakeld om de
expertise op het gebied van de workflow en het workflow management in te brengen. Vandaar
dat InfTech de workflowvisie van dit bedrijf heeft geadopteerd. In het vervolg zal dan ook
gesproken worden over InfTech/Pallas Athena. In deze paragraaf wordt deze workflowvisie
beschreven aan de hand van figuur B.1.
Logistic workflow
D
A
B
C
C
A
Procedural workflow
A
Step B
1
2
3
4
5
6
7
Figure B.1: De workflowvisie van de InfTech/Pallas Athena
Essentieel in de InfTech/Pallas Athena visie op workflow is het onderscheid in een:
Logistiek aspect en een
Procedureel aspect.
Logistieke workflow
Wanneer er in de praktijk en de literatuur over WFM gesproken wordt, dan heeft men dikwijls
slechts het logistieke aspect voor ogen. Het logistieke aspect heeft betrekking op workflowmanagement, het verplaatsen van de informatie van de ene werker naar de andere. Figuur B.1
licht dit toe. Horizontaal wordt de logistieke workflow uitgezet. Het is hier niet van belang
wat de elementen A tot en met D, waaruit de workflow is samengesteld, voorstellen. Ze zullen
aangeduid worden met rollen. Een belangrijke taak van een workflowsysteem is het verplaatsen
(routeren) van informatie tussen deze rollen.
128
Procedurele workflow
Maar met WFM is meer mogelijk. WFM is namelijk ook in staat om zaken te regelen met
betrekking tot de uitvoering van activiteiten, ongeacht het feit of de informatie van de een naar
de ander gaat. Dit wordt aangeduid met het procedurele aspect van de workflow; het sturen
en coördineren van de activiteiten die per individuele werker worden uitgevoerd. Bij nadere
bestudering van de activiteiten die door bijvoorbeeld B worden uitgevoerd, de procedurele
workflow, vallen de overeenkomsten op met de logistieke workflow. De elementen 1 tot en
met 7 stellen dan echter (deel)handelingen voor. InfTech/Pallas Athena heeft onderkend dat de
taken die binnen een rol worden uitgevoerd ook door het workflowsysteem ondersteund kunnen
worden. Het komt er dus op neer dat iedere stap in een workflow op zijn beurt weer een workflow
is van kleinere stappen.
Workflow in meer dimensies
Deze overeenkomst tussen de logistieke en procedurele workflow is door InfTech/Pallas Athena
onderkend. Kijkend naar de logica en de besturingsmogelijkheden van het verticale (procedurele)
systeem kan geconstateerd worden dat dit (in grote lijnen) hetzelfde is als de ondersteuning van
het logistieke traject. Volgens InfTech/Pallas Athena zit hem hier juist de meerwaarde van het IT2000 systeem. In de praktijk wordt de routering door de meeste systemen gedekt, maar juist in de
ondersteuning van de procedures schieten ze tekort. Door de besturingslogica uit de applicaties
te halen, kan een bibliotheek van modules gecreëerd worden. Een nieuwe procedure kan dan
geconstrueerd worden uit de reeds bestaande modules. Dit heeft een hoge mate van flexibiliteit
en efficiëntie bij de wijziging van het systeem tot gevolg.
Basic Units of Work
Het aanwenden van besturing ten behoeve van de procedurele workflow, geeft aan dat de activiteiten die binnen een rol worden uitgevoerd centraal staan. Dit roept de vraag op hoe de
opdeling in (deel)activiteiten gedaan moet worden. Iedere willekeurige stap in de procedurele
workflow is weer op te delen in kleinere activiteiten. De opdeling in kleinere activiteiten kan bijna
tot in het oneindige doorgaan. De vraag staat dan ook centraal: welke opdeling is nog zinvol?
Hier is geen eenduidig antwoord op te geven. Het verschilt erg per organisatie. Het algemeen
gehanteerde criterium berust hierop dat je zover moet gaan dat de besturing gebruikt wordt zodat
op operationele veranderingen ingespeeld kan worden. Dit houdt in dat er zover moet worden
opgedeeld dat er een duidelijk moment van bezinning is na het afronden van een activiteit; welke
activiteit wordt nu ondernomen? In dit rapport worden dergelijke activiteiten aangeduid met Basic Units of Work (BUW). Denk bijvoorbeeld aan het controleren van iemands aanvraagformulier.
Is dit gecontroleerd en zijn de gegevens incompleet of incorrect dan volgt daaruit als volgende
activiteit het schrijven van een brief teneinde deze gegevens aan te vullen. Het is natuurlijk niet
zinnig om bijvoorbeeld een activiteit als het schrijven van een brief op te delen in deelactiviteiten,
zoals het opstarten van de tekstverwerker, het laden van een standaardtekst, etc.
B.2.3
Typen workflow
Al naar gelang de aard van de processen onderscheidt InfTech/Pallas Athena drie typen workflow
of -omgevingen:
1. Ad hoc workflow
2. Gestructureerde workflow
3. Flexibel gestructureerde workflow
Deze typen workflow zullen hieronder besproken worden.
129
soort workflow(omgeving)
ad hoc
gestructureerd
flexibel gestructureerd
instantiaties van het proces
enkele per
jaar
veel
veel
laag
hoog
hoog
ieder geval
is uniek
geen
veel
gestructureerdheid van het proces
uitzonderingen op het proces
Table B.1: De drie verschillende workflow(omgevingen)
Ad hoc workflow
In omgevingen waar veel ad hoc werk plaatsvindt of werk dat slechts enkele keren per jaar
plaatsvindt, treft men dikwijls ad hoc workflow aan. Denk bijvoorbeeld aan een staforganisatie.
Processen zijn veelal door de eindgebruiker zelf gespecificeerd. De eindgebruiker beheert het
proces en participeert, meestal als initiator, in het afhandelen van het proces. Het proces is vaak
informeel. Er wordt weinig of geen aandacht besteed aan efficiëntie, effectiviteit, etc. In bijna
alle gevallen is er sprake van een proces waarin in een bepaalde volgorde meerdere gebruikers
informatie bekijken en/of informatie toevoegen. In het algemeen werken er meerdere personen
aan een geval. Voorbeelden zijn review-processen en processen waarin een document wordt
gecreëerd (bijvoorbeeld een produktfolder). Kenmerken zijn dat elk geval anders is en dat er
weinig of geen regels zijn [Bul93].
Gestructureerde workflow
Het gestructureerde type workflow treft men aan in administratieve omgevingen waar de processen goed gedefinieerd zijn. Ze bevatten weinig of geen uitzonderingen. Meerdere medewerkers, vaak complete afdelingen, zijn beschikbaar om een bepaald type proces te behandelen. In een
gestructureerde omgeving zijn er per proces veel gevallen. De eindgebruiker participeert in de
afhandeling van de gevallen. De definitie van de processen vindt meestal onder leiding van een
organisatiedeskundige plaats, daarbij ondersteund door eindgebruikers, managers van eindgebruikers en/of automatiseringsdeskundigen. De gevallen per proces zijn alle min of meer gelijk.
Uitzonderingen komen weinig voor. Een voorbeeld van een gestructureerde omgeving is de
afhandeling van eenvoudige schades, zoals ruitschades. Een ander voorbeeld is de afhandeling
bij een zorgverzekeraar van declaraties van zorgverleners, zoals tandartsen [Bul93].
Flexibel gestructureerde workflow
Het flexibele type workflow ondersteunt de werkprocessen, die weliswaar goed gedefinieerd
kunnen worden en tevens vaak worden uitgevoerd, maar waarbij er sprake is van uitzonderingen.
Die uitzonderingen bestaan vaak uit het overslaan van stappen, het opnieuw uitvoeren van
stappen, het verwerken van extra informatie die soms in een laat stadium binnenkomt etc. Toch
zijn de uitzonderingen gereguleerd: ieder geval van een proces is anders, maar lijkt toch op
de andere gevallen. Per proces zijn er in deze omgeving veel gevallen. De eindgebruikers
participeren niet slechts en een geval, maar sturen ook een geval, natuurlijk binnen de grenzen
van de vastgelegde procedure. Zij bepalen of er extra informatie gevraagd moet worden, of er
stappen overgeslagen moeten worden, of het geval ter beoordeling aan een andere collega moet
worden voorgelegd etc.
Zoals in de gestructureerde omgevingen vindt de definitie van de processen veelal plaats onder leiding van een organisatiedeskundige. Maar hier is sprake van een gecompliceerd, langdurig proces omdat met name de uitzonderingen in kaart gebracht moeten worden. De meeste bestaande
beschrijvingsmethoden voor administratieve processen houden met die dynamische aspecten
130
geen rekening. Een voorbeeld van een flexibel gestructureerde omgeving is schaderegeling voor
autoschades, waar zaken als meerdere getuigen, letsel, meerder partijen, politie- en expertiserapporten een rol spelen [Bul93].
Toepassingen
In bovenstaande onderverdeling is gekeken naar de types van workflow(omgevingen). De term
workflow bestrijkt een breed toepassingsgebied. Daarbij is geen onderscheid gemaakt tussen de
procedurele en logistieke aspecten van de processen. Dat onderscheid maken we in paragraaf
analyse en ontwerp. In die paragraaf zal in worden gegaan op het type pakket dat algemeen
toepasbaar is in één van de drie omgevingen. De meeste pakketten ondersteunen slechts een
beperkt deel van één type omgeving.
B.2.4
Voor- en nadelen
Voordelen
De bovenstaande visie tracht InfTech/Pallas Athena terug te laten komen in het IT-2000 project.
Klanten zijn erg geı̈nteresseerd in deze workflowbenadering, daar duidelijk is dat een dergelijke
aanpak toepasbaar is op hun organisatie. Het leidt ertoe dat een workflow-systeem uiteindelijk
de volgende voordelen kan gaan bieden:
Verkorting van de doorlooptijden
Door een geautomatiseerde routering en werkverdeling worden onnodige vertragingen uit
het proces verwijderd. Er is nog zeer weinig tijd nodig voor het transport van informatie.
Met behulp van rappeleringsfuncties en monitoropties kan de doorlooptijd worden bewaakt
en verkort.
Minder fouten
Daar kleinere delen van het proces door het systeem worden gestuurd, kan na iedere
BUW een correctheidscontrole door het systeem worden ingebouwd. Daarnaast zorgt de
digitalisering van de papierstroom ervoor dat dossiers niet langer zoek kunnen raken.
Verhoogde produktiviteit
Mede door verkorting van de doorlooptijd, zal de produktiviteit verhogen. Meer dossiers
kunnen worden afgehandeld in dezelfde tijd.
Verhoogde service
Door het direct beschikbaar zijn van de gegevens van een verzekerde kan, bij vragen, direct
de juiste informatie bij het systeem worden opgevraagd. Nieuwe produkten en diensten
kunnen op een gemakkelijke manier aan het systeem worden toegevoegd, zodat de service
naar de klanten toe kan worden verhoogd.
Verlaging van de kosten
Kostenverlagingen zijn terug te vinden in arbeidskosten, daar door de verhoogde produktiviteit meer dossiers met hetzelfde aantal medewerkers kan worden behandeld. Daarnaast
treden besparingen op door minder papierverbruik, minder printerkosten en zelfs minder telefoonkosten, daar verzekerden direct bij vragen geholpen kunnen worden en niet
teruggebeld hoeven te worden.
Verhoging van het werkplezier
Door het zoekraken van dossiers en het niet tijdig beschikbaar zijn van benodigde informatie, kunnen medewerkers gefrustreerd raken. Dit is verleden tijd. Medewerkers hebben
altijd en gelijktijdig toegang tot de gegevens betreffende een verzekerde. De werkdruk
wordt verlaagd en een verhoging van het werkplezier zal een resultaat daarvan zijn.
131
Verlaging van de kwetsbaarheid
Het proces wordt robuster en daardoor minder kwetsbaar voor storende invloeden van
buitenaf. Indien een medewerker ziek is, betekent dit niet dat zijn zaken niet meer behandeld kunnen worden, of dat een dossier, wat zich op zijn bureau bevindt niet meer
toegankelijk is.
Daarbij komt dan ook nog dat integratie met de bestaande systemen mogelijk is. Er is dus sprake
van value adding en asset protection. Hieronder wordt verstaan dat het workflow systeem echt
waarde toevoegd aan de bestaande organisatie (value adding) zonder dat dit ten koste gaat van
reeds gedane investeringen (asset protection). Tevens wordt er met WFM een communicatiekloof gedicht. Voor het eerst zitten (noodzakelijkerwijs) informatie-analisten, eindgebruikers en
organisatiedeskundigen rond de tafel. Dit levert spanningen op, maar ook heel interessante
resultaten. In het verleden ging dat anders. Door de informatie-analisten worden bijvoorbeeld
SDW-AO schema’s opgesteld, die voor de overige betrokkenen niet gemakkelijk toegankelijk
waren. Afgezien van het feit dat InfTech/Pallas Athena meent dat dergelijke schema’s niet die
informatie leveren die nodig is voor het realiseren van een succesvol systeem wordt al snel de
betrokkenheid en het commitment verloren bij diegenen die er later mee moeten werken.
Gevaren
De toepassing van WFM is echter niet geheel zonder gevaren. Bij onzorgvuldige toepassing
kunnen de volgende problemen zich voor gaan doen:
Verstarring van procedures
In principe dicteert het systeem de gang van zaken en de volgorde waarin activiteiten binnen
een procedure worden uitgevoerd. Hoewel het workflowsysteem de nodige flexibiliteit
biedt, is het voor de individuele werknemer niet gemakkelijk ad hoc af te wijken van de
door het systeem voorgeschreven volgorde waarin hij zijn activiteiten dient uit te voeren.
Te veel lopende band werk
Indien werknemers zeer kleine delen van de totale procedure in grote hoeveelheden moeten
gaan uitvoeren ontstaat lopende band werk. Hierdoor neemt de motivatie en de arbeidsvreugde af.
Te veel management controle
Het bekende ’big brother is watching you’-verschijnsel. In principe kan iedere werknemer
gecontroleerd worden met betrekking tot zijn of haar activiteiten. Dit wordt meestal niet
als positief ervaren en kan leiden tot spanningen op het werk.
Onderschatting van de huidige procedures
De uitvoering van procedures blijft mensenwerk. Formalisering en modellering is niet in
alle gevallen mogelijk. Men moet daarom ook waken voor over-automatisering. In het
systeem moet ruimte zijn voor de handmatige uitvoering van bepaalde taken.
Geen weg terug
De invoering van een workflow management-systeem is behoorlijk ingrijpend voor de
organisatie. De traditionele papierstroom wordt afgeschaft en men gaat over op images. De
werkverdeling gebeurt in het vervolg electronisch. Na het doen van de nodige investeringen
in apparatuur, opleidingen en structurele veranderingen is het praktisch onmogelijk terug
te keren naar de traditionele manier van werken.
Het zal duidelijk zijn dat de gevaren die hierboven geschetst zijn een obstakel kunnen vormen
voor invoering en acceptatie van het systeem. Door gedurende de ontwikkelfase op een aantal
punten te letten kan de kans op het ook daadwerkelijk uitkomen van deze gevaren worden
geminimaliseerd. Hiertoe dient men:
132
Een zorgvuldig vooronderzoek uit te voeren
Voorafgaand aan het project moet een grondig onderzoek worden uitgevoerd. Hierbij
komen vragen aan de orde als: Welke processen zijn geschikt voor een workflowaanpak?
Welke resultaten kan een organisatie verwachten bij de invoering van een dergelijk systeem?
Wat zijn de veranderingsprocessen waar rekening mee gehouden moet worden?
Formele en informele circuits in kaart te brengen
Het is zeer belangrijk te ontdekken hoe de communicatie binnen een bedrijf verloopt. Het
niet aansluiten van het systeem op de communicatiestructuur van de organisatie zal het
succes in de weg staan. De formele circuits zijn meestal bekend en liggen ten grondslag aan
de organisatiestructuur. Daarentegen met het belang van de informele circuits echter niet
onderschat worden. Het is dan ook belangrijk alle communicatiecircuits in kaart te brengen
alvorens met de ontwikkeling van het systeem aan te vangen.
Met een multi-disciplinair team werken
De ontwikkeling van het systeem moet een breed draagvlak vanuit de organisatie hebben.
Het is daarom aan te raden om zowel organisatiedeskundigen, automatiseerders, eindgebruikers als middle management in de werkgroep op te nemen.
Een evolutionaire manier van ontwikkelen te hanteren
Tijdens de ontwikkeling dient er steeds teruggekoppeld te worden naar de gebruikers.
Veranderingsvoorstellen van die gebruikers dienen ook serieus genomen te worden. Op
ieder moment dient er sprake te zijn van een werkend, net persé compleet, systeem. Alle
betrokkenen zien dat het werkt, en daar zij dit direct kunnen relateren aan hun huidige
manier van werken, kunnen zij nuttige suggesties voor verbetering aandragen.
Het definitieve procedure ontwerp pas na de keuze van de oplossing te maken
De middelen waarmee het uiteindelijke systeem gerealiseerd gaat worden heeft veel invloed
op het procedure ontwerp (zie paragraaf B.4.2). Voordat dit ontwerp dan ook definitief
gemaakt wordt moet de oplossing bekend zijn.
Met een pilot of fall-back scenario te werken
In de vorige paragraaf is het gevaar geschetst dat er geen weg terug is bij de invoering van een
dergelijk systeem. Het is daarom belangrijk hier de nodige zorgvuldigheid te betrachten.
Door het uitvoeren van een pilot kan vroegtijdig en met beperkt risico inzicht worden
verkregen in de problemen die optreden bij de invoering van een workflowsysteem. Indien
ervoor wordt gekozen het systeem company wide in te voeren dient een fall-back scenario te
worden opgesteld, voor het geval de invoering van het systeem mislukt.
B.2.5
Projectafbakening
Het IT-2000 pilotproject bij InfTech/Pallas Athena is gericht op leren en ervaring opdoen. Het
ontwikkelen van concepten. Het project moet echter wel operationeel zijn. Het moet echt met het
mainframe intergreren, het moet echte programmatuur zijn en het moet realistisch zijn. Het moet
werken en demonstreerbaar zijn, maar het hoeft niet af te zijn in die zin dat alles daarin geregeld
is op de manier waarop dat uiteindelijk de bedoeling is. Als er zich situaties voor doen, waarin
meer van hetzelfde wordt vereist, wordt één zo’n geval in het systeem gerealiseerd. Het project
is pas af als de technische en functionele evaluatie op papier staan. Men is op dit moment bezig
met de technische evaluatie. Het programmeerwerk is klaar. Een andere medewerker is bezig de
training op te zetten aan de hand waarvan InfTech medewerkers in staat zullen zijn dit systeem
bij de klant te maken.
B.3. Procesbeschrijving
133
B.3 Procesbeschrijving
B.3.1
Doel
De pilot, zoals die bij InfTech ontwikkeld wordt speelt slechts een ondergeschikte rol in dit
rapport. Het dient hoogstens ter illustratie van de beschreven workflowvisie. In deze paragraaf
zal kort in worden gegaan op het proces zoals dat ten grondslag ligt aan de IT-2000 pilot.
Het doel van het proces is het in- en uitschrijven van verzekerden, evenals het aanbrengen van
wijzigingen in de gegevens van een verzekerde. Het proces vindt plaats bij een ziektekostenverzekeraar ergens in Nederland. Van dit proces wordt een summiere beschrijving gegeven, daar
het niet direct van belang is voor de workflowaanpak van InfTech/Pallas Athena.
B.3.2
Voorwaarden
Bij de beschouwde klant is sprake van full-case handling. Dat wil zeggen dat een dossier van een
verzekerde wordt toegewezen aan één medewerker. Deze medewerker voert alle handelingen uit
met betrekking tot dit dossier. Na de toewijzing van een dossier is dus altijd bekend wie de behandelend medewerker is. Een voorwaarde aan dit proces is dus dat iedere medewerker, ongeacht
zijn ervaring, alle handelingen op een dossier moet kunnen uitvoeren. Hierdoor ontstaan problemen door verschil in ervaring en daardoor verschillende doorlooptijden, vakanties, etc.
B.3.3
Controlemaatregelen
De controlemogelijkheden zijn op dit moment minimaal. Weliswaar is te allen tijde bekend
door welke medewerker welk dossier behandeld wordt. Het stadium, waarin dit dossier zich
bevindt is echter onbekend. Door navraag te plegen bij een medewerker kan hierover opheldering
worden verkregen. Bij ziekte van de betreffende medewerker kunnen vragen of wijzigingen met
betrekking tot die cliënt niet of met veel moeite behandeld worden.
B.3.4
Functies
In het proces bij deze verzekeraar zijn als functies te onderkennen:
Postkamer
In de postkamer wordt alle post ontvangen. Tevens wordt de bestemming van de post
bepaald binnen de organisatie.
Mutalist
De mutalist behandelt de post. Deze post kan een bijvoorbeeld aanvraag voor een verzekering zijn, een declaratie, een wijziging in de gegevens van de verzekerde of een uitschrijving.
Chef
De chef heeft als functie de dossiers toe te wijzen aan een bepaalde mutalist, en controle uit
te oefenen op de algehele gang van zaken.
B.3.5
Procesverloop
In deze paragraaf wordt de nieuwe situatie geschetst en de veranderingen die er optreden ten
opzichte van de oude situatie. Dit wordt geı̈llustreerd aan de hand van figuur B.2.
Oude situatie
Alle post komt binnen in de postkamer. Hier wordt de post gescheiden in post die wel betrekking
heeft op de cliënten en overige post. De post met betrekking tot de cliënten wordt via de interne
134
SITUATIE NU
SITUATIE IN DE PILOT
postkamer
postkamer
il
il
ma
ma
il
ma
l
ai
m
chef
onervaren
mutalist
mutalist
ervaren
multalist
chef
Figure B.2: De oude situatie en die in de pilot
post doorgestuurd naar de chef die de post, afhankelijk van de cliënt naar een bepaalde mutalist
gestuurd. Er wordt geen onderscheid gemaakt in ervaren en onervaren mutalisten.
De manier waarop het proces nu gestructureerd is, is niet optimaal. De doorlooptijd van een
document (wijziging, aanvraag, klacht, etc.) laat te wensen over. Duidelijk is dat er veel tijd
verloren gaat door de interne post en de werkverdeling door de chef van de afdeling. De
controlemogelijkheden van de chef zijn minimaal en beperken zich tot visuele inspectie. Doordat
er geen onderscheid wordt gemaakt tussen moeilijke en gemakkelijke gevallen en ervaren en
onervaren mutalisten is de doorlooptijd niet constant. Er is duidelijk ruimte voor verbetering.
Situatie in de pilot
In de nieuwe situatie is de papieren documentenstroom vervangen door een imagesysteem. De
post wordt in de postkamer gescand en electronisch doorgestuurd naar de onervaren mutalist. Deze behandelt de post voor zover hij daartoe bevoegd is. De moeilijke gevallen worden
doorgestuurd naar de ervaren mutalist.
De chef maakt geen onderdeel meer uit van de documentenstroom, maar heeft wel inzicht in de
doorlooptijden en werkvoorraden. Hierdoor wordt een vertragende stap uit het proces verwijderd. Er worden hem mogelijkheden geboden om in te grijpen in het proces. Zo kan, bijvoorbeeld
in geval van ziekte, een dossier aan een andere mutalist worden toegewezen. Knelpunten en ondercapaciteiten kunnen vroegtijdig worden opgespoord.
B.4 Analyse en ontwerp
Doel van dit hoofdstuk is een beschrijving te geven van het traject van analyse van het proces en
het ontwerp van het systeem. Bij InfTech/Pallas Athena is WFM gebruikt om de werkverdeling
te doen, zonder dat de oplossing voor de ontsluiting en logistiek problemen oplevert. De imaging
B.4. Analyse en ontwerp
135
techniek is toegevoegd, om dossiers gelijktijdig toegankelijk te maken voor verschillende medewerkers. Tegelijkertijd is er ook geanticipeerd op problemen die op dit moment niet nijpend zijn.
Door efficiënter en slagvaardiger te werk te gaan worden niet alleen de kosten verlaagd, maar
men kan in de toekomst snel inspelen op de veranderende eisen in de markt. Dit verstevigt de
marktpositie.
B.4.1
Eisen
Bij de introductie van WFM wordt geen verandering gebracht in de situatie dat iedereen alles
doet. Er wordt wel onderscheid gemaakt tussen ervaren en onervaren werknemers. De onervaren
mensen doen dat deel van het proces dat weinig ervaring vereist en de ervaren mensen dat
deel wat meer ervaring vereist. Een dossier wordt in de nieuwe situatie dus door minstens 2
personen behandeld. Zelfs 3 als de postkamer wordt meegeteld. Ze hebben daar geen logistieke
problemen. Het zou ondoenlijk zijn om het hele proces in stukken te hakken ieder deelproces aan
een medewerker toe te kennen. De verandering die nu is doorgevoerd is voor deze organisatie
al een grote verandering.
B.4.2
Tools
In de vorige paragrafen is een onderscheid gemaakt tussen logistieke en procedurele workflow.
De logistieke workflow beschrijft de routering door de organisatie, en de procedurele workflow
beschrijft de taakondersteuning bij de verschillende rollen in het proces. Tevens is er een onderscheid gemaakt tussen de gestructureerde en flexibele workflow(omgeving). Dit geeft inzicht in
de typen processen die door een workflowsysteem ondersteund kunnen worden. De taakafhandeling en routering wordt hiermee in een kader geplaatst.
Verschil in oriëntatie
In opdracht van InfTech heeft Pallas Athena een onderzoek uitgevoerd naar de op de markt
beschikbare tools. Hierbij is gelet op de ondersteuning voor zowel de logistieke als de procedurele
workflow. Een ander criterium wordt gevormd door het feit of de tool algemeen toepasbaar is in
een van de workflowomgevingen. In deze marktanalyse is een onderscheid gemaakt tussen:
Routeringsgeoriënteerde pakketten, en
Taakgeoriënteerde pakketten
Het verschil in oriëntatie speelt een belangrijke rol in de manier waarop een workflow ondersteund kan worden. Zoals al gezegd zijn in een gestructureerde omgeving vaak meerdere
medewerkers of complete afdelingen beschikbaar om een bepaald type proces te behandelen. Er
kan dan sprake zijn van full-case handling, indien één medewerker een instantiatie van het proces
van A tot Z behandelt. Het kan echter ook zijn dat meerdere personen een bijdrage leveren,
waarbij iedereen een specifieke taak heeft. Hoe meer personen er aan één geval werken, hoe meer
er sprake is van een lopende-band achtige werkwijze, de zogenaamde paper factory. De meeste
taken die uitgevoerd worden in een dergelijke paper factory, zijn routinematig en er zal worden
aangestuurd op een hoog mogelijke produktiviteit en doorstroming. Servicegericht organisaties
hanteren meestal full-case handling, terwijl produktiegeoriënteerde organisaties meestal de paper
factory benadering aanhangen.
Idealiter zou een workflowprodukt voor de gestructureerde omgeving beide typen organisaties
moeten kunnen ondersteunen. Uit de marktanalyse blijkt dat meestal de nadruk ligt op het
ondersteunen van de paper factory. Er is sprake van een routeringsgeoriënteerdheid.
In de flexibel gestructureerde omgevingen treft men geen paper factory werkwijze aan. De gehele
case wordt door één medewerker behandeld. Deze voegt dus veel waarde toe aan het geheel.
Het is dan ook van het grootste belang dat deze werknemer overzicht houdt over de uitgevoerde
en nog uit te voeren taken op een case. Maar ook in dit geval dient er gerouteerd te worden.
136
De routering volgt meestal impliciet uit de aan de verschillende taken toegekende autorisaties.
De produkten voor dit type workflow kennen een onderliggend model voor de afhandeling van
de processen, waarbij het niet zal verbazen dat de nadruk ligt op het taakafhandelingsgedeelte.
De routeringsfunctionaliteit is vaak wat minder geschikt voor de gestructureerde lopende-band
omgevingen dan de speciaal daarvoor gemaakte routeringspakketten.
Bij taakafhandeling zijn de volgende zaken van belang:
Welke taken moeten worden uitgevoerd?
In welke volgorde moet dat gebeuren?
Welke uitzonderingen komen voor?
Welke autorisatie is vereist (bij voorkeur in termen van een rol), met betrekking tot de
normale voortgang en met betrekking tot de uitzonderingen?
welke data moet per taak verwerkt worden?
Bij routering wordt gekeken naar:
Wie moet de taak uitvoeren (in termen van personen of groepen of meer algemeen bestemmingen) ?
Welke informatie moet daarbij ter beschikking worden gesteld?
Bij de taakafhandeling zijn dus de procedurele aspecten van groot belang. De referenties naar
groepen of groepen personen is daarbij niet nodig. Voor het procedurele aspect is slechts de rol
voor het uitvoeren, of voor het behandelen van een uitzondering vereist. De rollen zijn in principe
afhankelijk van het proces, maar veel rollen komen in meerdere processen voor.
Bij routering kijken we naar de logistieke aspecten. Bijvoorbeeld, een geval waarbij een taak met
een bepaalde rol moet worden uitgevoerd, wordt gerouteerd naar een persoon met die rol. De
daarbij benodigde informatie wordt hem ter beschikking gesteld.
Routeringsgeorienteerd
Figure B.3: Routeringsgeorienteerde workflow
In figuur B.3 staat een eenvoudig proces dat is weergegeven met een routeringsgeoriënteerd
workflowpakket. De cirkels stellen de bestemmingen voor, waarnaar gerouteerd wordt. De
rechthoeken stellen de uit te voeren taken voor.
Opvallend hierbij is:
Het proces beschrijft de routering
Daaraan gekoppeld zijn de taken in de zin: op een bestemming moet een bepaalde taak
worden uitgevoerd
137
De sturingscondities maken onderdeel uit van de routering
De volgorde van de taken die op één en dezelfde bestemming worden uitgevoerd, zijn geen
onderdeel van de routering
Met name het laatste punt is van belang. Het zegt: Een routeringsgeoriënteerd pakket geeft
geen ondersteuning voor de volgorde van taken die op één en dezelfde bestemming worden
uitgevoerd. Dit is een nadeel, daar men gedwongen is de procedurele logica, die de volgorde van
taken beschrijft, alsnog in de applicaties in te bouwen. Maar dat wil men nu juist met workflow
voorkomen.
In een omgeving waar men op iedere bestemming slechts één taak uitvoert, is die ondersteuning
niet vereist. Vandaar dat de strikt routeringsgeoriërenteerde pakketten in de lopende-band
omgeving uitstekend voldoen, maar bij full-case handling tekort schieten. Een schijnbaar voor
de hand liggende oplossing voor het probleem is het volgende: neem voor iedere taak een
bestemming. Dan vindt er veel routering plaats naar dezelfde bestemming, maar de procedurele
logica is dan in ieder geval opgeslagen in het workflowsysteem. Echter, behalve het feit dat
deze aanpak leidt tot misbruik van de concepten van het systeem, is er vaak een probleem met de
implementatie. Routering leidt er bij de meeste pakketten toe, dat er opnieuw een persoon voor de
volgende taak wordt aangewezen. Die persoon moet dan geautoriseerd zijn op de bijbehorende
bestemming. Bij de voorgestelde oplossing moet dat dezelfde persoon zijn. Dat wordt in geen
van de pakketten ondersteund, hetgeen gezien de achterliggende filosofie ook niet vreemd is.
Men moet dus weer zelf gaan programmeren om dit toe te voegen.
Taakgeorienteerd
In figuur B.4 staat hetzelfde proces, echter nu weergegeven met behulp van een taakgeoriënteerd
pakket. De rechthoeken stellen de uit te voeren taken voor, de cirkels de bestemmingen waarnaar
gerouteerd wordt. Opvallend is hierbij:
Figure B.4: Taakgeorienteerde workflow
Het proces beschrijft de taakafhandeling
Daaraan gekoppeld zijn de bestemmingen in de zin van: een taak moet op een bepaalde
bestemming worden uitgevoerd
De sturingscondities maken onderdeel uit van de takendefinitie
De routering wordt afgeleid uit de takendefinitie: er vindt geen spontane routering plaats
138
Routering vindt pas plaats nadat een taak is afgesloten en de volgende taak op een andere
bestemming moet worden uitgevoerd. Het zal duidelijk zijn dat de taakgeoriënteerde workflowpakketten geschikt zijn voor de omgevingen waar sprake is van full-case handling. Maar
ze kunnen evenzeer gebruikt worden voor de paper factory omgeving. Daarbij is er immers bij
iedere taak een nieuwe bestemming. De volgorde van taken wordt dan gebruikt om (impliciet)
de volgorde van bestemmingen te definiëren.
Conclusie
Concluderend kan het volgende gesteld worden:
1. Indien men de volgorde van taken als belangrijk deel van de workflow wil beschouwen,
bijvoorbeeld omdat men personen meerdere taken van één geval achter elkaar wil laten
behandelen, dan schieten veel routeringsgeoriënteerde pakketten tekort.
2. In een flexibel gestructureerde omgeving wordt in het algemeen in meer of mindere mate
gebruik gemaakt van full-case handling. Routering is dan ondergeschikt.
3. In een gestructureerde omgeving treft men zowel paper factory achtige omgevingen aan als
full-case handling, en alle tussenvormen.
Een routeringsgeoriënteerd pakket is alleen geschikt voor gestructureerde omgevingen waar
men op een paper factory achtige manier werkt. Daar kan men ook een taakgeoriënteerd pakket
gebruiken (waarbij immers de routering impliciet wordt afgeleid). In alle andere gestructureerde
omgevingen en in alle flexibel gestructureerde omgevingen is een taakgeoriënteerd pakket vereist.
B.4.3
FlowPATH
Op basis van de hiervoor beschreven criteria voor de beoordeling van een workflowpakket
heeft Pallas Athena het pakket FlowPATH van Bull geadviseerd. In deze paragraaf zal in worden
gegaan op de achtergronden en concepten die aan FlowPATH ten grondslag liggen en de gevolgen
die het gebruik van FlowPATH heeft op de uiteindelijke oplossing.
Over FlowPATH
FlowPATH is een ontwikkeling van Bull in samenwerking met de Universiteit van Colorado op
basis van het Information Control Net model (ICN). Dit ICN-model is een wetenschappelijke
benadering van de kantooromgeving die dient als basis voor FlowPATH. Het model gaat uit van
Actors die een bepaalde Rol vervullen. Iedere rol wordt voorzien van een Activiteit waarbinnen
één of meerdere taken uitgevoerd worden. De engine van FlowPATH controleert en distribueert
de activiteiten naar de diverse rollen. Het concept maakt het systeem flexibel omdat wijzigingen
eenvoudig zijn door te voeren. Het ICN-model is toepasbaar voor gestructureerde en voor flexibel
gestructureerde kantooromgevingen [Bul].
Het FlowPATH-model
Het FlowPATH-model staat getoond in figuur B.5. Centraal in dit model staan de procedures.
Deze procedures bestaan op hun beurt weer uit een aantal activiteiten die door voortgangsregels
verband met elkaar houden. Iedere activiteit bestaat weer uit een aantal taken. Voor ieder taak
is bepaalde data benodigd. De taken worden uitgevoerd door rollen. Een acteur is een bepaalde
instantiatie van een rol.
139
Procedure
Activiteiten
gekoppeld
door voortgangsregels
Taken
Rollen
Acteurs
Data
Figure B.5: Het FlowPATH-model
Ontwerpondersteuning en simulatie
Voor de ondersteuning van het ontwerp wordt de applicatie MOBILE bijgeleverd. Het eerste
ontwerp van een procedure wordt hiermee geproduceerd. Met de simulatiemogelijkheid die
MOBILE biedt, kan een controle uitgeoefend worden op de realiteit en de werkbaarheid van de
procedure. Ook kunnen snel knelpunten aangetoond worden, doordat een werkproces met een
aangenomen documentenstroom getoond kan worden.
Uit het ontwerp van MOBILE komen bepaalde parameters die direct binnen FlowPATH gebruikt
worden, de zogenaamde voortgangstabel. Momenteel is de koppeling nog niet dynamisch. Een
volgende versie maakt het mogelijk om veranderingen binnen MOBILE, direct in te laten grijpen
op de lopende procedure.
Produktarchitectuur
FlowPATH is modulair opgebouwd. Aan de hand van de omschrijving van de beschikbare
modules wordt uitleg gegeven omtrent de routering en taakmodellering binnen FLowPATH. De
Oracle-database is geheel geı̈ntegreerd met FlowPATH, waardoor geen specifieke kennis nodig
is van dit produkt. Het totale systeem wordt gerealiseerd in een client/server architectuur.
Op het servergedeelte zijn de volgende modules actief:
1. Data Management Module
Een database vormt de basis van deze module waarin de gegevens van de activiteiten,
definities, relaties tussen alle processen, workcases, rollen en personen worden opgeslagen.
Daarnaast ook de gegevens die specifiek zijn voor de procedure, de workcase en de activiteit.
2. Scheduler Module
Deze module wordt geactiveerd in één van de volgende gevallen: het aanmaken van een
workcase, het afsluiten van een workcase, het completeren van een activiteit middels een
controle van de resultaten op basis van een te verwachten patroon, aan de hand waarvan
een volgende stap wordt gekozen. Ook in het geval er door de gebruiker voor "exception
handling" wordt gekozen, zal de Scheduler Module geactiveerd worden.
3. Dispatcher Module
De primaire module die zorgt voor het toewijzen van een activiteit aan één of meerdere
gebruikers. De gegevens worden aangegeven door de Scheduler Module. Wanneer de
keuze gemaakt moet worden voor één uit vele zelfde gebruikers kan het "lineair dispatching"
140
principe worden toegepast, waarbij een evenredige belasting verkregen wordt voor een serie
zelfde gebruikers. Daarnaast bestaan ook andere "dispatching methodes", bijvoorbeeld
directe toewijzing aan een acteur binnen een groep met dezelfde functie.
4. Message Box Module
Alle a-synchrone berichten (store and forward) die betrekking hebben op activiteiten die
toegewezen worden aan gebruikers, waarschuwingsberichten vanuit de Notifier Module
en onderlinge gebruikers berichten, worden behandeld door de Message Box Module.
5. Notifier Module
De tijdsgebonden gebeurtenissen worden hier bijgehouden. Deze waarschuwen de gebruikers op tijd voor bijvoorbeeld deadlines. Er zijn onder meer twee hoofdfaciliteiten:
de Reminding facility (activiteit gebonden)
de Delaying facility (workcase gebonden)
6. Coördinator Module
Vanuit deze module kan alles gezien worden wat met het FlowPATH systeem gebeurt door
middel van de volgende faciliteiten:
Auditing: volgt bepaalde gebeurtenissen en controleert deze op de doorlopen tijd.
Systeem status querying: bijvoorbeeld wie doet wat; wat is de huidige status van een
specifieke workcase; hoeveel workcases zijn in behandeling.
Workcase Management: bijvoorbeeld het onderbreken, laten hervatten, annuleren of
opnieuw toewijzen van een workcase.
Archiving: bijhouden van de historie van het FlowPATH systeem.
7. Administrator Module
Deze bevat meerdere programma’s voor onder andere:
De eerste implementatie van FlowPATH
Het onderhoud van een bestaand FlowPATH systeem
Het beheer van een geı̈nstalleerd FlowPATH systeem (hiermee kunnen ook gebruikers
van meerdere rollen worden voorzien)
Op het server (werkstation) gedeelte zijn de volgende modules actief:
1. Task Management Module
De combinatie van een specifieke workcase en een specifieke activiteit wordt een "task"
(taak) genoemd. De Task Management Module behandelt:
Multiplexen tussen taken
Uitwisselen van informatie tussen taken
Onderhoud van de status van taken
Onderhoud van aan taken gerelateerde statistieken
2. Activity Execution Module
Deze module verzorgt de specifieke gegevens om een activiteit uit te voeren, zoals
Specifieke workcase gegevens
Specifieke activiteiten gegevens
Externe gegevens, indien nodig (b.v. mainframe connectie)
141
3. Actor Interface Module
Tijdens de uitvoering van een activiteit heeft de gebruiker interactie met de "Activity Execution Module" via de "User Interface". Deze module doet het volgende
B.4.4
Presenteert (gescande) documenten op het scherm
Ontvangt gebruikers gegevens
Toont en houdt de status bij van de activiteiten in het register, zowel nieuwe, lopende
als afgehandelde activiteiten
Ontwikkelmethode
De klanten van InfTech zijn erg geı̈nteresseerd in de evolutionaire manier van ontwikkelen, zoals
die door InfTech/Pallas Athena wordt toegepast. Deze evolutionaire manier van ontwikkelen
heeft een soort structuur. Eerst wordt de kern van het systeem ontwikkeld. Daarna wordt schil
voor schil het systeem vervolledigd. Voordeel hiervan is dat de klant altijd een demonstratie van
het systeem kan krijgen en daardoor voeling houdt met de ontwikkeling. Aanvullende eisen of
veranderde wensen kunnen altijd worden meegenomen zonder fundamentele wijzigingen in het
reeds gerealiseerde systeem aan te brengen.
Traditioneel worden na een onderzoek van de informatie-analisten bij wijze van spreken al de
gebruikersschermen ontworpen. Het ontwikkelen van een systeem echter moet een iteratief
proces zijn. De klant moet erbij betrokken zijn, want hij kent zijn organisatie door en door en
weet ook welke problemen zich voor kunnen doen.
Het ontwikkeltraject van InfTech bestaat uit negen fasen die hieronder zullen worden toegelicht.
1. Acties inventariseren
Door het onderscheid in een logistieke en procedurele workflow, staan de procedures en
de activiteiten waaruit deze procedures zijn opgebouwd centraal. In de eerste fase worden
dan ook alle activiteiten waaruit een workflow is opgebouwd onderscheiden.
2. Volgorde/Authorisaties
Door middel van scripts worden de activiteiten in de juiste volgorde geplaatst, zodat de
juiste invoer tot uitvoer wordt getransformeerd. Tevens worden de bij deze activiteiten
behorende autorisaties toegevoegd.
3. Gegevens toevoegen
In de de derde fase worden de gegevens toegevoegd, zodat elke uiteindelijke gebruiker
op het moment dat hij een bepaalde activiteit moet uitvoeren over de juiste gegevens kan
beschikken. Deze gegevens kunnen bestaan uit data uit het mainframe, images, etc.
4. Database structuur
Vervolgens wordt de database structuur ontworpen, welke ten grondslag ligt aan het workflowsysteem. Hierin wordt het ’werk’ gerepresenteerd en alle toestanden waarin het zich
kan bevinden.
5. Procedures op activiteitenniveau
De activiteiten die in fase 1 zijn onderscheiden en in fase 2 in de juiste volgorde zijn gezet
worden in deze fase gegroepeerd tot procedures. Hierdoor wordt de logistieke workflow
vastgelegd, evenals de activiteiten waar tussen gerouteerd dient te worden.
6. Electronische formulieren ontwerpen
In deze fase worden de gebruikersschermen gedefinieerd. Dit in nauw overleg met de
uiteindelijke gebruikers, teneinde een schermendefinitie te verkrijgen in overeenstemming
met hun wensen.
142
7. Integreren met DB. Integreren met word processor, imaging, scanning, etc.
In deze fase komt alles samen. Alle in de vorige fasen ontwikkelde (data)structuren worden
geı̈ntegreerd met de verschillende applicaties. De koppeling met het mainframe vindt hier
echter nog niet plaats.
8. Script schrijven (facelifting), Integreren met mainframe
In deze fase vindt de integratie plaats met het mainframe. Eventueel wordt gebruik gemaakt
van facelifting, waarbij de gebruiker door middel van scripts wordt afgeschermd van de
mainframe-applicatie.
9. Management info (infomodule)
Als laatste wordt de management infomodule gerealiseerd. De informatie uit de database
over de status van het werk, wordt gecombineerd tot informatie over doorlooptijden,
werkvoorraden, knelpunten etc. Dit afhankelijk van het soort informatie wat door de
klant gewenst is.
Na iedere stap vindt een evaluatie plaats en wordt het systeem getest.
B.4.5
Gebruik van het ontwerp
Er is geen duidelijk afgerond ontwerp gemaakt voordat met de implementatie is begonnen. Daar
het project met minder mensen is uitgevoerd dan initieel de bedoeling was, is de documentatie
erbij ingeschoten. Diegenen die bij de ontwikkeling betrokken zijn geweest hebben hun ideeën
meteen vertaald naar het uiteindelijke systeem.
B.4.6
Workflow componenten
Het workflowsysteem bestaat uit een drietal componenten (zie figuur B.6), te weten
De beheersomgeving
De beheersomgeving bestaat uit het operating systeem (Unix), het database management
systeem en de terminal emulatie software.
De runtime component
De runtime component is opgebouwd uit een aantal operationele procedures. Deze zullen
in de volgende paragraaf aan de orde komen.
De ontwikkelomgeving
In de ontwikkelomgeving kunnen nieuwe procedures gedefinieerd worden die dan in de
runtime applicatie gehangen kunnen worden.
B.4.7
Implementatie
De implementatie kan schematisch weergegeven worden, zoals in figuur B.7. In FlowPATH
worden procedures gedefinieerd, die op hun beurt weer bestaan uit een aantal activiteiten. Een
activiteit bestaat uit een aantal scripts. Een script combineert data van de mainframe-applicatie
via de emulator met gebruikmaking van images via ImageWORKS. De info-module registreert
gegevens over werkvoorraden en doorlooptijden ten behoeve van managementinformatie.
B.5 Invoering
De invoering van het systeem is tot op heden nog niet gebeurt. In dit hoofdstuk wordt de manier
beschreven waarop dit gaat gebeuren.
143
B.5. Invoering
Beheers
omgeving
Ontwikkelomgeving
Runtime
procedures operationeel
Figure B.6: De opbouw van het systeem
emulator
MF-app.
script
activiteit
info
procedure
FlowPATH
ImageWORKS
Figure B.7: De implementatie
B.5.1
Keuzes
Er is gekozen voor een in twee dimensies gefaseerde aanpak. Niet alleen wordt de organisatie
verdeeld in groepen die stuk voor stuk vertrouwd worden gemaakt met het systeem. Voor ieder
groep geldt ook dat zij over een periode van enkele maanden geleidelijk hun werk overhevelen
naar het systeem. Eerst wordt de inschrijving op het nieuwe systeem gedaan, terwijl de rest op
de traditionele manier gebeurt. Vervolgens worden de inschrijving en de mutaties op het nieuwe
systeem gedaan, terwijl de uitschrijvingen nog op de oude manier worden gedaan. Als laatste
worden ook de uitschrijvingen op het nieuwe systeem gedaan en is die groep volledig vertrouwd
met het nieuwe systeem.
B.5.2
Stappen
De invoering in de organisatie kan het best geı̈llustreerd worden aan de hand van figuur B.8. Uitgaande van de invoering van een systeem waarbij 70 medewerkers betrokken zijn. De invoering
gaat gefaseerd in groepen van 10 personen.
144
60
50
.....enz.....
40
P
30
P
20
10
0
P
P
P
1
P
P
2
P
P
P
3
P
4
P
5
6
7
8
9
10 11 12 13 14 15 16 17
TIJD (in maanden)
Training
Procedures inschrijvingen
Procedures inschrijvingen en uitschrijvingen
Procedures inschrijvingen, uitschrijvingen en mutaties
Figure B.8: Het invoeringstraject
Maand 1
De eerste groep van 10 personen bestaat dan uit 8 ’gewone’ medewerkers en 2 van de personen
van wie de meeste weerstand te verwachten valt. Het is belangrijk deze personen in een vroeg
stadium van het traject te overtuigen. In de eerste maand wordt deze groep van 10 personen
getraind.
Maand 2,3,4
De drie maanden daarop volgend gaan ze met het systeem aan de slag. Ze doen slechts één
procedure, in dit geval de inschrijving van verzekerden. De eerste maand staat de scanner op de
afdeling met iemand van de postkamer die deze bedient. Op deze manier kunnen beide partijen
tot een optimale afstemming komen. Na een maand verhuist de postkamermedewerker met de
scanner naar de postkamer.
Maand 5,6,7
De drie maanden daarop volgend komt er een procedure bij. Bijvoorbeeld het uitschrijven van
verzekerden. De eerste maand is er weer iemand van de postkamer aanwezig.
Maand 8,9,10
De laatste maanden van het traject komt de procedure mutaties van inschrijvingsgegevens er nog
bij. De groep van 10 medewerkers is nu vertrouwd met het het gehele systeem. Ook hier komt
de eerste maand weer iemand van de postkamer op de afdeling. Een maand later dan de eerste
groep begint een tweede groep van 10 mensen aan hetzelfde trainingstraject. Het voordeel van
deze methode is dat er ten allen tijde kan worden ingegrepen. Er kan bij grote problemen van
gebruikers nog gewijzigd worden in het systeem, zonder dat iedereen opnieuw getraind moet
worden.
145
B.6. Conclusies en aanbevelingen
B.5.3
Hardware
Het IT-2000 systeem is een cliënt-server applicatie. De opbouw van het systeem staat schematisch
weergegeven in B.9.
PC
PC
PC
PC
PC
PC
Ethernet
Bestaande DCP
Bull DPX/20 (RS/6000)
Printer
Scanner
Figure B.9: De pilot hardware-opstelling
De pilot draait op de volgende hardware:
Bull DPX/20 server (RS/6000)
Werkstations
– Intel 486 processoren
– Hoog resolutie schermen (1024x768)
– DOS/Windows 3.1
Scanner
Laserprinter
2Gb magnetische opslag
B.6 Conclusies en aanbevelingen
B.6.1
Verloop van het onderzoek
Het onderzoek is goed verlopen. Met name John Hoogland die zowel werkzaam is bij InfTech als
Pallas Athena, is hiervoor dank verschuldigd. Helaas was er niet veel documentatie beschikbaar
met betrekking tot het pilotproject en de gevolgde ontwerpmethode. De meeste informatie is
door gesprekken overgedragen aan de auteur.
B.6.2
Conclusies
Middels de samenwerking met het workflow-adviesbureau Pallas Athena is binnen InfTech veel
kennis aanwezig over workflowsystemen. Deze kennis vormt in belangrijke mate de basis voor de
ontwikkelmethode die InfTech hanteert voor de ontwikkeling van workflowsystemen. Daarnaast
146
heeft InfTech veel oog voor de strategische en commerciële wensen van haar klanten. Door het
algemene karakter van deze methode heeft InfTech een weloverwogen gereedschap in handen
om hun klanten van een systeem te voorzien, waarmee ze zijn opgewassen tegen veranderende
markteisen. Tot op heden is het systeem van InfTech beperkt gebleven tot een goed functionerende
pilot. De waarde van het systeem bij operationeel gebruik en de methode is iets wat in de praktijk
nog moet blijken. Het karakter van InfTech is echter altijd gericht op leren en ervaring opdoen,
zodat praktijkervaringen zullen bijdragen aan de kwaliteit van de gehanteerde filosofie. De
toekomst kan derhalve met vertrouwen tegemoet worden gezien.
147
Appendix C
Het WA-12 rapport van MedIns
Summary
In deze appendix is het gehele rapport bevat, voor zover dit het MI2 project, zoals bij MedIns
is uitgevoerd betreft. Het gaat hier om het rapport zoals dat naar de betrokken organisatie is
opgeleverd, met dien verstande dat deze versie is geanonimiseerd; de naam van de organisatie
is veranderd, evenals persoonsnamen. Tevens heeft het systeem een andere naam gekregen.
Voor de rest is het rapport onveranderd gebleven.
Dit rapport beschrijft het workflowsysteem MI2. Dit is een dossier beheerssysteem dat in
gebruik is bij MedIns, een onderlinge verzekeringsmaatschappij voor de medische wereld in
het midden van het land. Het beschreven systeem is een succes, daar de beoogde resultaten
zijn behaald. Dit systeem is een schoolvoorbeeld van het ontstaan van een workflow-behoefte
vanuit archiveringsproblematiek. De weg langs DIS is dan ook geheel natuurlijk.
Dit rapport kent een achttal hoofdstukken waarin het gehele MI2 project wordt beschreven.
haalbaarheidsonderzoek, het verloop van het project en de projectorganisatie, het proces wat
ten grondslag ligt aan het systeem en de analyse van dit proces en het ontwerp van het systeem.
Ook de implementatie en invoering van het systeem evenals de evaluatie van het gehele traject
komen aan bod. Het rapport wordt afgesloten met conclusies en aanbevelingen.
C.1
Inleiding
C.1.1
beschouwd. Het doel van dit onderzoek is inzicht te krijgen in het ontwerp en de invoering van dit
soort systemen. Dit rapport beschrijft het workflowsysteem MI2. Dit is een dossier beheerssysteem dat in gebruik is bij de Onderlinge Levensverzekering Maatschappij voor Artsen U.A. te
Utrecht. Het doel van dit rapport is tweeledig. Voor MedIns is het een audit op hun systeem.
Voor de universiteit is het één van de systemen waarop de vergelijkende studie gebaseerd wordt.
C.1.2
Bereik
In dit rapport zal getracht worden een zo volledig mogelijk beeld te schetsen van het MI2systeem. De nadruk zal liggen op de analyse en het ontwerp van dit systeem en op de gevolgen
van workflow management en workflow automation voor de organisatie.
C.1.3
Doelgroep
De doelgroep van dit rapport bestaat uit de betrokkenen bij MedIns en de onderzoekers van de
Universiteit Twente. Van dit rapport zullen twee versies verschijnen. Een versie voor MedIns
148
C. Het WA-12 rapport van MedIns
en een versie voor het gebruik binnen de universiteit. De versie voor gebruik op de universiteit
verschilt hierin van die voor de MedIns, dat hierin de namen MedIns evenals de namen van
fabrikanten en leveranciers niet zullen voorkomen.
C.1.4
Structuur
Het rapport kent de volgende structuur. In paragraaf 2 wordt een beschrijving gegeven van het
MI2-project. Paragraaf 3 gaat verder met een uitgebreide procesbeschrijving, waarna in paragraaf
4 dieper in wordt gegaan op de analyse van het proces en het ontwerp van het systeem. Paragraaf
5 gaat over de invoering en de paragrafen 6 en 7 behandelen de evaluatie van respectievelijk het
systeem en het project. Het geheel wordt afgesloten met paragraaf 8, waarin conclusies worden
getrokken en aanbevelingen worden gedaan.
C.1.5
Terminologie
In deze subparagraaf wordt de terminologie gegeven, zoals deze bij MedIns wordt gehanteerd.
Afkortingen:
API Application Program Interface
MedIns Onderlinge Levensverzekering Maatschappij voor Artsen U.A. te Utrecht
MIversie OLMa DossierbeheersSysteem versie versie
PACE Professional Application Creation Environment
(4GL Databaseomgeving van WANG)
VS Virtual System
(Benaming van WANG hard en software systemen)
WA-12 Workflow Analyse in 12 organisaties
WANG De hard- en softwareleverancier van MedIns
WIIS Wang Integrated Image System
WPplus Het bij MedIns in gebruik zijnde tekstverwerkingspakket
Overige terminologie:
Activiteit
Een activiteit is een afgeronde hoeveelheid werk met een duidelijk resultaat
Rol
Een rol is een klasse werknemers die een bepaald takenpakket met bijbehorende bevoegdheid heeft
Image
De digitale representatie van één pagina in het systeem
C.2
Projectbeschrijving
C.2.1
Doel
Het doel van dit hoofdstuk is een beschrijving te geven van het MI2-project. Er zal een beeld
worden geschetst van MedIns verzekeringen en de problemen en wensen die aanleiding zijn
geweest voor de ontwikkeling van dit systeem. Dit heeft tot doel het project in zijn context te
plaatsen. Tevens komt de tijdsplanning en de organisatie van het project aan de orde.
149
C.2. Projectbeschrijving
C.2.2
De MedIns
De MedIns werd 26 jaar geleden opgericht op initiatief van de Koninklijke Maatschappij tot
bevordering van de Geneeskunde (KNMG). Naast het afsluiten van levensverzekeringen kunnen artsen (in opleiding) ook bij de MedIns terecht voor praktijkadviezen, pensioen en VUT,
schadeverzekeringen alsmede voor financiering van huis en praktijk en andere financieringen.
MedIns is verdeeld in een aantal nauw samenwerkende afdelingen. In de verzekeringswereld is
de term bedrijven gebruikelijk voor de afdelingen die zich met de verschillende verzekeringsprodukten bezighouden. Om verwarring te voorkomen zal deze term in dit rapport niet gebruikt
worden. Deze afdelingen spelen een belangrijke rol in het MI2-systeem. Bij de indexering wordt
namelijk naar deze afdelingen gerefereerd door middel van een tweeletterige code. De afdelingen
met hun codes staan weergegeven in tabel C.1.
Code
FI
LC
LI
SB
MS
UA
KN
EF
Afdeling
Financieringen
Collectieve Levensverzekeringen
Individuele Levensverzekeringen
Schadebemiddeling
Medisch secretariaat
Uitkeringen Administratie
Kontrakten
Effecten
Table C.1: De afdelingen van MedIns
C.2.3
Probleemomschrijving
De voornaamste doelstelling van het MI2-systeem is het verbeteren van de service naar de cliënten.
Een betere service betekent vooral een snellere service. Een snellere afhandeling van de verzekeringsaanvragen en verzoeken om informatie en wijzigingen door het publiek. Deze verbeterde
service werd belemmerd door archiveringsproblemen, die veroorzaakt worden door de lange tot
zeer lange bewaartijd van (levens)verzekeringen. In de tijd dat alle dossiers nog in papieren vorm
werden bewaard vormde de omvang van het archief een probleem. Een anekdote wil dat er zelfs
een tijd is geweest dat het archief in de gangen van het MedIns-gebouw was opgeslagen. Deze
grote papieren archieven zijn weggewerkt door over te gaan op verfilming. Dit is echter ook niet
zonder problemen, zodat men is gaan denken aan een geautomatiseerd dossierbeheerssysteem.
De hoofdoorzaken die hiertoe aanleiding hebben gegeven worden hieronder opgesomd.
Dossiers en stukken zijn pas na verfilming beschikbaar
De tijd tussen het moment dat een dossierstuk de organisatie binnenkomt en het moment dat
het voor alle medewerkers beschikbaar is, is te groot. Dit heeft twee oorzaken. Ten eerste
zijn stukken, zolang zij het verwerkingstraject doorlopen, niet beschikbaar voor andere
medewerkers. Ten tweede worden aan het eind van het traject zoveel stukken opgespaard,
dat er steeds een hele film ’volgeschoten’ kan worden. Zolang de dossiers zich in deze stapel
bevinden zijn ze niet toegankelijk, daar niemand op de hoogte is van de exacte verblijfplaats.
Dossiers kunnen moeilijk vindbaar of zelfs onvindbaar zijn
Indien een dossier zich niet in het archief bevindt is het niet altijd bekend welke medewerker
dit dossier in zijn of haar bezit heeft. Tevens is er geen controle op het terugbrengen van
dossiers door medewerkers. Dit leidt er toe dat dossiers pas na veel moeite vindbaar zijn
of zelfs geheel onvindbaar zijn.
150
Van veel cliënten werd meer dan één dossier aangehouden
Dit is een gevolg van het hiervoor genoemde probleem. Indien een dossier van een bepaalde
cliënt niet gevonden werd, dan werd in sommige gevallen een nieuw dossier aangemaakt.
Op deze manier werden van sommige cliënten meerdere dossiers aangehouden. Geen van
deze dossiers was dan compleet.
Dossiers zijn niet gelijktijdig toegankelijk
Alle dossiers, op papier of film, zijn slechts toegankelijk voor diegene die ze in zijn of haar
bezit heeft. Gelijktijdige toegankelijkheid van een dossier(stuk) door meerdere medewerkers wordt hierdoor uitgesloten.
Het aanbrengen van wijzigingen in dossiers gaf problemen
Technische redenen bemoeilijken het toevoegen of verwijderen van stukken aan een reeds
verfilmd dossier.
De MedIns dacht voor deze problemen een oplossing te vinden in de vorm van een geautomatiseerd dossierbeheerssysteem. Om de voordelen die een dergelijk systeem kan bieden te
garanderen zijn deze vastgelegd in een aantal eisen die vooraf aan het systeem zijn gesteld. Deze
zullen in paragraaf 3 uitgebreid aan de orde komen.
C.2.4
Projectverloop
Deze paragraaf is geheel gewijd aan het verloop van het MI-project. In tabel C.2 staat dit
projectverloop weergegeven voorzien van een tijdsindicatie. De stappen worden hieronder kort
beschreven.
nr.
1
2
3
4
5
6
7
8
9
10
besluit/fase
eerste voorstel aan de directie
herhaling voorstel voor de commissarissen
site-visits en bouw prototype
besluit bouw volwaardig systeem
onderhandelingen met WANG
afsluiten contracten
ontwikkeling van het systeem
begin proefdraaien (3 maanden) in eerste rayon
invoering van het systeem rayon voor rayon
het systeem is volledig ingevoerd
periode/tijdstip
feb 90
mrt 90
apr 90-mei 90
jun 90
jun 90-aug 90
sep 90-okt 90
nov 90-jan 91
feb 91-mrt 91
jun 91-jun 92
jun 92
Table C.2: Het verloop van het project
Eerste voorstel en besluitvorming
Het eerste voorstel voor een dergelijk systeem kwam in februari 1990 van dhr. J. Keur, hoofd
automatisering van de MedIns. Hij had bij diverse bedrijven automatiseringservaring opgedaan
en was recentelijk bij MedIns in dienst getreden. Geconfronteerd met de problemen bij de
administratieve verwerking van documenten ontwikkelde hij de plannen voor dit systeem. Het
kostte weinig moeite om de toenmalige directie en raad van commissarissen te overtuigen van
de te behalen voordelen met een dergelijk systeem. De raad van commissarissen van MedIns
bestaat vooral uit medici en zij kennen als geen ander de problematiek die gepaard gaat met
dossierbeheer. In dit stadium van het project is dus reeds veel commitment uit de besluitvormende
hoek gekomen. De gebruikers waren ook enthousiast, daar zij in de uitvoering van hun taken
geconfronteerd werden met de archiverings- en dossierproblematiek. Deze oplossing leek hier
een eind aan te maken.
C.3. Procesbeschrijving
151
Site-visits en bouw prototype
In het volgende stadium van het project zijn, met medewerking van huisleverancier WANG,
enkele sites bezocht. Een goed vergelijkbaar systeem is echter niet gevonden. Er wordt besloten
tot de bouw van een prototype. Op dat moment is een van de medewerkers van MedIns voor
halve dagen werkzaam op de automatiseringsafdeling en voor halve dagen cliëntenadviseur. Hij
was dan ook bij uitstek de man om bij een dergelijk project betrokken te worden, daar de link
met de gebruikers op deze manier fysiek gegarandeerd is. Vervolgens is een prototype op kleine
schaal gebouwd en werkzaam geweest in één rayon. De ervaringen met het prototype waren zeer
positief. Men heeft vervolgens besloten over te gaan tot de bouw van een volwassen systeem.
Onderhandelingen, bouw en invoering
Door de ervaringen met het prototype waren de voordelen, zoals die initieel geschetst waren
nog eens duidelijk onderstreept. Er zijn onderhandelingen gevoerd met de leverancier, om een
volwaardig systeem te gaan bouwen en company-wide in te voeren. Daar ook de leverancier geen
ervaring had met een dergelijk systeem, en een geslaagd project uit marketingoverwegingen
zeer interessant was, heeft de ontwikkeling kostenloos plaatsgevonden. Onder de voorwaarde
dat WANG dit systeem als site voor potentiële klanten mocht gebruiken zijn ook zeer gunstige
afspraken met betrekking tot de nazorg bedongen.
C.2.5
Projectorganisatie
De ontwikkeling van het systeem is niet in een formeel vastgelegde structuur gebeurd. De motor
achter het idee is dhr. J. Keur geweest. Verder heeft de ontwikkeling plaatsgevonden in een
gevarieerd team, bestaande uit
dhr. J. Keur, Hoofd automatisering van MedIns
een medewerker met een dubbele functie (50% automatisering en 50% cliëntenadviseur)
enkele gebruikers, afhankelijk van het deel van het systeem wat ontwikkeld werd
een programmeur van de leverancier (dhr. H. van der Markt, WANG)
C.2.6
Conversie van oude dossiers
Bij de ontwikkeling van het systeem is overwogen om de oude dossiers, die alleen op film
beschikbaar waren, om te zetten naar digitaal formaat (image). Hier is vanaf gezien, daar
het omzetten van film naar image teveel technische problemen opleverde, en
De kwaliteit van de films was zeer wisselend. Bij iedere nieuwe film moest de scanner
anders worden ingesteld. De tijd en daarmee de kosten om deze conversie uit te voeren
waren hierdoor zeer hoog.
de oude dossiers op film zeer weinig werden gebruikt.
Het grootste deel van het verfilmde archief was statisch. Gezien het eerste bezwaar zou een
kosten/baten analyse wel heel negatief uitvallen indien tot conversie van het gehele archief
zou worden overgegaan. Indien al een dossier nodig was uit dit archief, dan zou dat nog
wel van film kunnen worden gelezen.
C.3
Procesbeschrijving
C.3.1
Doel
In dit hoofdstuk wordt getracht een zo compleet mogelijke beschrijving te geven van het proces
van documentverwerking en dossierbeheersing, zoals dat ten grondslag ligt aan het MI2-systeem.
152
Het doel van het proces is de verwerking van alle inkomende en uitgaande poststukken en het
daarbij horende dossierbeheersvraagstuk. Een cliëntdossier bevat inkomende en uitgaande poststukken. Inkomende poststukken kunnen alle vormen aannemen zoals: geschreven en getypte
brieven, ingevulde formulieren etc. Daarnaast worden ook inkomende stukken aangeleverd
door de buitendienstmedewerkers. Dit zijn voornamelijk verslagen van bezoeken aan cliënten.
Uitgaande stukken zijn voornamelijk WPplus-documenten. Dit kunnen aan cliënten verzonden brieven zijn, besprekingsverslagen e.d. In een enkel geval komen ook andere vormen van
uitgaande post voor.
C.3.2
Procesverloop
Het proces van de verwerking van de post, zoals dat gebruikelijk was voor de invoering van
het dossierbeheerssysteem, wordt in de volgende subparagrafen beschreven. Hierbij wordt nog
uitgegaan van de oude situatie, waarbij de documenten in papieren vorm door de organisatie
worden gerouteerd.
Administratieve ondersteuning
In de afdeling administratieve ondersteuning is ook de postkamer ondergebracht. De inkomende
post wordt hier gescheiden in post die direct betrekking heeft op de afdelingen binnen MedIns
en andere post, zoals nota’s van leveranciers, folders, e.d. Deze laatste post is niet interessant
voor het systeem. Bij de post die wel direct betrekking heeft op de verzekeringen kunnen zich
twee gevallen voordoen:
1. het poststuk kan betrekking hebben op één onderwerp binnen één afdeling van MedIns
2. een poststuk kan betrekking hebben op meerdere onderwerpen of meerdere afdelingen
binnen MedIns
Aan poststukken die betrekking hebben op meerdere onderwerpen of meerdere afdelingen worden routebriefjes gehecht. Ze worden dus niet gekopieerd, maar gaan sequentieel door alle
betrokken afdeling. Een paralelle behandeling is niet mogelijk, daar dit een gelijktijdige toegang
van het (papieren) dossier vereist. Dit dossier is slechts in enkelvoud aanwezig. Duidelijk zal zijn
dat op dit punt efficiëntiewinst geboekt kan worden. De post wordt vervolgens doorgestuurd
naar de cliëntenadviseurs van de diverse afdelingen.
Cliëntenadviseurs
Iedere cliëntenadviseur beheert een bepaald rayon. In ieder rayon is een buitendienstmedewerker
werkzaam. Cliëntenadviseur en buitendienstmedewerker werken nauw samen bij de afhandeling
van een binnengekomen document. Bij ontvangst van het poststuk door de cliëntenadviseur zoekt
deze het bijbehorende dossier op. Het kan voorkomen dat het dossier niet aanwezig is in het
archief, maar dat een andere cliëntenadviseur van mogelijk een ander bedrijf dit in zijn bezit
heeft. In noodgevallen kan er van het dossier een kopie worden gemaakt.
De cliëntenadviseur houdt zich vervolgens bezig met de afhandeling van het binnengekomen
document. Afhankelijk van de aard van het document kan dit leiden tot een van de volgende
acties:
Bezoek aan de cliënt
In dit geval wordt de buitendienstmedewerker ingeschakeld. Indien nodig haalt hij of zij
aan het begin van de dag de dossiers van de desbetreffende cliënten op bij het MedIns
kantoor. Vervolgens wordt een bezoek aan de relatie afgelegd, waarna aan het eind van de
dag een verslag bij de cliëntenadviseur wordt afgeleverd.
C.3. Procesbeschrijving
153
Telefonisch onderhoud met de cliënt
Indien een bezoek niet nodig is kan de cliëntenadviseur de zaak telefonisch met de relatie
afhandelen. Dit zal vooral voorkomen indien er bij een cliënt vragen of onduidelijkheden
bestaan omtrent bepaalde kwesties. Ook hiervan wordt een verslag in het systeem (WPplus)
aangemaakt.
Schriftelijke afhandeling
Is een schriftelijke afhandeling noodzakelijk, dan zal de cliëntenadviseur middels dit
medium met de cliënt communiceren. Dit zal voornamelijk het geval zijn bij polissen
en offertes. Dit document wordt ook gegenereerd met behulp van het systeem (WPplus).
Het resulterende document wordt middels een daisywheel printer afgedrukt, met vier verschillend gekleurde doorslagen.
Wit voor de klant
Groen voor de adviseur
Rose voor de afdelingshoofden
Geel als werkkopie
Na verwerking wordt het ingekomen poststuk en het verslag of de brief (in veelvoud), samen met
het dossier van de relatie overhandigd aan een van de procuratiehouders van MedIns. Indien
deze het goedkeurt, gaat iedere doorslag naar de desbetreffende doelgroep.
Procuratiehouder
De procuratiehouder heeft als taak te controleren of een correcte afwerking heeft plaatsgevonden.
Deze controle doet hij aan de hand van de aanleiding, die tot dit resultaat geleid heeft. Zo heeft
een aanvraag voor een bepaald soort verzekering bijvoorbeeld een polis tot gevolg. Indien de
uitvoering niet correct is geweest, wordt het poststuk, het verslag of de brief, samen met het
dossier weer opnieuw ter afwerking teruggestuurd naar de desbetreffende cliëntenadviseur.
Heeft de afwerking wel correct plaats gevonden, dan zijn er twee mogelijkheden:
Het poststuk had betrekking op slechts één onderwerp en één bedrijf. In dit geval worden
zowel het poststuk als het WPplus document in chronologische volgorde opgeborgen in het
dossier van de relatie, waarna het dossier wordt teruggezet in het archief.
Aan het poststuk is een routebriefje bevestigd. In dit geval worden de stukken en het dossier
verzonden naar de persoon of het bedrijf, zoals vermeld op het routebriefje, om verder te
worden afgewerkt.
C.3.3
Functies
Zoals al blijkt uit bovenstaand procesverloop zijn er een drietal functies te onderscheiden:
1. Cliëntenadviseur
MedIns heeft het Nederlandse grondgebied verdeeld in een zestal rayons. Per rayon is een
aantal cliëntenadviseurs en buitendienstmedewerkers werkzaam. De buitendienstmedewerkers worden niet als aparte functie in die proces onderkent, daar zij communiceren via de
cliëntenadviseur. De taken van de cliëntadviseurs bestaat uit het maken van afspraken, het
bezoeken van relaties en het afwerken van de lopende zaken.
2. Procuratiehouder
Procuratiehouders zien toe op de verzekeringtechnisch correcte afwikkeling van de zaken
die de cliënten aan MedIns hebben toevertrouwd.
154
3. Administratieve ondersteuning
De administratieve ondersteuning assisteert de cliëntenadviseurs, procuratiehouders en de
rest van de MedIns organisatie in de uitoefening van hun taken.
C.3.4
Controlemaatregelen
Zoals gezegd zien de procuratiehouders toe op de verzekeringtechnisch correcte afhandeling van
het ingekomen stuk. Vanuit het management van de organisatie is er echter weinig controle op de
doorlooptijd en de werkvoorraden bij de diverse cliëntenadviseurs en procuratiehouders. Deze
controle vindt plaats door middel van visuele inspectie of door de betreffende persoon te vragen
naar de status van zijn of haar werkzaamheden.
C.4
Analyse en ontwerp
C.4.1
Doel
Doel van dit hoofdstuk is een beeld te schetsen hoe het proces bij de MedIns is ontleed in termen
van werkstromen en hoe het MI2-systeem is ontworpen.
C.4.2
Eisen
Zoals gezegd is de voornaamste doelstelling van het MI2-systeem het verbeteren van de service
naar de cliënten. Deze betere service komt neer op een snellere service. Om deze serviceverbetering te kunnen realiseren zal het systeem aan de volgende voorwaarden moeten voldoen:
1. De dossiers moeten on-line opvraagbaar zijn
Het tijdrovende zoeken naar de benodigde dossiers komt hiermee te vervallen. Telefonische
vragen van relaties kunnen zeer snel worden beantwoord.
2. De dossiers dienen gelijktijdig benaderbaar te zijn
De verschillende cliëntenadviseurs en procuratiehouders van de diverse bedrijven dienen
de dossiers gelijktijdig te kunnen benaderen. Het kopiëren van dossiers of gedeelten daaruit
komt hiermee te vervallen.
3. Er dient statusinformatie beschikbaar te zijn
De status van de werkzaamheden, die voortvloeien uit de aanwezigheid van een dossierstuk, moeten op een eenvoudigere wijze kunnen worden opgevraagd. Hierdoor is een beter
beheer van de uit te voeren werkzaamheden mogelijk.
C.4.3
Tools, methoden en technieken
Leverancier WANG beschikte destijds niet over pakketten om een dergelijk (workflow)systeem
te realiseren. Er is daarom ervoor gekozen het systeem in de PACE 4GL databaseomgeving in
combinatie met het WIIS image systeem te ontwikkelen. Er zijn werkgroepjes geweest, waarin
de betrokken functionarissen samen met een programmeur van WANG een deel van het system
hebben gemaakt.
C.4.4
Het dossier
Alvorens in te gaan op de verwerking van de post, is het belangrijk vast te leggen hoe het dossier
eruit ziet. Per cliënt wordt één dossier bijgehouden. Alle inkomende en uitgaande stukken
met betrekking tot een cliënt, ongeacht de bedrijven waarop de stukken betrekking hebben,
worden opgeborgen in het dossier. Dit dossier wordt veelvuldig door cliëntenadviseurs en
procuratiehouders geraadpleegd bij het afwerken en controleren van lopende zaken.
155
C.4. Analyse en ontwerp
C.4.5
Deelprocessen
We kunnen het proces wat in het MI2-systeem is vastgelegd opdelen in vier deelprocessen, te
weten:
1. Verwerking van inkomende post
2. Verwerking van uitgaande post
3. Batchverwerking
4. Opvragen van dossiers
Het proces, voor zover het de verwerking van de inkomende en uitgaande post betreft, staat
weergegeven in figuur C.1. In deze figuur staat een rechthoek voor een activiteit en een ruit voor
een beslissing. In de volgende subparagrafen zullen deze deelprocessen nader worden toegelicht.
Verwerking van inkomende post
De verwerking van de inkomende post, zoals dat in het systeem is vastgelegd, gebeurt in een
aantal stappen, die achtereenvolgens beschreven zullen worden. Het statusdiagram van een
inkomend poststuk staat weergegeven in figuur C.2
1. Sorteren en scannen
De inkomende post wordt gesorteerd in de volgende categorieën:
post die niet interessant is voor het dossiersysteem. Hieronder vallen nota’s van
leveranciers, foldermateriaal, etc.)
post die wel interessant is voor het dossiersysteem. Deze post wordt gescand met
behulp van WIIS. Het resultaat van deze stap is:
– Een WIIS-image op magnetic disk
– Een record in de PACE-tabel
Het PACE-record bevat een aantal relevante gegevens omtrent het inkomende poststuk,
zoals
– Het relatienummer. Dit wordt tijdens het scanproces (handmatig) toegekend
– Het WIIS-document-identificatienummer
– De datum en tijd waarop het poststuk is gescand
Het dossierstuk krijgt nu de status Te indexeren en een indicatie dat het WIIS-image is
opgeslagen op schijf.
RESULTAAT sorteren en scannen
Een WIIS-image op magnetic disk
Een record in de PACE-tabel Dossier-stuk
Nieuwe status Te indexeren
2. Indexeren inkomende post.
Tijdens de indexatiestap worden gescande ingekomen poststukken voorzien van één of
meer kenmerken. Deze indexatiestap heeft twee doelstellingen, te weten:
(a) Een key aan het dossier toe te kennen, waardoor het terug te vinden is in het archief;
(b) Kort aan te geven wat de inhoud is van het stuk.
156
INKOMENDE POST
post
Administratieve
ondersteuning
Stap 1
scannen
Stap 2
indexeren
Stap 3
Stap 4
Clienten
adviseur
Procuratie
houder
accorderen
verwerk
verwerk
afgewerkt
beoordelen
Stap 5
post goed?
post tekenen
en document
beveiligen
UITGAANDE POST
Stap 1
Stap 2
WPplusdoc
indexeren
Stap 3
accorderen
Stap 4
post inpakken
en versturen
Figure C.1: Postverwerking binnen het MI2-systeem
status terug
naar AF TE
WERKEN
157
Inkomend
poststuk
Scannen
Te indexeren
dossierstuk
WIIS-image
etc
Indexeren
Te accorderen
kenmerk
Te accorderen
kenmerk
Accorderen
etc
Af te werken
kenmerk
Niet correct
bij controle
Afwerken
Afgewerkt
kenmerk
WPPLUS
Diskfile
WPPLUS
document
zie bij
uitgaande post
Figure C.2: Het statusdiagram van een inkomend poststuk
Zoals al in de procesbeschrijving werd gesteld kan een inkomend poststuk betrekking
hebben op meer dan een bedrijf en meer dan een onderwerp. Om hiermee om te kunnen
gaan kunnen aan het poststuk meerdere kenmerken worden toegekend. In dat geval heeft
elk kenmerk betrekking op een onderwerp en bestaat het uit de volgende gegevens:
Kenmerk
nummer
1
2
De code van het bedrijf waarop het kenmerk betrekking heeft.
Maximaal vier niveau’s van trefwoorden die in het kort het onderwerp karakteriseren.
Herkomst
In/Uit
I
I
Bedrijfscode
IL
SV
Trefwoord
1
AANVRG
BRIEF CLIENT
Trefwoord
2
BROCH
SCHADE
Trefwoord
3
RISICO
AUTO
Trefwoord
4
DIVERSEN
ANDERE MAATSCHAPPIJ
Table C.3: Voorbeeld van een indexatie
Voor elk kenmerk wordt een record in de PACE-tabel Stuk-kenmerk opgenomen.
opgenomen kenmerk krijgt de status Te accorderen.
RESULTAAT indexeren inkomende post
Een record in de PACE-tabel Stuk-kenmerk
Nieuwe status Te accorderen
Het
158
3. Accorderen van kenmerken.
Het document is inmiddels bij de cliëntenadviseur aangekomen. Voordat hij met de daadwerkelijke afwerking van het dossierstuk begint, controleert hij de toegekende kenmerken
aan de hand van het gescande document. In deze stap, die accorderen wordt genoemd,
is het mogelijk om nieuwe kenmerken toe te kennen en reeds toegekende kenmerken te
wijzigen of te verwijderen. Het kenmerk krijgt nu de status Af te werken.
Indien alle kenmerken van een inkomend dossierstuk de status Af te werken hebben gekregen, krijgt het dossierstuk de indicatie Te kopiëren naar OD (=optical disk).
RESULTAAT accorderen van kenmerken
Nieuwe status Af te werken en Te kopiëren naar OD
4. Afwerken van onderwerpen.
Het dossierstuk blijft bij de cliëntenadviseur die overgaat tot de afwerking ervan. De
acties die daarbij kunnen worden genomen zijn beschreven bij de procesbeschrijving. De
verslagen worden vastgelegd in WPplus documenten, welke later in het dossier zullen
worden opgenomen. De status verandert na deze stap in Afgewerkt.
RESULTAAT afwerken van onderwerpen
WPplus document
Nieuwe status Afgewerkt
5. Controleren van de afwerking.
Aan de hand van het inkomende poststuk en de WPplus-documenten die zijn ontstaan
tijdens de afwerking van een onderwerp, controleert de procuratiehouder of de afwerking
op een correcte wijze is uitgevoerd. Indien dit niet het geval is, krijgt het kenmerk opnieuw
de status Af te werken. De betreffende cliëntenadviseur moet in dat geval het onderwerp
opnieuw afwerken.
RESULTAAT controleren van de afwerking
Nieuwe status Af te werken of Afgewerkt
Verwerking van uitgaande post
In het proces van de verwerking van uitgaande post zijn ook een aantal stappen te onderkennen.
1. Opnemen van uitgaande post.
In deze stap worden twee gevallen onderscheiden:
Opnemen van een WPplus-document.
Scannen van overige uitgaande post.
Een WPplus-document dat in een dossier moet worden opgenomen, wordt geconverteerd
naar een consecutive VS-file. Deze conversie is een voorbereiding van de opslag van het
document op optical disk.
Tijdens het opnameproces wordt aan het dossierstuk een relatienummer toegekend. De
opname van een WPplus-document resulteert in:
Een consecutive VS-file op magnetic disk.
Een record in de PACE-tabel Dossier-stuk.
159
Zie bij
inkomende post
WPPLUS
Diskfile
Opnemen
Uitgaand
poststuk
Te indexeren
dossierstuk
Consecutive
VS-file
Scannen
etc
Indexeren
Te accorderen
kenmerk
Te accorderen
kenmerk
Accorderen
etc
Afgewerkt
kenmerk
Figure C.3: Het statusdiagram van een uitgaand poststuk
Het PACE-record bevat een aantal relevante gegevens omtrent het uitgaande poststuk, zoals:
het relatienummer, het WPplus-documentnummer en de datum en tijd waarop het poststuk
is opgenomen. Het uitgaande dossierstuk krijgt de status Te indexeren en een indicatie dat
het dossierstuk is opgeslagen op magnetic disk.
RESULTAAT opnemen van uitgaande post
Een consecutive VS-file op magnetic disk
Een record in de PACE-tabel Dossier stuk
Nieuwe status Te indexeren
2. Indexeren van uitgaande post.
Uitgaande poststukken worden voorzien van een of meer kenmerken. Deze indexering
gebeurt op dezelfde wijze als het indexeren van inkomende post.
RESULTAAT indexeren van uitgaande post
Nieuwe status Te accorderen
3. Accorderen van kenmerken.
Hoewel uitgaande post niet meer afgewerkt behoeft te worden daar het uitgaande stuk het
resultaat is van de afwerkingsstap, worden de toegekende kenmerken aan de hand van het
opgenomen document gecontroleerd. Tijdens deze activiteit kunnen kenmerken akkoord
worden bevonden. In dit stadium is het mogelijk om nieuwe kenmerken op te nemen en
bestaande kenmerken te wijzigen of te verwijderen. Na de accordering krijgt het kenmerk
de status Afgewerkt.
Als alle kenmerken van een uitgaand dossierstuk de status Afgewerkt hebben gekregen,
krijgt het dossierstuk de indicatie Te kopiëren naar OD. Voor uitgaande post zijn de processen
afwerken en controleren niet gedefinieerd.
160
RESULTAAT indexeren van uitgaande post
Nieuwe status Afgewerkt
Batchverwerking
Van dossierstukken waarvan alle kenmerken zijn geaccordeerd, kunnen de bijbehorende magnetic
diskfiles worden overgeplaats naar optical disk. Deze dossierstukken hebben de indicatie Te
kopiëren naar OD. Tijdens deze batchjob, waarvan de werkwijze door parameters kan worden
ingesteld, worden de volgende acties uitgevoerd:
1. Kopiëren van files naar optical disk.
De magnetic diskfiles, behorende bij dossierstukken met de indicatie Te kopiëren naar OD,
kunnen worden gekopieerd naar optical disk. Het tijdstip waarop dit moet worden uitgevoerd, wordt door middel van een parameter vastgelegd. De keuze van de optical disk
in de juke-box wordt bepaald aan de hand van de eerste letter van de achternaam van de
cliënt. Na het kopiëren krijgen de bijbehorende dossierstukken de indicatie Opgeslagen op
OD.
2. Verwijderen magnetic diskfiles.
De magnetic diskfiles behorende bij de dossierstukken met de indicatie Opgeslagen op OD
kunnen worden verwijderd. Voordat tot verwijdering wordt overgegaan, wordt nagegaan
of er binnen het dossiersysteem geen enkele verwijzing naar de magnetic diskfile meer
aanwezig is.
Opvragen van dossiers
Dossiers kunnen op diverse manieren worden opgevraagd. De meest gebruikelijke manier is het
opvragen van een dossier van één bepaalde cliënt. Daarbinnen zijn selecties mogelijk op bedrijf,
trefwoorden, etc.
Het opvragen van dossiers die voldoen aan willekeurige selecties is voorbehouden aan de dossierbeheerders.
C.4.6
Overige functies
Systeemgegevens en systeembeheer
Het MI2-systeem is zodanig opgezet dat zo weinig mogelijk hard coded verwijzingen in de programmatuur zijn opgenomen. Dit heeft het belangrijke voordeel dat de programmatuur in hoge
mate systeemonafhankelijk is. Een belangrijk voordeel van een workflowsysteem is hiermee
gerealiseerd. Verwijzingen naar hardware, benamingen van files en instellingen van batchjobs
zijn opgenomen als parameters in een aantal systeemtabellen:
Algemene systeemparameters
Verwijzingen naar WPplus-libraries en WPplus-documenten
Verwijzingen naar magnetic en optical diskvolumes en -libraries
Parameters ten behoeve van de uitvoering van batchjobs
Met behulp van een aantal systeembeheerfuncties zijn deze tabellen on-line muteerbaar. Binnen
dit systeembeheer vallen bovendien een aantal speciale dossierbeheerfuncties zoals het verwijderen van dossiers, het wijzigen van relatienummers van dossiers, het beheren van de gebruikersmenu’s, etc.
C.5. Invoering
161
Menustructuur en menubeheer
Binnen het MI2-systeem is een eigen menustructuur opgenomen. Deze structuur is door de
beheerder on-line aan te passen via menubeheerfuncties. Alle functies binnen het systeem zijn
gegroepeerd tot zogenaamde functiegroepen. Per gebruiker wordt aangegeven welke functies
door hem/haar uitgevoerd mogen worden. Binnen het MI2-systeem is een menugenerator
opgenomen die per gebruiker alleen die functiegroepen en daarbinnen die functies laat zien
waartoe hij/zij geauthoriseerd is.
Systeeminstallatie en -onderhoud
Voor de technische installatie en het onderhoud van het system zijn twee extra functies aanwezig
die evenwel niet kunnen worden opgenomen in de menustructuur:
Tijdens de installatie wordt voor de gebruiker (degene die het systeem installeert) de menustructuur gevuld met de functie Onderhoud menustructuur. Vanuit dit startpunt kan de
volledige menustructuur voor alle gebruikers worden opgebouwd.
Voor het technische onderhoud van het systeem is een functie aanwezig om coderingen van
de programmatuur, indien nodig, aan te passen. Deze codering wordt zowel gebruikt in
de menustructuur als in de programmatuur zelf. Aanpassingen zijn alleen nodig indien
nieuwe functionaliteit aan het systeem wordt toegevoegd.
Authorisatie
Binnen het MI2-systeem wordt onderscheid gemaakt in twee soorten authorisatie:
Authorisatie van functies
Authorisatie van gegevens
De functionele authorisatie is enerzijds vastgelegd in de programmatuur (schermdefinities) en
anderzijds in de PACE data dictionary, waarbij gebruik wordt gemaakt van de securityfaciliteiten
van het VS-systeem.
C.4.7
Er is geen duidelijke scheiding aan te brengen tussen de ontwerp-, realisatie- en tuningfase van
het systeem. Er is sprake geweest van een iteratief proces. Ten allen tijde was er sprake van
een werkend systeem, wat naar aanleiding van wensen en opmerkingen van de gebruikers is
aangepast.
C.5
Invoering
C.5.1
Keuzes
Er is voor gekozen de gebruikers intern op te leiden. Dit lag voor de hand, daar gehele organisatie
sterk betrokken is geweest bij de ontwikkeling. De meeste kennis over het systeem was dus binnen
MedIns zelf.
C.5.2
Stappen
De opleiding van de gebruikers is steeds in groepjes gebeurd. De meeste aandacht is besteed aan
de eerste drie stappen, te weten scannen, indexeren en accorderen. De reden hiervoor ligt in het
feit dat dit zeer belangrijke stappen zijn om de documenten de rest van de workflow correct te
laten volgen. Hiervoor is een team samengesteld, bestaande uit:
162
1. Een vertegenwoordiger van automatisering met kennis over het systeem
2. Een medewerker van administratieve ondersteuning
3. Een cliëntenadviseur
De personen binnen de verschillende functies in dit team zijn echter wel gevarieerd. Op deze
manier ontstond er consensus binnen de organisatie omtrent de te volgen methode bij deze
stappen. Dit traject heeft ongeveer anderhalf jaar in beslag genomen. De overige activiteiten in
de workflow zijn vrij specifiek, en daarom zijn de opleidingen hieromtrent alleen gegeven aan de
betreffende functionarissen.
C.5.3
Realisatie
Hard- en software
Voor het invoeren van het MI2 systeem beschikte MedIns over een WANG VS 5460 (netwerk-)systeem. Dit systeem bestond uit een server met daaraan gekoppeld een aantal (domme) terminals
en een magnetische schijfeenheid. Dit staat weergegeven in figuur C.4. Op deze server draaide
een Cobol applicatie voor de premieberekeningen, offertes etc. en het WPplus pakket voor de
correspondentie. Ten behoeve van het MI2-systeem zijn er een aantal toevoegingen en wijzigingen
gedaan. De toevoegingen zijn in figuur D.8 weergegeven met stippellijnen. Ze worden hieronder
toegelicht:
1. Op de server is ook de PACE 4GL databaseomgeving gaan draaien ter ondersteuning van
het MI2 systeem
2. Voor de imagefaciliteiten draait het WIIS pakket ook op de server
3. De terminals zijn vervangen door 31 werkstations (lees: PC’s) met A4-schermen en windowsfaciliteiten
4. Alle gescande documenten worden opgeslagen op vijftig 5,25 inch WORM schijven in een
jukebox met een opslagcapaciteit van 47 Gb
Before MI2
WANG VS 5460
- Cobol appl.
- WPplus
With MI2
Magnetical
disc unit
WANG VS 5460
- Cobol appl.
- WPplus
- PACE
- WIIS
Terminals
Optical
disc unit
Magnetical
disc unit
Terminals
Image terminals
Scanner
Figure C.4: De infrastructuur van het MI2-systeem
C.6. Evaluatie systeem
163
Integratie met bestaande systemen
Het MI2 dossierbeheerssysteem is in eerste instantie ontwikkeld als een zelfstandig dossierbeheerssysteem. Naast het MI2-systeem zijn bij MedIns enkele systemen in gebruik die een
dusdanig zelfstandig karakter hebben dat een koppeling met het MI2-systeem weinig nut zou
hebben of zeer veel moeite zou kosten. Zo beschikt MedIns over een systeem voor het genereren
van contracten voor de overnames van praktijken etc. Ook de financiële administratie beschikt
over een eigen systeem.
Integratie met WPplus
De integratie met WPplus bestaat uit het benaderen van de administratieve gegevens van WPplusdocumenten en het verwijderen van deze documenten nadat de bijbehorende consecutive VS-files
op optical disk zijn geplaatst. Voor deze activiteiten wordt gebruik gemaakt van WPplus-API’s.
Koppeling op gegevensniveau
In het MI2-systeem wordt gebruik gemaakt van gegevens uit het bestaande informatiesysteem.
Deze gegevens zijn:
Relatiegegevens
Rayongegevens
Deze gegevens zijn vastgelegd in indexed VS-files die worden onderhouden door het bestaande
informatiesysteem. In het MI2-systeem zijn de relatie- en rayongegevens gedefinieerd door
middel van PACE-tabellen en zijn uitsluitend opvraagbaar.
Koppeling op applicatieniveau
Op applicatieniveau bestaat de koppeling van de MI2-programmatuur met het bestaande informatiesysteem uit het aanroepen van de contacthistorieprogrammatuur. Er is geen directe
koppeling aanwezig vanuit de bestaande programmatuur met de MI2-programmatuur.
C.6
Evaluatie systeem
Nadat het systeem bij MedIns volledig operationeel was, heeft er een evaluatie plaatsgevonden,
op basis van een enquete onder de gebruikers. Deze enquête is enkele maanden na de invoering
van het systeem uitgevoerd door een HEAO-studente.
De volgende overwegingen hebben de MedIns ertoe aangezet over te gaan tot de invoering van
dit systeem. Zij lenen zich dan ook in meer of mindere mate tot evaluatie.
1. Het verbeteren van het dossierbeheer
De voordelen die op dit gebied te behalen zijn, zijn objectief vast te stellen, voornamelijk
door de ervaringen van de gebruikers te peilen.
2. Het verbeteren van de concurrentiepositie
Dit beoogde voordeel is binnen het kader van dit onderzoek niet vast te stellen.
3. Het bijdragen aan het professionele imago van MedIns
Dit voordeel is zeer subjectief en daarom ook lastig vast te stellen. Vanzelfsprekend kan
gesteld worden dat het online beschikken over de juiste informatie betreffende een cliënt
een professioneel beeld naar buiten toe schetst.
164
4. Het realiseren van een forse omzetgroei met hetzelfde aantal medewerkers
Met name door voordelen met betrekking tot doorlooptijdbewaking en knelpuntsignalering
kan hier wel een oordeel over geveld worden. MedIns heeft steeds meer afdelingen van
de organisatie bij het systeem betrokken. Hiervoor zijn echter geen extra medewerkers
aangenomen. Door MedIns zelf is reeds geconstateerd dat de performance van het systeem
achteruit gaat door de zware belasting van de server. Er wordt onderhandeld met WANG
over de levering van een zwaardere machine.
C.6.1
Effecten op gebruikers
De resultaten van deze evaluatie laten zich als volgt samenvatten.
Alle gebruikers waren het erover eens dat ze in een stakker keurslijf gegoten zijn. Dit wordt
echter niet als negatief ervaren. De werksfeer was onveranderd gebleven. Al met al werden de
volgende voordelen geconstateerd:
routinematige dagindeling; de oude chaotische manier van dossierverkeer was iedereen
een doorn in het oog.
efficiëntieverbetering;
kostenbesparing op het gebied van de verfilming;
meer service naar de klant toe, wegens snelle toegankelijkheid van de dossiers.
daar staat echter tegenover dat de flexibiliteit van het werk is afgenomen De overschakeling
van fysiek document naar image is iets waar de gebruikers aan moesten wennen. Na een
gewenningsperiode treden hieromtrent geen problemen meer op. Bovendien heeft de klant er
niets van gemerkt.
C.6.2
Effecten op de relatie met klanten
Het contact met klanten is niet toe of afgenomen. Een groot voordeel van dit systeem, is dat
klanten bij vragen direct geholpen kunnen worden door een willekeurige persoon en dus niet
later teruggebeld worden.
C.6.3
Totaaloordeel
De conclusie die volgt uit de binnen MedIns uitgevoerd enquete is als volgt samen te vatten.
De invoering van het dossier beheerssysteem heeft tot onvermijdelijke veranderingen geleid in
de organisatie. Na een inleerperiode van de gebruikers zijn de meeste problemen en weerstanden
echter overwonnen. Het systeem heeft tot een grote verbetering van de service naar de klant toe
geleid.
C.6.4
Mogelijke verbeteringen
Met betrekking tot de flexibiliteit is er nog ruimte voor verbetering. Het systeem is niet gerealiseerd met een workflow-tool, om de simpele reden dat dit op het moment van ontwikkeling
nog niet voor handen was. Dit heeft echter wel als nadeel dat wijziging dicht bij de gebruiker niet
of nauwlijks gerealiseerd kunnen worden zonder tussenkomst van een WANG-programmeur.
C.7. Evaluatie project
C.7
Evaluatie project
C.7.1
Realisatie van doelen
165
Voor aanvang van het project heeft de leverancier (WANG) een aantal voordelen in het vooruitzicht gesteld met betrekking tot de organisatie. Na realisatie zou er, ten opzichte van de oude
situatie, sprake zijn van
een efficiënter dossierbeheer;
tijdsbeparing m.b.t. het raadplegen van een dossier;
besparing bij het archiveren;
functionaliteitsverbetering naar de gebruikers;
besparingen op papier en afdrukapparatuur.
Uit de uitgevoerde evaluatie blijkt dat al deze verwachtingen zijn waargemaakt. Met betrekking
tot de tijdsbesparing bij het oproepen van een dossier kan het volgende opgemerkt worden.
Door de imagingtechniek is een enorme tijdsbesparing bij het raadplegen van een dossier bereikt.
In het on-line gebruik van het systeem bleek dat de oproeptijd van een dossier, dit liep op tot 35
seconden, toch nog te groot was. Derhalve is besloten de in behandeling zijnde dossiers op een
magnetische schijf te bewaren. Op het moment dat deze dossiers niet meer in actieve behandeling
zijn, worden ze overgezet naar optische schijf. De raadpleegtijd is hierdoor verkort naar ongeveer
3 seconden.
C.7.2
Toepassing van de methode
Daar er nauwlijks sprake is geweest van een methode, kan hierover moeilijk een oordeel worden
geveld. Wel is het belangrijk op ge merken dat de gebruikers altijd actief geparticipeerd hebben
in de ontwikkeling van het systeem. De waardering binnen de organisatie is door deze actieve
betrokkenheid gegarandeerd.
C.7.3
Totaaloordeel
Het MI2-project mag geslaagd genoemd worden. De gestelde eisen zijn gerealiseerd, zonder
dat hierbij problemen optraden die vantevoren niet voorzien waren. Door voorloper te zijn in
deze technologie is de kosten/baten-analyse zeer positief uit gaan vallen, daar de leverancier het
systeem kostenloos heeft ontwikkeld. Hoewel de gebruikers in een strakker keurslijf zitten zijn er
geen problemen met de acceptatie. Dit is waarschijnlijk te danken aan de vroegtijdige en actieve
betrokkenheid van de gebruikers.
C.8
Conclusies en aanbevelingen
C.8.1
Het onderzoek is voorspoedig verlopen. Er zijn gesprekken gevoerd met dhr. J. Keur en met
dhr. H. van der Markt van WANG. Hieruit is veel nuttige informatie naar voren gekomen,
met betrekking tot de organisatorische context en het ontwikkeltraject van het systeem. Ook
documentatie was voorhanden. Vooral de gebruikersevaluatie en de technische documentatie
van de leverancier waren waardevol.
166
C.8.2
Conclusies
Dit systeem is een succes, daar de beoogde resultaten zijn behaald. Het is niet een workflowsysteem in de zin dat werkstromen dicht bij de gebruiker veranderd kunnen worden. Daarvoor
is een PACE-applicatieprogrammeur nodig. De geringe flexibiliteit, zoals de gebruikers dat
ervaren is daarvan een symptoom. Dit systeem is een schoolvoorbeeld van het ontstaan van
een workflow-behoefte vanuit archiveringsproblematiek. De weg langs DIS is dan ook geheel
natuurlijk.
C.8.3
Aanbevelingen
Doordat kennis over het bedrijfsproces verzameld is en doordat er een electronische documentinfrastructuur is, liggen er goede kansen voor flexibiliseren en diversificeren van werkstromen.
Als eerste stap adviseren wij om strategische kansen in kaart te brengen en door middel van prioriteiten een plan uit te stippelen. Door het huidige succes heeft MedIns een goede uitgangspositie
voor verdere expansie in commerciële zin.
167
Appendix D
Het WA-12 rapport van ChamCom
Summary
In deze appendix is het gehele rapport bevat, voor zover dit het FLUSH project, zoals bij
ChamCom is uitgevoerd betreft. Het gaat hier om het rapport zoals dat naar de betrokken
organisatie is opgeleverd, met dien verstande dat deze versie is geanonimiseerd; de naam van
de organisatie is veranderd, evenals persoonsnamen. Tevens heeft het systeem een andere
naam gekregen. Voor de rest is het rapport onveranderd gebleven.
Doel van het hier beschreven FLUSH project is te komen tot een DIP-systeem met workflowfaciliteiten voor de begeleiding van het gehele traject van deponering en reproductie van (financiële) jaarverslagen van Nederlandse organisaties. Het is een succesvol project in die zin dat
het voldoet aan de eisen en wensen die ChamCom daar vantevoren aan heeft gesteld. De winst
op het gebied van efficiëntie en flexibiliteit is iets wat in de toekomst zal moeten blijken. De
combinatie van een grondige voorbereiding, de vroege betrokkenheid van gebruikers en een
soepel verlopend project geeft vertrouwen in het verdere verloop van de invoering van deze
technologie binnen ChamCom.
Dit rapport kent een achttal hoofdstukken waarin het gehele FLUSH project wordt beschreven.
D.1 Inleiding
D.1.1
beschouwd. Het doel van dit onderzoek is inzicht te krijgen in het ontwerp en de invoering van
dit soort systemen. Dit rapport beschrijft het workflowsysteem FLUSH. Dit is een systeem voor
de begeleiding van het traject van deponering en reproductie van (financiële) jaarverslagen van
Nederlandse ondernemingen. Het is een Document Image Processing-systeem dat door Data
General System Integration is ontwikkeld in opdracht van een Kamer van Koophandel in het
westen van Nederland.
D.1.2
Bereik
In dit rapport zal getracht worden een zo volledig mogelijk beeld te schetsen van het FLUSHproject. Hierbij komen zaken aan de orde als de aanleiding voor ontwikkeling van dit systeem,
het haalbaarheidsonderzoek, het verloop van het project, de analyse en het ontwerp van het
systeem en de organisatorische gevolgen hiervan op deze Kamer van Koophandel.
168
D. Het WA-12 rapport van ChamCom
D.1.3
Doelgroep
De doelgroep van dit rapport bestaat uit de betrokkenen bij de betrokken Kamer van Koophandel
(ChamCom) en de onderzoekers en begeleiders van het WA-12 project aan de Universiteit Twente.
Verder wordt iedere geı̈nteresseerde uitgenodigd dit rapport te lezen.
D.1.4
Structuur
Het rapport kent de volgende structuur. In paragraaf D.2 wordt een beschrijving gegeven van
het FLUSH-project. Paragraaf D.3 gaat verder met een uitgebreide procesbeschrijving, waarna in
paragraaf D.4 dieper in wordt gegaan op de analyse van het proces en het daaruit voortvloeiende
ontwerp van het systeem. Paragraaf D.5 gaat over de invoering van het systeem en de paragrafen
D.6 en D.7 behandelen de evaluatie van respectievelijk het systeem en het project. Het geheel
wordt afgesloten met paragraaf D.8, waarin conclusies worden getrokken en aanbevelingen
worden gedaan.
D.1.5
Terminologie
In deze paragraaf wordt een overzicht gegeven van de in dit rapport gebruikte terminologie.
Hierbij wordt zoveel mogelijk gebruik gemaakt van de terminologie die bij de ChamCom wordt
gehanteerd.
Afkortingen:
API Application Program Interface
DIP Document Image Processing
DIS Document Information System
FIS Het Financiële Informatiesysteem van de afdeling Financiële Administratie
HVS -register Handels- Verenigingen en Stichtingen register
IB&A De afdeling Informatiebeheer & Automatisering van de ChamCom
FLUSH Dit is de naam van het DIP-systeem van de ChamCom.
PART De afdeling voor postverwerking, postregistratie en archief
RMP Regionaal Mutatie Proces. Dit is een hoeveelheid programmatuur, waarmee de ChamCom’s in staat zijn hun registergegevens te onderhouden.
V-formulier Kapitaalopgaafformulier voor ondernemingen op basis waarvan de kamer de
jaarlijkse bijdrage bepaald
Definities en begrippen:
Workflow Management
Onder workflow management verstaat de ChamCom: alle programmatuur om administratieve processen te sturen en optimaal te ondersteunen. In wezen komt het neer op een
geavanceerde manier van queuen.
Jaarstuk
Een uit een of meer pagina’s bestaand document, waarin een rechtspersoon (N.V. of B.V.)
verslag uitbrengt van de financiële en organisatorische gang van zaken in het afgelopen
jaar.
Image
De digitale weergave van één pagina in het systeem.
D.2. Projectbeschrijving
169
D.2 Projectbeschrijving
D.2.1
De Kamer van Koophandel
Inleiding
ChamCom is een publiekrechtelijk orgaan van en voor het Nederlandse bedrijfsleven. In ons land
zijn 35 Kamers van Koophandel werkzaam die ieder een deel van het Nederlandse grondgebied
als hun werkterrein hebben. De ChamCom’s worden bestuurd door vertegenwoordigers van
ondernemers en werknemers van kleine, middelgrote en grote bedrijven. De financiering van
de ChamCom’s gebeurt door het bedrijfsleven middels een jaarlijkse bijdrage per ingeschreven
organisatie.
Taken
ChamCom heeft een drieledige funktie:
1. Belangenbehartiging bij de overheden door advisering en stimulering
Als pleitbezorger van het bedrijfsleven draagt de ChamCom bij en wendt zij haar invloed
aan in de besluitvorming van de (meestal lokale) overheid. De ChamCom probeert hiermee
een brug te slaan tussen de overheid en het bedrijfsleven.
2. Ondersteuning van bedrijven door voorlichting en dienstverlening
Een wat anoniemere, maar voor de kleinere bedrijven zeker zo interessante funktie is de
vraagbaak-, wegwijs- en bemiddelingsfunktie die de ChamCom vervult. Bij de ChamCom
is kennis aanwezig over uiteenlopende zaken waar ondernemers mee te maken kunnen
krijgen. Denk bijvoorbeeld aan subsidieregelingen, rechtsvormen en exportmogelijkheden.
3. Uitvoering van enkele economische wetten
Door de wetgever is de uitvoering van een aantal wetten aan de ChamCom toevertrouwd.
De Handelsregisterwet is daarvan de meest sprekende. Op grond van die wet dienen alle
bedrijven zich te laten inschrijven in het Handelsregister. Een soortgelijke plicht bestaat
voor verenigingen en stichtingen. Onder deze taak valt ook het toezicht op de correcte
naleving van de Vestigingswet, de Drank- en Horecawet en de Winkelsluitingswet. Sinds
de 4e EG-richtlijn heeft de Kamer er in dit kader een extra funktie bijgekregen, namelijk het
beheren van het Jaarstukkenregister en het zorgdragen voor een correcte naleving van de
plicht tot deponering door de betreffende organisaties.
Bij deze Kamer van Koophandel en Fabrieken zijn zo’n 60.000 bedrijven ingeschreven. Zij heeft
180 werknemers.
De afdeling Informatiebeheer & Automatisering (IB&A)
In toenemende mate wordt de dienstverlening van de ChamCom afhankelijk van geautomatiseerde systemen. De belangrijkste taak van de stafafdeling Informatiebeheer- & Automatisering is door middel van een adequate informatievoorziening bij te dragen aan de verwezenlijking
van de beleidsuitgangspunten die door de ChamCom als geheel en de afzonderlijke afdelingen
worden uitgezet. Naast een ondersteunende rol heeft IB&A in dit verband ook een initiërende en
katalyserende functie.
Belangrijke aandachtsgebieden zijn:
de zorg voor een optimale beschikbaarheid van de geautomatiseerde systemen
de verdere optimalisering van het gebruik van bestaande toepassingen
het starten van nieuwe ontwikkelingen in samenwerking met de gebruikersorganisatie
170
Met betrekking tot de informatievoorziening en automatisering zijn in het begin van 1992 een
tweetal audits gehouden. De eerste audit vond plaats in het kader van de jaarrekeningcontrole door de externe accountant en had betrekking op de beveiliging en continuı̈teit van de
geautomatiseerde systemen. Conclusie van dit onderzoek was dat voldoende maatregelen en
voorzieningen zijn getroffen, zij het dat op enkele onderdelen aanscherping gewenst is. In de
loop van 1992 is hierop actie ondernomen. De tweede audit had betrekking op het beleid met
betrekking tot de informatievoorziening en de wijze, waarop in de organisatie één en ander is gerealiseerd. Ook dit onderzoek gaf een positieve uitkomst. Er is een goede samenwerking tussen
de afdeling Informatiebeheer & Automatisering en de overige afdelingen van de ChamCom, hetgeen van groot belang is omdat informatieverwerking het primaire proces van de ChamCom is.
Een andere conclusie van de audit is dat de aanpak en realisering van de automatisering binnen
de ChamCom inhoudelijk en financieel op een verantwoorde wijze plaatsvindt [LH92].
D.2.2
Geschiedenis van de automatisering bij de ChamCom
Algemeen
In de tijd dat de ChamCom bestaat heeft zij letterlijk de ontwikkeling doorgemaakt van ganzeveer
tot terminal. De automatisering begon met databasetoepassingen voor het HVS-register. Hieruit
kon vrij gemakkelijk gehoor worden gegeven aan de binnengekomen verzoeken om informatie.
De automatisering ging verder met de invoering van systemen ter ondersteuning van de financiële
administratie, de postverwerking en de registratie van leverings- en betalingsvoorwaarden.
De 4e EG-richtlijn
Als gevolg van de 4e EG-richtlijn, die eind jaren ’80 zijn intrede deed, zijn N.V.’s en B.V.’s verplicht jaarlijks hun financiële jaarverslagen en instemmings- of aansprakelijkheidsverklaringen
bij de ChamCom te deponeren. Dit heeft tot gevolg dat bij de Rotterdamse ChamCom jaarlijks
ongeveer 20.000 jaarstukken en 1.500 verklaringen worden ontvangen en geregistreerd. In zijn
totaliteit spreken we hier over circa 107.500 images.
Deze stukken moeten door de afdeling handelsregister worden geregistreerd en permanent worden opgeslagen, om op een willekeurig later moment beschikbaar te zijn voor reproduktie (circa
12.500 afschriften/62.500 images per jaar) en inzage voor en door derden (circa 10.000 per jaar).
Verfilming of imaging
In eerste instantie zijn de jaarstukken in papieren vorm opgeslagen. Deze situatie was onhoudbaar. De omvang van het archief was enorm en jaarstukken waren zeer moeilijk vindbaar.
Oplossingen voor deze problematiek leken te worden geboden door de technieken verfilming of
imaging. De techniek van verfilming bood voordelen, daar
het een oudere, en dus bekende techniek is,
het weinig veranderingen in de organisatie teweeg zou brengen en
het een geringere investering vergt dan imaging,
maar ook nadelen, daar
er nog steeds handmatige storage en retrieval plaats moet vinden, met alle problemen van
dien (zoekraken, verkeerd opgeborgen, etc.) en
de dossiers niet gelijktijdig toegankelijk zijn.
Daarom werd met name gekeken naar de imaging techniek. Hieraan kleefden destijds nogal
wat nadelen. De toepassingen van toen vonden plaats op (netwerken van) PC’s en waren vrij
kleinschalig. De ChamCom heeft een infrastructuur gebaseerd op de IBM AS/400 en zocht een
171
toepassing die hierop aansloot. Op dat moment was een dergelijke oplossing niet voorhanden.
Het pakket FileNet van Olivetti was wel een optie. Dit pakket had echter een dusdanige omvang
en prijs dat een kosten/baten-analyse negatief zou uitpakken. De imagingtechniek viel op dat
moment af. Er werd echter niet uit het oog verloren dat de imagingtechniek dusdanige voordelen
bood dat wanneer de tijd en de techniek er rijp voor was, er op deze techniek kon worden
overgegaan. Snelheid en betrouwbaarheid van storage en retrieval en kosten speelden hierbij een
belangrijke rol.
D.2.3
Projectdoelen
Naast de (technische) eisen aan het systeem, zijn er vooraf een aantal doelen aan het FLUSHproject gesteld.
Het moet leiden tot een ontlasting van de werkdruk
Procedures moeten geautomatiseerd en geoptimaliseerd worden
Directe toegankelijkheid van jaarstukken na bewerking moet mogelijk zijn
Mogelijkheid tot directe informatieverstrekking aan het publiek
D.2.4
Projectorganisatie
Gedurende het gehele traject is getracht een zo breed mogelijke vertegenwoordiging vanuit de
organisatie te krijgen. In dit kader kan het ontwikkeltraject verdeeld worden in twee delen met
als scheidingspunt de leverancierskeuze.
Organisatie tot en met de leverancierskeuze
Gedurende dit deel van het traject is gewerkt met een projectgroep bestaande uit medewerkers
van de ChamCom aangevuld met een extern consultant. De samenstelling was als volgt:
het hoofd van de administratie afdeling HVS
een vertegenwoordiger van de afdeling systeembeheer en ontwikkeling
het hoofd van de afdeling IB&A
een vertegenwoordiging vanuit de gebruikers en
een extern consultant (DocWorld)
Organisatie vanaf de leverancierskeuze
Hier is gewerkt met een stuurgroep/projectgroep constructie, zoals dat bij projecten van Data
General gebruikelijk is. Algemeen gezien heeft de stuurgroep tot taak toe te zien op de correcte
uitvoering van het project. Praktisch gezien houdt dit in:
het beoordelen van de door de projectgroep opgestelde mijlpaalprodukten
het controleren van de voortgang van het project
het beslissen daar waar de beslissingsbevoegdheid van de projectgroep ontoereikend is
het vaststellen van de uitgangspunten
het beoordelen of en wat de consequenties van genomen besluiten zijn voor het afgesloten
contract
172
De stuurgroep had de volgende samenstelling:
een vertegenwoordiging van (het management van) de ChamCom:
– de algemeen secretaris
– het hoofd van de afdeling automatisering
een vertegenwoordiging van het management van de leverancier (Data General)
een onafhankelijke consultant met een verifiërende en bemiddelende funktie
Onder deze stuurgroep funktioneerde een projectgroep met verantwoordingsplicht naar de stuurgroep toe. De projectgroep is belast met de uitvoering en daadwerkelijke implementatie van
het project. Zij kende de volgende samenstelling:
een afvaardiging van de ChamCom:
– een vertegenwoordiger van systeembeheer en ontwikkeling
– een vertegenwoordiger van de gebruikers
– een vertegenwoordiger van IB&A
een afvaardiging van de leverancier (Data General):
– de projectleider
– de analist
D.2.5
Projectverloop
Tabel D.1 geeft aan welke stappen in het gehele traject van de probleemsignalering tot de
daadwerkelijke invoering onderkend kunnen worden.
Nr.
1
2
3
4
5
6
7
8
Stap
Gesprekken met gebruikers/Voorstudie
Voorlichtingssessies
Haalbaarheidsstudie
Besluit om workflow toe te gaan passen
Het funktionele ontwerp
Benadering en selectie van leveranciers
Mislukken project eerste leverancier
Ontwikkeling van het systeem
Invoering van het systeem
periode/duur
1989/1990
2e helft 1990
voorjaar 1991
zomer 1991
najaar 1991
voorjaar 1992
1992/1993
najaar 93
voorjaar 94
Table D.1: Stappen in het project
Gesprekken met gebruikers/Voorstudie
Door klachten van gebruikers over de administratieve verwerking van een aantal processen
is de afdeling IB &A van de ChamCom op zoek gegaan naar een oplossing. Deze oplossing
leek te komen met de invoering van imaging en WFM. De medewerkers van de afdeling informatievoorziening en automatisering hebben zich vervolgens uitgebreid geı̈nformeerd over de
workflow aanpak. Dit gebeurde middels het bestuderen van literatuur en artikelen, het bezoeken
van beurzen en het raadplegen van deskundigen. Het was duidelijk dat deze techniek vele
voordelen bood, waarvan op dat moment de meest belangrijke waren:
173
het meten van doorlooptijden en werkvoorraden wordt vergemakkelijkt (monitoring);
het wordt mogelijk processen te sturen (routing);
de flexibiliteit van de informatievoorziening neemt toe;
alle benodigde gegevens (data en images) voor iedere werkplek kunnen automatisch aan
de gebruiker op zijn werkplek worden aangereikt.
Er zijn vervolgens gesprekken gevoerd met gebruikers, waarbij de oplossing in de vorm van
WFM werd voorgesteld. De ChamCom heeft onderkend dat een grote betrokkenheid van de
gebruikers in deze fase al zeer belangrijk is. Vooral de omschakeling van papieren document
naar image is iets waar de gebruikers achter moeten staan. Deze betrokkenheid werd op dat
moment verkregen.
Voorlichtingssessies
Op het moment dat het project in samenwerking met de consultant wat meer tot stand is gekomen,
is een gebruikersvoorlichtingssessie gehouden. De doelgroep bestond uit:
de direct betrokkenen oftewel de uiteindelijke gebruikers;
het hoofd van de gebruikersafdeling en
een vertegenwoordiging van systeembeheer, met het oog op de uiteindelijke realisatie.
Tijdens deze sessie is geschetst wat de voordelen en veranderingen waren waar men rekening
mee moet houden bij de invoering van imaging en WFM in de organisatie. Omdat de voordelen
zo duidelijk waren was er op dat moment al commitment van de (toekomstige) gebruikers.
Haalbaarheidsstudie
In het voorjaar van 1991 heeft de ChamCom een haalbaarheidsstudie [KD91] laten uitvoeren
door het adviesbureau DocWorld uit Rotterdam. Deze had als doel een antwoord te geven op
de vraag of een DIP-systeem zou leiden tot kostenbesparing en efficiëntieverhoging. Een positief
antwoord op deze studie zou leiden tot een onderzoek naar en een mogelijke uitvoering van een
pilot-project. Een negatief antwoord zou de kamer duidelijkheid verschaffen over het feit dat de
toepassing van een DIP-systeem (voorlopig) niet haalbaar zou zijn.
Het haalbaarheidsonderzoek heeft 4 van de 18 processen bij de ChamCom onder de loep genomen.
Dit waren:
1. HVS-register
Dit proces is belast met het registreren van mutaties in het Handels- Verenigingen en Stichtingen register en het verstrekken van informatie uit dit register aan derden. De dossiers uit
dit register worden op vele andere afdelingen van de ChamCom gebruikt.
2. Jaarstukken
In dit proces worden de gedeponeerde jaarstukken verwerkt en wordt informatie hieromtrent aan derden verschaft. Dit proces vindt tevens plaats op de afdeling HVS-register.
De verwerkte jaarstukken worden gebruikt door de afdeling Financiële Administratie voor
het bepalen van de jaarlijkse bijdrage van de deposant.
3. Postverwerking, postregistratie en archief
Het verwerken, registreren, en archiveren van de dagelijks binnenkomende post. Deze
activiteiten vinden plaats op de afdeling PART.
174
4. Handelsnaamonderzoek
Het onderzoeken of de naam van nieuw op te richten bedrijven lijkt op of gelijk is aan
bestaande namen van bestaande bedrijven. Ook deze werkzaamheden vinden plaats op de
afdeling HVS-register.
In dit rapport zal slechts worden ingegaan op de resultaten van de studie naar de Jaarstukkenapplicatie. De haalbaarheidsstudie [KD91] stelt dat door gebruikmaking van DIP de volgende
besparingen en voordelen kunnen worden gerealiseerd:
1. Direct na verwerking is het jaarstuk voor iedere gebruiker vastgelegd.
2. Microfilmen is overbodig.
3. Sneller opzoeken van jaarstukken voor publiek.
4. Betere controle op nog te ontvangen jaarstukken van bedrijven.
5. Geautomatiseerde correspondentie bijvoorbeeld indien een jaarstuk niet aan de wettelijke
eisen voldoet, indien een jaarstuk nog niet is ontvangen en bij de afdeling Financiële Administratie de verwerking van de V-formulieren.
6. Besparing op microfilmapparatuur, verbruik films, jackets, etc.
Hierbij dienen echter de volgende kanttekeningen te worden gemaakt:
1. Voor het scannen van jaarstukken is een min of meer zelfde voorbewerking noodzakelijk
als nu bij microfilmen geldt.
2. Indien de scanner optimaal moet worden gebruikt en indien de kwaliteit van de gescande
jaarstukken gelijkmatig moet zijn, kan het noodzakelijk zijn van de te scannen jaarstukken
eerste fotokopieën te maken en de kopieën te scannen.
3. Het is goed mogelijk, dat door middel van een publieksterminal de jaarstukken worden
ingezien en dat men opdracht geeft tot het maken van een kopie, al dan niet met een
geautomatiseerde betaling.
De conclusie van het haalbaarheidsonderzoek laat zich als volgt samenvatten:
Bij invoering van document image processing moet de Kamer met het volgende rekening houden:
De procedures binnen een organisatie zullen veranderen. De processen worden korter,
beter te managen, maar ook anders. Het vereist dus flexibiliteit van de medewerkers.
De kwaliteit van het werkproduct verbetert voor de ChamCom zelf en voor het publiek.
Tevens heeft het een gelijkmatiger, lagere werkdruk tot gevolg.
Het vereist een belangrijke investering. Daar de invoering geleidelijk zal geschieden, zal de
besparing niet onmiddelijk worden gerealiseerd.
Het is inmiddels een volwassen technologie, waardoor de onderzochte applicaties, met
uitzondering van PART zonder risico kunnen worden gerealiseerd
Voor- en nadelen afwegend meent DocWorld, dat het in het voordeel is van de ChamCom om
met een pilot project aan te vangen. De volgende argumenten liggen hieraan ten grondslag:
1. De kosten/baten afweging bij de eerste twee applicaties pleiten ten gunste van DIP (een
besparing van fl. 500.000 op jaarbasis per proces);
2. Alle volgende applicaties zijn relatief goedkoop te realiseren;
175
3. De werkdruk van medewerkers wordt gelijkmatiger verdeeld en neemt af. Meer en kwalitatief beter werk kan met de huidige medewerkers of met minder medewerkers worden
verricht.
4. Bij de aansluiting op het bestaande AS/400 systeem worden geen problemen verwacht;
5. Het dienstenpakket van de ChamCom kan worden vergroot.
Voor een totaal en maximaal renderend gebruik van DIP is de huidige wetgeving echter een obstakel. De verouderde wetgeving voorziet niet in moderne technologie, ook niet als het doel van
de wet - het instand houden en te allen tijde toegankelijk zijn van de openbare gegevens van het
HVS-register - in stand blijft. In het licht van komende ontwikkelingen beveelt het haalbaarheidsonderzoek aan, alle mogelijke inspanningen te doen om tot wijziging van de huidige verouderde
wetgeving te komen en daarop vooruitlopend eventueel tezamen met andere ChamCom’s aan
het ministerie toestemming vragen met het oog op kostenbesparing en beveiliging van moderne
technologie gebruik te mogen maken, waaronder ook DIP valt.
In het haalbaarheidsonderzoek worden de eisen genoemd waaraan een project zou moeten voldoen, teneinde in aanmerking te komen voor een pilot. Het project moet:
belangrijk genoeg zijn;
niet te groot in volume zijn;
niet teveel gebruikers hebben;
geen of kleine conversie nodig hebben;
niet tijdkritisch zijn;
gemotiveerde medewerkers hebben.
Op basis van deze criteria beveelt het haalbaarheidsonderzoek de applicatie Jaarstukken aan voor
een pilot-project. Er is een kosten/baten-analyse gemaakt voor de applicatie jaarstukken zowel
voor wat betreft een totaal systeem als een pilot systeem. Hierbij zijn de volgende aannames
gedaan:
Gemiddelde investering
Afschijving systeem 5 jaar, conversie 10 jaar
Rente 9%
Besparing = 14 mensjaren à fl. 65.000,00; bij pilotproject 2 12 mensjaar
Onderhoud systeem 12%
besparing ruimte totaal 200m 2 (kasten, archieven etc.)
aanschaf alternatieve hard- en software fl. 690.000,00
afschrijving 5 jaar, rente 9%
De resultaten van de kosten/baten-analyse staan weergegeven in tabel D.2.
Besluit om workflow te gaan toepassen
Op basis van de uitgevoerde haalbaarheidsstudie was het management overtuigd van de te
behalen voordelen bij het invoeren van WFM. Er is echter gekozen om het eerst aan te pakken
project niet als pilot aan te merken, maar als beginpunt voor de invoering van WFM in de gehele
organisatie.
176
Item
Investering
Totaal systeem
1.600.000
Pilot systeem
800.000
Afschrijving
Rente
Onderhoud
Subtotaal
Gemiddelde conversie
Beeldplaten
Totale kosten per jaar
320.000
72.000
192.000
584.000
191.000
21.000
796.000
160.000
36.000
96.000
292.000
5.000
297.000
Mensjaren
Microfilmapparatuur
Afschrijving
Onderhoud/rente
Verbruiksmaterialen
Alternatieve programmatuur,
apparatuur en conversies
afschrijving
onderhoud/rente
ruimtebesparing
200m2 c.q. 52m2 á fl 250,00
Totaal besparingen per jaar
910.000
163.000
24.000
18.000
21.000
24.000
18.000
21.000
138.000
114.000
50.000
0
0
13.000
KOSTEN
BESPARINGEN
Per saldo
1.275.000
239.000
479.000 plus
58.000 min
Table D.2: Verwachte kosten en besparingen voor de applicatie jaarstukken
Het funktionele ontwerp
Zoals het haalbaarheidsonderzoek al voorstelde, leek de registratie van Jaarstukken de meest
geschikte toepassing om als eerste aan te pakken. Naast het feit dat het aan de gestelde eisen
voldeed, bood het voor de ChamCom nog een aantal aanvullende voordelen, namelijk:
de problemen met en bezwaren tegen verfilming (zie x2.2.2 en x3.6) werden verholpen,
waardoor er
onmiddelijk rendement ontstond en
het was een mooi startpunt voor vervolgapplicaties.
Het funktionele ontwerp voor de applicatie van jaarstukken is vervolgens opgesteld door een
werknemer van de afdeling IB&A in samenwerking met het hoofd van de gebruikersafdeling.
Benadering en selectie leveranciers
De aanbodzijde van de markt voor workflowmanagementsystemen was vrij onbekend. Er is
daarom bewust gekozen voor een zorgvuldige leveranciersselectie. Voor de begeleiding van deze
stap in het traject is wederom gebruik gemaakt van de diensten van adviesbureau DocWorld uit
Rotterdam [Kre92b]. Er is gekozen voor een gefaseerde benadering. Deze verliep in 10 stappen.
1. Nominatie van 17 leveranciers
Uit een lijst van 23 potentiële leveranciers zijn er 17 gekozen.
2. Invullen van vragenlijst door 17 leveranciers
Aan de geselecteerde leveranciers is een vragenlijst met 12 vragen toegestuurd, met het
177
verzoek deze vragen kort en bondig te beantwoorden. Deze vragenlijst ging vergezeld met
een korte uitleg omtrent de te realiseren applicaties en een beschrijving van de activiteiten
van de ChamCom.
3. Selectie naar 8 leveranciers
De antwoorden op de vragenlijst vormden het enige selectiecriterium. De beoordeling
is mede gemaakt op de zakelijkheid en vakbekwaamheid waarmee de vragen werden
beantwoord.
4. Presentatie van systeem en bedrijf door 8 leveranciers
De overgebleven 8 leveranciers werden uitgenodigd om aan de projectgroep het product
en het bedrijf te presenteren. Iedere leverancier had 1,5 uur de tijd om een presentatie te
geven. Vervolgens was er gelegenheid tot het stellen van vragen en een discussie.
5. Selectie van 6 leveranciers
Op basis van de indrukken opgedaan in de hierboven beschreven stap is een selectie gedaan
naar 6 leveranciers.
6. Nadere vragenlijst en bezoeken aan leveranciers en gebruikers
De overgebleven 6 leveranciers ontvingen een nieuwe vragenlijst, aangevuld met de relevante delen van het haalbaarheidsonderzoek. Met al deze leveranciers werden opnieuw
gesprekken gevoerd en werd een bezoek gebracht aan de hoofdvestiging van deze leverancier alsmede, voor zover mogelijk, aan een gebruiker.
7. Selectie naar 3 leveranciers
Op basis van de indrukken opgedaan in bovenbeschreven stap is een selectie gemaakt naar
3 leveranciers.
8. Aanvraag voor offerte
De overgebleven leveranciers waren volgens het oordeel van de projectgroep allen in staat
een systeem op te leveren, dat voldeed aan de door de ChamCom gestelde eisen en wensen.
De bedrijven is verzocht een offerte in te dienen, waarin de volgende zaken aan de orde
zouden komen:
prijsstelling;
garantie en onderhoud;
commitments;
systeem software (keuze pakket);
systeem ontwikkeling en documentatie;
groeipad (ontwikkeling nieuwe applicaties);
training;
mogelijkheid tot verkoop van systeem aan andere ChamCom’s;
koppeling met AS/400.
9. Beoordeling van offerte en onderhandeling
De drie offertes werden allen op tijd bij de ChamCom ingediend. Met ieder bedrijf zijn
toen nog minimaal twee gesprekken gevoerd om tot een uiteindelijke configuratie en prijs
te komen.
10. Keuze van de leverancier
De laatste selectie is gedaan op basis van prijs en verschillen in configuratie.
De selecties waren altijd gebaseerd op de vraag of de bedrijven die niet afvielen voldoende
vertrouwen boden om de procedure te vervolgen. Het is niet belangrijk welk bedrijf afvalt, maar
het is belangrijk welk bedrijf overblijft.
Met de geselecteerde leverancier is het project mislukt. Dit had vele oorzaken, waarvan de
belangrijkste waren:
178
Er werd teveel gewerkt met under-contractors, waarbij verantwoordelijkheden werden
afgeschoven.
De koppeling met de AS/400 kon niet tot stand worden gebracht.
Het gebruikte pakket werd niet meer door de Nederlandse distributeur ondersteund.
Het contract wat de ChamCom met deze leverancier had afgesloten was echter van dien aard
dat de schade bij de ChamCom in de hand gehouden kon worden. De ChamCom heeft het
vertrouwen in de technologie echter niet verloren, en men is vervolgens verder gegaan met
nummer 2 op de lijst, Data General. Deze was geschrokken van het mislukken van dit project,
maar had in de tussentijd een enigszins vergelijkbaar systeem gerealiseerd.
Ontwikkeling van het systeem
De ontwikkeling van het systeem is zonder problemen verlopen. Data General is ten allen tijde
bereid geweest om ad hoc veranderingen aan te brengen en te voldoen aan nieuwe wensen
ten aanzien van het systeem. Het aanvankelijk gesignaleerde probleem, de koppeling van de
software aan de IBM AS/400, is opgelost. Data General laat deze software ontwikkelen bij het
rekencentrum van de ChamCom’s.
Invoering van het systeem
Hiervoor wordt verwezen naar paragraaf 5.1.
D.2.6
Conversie
In het haalbaarheidsonderzoek worden de kosten geschetst voor de conversie van verfilmde
stukken en stukken die de ChamCom in papieren vorm heeft opgeslagen. Hier zal niet verder op
worden ingegaan, daar de ChamCom er voor gekozen heeft geen conversie uit te voeren van oude
jaarstukken. De motivatie hierachter is dat de vraag naar oude jaarstukken zeer snel afneemt op
het moment dat er een nieuw jaarstuk van dat bedrijf verschijnt. Een kosten/baten-analyse zou
negatief uitpakken.
D.3 Procesbeschrijving
D.3.1
Doel
In dit hoofdstuk zal dieper in worden gegaan op het proces wat aan de FLUSH-applicatie ten
grondslag ligt. Het doel van dit proces is het controleren en vastleggen van gedeponeerde
jaarstukken en het verschaffen van informatie en reprodukties aan derden hieromtrent. Bij de
beschrijving van het proces wordt nog uitgegaan van de situatie voor de introductie van het
FLUSH-systeem. Dit ter vergelijking met het nieuwe proces, dat in de paragraaf D.4 Analyse en
ontwerp uitgebreid aan de orde zal komen.
D.3.2
Voorwaarden
De ChamCom registreert de ontvangst van het jaarstuk en maant aan indien na verloop van
13 maanden geen jaarstuk is ontvangen. Aan de Staatscourant wordt de registratie van ieder
jaarstuk gemeld. Tevens is de kamer verplicht het publiek op verzoek jaarstukken ter inzage te
geven. Voor dit doel worden de jaastukken na diverse bewerkingen gemicrofilmd. De afdeling
Financiële Administratie gebruikt de (originele) jaarstukken om de indeling van de rechtspersonen in de tariefgroepen ten behoeve van de jaarlijkse bijdrage te controleren. Incidenteel worden
jaarstukken ook door andere afdelingen geraadpleegd.
D.3. Procesbeschrijving
179
Na gebruik worden de originele jaarstukken naar het Computercentrum van de Kamer van Koophandels in Woerden verstuurd. Na verloop van tijd ontvangt men uit Woerden een microfiche
per jaarstuk die uitsluitend als back-up voor de eigen microfiche dienst doet.
D.3.3
Afdelingen en bezettingen
De afhandeling van de deponering van jaarstukken vindt plaats op de aparte subafdeling Administratie (3 personen) binnen de afdeling HVS. De subafdeling Verstrekking Informatie (12
personen) heeft als taak het ter beschikking stellen van informatie uit het HVS-register en deponeringen, waaronder Jaarstukken valt. De afdeling Financiële Administratie is de tweede
gebruiker van deze applicatie. De jaarstukken worden gebruikt als toetsing voor de vaststelling
van de indeling in groepen voor de jaarlijkse bijdrage. Hiermee zijn 2 personen belast.
D.3.4
Procesverloop
Voor de beschrijving van het proces, wordt de indeling gehanteerd uit het haalbaarheidsonderzoek [KD91].
Het proces is op te delen in een viertal deelprocessen. Deze deelprocessen hebben betrekking op:
1. Afhandeling van binnengekomen jaarstukken;
2. Afhandeling van incorrecte stukken;
3. Afhandeling van V-formulieren;
4. Reproduktie van jaarstukken.
Afhandeling van binnengekomen jaarstukken
Een binnengekomen jaarstuk of verklaring ondergaat een aantal stappen die uiteindelijk moeten
resulteren in een gedeponeerd en dus vastgelegd document. De jaarstukken worden ’s ochtends
aangeleverd vanuit de postkamer. De eerste stap is de controle of het jaarstuk van een bedrijf is, dat
bij deze ChamCom staat geregistreerd. Zo niet, dan wordt het naar de juiste ChamCom gestuurd.
Het jaarstuk wordt vervolgens voorbewerkt. Hieronder wordt verstaan het demonteren van het
boekwerk tot een stapel losse pagina’s. In de volgende stap wordt het jaarstuk gecontroleerd,
dat wil zeggen getoetst aan de wettelijke eisen. Indien het stuk hier niet aan voldoet zal actie
ondernomen worden, teneinde wel een correct jaarstuk te verkrijgen. Zie hiervoor de volgende
paragraaf. Tot het moment dat er een aanvulling of correctie binnen is, zal er met het jaarstuk
niets gebeuren. Is het jaarstuk wel correct, dan wordt het voorzien van een datumstempel en een
nummering per pagina. Het jaarstuk wordt nu geregistreerd in het registersysteem door middel
van een entry van maximaal 11 rubrieken. Deze entry wordt vervolgens gecontroleerd, waarna
de jaarstukken worden verfilmd en doorgestuurd naar de afdeling Financiële Administratie.
Afhandeling van incorrecte stukken
Indien bij de controle van de jaarstukken blijkt dat deze niet voldoen aan de wettelijk gestelde
eisen, zal er telefonisch contact zijn danwel correspondentie plaatsvinden met het betrokken
bedrijf teneinde in het bezit te komen van een correct jaarstuk.
Afhandeling van V-formulieren
Na afhandeling van het jaarstuk door de afdeling HVS belandt het jaarstuk bij de afdeling Financiële Administratie. Deze heeft ten doel aan de hand van het jaarstuk de tariefgroep te bepalen
waarin de onderneming thuishoort. Dit in verband met de jaarlijkse bijdrage van de desbetreffende onderneming aan de ChamCom. Indien de bijdrage van de deposant mogelijkerwijs moet
180
worden gewijzigd, dan krijgt deze een V-formulier toegezonden. Middels een V-formulier kan
het in de onderneming gestoken kapitaal bepaald worden. De stappen die door de Financiële
Administratie worden ondernomen zijn:
Het jaarstuk wordt aangeleverd en op datum gesorteerd;
De balans wordt met de huidige rangschikking vergeleken (middels een AS/400 applicatie);
Het jaarstuk wordt afgelegd indien er geen aanleiding is voor verandering;
Indien er wel aanleiding is voor verandering wordt een V-formulier aangemaakt en opgestuurd naar het betreffende bedrijf;
Reproduktie van jaarstukken
Jaarstukken en verklaringen worden bewaard om voor derden te kunnen worden gereproduceerd
naar aanleiding van schriftelijke of telefonische verzoeken, of naar aanleiding van vragen aan de
balie van de ChamCom. Schriftelijk en telefonisch worden uitsluitend kopieën van de stukken
aangevraagd, welke aan de aanvrager worden toegezonden. Hiervoor worden vanzelfsprekend
kosten in rekening gebracht. Mondeling kan men ook een uitreksel aanvragen, welke eveneens
in rekening wordt gebracht of men kan een jaarstuk ter inzage vragen, hetgeen kosteloos is.
Vanzelfsprekend is het ook mogelijk voor medewerkers van de ChamCom om stukken op te
vragen voor intern gebruik.
D.3.5
Functies
In het gehele proces zijn de volgende functies te onderkennen:
Medewerker ChamCom (HVS-Administratie)
Deze houdt zich bezig met de verwerking van de jaarstukken.
Cliënt (Verstrekken Informatie)
Houdt zich bezig met het ter beschikking stellen van informatie van het HVS-register en
deponeringen, waaronder Jaarstukken valt.
FIS (Financiële Administratie)
De jaarstukken worden gebruikt als toetsing voor de vaststelling van de jaarlijkse bijdrage.
D.3.6
Knelpunten
In het gehele proces van deponering en reproduktie van jaarstukken op basis van verfilming
traden echter de volgende knelpunten en bezwaren op:
Jaarstukken zijn pas na het microfilmen ter inzage beschikbaar;
Fiches van jaarstukken kunnen niet altijd direct worden gevonden (elders in gebruik, fout
opgeborgen);
Het afdruk-apparaat is vaak bezet, er moet dikwijls lang op de afgifte van een jaarstuk
worden gewacht;
Er is geen controle op het terugbrengen van een fiche door het publiek;
Het gehele proces van verfilming en doorsturen levert een te grote werkdruk op;
Mede door het vorige punt krijgen de service- en controle-activiteiten te weinig aandacht.
D.4. Analyse en ontwerp
181
D.4 Analyse en ontwerp
D.4.1
Doel
Aan Data General is ten doel gesteld, een DIP-systeem met workflowfaciliteiten te ontwerpen
en te realiseren voor de begeleiding van het gehele traject van deponering en reproduktie van
jaarstukken door de organisatie. Dit hoofdstuk beschrijft het functioneel ontwerp [Wid], dat door
de ChamCom is opgesteld evenals het basisontwerp, zoals dit door Data General is opgesteld
[Reg93] mede op basis van het functioneel ontwerp.
D.4.2
Eisen
Vooraf heeft de ChamCom enkele eisen geformuleerd, waaraan het ontwerp van het systeem zou
moeten voldoen:
Het moet ontworpen worden op basis van het door de ChamCom opgestelde functionele
ontwerp.
De volledigheid van de informatie moet gegarandeerd zijn.
Eenmalige invoer gegevens voor zowel data-systeem en DIP-systeem.
Backup van de informatiedrager.
Toegangscontrole per functie en per werkplek.
Het systeem moet gaan draaien met een koppeling naar de aanwezige IBM AS/400.
D.4.3
De door Data General gehanteerde methode is een aangepaste versie van SDM II aangevuld met
technieken uit de Jackson System Development methode. De uiteindelijke realisatie zal plaats
vinden met behulp van het pakket Floware van Recognition Equipment.
D.4.4
Functioneel Ontwerp
Het functioneel ontwerp is een gedetailleerd gebruikersgericht ontwerp van het volledige systeem. Dit wordt beschreven in termen van functies en gegevens (geen programma’s en bestanden)
[Uij81]. Het is gebruikelijk om in het functioneel ontwerp een opdeling te maken in deelsystemen.
In dit functioneel ontwerp worden de volgende deelsystemen onderscheiden.
1. Voorbewerking, registratie en opslag van de gegevens met betrekking tot gedeponeerde
stukken in de IBM AS/400 handelsregister database en het DIP-systeem.
2. Inzage en reproduktie van de gedeponeerde stukken (intern, alsmede voor en door derden).
3. Kontrole en eventueel muteren van de jaarlijkse bijdrageklasse in de IBM AS/400 database
op basis van de inhoud van de gedeponeerde stukken.
Het functioneel ontwerp beschrijft de functionaliteiten die het systeem zou moeten bieden zeer
gedetailleerd. Ook zijn alle deelsystemen uitgewerkt met behulp van Data Flow Diagrammen
(DFD’s). Zoals gezegd is het functioneel ontwerp een van de uitgangspunten voor het basisontwerp van het systeem.
182
D.4.5
Basisontwerp
Het basisontwerp valt uiteen in drie delen, die ieder een deel van het systeem definiëren:
Workflow diagrammen
De workflow diagrammen definiëren de route die werk aflegt tussen verschillende functies
of activiteiten. In dit geval wordt de afhandeling van binnengekomen jaarstukken en verklaringen vastgelegd. Binnen de gekozen ontwikkelomgeving is de workflow dynamisch:
het is mogelijk om wijzigingen in de workflow aan te brengen zonder de broncode van de
ontwikkelde software aan te passen [Reg93].
Entiteit Relatie diagrammen (ERD’s)
Het entiteit relatie diagram (ERD) definieert de relatie tussen gegevens. Het ERD is
genormaliseerd: dit betekent dat geen enkele gegevensverzameling (entiteit) overbodige of
dubbele gegevens bevat [Reg93].
Dialoog ontwerp
Het dialoog ontwerp geeft een definitie van de dialoog tussen gebruiker en applicatie aan
de hand van de definitie van de getoonde schermen [Reg93].
In dit rapport zal niet in worden gegaan op de ERD’s en het dialoog ontwerp. Voor meer informatie
hierover wordt verwezen naar het basisontwerp [Reg93]. De nadruk zal in dit rapport liggen op
het de workflowdiagrammen. In de workflowdiagrammen wordt in drie fasen afgedaald tot het
activiteitenniveau:
1. Afbakening context;
2. Decompositie in hoofdactiviteit;
3. Beschrijving workflows;
De diverse fasen zullen in de volgende subparagrafen worden besproken.
D.4.6
Afbakening context
De eerste stap van het ontwerp is gericht op de afbakening van de context van FLUSH binnen
haar omgeving. Alle rollen die op enige wijze met het systeem staan worden in kaart gebracht.
Het resultaat van deze stap geeft de interacties aan tussen het systeem en haar omgeving. De
afhankelijkheid tussen events en produkten wordt hier nog buiten beschouwing gelaten. Het
systeem is dus een black-box. Zie figuur D.1.
D.4.7
Decompositie in hoofdactiviteiten
Het deponeren en reproduceren van jaarstukken wordt in de vorige fase als de taak van het systeem
gezien. Door de black-box nu open te breken kunnen de vijf hoofdactiviteiten waaruit deze taak
is opgebouwd onderscheiden worden. Zoals uit figuur D.2 volgt zijn in het FLUSH-systeem de
volgende hoofdactiviteiten te onderscheiden:
1. Controleren en deponeren
Deze activiteit bestaat uit het controleren of een deponering correct is, het indexeren van
de deponering, de data-entry in RMP en het verdelen van de subdocumenten. Ook het
fiatteren van deze handelingen en het controleren van de staatscourant valt hieronder.
2. Corrigeren deponering
Dit houdt in het opstellen en afdrukken van een correctiebrief, waarin gevraagd wordt
bepaalde tekortkomingen in een deponering aan te vullen. Ook het rappeleren van deze
brief en het verwerken van binnengekomen correcties hoort hierbij.
183
aangeboden deponering
Client
correctie deponering
FIS
factuur gegevens
telefonische correctie
reproduktie aanvraag publiek
reproduktie fax
reproduktie afdruk
FLUSH
reproduktie aanvraag personeel
correctiebrief
rappel correctiebrief
retourbrief
V-formulier
rappel V-formulier
reproduktie op scherm
Client
reproduktie afdruk
Medew.
ChamCom
Medew.
ChamCom
V-formulier ontvangen
Figure D.1: Context afbakening
reproduktie verzoek publiek
factuur gegevens
5.
Reproduceren
documenten
reproduktie fax
reproduktie afdruk
reproduktie verzoek personeel
3.
Aanmaken
V-formulieren
V-formulier
rappel V-formulier
afgekeurd op datum
vaststelling
correctie
afgekeurd
ter goedkeuring
1.
Controleren &
deponeren
ok, controleer bijdrage
4.
Reproduceren
voor
abonnees
2.
Corrigeren
deponeringen
factuur gegevens
reproduktie fax
reproduktie afdruk
correctiebrief
retourbrief
Figure D.2: Hoofdactiviteiten in FLUSH
184
3. Aanmaken V-formulieren
Deze activiteit omvat het invullen en afdrukken van V-formulieren en het rappeleren van
deze formulieren.
4. Reproduceren voor abonnees
Deze activiteit bestaat uit het reproduceren van nieuw binnengekomen deponeringen voor
abonnees en het genereren van factuurgegevens voor deze reprodukties.
5. Reproduceren documenten
Het op verzoek van cliënten of ChamCom medewerkers reproduceren van deponeringen
en/of correspondentie en het genereren van factuurgegevens voor deze reprodukties.
Data General heeft de in de procesbeschrijving onderkende taak reproduceren opgedeeld in twee
delen, afhankelijk van het initiatief waarop de activiteit uitgevoerd wordt. Het reproduceren voor
abonnees is een activiteit die automatisch wordt uitgevoerd bij de deponering van een nieuw stuk.
De reproduktie van documenten is iets wat op een willekeurig tijdstip door een cliënt zelf of door
een medeweker van de ChamCom kan worden uitgevoerd.
D.4.8
Beschijving van de workflows
De in de vorige fase onderscheiden workflows zijn weer onder te verdelen in een aantal activiteiten, afhankelijk van de aard van de workflow. De vijf workflow zullen hieronder besproken
worden.
Controleren en deponeren
Deze hoofdactiviteit is de kern van het FLUSH-systeem en staat weergegeven in figuur D.3.
Batchgewijs
scannen
Controle
indexering
data-entry
onderverdeling
afgekeurd
correctie
ter goedkeuring
afgekeurd op datum vaststelling
ok
incorrect
Fiatteren
Fiatteren
ok
correct
Controleren
staatscourant
incorrect
correct
Figure D.3: Workflow controleren & deponeren
Batchgewijs scannen
Zowel gedeponeerde jaarstukken als gecorrigeerde jaarstukken kunnen zich bij deze hoofdactiviteit aandienen. De gedeponeerde jaarstukken moeten eerst gescand worden. In deze stap zijn
de nodige faciliteiten beschikbaar om een zo goed mogelijk digitaal exemplaar van het origineel
te verkrijgen.
Controleren, indexeren en data-entry
Na het scannen worden de jaarstukken één voor één aangeboden voor controle en data-entry
binnen HVS. Het controleren van een jaarstuk of verklaring op volledigheid en de data-entry
bestonden ook reeds voor de invoering van het FLUSH-systeem. Deze acties zijn nu uitgebreid
met indexering en het verdelen van een document in subdocumenten. Iedere pagina uit een
jaarstuk wordt nu één voor één op het scherm getoond, waarbij de gebruiker de volgende acties
moet uitvoeren:
185
Controle
In deze stap wordt gecontroleerd of het jaarstuk of de verklaring aan de wettelijke eisen
voldoet. Is dit niet het geval, dan kan het document niet worden gedeponeerd. Ook wordt
gecontroleerd of er reeds eerder een stuk is binnengekomen waarvoor correcties worden
verwacht. Indien het stuk een correctie is op een reeds eerder ontvangen stuk, dan wordt
dit bij de hoofdactiviteit corrigeren deponeringen aangeboden.
Data-entry
De data-entry in het RMP is niet gewijzigd. De gebruiker kan via de terminal-emulatie deze
actie uitvoeren.
Indexering
Voor de indexering binnen FLUSH moet de gebruiker de documentsoort aangeven. Het
dossiernummer, het boekjaar en de deponeringsdatum worden automatisch overgenomen
vanuit het RMP.
Opsplitsen in subdocumenten
Tijdens het bekijken van pagina’s kunnen pagina’s aan een subdocument worden gekoppeld
door het desbetreffende subdocument in een lijst aan te wijzen.
Wijziging bijdrage
Indien aan de hand van een balans blijkt dat moet worden nagegaan of de bijdrage van een
deposant moet worden aangepas, dan wordt dit door de gebruiker aangegevens, zodat dit
apart kan worden behandeld.
Fiatteren data-entry, indexering en opdeling
De in het HVS en FLUSH ingevoerde gegevens moeten achteraf worden gecontroleerd en gefiatteerd om fouten op te vangen. Hiervoor moet de controleur de documenten kunnen inzien.
FLUSH toont hiervoor de documenten één voor één op het scherm in de volgorde van dossiernummer, wat overeenkomt met de volgorde die door het RMP wordt toegepast. Na fiattering
is het jaarstuk of de verklaring openbaar. Het document kan nu tevens worden gebruikt voor
reproduktie en verzending naar abonnees.
Controle staatscourant
Dagelijks publiceert de staatscourant een overzicht van alle gedeponeerde stukken. Hiervoor
levert de ChamCom een tape met de benodigde gegevens.
Corrigeren deponering
De tweede hoofdactiviteit betreft de afhandeling van de incorrecte stukken. Deze hoofdactiviteit
wordt inzichtelijk gemaakt aan de hand van figuur D.4.
Incorrecte jaarstukken en verklaringen zijn te verdelen in twee hoofdgroepen: jaarstukken waarvan de datum vaststelling ontbreekt en alle overige fouten. De meeste incorrecte documenten
vallen onder de eerste groep. Indien de datumvaststelling ontbreekt wordt een brief gestuurd
naar de deposant waarin wordt gevraagd deze datum schriftelijk of telefonisch te melden. In alle
overige gevallen wordt gevraagd de fouten schriftelijk te corrigeren. FLUSH is verantwoordelijk
voor het afdrukken van de brieven, de rappelering van de brieven en de verwerking van de
binnengekomen reacties.
Afdrukken van brieven
Bij het ontbreken van de datum vaststelling drukt FLUSH zonder verdere tussenkomst van de
gebruiker een brief af. In alle andere gevallen kan een keuze worden gemaakt tussen een aantal
reeds gedefinieerde teksten, of kan een eigen tekst worden ingevoerd. Bij het afdrukken van
brieven maakt FLUSH gebruik van de in het RMP aanwezige NAW-gegevens.
Genereren van rappelbrieven
Indien een deposant na twee weken (een instelbare tijd) niet heeft gereageerd, dan genereert
FLUSH automatisch een rappel: dit is een vaste brief waarin de variabele paragraaf van de
186
afgekeurd op datum
vaststelling
afgekeurd
Autom.
invullen
reden
Toevoegen
NAW
Afdrukken
correctiebrief
1e rappel
Toevoegen
NAW
Afdrukken
1e rappel
correctiebrief
2e rappel
Toevoegen
NAW
Afdrukken
2e rappel
correctiebrief
Toevoegen
NAW
Afdrukken
retour
brief
correctiebrief
Reden
invullen
Rappeleren
correctiebrief
stoppen
Rappeleren
correctiebrief
starten
te laat
Afhandelen
weigeraars
Behandelen
correcties
correctie
retourbrief
accoord
ter goedkeuring
Batchgewijs
scannen
Indexeren
gescande
correcties
Figure D.4: Workflow corrigeren deponering
originele brief wordt overgenomen. Na nog eens twee weken genereert FLUSH een tweede
rappel: ook dit is een vaste brief waarin de variabele paragraaf is opgenomen. Tenslotte wordt na
nog eens twee weken het document als niet behandelbaar beschouwd. Geen van de rappelbrieven
wordt in het archief opgenomen.
Niet behandelbare documenten
Documenten, waarvan de fouten na herhaalde rappels niet worden hersteld, worden aan de
gebruiker getoond. Deze heeft nu de keuze het document als nog goed te keuren of om het
document met een begeleidende brief aan de deposant te retourneren. FLUSH genereert hiervoor
een retourbrief. Het gescande document wordt hierbij niet afgedruk. Het document wordt uit de
FLUSH database verwijderd.
Verwerken reacties
Reacties kunnen schriftelijk of telefonisch binnenkomen. Schriftelijke reacties worden gescand
en vervolgens verwerkt. Binnengekomen schriftelijke reacties kunnen na bepaling van het bij
behorende dossier altijd opgeslagen worden als binnengekomen correspondentie.
Aanmaken V-formulieren
Derde hoofdactiviteit binnen het FLUSH-systeem heeft betrekking op de eventuele wijziging in
de bijdrage(klasse) van de deposant. Dit staat getoond in figuur D.5.
Aanmaken V-formulieren
Bij het aanmaken van V-formulieren krijgt de gebruker de bij controle geselecteerde documenten
één voor één te zien. De variabele gegevens van het V-formulier kunnen nu worden ingevuld,
waarna deze wordt afgedrukt op een speciaal voorbedrukt formulier. Naast het V-formulier
wordt tevens een vaste brief afgedrukt waarin de NAW-gegevens van het RMP zijn opgenomen.
Zowel het aangemaakte formulier als de brief worden niet als correspondentie opgeslagen. Indien
de gebruiker besluit dat geen V-formulier noodzakelijk is, dan wordt het in behandeling zijnde
document als afgehandeld beschouwd.
Rappeleren V-formulieren
De rappelering loopt bij V-formulieren gelijk aan die bij incorrecte documenten.
Verwerken niet ingevulde formulieren
Indien een V-formulier na de rappels niet ingevuld wordt geretourneerd dan wordt het bijbehorende stuk aan de gebruiker getoond. Verdere afhandeling vindt dan buiten FLUSH plaats.
Verwerken ingevulde V-formulieren
Na ontvangst van ingevulde V-formulieren moet dit in FLUSH worden aangegeven. Het document wordt dan als afgehandeld beschouwd en uit de rappelering verwijderd.
187
Invullen
V-formulier
1e rappel
Rappeleren
V-formulier
stoppen
Accepteren
V-formulier
Toevoegen
NAW
Afdrukken
V-formulier
V-formulier
Toevoegen
NAW
Afdrukken
1e rappel
V-formulier
rappel V-formulier
Toevoegen
NAW
Afdrukken
2e rappel
V-formulier
rappel V-formulier
Rappeleren
V-formulier
starten
2e rappel
te laat
Tonen
weigeraars
Figure D.5: Workflow aanmaken V-formulier
Reproduceren documenten
Jaarstukken en verklaringen worden bewaard om voor derden te kunnen worden gereproduceerd
naar aanleiding van schriftelijke of telefonische verzoeken, of naar aanleiding van vragen aan de
balie van de ChamCom. Deze activiteit staat getoond in figuur D.6.
Aan de balie wordt kosteloos inzage gegeven in de gedeponeerde jaarstukken en verklaringen.
Tegen een vergoeding kunnen de documenten via post en/of fax worden toegezonden.
Naast reprodukties voor derden biedt FLUSH uiteraard ook de mogelijkheid om voor intern
gebruik documenten in te zien of af te drukken. Deze en voorgaande mogelijkheden zijn binnen
het RMP geı̈ntegreerd en kunnen via het zoeksysteem worden benaderd. Alleen voor het inzien
van documenten is een DIP-werkstation noodzakelijk; Vanaf iedere AS/400 terminal kunnen
documenten worden afgedrukt en/of gefaxt.
Het inzien van documenten is uiteraard alleen mogelijk op DIP-werkstations. Het RMP zoeksysteem wordt hierbij gebruikt via terminal emulatie. Zodra een dossier is geselecteerd dan wordt
het dossiernummer overgenomen en kan de gebruiker overschakelen naar de DIP-applicatie.
Hierin worden de volgende mogelijkheden geboden:
Selectie van een document
Een document kan worden geselecteerd door dit in een overzicht aan te klikken. Dit
overzicht is gesorteerd op boekjaar en datum van deponering (beide in omgekeerde volgorde).
Selectie van een subdocument
Binnen een document kan indien gewenst een subdocument worden geselecteerd; zo niet
dan worden alle pagina’s van het document getoond.
Bladeren door de pagina’s
Binnen de geselecteerde pagina’s kan vooruit en achteruit worden gebladerd, en kan direct
naar de eerste en de laatste pagins worden gesprongen. Pagina’s kunnen worden vergroot
en geroteerd.
Reproduceren voor abonnees
FLUSH biedt de mogelijkheid om abonnementen vast te leggen waarbij cliënten automatisch
alle nieuw gedeponeerde documenten van een geselecteerde documentsoort en/of reeks dossiers
krijgen toegezonden via post of per fax. Een document wordt naar de cliënt verzonden indien
188
reproduktie aanvraag publiek
Selecteren
reprodukties
publiek
Faxen
reproduktie
reproduktie fax
document verzonden
fax
Factureren
fax
factuur gegevens
Factureren
afdruk
factuur gegevens
Afdrukken
reproduktie
reproduktie afdruk
afdruk
reproduktie aanvraag personeel
Selecteren
reprodukties
publiek
Figure D.6: Workflow reproduceren documenten
het aan genoemde eisen voldoet en van een boekjaar dat jonger is dan tot nu toe in een dossier
gedeponeerd. Indien verzending per fax niet mogelijk blijkt dan wordt het document naar de
abonnee verzonden. Bij facturering worden de kosten per document gespecificeerd.
D.4.9
Zoals gesteld vormt het functioneel ontwerp het uitgangspunt voor het basisontwerp. Het enige
grote verschil tussen beide ontwerpen is de toevoeging van het abonnementensysteem aan het
basisontwerp.
D.4.10
Implementatie
Niet alle activiteiten, die in de verschillende workflows onderscheiden zijn, resulteren in een stuk
programmatuur. De activiteiten worden gegroepeerd in 21 categorieën van soortgelijke basisactiviteiten. Deze basisactiviteiten worden gerealiseerd en middels het aanroepen met de juiste
argumenten wordt een specifieke activiteiten verkregen. Zo wordt de basisactiviteit afdrukken
document bijvoorbeeld gebruikt voor het afdrukken van een correctiebrief, het 1e en 2e rappel
daarop, de retourbrief etc. Tabel D.3 laat de relatie tussen de 41 onderscheiden activiteiten en
de 21 basisactiviteiten. Voor meer informatie wordt verwezen naar het FLUSH basisontwerp van
Data General [Reg93].
D.5 Invoering
D.5.1
Stappen
In dit stadium van het project zijn de volgende stappen onderkend:
1. De afdeling systeembeheer is op cursus gegaan bij Data General. Zij waren wel al op cursus
geweest bij de vorige leverancier, maar dat was ruim een jaar geleden. Het hoofddoel van
deze cursus was opfrissen van de reeds opgedane kennis.
Table D.3: Beknopte datadictionary
OVERIG
Onderhoud abonnees en abonnementen
Onderhoud documenten subdocumentsoorten
Onderhoud dossiers
Onderhoud factureringsgegevens, tarieven en portokosten
WORKFLOW REPRODUCEREN DOCUMENTEN
Afdrukken reproduktie
Factureren afdruk
Factureren fax
Faxen reproduktie
Selecteren reprodukties publiek
Selecteren reprodukties personeel
WORKFLOW REPRODUCEREN VOOR ABONNEES
Afdrukken reproduktie abonnee
Factureren abonnement afdruk
Factureren abonnement fax
Faxen voor abonnement
Genereren reprodukties
WORKFLOW AANMAKEN V-FORMULIER
Accepteren V-formulier
Afdrukken V-formulier
Afdrukken 1e rappel V-formulier
Afdrukken 2e rappel V-formulier
Invullen V-formulier
Rappeleren V-formulier starten
Rappeleren V-formulier stoppen
Toevoegen NAW
Tonen weigeraars
WORKFLOW CORRIGEREN DEPONERINGEN
Afdrukken correctiebrief
Afdrukken 1e rappel correctiebrief
Afdrukken 2e rappel correctiebrief
Afdrukken retourbrief
Afhandelen weigeraars
Automatisch invullen reden
Batchgewijs scannen
Behandelen correcties
Indexeren gescande correcties
Rappeleren correctiebrief starten
Rappeleren correctiebrief stoppen
Reden invullen
Toevoegen NAW
WORKFLOW CONTROLEREN & DEPONEREN
Batchgewijs scannen
Controle, indexering, data entry & onderverdeling
Controleren staatscourant
Fiatteren
GEINITIEERD DOOR
W=workflow, G=gebruiker, T=workflow en tijd
Accepteren V-formulier
p
G
Afdrukken document
p
p
p
p
p
p
p
p
p
W
Automatisch invullen
p
p
p
W
Batchgewijs scannen
p
p
G
Behandelen correcties
p
G
Controle, indexering,...
p
G
Factureren reproduktie
p
p
p
p
W
Faxen document
p
p
W
Fiatteren
p
G
Genereren reprodukties
p
G
Indexeren gescande correcties
p
G
Invullen V-formulier
p
G
Onderhoud abonnees en abonnementen
p
G
Onderhoud (sub)documentsoorten
p
G
Onderhoud dossiers
p
G
Onderhoud factureringsgegevens
p
G
Rappeleren starten
p
p
T
Rappeleren stoppen
p
p
W
Reden invullen
p
G
Selecteren reproduktie
p
p
G
Tonen documenten
p
p
p
G
D.5. Invoering
189
190
Faxen
voor
abonnement
reproduktie fax
document verzonden
Factureren
abonnement
fax
factuur gegevens
Factureren
abonnement
afdruk
factuur gegevens
Afdrukken
reproduktie
abonnee
reproduktie afdruk
fax
Genereren
reprodukties
ok
afdruk
Figure D.7: Workflow reproduceren voor abonnees
2. Bij het gereedkomen van het systeem gaan de gebruikers op training bij Data General om
bekend te raken met hun gedeelte van het systeem.
3. Als laatste stap komt er een demonstratie van het systeem voor het overige personeel.
D.5.2
Schaduwdraaien
Er is niet schaduwgedraaid met het systeem. Wel wordt er parallel aan het oude systeem met
het nieuwe systeem gewerkt. Hele dagprodukties worden na gewone verwerking ook nog aan
het nieuwe systeem aangeboden. Deze opgeslagen informatie wordt echter weggegooid. Op
het moment dat het systeem volledig operationeel is, zal er een omslagpunt komen, waarop het
proces overgaat op het nieuwe systeem.
D.5.3
Architectuur
Het FLUSH-systeem is een cliënt/server toepassing. Het bestaat uit cliënt-componenten die
gebruik maken van diensten geleverd door de server-componenten. De cliënt- en servercomponenten zijn verdeeld over de verschillende hardware-platformen. De gebruikers hebben
toegang tot de cliënt-componenten van FLUSH via de PC-werkstations en de AS/400 terminals.
Daarnaast is FLUSH een workflow toepassing. Deze toepassingen bestaan uit relatief zelfstandige
componenten die via workflow berichten (werk) met elkaar uitwisselen. Een belangrijke server
is daarom de workflow activity manager. Deze manager regelt de stroom van werk tussen de
verschillende activiteiten. De activiteiten zelf maken gebruik van database services, te weten:
De FLUSH database server
Dit is de centrale database waarin alle gegevens van FLUSH worden bewaard. Onderdeel
hiervan is de optische lange termijn opslag van pagina’s.
De RMP en FIS database server
Dit zijn de bestaande databases van het RMP en FIS. Deze databases worden onder andere
gebruikt tijdens het selecteren van te reproduceren (sub)documenten en voor debiteur en
NAW-gegevens. FLUSH gebruikt de RMP en FIS databases uitsluitend om gegevens te
lezen, nimmer om ze te schrijven of te wijzigen.
Daarnaast zijn er nog de volgende drie services:
D.5. Invoering
191
De fax service
Dit is de sevice die het mogelijk maakt om documenten via fax te verzenden (brieven en
reprodukties).
De print service
Dit is de service die het mogelijk maakt om documenten op papier af te drukken (brieven,
formulieren, reprodukties).
De FIS service
De FIS API kan vanuit FLUSH ook als service worden gezien. De FIS API biedt FLUSH de
mogelijkheid om afgedrukte/gefaxte reprodukties te factureren.
Hardware
De volgende hardware was reeds bij de ChamCom aanwezig:
IBM AS/400 model F/60 minicomputer;
Een deel van het FLUSH systeem is geı̈mplementeerd op de AS/400.
IBM token ring netwerk;
IBM cabling system.
Ten behoeve van het nieuwe systeem zijn de volgende hardware-investeringen gedaan:
AViiON 4605 server
De centrale server is een AV/4605 uitgerus met 64 Mb intern geheugen. Dit model AViiON
is uitgerust met één centrale processor.
CLARiiON disk-array
De CLARiiON heeft 20 slots waarvan er hier 12 bezet zijn met 6 x 500Mb en 5 x 1,2Gb
magnetische schijven. Door mirroring en RAID-5 resulteert een netto-opslag van 9,6Gb.
Hiervan wordt 6 Gb benut voor de opslag van images en 3,6 Gb voor de opslag van de
systeemsoftware en standaardsoftware.
LMSI Rapid Changer
Deze optische disk-array heeft beschikt over 5 optische WORM-schijven van ieder 5,6 Gb.
Deze opslagcapaciteit van 28 Gb wordt benut voor de permanente opslag van jaarverslagen.
PC werkstations
De PC werkstations zijn gebaseerd op 486DX2/66 microprocessoren. Afhankelijk van de
taak waarvoor een PC wordt ingezet, is deze uitgerust met:
– een hoge-resolutie scherm;
– een token-ring kaart;
– een scanner;
Fax server
De fax server is een PC werkstation uitgerust met een token-ring kaart en een faxkaart voor
het verzenden van fax-berichten. Deze is niet bestemd voor het ontvangen van faxen.
Print server en printer
De print server is een speciaal kastje dat het mogelijk maakt een standaard printer aan het
token-ring netwerk te koppelen. De communicatie met de AViiON server verloopt via het
TCP/IP protocol en draagt zorg voor print-spooling en scheduling.
192
Doel
Naam
Toepassing
Ontwikkeling
Plexus 4GL ontwikkelomgeving
Plexus Floware ontwikkelomgeving
Microsoft C/C++ 7.0 en Windows SDK
GNU C en Informix ESQL/C
RPG/400 en Synon/2
DG/UX 5.4R2.01
MS-DOS 6.0 en Windows 3.1
OS/400 v.2 release 2 mod. level 0
Informix On-Line 5.0
Informix Star
Informix Optical
Plexus Storagemanager v2.0
Sequelink
Plexus 4GL run-time
LAN Workplace for DOS 4.1
Rumba for AS/400
ontw. windowsapp. voor databasebenadering
ontw. workflowactiviteiten binnen Plexus 4GL
ontw. waar Plexus 4GL tekort schiet
ontw. van de delen van FLUSH op de server
ontw. van het AS/400 gedeelte
operating-system van de server
operating-system van de PC’s
operating-system van de AS/400
database-manager van FLUSH
databasebenadering vanaf de PC’s
aansturing optische opslagmedia
besturing jukebox en optical drive
communicatie server en AS/400
workflow activiteiten
TCP/IP communicatieplatform
terminal emulatie vanaf de PC’s
Gebruik
Table D.4: Software
Software
De standaard software componenten zijn te splitsen in software die tijdens de bouw van het
systeem zijn toegepast en software die tijdens het gebruik van het systeem worden gebruikt. Een
en ander staat weergegeven in tabel D.4.
Netwerk
De opbouw van het netwerk staat weergegeven in figuur D.8.
Nazorg
De nazorg van het systeem is als volgt geregeld:
Er is een garantieperiode op de software van een jaar. Fouten worden gedurende deze
periode kosteloos door Data General hersteld. Dit mag vrij uniek genoemd worden.
Er is een hardwaregarantie en tevens is er een onderhoudscontract afgesloten.
Op verzoek van de ChamCom zal Data General aanvullende functionaliteiten leveren. Dit
is vanzelfsprekend niet kosteloos.
Waarschijnlijk zal er ook een onderhoudscontract met betrekking tot de software worden
afgesloten. Dit contract zal een afbouwend verloop hebben, daar de kamer er naar streeft
zelf de zorg voor en de aanvulling van de applicaties te ondersteunen.
D.6 Evaluatie systeem
De jaarstukkenapplicatie is op het moment van schrijven pas kort operationeel. De kamer wil
circa 3 maanden na de invoering een evaluatie houden. De in deze paragraaf te noemen punten
zijn dan ook slechts voorlopige waarnemingen.
D.6.1
De medewerkers die reeds enige ervaring hebben met het systeem zijn enthousiast, daar de
voordelen direct gevolg hebben voor hun uitvoerende taken. De overige werknemers die met het
systeem werken wachten nog op wat meer operationele ervaring.
193
D.7. Evaluatie project
AViiON
4605
AS/400
Printer
Fax server
Print server
16Mpbs
token ring
Bridge
16Mpbs
token ring
Sequelink
gateway
Scanner
PC Werkstations
Figure D.8: Opbouw van het netwerk
D.6.2
Effecten op de organisatie
Door het gebruik van Floware zijn er op alle activiteiten meetpunten aanwezig. Door de betreffende queue uit te lezen kan een overzicht verkregen worden van de werkvoorraden in het traject.
Tevens is er sprake van meer service naar de klant toe. De initieel geschetste voordelen komen
naar voren en er worden steeds nieuwe mogelijkheden ontdekt om het systeem toe toe passen.
D.6.3
Effecten op de efficiëntie
De efficiëntie is duidelijk verbeterd. Een simpel vergelijk tussen de oproep van een image en het
zoeken naar de juiste microfilm illustreert dit. Efficiëntievoordeel komt ook voort uit het feit dat
dossier niet meer zoek zijn en tegelijkertijd toegankelijk zijn voor meerdere medewerkers.
D.6.4
Totaaloordeel
Met het FLUSH systeem is de ChamCom in het bezit gekomen van een compleet en naar wens
functionerend workflowsysteem. Bij de realisatie van het systeem is voldaan aan alle eisen die
de ChamCom er vooraf aan heeft gesteld. De invloed die het systeem heeft op de manier waarop
er gewerkt wordt is iets wat in de toekomst moet blijken.
D.7 Evaluatie project
D.7.1
In paragraaf D.2.3 zijn een viertal doelen opgenoemd, die na de ontwikkeling van het systeem
gerealiseerd moeten zijn. Ten eerste moet het systeem leiden tot een ontlasting van de werk-
194
druk. Door het systeem worden alle benodigde gegevens voor de uitvoering van een taak op de
werkplek aangereikt. Tevens is in één oogopslag te zien hoeveel werk nog gedaan moet worden. Dit leidt tot een meer efficiënte manier van werken. De werkdruk wordt hierdoor ontlast.
Ten tweede zou er door het systeem een automatisering en optimalisering van de procedures
moeten plaatsvinden. Door de eis dat het systeem gerealiseerd zou moeten worden op basis van
het functionele ontwerp van de ChamCom is de optimalisatie van de procedures naar de wens
van de ChamCom gerealiseerd. Ten derde zou de directe toegankelijkheid van jaarstukken na
bewerking mogelijk moeten zijn. Door de combinatie van het workflowsysteem met een DIS
systeem op basis van imaging zijn de jaarstukken na het scannen (de eerste stap) direct beschikbaar. Als laatste moet een directe informatieverstrekking aan het publiek voorzien zijn. Aan deze
eis is zeker voldaan. Niet alleen kunnen afschriften van jaarstukken telefonisch of schriftelijk
worden aangevraagd bij de balie, ook kan een abonnement worden genomen, zodat nieuwe
jaarstukken automatisch worden opgestuurd of gefaxed. Indien gewenst kan het publiek ook
direct en kosteloos toegang hebben tot jaarstukken, door gebruik te maken van een aantal bij de
ChamCom aanwezige terminals.
D.7.2
De ontwikkeling van het systeem was geheel in handen van Data General. Dit in nauw overleg
met de ChamCom. Zoals gesteld gebruikt Data General een derivaat van SDM II en Jackson
System Development (JSD) voor de ontwikkeling van dit systeem. Van SDM II is de fasering
gehanteerd, terwijl met behulp van Jackson de activiteiten zijn gemodelleerd. De koppeling
tussen de activiteiten in de workflow is met behulp van FloWare gebeurd. Hierbij is getracht zo
efficiënt mogelijk met code om te gaan (zie tabel D.3).
Data General heeft altijd een flexibele houding aangenomen en is ten allen tijde bereid geweest
veranderingen door te voeren. Dit heeft geleid tot een goede verstandhouding tussen de beide
partijen en een grote mate van tevredenheid vanuit de ChamCom over het door Data General
geleverde werk.
D.7.3
Waardering binnen de organisatie
Initieel was er geen vraag vanuit het personeel naar WFM. Wel waren er problemen met enkele
administratieve processen. Door het schetsen van de mogelijkheden van een WFM/imaging
oplossing werd een vraag gecreëerd, gevoed door enthousiasme voor een dergelijke oplossing.
Reeds in een vroeg stadium is er dus betrokkenheid vanuit de organisatie gekomen. De enige
partij die enigszins terughoudend naar deze oplossing keek was systeembeheer. Zij stelden
zo hun vraagtekens bij het nieuw te introduceren hardwareplatform. Deze vraagtekens bleken
onterecht, daar de koppeling met het aanwezige platform geen noemenswaardige problemen
heeft opgeleverd.
D.7.4
Toekomst
Op het moment dat dit project volledig afgerond en geëvalueerd is, zal worden aangevangen met
een volgend project uit de lijst die genoemd is in het haalbaarheidsonderzoek. Waarschijnlijk
zal het hier gaan om de deponering van leverings- en betalingsvoorwaarden. De aanpak van
toekomstige projecten zal niet veel verschillen van de aanpak van dit project. Wel zal ernaar
worden gestreefd de ontwikkeling sneller en binnenshuis te doen plaatsvinden. De snelheid zal
in ieder geval toenemen, daar het haalbaarheidsonderzoek en de leveranciersselectie niet meer
hoeft plaats te vinden. Tevens zal, door het slagen van dit project, de betrokkenheid vanuit de
organisatie gemakkelijk verkregen worden.
D.8. Conclusies en aanbevelingen
D.7.5
195
Totaaloordeel
De ChamCom mag bogen op een geslaagd en soepel verlopen project. Belangrijke redenen
hiervoor zijn een zorgvuldig voortraject en een vroegtijdige betrokkenheid vanuit de gehele
organisatie. Door de hierbij opgedane ervaringen kunnen toekomstig aan te pakken projecten
met vertrouwen tegemoet worden gezien.
D.8 Conclusies en aanbevelingen
D.8.1
Het onderzoek heeft een voorspoedig verloop gekend. Van de meeste stappen in het project was
documentatie aanwezig, welke de onderzoeker ter beschikking is gesteld. In het bijzonder is
dank verschuldigd aan dhr. C. de Widt van IB&A. Niet alleen heeft hij de achtergronden van het
project verduidelijkt, daar waar het niet in de documentatie stond. Ook is hij altijd bereid geweest
de onderzoeker met raad en daad bij te staan om dit rapport zo accuraat mogelijk te maken. Ook
de leverancier, Data General, heeft haar medewerking aan dit onderzoek verleend. Met name
dhr. T. van der Stap en dhr. R.N. de Regt zijn hiervoor dank verschuldigd. Tenslotte waren ook
drs. H.A. Kremers en J. van Dijken van adviesbureau DocWorld bereid geweest hun visie op dit
project met de onderzoeker te delen.
D.8.2
Conclusies
De conclusies van dit onderzoek laten zich als volgt formuleren:
Met het FLUSH systeem heeft de ChamCom de beschikking over een gecombineerd workflowen DIS-systeem, dat aan de eisen en wensen voldoet die de ChamCom er van tevoren aan heeft
gesteld. De winst op het gebied van efficiëntie en flexibiliteit is iets wat in de toekomst zal moeten
blijken.
De combinatie van een grondige voorbereiding, de vroege betrokkenheid van de gebruikers en
een soepel verlopend project geeft vertrouwen in het verdere verloop van de invoering van deze
technologie binnen de ChamCom.
Opgemerkt kan worden dat de jaarstukken-verwerking een sterk gestructureerd en routinematig
proces is. Er worden geen extreem hoge eisen gesteld aan de flexibiliteit van het systeem. Mede
daarom is het een verstandige keuze geweest voor een eerste werkstroom. Toekomstig aan te
pakken werkstromen stellen waarschijnlijk hogere eisen aan de flexibiliteit van de geautomatiseerde werkstroom. Dit kan alsnog verassingen opleveren.
196
197
Appendix E
Het WA-12 rapport van InvCom
Summary
In deze appendix is het gehele rapport bevat, voor zover dit het ICflow project, zoals bij InvCom
is uitgevoerd betreft. Het gaat hier om het rapport zoals dat naar de betrokken organisatie is
opgeleverd, met dien verstande dat deze versie is geanonimiseerd; de naam van de organisatie
is veranderd, evenals persoonsnamen. Tevens heeft het systeem een andere naam gekregen.
Voor de rest is het rapport onveranderd gebleven.
Doel van het hier beschreven ICflow project is te komen tot een DIP-systeem met workflowfaciliteiten voor de begeleiding van het gehele traject van hypotheekverlening. Het is een
succesvol project in die zin dat het voldoet aan de eisen en wensen die InvCom daar vantevoren
aan heeft gesteld. De winst op het gebied van efficiëntie en flexibiliteit is iets wat in de toekomst
zal moeten blijken.
Dit rapport kent een achttal hoofdstukken waarin het gehele ICflow project wordt beschreven.
E.1 Inleiding
E.1.1
beschouwd. Het doel van het onderzoek is inzicht te krijgen in het ontwerp en de invoering van
dit soort systemen. Dit rapport beschrijft het workflowsysteem ICflow. Het is een DIP-systeem
dat door Data General System Integration is ontwikkeld in opdracht van de InvCom Groep.
Het doel van dit rapport is tweeledig. Voor InvCom is het een audit op hun systeem. Voor de
universiteit is het één van de systemen waarop de vergelijkende studie gebaseerd wordt.
E.1.2
Bereik
In dit rapport zal getracht worden een zo volledig mogelijk beeld te schetsen van het ICflow
systeem. De nadruk zal hierbij liggen op de analyse en het ontwerp van workflow systemen en
op de gevolgen van workflow management en workflow automation voor de organisatie.
E.1.3
Doelgroep
De doelgroep van dit rapport bestaat uit de betrokkenen bij de InvCom Groep en de onderzoekers
van de Universiteit Twente. Van dit rapport zullen twee versies verschijnen. Een versie voor
198
E. Het WA-12 rapport van InvCom
de InvCom Groep en een versie voor gebruik op de universiteit. De versie voor de universiteit
verschilt in dit opzicht van die voor de InvCom Groep, dat hierin de naam InvCom, de naam van
Data General, evenals persoonsnamen niet zullen voorkomen. Tevens zal het systeem een andere
naam krijgen.
E.1.4
Structuur
Het rapport kent de volgende structuur. In paragraaf 2 wordt een beschrijving gegeven van
het ICflow-project. Paragraaf 3 gaat verder met een uitgebreide procesbeschrijving, waarna in
paragraaf 4 dieper in wordt gegaan op de analyse van het proces en het daaruit voortvloeiende
ontwerp van het systeem. Paragraaf 5 gaat over de invoering van het systeem en de paragrafen 6 en 7 behandelen de evaluatie van respectievelijk het systeem en het project. Het geheel
wordt afgesloten met paragraaf 8, waarin conclusies worden getrokken en aanbevelingen worden
gedaan.
E.1.5
Terminologie
In dit rapport wordt zo veel mogelijk de terminologie van de InvCom Groep gehanteerd.
Afkortingen:
DIP Document Image Processing
DIS Document Information System
WA-12 Workflow Analyse in 12 organisaties
Begrippen:
Image
De digitale weergave van één pagina in het ICflow systeem.
InvCom
InvCom is de spaarbank van de InvCom Groep.
ICflow
De naam van de DIP-applicatie zoals die door Data General is ontwikkeld voor de afdeling
hypotheken van InvCom.
E.2 Projectbeschrijving
E.2.1
Doel
Het doel van dit hoofdstuk is een beschrijving te geven van het ICflow project. Het gehele traject,
van probleemsignalering tot en met realisatie zal aan de orde komen.
E.2.2
InvCom
InvCom is met een totaal beheerd vermogen van meer dan 60 miljard één van de grootste
beleggings ondernemingen van Europa. In termen van informatieverwerking vormt het ICgiro
systeem de kern van InvCom. In principe heeft iedere cliënt van InvCom een rekening in dit ICgiro
systeem. Middels deze rekening kan hij of zij gebruik maken van alle beleggings- en spaarvormen
van InvCom. InvCom beschikt zelf niet over een ontwikkelafdeling voor informatie technologie.
Wel heeft zij een beheer- en onderhoudafdeling en een helpdesk.
E.2. Projectbeschrijving
199
InvCom is de spaarbank van InvCom. Sparen bij InvCom gaat ook via het ICgiro rekeningensysteem. De ingelegde spaargelden worden door InvCom belegd of uitgeleend, bijvoorbeeld door
middel van het in dit rapport beschreven uitgeven van hypotheken. De afdeling Hypotheken
van InvCom staat centraal in dit rapport, daar de DIP applicatie gericht is op ondersteuning van
het hypotheekverleningsproces, zoals dat plaats vindt op deze afdeling.
E.2.3
Aanleiding
Doel van het ICflow-project is te komen tot een DIP-systeem voor InvCom Hypotheken waarin
de papieren hypotheekdossiers welke nu op de afdeling Hypotheken aanwezig zijn, worden
vervangen door een gedigitaliseerd image processing systeem. De volgende punten zijn in meer
of mindere mate aanleiding geweest om een dergelijk systeem te gaan bouwen:
Het dossierprobleem
Tot op heden worden de hypotheekdossiers in papieren vorm opgeslagen. Dit leidt ertoe
dat dossiers zoek kunnen raken, en dat ze niet gelijktijdig door meerdere medewerkers
toegankelijk zijn. Bij telefonische vragen van cliënten is het ook niet mogelijk om direct
over de juiste informatie te beschikken. Het dossier zal moeten worden opgezocht en de
cliënt zal moeten worden teruggebeld. Vanzelfsprekend kost dit tijd en geld.
Doorlooptijdbewaking
Door een uitgebreide rappeleringsfunctie moet het mogelijk zijn de doorlooptijd tot een
minimum te beperken. Het hoofd van de afdeling zal in staat kunnen zijn de status van alle
aanwezige hypotheekdossiers in te zien.
Werkverdeling
Middels een workflowsysteem kan een efficiënte werkverdeling plaatsvinden. Het hoofd
van de afdeling kan nieuwe hypotheekaanvragen aan de minst bezette medewerkers toewijzen. Bij ziekte of overbezetting kunnen dossiers aan een andere kredietmedewerker worden
toegewezen.
Flexibiliteit
Dit is niet zozeer een aanleiding, maar een voor InvCom aantrekkelijk punt aan een DIPsysteem. Een workflowsysteem biedt flexibiliteit. De procedures die op de afdeling worden
gehanteerd liggen niet voor altijd vast in het systeem. Het systeem kan met de ontwikkeling
van de organisatie meeveranderen en eventueel kunnen extra diensten aan het systeem
worden toegevoegd.
E.2.4
Projectverloop
Historie
InvCom is in Nederland altijd één van de voorlopers geweest met de invoering van nieuwe
technieken op het gebied van de informatieverwerking. De eerste image applicatie bij InvCom
was de ICgiro applicatie. Dit was tevens een van de eerste grootschalige image applicaties
in Nederland. De motor achter dit project was dhr. Telder, directeur van ICgiro en onderdirecteur van InvCom. Dit systeem was gerealiseerd op basis van FileNet van Olivetti. De
archiveringsproblemen bij InvCom Hypotheken, met name de omvang van het archief, deed dhr.
Dols, hoofd van deze afdeling, in contact komen met dhr. Telder. Het idee achter het ICgirosysteem leek ook geschikt voor InvCom Hypotheken. Door de image-faciliteiten zouden de
archiveringsproblemen tot het veleden behoren. Tevens boodt het systeem meerdere voordelen,
met betrekking tot de doorlooptijdbewaking en werkverdeling. Er is besloten over te gaan tot
de realisatie van een dergelijk systeem. Daar het de bedrijfspolicy is om alles wat niet tot de
core-buisiness van InvCom behoort uit te besteden is het Rotterdamse adviesbureau DocWorld
ingeschakeld om het functioneel ontwerp te maken voor dit systeem. Vervolgens is over gegaan
200
tot de leveranciersselectie. Er is geen kosten/baten-analyse gehouden daar InvCom Hypotheken
een dusdanig snel groeiende organisatie is dat situaties in de loop van de tijd niet vergelijkbaar
zijn.
Leveranciersselectie
De leveranciersselectie is verlopen in een tweetal fasen. Men begon met 4 leveranciers, aan wie
het functioneel ontwerp van het systeem is toegestuurd. Men is gevraagd een visie te geven op
het probleem en een omschrijving van de methode van aanpak. Hierna vielen er twee af. Alleen
Olivetti en Data General bleven over. Olivetti dacht van begin af aan de opdracht reeds binnen
te hebben, daar zij het ICgiro systeem en ook deels de InvCom infrastructuur geleverd hadden.
InvCom kende het pakket Floware reeds van beurzen en het systeem zou op basis van dat pakket
gerealiseerd moeten worden. Dit was voor beide overgebleven partijen geen probleem. Voor sitevisits is men vervolgens naar Engeland en België gegaan. In Engeland heeft men een ziekenhuis
bezocht en in Brussel een building society. Doordat InvCom niet tevreden was over de opstelling
van Olivetti en een zeer hoge prijsstelling is de opdracht naar Data General gegaan.
ICgiro II eerst
Er waren problemen rond het ICgiro systeem. Dit was te wijten aan het feit dat Olivetti het
systeem niet meer ondersteunde. Op het moment dat het ICflow project gestalte kreeg, werden
de problemen rond het ICgiro systeem nijpender. Er werd besloten het ICgiro project eerst te
vervangen door een nieuw systeem. Het ICflow project werd stilgelegd. Voor het ICgiro II
systeem is ook gekozen voor een systeem op basis van Floware, waarvoor ook Data General is
ingeschakeld. Op de ontwikkelingen rond het ICgiro II systeem wordt niet verder in gegaan.
Nadat het ICgiro II systeem gereed gekomen was, is verder gegaan met de ontwikkeling van
ICflow.
Ontwikkeling van ICflow
In het ontwikkeltraject van ICflow kunnen de volgende stappen onderscheiden worden.
1. Plan van aanpak
De eerste mijlpaal in het ontwikkeltraject wordt gevormd door het plan van aanpak. Hierin
staat de organisatie van het project beschreven, de betrokken personen evenals een planning
van het gehele project.
2. Basisontwerp
In het basisontwerp wordt een beschrijving gegeven van de functionaliteiten van het systeem, de workflow, de technische realisatie en het gegevensmodel.
3. Detailontwerp
In het detailontwerp wordt de technische gegevensstructuur, het ontwerp van de dialogen
met de gebruikers, de koppelingen met de externe informatiesystemen en de opsplitsing
van het systeem in aparte modules beschreven. Van ieder van de te bouwen modules wordt
in hoofdlijnen de opbouw vastgelegd.
4. Realisatie
Hieronder wordt verstaan het bouwen en testen van de software en het samenstellen van
het systeem en de gebruikersdocumentatie.
5. Invoering
In de invoeringsstap wordt de benodigde hardware en software geı̈nstalleerd en worden
de gebruikers opgeleid.
De hier onderscheiden stappen vinden niet per definitie sequentieel plaats. Daar een van de eerste
activiteiten van het detailontwerp het opsplitsen in modules is, kunnen die modules afzonderlijk
de verdere stappen doorlopen.
E.2. Projectbeschrijving
E.2.5
201
Projectorganisatie
Bij de projectorganisatie is gebruik gemaakt van de stuurgroep/projectgroep structuur. Deze
structuren zullen hieronder worden toegelicht.
Stuurgroep
Algemeen gezien heeft de stuurgroep tot taak toe te zien op de correcte uitvoering van het project.
Praktisch gezien houdt dit in:
Het beoordelen van de door de projectgroep opgestelde mijlpaalprodukten;
Het controleren van de voortgang van het project;
Het beslissen daar waar de beslissingsbevoegdheid van de projectgroep ontoereikend is;
Het vaststellen van de uitgangspunten;
Het beoordelen of en wat de consequenties van genomen besluiten zijn voor het afgesloten
contract.
De stuurgroep van dit project bestaat uit vier functionarissen van InvCom en drie van Data
General. Het voorzitterschap is in handen van InvCom.
Projectgroep
De projectgroep is belast met de directe uitvoering van het project. Hierbij worden ook de
toekomstige gebruikers betrokken. De projectgroep bestaat uit vier functionarissen van InvCom
en vijf van Data General. Het voorzitterschap van de projectgroep is in handen van Data General.
Er vindt een tweewekelijkse rapportage plaats van de projectgroep naar de stuurgroep.
E.2.6
Problemen
Tijdens de ontwikkeling van het systeem zijn er enkele problemen opgetreden. Deze zullen
hieronder worden besproken:
De initiële planning wordt niet gehaald
Ook bij Data General is de ervaring met dit soort projecten niet groot. Het is moeilijk te
voorzien welke problemen zich zullen gaan voordoen gedurende het ontwikkelingstraject.
Er is altijd naar gestreeft de initiële opleverdatum te handhaven, maar door problemen
schuiven veel activiteiten naar achter, zodat het eind van de planning steeds drukker wordt.
Veranderende eisen
In eerste instantie zou er gewerkt worden met het pakket Word voor Windows voor de
generatie van offertes en correspondentie. Deze voorwaarde is altijd in de ontwerpen naar
voren gekomen. De beheer- en onderhoudafdeling van InvCom heeft dit echter in eerste
instantie over het hoofd gezien. In een later stadium wezen zij er op dat er met het InvCom
correspondentiesysteem gewerkt moest worden, wat een extra koppeling vereist. Dit heeft
de nodige vertraging opgeleverd.
Problemen met coördinatie en communicatie tussen projectgroep en stuurgroep
De communicatie tussen de projectgroep en de stuurgroep is niet optimaal verlopen. Er
zijn door de stuurgroep beslissingen genomen over zaken waar de projectgroep zich nog
niet over had uitgesproken, en waardoor zij voor voldongen feiten kwamen te staan.
202
E.3 Procesbeschrijving
E.3.1
Doel
Doel van dit hoofdstuk is het proces in kaart te brengen, zoals dat ten grondslag ligt aan het
ICflow systeem. Het te beschrijven proces betreft de verlening van hypotheken, zoals dat plaats
vindt bij InvCom N.V., een onderdeel van InvCom.
E.3.2
Voorwaarden
Simpel gezegd is een hypothecaire lening een lening waarbij een (onroerend) goed als onderpand
wordt aangeboden. Bij het uitgeven van hypothecaire leningen wordt gesproken over de hypotheeknemer, in dit geval InvCom, en de hypotheekgever, in dit geval de cliënt. In dit rapport
zal omwille van de duidelijkheid gesproken worden over InvCom en cliënt.
Wil InvCom een hypotheekaanvraag van een cliënt honoreren, dan moet aan een viertal voorwaarden zijn voldaan. Deze voorwaarden zijn:
1. De taxatie van het (onroerend) goed moet aanwezig en geaccepteerd zijn. Dit kan door
middel van een taxatierapport, een koop aannemingsovereenkomst of een onroerend goed
aanslagbiljet;
2. De offerte moet zijn goedgekeurd en ondertekend door InvCom;
3. De offerte moet zijn geaccepteerd door de cliënt;
4. Een hypotheekakte moet zijn opgemaakt door de notaris en geaccepteerd door InvCom.
E.3.3
Levensstadia van een hypotheek
Het procesverloop op de afdeling hypotheken kan het best inzichtelijk gemaakt worden aan de
hand van de levensstadia waarin een hypotheekdossier zich kan bevinden. Een hypotheekdossier
kan zich in 7 verschillende levensstadia bevinden. Deze worden weergegeven in figuur E.1. Deze
levensstadia zullen in deze paragraaf behandeld worden.
Aanvraag nieuwe hypotheek
Dit is het eerste stadium van iedere hypotheek. De aanvraag komt de organisatie binnen en
aan de hand daarvan wordt een leeg dossier aangemaakt met het aanvraagformulier als eerste
document. Een aanvraag gaat over naar toestand 2, de lopende hypotheek, als aan alle in 3.2
genoemde voorwaarden is voldaan. Wordt aan één of meerdere van deze voorwaarden niet
voldaan, dan zal er geen hypotheek worden afgesloten en gaat het dossier tijdelijk over naar
toestand 7, de afgewezen/uitgestelde hypotheek.
Lopende hypotheek
Indien de aanvraag voor een hypotheek wordt geaccepteerd, dan zal het dossier overgaan naar
stadium 2, de lopende hypotheek. Er is inmiddels een ICgiro rekening geopend, waarop alle
girale mutaties op de hypotheeksom plaatsvinden. In principe blijft de hypotheek in dit stadium
gedurende de gehele looptijd. In dit stadium kunnen een aantal wijzigingen in het dossier
plaatsvinden die wel of niet resulteren in de overgang van het dossier naar een ander stadium.
Het dossier gaat niet over naar een ander stadium bij een
wijziging in de NAW gegevens van de cliënt;
wijziging in de behandelende kredietmedewerker;
verlenging van het krediet.
203
E.3. Procesbeschrijving
7
Afgewezen/
uitgestelde
hypotheek
1
Aanvraag
nieuwe
hypotheek
3
Aandachts
geval
2
Lopende
hypotheek
4
Aanvraag
wijziging
hypotheek
5
Aanvraag
royement
hypotheek
6
Opgeheven
hypotheek
Figure E.1: De levensstadia van een hypotheekdossier
Het dossier gaat wel over naar een ander stadium bij een
aanvraag voor een wijziging (verhoging) van de hypotheek (naar toestand 4);
royement van de hypotheek (naar toestand 5);
toestand waarin de hypotheek extra aandacht vereist (naar toestand 3).
Extra aandacht
Het dossier belandt in dit stadium bijvoorbeeld bij overschrijdingen in rentebetalingen of aflossingen, beslagen of echtscheidingen. Het is een keuze van de kredietmedewerker het dossier in dit
stadium te laten belanden. De betreffende medewerker zal trachten de aard en de ernst van de
problemen te achterhalen en hij zal de nodige actie ondernemen, teneinde het de hypotheek weer
in stadium 2, de lopende hypotheek, te brengen.
Aanvraag wijziging hypotheek
De procedure die in dit stadium wordt gehanteerd is in grote lijnen gelijk aan die bij het openen
van een nieuwe hypotheek. Het grote verschil ligt hierin, dat bij een verwerping van de wijziging
de hypotheek weer in stadium 2, de lopende hypotheek, belandt.
Aanvraag royement
Er wordt een royement aangevraagd, indien
het onderpand wordt verkocht;
de cliënt overlijdt;
204
de bank het krediet opzegt.
Is het royement volledig, dan gaat het dossier over naar toestand 6. Is dit niet het geval, dan gaat
zij terug naar toestand 2, met de volgende voorwaarden:
de aflossingsnota is door InvCom gemaakt;
de notaris moet zorgen dat het te ontvangen bedrag wordt betaald;
InvCom moet afstand doen van het hypotheekrecht.
Opgeheven hypotheek
Indien een dossier in dit stadium belandt dan is de hypotheek beëindigd. Alle documenten
binnen een dossier bestaan nog en kunnen worden benaderd. Het hypotheek rekeningnummer
bestaat niet meer.
Afgewezen/uitgestelde hypotheek
Er zijn twee oorzaken, waardoor een hypotheekdossier in dit stadium kan belanden:
De aanvraag voor een hypotheek wordt afgewezen
Uitgaande van de door InvCom Hypotheken opgestelde regels kan aan deze hypotheekaanvraag niet worden voldaan.
De aanvraag voor een hypotheek wordt uitgesteld
Nog niet alle gegevens en documenten, noodzakelijk om een hypotheekaanvraag te honoreren zijn beschikbaar. De hypotheek blijft in deze fase zolang het dossier nog niet compleet
is.
E.3.4
Procesverloop
In de vorige paragraaf zijn de toestanden beschreven waarin een hypotheekdossier zich kan
bevinden. Dit is een belangrijk gegeven, daar het van grote invloed is op het proces van de
hypotheekverwerking. De activiteiten die een medewerker van de hypotheekafdeling moet
uitvoeren teneinde het dossier door de diverse stadia te loodsen zullen in deze paragraaf worden
beschreven en worden toegelicht aan de hand van figuur E.2, E.3, E.4 en E.5. Deze stappen
liggen zonder wijzigingen ten grondslag aan het systeem. Dit betreft alleen de stadia 1, 2, 5 en 6
daar iedere hypotheek deze stadia doorloopt. De overige stadia worden aangedaan op initiatief
van de kredietmedewerker.
Procesverloop tot een lopende hypotheek
Binnen het deel van het proces wat leidt tot een lopende hypotheek kunnen 25 stappen onderscheiden worden. Deze worden hieronder toegelicht.
1. De aanvraag wordt in behandeling genomen als het aanvraagformulier uit de informatieset
is ontvangen en niet bij voorbaat is afgewezen. De beoordeling heeft plaats gevonden en
als besloten wordt een offerte uit te brengen vangt de workflow aan.
2. Er wordt een tijdelijke rekening aangemaakt. Het formulier kan nu worden gescand en
geı̈ndexeerd.
3. Er dient een taxatie te worden gemaakt. Een taxatie is niet nodig bij nieuwbouw of een
bestaand pand waarvan reeds een taxatie voorhanden is. Indien er een taxatie aanwezig
is of indien er geen taxatie benodigd is, wordt direct naar stap 9 gegaan. In alle andere
gevallen wordt vervolgd met stap 4.
205
aanvraag
wordt in
behandeling
genomen
open
rekening
1
2
ja
taxatie?
3
maak opdr.
voor taxateur
4
nee
later
ontvangst
taxatierap.
beoordeling
taxatie
nee
5
6
afwijzing?
7
ja
stuur
afwijzing
8
stuur offertebrief en bijl.
9
einde
later
Figure E.2: Eerste deel van de procesbeschrijving
4. Indien er geen taxatie aanwezig is, wordt er een standaard brief of fax naar de taxateur
gestuurd.
5. Het taxatierapport wordt in 2-voud ontvangen.
een exemplaar gaat naar de aanvrager
het andere exemplaar wordt gescand en geı̈ndexeerd
6. De taxatie wordt beoordeeld. Op de criteria die hierbij gehanteerd worden zal in dit rapport
niet worden ingegaan, daar ze buiten de context van dit onderzoek vallen.
7. Op basis van de in de vorige stap uitgevoerde beoordeling kan de hypotheekaanvraag
alsnog worden afgewezen.
8. Indien de hypotheekaanvraag alsnog wordt afgewezen wordt er een standaardbrief naar
de aanvrager gestuurd. Het proces eindigd hier.
9. In deze stap is een goedgekeurde taxatie aanwezig of niet benodigd. In dit geval wordt een
offerte met bijlagen gestuurd naar de aanvrager. De inhoud van deze offerte en de bijlagen
zal niet worden behandeld.
206
getekende
offerte
retour
nee
10
stuur
rappelbrief
11
ja
ontvangst
getekende
offerte
12
ja
vragen?
13
correspondentie
14
nee
stuur geg.
naar
notaris
15
later
concept akte
van notaris
16
vragen?
17
correspondentie
18
Figure E.3: Tweede deel van de procesbeschrijving
10. Na een bepaalde tijd wordt gecontroleerd of de getekende offerte reeds terug is ontvangen
van de cliënt. Is dit niet het geval, dan wordt stap 11 uitgevoerd, anders wordt vervolgd
met stap 12.
11. De offerte is nog niet ontvangen van de cliënt, er wordt een rappelbrief verstuurd.
12. De getekende offerte is retour ontvangen van de cliënt.
13. Het is mogelijk dat de cliënt naar aanleiding van de offerte nog vragen heeft. In dat geval
wordt stap 14 uitgevoerd.
14. Er wordt correspondentie gevoerd met de cliënt over de onduidelijkheden die bij deze nog
bestaan. Na afdoende beantwoording van de vragen zal alsnog een getekende offerte van
de cliënt worden ontvangen.
15. Indien er geen vragen zijn, of indien de vragen reeds beantwoord zijn zullen de gegevens
naar de notaris worden verstuurd, teneinde een hypotheekakte te verkrijgen.
16. Na verloop van tijd wordt de concepthypotheekakte ontvangen van de notaris.
17. Indien de notaris vragen heeft naar aanleiding van de gegevens die door InvCom zijn
opgestuurd, zal worden overgegaan naar stap 18.
18. Er vindt correspondentie plaats met de notaris om onduidelijkheden weg te nemen, zodat
een hypotheekakte kan worden opgeleverd.
19. Zijn de onduidelijkheden weggenomen, dan wordt het bericht akkoord naar de notaris
verstuurd en kan de akte passeren.
20. De notaris zal in overleg met de cliënt bepalen wanneer de akte passeert en zal deze datum
aan InvCom kenbaar maken.
207
bericht van
accoord naar
notaris
19
later
bericht van notaris
omtrent datum
passeren akte
20
invoeren rogiro
gegevens en
maken van
betalingsopdracht
21
later
ontvangst
stukken
notaris
dossier
compleet
22
nee
23
correspondentie
24
ja
lopende
hypotheek
25
Figure E.4: Derde deel van de procesbeschrijving
21. Alle gegevens van de cliënt worden ingevoerd in het ICgiro systeem en er zal een betalingsopdracht worden aangemaakt om de hypotheeksom over te maken.
22. De hypotheekakte worden terugontvangen van de notaris en toegevoegd aan het dossier.
23. Er wordt nogmaals gecontroleerd of het dossier compleet is, zoniet, dan wordt overgegaan
naar stap 24 en anders naar stap 25.
24. Er vindt correspondentie met de notaris plaats om de ontbrekende stukken nog aan het
dossier toe te voegen.
25. Het hypotheekdossier is compleet en er is sprake van een lopende hypotheek.
Procesverloop van het doorhalen van de hypotheek
Evenals het openen van een hypotheek is ook het doorhalen van een hypotheekakte (opheffen van
de hypotheek) in het systeem vastgelegd. De voorwaarden waaronder de hypotheekakte wordt
doorgehaald staan beschreven in 3.3.5. Hierin worden de stappen a tot en met j onderscheiden
die hieronder worden beschreven:
a Bij InvCom wordt een verzoek ontvangen voor het doorhalen van de hypotheek.
b Daar de hypotheek wordt opgeheven moet het resterende bedrag worden afgelost. Deze
aflossingsnota wordt gemaakt.
c De orginelen van de aflossingsnota worden naar de notaris verstuurd.
d Tevens wordt een kopie van deze aflossingsnota naar de boekhouding van InvCom gestuurd.
e Is het nog uitstaande saldo ontvangen dan krijgt InvCom hiervan een bericht.
f De notaris maakt vervolgens een volmacht om het pand over te dragen zonder dat hierop
nog hypothecaire veplichtingen rusten.
208
verzoek
doorhalen
HA
a
maak
aflossingsnota
b
stuur originelen
aflossingsnota
naar notaris
stuur kopie
aflossingsnota
naar afdeling
boekhouding
c
later
d
later
notaris maakt
volmacht en
stuurt volmacht
naar Roparco
na vereffening
saldo; kopie
retour Roparco
f
verzoek opheffen
rekening naar
Rogiro rekeningadministratie
e
g
Roparco
tekent
volmacht
h
getekende
volmacht
scannen
i
getekende
volmacht
naar notaris
j
Figure E.5: Het doorhalen van een hypotheekakte
g Er wordt tevens een verzoek tot opheffing van de rekening naar ICgiro gestuurd.
h De volmacht die van de notaris is ontvangen wordt getekend.
i De volmacht die van de notaris is ontvangen wordt gescand en zo ingebracht in het ICflowsysteem.
j De volmacht wordt aan de notaris geretourneerd. De hypotheek is hiermee beëindigd.
E.3.5
Functies
De gehele afdeling InvCom Hypotheken bestaat uit zeven mensen, waarvan vier kredietmedewerkers, twee administratief medewerkers en het hoofd van de afdeling. Deze functies worden
hieronder beschreven.
1. Administratie
De administratie wordt vervuld door twee medewerkers. Zij ontvangt alle post en draagt
er zorg voor dat de poststukken bij de juiste medewerker komen. Nieuwe hypotheekaanvragen worden naar het hoofd van de afdeling gestuurd. Overige poststukken, die bij een
dossier horen worden naar de behandelend medewerker gestuurd.
2. Hoofd van de afdeling
Het hoofd van de afdeling ontvangt de nieuwe hypotheekaanvragen. Hij wijst een aanvraag
toe aan een kredietmedewerker. Daarnaast is hij belast met de algehele leiding over de
afdeling en het controleren van de uitgaande poststukken.
3. Kredietmedewerker
Er zijn vier kredietmedewerkers die allen de directe verantwoordelijkheid over de aan
hen toegewezen hypotheekdossiers hebben. Hij moet er zorg voor dragen dat een hypotheekaanvraag correct wordt afgehandeld en al dan niet resulteert in een lopende hypotheek.
209
E.4. Analyse en ontwerp
E.3.6
Aantallen
In het functionele ontwerp [Kre92a]. wordt een schatting gegeven van de omvang van dit proces.
Deze is weergegeven in tabel E.1.
Item
Dossiers in gebruik
Images per dossier (gemiddeld)
Inkomende documenten per dag
Inkomende images per dag
Raadplegingen dossiers per dag
Uitgaande brieven per dag
Aanvragen per jaar
Nieuwe hypotheken per jaar
Aantal 9.300
65
75
300
250
100
1.300
1.000
Table E.1: Aantallen
E.3.7
Controlemaatregelen
De huidige situatie is dat alle acties met betrekking tot het agenderen en rappeleren op initiatief
en onder controle van de medewerkers en het hoofd van de afdeling valt. Het hoofd van de
afdeling verdeelt de opdrachten en kan daarbij informeren naar de mate waarin een bepaalde
kredietmedewerker bezet is.
E.4 Analyse en ontwerp
E.4.1
Doel
Dit hoofdstuk beschrijft de analyse en het ontwerp van het ICflow-systeem. In het vorige hoofdstuk is het proces beschreven wat ten grondslag ligt aan het systeem. Door dit systeem moeten
de problemen beschreven in paragraaf 2.3 tot het verleden gaan behoren.
E.4.2
ICflow en ICgiro II
Alvorens in te gaan op de aspecten van analyse en ontwerp van het systeem is het belangrijk een
scheiding aan te brengen tussen het taakgebied van de ICflow applicatie en die van de ICgiro II
applicatie.
Het centrale systeem bij InvCom is het ICgiro II systeem. Dit systeem houdt van alle bij InvCom
lopende rekeningen de relevante gegevens bij. Zo ook van hypotheken. Op het moment dat een
hypotheek is geopend, gaat het ICgiro II systeem ook een rol spelen. In het totale proces van
de hypotheekverlening en het hypotheekgebruik kan de volgende functionele opdeling worden
gemaakt.
1. Het ICgiro II rekeningsysteem is belast met het bijhouden van de rekeninggegevens, zoals
Naam, adres en woonplaats gegevens
Standen van rekeningen en limieten
Lijsten voor verantwoording DNB
etc.
210
2. Het ICflow systeem is belast met de dossieradministratie en de procesautomatisering. Hieronder vallen dus de wijzigingen in het stadium waarin de hypotheek zich bevindt, zoals
bijvoorbeeld
Het openen van de hypotheek;
Het verhogen van het hypotheekbedrag;
Het opheffen van de hypotheek;
Het ingrijpen bij betalingsachterstanden;
etc.
Duidelijk zal zijn dat de link tussen de ICflow applicatie en het ICgiro systeem zeer belangrijk is.
E.4.3
Eisen
Eisen met betrekking tot het ontwerp
Aan het ontwerp van het ICflow systeem liggen enkele uitgangspunten ten grondslag:
Het functionele ontwerp van adviesbureau DocWorld; Dit functionele ontwerp beschrijft
een (alternatieve) werkmethodiek voor de afdeling hypotheken van InvCom, evenals de
functionaliteiten die het nieuwe systeem zou moeten bieden [Kre92a].
De ontwikkeling moet plaats vinden op basis van de bestaande technische infrastructuur.
Er moet een integratie plaatsvinden met het ICgiro II systeem. De coderingen, zoals die in
dat systeem worden gebruikt zijn dus leidend.
Alle werkplekken moeten gerealiseerd worden op basis van IBM-PC’s met MS-Windows.
Eisen met betrekking tot de authorisatie
Met betrekking tot de authorisatie zijn geen omvangrijke maatregelen nodig. Alle medewerkers
van de afdeling hypotheken hebben dezelfde toegang. Het hoofd van de afdeling moet wel de
mogelijkheid hebben om bepaalde medewerkers bepaalde transacties wel of niet toe te kennen.
Indien er op hetzelfde systeem mogelijk meer applicaties gaan draaien, is een toegangscontrole
wel op zijn plaats.
E.4.4
De ontwikkeling van het systeem is in handen van Data General. Data General maakt bij de
ontwikkeling gebruik van de SDM II fasering met als beschrijvingsmethodes ERD’s en Yourdon
DFD’s. De realisatie vindt in principe plaats met behulp van het workflow pakket Floware van
Plexus/Recognition Equipment.
E.4.5
Ontwerp
Het hier beschreven ontwerp is gebaseerd op het basisontwerp van Data General [Reg93] waarin
hoofdzakelijk de functionaliteiten van het ICflow systeem beschreven worden. Het basisontwerp
valt uiteen in een viertal hoofdstukken:
1. Het dossier
Uitgaande van het huidige papieren dossier, beschrijft dit hoofdstuk de opbouw van het
DIP-archief. Behalve de opbouw en toegang tot de dossiers, worden ook de verschillende
stadia in het leven van een dossier beschreven.
211
2. De workflow
Dit hoofdstuk beschrijft de workflow tussen de verschillende medewerkers van InvCom
Hypotheken. Met name de verwerking van binnenkomende post en te volgen goedkeuringsprocedures kunnen uitstekend door workflow worden ondersteund.
3. De technische vormgeving
Dit hoofdstuk beschrijft hoe ICflow hardware en software-matig is opgebouwd en hoe het
binnen het netwerk van InvCom is ingepast.
4. Definities
Dit hoofdstuk is het meest uitgebreide van het basisontwerp. Het definieert in eenduidige
bewoordingen het logisch gegevensmodel van het dossier, de stadia van een dossier en de
verschillende documentsoorten.
E.4.6
Het Dossier
Benadering van dossiers
Dossiers kunnen via twee nummers worden benaderd: het relatienummer en het rekeningnummer. Het relatienummer is een uniek nummer dat aan alle relaties van InvCom wordt toegekend.
Dit nummer bestaat al bij het eerste contact met een relatie, en kan dus als uitgangspunt dienen bij
het benaderen van dossiers. Zodra een hypotheekrekening wordt geopend krijgt deze rekening
een uniek rekeningnummer. Dit rekeningnummer is het tweede nummer waarmee een dossier
kan worden benaderd.
Het relatie- en/of rekeningnummer worden door ICgiro II op het scherm getoond. Het DIPsysteem neemt deze nummers over: ze hoeven dus niet handmatig ingetoetst te worden.
Inhoud van het dossier
Van iedere bij InvCom lopende hypotheek wordt een dossier bijgehouden. Dit dossier bestaat uit
een electronische ’map’, waarin de documenten worden bewaard.
1. De map bevat de volgende informatie:
Het relatienummer
Het rekeningnummer (indien toegekend)
De naam van de (huidige) kredietmedewerker; Dit is de medewerker bij wie het dossier
in behandeling is. Door deze naam ’op’ de map te vermelden, kunnen nieuwe documenten naar de juiste medewerker worden doorgestuurd.
Het voorblad; Het voorblad is een invulformulier dat naar eigen inzicht kan worden
ingevuld en/of gewijzigd. Het voorblad kan gebruikt worden door de kredietmedewerker om een uittreksel van de documenten in het dossier bij te houden.
Notities; Bij ieder dossier kunnen notities worden gemaakt: deze notities zijn permanent en worden met datum/tijd en naam opgeslagen.
Op de papieren dossiers is met kleuren aangegeven in welk stadium een dossier zich
bevindt. ICflow biedt een soortgelijke markering. Hier wordt nog op teruggekomen.
2. De documenten in het dossier kunnen van heel verschillende aard zijn. Denk hierbij aan
bijvoorbeeld een aanvraagformulier, een taxatierapport, een getekende offerte etc. De
documenten bestaan uit een of meer ingescande pagina’s. Deze zijn aangevuld met de
volgende gegevens:
de datum
een inkomend/uitgaand indicator
212
het soort document
het aantal pagina’s
notities van ICflow (namen opstellers, controleur, ondertekenaars)
Benadering van documenten
Binnen een geopend dossier kunnen individuele documenten worden benaderd door ze uit een
door ICflow getoonde lijst te selecteren. Deze lijst bevat de voornaamste kenmerken van de
documenten en kan op een tweetal manieren worden gesorteerd:
op datum
op documentsoort en datum
Management van dossiers; Bekijken
De relationele DB die ten grondslag ligt aan ICflow kan met standaard programmatuur worden
benaderd. Op deze manier kan bijvoorbeeld informatie worden opgevraagd over:
Aantal dossiers;
Aantal dossiers in een bepaalde toestand;
Aantal dossiers per medewerker;
Aantal dossiers in een bepaalde toestand per medewerker.
ICflow houdt twee historische bestanden bij voor informatie die specifiek voor het management
is bedoeld:
De historie van toestandsovergangen; Iedere keer wanneer een dossier naar een nieuwe toestand overgaat, wordt dit in een historisch overzicht bijgehouden. Hierdoor kunnen
overzichten worden gegeven van;
– het aantal nieuwe aanvragen per periode;
– het aantal geopende hypotheken per periode;
– de (gemiddelde) tijd tussen de ontvangst van de aanvraag en de overgang naar een
geopende hypotheek.
de historie van managementvragen; Binnen ICflow is het mogelijk een of meer managementvragen te formuleren. Deze vragen moeten op bepaalde momenten in het proces van de afhandeling van de hypotheekaanvraag worden beantwoord. Hierbij kan gedacht worden aan
een vraag zoals: "Voor welk bedrag is de offerte aangemaakt?".
Management van dossiers; Ingrijpen
Er zijn twee mogelijkheden waarop kan worden ingegrepen in de ICflow bestanden:
Een wijziging van de toegewezen kredietmedewerker van een dossier
Op ieder dossier staat de naam van de behandelend kredietmedewerker vermeld. Deze
naam kan worden gewijzigd om het dossier aan een andere medewerker toe te kennen. Dit
kan per dossier afzonderlijk of voor alle dossiers van een bepaalde kredietmedewerker.
Het verwijderen van oude dossiers
Binnen ICflow is het verwijderen van oude dossiers vooralsnog niet mogelijk. Gezien
de lange bewaartijd van dossiers (langer dan dertig jaar) zal hieraan op een later tijdstip
aandacht worden besteed.
213
Verwerken
post kredietmedewerkers
Inscannen
post
Opzoeken/
aanmaken
dossiers
verkeerd
bezorgde
post
Distributie
poststukken
verkeerd
bezorgde
post
Nieuwe
aanvragen
Verwerken
post hoofd
afdeling
Figure E.6: De verwerking van de post
E.4.7
De Workflow
ICflow ondersteunt de stroom van de te behandelen documenten (werk) tussen de verschillende
medewerkers, evenals de verschillende activiteiten van een enkele medewerker.
Verwerking van binnengekomen post
De binnengekomen post is het startpunt van de workflow. Deze post wordt vanaf een centraal
punt gedistribueerd naar de verschillende medewerkers van de afdeling. Dit proces kan in de
volgende delen worden gesplitst.
de centrale verwerking en distributie van post
de individuele verwerking van post door:
– het hoofd van de afdeling
– de kredietmedewerkers
Dit is weergegeven in figuur E.6.
Centrale verwerking en distributie
Binnenkomende post wordt op een centraal punt verwerkt en gedistribueerd. Dit proces is in een
drietal stappen te verdelen:
1. Inscannen post
Alle binnengekomen post moet in het DIP-systeem worden ingevoerd door het met behulp
van een scanner in te lezen. Dit vereist enige voorbereiding: zo moeten pagina’s van
elkaar worden gescheiden en moeten buiten-formaat pagina’s (bouwtekeningen) worden
verkleind. Binnengekomen post kan uit pagina’s bestaan die later als één of als meerder losse
documenten worden opgeslagen. Deze opsplitsing gebeurt niet hier: de binnengekomen
post wordt per binnengekomen stuk verwerkt.
2. Opzoeken dossiers
Bij ieder ingescand poststuk moet nu het bijbehorende dosser worden opgezocht. Hierbij
wordt het binnnengekomen poststuk als het ware boven op het dossier gelegd om zo
verder te worden behandeld. Een dossier kan worden benaderd door het desbetreffende
relatienummer binnen ICgiro II te bepalen. Indien de relatie hier niet bekend is (wat
normaliter niet het geval zal zijn) wordt deze nu ingevoerd. Indien geen dossier aanwezig
is dan wordt een leeg dossier aangemaakt.
214
3. Distributie post
Voor verdere verwerking worden de poststukken met bijbehorende dossiers gedistribueerd
naar de verschillende kredietmedewerkers. In elk dossier is aangegeven bij welke medewerker het in behandeling is. Enkele documentensoorten worden behandeld door het
hoofd van de afdeling. Voorbeelden hiervan zijn nieuwe aanvragen, acceptatiestukken
en klachten. De keuze om een bepaald stuk naar het hoofd van de afdeling te sturen wordt
door de distribuerende medewerker (en dus niet door het systeem) gemaakt. Medewerkers
kunnen verkeerd gedistribueerde post voorzien van een mededeling retourneren. Deze
post kan dan opnieuw worden gedistribueerd. Post voor andere afdelingen kan hier uit
de workflow worden verwijderd; indien gewenst kan het poststuk eerst worden afgedrukt
(indien het origineel reeds is vernietigd of afgevoerd).
Individuele verwerking van post
Bij het verwerken van post krijgen medewerkers een lijst van te verwerken poststukken. De lijst is
op datum gesorteerd. Bij het verwerken van post zijn een aantal standaard-functies beschikbaar:
Raadplegen dossier
Het bij het poststuk behorende dossier kan onmiddelijk worden geraadpleegd, waarbij op
het voorblad eventueel notities kunnen worden aangebracht.
Uitstellen verwerking
De verwerking van een document kan worden uitgesteld. Bijvoorbeeld omdat telefonisch
moet worden overlegd en de andere partij niet bereikbaar is. ICflow geeft de uitgestelde
verwerking aan door middel van de sortering van de lijst met binnengekomen documenten.
Verzenden correspondentie zonder verzoek om antwoord
Een brief waarop geen antwoord wordt verwacht kan worden opgesteld en verzonden. Hierbij volgt ICflow de voor het document geldende goedkeuringsprocedure. Een voorbeeld
van deze correspondentie is een ontvangstbevestiging. De brief kan indien gewenst worden
opgenomen in het dossier.
Verzenden correspondentie met verzoek om antwoord
Een brief waarop antwoord wordt verwacht kan worden opgesteld en verzonden. Een
voorbeeld hiervan is de taxatie-aanvraag. Ook hier volgt ICflow de voor het document
geldende goedkeuringsprocedure. De brief kan indien gewenst in het dossier worden
opgenomen. ICflow kan de rappelering verzorgen.
Vraag en antwoord
Een document kan vergezeld met een vraag worden gestuurd naar een collega. Deze
kan dan het document en het bijbehorende dossier inzien en de vraag beantwoorden. Deze
functie is toegevoegd omdat het papieren dossier niet langer bestaat: het is dus niet mogelijk
om even naar een collega te lopen om daar een probleem voor te leggen.
Bovenstaande functies zijn (op uitstellen verwerken na) ook beschikbaar buiten de workflow om.
De gebruiker moet hiervoor eerst een dossier kiezen, en kan dan deze functies gebruiken.
Individuele postverwerking door het hoofd van de afdeling
Enkele soorten documenten worden door het hoofd van de afdeling in behandeling genomen.
Deze kan deze poststukken zelf afhandelen of doorsturen naar de kredietmedewerkers.
De behandeling van nieuwe aanvragen vereist hier wat extra aandacht: het hoofd van de afdeling
kan een aanvraag aan een kredietmedewerker toekennen, of kan de aanvraag weigeren. ICflow
bewaart alle in dit stadium geweigerde aanvragen in een apart archief: dit archief kan bij het
beoordelen van nieuwe aanvragen worden geraadpleegd.
215
Individuele postverwerking door de kredietmedewerker
De kredietmedewerkers verzorgen de verdere verwerking van de binnengekomen post. Dit
omvat onder andere de volgende activiteiten:
Opsplitsen van het poststuk in meerdere documenten; De pagina’s van het binnengekomen
poststuk kunnen indien gewenst worden opgesplitst in meerdere documenten.
Toekennen documentsoort en archivering; Aan ieder document moet een documentsoort worden toegekend waarna het in het dossier kan worden opgeborgen.
Bijwerken checklist; Aan de hand van het binnengekomen document kan de bij het dossier
behorende checklist en voorblad worden bijgewerkt. Met behulp van deze gegevens kunnen
verder acties worden gestart.
Goedkeuringsprocedures
Opstellen
document
Opstellen
document
Niet akkoord
Controleren
document
Niet akkoord
Niet akkoord,
Akkoord
Ondertekenen
document
Ondertekenen
document
Figure E.7: De goedkeuringsprocedures
Binnen InvCom Hypotheken geldt als regel dat uitgaande post voor verzending moet worden
gecontroleerd en ondertekend door een daartoe bevoegde medewerker. Afhankelijk van het
documenttype zijn er verschillende procedures. Deze zijn getoond in figuur E.7.
1. Uitsluitend ondertekening
De eenvoudige procedure is die waarbij het document direkt wordt afgedrukt en ter ondertekening wordt aangeboden aan het hoofd van de afdeling. Deze kan dan het document
ondertekenen of afwijzen. Hierbij kan het afdelingshoofd het bijbehorende dossier via zijn
DIP-station raadplegen.
2. Controle en ondertekening
Een iets uitgebreidere procedure is die waarbij het document eerst ter controle naar een
collega wordt gestruurd. Pas na deze controle wordt het document afgedrukt en ter ondertekening aangeboden.
3. Controle en dubbele ondertekening
De meest uitgebreide procedure is die waarbij na controle en ondertekening het document
ook door een directielid moet worden ondertekend. Aangezien directieleden geen DIPstation tot hun beschikking hebben, moeten de voornaamste documenten uit het dossier
worden afgedrukt om controle mogelijk te maken.
216
Controle van documenten
Voor de controle van een document stuurt de medewerker die het document heeft opgesteld
dit door naar een collega. ICflow geeft hiervoor een lijst van medewerkers die hiertoe bevoegd
zijn (dit zijn in principe alle kredietmedewerkers). De controlerende medewerker krijgt een
lijst van alle te controleren documenten. Bij afkeuring kan de controleur hiervan de redenen
aangeven, waarna de offerte wordt geretourneerd naar de kredietmedewerker. Bij goedkeuring
wordt de offerte op papier afgedrukt om ter goedkeuring te worden aangeboden. Bij dubbele
ondertekening worden bij het afdrukken tevens bijlages afgedrukt. Per documentsoort is dit een
vaste selectie documenten (waaronder voorblad, checklist en bepaalde documenten).
Bij het controleren van een document kan het bijbehorende dossier worden geraadpleegd. Tevens
is de ’vraag en antwoord’ functie beschikbaar. Na goedkeuring zal het document automatisch
worden afgedrukt zodat het kan worden ondertekend. De naam van de controleur wordt als
notitie aan het document toegevoegd.
Ondertekening van documenten
Bij ondertekening moeten zowel ICflow als de ondertekenaar een registratie hebben van de
ondertekende documenten. Voor de ondertekenaar drukt ICflow een ’afvinklijstje’ af van alle
door hem/haar te ondertekenen documenten. Dit lijstje heeft een tweetal functies:
1. Het kan gebruikt worden om de ondertekende documenten in ICflow aan te geven (door
het aanklikken van een op het scherm getoonde lijst).
2. Het kan door de ondertekenaar bewaard worden.
Bij ondertekening kan het document alsnog worden afgekeurd: deze wordt dan aan de opsteller
geretourneerd. Is een document ondertekend dan beschouwt ICflow het document als verzonden.
Indien de ondertekenaar een DIP-station ter beschikking heeft dan kan deze het bij het document
behorende dossier raadplegen. Ook hier is de ’vraag en antwoord’ functie beschikbaar. Heeft
een ondertekenaar geen DIP-station ter beschikking, dan kan ICflow het bijbehorende voorblad
afdrukken; dit blad moet dan voldoende notities bevatten om de ondertekenaar de mogelijkheid
te bieden het document te beoordelen.
E.4.8
Rappelering
Zodra een vraag is gesteld aan de buitenwereld (bijv. aan een relatie) dan moet worden gecontroleerd of op deze vraag antwoord wordt gegeven. Is na een gegeven tijd nog geen antwoord dan
moet hiervoor een rappel worden verstuurd. Vragen kunnen schriftelijk of telefonisch worden
gesteld. Bij het stellen van de vraag moet aan ICflow de volgende informatie worden verstrekt:
De maximale responstijd
ICflow zal na een ingegeven tijd (in dagen) waarschuwen dat voor een bepaalde vraag nog
geen antwoord is ontvangen.
Het bijbehorende item op de checklist
Om de rappelering zo flexibel mogelijk te maken, kan aan de vraag een item op de checklist
worden gekoppeld: zodra dit item als aanwezig/voltooid wordt gemarkeerd zal ook de
vraag als beantwoord worden beschouwd. Indien geen item is aangegeven, moet dit
handmatig gebeuren.
De rappelering kan naar keuze telefonisch of schriftelijk plaatsvinden. Na het verzenden van een
rappel moet opnieuw een maximale responstijd worden ingegeven.
De fax-functie van ICflow is beschikbaar voor het verzenden van vragen of rappels: de fax dient
hierbij als vervanging van de telefoon: de fax wordt nooit gebruikt voor het verzenden van andere
documenten.
217
Opstellen documenten
ICflow biedt geen faciliteiten om documenten op te stellen. ICflow biedt echter wel de mogelijkheid om gebruik te maken van het correspondentiesysteem van InvCom: Cor. Brieven worden
volledig opgesteld door het correspondentiesysteem. Zodra een brief is opgesteld wordt de
inhoud hiervan naar ICflow gestuurd en in de workflow opgenomen. Zodra de brief is gecontroleerd, en dus moet worden afgedrukt, geeft ICflow aan Cor door dat de brief is gefiatteerd.
Cor verzorgt dan het afdrukken van de brief. Zodra een brief ondertekend is, en dus verzonden wordt, geeft ICflow aan het correspondentiesysteem door dat het document verzonden is.
Cor verzorgt dan het bijwerken van de inhoudsopgave binnen ICgiro II. Indien een brief in de
workflow wordt afgekeurd, dan geeft ICflow dit aan het correspondentiesysteem door. Het correspondentiesysteem wordt dan opnieuw gebruikt om een nieuwe brief aan te maken, waarna
het proces opnieuw begint.
Workflow management
Het management van de workflow is op te splitsen in functies voor het bekijken en controleren
van de workflow, en functies om actief in de workflow in te grijpen. In principe zijn beide functies
alleen voor het hoofd van de afdeling beschikbaar.
Workflow management; bekijken en controleren
Binnen ICflow kunnen de volgende gegevens over de workflow worden opgevraagd:
Wachtrijen per activiteit
Per activiteit kan worden opgevraagd hoeveel werk er per activiteit nog moet worden
afgehandeld.
Wachtrijen per activiteit per gebruiker
Het overzicht van de wachtrijen per activiteit kan per gebruiker worden opgesplitst om zo
de individuele werklast te bepalen.
Bij beide overzichten kan tevens worden nagegaan hoeveel werk er langer dan een gegeven aantal
dagen ligt te wachten.
Workflow management; ingrijpen
Binnen ICflow kan op twee manieren worden ingegrepen in de workflow:
Overdragen van werk
Werk kan, samen met bijbehorende dossiers van één kredietmedewerker naar een andere
worden overgedragen. Deze overdracht is in principe permanent.
Tijdelijk toegang tot het werk van een collega
Per kredietmedewerker kan worden aangegeven wie er toegang heeft tot zijn/haar werk.
Deze mogelijkheid kan worden gebruikt om het werk van kredietmedewerkers tijdens
vakanties of ziekte aan anderen over te dragen.
E.4.9
Context
Het ICflow systeem heeft een interactie met acht andere actoren bij InvCom. De context waarin
ICflow geplaatst moet worden staat weergegeven in figuur E.8.
218
ICgiro
Scanning
operator
Cor
Systemsmanager
ICflow
Distributer
Board
Employee
executive
Head of the
department
Figure E.8: De context van het ICflow-systeem
E.5 Invoering
E.5.1
Planning
Na de fase basisontwerp, is er een planning opgesteld voor de verdere uitvoering van het project.
Deze planning omvatte dus zowel de fasen detailontwerp, realisatie en invoering. In deze
planning komen de volgende acht punten naar voren:
1. Voortgangsbespreking
Tijdens het verloop van het project zal eens in de twee weken een korte voortgangsbespreking worden gehouden, waarin de projectgroepleden op de hoogte worden gehouden van
de status van het project.
2. Platform installatie
Onder de noemer platform-installatie vallen alle activiteiten die nodig zijn om het platform
te creëren waarop ICflow zal functioneren: dit omvat de installatie en configuratie van de
AViiON server en werkstations tot en met de overdracht aan de produktie-afdeling InvCom.
Het overgrote deel van de activiteiten zijn reeds binnen het ICgiro project uitgevoerd.
3. Detailontwerp en realisatie
Het detailontwerp en de realisatie van de verschillende functies verloopt volgens een vast
ontwerp-bouw-test patroon. Er zal voor iedere voor gebruikers zichtbare module een
gebruikerstest worden gehouden. Met de term ’gebruikerstest’ wordt bedoeld een demonstratie van de module aan de gebruikers en de mogelijkheid voor gebruikers om gebruik te
maken van de module. Bedoeling van de gebruikerstest is in een zo vroeg mogelijk stadium
inbreng van de gebruikers mogelijk te maken.
4. Integratietest (15 dagen)
Tijdens de integratietest wordt de correcte samenwerking van de verschillende systeem-
E.5. Invoering
219
componenten getoetst. Deze test vindt eerst bij Data General plaats. Is het systeem daar
goedgekeurd, dan volgt een soortgelijke test bij InvCom.
5. Documentatie (25 dagen)
Het schrijven van de documentatie neemt veel tijd in beslag en is daarom als apart onderdeel
opgenomen in de planning.
6. Invoering (11 dagen)
De invoering omvat het installeren van software op PC’s, het opleiden van beheerders en
gebruikers en de door InvCom uit te voeren acceptatietest.
7. Acceptatie (14 dagen)
De acceptatie is in een drietal delen opgesplitst. Eerst vindt er een acceptatie plaats door de
gebruiker van de geleverde functionaliteit. Vervolgens moet er een eindacceptatie door het
hoofd van de afdeling worden gedaan en afsluitend de eindacceptatie door de gebruiker.
8. Nazorg (14 dagen)
Data General zal twee weken na oplevering aanwezig zijn om eventueel optredende storingen snel te verhelpen, en om gebruikers bij het gebruik van het systeem te begeleiden.
E.5.2
Architectuur
Het ICflow systeem kan aangemerkt worden als een client/server toepassing. De gebruikers
hebben toegang tot ICflow via de PC’s die als client fungeren. Via deze PC’s worden drie services
geboden:
Database service
De kern van ICflow is de centrale database waarin alle dossiers worden opgeslagen.
Workflow service
FloWare biedt een centrale activity manager die bij gebruik van ICflow de korrekte afhandeling van de workflow verzorgt.
Print service
De print service biedt de gebruikers de mogelijkheid om gezamenlijk een printer te delen.
Deze service is speciaal gericht op het snel kunnen afdrukken van ingescande pagina’s.
Gebruikers maken nooit rechtstreeks gebruik van deze services maar doen dit via de Windows
client-applicaties. Er wordt dus binnen ICflow geen gebruik gemaakt van bijvoorbeeld terminalemulatie. Naast ICflow kunnen gebruikers via de PC’s ook gebruik maken van ICgiro II; hiervoor
wordt uiteraard wel terminal-emulatie toegepast.
De client-applicatie bestaat uit een hoofdmenu waarin de activiteiten worden getoond waartoe
een gebruiker toegang heeft. Gebruikers zijn ingedeeld in groepen: iedere groep heeft toegang
tot bepaalde activiteiten. Iedere activiteit is een op zich zelf staande Windows-applicatie.
Hardware
De hardware componenten zijn te splitsen in server-systemen en client-systemen. De volgende
lijst geeft een overzicht van deze verschillende componenten:
Servers
– Database en floware server (1 maal)
De voornaamste server is de database en FloWare server. Deze server is geïmplementeerd op een Data General AViiON 4605 systeem uitgerust met magnetische schijven
voor indexgegevens en tijdelijk opslag van documenten en optische (WORM) schijven
voor lange termijn opslag van documenten.
220
– Print server (1 maal)
De print server maakt het mogelijk om op een centraal geplaatste printer afdrukken te
maken van documenten. De server is een PC waarop de Plexus print-server software
alle afdrukverzoeken afhandelt.
Clients
– Werkstations (7 maal)
Werkstations, waarmee gebruikers de ICflow applicatie kunnen gebruiken zijn PC’s
uitgerust met een speciaal hoge resolutie scherm en controller.
– Scanning station (1 maal)
Het scanning station is een werkstation waaraan de scanner is gekoppeld die gebruikt
wordt voor het inscannen van binnengekomen post. Het scanning station is hiervoor
uitgerust met een AIP (de)compressie kaart.
Alle bovengenoemde PC’s zijn minimaal uitgerust met een 486SX/20 processor, 8Mb intern
geheugen en een 40Mb harde schijf.
Netwerk componenten
De clienten serversystemen zijn via een netwerk met elkaar verbonden. Hiervoor wordt de
bestaande netwerkinfrastructuur van InvCom gebruikt: deze is hiervoor geschikt en biedt voldoende capaciteit. De database/workflow server is in de centrale computerruimte van InvCom
geplaatst. Het systeem is hier in één van de tokenring segmenten opgenomen. De AViiON heeft
een eigen tokenring controller.
De printserver en clientsystemen zijn op de hypotheken afdeling geplaatst. Al deze PC’s zijn in
het daar aanwezige tokenring segment opgenomen. Alle clientsystemen zijn hiervoor met een
IBM tokenring kaart uitgerust.
De verschillende systemen maken gebruik van TCP/IP om met elkaar te communiceren. Ieder
systeem heeft hiervoor een internet-adres toegewezen gekregen. Binnen InvCom wordt naast
TCP/IP ook Novell IPX gebruikt. Ieder van de werkstations is daarom met beide protocolstacks
uitgerust. De ICflow werkstations benutten hiervoor het ook elders binnen InvCom toegepaste
’LAN workplace for DOS’.
Werkstations maken tevens via terminal-emulatie gebruik van de ICgiro II applicatie. De Roflow werkstations maken hiervoor gebruik van de aanwezige componenten: de NSA servers in
combinatie met de ’Dynacomm Elite’ terminal emulator.
Software
De standaard software componenten zijn te splitsen in software die tijdens de bouw van ICflow
wordt toegepast, en software die tijdens het gebruik van ICflow wordt toegepast. Van ieder van
deze componenten volgt hier een opsomming:
Tijdens ontwikkeling
– Plexus workflow en 4GL omgeving
De ICflow applicatie is ontwikkeld binnen de Plexus workflow en 4GL omgeving. Deze
laatste omgeving biedt de mogelijkheid om snel Windows-applicaties te bouwen die
de centrale database kunnen benaderen en waarin images een voorname component
vormen. De workflow omgeving biedt naast een API onder Windows ook een API
onder DG/UX zodat ook op de centrale server delen van de applicatie kunnen worden
ontwikkeld.
– Microsoft C/C++ 7.0 en Windows SDK
Daar waar de 4GL omgeving tekort schiet, zal gebruik worden gemaakt van de Microsoft C/C++ en de bijbehorende SDK voor Windows. Hierbij wordt de compiler
E.6. Evaluatie systeem
221
als ANSI C compiler gebruikt. Het in C geschreven deel van de applicatie wordt zo
beperkt mogelijk gehouden.
– GNU C en embedded SQL
De delen van de applicatie die op de centrale server moeten draaien, worden in ANSI
C geschreven met embedded SQL om de database te kunnen benaderen.
Gebruiker
– Operating system
De AViiON server is uitgerust met DG/UX; een op AT&T Unix System 5.4 gebaseerd
operating system. Alle PC’s zijn uitgerust met DOS 5.0 in combinatie met MS-Windows
versie 3.1.
– Communicatie/emulatie
De AViiON server is uitgerust met TCP/IP. Zoals reeds vermeld zijn alle PC’s uitgerust
met ’LAN workplace for DOS’, terwijl alle werkstations tevens voorzien zijn van
’Dynacomm Elite’ voor terminal-emulatie.
– Plexus
Op de AViiON worden de Plexus data manager (relationele database manager) en
workflow activity manager gebruikt. Iedere PC is uitgerust met de run-time versie
benodigd voor de Plexus 4GL en workflow omgeving.
E.6 Evaluatie systeem
Om inzicht te krijgen in het functioneren van het systeem en de effecten op de gebruikers zijn
interviews gehouden met twee kredietmedewerkers en twee medewerkers van de administratie.
Deze interviews vonden plaats nadat de twee weken durende acceptatiefase was afgerond. De
ervaringen die de gebruikers met het systeem hebben opgedaan zijn daarom vrij beperkt, en
hetgeen in dit hoofdstuk daarover gezegd wordt moet dan ook in dat licht gezien worden.
E.6.1
Bij de evaluatie van de effecten op de gebruikers kan het onderscheid in de diverse functies
worden gemaakt. Het hoofd van de afdeling is tevreden. Winst is vooral geboekt op het gebied
van de controlemogelijkheden en de werkverdeling. De kredietmedewerkers zijn niet onverdeeld
positief. De vervanging van papieren document in gedigitaliseerd image biedt veel voordelen,
maar het ’onderhanden werk’ is niet overzichtelijker geworden; waar vroeger een dossier op het
bureau lag, wordt het nu met een regeltje op het scherm aangegeven. Waarschijnlijk is dit een
kwestie van gewenning. De dames van de administratieve afdeling zien een verarming van hun
werk. Het opzoeken van dossiers verdwijnt, evenals het typen van de offertes. In de testfase
beperkten de werkzaamheden zich tot het scannen van de inkomende post en de uitgaande
post. Op het moment dat de koppeling tussen het correspondentiesysteem en ICflow tot stand is
gebracht zal het scannen van de uitgaande post vervallen. Het hoofd van de afdeling zal voorzien
in extra taken voor deze dames.
E.6.2
Effecten op de organisatie
Door het feit dat de procedures van de afdeling Hypotheken ongewijzigd ten grondslag liggen aan
het ICflow system zijn de effecten op de organisatie klein. De papieren dossiers zijn verdwenen
en er wordt nu gewerkt met beeldschermen. Hoewel in de oude situatie ook beeldschermen
aanwezig waren, ten behoeve van de correspondentie en de toegang tot het ICgiro systeem,
waren die beeldschermen ondersteunend en dus voor periodiek gebruik. Het ICflow-systeem
ondersteunt echter ieder deel van het proces en daarom dient er continu mee gewerkt te worden.
222
De medewerkers ervaren dit als zeer vermoeiend voor de ogen, maar verwachten dat dit zal
wennen.
Het systeem voorziet ook in het electronisch sturen van berichten naar collega’s. Daar de afdeling
Hypotheken vrij klein is, zal er, zeker voorlopig, nog gebruik worden gemaakt van mondelingen
communicatie. De interactie met collegas zal dus niet lijden onder het systeem. Al met al
verwachten de medewerkers niet dat het systeem ingrijpende veranderingen op de organisatie
zal hebben.
E.6.3
Effecten op de efficiëntie
De kredietmedewerkers zijn het eens over het feit dat het systeem hun zal helpen om efficiënter
te werken. Het grootste probleem uit de oude situatie was de moeilijke vindbaarheid of zelfs
onvindbaarheid van dossiers. Dit leidde tot onnodig tijdsverlies, iets wat nu tot het verleden
behoort. Zoals al gemeld worden de overzichten die ICflow geeft van de nog te vervullen acties
als minder drukkend ervaren dan de papieren dossier die op het bureau lagen.
E.6.4
Totaaloordeel
Op basis van de summiere ervaringen van de medewerkers kan een voorzichtig oordeel geveld
worden. In de acceptatiefase heeft het initiatief van de individuele gebruiker een grote rol
gespeeld. Enthousiaste medewerkers hebben de gelegenheid aangegrepen om het systeem
goed te leren kennen, en anderen hebben het met de nodige reserveringen aangezien. De
daaruitvoortvloeiende ervaringen zijn daarom ook niet gelijk. Feit is dat het systeem naar behoren
functioneert, en dat de medewerkers geen problemen tegengekomen zijn die niet voortvloeien uit
de andere manier van werken, en dus na een zekere gewenningsperiode tot het verleden zullen
behoren.
E.6.5
De documentatie van het ontwerp van het systeem door tijdsdruk in het gedrang gekomen.
Dit kan in de toekomst problemen opleveren. De gebruikershandleiding, zoals die in eerste
instantie is opgesteld voldeed niet aan de wensen. Deze was opgesteld door de ontwerper en
ging daarom niet uit van de, voor wat het systeem betreft, ’onwetende’ medewerker. Deze
gebruikershandleiding wordt daarom opnieuw geschreven.
E.7 Evaluatie project
E.7.1
Vooraf zijn de doelen niet geconcretiseerd. De problemen die aanleiding vormden voor de
ontwikkeling van dit systeem lenen zich echter wel voor evaluatie. Dit zijn het dossierprobleem,
de doorlooptijdbewaking, de werkverdeling en de verhoging van de flexibiliteit. Deze staan
nader beschreven in paragraaf 2.3. Het dossierprobleem is zeker opgelost, daar in het systeem
de papieren dossiers zijn vervangen door images. Dossiers zijn niet meer zoek, wat leidt tot een
efficiëntere manier van werken. De doorlooptijdbewaking is ook gerealiseerd. Niet alleen heeft
het hoofd van de afdeling meer inzicht in de doorlooptijd van de aanvragen, maar ook worden de
hypotheekmedewerkers meer gewezen op onderhanden werk. Door middel van een uitgebreide
rappeleringsfunctie zal de doorlooptijd van een hypotheekdossier niet langer vergen dan strikt
nodig is. Ook op het gebied van de werkverdeling is vooruitgang geboekt. Het hoofd van de
afdeling, belast met de verdeling van nieuwe hypotheekaanvragen, heeft gemakkelijk inzicht in
de werklasten van de diverse kredietmedewerkers. Over het punt van de flexibiliteit kan weinig
gezegd worden. Door gebruik van Plexus zou deze voorwaarde gegarandeerd moeten zijn. De
mate waarin is iets wat in de toekomst zal moeten blijken.
E.8. Conclusies en aanbevelingen
E.7.2
223
De methode die door Data General wordt toegepast is niet formeel gedefinieerd en vastgelegd.
Als fasering wordt SDM II gebruikt en deze wordt ook aangehouden. Het is echter niet zo dat
alle fasen gescheiden in de tijd van elkaar plaats vinden. Dit om een snelle doorlooptijd van
het project te garanderen. Als modelleringstechnieken wordt gebruik gemaakt van ERD’s en
Yourdon DFD’s. Deze blijken van grote waarde.
E.7.3
Waardering binnen de organisatie
De waardering binnen de organisatie is goed. Hoewel het systeem niet is ontstaan als gevolg
van een vraag van de medewerkers, zijn ze er toch van overtuigt dat het systeem een zinvolle
ondersteuning is van hun werkzaamheden. De medewerkers die geen deel hebben uitgemaakt
van het projectteam zouden betere informatievoorziening gedurende het ontwikkeltraject op
prijs hebben gesteld. Voor deze kredietmedewerkers en medewerkers van de administratie is het
onduidelijk geweest wat voor een effect dit systeem zou hebben op hun werk.
E.7.4
Totaaloordeel
Door de problemen met het ICgiro-systeem heeft het ICflow project vertraging opgelopen. Het
ICflow project is niet geheel zonder problemen verlopen. Zo is de initiële planning niet gehaald,
zijn de eisen gedurende het project veranderd en zijn er problemen opgetreden in de communicatie
tussen de projectgroep en de stuurgroep. Deze problemen waren echter niet onoverkomelijk en
er kan worden teruggekeken op een geslaagd project.
E.7.5
Bij toekomstig aan te pakken projecten verdient het de voorkeur alle toekomstige gebruikers te
allen tijde voldoende voor te lichten over de gevolgen van een dergelijk systeem voor hun werk.
Ook zouden de uiteindelijke gebruikers betrokken moeten worden bij het ontwerp van de uiteindelijke schermen. Met name workflow systemen zijn van grote invloed op de manier van werken,
ook al ligt de procedure ongewijzigd ten grondslag aan het systeem. Een hoop onzekerheid wordt
op deze manier weggenomen en systeem zal met meer enthousiasme ontvangen worden.
E.8 Conclusies en aanbevelingen
E.8.1
Het onderzoek is goed verlopen. Er was voldoende informatie beschikbaar en alle betrokkenen
waren enthousiast en gemotiveerd om aan het onderzoek deel te nemen. Dhr. L.T.M. Dols,
hoofd afdeling InvCom Hypotheken, is ten allen tijde bereid geweest de benodigde informatie
te verstrekken om dit rapport zo compleet mogelijk te maken. Ook Data General, de leverancier
van het systeem heeft haar medewerking verleent. In het bijzonder zijn dhr. T. van der Stap, dhr.
R.N. de Regt en dhr. G. Berghorst dank verschuldigd. Ook adviesbureau DocWorld was bereid
tijd en moeite te investeren in dit onderzoek. Hiervoor zijn dhr. H.A. Kremers en dhr. J. van
Dijken dank verschuldigd.
E.8.2
Conclusies
Met ICflow beschikt InvCom Hypotheken over een goed werkend workflow systeem ter ondersteuning en stroomlijning van haar activiteiten. Het feit dat de procedures op deze afdeling
praktisch ongewijzigd zijn overgenomen in het systeem, resulteert een vrij gemakkelijk verlopende acceptatie door de gebruikers. Deze acceptatie had echter versoepeld kunnen worden
224
door de gebruikers actiever te laten participeren in de ontwikkeling van het systeem. De mate
waarin de voordelen van dit systeem naar voren zullen komen is iets wat in de toekomst zal
moeten blijken. Feit is dat met name aan de kant van de administratie het systeem haar tol op het
gebied van de werkgelegenheid eist.
Kortom: dit project laat zien dat een workflow systeem in de primaire produktie heel haalbaar
kan zijn.
225
Bibliography
[BB87]
S. Boomsma and H. Borrendam. Kwaliteit in diensten. Kluwer, Deventer, 1987.
[BBS93] Aart van den Berg, Ad Boumans, and George Spanhoff. De aanval op starre informatievoorziening: Workflow-management. Computable, 26(21):25–27, 28 Mei 1993.
[BJ93]
drs. ir. R.T.M. Bots and dr. W. Jansen. Organisatie en informatie. Samsom, Alphen aan de
Rijn, 1993.
[Boe89] H. Boer. Inleiding Organisatiekunde. Faculteit der Bedrijfskunde, Universiteit Twente,
1989.
[Bri90]
J.N. Brinkkemper. Formalisation of Information Systems Modelling. PhD thesis, University
of Nijmegen, 1990.
[Bul]
Bull Nederland N.V. FlowPATH produktbeschrijving.
[Bul93] Bull Nederland N.V./Pallas Athena B.V. Algemene visie op werkstroombesturing, september
1993.
[Bur85] J. Burch. Network topologies: The ties that bind information systems. Data Management,
23(12):34–37, December 1985.
[Daf92] Richard L. Daft. Organization Theory and Design. West Publishing Company, 1992.
[DK82] T. Deal and A. Kennedy. Corporate Cultures. Addison-Wesley, Reading, MA, 1982.
[Dur87] M. Durr. Peer networks gain ground. Computerworld, 21(4):39–44, February 1987.
[EGR91] C.A. Ellis, S.J. Gibbs, and G.L. Rein. Groupware; some issues and experiences. Communications of the ACM, 34(1):39–58, January 1991.
[EN86] E.K.C. Esseling and H. van Nimwegen. Administratieve processen, aanpak en technieken
t.b.v. vastlegging, analyse en ontwerp. Kluwer Deventer, 3 edition, 1986.
[EN89] Ramez Elmasri and Shamkant B. Navathe. Fundamentals of Database Systems. AddisonWesley World Student Series. Benjamin/Cummings, Redwood City, CA 94065, 1989.
[GL94] J.A. Gulla and O.I. Lindland. Modeling cooperative work for workflow management.
In G. Wijers, S Brinkkemper, and T Wasserman, editors, Advanced Information Systems
Engenering. Springer-Verlag, 1994.
[Har92] F. Harmsen. Het logistieke model en de synthese met data flow diagramming. Master’s
thesis, Katholieke Universiteit Nijmegen, 1992.
[HD93] R.W.H.W. Huffmeijer and M.M. Duitshof. Research questions for the wa-12 project.
University of Twente, 1993.
226
Bibliography
[HL91] Keith Hales and Mandy Lavery. Workflow management software: the business opportunity. Technical report, Ovum Ltd, 7 Rathbone Street, London W1P 1AF, UK, 1991.
[Jab94] S. Jablonski. Workflow Management Systems; Modelling and Architecture. Digital Equipment
GmbH, Karlsruhe Germany, June 1994. Tutorial Notes from the 6th CAiSE conference.
[KD91] drs. H.A. Kremers and J. van Dijken. Haalbaarheidsonderzoek Document Image Processing
van ChamCom. DocWorld, juli 1991.
[Kre92a] drs. H.A. Kremers. Functioneel ontwerp Applicatie InvCom Hypotheken. DocWorld, oktober
1992.
[Kre92b] drs. H.A. Kremers. Rapportage keuze leverancier ten behoeve van het D.I.P project van
ChamCom. DocWorld, juni 1992.
[LaP87] A. LaPlante. Small firms cite software training problems. Infoworld, 9(3):29, january 1987.
[Lee86] D. Lee. Usage pattern and sources of assistance for personal computer users. MIS
Quarterly, pages 313–325, december 1986.
[Lei88] R. Leifer. Matching computer-based information systems with organizational structures.
MIS Quarterly, March 1988.
[LH92] P. Lodder and H. den Hoed. Jaarverslag 1992 ChamCom, 1992.
[LT87]
R. Leifer and T. Triscari. Organizational information processing characteristics and
computer based information systems design. Technical report, School of Managment,
Rensselaer Polytechnic Institute, 1987.
[Mar92] R.T. Marshak. Requirements for workflow products. In David D. Coleman, editor,
Groupware ’92, pages 281–285, San Mateo, CA 94403, USA, 1992. Morgan Kaufmann
Publishers, Inc.
[Mer63] Merriam-Webster, Inc. Webster’s 7th Collegiate Dictionary, 1963.
[Mil86] D. Miller. Configurations of strategy and structure: Towards a synthesis. Strategic
Management Journal, 7(2):233–249, March-April 1986.
[Min79] H. Mintzberg. The Structure of Organizations. Prentice-Hall, Englewood Cliffs, NJ, 1979.
[Min81] H. Mintzberg. Organization design: Fashion and fit. Harvard Business Review, 59(1):103–
116, February 1981.
[Min83] H. Mintzberg. Structure in fives: designing effective organizations. Prentice Hall, Englewood
Cliffs, NJ, 1983.
[MJ94]
E. Mulder and S. Joosten. A literature investigation on workflow. University of Twente,
1994.
[NA85] J. Naisbitt and P. Aburdene. Reinventing the Corporation. Warner, New York, 1985.
[Nac82] J. Nack. Newton’s laws of data processing. The Economics of Information Processing,
0(1):19–31, 1982.
[OPBS93] J. Overbeek, P. Pottjewijd, H. Broekhuisen, and G. Spanhoff. Stroomlijnen van werkprocessen, Aanpak voor analyse en verbetering van interne bedrijfsvoering. DCE Nederland b.v.,
1993.
[PW82] T. Peters and R. Waterman. In Search of Excellence. Warner Books, New York, 1982.
[Reg93] R.N. de Regt. FLUSH Basisontwerp versie 0.10. Data General, augustus 1993.
Bibliography
227
[RSM84] J. Rockart and M. Scott Morton. Implications of changes in information technology for
corporate strategy. Interfaces, 14(1):3–16, January/February 1984.
[Uij81] A.A. Uijttenbroek. Een samenvatting van de System Development Methodology. Academic
Service, 1981.
[Vre91] A.A. Vreven. Systeemontwikkeling met behulp van SA/SD, SDM en SDW. Academic Service,
1991.
[Wid]
C. de Widt. Funktioneel ontwerp Registratie, inzage en reproduktie gedeponeerde jaarstukken.
ChamCom.
[Wil89] R. Wild. Production and Operations Management. Cassell Educational Limited, 1989.
228
Bibliography
Index
4GL, 3
flexibility, 97
FloWare, 46
FlowPATH, 27, 28
form, 12
full case handling, 11
function, 12
action, 11
activity, 9
external, 11
internal, 11
actor, 9
administrative organisation, 14
anticipating risks, 19
architecture, 16
archiving, 98
goals, 104
external, 104
internal, 105
groupware, 13
imaging, 3
implementation, 3
indexing, 12
information system
centralised, 90
decentralised, 89
distributed, 91
stand-alone, 90
InfTech, 22
integration, 99
IPO-paradigm, 75
IS, 5
IT-2000, 22
Basic Units of Work (BUWs), 23
BPR, 3
Bull, 27
business implications, 18
business process redesign (BPR), 15
Business Process Redesign/Re-engeneering,
3
CASE, 3
Case, 3
case folder, 11
Client/Server (C/S), 3
coordination mechanisms, 81
direct supervision, 82
mutual adjustment, 81
standardisation of outputs, 85
standardisation of skills, 86
standardisation of work, 83
CSCW, 13
Leifer, 75
logistics, 15, 101
management tasks, 77
method, 3
Mintzberg, 74
Data General, 38, 46
DDE, 3
DIS, 3
disconnection point, 102
division of labour, 80
document imaging, 14
DocWorld, 36, 42, 44
network plan, 12
object, 9
OM, 3
order, 101
organisation
contextual dimensions, 77
structural dimensions, 77
subsystems, 76
organisation type
adhocracy, 81
divisionalised form, 85
electronic file, 11
event, 9
external, 11
internal, 11
229
230
Index
machine bureaucracy, 84
professional bureaucracy, 86
simple structure, 82
Pallas Athena, 22, 27, 28
passing time, 102
Plexus, 41, 47
preparation time, 102
primary process, 101
process, 10
arrangement, 105
capacity, 101
control, 105
organisation, 106
quality of data, 100
queue, 101, 107
realisation, 4
role, 12
screen, 12
server, 4
SETI, 5
SPA, 5
step, 12
stock, 102, 107
system
closed, 75
open, 75
task division
horizontal, 80
vertical, 80
technique, 4
telematics, 15
throughput, 96
TIOS, 5
tool, 4
transport time, 102
trigger, 10
University of Twente, 5
WA-12, 4, 5
goal, 6
method, 6
proceedings, 7
research problem, 6
waiting time, 102
WANG, 30, 31, 35
WIIS, 31, 34
workflow, 10, 12
actor assignment, 16
ad hoc, 23
advantages, 18
application domain, 74
architecture, 16
automation, 12
control, 15
environments, 23
flexible structured, 23
functionality, 15
history, 13
logistic, 12, 22
management, 12
monitoring, 15
notification, 16
possibilities, 18
procedural, 12, 22
procedure management, 16
routing, 15
structured, 23
threats, 18
weaknesses, 18
workflow automation, 13
workflow management, 13
working order, 101

Workflow Automation in Four Administrative Organisations

Transcription

Similar documents

Design of a Domain Specific Language for a Dutch Student House

hoe beginnen met lightroom 4?

Design of drinking water treatment plants

Dia 1 - TES Industrial Systems

Northern Renaissance 1400 - 1500 PDF

programmaboekje - INCOSE

Waveguide lasers 31

HEATMASTER,YOUR HOTTEST INNOVATOR