Applied to financial services

Applied to financial services

Master Thesis in Computer Science

S.R.W. Algoe, BSc. (1154982) V.R.K. Boedhram BSc. (1149652) August 2009

Supervised by: Prof.dr.ir. J.L.G. Dietz - Delft University of Technology Ir. S. van Kervel - ForMetis Consultants B.V

2

DEMO introduced to financial services Chapter 1. Introduction S.S.R.W. Algoe BSc. V.R.K. Boedhram BSc.

Master Thesis in Computer Science

This research is performed for the research group: Computer Science - Information Architecture Faculty of Electrical Engineering, Mathematics and Computer Science Delft University of Technology P.O. Box 5031 2600 GA Delft The Netherlands The research is conducted at: ForMetis Consultants B.V Hemelrijk 12 c 5281 PS Boxtel The Netherlands

Supervisors: Prof.dr.ir. J.L.G. Dietz - Delft University of Technology Ir. Steven van Kervel - ForMetis Consultants B.V Executors: S.R.W. Algoe BSc. (1154982) - Delft University of Technology V.R.K. Boedhram BSc. (1149652) - Delft University of Technology

3


4


Dedicated to:

I dedicate this master thesis report to my father Ashok Hiralal Algoe and my mother Bidja Algoe Baldew on whose constant encouragement and love I have relied throughout my time at my study. How they raised me, and the lessons I have learned from them I can endure every obstacle in my live.

Your beloved son Shairesh Sherwin Rinesh Winay Algoe

5


6


I dedicate this master thesis document to: My parents Devanand Boedhram and Wasantimala Soebdhran My grandparents, George Bisoendath Boedhram, Radjkoemarie Dihal and Krishnawatie Phagoe My respect goes to my grandfather, Who has left me during this project G.B. Boedhram R.I.P. Honour goes also to the rest of my Family Who support me in achieving my goals, that I have set for myself in my life Vijay Radj Kiran Boedhram

7


8


Executive Summary Often organizations do not exactly know what they desire, when it comes to information systems. Professional companies like ForMetis are needed to give advice and design tailor made information systems for organizations that have the need of it. To do so, one usually uses a software developing methodology. ForMetis has developed such a methodology with their ten year of experience (The ForMetis methodology). The DEMO methodology is a powerful tool that has proven itself successful in the modeling of organizations. DEMO methodology models the essence of an organization and claims to be coherent, consistent, comprehensive and concise. It is a very powerful tool for identifying transaction of an organization and also the communication with the external actors. DEMO can be used as an aid to design information systems and can check the completeness of these systems whether it covers the essential business processes. The ForMetis methodology consists of the following phases: planning, analysis, design, implementation and system. The analysis and design phase are the most important phases. In these phases requirements are retrieved in an informal way and are written on large sheets, which are not reusable. Informal specifications are made and often the implementation is the specification. The new, so called F-DEMO methodology was discussed and a postmortem case (intermediary) was used to illustrate the added value of DEMO. The new methodology is the ForMetis methodology extended with DEMO in the analysis and design phase. In these phases the Construction Model, Proces Model and the State Model are added. These models are a valuable addition to the derivation of requirements and the making of specifications. In order to evaluate the use of F-DEMO a survey was held to check how many of the findings that were raised when producing the information system at the intermediary could be prevented. The findings were categorized in implementation, requirements, usability, misunderstandings, wishes and irrelevant types. From all these findings 33,1 percent could be prevented using the new methodology. The project time is also reduced. Therefore, the recommendation is to start using the F-DEMO methodology in future projects.

9


10


Preface This master thesis is the final part of the Computer Science – Information Architecture program at the faculty of Electrical Engineering, Mathematics and Computer Science of the Delft University of Technology in collaboration with the faculty Technology, Policy and Management. The Information Architecture program addresses the problem of designing and engineering enterprises including their IT applications. Enterprise engineering is a discipline concerning the design and the engineering (in the narrow sense) of enterprises, regarding both their business and their organization. Enterprise ontology is a formal and explicit specification of a shared conceptualization among a community of people of an enterprise (or a part of it). It includes static, kinematic, and dynamic aspects. In particular, enterprise ontology satisfies the next five quality requirements (C4E), coherence, comprehensiveness, consistency, conciseness and essence. DEMO is a methodology that is based on the concepts of enterprise ontology to design and engineer organizations. This methodology has proven to be effective in numerous projects in practice. ForMetis Consultants BV is founded in 1997 and is a software development organization that is specialized in developing tailor made software for the financial services industry. At that time, they recognized a gap between the software developer and the consumer, but they could not find any concrete solutions for this problem. Therefore, they developed their own methodology as a guideline to deal with software developing projects. In respect to the future, ForMetis wants to research the new developments in this area. They have recognized DEMO as a solution to their problems and want know what the effects are on the quality of the software when DEMO is applied to their own developing strategy. The quality aspects in this area are implementation, usability, complexity and development time. The goal of this report is to define, apply and examine the effects of a new development methodology that includes DEMO and deals with the quality aspects securely. First in Chapter 1, background information will be given on the subject of this project and the research question, scope and research approach will be formulated. Chapter 2 describes the recent methodology used by ForMetis and the new methodology that is extended with DEMO. In Chapter 3 the new methodology will be applied to financial services. Chapter 4 is about the research survey that is prepared to evaluate the new extended methodology. In Chapter 5, a comparison is made of both approaches. Finally, Chapter 6 will give a conclusion, Chapter 7 will give recommendations and in Chapter 8 a small discussion will be held. Special thanks to Prof.dr.ir. J.L.G. Dietz and ir. Steven Van Kervel for their guidance and supervision during this project. Delft, 2009 S.S.R.W. Algoe BSc. V.R.K. Boedhram BSc.

11


12


Table of Contents CHAPTER 1.

INTRODUCTION ........................................................... 19

1.1 BACKGROUND INFORMATION ........................................................ 19 1.1.1 The Software Organization ..................................................... 21 1.1.2 The Intermediary .................................................................... 23 1.2

RESEARCH GOAL ........................................................................... 24

1.3 RESEARCH APPROACH ................................................................... 26 1.3.1 Analysis phase ......................................................................... 26 1.3.2 Modeling and Validation phase ............................................... 26 1.3.3 Evaluation phase ..................................................................... 26 1.4 WORKLOAD AND OBSTACLES ........................................................ 27 1.4.1 Research needed for the thesis proposal .................................. 27 1.4.2 Create awareness within ForMetis Consultants BV ................ 27 1.4.3 Create awareness within Van Lanschot Chabot...................... 27 1.4.4 Research for the DEMO models .............................................. 28 1.4.5 Broader scope .......................................................................... 28 1.4.6 Intensive survey ...................................................................... 28 1.5

DOCUMENT OUTLINE ..................................................................... 28

CHAPTER 2.

INSPECTING METHODOLOGIES................................ 31

2.1 FORMETIS METHODOLOGY ............................................................ 31 2.1.1 Planning .................................................................................. 32 2.1.2 Analysis ................................................................................... 32 2.1.3 Design ..................................................................................... 33 2.1.4 Implementation ....................................................................... 33 2.2 F-DEMO (FORMETIS METHODOLOGY EXTENDED) ....................... 35 2.2.1 DEMO theory ......................................................................... 36 2.2.2 Operation Axiom .................................................................... 37 2.2.3 Transaction Axiom ................................................................. 37 2.2.4 Composition Axiom ................................................................ 38 2.2.5 Distinction axiom .................................................................... 39 2.2.6 Organization Theorem ............................................................ 39 2.2.7 Enterprise Ontology ................................................................ 40 CHAPTER 3.

APPLYING DEMO TO FINANCIAL SERVICES.......... 43

3.1 THE CONSTRUCTION MODEL (CM) ............................................... 44 3.1.1 Interaction Model (IAM) ........................................................ 44 3.1.2 Interstriction Model (ISM) ...................................................... 51 3.2

THE PROCESS MODEL (PM) .......................................................... 56

3.3

THE STATE MODEL (SM) .............................................................. 64

13


CHAPTER 4.

RESEARCH SURVEY .................................................... 69

4.1 SURVEY AND DATA PREPARATION ................................................ 69 4.1.1 Elimination of duplicates ........................................................ 70 4.1.2 Identification categories .......................................................... 70 4.1.3 Categorizing the findings into the categories .......................... 71 4.1.4 Identify the findings that could be eliminated with F-DEMO 72 4.1.5 Statement made in the survey ................................................ 76 4.1.6 Finishing the survey ................................................................ 77 4.2

RESULTS OF THE SURVEY .............................................................. 77

4.3

DISCUSSION PER TYPE ................................................................... 81

CHAPTER 5.

COMPARISON OF THE APPROACHES...................... 85

5.1

FORMETIS METHODOLOGY VS. F-DEMO METHODOLOGY ............. 85

5.2

PLANNING PHASE .......................................................................... 86

5.3

ANALYSIS PHASE ........................................................................... 87

5.4 DESIGN PHASE ............................................................................... 88 5.4.1 Motivation using the Construction Model .............................. 88 5.4.2 Motivation to use the Process Model ...................................... 89 5.4.3 Motivation to use the State Model without Action Model...... 89 5.5

IMPLEMENTATION PHASE .............................................................. 89

5.6

SYSTEM .......................................................................................... 90

5.7

BENEFITS AND DRAWBACKS .......................................................... 90

CHAPTER 6.

CONCLUSION................................................................ 93

CHAPTER 7.

RECOMMENDATIONS & FUTURE RESEARCH ........ 97

7.1

REVISE PLANNING PHASE BY ADDING PROJECT MANAGEMENT ..... 97

7.2

APPLY THE ACTION MODEL TO THE STUDY CASE ......................... 98

7.3

MAKE USE OF AUTOMATED TESTING WHEN IMPLEMENTING.......... 99

7.4

GENERATE INFORMATION SYSTEMS FROM DEMO MODELS ........... 99

7.5

MOTIVATE BUSINESS PARTNERS FOR USING FORMAL MODELS ....... 99

CHAPTER 8.

DISCUSSION ................................................................. 101

REFERENCES ........................................................................................ 105 INDEX..................................................................................................... 109 APPENDIX A

CHECKLIST PENSION AND LIFE INSURANCE....... 115

APPENDIX B

SURVEY ....................................................................... 139

APPENDIX C

SPECIFIC INFORMATION TABLE ............................ 175

APPENDIX D

MAPPING TABLE ....................................................... 177

APPENDIX E

DON PAPARASSOS ..................................................... 181

14


List of Figures Figure 1.1 Software development process [Davis, 2004] .............................. 20 Figure 1.2 DEMO recognized by ForMetis as the missing link .................. 23 Figure 1.3 Overview of the research approach ............................................ 26 Figure Figure Figure Figure Figure Figure Figure Figure Figure

2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9

ForMetis methodology based on prototyping. ........................... 31 Joint Application Design meeting room .................................... 32 DTAP model for software implementation and distribution ..... 34 F-DEMO (ForMetis methodology extended with DEMO) ........ 36 Operation Axiom ....................................................................... 37 DEMO basic transaction pattern .............................................. 38 Distinction Axioms .................................................................... 39 Organization theorem supported by ICT-systems ..................... 40 Organization theorem and the aspect models of DEMO ........... 41

Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure

3.1 The Aspect Models of DEMO ................................................... 43 3.2 Performa-Informa-Forma analysis ............................................. 45 3.3 Legend of the ATD and some basic construct ........................... 46 3.4 Global ATD of the intermediary ............................................... 47 3.5 Detailed ATD of the intermediary ............................................ 49 3.6 Legend of the Actor Bank Diagram ........................................... 53 3.7 The OCD of the Intermediary ................................................... 55 3.8 Legend of the PSD .................................................................... 56 3.9 PSD of business process 8 .......................................................... 58 3.10 PSD of business process 1 ........................................................ 59 3.11 PSD of business process 2 ........................................................ 59 3.12 PSD of business process 3 ........................................................ 60 3.13 PSD of business process 4 ........................................................ 61 3.14 PSD of business process 5 ........................................................ 61 3.15 PSD of business process 6 ....................................................... 62 3.16 PSD of business process 7 ........................................................ 62 3.17 Legend of the OFD (part 1) .................................................... 64 3.18 Legend of the OFD (Part 2) .................................................... 65 3.19 The OFD of the intermediary .................................................. 66

Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure

4.1 Approach of the creation of the survey ..................................... 69 4.2 Occurrences by type given in percentages ................................. 72 4.3 Occurrences detected with F-DEMO per type........................... 74 4.4 Relative findings detected with F-DEMO per type ................... 74 4.5 Distribution of the filtered types ............................................... 75 4.6 Distribution of the findings that could not be filtered ............... 75 4.7 Occurrences detected with F-DEMO per type (in practice) ...... 79 4.8 Relative findings detected with F-DEMO per type (in practice)80 4.9 Distribution of the filtered types (in practice) ........................... 80 4.10 Distribution of not filtered findings (in practice) ..................... 81

15


Figure 5.1 Phases in ForMetis methodology (in detail) .............................. 85 Figure 5.2 Phases in F-DEMO (in detail)................................................... 86 Figure 5.3 AH-way to elaborate business processes .................................... 87 Figure 7.1 Importance of the project-planning phase ................................. 98 Figure 8.1 Two Peaks identified from survey results ................................. 101

16


List of Tables Table Table Table Table Table

3.1 3.2 3.3 3.4 3.5

TRT of the intermediary ............................................................ 50 Part of the Bank Content Table ................................................. 52 Composite Production Banks ..................................................... 53 Part of the IUT of the intermediary ........................................... 63 Part of the OPL of the intermediary .......................................... 65

Table Table Table Table Table

4.1 4.2 4.3 4.4 4.5

Different categories according to the type of finding .................. 71 Number of findings by category .................................................. 71 Type of occurrences after mapping ............................................. 73 Results of the survey .................................................................. 78 Number of findings given the overall improvement .................... 78

Table 5.1 Benefits and drawbacks of the ForMetis methodology ............... 90 Table 5.2 Benefits and drawbacks of the F-DEMO methodology ............... 91 Table 8.1 Difference improvement rate per group ..................................... 102

17


BRIEF SUMMARY OF CHAPTER Chapter 1

1.1 Background Information Nowadays software has an immense role in the financial industry. On the other hand companies in the financial industry has become complex and need a formal hbnjjjjjjjjj to guide them to re (-engineer) their business processes. More methodology specifically the development of tailor made information systems is complex in the area of financial applications. ForMetis Consultants BV has detected that the production of financial products are very inefficient in comparison with the production of tangible and material goods within other industries. Van Lanschot Chabot (intermediary) is a client of ForMetis who struggles with the problems described.

1.2 Research Goal Until now, ForMetis have done the modeling of the production of financial service with an ad-hoc approach. However, the use of a formal methodology can improve the problems mentioned. Therefore, the goal of this research is to analyze and design the financial services with DEMO. In addition, research how it helps to improve the quality of them.

1.3 Research Approach The research approach of this project is divided in three phases. In the first phase, an environment analysis of Van Lanschot Chabot and ForMetis is conducted. In addition, the proposal for this master thesis is written and the research is done in the ForMetis way of designing software. In the second phase, DEMO is used to model the whole intermediary and the models are validated. In the last phase, the result are evaluated with the use of a survey

1.4 Workload and Obstacles An extensive research was needed to write a specific master thesis proposal. To complete the project in an efficient way, awareness had to be created at ForMetis and the intermediary for the need of a formal methodology. Due to the financial crisis, the intermediary stops participating practically in the project, but they still granted permission to use their information. Therefore, extra interviews were needed with the employees of ForMetis who were involved in the software development project of the intermediary. Because of the fact that two students performed this thesis made the scope broader, and therefore the whole intermediary had to be modeled.

1.5 Document outline In chapter 1 an introduction is given. Chapter 2 specifies the methodologies to be inspected. In chapter 3, the DEMO methodology is applied. Chapter 4 shows the result obtained. In chapter 5, the two approaches are compared. Finally chapter 6 gives a conclusion, chapter 7 the recommendations and chapter 8 the discussion that is held.

18


Chapter 1.

Introduction

Due to the financial crisis [Fratianni & Marchionne, 2009] many financial institutions need to change their business processes to get more transparency and to regain their trust from their customers. It is argued that with modern software and enterprise ontology approaches this can be accomplished. The software companies are specialized in implementing information systems that support business processes and the workflow of organizations with the aid of enterprise ontology. They claim to do it faster, less faulty, fewer costs and with the use of automated software. Mulder states that ontological approaches are a powerful concept to engineer organizations, because they are truthful and valuable [Mulder, 2006]. Many people agree that automation, speed, and perfection are key aspects that define the superiority of software development today. With increasing competition and demand of effectiveness, software development processes are getting more sophisticated with the combination of proven old and swift advanced technologies. Competition arises because of perfection and better services between companies and service providers. Moreover, to make a difference and be the favorite of customers, fast adapting the business strategy is needed to comply with the demands. Software companies need to change and invest in new software development methodologies to keep pace on the area of the business agility of the customers.

1.1 Background Information In the last decade, software has conquered an essential and critical role in the financial industry. Software development has become big business and so the emphasis to stay in business is put on high quality and shorter time to market of lower costs. The implementation of IT applications in organizations all over the world has improved the performance of their business processes, but still many software projects fail. The amounts of projects that fail are enormous [IT Cortex, 2001] [ZDNet, 2009]. More often, software projects fail or the budget costs and the resources needed are doubled because of a missing fundamental methodology for requirements gathering. Other reasons for failures of information systems that effect the implementation are political, functional, technical, and budgetary. [Kervel, 1999]. On the other hand, organizations and their way of working have become very complex so that their agility has come under pressure. It is known from the past that developing information systems is very difficult, because of its complexity and even harder when the right tools are missing. In addition, many mistakes are made when designing information systems. These mistakes are the cause of system changes and commotion for the system users. The law of Boehm [Boehm, 1981] says that a mistake that occurs in the beginning of a developing project will exponentially increase

19


the cost to repair the mistake in a later stadium. Recently, this statement was again confirmed [Jansen, 2003]. The most common problem here is that often the clients, who are asking for a software solution, do not know exactly what they exactly desire and how this could support their business [Davis, 2004]. This finding has increased the demand for a methodology that supports changing or merging enterprises in terms of their production design, their engineering and especially their IT applications. A criteria of this methodology is that it has to be scientific based and formal so that it is correct and can be verified on correctness. A methodology that satisfies these criteria‟ s can be used as a guide to limit the number of failures and cost when developing software solutions.

Figure 1.1 Software development process [Davis, 2004]

More specifically the development of tailor made information systems is complex in the area of financial applications. ForMetis Consultants BV [Formetis Consultants BV, 1998-2009] has found that the production of financial products is very inefficient in comparison with the production of tangible and material goods within other industries. Typical companies in the financial services industry are banks, insurance companies, stock brokerages, consumer finance companies, etc.). These companies run into specific problems when modeling the production of financial products such as loans, investments, insurance, etc. [Kervel, 1999]. Examples of these occurring problems are low service and quality levels to the customer, long

20


processing time of a financial product (even for simple productions), lack of management information, high production cost for a financial service (production per person per service is low), partial software solutions and long time-to-market for new products. The underlying reasons for these kinds of problems is that the production of financial services is difficult to model, because a service is a highly personalized and is a unique product that is produced in close collaboration with the client. This dependency makes the lifespan of such a service highly unpredictable and therefore very hard or even impossible to model. Kervel states that only fully predictable processes can be modeled in a formal way and these formally modeled processes can be automated with the traditional IT tools available. The main issues that lead to the problems distinguished earlier are a lack of predefined quality criteria and roles for persons responsible for the production of financial services, a lack of understanding between the balance of human and computer and a lack of a correct methodology for the production of financial services. The production of financial services is subjected to business rules and a strong interaction with a client who demands high service and quality levels. The information related to these services is typically stored in traditional legacy systems and electronic dossier systems. The electronic dossier system could contain information about business rules, information states and additional documents in many file formats. One of several software development projects that have been completed by ForMetis Consultants BV was a tailor made financial information system for a company called Van Lanschot Chabot [Van Lanschot Chabot, 2009]. This company is one of the largest financial companies in The Netherlands in which the earlier mentioned problems arise. In this matter this software development project will be used as a case study of this master thesis project.

1.1.1 The Software Organization ForMetis Consultants BV, from now on to be called ForMetis, is a company that designs information systems in their own specific way. They have been doing this since 1997 and are a solid partner of several client organizations that want to improve their information systems [Kervel, 1999]. In 1993, ForMetis founders started with Research & Development and in 1997, this Model Driven Architecture (MDA) based system went into production. For the construction of these tailor-made information systems a software design suite is used which is called DP (Don Paparassos) workbench (see Appendix E for a complete description of DP). The DP workbench is based on a philosophy called Don Paparassos, which gives a better understanding in organizing business. It consists of a software design suite, business methods to (re)design organization and business procedures to monitor organizations. Software is generated on the fly and is founded on a component-based framework. This means that an application is made by gathering readymade components and linking them together as a whole, in this way software applications could be made automatically without any programming [Gamma et al., 1994]. This approach is called Model Driven Architecture (MDA) and is introduced by the Object Management Group [OMG, 2008]. The components include workflow procedures, imaging functionality, text processing, generation of management information, agenda, deadlines, exception handling, interfaces to legacy applications and databases, embedding of standard windows applications, custom application development etc. DP is very flexible because applications can be modified at runtime, without interfere of the

21


users and letting the system to remain in a consistent state. These applications are built within a very short period (days instead of weeks or months) and in close interaction with the customer. These tailor made applications cost less than standard software packages. The information systems that are constructed with the use of DP are called “Slim Dossier”. The E-dossiers incorporated in “Slim Dossier” are intelligent, incorporate the knowledge of the production processes of the company and monitor them. The target industries of ForMetis are Insurance, Banking, Health Care and the Business service industry. ForMetis has a substantial record of accomplishment with an exceptionally high success rate in the banking and insurance world. ForMetis is located in Boxtel and counts about 10 employees in the Netherlands and Hungary and 2 interim students. ForMetis has the following philosophy: “Ambitious business targets can only be achieved if the

business strategy, the design of the organization, the design of the business processes and the information system are well understood, well balanced and well integrated.” [Kervel, 1999] The core business of ForMetis is to improve the production of financial services for their clients. Besides this, ForMetis disposes of a set of business methods, techniques and organization designing principles to produce, model and redesign services. During several workshops the products, production methods and processes of the clients are analyzed with interactive development and ad-hoc validation by knowledgeable users. This is conducted interactively with the customer, so that a working information system is designed and implemented on the fly with some working functionality. From this, the client can decide whether the system satisfies the requirements (considering production costs and quality) presented at the beginning of the workshops. In section 2.1 we go more deeply into the methodology used by ForMetis when retrieving the requirements of a new information system. After the requirements of the system are set, the implementation can proceed. If the client accepts the system, the information system is completed. ForMetis lacks a fundamental methodology that leads to the following issues:  No shared identical concepts, each person has a subjective interpretation.  No distinction between essential and non-essential.  No modeling on transactions.  No transaction processing and dynamic behavior analysis.  Informal approval by participants of the DP application, followed by later change of interpretations from all people involved. “This is a typical example of a “best practice approach”

as we do not really understand what we are doing, but this seems to be the best way to do it. The implementation is the specification” Steven van Kervel, ForMetis Consultants BV. 1999 Despite of a high level of customer satisfaction, these problems were already recognized ten years ago and therefore ForMetis is strongly interested in the

22


ontological modeling methodology DEMO (Design and Engineering Methodology for Organizations)[Dietz, Enterprise Ontology, 2006]. The DEMO theory is discussed in Section 2.2.1. This methodology fits perfectly within the methodology of ForMetis. For this cause, ForMetis wanted to do research on how DEMO is usable for the modeling of financial services and their application development in the financial industry.

Software Organizations

DEMO

Financial Organizations

Figure 1.2 DEMO recognized by ForMetis as the missing link Software organizations need to understand the business of the financial organizations to design high quality information systems. For the financial organizations on the other hand, it is necessary that they know what they expect from their information system to perform their business, this is not always the case. Most organizations do not know how to specify concrete process structures and requirements. If these process structures are specified in a concrete way, software organization will be able to translate these process structures and requirements in their language to implement the system. For this purpose, the software company needs to understand DEMO as well. The advantage of DEMO is that it specifies business processes and requirements in an unambiguous way and makes it understandable for everyone. Therefore, DEMO can be an aid for both organizations to help understand each other‟s business processes. DEMO is seen as the missing link between software and financial organizations.

1.1.2 The Intermediary As mentioned earlier Van Lanschot Chabot is used as a case study for this master thesis project. From now on Van Lanschot Chabot will be mentioned as the intermediary. The intermediary is one of the biggest intermediary insurance companies in the Netherlands. They work as a representative by selling several kinds of insurance products for several insurance companies. Some examples of these products are life insurance, pension insurance, health care insurance, vehicle and transport insurance, private damage insurance, fire insurance etc. The key value of such an intermediary is that it has expertise in giving advice to clients about insurance products that they are selling for the insurance companies. This aspect gives them the explicit disposal of expertise on the products that are available in this specific branch. When such an advice is given to a potential client, first an advice report is produced with the gathered information from a personal interview.

23


Based on the information stated in the advice report an offer is given to the client regarding the insurance that is discussed. The offer can be created by the intermediary or directly by the related insurance company, but in the second case, the intermediary remains to be the contact person of the potential client. When the potential client agrees to the offer, a policy is created either by the intermediary or by the related insurance company. Again, in the second case the intermediary remains to be the contact person. From this point on, we could speak of a client, earlier the potential client could not be seen as a client because in fact there was not yet a legal agreement between the intermediary and the potential client. This way of working is considered the core business of the intermediary. The processes based on the core business of the intermediary are modeled with a software tool called BWise [BWise, 2009]. BWise is a software tool that intents to help companies to forecast and give better perception of the consequences when (re-) engineering. BWise falls in the category compliance and risk management software, based on a fundament called Business Process Management (BPM). Processes, compatibility, performance management are the core business of BWise. Besides this, templates are designed which take into account guidelines and governance. The templates are seamlessly integrated into the BWise product suite. BWise is available in two versions, BWise Professional and BWise Expert. In contrary to BWise Professional when it is not necessary to be an IT expert, the second version gives the opportunity to define own processes. BWise saves the models of the described organization in a repository, which is based on Unified Modeling Language [Object Management Group, 2009]. However, the intermediary has the BWise models made they do not use it, because they find it to complicated and it does not provide any value to their business. In addition, when software development is needed, their IT department does not use these models, because the BWise models do not provide them with the needed information.

1.2 Research Goal In the past, and in their own specific way ForMetis has attempted to improve the production of financial services to make progress in the financial business. Based on their experience and the need to continue to make progress in this specific sector, they pose the following research question:

Are there models, methods or methodologies with which the quality of financial services modeling can be improved by ForMetis? For answer this question, ForMetis examined if DEMO [Dietz, Enterprise Ontology, 2006] is usable for the modeling of financial services and their application development in the financial industry. DEMO is a promising modeling paradigm to represent the essence of an organization. It is claimed by Mulder that the DEMO methodology is C4E (coherence, comprehensiveness, consistency, conciseness, and essence) certified and that any organization can be modeled with this methodology [Mulder, 2006]. It abstracts the activities of the organization at a high level, simply from the business domain and distinguishes between business, informational and documental actions. The concept provides four related aspect models, which are the construction model (represents the construction of an organization),

24


the process model (indicates the relations within the transactions), the action model (this includes all the business rules) and at last the state model (represents all the states of the production and de coordination world of the enterprise. When DEMO is compared with other process modeling techniques, such as Event Driven Process Chains (EPC), Petri Nets, Activity Diagrams and traditional flow charts, it can be stated that these other techniques do not define the business process well and do not distinguish the business and informational actions [Albani & Dietz, 2006] and lack a formal theory. Until now, the modeling of the production of financial services has been done with an ad-hoc approach by ForMetis. This is because financial services have several specific problems. They are difficult to mode, the execution is unpredictable, they are complex, they contain informal knowledge, etc. So the question that arises at this moment is; can it be done better? With better is meant: Can we improve the quality of these services with DEMO. Quality can be divided in modeling quality (only the essence is described), implementation quality (reducing processing time, faults reduction) and operation quality (production cost of a service). The research goal of this thesis is to answer the following main research question: “Can DEMO be used to analyze and design the services

within the intermediary insurance business and contribute to the service and product quality?” To answer this main research question, it can be divided into sub-questions that are listed below. 1. What do we understand by financial services within intermediary insurance company and how were they modeled when starting the construction of the information system? a. What are financial services and how do they relate to an intermediary and their customers? b. To which constraints is a financial service exposed in the insurance business? c. What were the exact findings (errors, bugs ambiguities) after launching the new software within the intermediary and how can they be categorized? d. Which quality aspects can be identified out of these services and to what extent can they be improved? e. What is the quality level at the intermediary at present and how is this measured? f. How are the financial services within the intermediary modeled nowadays? 2. How can the aspect models of the DEMO model, provide improvements to the modeling of financial services? a. What are the aspect models? b. How can the financial services be modeled with the aspect models? c. Which findings would not have been occurred after using DEMO modeling theory? d. To what extend do these models improve one or more quality aspects?

25


e. What are the efforts when a complete intermediary has to be modeled according to the DEMO methodology?

1.3 Research Approach The research approach used for this Master Thesis is illustrated in Figure 1.3. It consists of three phases: analysis, modeling and validation, and the evaluation phase. Every phase is subdivided into sub-phases to give a transparent view of the project planning and a fast overview of what was done in each separate phase.

Analysis •Environment Analysis at Van Lanschot Chabot •Environment Analysis at Formetis •Thesis Proposal •Research into Formetisway

Modeling and Validation •Research into DEMO way •Develop F-DEMO way •Applying F-DEMO way •Validating F-DEMO models

Evalutation •Comparison of F-DEMO and Formetis way •Improvements Suggestions

Figure 1.3 Overview of the research approach

1.3.1 Analysis phase During the analysis phase was studied what financial services of the intermediary exactly are, how they are documented for further use in the business and how they currently are designed. For this purpose, the intermediary uses BWise to describe their business processes in a nonformal way. The next step in this phase is getting a clear understanding on how ForMetis deals with a new development project in general and which kind of approaches they apply to develop these kinds of software applications.

1.3.2 Modeling and Validation phase In the modeling and validation phase, DEMO is applied to the software development case of the intermediary that was done by ForMetis. This is conducted based on a combination of interviews and on the reports generated from the workshops held by ForMetis at the intermediary. All the several aspect models of the DEMO methodology excluding the Action Model will be constructed, to create a good fundament for comparison with the ForMetis methodology. The models were validated by experts from the financial services industry.

1.3.3 Evaluation phase Within the evaluation phase, a survey is held with questions regarding the quality improvement on a new defined methodology based on DEMO applied by ForMetis. The focus of the survey will be on whether or not the modeling of financial services with DEMO can improve the quality of the financial information system. To determine this, a score will be assigned to every question based on the improvement that is gained with the use of DEMO. At this point all relevant data can be extracted from the survey

26


and assigned to each different part of the software development to give a better comparison of the current methodology of ForMetis and the new methodology based on DEMO.

1.4 Workload and Obstacles This section presents the workload and obstacles encountered by the executors of the project. The factors presented, may or may not have influenced the project directly, but they had an effect on the workload and/or total project time.

1.4.1 Research needed for the thesis proposal To find out what modifications were needed to improve the software development of ForMetis with the use of DEMO, an extensive research was needed in the analysis phase. Because of the fact that DEMO was never before introduced to the financial service industry, it made the research extra intensive to write a specific and concrete master thesis proposal.

1.4.2 Create awareness within ForMetis Consultants BV For creating awareness within ForMetis, many interviews and presentations were held with the employees. The development methods, problems during the production of financial information systems and new thoughts on the development of this were the main questions. In addition, the DEMO methodology was extensively presented to make them aware of the fundamentals on enterprise ontology and what the benefits are when applying it. In the modeling phase, first a part of the intermediary was modeled taking into account all three organization levels (the ontological, infological and datalogical level). This was done because the information technologists need to see these levels to identify themselves with them, because in practice they only recognize infological and datalogical steps. This was needed to show the power of the DEMO methodology to the experts and was applied to the global and detailed Action Transaction Diagram (ATD) and to the Transaction Result Table (TRT).

1.4.3 Create awareness within Van Lanschot Chabot For the modeling phase, an analysis of the financial services delivered by an intermediary and the related business process of these financial products was needed. For this purpose, Van Lanschot Chabot had to make aware of the fact that their company could be an excellent case study for this project. Presentations were given to the managers of the intermediary to state this need and the benefits of applying a fundamental methodology to their company. In the beginning, Van Lanschot Chabot was willing to participate actively into this project and gave permission to the fact that their company may be used as a case study, but when the effects of the earlier financial crisis appeared on the scene, they minimized their participation in this project, although the permission was still granted. Therefore, extra interviews were needed with the employees of ForMetis that were closely involved with the development of the information system developed for Van Lanschot Chabot, to retrieve knowledge for analyzing the business of the intermediary.

27


1.4.4 Research for the DEMO models To define DEMO transactions nearly 90 checklists (process descriptions) were analyzed to get a better view on how the intermediary executes their financial services. The intermediary makes use of BWise to model their business processes. To validate these checklists, 85 BWise diagrams were examined and analyzed. From all these checklists, BWise models and discussions with the experts, the transactions could be identified and specified.

1.4.5 Broader scope Because of the fact that two students performed the final thesis project, the scope had to be changed. So the scope was made broader from the modeling of two separate departments to the modeling of the complete insurance company.

1.4.6 Intensive survey In the evaluation phase, the F-DEMO methodology is evaluated with a survey. The survey is constructed by analyzing the 334 finding that was given by the users of the previously developed information system. All these findings had to be categorized and validated with the insurance expert at ForMetis who was in charge when developing the information system. For every interviewee, an introduction was given on how to fill in the survey. This was done by answering the first 25 question together with the interviewee. The total time needed for completing the survey was about 6 hours, this is to show how intensive the survey was for the participants.

1.5 Document outline In Chapter 2 the general methodology used by ForMetis for their software development trajectory is described. This provides a preview on the new methodology for designing information systems in which the DEMO methodology is used, and a brief introduction into the DEMO methodology. In Chapter 3 DEMO is applied to the intermediary as a case study. In this chapter DEMO aspect models are constructed, which are the Construction Model (Interaction Model and Interstriction Model), Process Model, the State Model and the Action Model. Chapter 4 provides the survey that is conducted with experts to evaluate the new methodology for the software development trajectory. It also provides the type of findings that were identified by the users of the system developed by ForMetis for the intermediary. The results on the improvement when using the new F-DEMO approach are also presented in this chapter. In Chapter 5, a comparison is made between the ForMetis methodology and the F-DEMO methodology. The comparison is made by researching the planning, analysis, design, implementation and maintenance phase of both approaches and by identifying the benefits and drawback of them. Finally, Chapter 6 will give a brief conclusion on this master thesis by answering the research questions stated in Chapter 1. Chapter 7 gives the recommendations on further steps and presents some of the future work needed. Chapter 8 embraces a small discussion about the result of the survey.

28


29


BRIEF SUMMARY OF CHAPTER 2

2.1 ForMetis methodology ForMetis is specialized in software development and therefore made its own methodology for that purpose. The ForMetis methodology consists of five phases. The first phase is the planning phase. The planning is done on an ad-hoc basis. In the second phase (analysis) workshop are conducted to retrieve requirements for the system. The workshops are based on the joint application design (JAD) method. In the design phase informal specification are made on large paper sheets. In the implementation phase, the system is implemented according the DTAP method. The implementation of the system is considered the specification of the system. In the last phase, the system is brought in production and is maintained.

2.2 F-DEMO (ForMetis methodology extended) In the F-DEMO methodology, the ForMetis methodology is extended with the DEMO methodology. The use of DEMO within the analysis and design phase of the ForMetis way will affect its software development methodology in a radical matter. The planning, implementation and system (maintenance) phase will be the same as in the old methodology of ForMetis. In the F-DEMO analyze phase enterprise ontology and the DEMO methodology is used to gather information to design the models for the system under consideration. This is still done in workshops together with the client. In this phase, an actor analysis is done and the business transactions of the intermediary are indentified. In the design phase the Construction Model, Process Model and State Model are constructed to retrieve the requirements for the system. This is done with the use of the operation, transaction, composition, distinction axiom and the organization theorem of the PSI theory. As an addition, the user interface requirements are specified in this phase.

30

DEMO introduced to financial services Chapter 2. Inspection of Methodologies S.S.R.W. Algoe BSc. V.R.K. Boedhram BSc.

Chapter 2.

Inspection of Methodologies

This chapter sets out two different kinds of development methodologies with respect to information systems. These types are the current methodology used by ForMetis and a new methodology that is extended with DEMO. Before a methodology in which DEMO is used could be described, it first has to be explained. The new methodology that is extended with DEMO will be referred as the F-DEMO methodology. Within the F-DEMO methodology, the relevant DEMO aspect models are used for the analysis and design phase. Note that the descriptions in this Chapter are brief and introductory. Chapter 3 will provide better insight into every aspect model with the use of applying these models to the intermediary case.

2.1

ForMetis methodology

ForMetis is specialized in software development and therefore made its own methodology for that purpose. The ForMetis methodology represents a software development methodology that is created, developed and used internally by ForMetis. It portrays a trajectory for the development of software applications. Figure 1.1 refers to the ForMetis methodology and depicts all different phases. As can be seen this way of software development is based on a phenomenon called prototyping. The prototyping method consists of the following phases: planning, analysis, design, implementation and maintenance. At the beginning of the software development process a prototype is constructed as soon as possible. This prototype is a plain version of the actual product that has to be developed eventually. With rapid prototyping, 70 percent of the functionality is implemented within 5 days.

Planning

Analysis Design

System (prototype)

Implementation

Figure 2.1 ForMetis methodology based on prototyping.

31


2.1.1 Planning This phase is a general approach for organizing a project into activities. They help the project manager and his team to decide what work should be done and in what sequence. This phase should be seen as an aid to thinking, not rigid prescriptions of the way to do things – each project will end up with its own unique plan.

2.1.2 Analysis ForMetis makes use of several workshops based on an information-gathering technique called joint application design (JAD). These workshops are conducted with each department of the company that needs the new software tool. Workshops are chosen above interviews because it has the ability to lead to intense discussions and improvement on the relevant subject within a group of persons. The project team, users of the system and the management are considered to work together during the workshops to identify requirements for the system. It is often the most useful method for collecting information from users [Wood & Silver, 1989]. The workshops are accompanied by a chairperson who is skilled in these techniques. The chairperson is someone who sets up the meeting agenda and guides the debate, but does not join in the discussion as a participant. During the session, he does not provide any ideas or opinions on the discussed topics and is assumed to remain neutral. He also has to be an expert in both techniques, namely process techniques and information systems analysis and design techniques. In addition, computers and computer-aided software engineering tools are used to record information as the session proceeds. The JAD group meets for several hours, several days or even several weeks until all of the issues have been discussed and the needed information is collected. Most JAD sessions take place in a specially prepared meeting room, away from the participants‟ usual offices, so that they are not interrupted by their work. An example of how this meeting room is setup is given in Figure 2.2.

Figure 2.2 Joint Application Design meeting room

32


At the front of the room, there is a whiteboard (that could be used as a background for a projector) and a flip chart. In front of this is where the facilitator leads the discussion. At the walls, there are enough flip charts where everyone could write on. During these workshops with each department the production methods, processes, and services of the client were analyzed. Some essential questions that have to be answered throughout the workshops are: What are the services of the company? Who are the clients? How can we make these clients happy? How do we manufacture these services now? How can we do better using electronic systems?

2.1.3 Design After the analysis phase is finalized, requirements of the financial services are gathered and written on large sheets of papers. This is conducted interactively with the customer, so that a working information system is designed on the fly containing some working functionalities. The simplest kind of requirement is a prototype of the user interface. This is a set of pictures of the system that are shown to customers and users in sequence, to give an indication on what would happen when the systems runs. It can often be a very powerful tool for eliciting ideas and feedback, and requires very little effort to create. Because paper prototypes are easy to create, they are ideal for parallel software development. A prototype is a rapidly implemented program that contains only a part (up to 70%) of the anticipated functionality of a complete system. Its purpose is to gather requirements by allowing software engineers to obtain early feedback about their ideas. The most common type of prototype within the ForMetis methodology is a “mock-up” of the system‟s user interface, created using a rapid prototyping language. Rapid prototyping in basic HTML allows you to create user interfaces very quickly to display the important parts of the system. Users can sometimes make actual use of a rapid prototype and often many modifications as necessary are made in response to satisfy the feedback from users. In addition to prototyping the user interface, sometimes the choice is made to prototype other aspects of a system, such as a database or an algorithm. As with all prototypes, the intent is to test and validate existing ideas, as well as to generate new ideas. . The analysis and the design phase are the most important phases of a software development project. In these phases, the requirements regarding the considered system are specified. Boehm describes that most of the fundamental mistakes are made in these phases. He also states that faults made in these stadia and discovered in a later stadium will increase the cost exponentially [Boehm, 1981]. From experience is shown that every mistake expressed in time costs thirty-two hours. Therefore, the importance of a fundamental method is needed to gather these requirements [Bergsma, 2007].

2.1.4 Implementation It is the desire of every end-user within the IT infrastructure to carry out his work without any form of interference caused by others. Emphatically the end-user does not want to be disturbed by computerization. For this cause, ForMetis uses an implementation based on a concept called DTAP (“OTAP” called in Dutch) for software implementation and distribution

33


[Bouwmeester & de Landsheer, 1997]. Within DTAP four independent environments could be identified, namely Development, Testing, Acceptance and Production. Also within the implementation phase, no cooking book exists that precisely describes how the implementation phase has to be done. In practice, every software development phase turns out to be a unique interaction between the computerization department and the end-users in compliance with infrastructural and organizational possibilities.

D

P

Software

T

A

Figure 2.3 DTAP model for software implementation and distribution

The development and testing environments are the responsibility of ForMetis, but their client is accountable for the Acceptance and Production environments. This is because eventually the software has to run on their infrastructure. It is also explicitly necessary to make different use of both Testing and Acceptance environments. Within the Testing environment, the focus is on preventing the early appearances of bugs in the software and in the Acceptance environment, the focus lies on determination of the quality of the product. Obviously, the quality is what primary matters for the client. Additionally recovering the occurrences of any bug within the Acceptance is hard, the only thing that now could be determined is if the usability of the system is maintained. Not only the end-user, but also the system administrators have to notify ForMetis about their demands on the maintenance of the system. The development environment is an administration environment where the modifications and the new functionalities are designed and elaborated. The users of this environment are administrators (who prepare packages for distribution and installation), developers of various software distribution packages and developers of specific applications. According to the ideal DTAP model, the user from this environment should not have access to another environment. However, mostly in software distribution this is not the case because system administrators will be active within other environments. The test environment has as primary objective to test the modification that has been made in the development environment on functional,

34


technical, integral and especially procedural level. If necessary, measurements can be taken to analyze the impact of the modification made. The modifications are executed in the test environment on similar hardware that is used in the production environment. In this way, you stay clear of hardware specific problems. The modifications from the development environment are analyzed in the test environment. When a flaw is detected within the modification, it first has to be corrected in the development environment. Ad-hoc changes are not allowed in the test environment. ForMetis uses this environment in an additional way and they allow the users of the application to test the software. The findings during this testing are then passed on by the users to the developers. The acceptance environment is meant for the end users. The primary role of this environment is to monitor if the changes that were made can be handled by an environment that resembles the production environment at most. Hereby is assumed that the development and test environment are not for hundred percent configured as the production environment regarding high cost and investments. For this environment, the same holds when a modification has a flaw. It first has to be corrected in the development environment and tested before it can be analysed in the acceptance environment. The production environment is the actual environment of the end user. This environment supports the business process of the organization into consideration. When the changes that are made in the acceptance environment are fully agreed upon, it can be adopted in the production environment. It is of the most importance that failures do not occur within this environment. Since the changes of the packages have successfully completed in the development, test and acceptance phase, it can be installed on several workstations.

2.2 F-DEMO (ForMetis methodology extended) Investigating the methodology used by ForMetis one comes to several findings on the fundamentals that are used in every phase of the software development. First by the absence of a good software engineering practice, the great importance of working out the requirements and the design before any implementation is ignored. In addition, the use of this form of prototyped software engineering has its drawbacks. At first, it costs a lot of time because prototypes are rebuilt when the requirements are known. After the finishing of a prototype, the client may have the idea that the project is nearly finished while plenty of work still has to be done. Since there is no good plan designed in the planning phase there is nothing identified to aim towards. Since there is nothing to aim towards, ForMetis could never know if they are doing well or poorly. Therefore, the control of costs and schedule are not to be found. However, there is a vague consensus, because the development is faster than ever and the client is satisfied with the result. In the analysis phase, the use of JAD to acquire system requirements is a powerful tool. However JAD suffers from the traditional problems associated with groups, sometimes people are reluctant to challenge the opinions of others (particularly their boss), a few people often dominate the discussion, and not everyone participates. The consequence of not having a good design of the system has various weaknesses that limit their usefulness for creating the final version of complex systems. The weaknesses include inefficiency, and limitations on the ability to create robust and flexible designs. The internal quality of

35


software deteriorates faster if it is not well designed. Because in the ForMetis methodology the design phase is an ad-hoc activity, rapid deterioration of internal software quality is to be expected. The current use of prototyped user interfaces also fails, because there is often nothing much behind the user interface. It may not, for example, perform any computations, access any databases or interact with any other systems. However, not much effort is needed into designing its architecture, therefore it will become hard to maintain, and will contain many bugs. When in a later phase the requirements are reconsidered, making them undone is not easy because it takes more time for the programmer to modify the current software. Rebuilding new software is often easier. The design phase has a lack of modeling concepts which makes it harder for the programmer to get a clear vision on what the client really wants, and even harder to translate this vision into software. There is also no explicit recognition of the need for systematic testing and other forms of quality assurance. Many undetected defects therefore remain, giving rise to never-ending changes that make the system worse. As a result, the system most often collapse at some point and becomes unusable and irreparable. The only solution is then to rebuild the system from scratch (until it collapses again). The negative aspects make the cost of developing and maintaining software very high. Despite these negative aspects, it has to be said that ForMetis has never let a software project fail and the clients were always satisfied. The use of DEMO within the analysis and design phase of the ForMetis way will affect its software development methodology in a radical matter. As shown in Figure 2.4 the implementation phase is now done apart from the analysis and design. This is because with the use of DEMO all system requirements have to be described and modeled before any implementation is done. Additional it will have consequences for all different phases, the planning could now be better done because the whole system could be divided into independent software components; the analysis and design phases will result in better-defined requirements; before the implementation phase is reached, the analysis and design are finished. From this point, the programmer of the system only has to deal with programming errors, requirements are no longer his worst nightmare.

Planning

Analysis (DEMO)

Implementation

System (prototype)

Design (DEMO)

Figure 2.4 F-DEMO (ForMetis methodology extended with DEMO)

2.2.1 DEMO theory The DEMO methodology is developed at the Delft University of Technology under the supervision of Prof. Dr. Ir. Jan L. G. Dietz [DEMO Knowledge Center, 2008]. DEMO is a methodology that is designed for (re)designing and (re)engineering of organizations and is based on a scientific fundamental theory called Ψ-theory (pronounced as PSI-theory

36


and stands for Performance in Social Interaction). The Ψ-theory states that organizations belong to the category of social systems. In these social systems, human beings have the ability to comply with commitments toward each other. This is called social interaction [Dietz, Enterprise Ontology, 2006]. Hence, there is an essential difference between organizations and other systems, like information systems. Information systems belong (only) to the category of rational systems. This implies that they do not make decisions, but only calculations, and in doing so only support decision making [Barjis et al., 2002]. The Ψ-theory at the same time also explains that applying information systems methods and techniques on organizations do not deal with problems like merging, splitting, designing, engineering etc. of enterprises. The Ψ-theory has four axioms and one theorem that will be described in the following sections. An axiom is a proposition that is not proven or demonstrated but is considered self-evident. Its truth is taken for granted, and serves as a starting point for deducing and inferring other (theory dependent) truths. Next, a theorem is derived from earlier accepted or established statements such as axioms.

2.2.2 Operation Axiom The first axiom is displayed in Figure 2.5. It represents the operation of an organization as a system that performs production acts and coordination acts, which results in production facts and coordination facts. This axiom is therefore commonly referred as the operation axiom. By performing production acts (P-acts), actors contribute directly to the realization of the function of the organization. P-acts may be material (storage e.g.) or immaterial (judging e.g.). With the performing of coordination acts (Cacts), actors enter into and comply with commitments about production acts. C-acts are called atoms of an organization because they are the units of action in which exactly one commitment concerning exactly one P-fact is brought about. Some examples of C-acts are requesting and promising. In DEMO, an actor is described as a subject in the fulfillment of its actor role [Dietz, Enterprise Ontology, 2006].

COORDINATION

PRODUCTION

ACTOR ROLES C-act

P-act Actors

C-world C-fact

P-world P-fact

Figure 2.5 Operation Axiom

2.2.3 Transaction Axiom The second axiom of Ψ-theory is the transaction axiom. This axiom states that C-acts and P-acts always and only occur in universal patterns, called (business) transactions [Dietz, Enterprise Ontology, 2006]. Transactions are called molecules of an organization, because they are composed out C-acts and P-facts that are atoms in an organization. Figure 2.6 shows that when

37


performing a transaction two actors are involved with it at all times. The person that starts the transaction and eventually completes it is called the initiator (customer), the other one, who actually performs the objective action, is called the executor (producer).

request

desired result

result requested O-phase

promise

result promised

E-phase

customer

result accepted

accept

R-phase result stated

result produced

producer

state

Figure 2.6 DEMO basic transaction pattern

2.2.4 Composition Axiom The third axiom of the Ψ-theory states that transactions occur in a tree structure. This means that a transaction can be composed out of other transactions. An example of such a transaction can be found in the fast food industry. A hamburger is created when the bread is toasted, the meat is grilled and the bread is dressed with the ingredients. So for the creation of the hamburger, three transactions are needed: (1) toast bread, (2) grill meat and (3) dress bread. A transaction can be initiated in three different ways: as a self-activation transaction (for periodic actions), by an actor role in the environment and enclosed in another transaction. A transaction enclosed in another transaction is called an autonomous business process. In this way, periodic action can be conceived. Each tree of enclosed transactions is an instance of a business process under execution. Business processes form the fibers of organizations. As can be seen in Figure 2.6 a transaction consists of three phases. In the order (O-phase) the initiator and the executor are negotiating to reach an agreement about the result (P-fact) to be established (e.g. delivery of some performance). The basic C-acts here are the request and the promise. In the execution phase (E-phase), the executor produces the result of the Pfact that is agreed upon in the O-phase (e.g. deciding about some performance). In the result phase (R-phase), the initiator and the executor negotiate to reach an agreement about the established result. The R-phase starts with the statement by the executor, and ends with the acceptance by the initiator, or not. In this case, only the basic transaction pattern is

38


depicted. In a complete transaction pattern, which is often used in practice one will also find transactions with cancelation patterns (e.g., declining a request, rejecting a statement), but these will not be considered.

2.2.5 Distinction axiom The fourth axiom, the distinction axiom describes that in fulfilling actor roles three human abilities are involved in performing P-acts and C-acts: the ontological (performa), the infological (informa) and the datalogical (forma) capabilities (Figure 2.7). At the coordination side, the performa ability indicates that one is able to feel committed as performer or addressee of a coordination act. The informa ability at the coordination side describes that one has the ability to formulate and interpret thoughts. The forma ability at the coordination site point out that one is able to speak, write, listen and read. On the production side, the performa ability is producing a new P-fact, like deciding and judging. The informa ability at the production sides describes the act of doing something with the content of the information, like computing and reasoning. The forma ability at the production side concerns the ability of performing datalogical acts, like storing, transmitting etc.

COORDINATION

HUMAN ABILITY

exposing commitment (as performer)

evoking commitment

PRODUCTION

ontological action (deciding, judging)

(as addressee)

expressing thought (formulating)

educing thought

infological action (reproducing, deducing, reasoning, computing, etc.)

(interpreting)

uttering information (speaking, writing)

perceiving information

datalogical action (storing, transmitting, copying, destroying, etc.)

(listening, reading)

Figure 2.7 Distinction Axioms

2.2.6 Organization Theorem The Organization Theorem is the only theorem that exists in the Ψ-theory. This theorem states that the organization of an enterprise is a heterogeneous system that emerges from the layered integration of three homogeneous systems (Figure 2.8): the B-organization (B for business), the I-organization (I for Intellect) and the D-organization (D for document). It is allowed for the members of the organization to take part in all the three aspects organizations. Each of the three homogeneous systems represents a different aspect of the total organization. Moreover, each aspect contains a function and construction side. The construction of the D‐organization is supported by the function of hardware. The construction of the

39


I‐organization is supported by the function of the D‐organization. In addition, the construction of the B‐organization is supported by the function of the I‐organization. Depending on the task, an actor can take the shape of a B-, I- or D‐actor. On the production side, D‐applications are generic software such as text processors and database management systems. I‐applications are enterprise (type) ‐specific software such as accounting systems and human resource applications. B‐applications are decision support systems. On the coordination side, D‐applications are typically networking and e‐mail systems. I‐applications are workflow systems and B‐applications are process‐management systems.

Figure 2.8 Organization theorem supported by ICT-systems

2.2.7 Enterprise Ontology The ontology of an enterprise describes the construction and the operation of the B-organization as has been depicted in Figure 2.8. The ontological model of an enterprise shows only its essence, fully abstracted from realization and implementation. This is the strength of the DEMO methodology, in contrary to other approaches that firmly link the essence to the realization, implementation and operation. A complete ontological model consists of four aspects models, the Construction Model (CM), the Process Model (PM), the Action Model (AM) and the State Model (ST) (see section 0 for a complete description of these models). The Construction Model indentifies the actor roles, transaction types and the information links from actor roles to production or coordination banks [Dietz, Enterprise Ontology, 2006]. The Process Model specifies the causal and condition links between the transactions. The Action Model specifies the action rules that actors apply in carrying out transactions. The State Model exhibits the

40


object classes, fact types, and event types, as well as the existence and occurrence rule. The ontological model has proven to be an ideal beginning point in enterprise (re)engineering projects and it has been used in more than 100 projects. Ontological models are also used for the derivation of use cases, databases schemas and (business) components in a consistent and coherent way. As can be seen in Figure 2.9 the red expansion gives the ontological model for the B-organization. Not shown in the figure are a green expansion that represents an infological model and a blue expansion that stands for the datalogical model.

B-Organization

I-Organzation

D-Organization

CM

PM

SM

AM

Figure 2.9 Organization theorem and the aspect models of DEMO

41



3.1 The Construction Model (CM) The Construction Model (CM) of an organization specifies its composition, its environment and its structure. In this model, the identification of a business transaction is the most important step because they are the core entities on which an organization is build. The CM is divided in the InterAction Model (IAM) and the InterStriction Model (ISM). The Interaction Model focuses on the specification of the business transaction types that take place between the organization under examination and its environment, as well within the organization. Secondly, it specifies the actors between the boundaries of the organization with their initiation and execution roles. The IAM is expressed in an Actor Transaction Diagram (ATD) and a Transaction Result Table (TRT). The CM of the intermediary is constructed by analyzing several checklists of the intermediary and conducting interviews with experts. The complete IAM of the intermediary consist of five composite actor roles and three elementary actor roles. The intermediary counts eight transactions, which have to be fulfilled by the relevant actor roles.

3.2 The Process Model (PM) The Process Model provides the specification of the state space and the transition space of the coordination world. As it is known from the transaction axiom, the Cworld consists of the creation of a C-result and every transaction in the C-world exists of the creation of a C-result. So in fact, there is a one-to-one relationship between this C-result and the causing C-act. The PM of the intermediary is expressed in a Process Structure Diagram (PSD) and an Information Use Table (IUT). The PM also provides a full specification of the causal and conditional relationships between the business transactions. The PM of the intermediary consists of eight business processes. The most complex business process is the damage claim handling process. In the case of the intermediary, the PM can be very useful as the starting point for requirements engineering regarding information system. The PSD and the IUT contains all the information that is needed for a sensible discussion and leaves no room for unnecessary requirements.

3.3 The State Model (SM) The State Model (SM) provides a complete and precise specification of all the information that is created and/or used by the organization of the intermediary. The SM consists of object classes, fact types, result types and existential laws that hold. The fact types can be divided in derived or original facts. All the facts, whether it is an original or a derived fact, are results of the successful execution of the business transaction processes. For organizations and especially the intermediary, the SM is a proper model to gather information regarding requirements engineering. Due to the property that SM is structured in chunks around the main objects, it can be used to a business component-based design. This is for great importance in all Rapid Application Development (RAD) methods.

42

DEMO introduced to financial services Chapter 3. Applying DEMO to financial services S.S.R.W. Algoe BSc. V.R.K. Boedhram BSc.

Chapter 3.

Applying DEMO to financial services

Before applying DEMO to financial services, the methodology had to be introduced to the insurance experts to let them have some understanding what it is. This was done by giving several presentations to ForMetis and to insurance experts of the intermediary about enterprise ontology and the notion of the DEMO methodology. In these presentations, the way of thinking and some examples of the use of DEMO were presented. To obtain experience and knowledge about the financial industry, more precisely about insurances and policies, the experts working at ForMetis were interviewed and desk research was done. In this chapter, the DEMO methodology is applied to the intermediary and its relevant aspect models as shown in Figure 3.1. The reason that the aspect models are placed in a triangle shape is because in this way it represents their mutual relationships. The Construction Model occupies the top of the triangle because it is the most concise model and represents the construction of the organization. This model consists of the Interaction Model and the Interstriction Model. The Process Model contains for every transaction type a transaction pattern (often called a business process). The State Model specifies all the information per state that is created or used by the system. Last of all models, is the Action Model that is positioned at the bottom of the triangle, because it gives the most detailed view of the organization. It specifies the action rules that serve as a guideline to execute the business process. Construction Model

Interaction Model

Interstriction Model IAM ISM

ATD TRT ABD BCT PM

SM

Process Model

State Model PSD IUT

OFD OPL

AM

Action Model

Figure 3.1 The Aspect Models of DEMO

43


3.1 The Construction Model (CM) According to Dietz, the Construction Model (CM) of an organization specifies its composition, its environment and its structure. In this model, the identification of a business transaction is the most important step because they are the core entities on which an organization is build. The CM leaves out issues of the process order and wraps the coordination and production facts and acts of each transaction into one package. This potential makes it the most concise and easily understood DEMO model. The environment and the composition are both considered a set of actor roles. By convention, the kernel of the intermediary is a composite actor role. This is generally conducted to identify the transactions between the kernel and the external actors. At the kernel of the intermediary, there exists elementary actor roles and therefore this more detailed model is called a detailed CM. The composite actor roles are separated from the elementary actor roles in the kernel by a boundary. The CM is divided in the InterAction Model (IAM) and the InterStriction Model (ISM). The IAM specifies the actor roles in the organization and the transactions that take place between them and the ISM specifies the relationship between the actor roles in the organization and the information banks used by them. In this chapter, the IAM and ISM of the intermediary will be discussed.

3.1.1 Interaction Model (IAM) The Interaction Model as stated by Dietz is a „timeless‟ representation of the transactional structure of an organization. By the term timeless is meant that the Interaction Model does not show the order or sequence in which the business transactions in an organization take place. The timeaspect is enclosed in the Process Model, which will be discussed in the next section. The Interaction Model focuses first on the specification of the business transaction types that take place between the organization under examination and its environment, as well within the organization. Secondly, it specifies the actors between the boundaries of the organization with their initiation and execution roles. The IAM is expressed in an Actor Transaction Diagram (ATD) and a Transaction Result Table (TRT). Since it is known that business transactions are the essential building blocks of an organization and by which business take place we first have to identify the transactions for the intermediary. After this, the actor roles have to be identified who are the initiators and executors of these transactions. To identify these transactions the checklists that represent the workflow have to be examined (see Appendix A for an example of a checklist) and interviews with insurance experts are needed of the intermediary. Figure 3.2 exhibits a section of a checklist with red colored (ontological) parts from which the business transaction “T01 product advice” is derived. The parts in the figure are colored according the Performa-Informa-Forma Analysis as described by Dietz. This analysis is based on the distinction axiom that makes a distinction between ontological, infological and datalogical transactions. The identified segments cannot be mapped directly one-to-one to transactions, because some segments relate to the same transaction. Therefore, in this case, the distinction axiom has been applied to identify unique transactions.

44


Checklist: Collective Pension Offer Part: Consultation Report and inventory  Consultation Report is present After the consultation is complete, a report has to be enclosed to the file.  Inventory form is present An inventory document (part of the consultation report) has been made.  Excel document with data of the participants is present The data of the participants of the collective pension is stored in an Excel file Part: Offer traject  The specialist has created an offer in the insurance software With the use of the software of the insurance company, the specialist has made an offer.  The relevant pieces are send to the insurance company to receive an offer The insurance companies are asked for delivering an offer based on the client information. (Action: recall)  The delivered offer has been checked The delivered offer has been checked.  Advice is given with extra notes An advice is written and passed on to the consultant.  Advice has been reviewed (four-eye principle) The advice has been reviewed according to the four-eye principle. (Action: send to the consultant)  Advice has been sent to the client The advice is sent to the client and is guarded with the use of a recall of two weeks. (action: recall of two weeks)  Consultant has visited the client The consultant has to visit the client to give advice on the given offer. For every visit, a recall date is set. (action: recall with date)  Report of the meeting is made Report of the meeting is made.  Business account manager is informed If the relation is business related then the involved account manager has to be informed. (action: send to account manager)  Proposal of the service agreement is delivered The client received a copy of the service agreement.

Figure 3.2 Performa-Informa-Forma analysis To construct the ATD the actor roles that perform a business transaction were identified. For this cause, the Coordination-Actors-Production Analysis is used. This analysis is based on the operation axiom, which identifies several actor roles that are related to the business transactions as stated in the TRT [Dietz, Enterprise Ontology, 2006]. First, the global ATD is created to give a view of the existing external actors who are committed to the intermediary and are needed to do business. It is essential to comprehend the legend of the symbols that are used in the ATD to get a clear and concise understanding on the diagram. In Figure 3.3 the legend of the ATD is exhibited.

45


Figure 3.3 Legend of the ATD and some basic construct The global ATD of the intermediary consists of five composite actor roles: CA00 the Intermediary: fulfilled by the intermediary named Van Lanschot Chabot; CA01 the Potential Client: fulfilled by an individual person that wishes to start an individual policy with an insurance company, with the aid of the intermediary; CA02 the Insurance company: fulfilled by any external insurance company that delivers the policies to the client via the intermediary; CA03 the Client: fulfilled by the person that has an individual policy from the intermediary; this person is the insurant of the policy and optionally the insured of the policy; CA04 the Damage Expert: fulfilled by any external company that is specialized in damage assessment, which can be tangible or intangible. As a result they inform the intermediary that then can make the decision whether to pay out the claim; From the global ATD (see Figure 3.4) can be seen that the intermediary (kernel) is surrounded by four composite actor roles. In addition, the transactions that are executed by the intermediary can clearly be seen (displayed with the executor links). The transactions that are initiated and executed by the other composite actors are also depicted. For example transaction T01 (product advice) is initiated by composite actor Potential Client (CA01). This transaction is executed by the composite actor Intermediary kernel (CA00). In natural language, it can be said that actor CA01 is asking advice to actor CA00 about some insurance product. This is similar for all other transactions. Next, the detailed ATD of the

46


intermediary will be introduced. This ATD gives a more detailed view of the construction and the operation of the intermediary. INTEMEDIARY

CA02

CA01 T01

CA00

product advise

Potential Client

T02 offer delivery

T03 policy delivery

CA03 T04

Insurance z Company

policy termination Intemediary Kernel

T05 complaint handling T06 Client

certificate delivery

T07 policy continuation T09 T08

insurance damage claim

damage claim

CA04 T10

Damage Expert

damage expertise

Figure 3.4 Global ATD of the intermediary

47


The detailed ATD (see Figure 3.5) consists of the elementary actor roles within the intermediary. These actor roles are added to the list of actor list. The elementary actor roles within the kernel of the intermediary are the only internal actors that are added to the detailed ATD because the external actors are not interesting for the core business of the intermediary, these are: A01 Product Advisor: fulfilled by a person employed by the intermediary and that gives advice to a potential client; A05 Complaint Controller: fulfilled by a person employed by the intermediary and that handles complaints from the customers. A08 Damage Claimer: fulfilled by a person employed by the intermediary that claims the damage submitted by the clients.

48


INTERMEDIARY CA01

CA02

A01 T01

Product Advisor

product advise

Potential Client

T02 offer delivery

T03 policy delivery

CA03 T04

Insurance z Company

policy termination A05 T05

Complaint Controller

complaint handling T06 Client

transport certificate delivery T07 policy continuation T09 A08 T08

Damage Claimer


damage claim

CA04 T10

Damage Expert

damage expertise

Figure 3.5 Detailed ATD of the intermediary Table 3.1 depicts the transactions that the intermediary executes for its environment and initiates within its environment. On the left side of the table, the transaction type is described and on the right side, the result of the transaction is depicted. This is the result of the compliance with the customer (in this case the client) and the producer (in this case the intermediary).

49


Table 3.1 TRT of the intermediary

T01 T02 T03 T04 T05 T06

Transaction type product advice offer delivery policy delivery policy termination complaint handling transport certificate delivery

Result type R01 R02 R03 R04 R05

product advice A is delivered policy PO has been offered policy PO has been delivered policy PO has been terminated complaint C has been handled

R06

transport certificate TC has been given

T07

policy continuation

R07

T08

damage claim

R08

T09


R09

T10

damage expertise

R10

continuation of policy P has been done for year Y claim CL has been handled insurance damage claim CL has been handled expertise of the damage of claim CL has been given

The actor who executes the business transaction actually gets the same name of the transaction. For example transaction T05 (complaint handling) is executed by the complaint controller and therefore gets the name A05. This is similar for transaction T08 (damage claim) and T01 (product advice). Designing the detailed ATD has led to discussion with the experts and to lots of confusion about what the core business is of the intermediary. From the diagram, it can easily be concluded that the intermediary only executes three ontological business transactions (T01, T05 and T08). Moreover, it initiates two business transactions that are done by the Damage Controller. These transactions are T09 (insurance damage claim) and T10 (damage expertise). The actor role CA01 (Potential Client) represents the persons who want advice from the intermediary. Obviously, it is the initiator of T01, T02 and T03. Actor role A01 is considered the executor of T01. Only advice is given to the potential clients, which can be individuals or companies. This is the first prominent transaction that is performed by the Intermediary. The actor role CA02 (Insurance Company) is for example the executor of transactions T02 (offer delivery) and T03 (policy delivery). CA01 can request an insurance offer from the Intermediary (CA00). The intermediary then can produce an insurance offer when they are fully authorized by the insurance company. When this is not the case, they have to send the complete request to the insurance company that will create an insurance offer for the potential client based on the supplied information. Then this offer is sent back to the intermediary and they depict of the offer satisfies their conditions. When the offer is accepted by the potential client, they can request an insurance policy from the intermediary. The intermediary can create an insurance policy for the potential client when they have the full authority from the insurance company to create policies. If this is not the case, the complete dossier with the request forms is submitted to the corresponding insurance company and they will perform this task. This pattern is similar for business transactions T04, T06 and T07. This explains why the five links go directly through the kernel of the intermediary to the insurance company. Actor role CA03 (Client) represents the persons who are already clients of the intermediary and can terminate or extend their insurance policies, submit complaints, apply for transport certificates or apply for damage claims. The execution of transaction T05 is the second most important

50


transaction that is performed by the intermediary. Elementary actor role A05 (Complaint Controller) represents the person who manages and handles the complaints which are submitted by the clients. CA03 is also considered the initiator of business transactions T04, T06, T07 and T08. From the detailed ATD can be depicted that composite actor role CA02 is the executor of transactions T04, T06, T07, T09, and that internal actor role A08 is the executor of transaction T08 (damage complaint). This actor represents the person, which claims the damages of the clients related to the intermediary. This is the third important business transaction that is performed by the intermediary. A08 is furthermore considered to be the initiator of transaction T09 (insurance damage claim.) and transaction T10 (damage expertise). Therefore, when a client submits a damage claim to the intermediary, the intermediary tries to find the cause of the damage the size of the damage (cost) and tries to answer the responsibility question. This is conducted by using a third party to examine the damage. Next, they request the insurance company to pay the claim for the damage that has occurred. CA04 represents the persons that inspect the damage and its size. From the description of the detailed ATD and the expert discussion, a conclusion can be made that the intermediary is no more than a servicehatch. This means that they purely gather information of their clients and pass it through to the insurance companies to create insurance policies. Alternatively, they can create it by themselves on behalf of the insurance company. Theoretically, it can be said and by considering DEMO (Organization Theorem and construction models), the intermediary is considered to be a combination of an I-organization and a D-organization. Therefore, they can only be seen as a performer of infological and datalogical transactions.

3.1.2 Interstriction Model (ISM) The interstriction model is necessary because the availability of information forms an important aspect for the continuation of business transactions. For the execution of business transactions at several occasions, information is needed to be accessible. In other words, the execution of many business transactions action cannot be progressed or be successful when the appropriate information is missing. A pizza-man can only promise to deliver a pizza if he knows the stock level of the ingredients for the pizza is satisfied. In our case, the intermediary cannot sell an insurance product if it is not known what the dependencies are. These important bits of information are gathered during so-called informative conversations. The ISM provides a model that identifies and specifies the informative conversations between actors and information banks of the system. The ISM is gathered from the Actor Bank Diagram (ABD) and the Bank Content Table (BCT). Instead of the ABD, we will provide the Organization Construction Diagram (OCD). The OCD gives all the information links that are added to de ATD. The legend for understanding and comprehending the OCD is exhibited in Figure 3.6. The interstriction relations of the intermediary that are represented by the dashed lines in fig 3.7 are mentioned in the BCT. The role of the BCT is to specify the fact banks in which the object classes, the instance of the fact types and the result types from the State Model exist. This model will be elaborated in section 3.3. The BCT is given in Table 3.2.

51


Table 3.2 Part of the Bank Content Table Objects class, fact type, or result type

P-bank

PRODUCT ADVICE product advice A is delivered contact_person CLIENT client_date_of_birth

PB01

PB02

clientage clientadress clientbanknumber POLICY policy PO has been offered policy PO has been delivered policy PO has been terminated continuation of policy P has been done for year Y maximum_offer_period DAMAGE insurance damage claim CL has been handled damage_handling_deadline expertise of the damage of claim CL has been given CLAIM

PB03

PB04

PB05 PB06

claim_period claim_fee ERTIFICATE transport certificate TC has been given COMPLAINT complaint C has been handled YEAR current_date

52

PB07 PB08 CPB03


Figure 3.6 Legend of the Actor Bank Diagram The following table depicts some important composite data banks. In this table, one can also see the contents of the banks and by which actor the information is accessed. Table 3.3 Composite Production Banks Bank nr.

Bank name

Bank contents

CPB01

Insurance portfolio

Insurances

CPB02

CPB03

CPB04

Intermediary data General data

External expert information

Actor nr. CA01

General conditions Regulations

A01

Policies

A01

KVK number of organization and general regulations Cost claims CV‟s

CA00

Engage contracts

CA04

A05

A08 A08

Actor name Potential client Product advisor Complaint Controller Product advisor The intermediary Damage claimer Damage claimer Damage expert

53


In Figure 3.7, the interstriction relations are represented by dashed lines. This figure also shows the Organization Construction Diagram of the intermediary. The executor link and the initiator link are not dashed, because of the readability of the diagram. The reader has to keep in mind that the solid lines cover the dashed lines and so the solid lines can be seen as information links. Equipped with the knowledge stated in the BCT and the given composite production banks, the information links in the OCD can be clarified. All the roles fulfilled by internal actors need access to one or more information items from the external production bank “general data” (CPB03). Drawing the information lines to all the actor roles would make the diagram unreadable and therefore its information link is linked to the boundary. The information stored at the production bank “insurance portfolio” CPB01 is more specific, because it contains information on specific insurances and services that can be given to the clients. In addition, the regulations hold by the production bank “intermediary data” (CPB02) are important for the actor role “Product advisor”. For the actor role “Complaint Controller” it is necessary to know why a policy is terminated (PB03, PB08) and who the clients of the intermediary are (PB02). In addition, the actor role “Damage Claimer” needs information about the damage and information from the expert (CPB04) to decide whether to pay out the damage to the clients. This actor also needs knowledge about the policies and offers to claim the damage for the client (PB02, PB03, PB05, and PB06). The relevance of the ISM for the intermediary is that it can give background information of the existing systems and other ICT applications used by the intermediary. In this way, the overlap of systems and blank spots can be found. With blank spots are meant activities that are not supported by a specific information system, but are essential for the operation. The ISM also provides a specification about which information is needed by which actor role and how this is provided to the relevant actor role. This idea improves the issue of data ownership and makes it transparent for all the actors involved.

54


Insurance portfolio

CPB01

Intermediary data

CPB02

general data

CPB03

INTERMEDIARY CA02 CA01

A01 T01

Product Advisor

product advise T02

Potential Client

offer delivery

T03 policy delivery

Intermediary data

CPB02

CA03 T04

Insurance z Company

policy termination A05 T05

Complaint Control

complaint handling T06 Client

transport certificate delivery T07 policy continuation T09 A08 T08

Damage Claimer


damage claim

CA04 T10 general data

CPB03

Damage Expert

damage expertise

External expert information

CPB04

Figure 3.7 The OCD of the Intermediary

55


3.2 The Process Model (PM) The Interaction Model does not denote the order in which the identified business transactions are executed, although intuitively the order is known. To get the right order of the transactions the Process Model (PM) is developed. It provides the specification of the state space and the transition space of the coordination world. As it is known from the transaction axiom, the C-world consists of the creation of a C-result and every transaction in the C-world exists of the creation of a C-result. So in fact there is a one-toone relationship between this C-result and the causing C-act, these acts are also contained in the PM [Dietz, Enterprise Ontology, 2006]. A collective of a C-result and its causing C-act are called a process step by Dietz. The PM specifies for every process step the information that is needed to perform the step. This is of great importance for this project because in the evaluation phase the findings that were presented by the intermediary will be mapped to the information items from the process steps. This will be further elaborated in chapter 0. The PM of the intermediary is expressed in a Process Structure Diagram (PSD) and an Information Use Table (IUT). Practically the IUT cannot be produced before the State Model (SM) is finished. A part of it is shown in advance in this section. The whole IUT can be found in Appendix C. Figure 3.8 exhibits the legend of the PSD to read the diagram, which will be presented. The symbol of a C-fact type is represented by a disk and a C-act is represented by a small box. The disk is pushed onto the box, because of the one-to-one relationships between the C-result type and the C-act type. The same reasoning holds when pushing the small diamond of a P-fact type onto the small box of the P-act type. All these combined result types represents the process steps in the PSD.

Figure 3.8 Legend of the PSD

56


The PM also provides a full specification of the causal and conditional relationships between the business transactions. Like the previous section, the intermediary case will be used to illustrate the process model of the intermediary. Causal relationships are relationships in which a transaction causes another transaction to start, during or at the completion of transaction. For example, consider the simple activity of buying a pizza from a pizzeria. Here a causal relationship between the delivery of the pizza and the payment of the pizza can be found. Because the successful delivery of the pizza causes the start of the business transaction, in which the delivery of the pizza is paid for. In our case, consider the activity of claiming damage for the client. This activity is shown in the PSD of business process 8 of the intermediary (see Figure 3.9). There exists a causal relationship between the claiming of the damage, the damage expertise carried out by the damage expert and the insurance company that pays out the damage claim. The successful execution of the damage expertise and the authorization by the intermediate to pay out the damage causes the start of the business transaction in which the client is paid. As one can see from the figure, the optional transactions T10 and T09 are enclosed in T08. These transactions are optional because when the intermediary has full authorization on the damage claim, business transaction T09 and T10 don not have to be carried out. The dashed lines in the figure represent the conditional relationships. The completion of one transaction phase forms the condition for the initiation or the completion of another transaction phase. This type of relationship is called a conditional relationship between the business transaction phases. Conditional relationships can only exist within a business process and never between distinct processes. The pizzeria provides us again with an illustrative example. Pizza dough is ordered from a factory and therefore, the delivery of the pizza to their customers can only be performed when the dough is delivered. In our case, the damage claim (T08) is not completed until the damage expertise (T10) has been conducted and the insurance company has agreed upon the payment of the claim (T09). The execution of the transaction T08 has to wait on the acceptance of transaction T09 and T10 before it can be completed.

57


CA03

A08

CA04 damage expertise

damage claim T08 rq

0..1

T08 pm

T10 rq

T10 pm

T10

0..1 T10 ac

T10 st

CA02 0..1

insurance damage claim T09 rq

T09 pm

T09

0..1 T08

T08 ac

T09 ac

T09 st

T08 st

Figure 3.9 PSD of business process 8

The PSD of business process 8 shows that there are two optional transactions (T10 and T09) enclosed in T08. The meaning of this is that if a client wants to claim damage (T08/rq), the responsible actor role A08 has to wait for the validation of the damage expertise, which is performed by the damage expert (this is the damage report created by the damage expert T10/ac). These steps are performed when the intermediary has full authorization for performing this transaction. However, when the intermediary do not have a full authorization it has to wait for the insurance company to complete this transaction (the conformation of the damage and the amount that have to be paid T09/ac).

58


Now the other business process of the intermediary will be discussed and illustrated in a chronically way. The PSD of business process 1 is shown in Figure 3.10. As one can see from the figure, actor role CA01 performs the request of transaction T01. Because of the product advice that has to be given, actor role A01 has to perform two acts: T01/pm and T01/ex. The Potential Client can than perform the T01/ac or not. If the potential client does not accept the product advice, he/she will not become a client of the intermediary. An advice concerning a product can be given to anyone who wants an advice. CA01

A01 product advice

T01 rq

T01 pm

T01

T01 ac

T01 st

Figure 3.10 PSD of business process 1 As soon as CA01 has accepted the advice, transaction T02 has to be started to obtain an offer. T02 is referred as the root of the business process 2 (see Figure 3.11). This business process is a shared process that is actually performed by the insurance company (or by the intermediary with the use of software of the insurance company when they are authorized to do so). CA01 performs T02/rq and T02/ac. The insurance company (CA02) performs two acts: T02/pm and T02/ex. CA01

CA02 offer delivery

T02 rq

T02 pm

T02

T02 ac

T02 st


59


After the offer is created and accepted by CA01, transaction T03 is initiated by CA01. This can be seen in the PSD of business process 3 (see Figure 3.12) of the intermediary. The policy offer of the Potential Client is created by a shared collaboration between the intermediary and the insurance company. Nevertheless, the insurance company still has the authority to create an offer for the requested policy, which is also the case for business process 2. As it is illustrated in the figure below, CA01 performs T03/pm and T03/ex. As soon as CA01 has accepted the policy offer of the insurance company in close collaboration with the intermediary, CA01 becomes a client of the intermediary and fulfills the role of CA03 (Client).

CA01

CA02 policy delivery

T03 rq

T03 pm

T03

T03 ac

T03 st


The PSD of business process 4 is shown in Figure 3.13. With this process actor role, CA03 can terminate a policy by performing a T04/rq. This request is granted by actor role CA02 by performing two acts: T04/pm and T04/ex. The acceptance (T04/ac) of the Client terminates the policy officially. This process is also a shared process, which is conducted in collaboration with the insurance company, because they still have the authority for terminating a policy.

60


CA03

CA02 policy termination

T04 rq

T04 pm

T04

T04 ac

T04 st


Complaints of the clients are processed in the business process 5 of the intermediary. This transaction is initiated by actor role CA03 by requesting (T05/rq). Actor role A05 is an elementary actor role within the intermediary and has the authority to examine these complaints. It therefore performs T05/pm and executes this transaction (T05/ex). After the execution, A05 states (T05/st) the result. The transaction is considered completed, when the result is accepted by CA03.

CA03

A05 complaint handling

T05 rq

T05 pm

T05

T05 ac

T05 st


61


With the use of business process 6 (see Figure 3.14), transport certificates are produced for the clients that desires one. Transport certificates are special certificates that one needs to transport goods or other specific tangible products from one place to another. To obtain such a certificate, actor CA03 has to initiate transaction T06 by performing the T06/rq. This certificate is produced by the insurance company in close collaboration with the intermediary and therefore has to perform two acts: T06/pm and T06/ex. CA03

T06 rq

CA02 transport certificate delivery

T06 pm

T06

T06 ac

T06 st

Figure 3.15 PSD of business process 6 Business process 7 (see Figure 3.16) is produced to provide the possibility for the continuation of policies. By the law, this functionality has to be provided by an insurance company. Therefore, the client, which performs the role of CA03, has to request this annually by performing the T07/rq. The insurance company grants the continuation by performing two acts: T07/pm and T07/ex. CA03

CA02 policy continuation

T07 rq

T07 pm

T07

T07 ac

T07 st


62


The PM can be used for many applications. In the case of the intermediary, it can be very useful as the starting point for requirements engineering regarding information system. The PSD and the IUT contains all the information and leaves no room for unnecessary requirements that is needed for a good discussion. In addition, at the same time it guarantees that nothing will be forgotten. The process that we have identified focuses on the core of the organization. These are the ontological business processes. When one wishes a more detailed view of the organization, which is extremely useful for information system development, one can also identify the datalogical and infological processes. Datalogical processes are processes that describe how and where the data is saved. The writing of reports is also a datalogical process. Infological processes are more reasoning on the data that is stored and computed it so that it can be used to make decisions. This implies that the use of this methodology can improve the design of the dossier systems and that it can be an aid to improve the workflow of the financial services. One can make reasonable that the improvement of the workflow also contribute to the time aspect of the financial services so that they can be produced more rapidly. Table 3.4 exhibits a part of the UIT of the intermediary and contains the information of all business processes. Table 3.4 Part of the IUT of the intermediary Object Class, fact type, or result type PRODUCT P is the product in A clientdateof birth CLIENT clientage clientaddress clientbanknumber POLICY offertimeperiod clientpolicynumber #policiesofclient policytimeperiod policyfee CERTIFICATE TC is part of PO certificatefee DAMAGE #damageofclient claimclient CLAIM The claim of D is CL E is expertise of CL YEAR COMPLAINT

process steps T01/rq T01/rq T01/rq T01/rq T02/rq T03/rq T01/rq T01/rq T01/rq T02/pm T03/rq T04/rq T02/rq T04/rq T08/rq T09 rq T04/rq T04/pm T04/rq T06/rq T06/rq T06/ac T08/rq T09/rq T10/rq T08/rq T08/ac T09/ac T08/rq T09/rq T08/pm T09/pm T10/ac T07/pm T05/rq

63


3.3 The State Model (SM) The State Model (SM) provides a complete and precise specification of all the information that is created and/or used by the organization of the intermediary. In other words, it provides a specification on the state of the production world. The SM consists of object classes, fact types, and result types and as well of the existential laws that hold. The Object Fact Diagram (OFD) is the graphical representation that is issued to represent the SM. The Object Property List (OPL) is an addition to the SM and specifies correct fact types, which can be mathematical functions. From which the range of the fact types is a set of values. The OFD is fully based on the World Ontology Specification Language (WOSL). The graphical notation that is applied to construct the OFD and supports the WOSL is the fact oriented conceptual modeling language ORM (Object Role Modeling). The legend of the OFD is presented partly in Figure 3.17 and Figure 3.18. Generally, two kinds of facts are known which can be derived or original. The derived facts are constructed by the means of logical deduction or by mathematical calculations. The results generated when executing business transactions are the original facts. This means that when a transaction process is successful completed, the predicate of the proposition becomes the fact. This states that all the facts, whether it is an original or a derived fact, are results of the successful execution of the business transaction processes. The facts as described above consist of original information and derived information that are considered in the State Model. Derived information is referred as information that is derived by derivation rules that state how the derived information is determined and what the original facts from the basic material for the derived information.

Figure 3.17 Legend of the OFD (part 1)

64


Figure 3.18 Legend of the OFD (Part 2) In the OFD, the facts are stated as elementary natural language sentences. An elementary sentence is an object that has a property or has a relationship with other objects. These sentences cannot be divided in smaller parts without losing information. In DEMO, an elementary part is considered the smallest existing part. So the elementary natural language is considered as the smallest information unit. All the contents that can be expressed in the OFD and the OPL are fully determined by its Action Model (AM). Therefore, the SM is a truly objective model of an organization and only the relevant information items for the operation of the organization are presented. Table 3.5 shows the part of the OPL of the intermediary. Table 3.5 Part of the OPL of the intermediary property type clientdateof birth clientage(*) clientaddress clientbanknumber offertimeperiod clientpolicynumber #policiesofclient(*) policytimeperiod policyfee #damageofclient(*) claimclient certificatefee

object class CLIENT CLIENT CLIENT CLIENT PRODUCT POLICY POLICY YEAR YEAR DAMAGE CLAIM CERTIFICATE

scale JULIAN DATE NUMBER STRING NUMBER NUMBER NUMBER NUMBER NUMBER EURO NUMBER EURO EURO

65


Three of the properties in the OPL, indicated by asterisks are derived fact types. The derivation rules of these properties are stated as follows: clientage(C) = currentdate - clientdateofbirth(C), converted for calendar #policiesofclient(P) = sum total of all the policies of C #damagedofclient(D) = sum total of all the damages of C Figure 3.19 shows that the intermediary has seven core categories, “CLIENT”, “PRODUCT ADVICE”, “CERTIFICATE”, “POLICY”, “CLAIM”, “DAMAGE” and “COMPLAINT”, of which instances are created by the intermediary. There are two external objects classes: PRODUCT and YEAR. The little diamonds that are connected to the categories represent the result types that are created within these states. From the diagram, one can see that a product advice is unique and that one product can have one or more unique advices. In addition, a product advice is given to a client and a client can get one or more unique advice for a product. F01

F00 PRODUCT

P

PRODUCT ADVICE

A

A

CLIENT

C

product advice is given to client

is part of product advice

R06

R01

TC

A

transport certificate TC has been given

product advice A is delivered R07

R09

R08

R03

PO

YEAR

Y

CL

CL

PO policy PO has been delivered

the continuation of policy PO has been done for year Y

insurance damage claim CL has been handled

F02 CERTIFICATE

TC

PO

F03 POLICY

is part of policy

PO

CLAIM

CL

is the damage off

R04

COMPLAINT

claim CL of has been handled

R10

F04

PO

D

CL

is part of damge

policy PO has been terminated

R05

CL expertise of the damage of claim CL has been given

R02

C

PO

complaint C has been handled

policy PO has been offered

DAMAGE

Figure 3.19 The OFD of the intermediary Therefore, it can be claimed that the SM is a proper model to gather information regarding requirements engineering. The SM only presents the relevant and essential information items for the operation of an organization. This cannot be said for the current practice in requirements engineering. The current way of working leads to the absence of necessary information and to the presence of unnecessary information. Due to the

66


property that SM is structured in chunks around the main objects, it can be used to a business component-based design. This is for great importance in all Rapid Application Development (RAD) methods. It also makes it important for ForMetis, because their information development approach is based on RAD. One can claim that if the system development methods get better, the application will be improved and so the products generated from this application are of a better quality.

67



4.1 Survey and Data preparation

The questions of the survey are derived from raw findings that were given by the previous system users. Each finding of the 325 findings was iteratively checked on its cause and when the same cause occurred, the duplicate finding was eliminated from the list. After the elimination of the duplicates, six categories (implementation, requirements, usability, misunderstandings, wish and irrelevant) according to the type of cause are identified. The result after the findings were categorized was, that requirements and implementation related findings occurs the most. There are followed by the usability, wishes, misunderstanding and irrelevant findings. Before we could start with the creation of the survey, the findings had to be tested according to the F-DEMO methodology. From the result it is concluded that 50,5 percent (theoretical) of the finding can be improved using F-DEMO and 49,5 percent not. In the survey that was held with the expert, for every finding, the question was asked if it could be prevented when DEMO was used. The first 25 questions were done together

with the interviewees and the rest in their own spare time. 4.2 Results of the Survey The improvement of 50,5 percent is theoretically based, without considering the knowledge of experts who have more practical experience in this area. From the survey is stated that the improvement is 41,3 percent, but after mapping, this turns out to be an overall improvement of 33,1 percent when using the F-DEMO methodology. Most of the findings (24,2 %) were requirements findings that could be prevented. The rest were usability findings (1,8 %), wishes (5,4) and misunderstandings (1,8 %). No implementation errors could be prevented. From all the finding that could be prevented using the DEMO methodology, 73 percent were requirements finding, 5 percent usability errors, 16 percent were wishes and 6 percent were the misunderstanding related errors.

4.3 Discussion per type The irrelevant finding could not have been prevented because these findings have nothing to do with the system development trajectory and therefore F-DEMO cannot avoid these types of findings. From the theory, it can be stated that

requirement issues can be solved using the F-DEMO methodology. As was shown earlier the requirements issues can be improved with 24,2 percent. Implementation errors (24,6 %) cannot be solved by applying DEMO. DEMO does not take into account programming mistakes. Usability errors can be solved with the used of DEMO. If one can consider the user interface as a human being, the basic transaction steps can be used to solve user interface problems. Most of these whishes (14,8 percent) were requirements that were not derived from the workshops. DEMO thus can retrieve and solved wishes in some degree. Misunderstandings are made when there is no mutual understanding within the client organization about a concept or functionality. DEMO has proved to remove ambiguity from one mind.

68

DEMO introduced to financial services Chapter 4. Research Survey S.S.R.W. Algoe BSc. V.R.K. Boedhram BSc.

Chapter 4.

Research Survey

Before we can compare the methodology of ForMetis with the new developed methodology as described in Chapter 3, we first have to determine what the impact on the findings of the information system would have been that is developed using the F-DEMO way after deploying it. Therefore, we did an analysis described in the previous chapter. However, arriving at the implementation phase, after completing the analysis and design phases it was to be recognized that because of the available cost and time constraints realizing a whole software project with the F-DEMO way was not doable beyond the available recourses. So the implementation phase was not realized, however to do an evaluation on this phase we could suggest that the methods used in the implementation phase were the same as in the previous system considering a different analysis and design phase. When comparing the development of information systems, the actual implementation phase is critical. Therefore, because of the previous system findings were given by users. Taking these findings, we could test if these findings would still arise after delivering a system based on the new FDEMO methodology. This test was shaped to a survey and was given to interviewees to determine whether a system developed with F-DEMO was able to prevent the given finding (a copy of the survey can be found in Appendix B).

4.1 Survey and Data preparation Several steps had to be done before the research survey could be created and are in detail described in this section. At first, the raw data (the findings of the previous information system) had to be gathered. This was delivered by the experts of ForMetis and was a list of findings that was given by users of the previous produced information system. Now the data is known the duplicates had to be eliminated by looping through the list. This was done with the help of the ForMetis experts who have a clear understanding of the scope in which the findings occurred. Then also with the help of these experts, categories are defined by which the data can be categorized. Next, the theoretical boundaries of the improvement when using the new F-DEMO methodology had to be defined. Then the construction of the survey statement was started and was applied to the findings that resulted in the survey questions. At last, the survey could be filled in. These steps are in more detail described in the following sections as given in Figure 4.1. [4.1.1]

[4.1.2]

[4.1.3]

[4.1.4]

[4.1.5]

[4.1.6]

Elimination of Duplicates

Identification of the Categories

Categorizing the findings

Identification of the theoritical limit

Construction of survey statement

Filling out Survey

Figure 4.1 Approach of the creation of the survey

69


4.1.1 Elimination of duplicates The questions of the survey are derived from raw findings that were given by the previous system users. The list of findings was processed by ForMetis. These raw findings were obviously not unique because of the existing duplicates in the list. Therefore, a filtering had to be done to take out the duplicate remarks. Each finding was iteratively checked on its cause and when the same cause occurred, the duplicate finding was eliminated from the list. After the filtering a list of 325 unique findings were left.

4.1.2 Identification of the categories After the elimination of the duplicates, six categories according to the type of cause could be identified. It was done with the help of the experts from ForMetis that have a more clear view on the context in which the finding occurred. The categories are described below and in Table 4.1 examples are given of each category. The first category consists of usability errors, which is when the finding states something that involves issues regarding the user interface. The usability holds essential information about the user interface of the system, regarding the request, promise, state and accept steps of a transaction. If the cancelation patterns of the universal transaction is taken into account the reject, decline, quit and stop steps have to be considered. This emphasizes the construction of the user interface. Then there exists a category regarding implementation errors, these are caused by the insufficient testing of the programmer that lets the programming errors to be unnoticed (for example a wrong policyid is shown in a dossier). The third category consists of misunderstandings between the users of the systems when they have no mutually understanding on what they meant and thus have no shared conceptualizations. Another category refers to the lack of well-formed requirements when no concrete (C4E: coherent, comprehensive, consistent, concise, and essential) requirements are created. In addition, missing functionalities are also considered requirements errors. Next, there exists a category named wish, which contains new desired functionalities. These were mostly forgotten when gathering the new requirements and were brought forward later on during the project. Besides these types, a special type called irrelevant was introduced that refers to findings that did not have anything to do with the system.

70


Table 4.1 Different categories according to the type of finding Type Usability

Finding Unfortunately, the window of the work list is not adjustable, which causes the width of the columns to be very small. Every time the columns have to be adjusted by the use of the mouse.

# 257

(This usability issue was not taken into account when building the system, because it was not asked by the client.) implementation misunderstanding

The marked checkboxes are not memorized in the checklists. It would be nice to have an extra blank field in the screen of the user, which contains the work list of his apartment. This would mean that you do not have to go back to the main screen.

1 312

(It is not necessary to go back to the main screen, because at all times there is a button that links to the work list of the user.) requirement

When the checklist is completed, it is still possible to modify it.

12

(In the specification, it was not stated that the checklists might not be modified.) wish

In the checklists, there is no opportunity to enter recurring actions.

57

(This was never brought forward by the client.) irrelevant

System is very slow, so you can see the screen building up.

261

(The final system was tested in a test-environment before deploying it to runtime environment. The test environment does not have the same capacity as in runtime.)

4.1.3 Categorizing the findings into the categories The findings were categorized according to their cause. This was done iteratively by looping through the list and was validated by the ForMetis experts. In Table 4.2 the number of findings are given per category. It can be seen from the table that requirements and implementation related findings occur the most. There are followed by the usability, wishes, misunderstanding and irrelevant findings. Table 4.2 Number of findings by category

Type of finding 1. Irrelevant 2. Requirements 3. Implementation 4. Usability 5. Wish 6. Misunderstanding Total

Number of findings 7 109 80 65 48 16 325

Total 2,2% 33,5% 24,6% 20% 14,8% 4,9% 100%

71


Figure 4.2 gives an overview of all the occurrences per type expressed in percentages. Per type of finding the number of occurrences are summed which gives a clear overview on what types occur and how they relate with each other by giving the percentages. So again, we see that 33,5 percent of all occurrences turn out to be a requirement related finding.

4,9% 2,2% Irrelevant 14,8%

33,5%

20,0%

Requirements Implementation

24,6%

Usability Wish Misunderstanding

Figure 4.2 Occurrences by type given in percentages

4.1.4 Identify the findings that can be eliminated with F-DEMO Before we could start with the creation of the survey, the findings have to be tested according to the F-DEMO methodology. This means that it is checked if the finding would still occur after the new methodology was used for the creation of the information system. This can be seen as the theoretical boundary of the improvement. The minimum improvement that can occur is equal to 0 percent, this means that none of the findings could be eliminated with the use of FDEMO. To determine the maximum improvement it has to be checked how many of the findings can be eliminated with the use of the models of the FDEMO methodology. This has to be done by examining the models and checking whether the cause of each finding is handled in one of the models. More precisely a mapping has to be made from the cause of the findings to the specific transactions or processes of these transactions. If this mapping for the finding is possible, then theoretically the finding will be prevented. Thus the elimination of a finding, leads to a certain improvement expressed in a percentage. To do the mapping a table was constructed with the specific information regarding to the finding. The complete mapping can be found in Appendix C where the finding is mapped to the transaction of the DEMO aspect models by giving information items (object class, fact type or result type) and their production banks. The result of the mapping is displayed in Table 4.3.

72


Table 4.3 Type of occurrences after mapping Type of finding

1. 2. 3. 4. 5. 6.

Irrelevant Requirements Implementation Usability Wish Misunderstanding Total

Number of occurrences not tot map map 7 0 7 109 105 4 80 0 80 65 15 50 48 33 15 16 11 5 325 164 161

Percentage tot 2,2% 33,5% 24,6% 20% 14,8% 4,9% 100%

map 0,0% 96,3% 0,0% 23,1% 68,8% 68,8% 50,5%

not map 100,0% 3,7% 100,0% 76,9% 31,2% 31,2% 49,5%

Overall percentage not map. map 0,0% 2,2% 32,3% 1,2% 0,0% 24,6% 4,6% 15,4% 10,2% 4,6% 3,4% 1,5% 50,5% 49,5%

The table is divided into a number of occurrences and percentages. To better explain the table, let us look at the requirements findings. Of all the 325 findings, 109 findings are related to requirements errors. From these findings, 105 findings are mappable and 4 findings are not. In other words, 105 requirement errors can be prevented with the use of the new methodology. So 105/109=96,3 percent of all the requirement related findings are preventable and 4/109=3,7 percent is not. For the overall improvement, this means that 105/325=32,3 percent is preventable by dealing with the requirements and 4/325=1,2 percent is not. By adding all these improvements per type a maximum improvement of 50,5 percent can be obtained. This leaves out a percentage of 49,5 percent that cannot be improved. The number of findings per type that could be prevented according to the mapping is displayed in Figure 4.3 and the number of findings, which could not have been prevented. In the figure, the upper numbers represents the amount that is not detectable and the lower numbers the amount that is detectable. The number of detectable findings is also displayed with a full color occurring to the colors given in Table 4.3 and the light colored bars represents the associated type of finding. Note that in theory, F-DEMO is not able to detect any form of implementation error and this is clearly illustrated in the figure. It means that DEMO cannot solve implementation errors, which are made by the programmer.

73


120

4

occurence

100 80 60

105 80

40 20 0

7 0

0

50 15

15 33

5 11

Figure 4.3 Occurrences detected with F-DEMO per type.

The numbers given in Figure 4.3 are translated into a percentage to give a better indication of the percentage per type of finding that can be prevented, this is displayed in Figure 4.4. So given this fact 0 percent of the implementation errors could be prevented with the use of F-DEMO. It is also clear now that 0 percent of the findings, which turned out to be not an error could be prevented. In contrary, we could see that 96,3 percent of the requirement findings could be prevented.

100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0%

Figure 4.4 Relative findings detected with F-DEMO per type

74


Let us now consider only the filtered findings per type as shown in Figure 4.5. Then we could see that of all prevented findings 64 percent was related to a requirement error. We also see that 0 percent of the implementation type is prevented, which is again a confirmation of the theory.

6,7% 0,0% Irrelevant 20,1%

Requirements

9,1%

64,0%

Implementation Usability Wish

0,0%

Misunderstanding

Figure 4.5 Distribution of the filtered types

If we look at all the findings that were not filtered out, then we have something like Figure 4.6. Here we see that 49,7 percent is an implementation error, 31,1 percent a usability error, 9 percent a wish, 3,1 percent a misunderstanding, 4,3 percent is not even a problem and 2,5 percent still is a requirements error.

9,3%

3,1% 4,3% 2,5% Irrelevant Requirements

31,1%

49,7%

Implementation Usability Wish Misunderstanding

Figure 4.6 Distribution of the findings that could not be filtered

As we saw in the previous figures, of the 325 findings a number of 164 findings can be prevented with the use of F-DEMO methodology. It now implies that in theory an improvement can be made of 50 percent. Nevertheless, it has to be mentioned that this is strictly a theory, this is because of the fact that was stated that a finding could be fully prevented or not. However, this is a too much black and white picture. So this asks

75


for a better approach and at this moment, the theory has to be tested with the use of the survey to get a more practical result. This means that in theory a maximum improvement of 50,5 percent can be obtained when all the mappable findings are improvable. In practice, this is often not the case, because a percentage of 100 percent on the improvement for every mappable finding only exists in Utopia and thus is not realistic. To find a practical and more realistic improvement rate a survey was made that has to be filled out by several experts from the financial and software industry.

4.1.5 Statement made in the survey Before the survey could be created, a statement was made that is questioned in the survey, namely: “The given finding by the user would have been

prevented with the use of a DEMO based methodology.” Now the questioned statement of the survey is known the possible scores had to be established. The score that could be given on the statement are closed and only one answer could be marked by the interviewee per finding. A score has to be given from 1 to 5, which means: 1 completely disagree, 2 disagree, 3 neutral, 4 agree and 5 completely agree. In other words, this means that there is a range between the extreme cases that the finding can completely or in the worst case not be solved when using the F-DEMO methodology. Therefore, from each finding we wanted to know if the used of F-DEMO could have prevented a finding. The numbers 1 to 5 represents the following values 0, 0.25, 0.5, 0.75 and 1. A score of 1 means that the finding with the use of F-DEMO cannot be prevented. In addition, a score of 5 means that for 100 percent certainty can be said that the finding will be prevented. If for example, every interviewee gives a value of 5 on every question it means that all the findings will be prevented when applying F-DEMO. Then a maximum improvement of 100 percent exists in practice. Per question there exists a maximum improvement of 100 percent/325 = 0.308 percent (325 is the number of questions asked). So the actual improvement per question can be calculated when taking the average of the given values of the interviewees per question and multiply this with the maximum improvement (0.308 percent). At last, all the improvements per question are added up to come to the total improvement. When applying the calculation described above, there can be a situation when the interviewee gives a possible improvement on some finding that in theory may not occur. Consider a finding that relates to an error that is caused due to bad implementation by the programmer. When one of the interviewees accidently gives an improvement on this finding, this implies that the new software methodology prevents this finding from occurring. However, the fact is that F-DEMO cannot prevent any form of implementation errors. To avoid this type of subjectivity this has to be verificated back to the DEMO model, this is also done with the table from Appendix C.

76


4.1.6 Filling out the survey The survey has to be filled out by interviewees that are familiar with the context in which the findings were given as result of the previous ForMetis methodology. In addition, a clear understanding has to be on what impact the new software development methodology (F-DEMO) has and in which areas improvements arise. Because of the lack of DEMO knowledge within ForMetis, extra lectures regarding this subject were given to these experts. The first 25 questions were done together with the interviewees and the other 300 had to be answered in their own spare time, at home or at the office or wherever they prefer. The fact that the enquirer goes to the interviewee requires much time and traveling effort. Long enquiries costs extra time, but by doing it this way, the time needed to complete the survey is less. The time needed for completing the survey could run up to at least 6 hours.

4.2 Results of the Survey The theoretical findings from the previous section are examined in an expert survey. Now we can get a better insight of the precise contribution of F-DEMO to each finding. The in the previous section discussed improvement of 50,5 percent is theoretically based, without considering the knowledge of experts who have more practical experience in this area. To make the following section clearer and better understandable the words mappable, not mappable and validation the following definition is given: Mappable: The finding is considered mappable if the cause of the finding is handled in one of the F-DEMO aspect models. Specifically the information table, see Specific Information Table in Appendix C). Not mappable: A finding that is not mappable. Validation: This refers to the survey that is filled out by the experts by giving a weight (0, 25, 50, 75 and 100 percent improvement per question). Verification: It is rechecked if the finding is mappable. Each finding prevented with F-DEMO can get a certain improvement rate that is expressed as a percentage. In the way as described in section 4.1.5 one may come to an improvement per finding. For each type of finding, the improvements are added to total improvement percentage. These percentages can be depicted in the left column of Table 4.4. These are the results of the survey without verification on whether the finding is mappable or not. Logically said when taking mapping into account one comes to a lower improvement, this is because the interviewee can give an improvement on a finding that is in theory not improvable. For example when an interviewee gives a score of 4 (this is 75 percent) to a finding that is not mappable, this score has to be neclected and the actual improvement is 0 percent. The improvement per mappable finding is depicted in the right column of Table 4.4. In Appendix D each finding can be found and whether it is mappable (0 is not mappable and 1 is mappable) with the average improvement per finding before and after mapping.

77


Table 4.4 Results of the survey survey

Irrelevant Requirements error Implementation error Usability error Wish Misunderstanding Total

without verification 0,0% 24,9% 0,3% 6,5% 7,2% 2,5% 41,3%

with verification 0,0% 24,2% 0,0% 1,8% 5,4% 1,8% 33,1%

In the table is depicted that the improvement regarding the implementation errors is 0,3 percent, but as we mentioned before in theory this cannot be realized. After mapping, it indeed turns out that these types of findings are not prevented, so this is according to the theory. From the survey is stated that the improvement is 41,3 percent, but after mapping this turns out to be a solid improvement of 33,1 percent. Now that we have the overall improvement and its distribution to the different types of findings, we can calculate this percentage back to an estimated number of prevented findings per type. This is done to give a better understanding on the type of findings that are prevented with FDEMO. Then a better view on the type and complexity is given on the not prevented findings that remain. Table 4.5 gives the number of findings that are prevented and not prevented with F-DEMO. The total number of findings and the total number of findings per type from Table 4.3 are used in the following calculation. The number of prevented findings per type is calculated by multiplying the overall improvement with the total findings (325). The number of prevented requirement findings are 325 x 24,2% =79 findings. The number of findings that are not prevented per type, is calculated by substracting the total findings per type given in Table 4.2 with the prevented findings, this again for the requirements is 109-79=30 findings. Table 4.5 Number of findings given the overall improvement

Irrelevant Requirements error Implementation error Usability error Wish Misunderstanding Total

78

overall improvement 0,0% 24,2% 0,0% 1,8% 5,4% 1,8% 33,1%

number of prevented findings 0 79 0 6 17 6 108

number of not prevented findings 7 30 80 59 31 10 217


Figure 4.7 displays the number of prevented findings per type. In the figure, the upper numbers represents the amount that is not detectable and the lower numbers the amount that is detectable. The number of detectable findings is again displayed with a full colored bar according to the colors given in Table 4.3 and the light colored bars represents the not preventable findings according to the color. Given the figure, a comparison with the theory can be made with Figure 4.3. From the figures, one can see that all the prevented findings are in practice lower than in theory. To better compare the theory with the practice the improvements in percentages per type from Figure 4.8 and Figure 4.4 have to be considered.

120 100

30

occurence

80 60 79

40

80

59

31

20 0

7 0

0

6

17

10 6

Figure 4.7 Occurrences detected with F-DEMO per type (in practice)

79


occurence

0%

72,5%

0%

9,2%

35,4%

37,5%

100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0%

Figure 4.8 Relative findings detected with F-DEMO per type (in practice) Now the improvement per type of finding is known, something has to be said about the total improvement and the relation to each improvable types of finding. Figure 4.9 gives an overview of all the findings that are filtered and how they are distributed over the different types of errors. This figure also illustrates that from all the errors that can be solved 73 percent of them are requirements errors, 5 percent are usability errors, 16 percent are wishes and 6 percent are misunderstandings. If we take into account the requirements and the wishes, we could see that over all the prevented errors these two types are almost 90 percent. This emphasizes that requirements engineering is an important matter when designing information systems and that DEMO is excellent in retrieving requirements. This improves the quality of the financial products that have to be delivered and it means that most of the complexity that comes with these types of errors is drastically lowered.

0% 16%

Irrelevant

6%

Requirements

5% 0%

Implementation 73%


Figure 4.9 Distribution of the filtered types (in practice)

80


If we take a final look at the remaining findings that cannot be prevented with the F-DEMO methodology, one sees that still 14 percent of all findings are related to requirements (see Figure 4.10). This is more than was forecast by the theory. A simple explanation on this is that the intervieuwees did not give an improvement of 100 percent per finding, like in theory when a finding is preventable (100%) or not (0%). In practice this is logical, because not always all requirement related findings can be prevented with the use of F-DEMO and there always exists a situation that a client will come with new essential requirements for the system. This is because given the time constraints for applying F-DEMO in practice is limited and people intend to forget requirements, which are not directly covered in the time given. When one have enough time for applying FDEMO it is guaranteed in theory that all the requirements are retrieved before implementation of the information system.

5% 3% 14% 27%

Irrelevant

14%

Requirements Implementation 37%


Figure 4.10 Distribution of not filtered findings (in practice)

4.3 Discussion per type The first of the six categories (irrelevant, requirements, implementation, usability, wish and misunderstanding), are the findings which were irrelevant and give a quality improvement of 0 percent. These findings have nothing to do with the system development trajectory and therefore FDEMO cannot avoid these types of findings. Then there are the requirements findings. These are the biggest part of all that were examined (nearly 33,5 percent). From the theory, it can be stated that those requirement issues can be solved using the F-DEMO methodology. As was shown earlier the requirements issues can be improved with 24,2 percent. The third category consists of implementation errors that in theory cannot be solved by applying DEMO. However, the complexity of these errors is low and can be solved faster than requirements related findings. This category is the second large group with 24,6 percent and leads to an improvement rate of 0 percent with the use of DEMO. The fourth group contains the usability errors (20 percent of the findings). From the outcome of the survey can be said that an improvement of 1,8 percent can be gained using DEMO. DEMO can describe the human computer dialog of the user interface if one can consider the user interface as a human being. These communication steps are similar to the basic

81


process and cancelation steps described by Dietz. From this result, it can be concluded that the placement of buttons, size of textboxes, sorting of lists, and margins of columns cannot be improved using DEMO. The fifth group describes the whishes that the users brought forward after the production of the system started. Most of these whishes (14,8 percent) were requirements that were not derived from the workshops. Because the whishes have not been put in the same category as the requirements, the survey can help finding out whether these wishes would be derived at the start of the project and not during the project. With the use of DEMO 1,8 percent improvement is gained on this category. So it can be concluded that most of the whishes cannot be improved using DEMO. The last group is categorized as the misunderstandings. Misunderstandings are made when there is no mutual understanding within the client organization about a concept or functionality. 14,8 percent of all the findings were misunderstandings, the F-DEMO methodology improves nearly 30 percent of the misunderstandings and improves the whole with 5,5 percent. It can be concluded that a big part of these types of findings can be improved with the use of the DEMO methodology. This again confirms that lot of ambiguity can be filtered with the use of this methodology.

82


83



5.1 ForMetis vs. F-DEMO methodology The ForMetis Methodology consists of five phases. The planning, analysis, design, implementation and system phase. According to these five steps, they design information systems for their clients. F-DEMO also has these five phases but differs from the ForMetis Methodology. Step 1 (Ad-hoc Experience planning) and step 4 (DTAP implementation method) are equal for both methodologies. A quick view on step 5.System (prototype) and aftercare states that this step in both methodologies is considered similar. However, when one inspects step 5 thoroughly it can be concluded that step 5 is the result phase, derived from the earlier steps.

5.2 Planning Phase This step sets out the project planning for the design of the information system. For the intermediary this was conducted to design the E-dossier system. This step is similar for both approaches.

5.3 Analysis Phase In the analysis phase ForMetis uses the so-called AH-game. The AH-game is described to the client to show them how processes are constructed and performed in a quick and easy way. In the F-DEMO approach, the analysis is done by an intensive usage of the DEMO.

5.4 Design Phase For ForMetis the implementation of the system and the informal specifications are the specification of the system. F-DEMO uses the Construction Model, Process Model and the State model in this phase to retrieve the relevant requirements.

5.5 Implementation Phase The DTAP implementation method is similar in both methodologies.

5.6 System In step 5 of the ForMetis methodology, the findings of the users are analyzed and then the cycle of analysis, design and implementation phases are started over. However, in step 5 of the F-DEMO methodology, only the implementation phase is started over again after the findings of the users are analyzed.

5.7 Benefits and drawbacks The F-DEMO methodology has more benefits than the ForMetis methodology. It decreases the amount of findings. Less requirement related errors, user interface design is better, errors in the system can be solved quicker (mostly implementation errors), low complexity level, less maintenance time and cost.

84

DEMO introduced to financial services Chapter 5. Comparison of the approaches S.S.R.W. Algoe BSc. V.R.K. Boedhram BSc.

Chapter 5.

Comparison of the approaches

In this chapter, the ForMetis methodology for designing information systems will be compared with the F-DEMO methodology, which consists of the ForMetis methodology extended with the DEMO methodology. The ForMetis methodology is developed in-house by ForMetis. The F-DEMO methodology is characterized by the application of DEMO, however several phases overlap. The overlapping of the related phases and the several differences will be pointed out. Furthermore, the benefits and drawbacks of the methodology will be described, illustrated using the case study.

5.1 ForMetis vs. F-DEMO methodology ForMetis has used the five steps that are depicted in Figure 5.1, interactively with the intermediary to design the information system. The purpose of the system was to create an E-dossier system. One of the functionalities was the possibility to organize the digital dossiers of the client. Example of dossiers are damage dossiers, polis dossiers etc. The system had to give the managers information about the work that was finished or not. This could help them to manage their units better. The system had to support the workflow of the users and help them to complete their work. The workflow structure is programmed as a checklist that monitors the followed process execution to deliver the relevant service (insurance, policy). Planning 1. Ad-hoc experience planning

evaluation Analysis 2. Workshop (AH-way) Design 3. Informal Specifications

System 5.System (prototype) and aftercare

Implementation 4. DTAP implementation

Figure 5.1 Phases in ForMetis methodology (in detail) In the past, the ForMetis methodology has led to many successful projects and was gratefully accepted by their clients. Because the strong interactivity, knowledge mobility and creativity of their approach the acceptation by the client is very high. The only drawback on this is that the implementation is the specification of the information system, so the

85


client can ask for more functionality even when this is not discussed before implementation. On behalf of the ad-hoc approach of ForMetis and the improvement when using formal models, a new methodology has to be made to do a more secure analysis and design phase. That is why the F-DEMO methodology is constructed (previewed in Section 2.2) and has to be applied before starting with the implementation phase. Figure 5.2 shows the steps that are determined when using the F-DEMO methodology to design an information system. Note that the step 1 (Ad-hoc Experience planning) and step 4 (DTAP implementation method) are equal for both methodologies. A quick view on step 5.System (prototype) and aftercare states that this step in both methodologies is considered similar. However, when one inspects step 5 thoroughly it can be concluded that step 5 is the result phase derived from the earlier steps. Therefore, it can be stated that this step is different for every project trajectory and thus is highly dependent on the execution of the earlier phases.

Planning 1. Ad-hoc experience planning

Analysis 2. Workshop (DEMO-way) Design 3.DEMO models (IAM, PM, SM)

Implementation 4. DTAP implementation method

System 5.System (prototype)

evaluation

Figure 5.2 Phases in F-DEMO (in detail) Figure 5.1 shows that after several workshops and some written informal specification the implementation of the system starts directly, without a methodically or comprehensive design phase. After the implementation phase has successfully completed, the system phase follows which is the result of the implementation phase. This is different in the F-DEMO methodology. Here we have taken the implementation phase as a separated phase. This is done to get a broader and more cleaner analysis and designing phase (modeling) with fundamental correct models from which coherent, concrete, comprehensive, concise, and essential requirements can be gathered before the implementation phase can start. F-DEMO is characterized by its intensive DEMO usage. In every software book and system design study, is mentioned that the analysis and design phase are the most important phases of the development project. Time and effort invested here pay off well in terms of reduced findings/bugs later when the system is analyzed.

5.2 Planning Phase In the planning phase, Step 1 (Ad-hoc experience planning) is similar for both methodologies. This step sets out the project planning for the design of the information system. For the intermediary this was conducted to design the E-dossier system. The need for this step is to estimate the duration time and the recourses of the project and its complexity. This step also describes the agreements that are made with the organization into consideration.

86


5.3 Analysis Phase The workshop AH-way (step 2) of ForMetis is based on so-called AH-game (Albert Hein is a Dutch supermarket). In this way, the processes of the organization are constructed. The AH-game is described to the client to show them how processes are constructed and performed in a quick and easy way. In the AH-game, a person is send with a list (input) to the supermarket to get groceries. This has to be done in an efficient way. If the person knows on which shelf‟s (systems), the groceries are he/she will be very quickly done. The shopping chart helps to make it easy (process) and the result (output) is the receipt of the groceries. Figure 5.3 exhibits that for example to gather policy input (client information, etc.) this can be found in various systems. After the process is completed, a policy as a result is the output of the system. To optimize the process, Key Process Indicators (KPI) of the intermediary was determined. This is done on basis of punctuality, accuracy, efficiency and productivity. An example of a KPI is the time to construct a policy. Let consider this 2 weeks. Thus, a KPI is determined to control if the process goes according the way it should. This means that all the policies should be made in two weeks time. In this way the checklists (see Appendix A) for performing the business process to produce financial services like policies, insurances and transport certificates are constructed. These checklists contain the process which has to be followed to complete (terminate, prolonged etc.) the policies of the clients regarding the intermediary.

Systems from which information is needed

Input

Process Steps

Output

Systems where information is stored

Figure 5.3 AH-way to elaborate business processes

Step 2 (Workshop DEMO way) differs from step 2 of the ForMetis methodology because of its intensive usage of the DEMO aspect models. This step uses the DEMO methodology and its way of thinking to gather the essential requirements of the system. In this workshop first the mission and business strategy of the organization in our case of the intermediary is extracted. Secondly, the elementary actor roles and their relationships are determined by a thoroughly actor-transaction analysis. This is conducted for every department. Thirdly, knowledge of their business processes and information that is needed to execute these business processes successfully is

87


gathered. At last, some questions about the user interface of the system into consideration are asked.

5.4 Design Phase The difference between step 3 of the ForMetis methodology and the FDEMO methodology is that: ForMetis makes a report of the findings in an informal way to retrieve knowledge about the business of the client. This way has several drawbacks. The important problems that arise are that a lot of ambiguity exists. Secondly, information systems are complex and many unnecessary details are produced. At last, in the mind of the client different concepts of the system exist. After the knowledge retrieval has been conducted with the DEMO way, the development of the DEMO models starts. These models describe all essential knowledge that is necessary for the development of the information system. When everyone who has attended the workshops sees and understands the models, everyone has a clear view of the business of the organization (mission and strategy). First the CM in step 3 (that consists of IAM and ISM) of the organization is constructed, which addresses the construction of organization and the responsibilities of the actor roles. The PM is constructed with all the business processes. Every step in the process is modeled precisely and specified which information items are needed. The SM states all the import object classes, the relations between them and the existential laws. From these models, the requirements regarding the system can be extracted, such as domain requirements and system requirements. User interface requirements can also be presented. If one considers the communication with the system as communicating with a person and considers the basic process steps (request, promise, state and accept) as communication patterns between him/her and the system, one can say that on basis of these findings the requirements for the user interface can be gathered. To make this complete the cancellation steps has to be taken into account, because sometime a request, promise, state or accept can be cancelled or rejected by a person and so by a computer system. The importance of this approach is that it describes which information has to be on the screen (construction of the user interface), but not how it will be presented (format or style). At last, the models have to be validated before they can be used in the further development.

5.4.1 Motivation using the Construction Model The Construction model is the most concise model of the organization and identifies the transaction types and the associated actor roles (IAM). It provides the organization with the essential business transaction and the actors that are responsible for these transactions. Thus, it specifies the construction of an organization. It also contains the locations of different kinds of information that are necessary for an organization (ISM). This is from great importance for the implementation of the information systems so that ForMetis and the organization (intermediary) can get an insight of the infrastructured architecture on which the information systems of the organization runs. The combination of the IAM and the ISM provide domain requirements, which are necessary for the implemenion phase.

88


5.4.2 Motivation to use the Process Model ForMetis had to implement the business processes of the intermediary into the dossier system (information system) to deal with the creation of policies and insurances for their clients. To implement business processes into an information system, all these processes have to be modeled beforehand. Using an ad-hoc approach like the AH-workshop leads to too many details; this is not needed to design a compact and complete process and gives a lot of overhead. Since the Process Model has the ability of showing the interdependencies between transactions and business processes, this is precisely the type of model to use for a getting accurate KPI‟s to guard the business processes (on the basis of the four criteria‟s: punctuality, accuracy, efficiency and productivity). The Process Model can also provide cancelation patterns, which are able to describe process exceptions. These exceptions can be used to retrieve process requirements, user interface requirements.

5.4.3 Motivation to use the State Model without Action Model The State Model was made by writing down the transaction result types as object classes. This is the link between the Interaction Model and the State Model. After this, a part of the object classes is linked to the others by drawing relationships between these classes. At times, other object classes must be added to make this model comprehensive. Missing information in the State Model is not desirable, but constructing the action model for the intermediary costs a lot of time, which negatively influences the development time criteria of the project. A simple Action Model was constructed with the information obtained from conversations with the client. Because of the simplicity of the Action model, it was not necessary to put it on paper, but enough information was obtained to construct the State Model. The importance of the State Model that it contained the important object classes and existential laws from which data model can be constructed for the implementation phase. It is also able to show which actor role made which object class and from which this object class is. This means that the model is able to determine which actor role is responsible for the consistence of these object classes. The Action Model would be a great addition for the implementation phase, because in the model scripts (action rules) are designed, which can gives the business rules of an organization. This is of great importance for the programmer who uses these rules in the implementation of the application.

5.5 Implementation Phase Step 4 DTAP implementation method is similar in both methodologies. The DTAP method as described in section 2.1.4 is used in both methodologies to implement the information system. The validation of the system, in other words the acceptance of the system, means that the system has to do what the client expects from it. This is similar within both softwaredeveloping methodologies. The system is implemented with a componentbased software developing approach. An application is made by linking readymade components together [Gamma et al., 1994]. For example, existing buttons, lists and dossier components are used by putting them together to form the needed part of the application.

89


5.6 System As mentioned earlier step 5 is derived from the results of previous steps. Step 5 of the ForMetis approach differs from step 5 of the F-DEMO approach. In step 5 of the ForMetis methodology, after the system is implemented and produced, the users evaluate the system. Then the arrow indicates that the analysis, design and implementation phases are started over to comply with the demands of the users. This is an iterative process and cost more time and money to complete the project. However, in step 5 of the F-DEMO methodology the arrow illustrates that only the implementation phase is started over again after the users have evaluated the system. This indicates that only the implementation has to be redone and the information system copes with the requirements. This shows the strength of DEMO, because clearly all the requirements are identified in a correct way and less requirement errors and usability error are made. Now only the implementation errors have to be considered, which mostly are from a low complexity. In addition, if new requirements arise quoted by the users the software company can consider to implement a version upgrade for the right costs.

5.7 Benefits and drawbacks The benefit and drawbacks of the ForMetis methodology are presented per developing step in Table 5.1. Step 1, step 4 and step 5 have been compared theoretically because doing over the whole implementation phase and the design of the new dossier system would be unnecessary and not beneficial, considering the cost and time of this project. Table 5.1 Benefits and drawbacks of the ForMetis methodology Developing Step

1.Ad-hoc experience planning

2.Workshop AH-way

3.Informal Specifications 4.DTAP implementation method 5.System(prototype) and aftercare

90

Benefits - experience in relative small projects - specific domain knowledge - tailor made - intuitive good - provides input and output of processes - identifies KPI for process optimization - specification of info/data systems - highly interactive - mobilization of knowledge - creativity

Drawbacks

- quickly and easy to understand

- lots of ambiguity - different concepts - no formal requirements - testing phase is still improvable, the use of automated testing could improve the test time. - exhausting aftercare (334 findings)

- independent development areas - the users are not interrupted - fast and interactive way production

- no thoroughly analysis - little knowledge about involved risks - no support of large projects - implementation is the specification

- only processes are considered - missing actor analysis - no mission and strategy specification


As mentioned earlier step 1 and step 4 of both developing methodologies are the same and therefore will not be described in the following table, which gives the benefits and drawbacksof the F-DEMO methodology. It is assumed that the benefits and drawbacks of step 1 and step 4 of F-DEMO methodology are similar. Table 5.2 Benefits and drawbacks of the F-DEMO methodology Developing Step 2.Workshop DEMOway

3.Construction Model (IAM/ISM)

3a.Process Model

3b.State Model 3c.Requirments retrieval 3d. Validation 5.System (prototype) and aftercare

Benefits - mission and strategy specification - business process are specified - actor analysis and specified domain requirements - user interface matters are discussed - specification of the construction and function - transaction and actors or specified - information banks are described - the responsibility of the actors who fulfill an actor role are specified (managers responsibility) - only the essence is specified - specified business process - specified process requirements - specified process information - not ad-hoc - gather data requirements - helps in RAD - essential requirements - validated Models - conceptual consensus - optimized models - fast and interactive development - less requirement related errors - user interface design is better - errors in the system can be solved quicker (mostly implementation errors) - low complexity level - less maintenance time and cost - less errors has to be solve

Drawbacks - training needed in DEMO - awareness on the notion of enterprise ontology

- abstract - needs training to read the model

- separate TPD (transaction process Diagram) needed for cancellation patterns - time consuming - no one-on-one mapping to relational database - costs extra time - time consuming - duration of the project increases

From Table 5.1 and Table 5.2 follows that F-DEMO has a broader and longer analysis phase. In this way, the implementation phase can be

91


conducted faster, because the requirements are formulated more clear (C4E). The remaining implementation errors at the finished production phase are of a lower complexity and costs half the time to resolve. Let us reconsider the results from the enquiry (see Chapter 4). The total improvement of the project according F-DEMO methodology regarding the requirements, implementation, usability quality matters and misunderstandings, wishes and irrelevant issues that arises when producing a system for financial purposes gives and overall quality improvement of 33,1 percent. This improvement has been made by only changing the analysis and design phase of the ForMetis methodology. From the enquiry result shoot out a 24,2 percentage improvement for the requirements quality matters. This means that improving the requirements for the financial products that have to be implemented in the system, will improve the production of financial systems regarding these products.

92

DEMO introduced to financial services Chapter 6. Conclusion S.S.R.W. Algoe BSc. V.R.K. Boedhram BSc.

Chapter 6.

Conclusion

The insurance business, of which an intermediary is a part of, makes highly personalized financial services that are highly personalized and unique. The production of financial services is subject to business rules and a strong interaction with the client who demands high service and quality levels. This dependency makes the lifespan of such a service highly unpredictable and hard to model. Occurring problems within the intermediary are low service and quality levels to the customer, long processing time of a financial product (even for simple productions), lack of management information, high production cost for a financial service (production per person per service is low), partial software solutions and long time-to-market for new products. The main issues that lead to these problems are a lack of predefined quality criteria and roles for persons responsible for the production of financial services, a lack of understanding between the balance of human and computer and a lack of a correct methodology for the modeling and production of financial services. The processes based on the core business of the intermediary have been modeled with a software tool called BWise. BWise is a software tool that intents to help companies to forecast and give better perception of the consequences when (re-) engineering. BWise falls in the category compliance and risk management software, based on a fundament called Business Process Management (BPM). Processes, compatibility, performance management are the core business of BWise. Besides this, templates are designed which take into account guidelines and governance. BWise saves the models of the described organization in a repository, which is based on Unified Modeling Language (UML). The problem with this type of modeling is that it cannot deal with large and complex organizations, because it is expressed in a natural language. In addition, its lack of a formal theory makes it highly sensitive for ambiguity and therefore different concepts on the models exists which makes consensus hard to be made. The ontological level of an enterprise shows only its essence, fully abstracted from realization and implementation. When recursion of this ontological essence is applied, it delivers detailed models. This is the strength of the DEMO methodology, in contrary to other approaches that firmly link the essence to the realization, implementation and operation. The DEMO methodology is developed at the Delft University of Technology by Prof. Dr. Ir. Jan L. G. Dietz. DEMO is a methodology that is designed for (re)designing and (re)engineering of organizations and is based on a scientific fundamental theory called Ψ-theory (pronounced as PSI-theory and stands for Performance in Social Interaction). The Ψ-theory states that organizations belong to the category of social systems. In these social systems, human beings have the ability to comply with commitments toward each other. The Ψ-theory states at the same time that applying default information systems methods and techniques on organizations are unable to deal with problems like merging, splitting, designing, engineering etc. of enterprises. The Ψ-theory has four axioms and

93


one theorem. An axiom is a proposition that is not proved or demonstrated but considered self-evident, its truth is taken for granted, and serves as a starting point for deducing and inferring other (theory dependent) truths. The first axiom represents the operation of an organization as a system that performs production acts and coordination acts. The transaction axiom states that these acts always occur in universal patterns, called (business) transactions. The third axiom of the Ψ-theory states, that transactions occur in a tree structure and can be composed out of other transactions. The fourth axiom, the distinction axiom describes that in fulfilling actor roles three human abilities are involved in performing: the ontological (performa), the infological (informa) and the datalogical (forma) capabilities. Next, a theorem is derived from these axioms. This theorem states that the organization of an enterprise is a heterogeneous system that emerges from the layered integration of three homogeneous systems: the Borganization (B for business), the I-organization (I for Intellect) and the Dorganization (D for document). DEMO consists of the Construction Model (CM), Process Model (PM), State Model (SM) and Action Model (AM). The Construction Model is the most concise model and represents the construction of the organization. The Process Model contains for every transaction type a transaction pattern (often called a business process). The State Model specifies all the information per state that is created or used by the system. Last of all models, is the Action Model and gives the most detailed view of the organization. It specifies the action rules that serve as a guideline to perform the business process. One of several software development projects that have been completed by ForMetis Consultants BV was a tailor made information system to produce financial services for an intermediary called Van Lanschot Chabot. After the launch of the new software at the intermediary, the users of the system gave a list of findings (errors, bugs, ambiguities and other comments) on the system. The findings could be categorized by their relation to their cause. These categories are usability, implementation, misunderstanding, requirements, wish and irrelevant. Usability findings relates to issues regarding the user interface. Implementation findings are caused by errors made by the programmer when implementing the software. Misunderstandings are about issues of users who have the same concept or thought about a subject. Not completely designed requirements that are essential for the functionality of the system are subjected to requirements errors. Wishes relates to requirements that are not essential for the functionality of the system and are not taken into account when gathering requirements at the beginning of the development. Finally, findings that do not have anything to do with the system are marked as irrelevant. Requirements, implementation, misunderstandings, wishes and usability findings have an impact on the quality of a financial service. If the number of one of these findings increases, the quality level will decrease and vice versa. To find the boundaries of the improvement that could be reached when applying a new software development trajectory, a mapping was done. The finding is mapped to one of the aspect models of DEMO by checking if the given finding is specified by one of the models. When the mapping is successful, the finding is eliminated in the new software and so the quality of the financial service will increase. The theoretical boundaries of the improvement that follows from the mapping are a minimum of 0 percent and a maximum of 50,5 percent. The maximum is determined by the following improvements, requirements (32,3 percent), usability (4,6 percent), wish (10,2 percent) and misunderstandings (3,4 percent). Because

94


DEMO does not relate to implementation, all of these types are reduced except of irrelevant and implementation related findings. The theory is tested by performing a survey to DEMO experts by letting them answer the question if each of the given finding could be prevented according to their experience. Each finding prevented with the new software development methodology gets a certain improvement rate that is expressed as a percentage. In practice a total improvement was reached of 33,1 percent, requirements (24,2 percent), usability (1,8 percent), wish (5,4 percent) and misunderstanding (1,8 percent). It is concluded that the F-DEMO way is better to develop information systems in the financial business than the previous ForMetis methodology. The extra effort put into designing the new software development methodology (F-DEMO) and the advantages and benefits that this methodology provides. In spite of the fact that it takes more time to construct DEMO models of an organization, in the end this way of developing and modeling certainly pays off. As Boehm described the time and cost are easily doubled when the requirements of the information system are not specified in a formal way. When is assumed that everybody involved in the project understands DEMO, the results show that nearly half of the remaining findings were implementation errors of a low complexity. These errors can be solved in half time and therefore compensate the time that is needed to specify the DEMO models. The maintenance time of the system will also decrease because of the precisely identified requirements. Coherence, comprehensiveness, consistence, concise, and essential requirements directly simplify the work of the programmer and improve the implementation time. These type of aspects states that the whole project time when using the FDEMO methodology will be equal to the project time, when using the ForMetis methodology had been used. The ForMetis methodology has a short analysis and design phase and a broader implementation phase. This is a characteristic of the prototyped software development approach. The FDEMO methodology has a broader analysis and design phase and improves the implementation phase thoroughly. In this way, the information system can then be corrected more cost-efficiently when it has to be maintained. The outcome of this research presents a considerable improvement when using DEMO for developing information systems against a fair increased or equal development time. The CM, PM and SM are for great importance to specify requirements and business processes of the organization. For the foundation of this research, it was necessary to construct all the PSD‟s, but in practice, most of the business processes of the insurance business are identical. This is a time-consuming activity. Therefore, one template can be used to model these processes and so this activity will not be such a time-consuming task anymore. The company management shares this view. As was stated in the introduction of this document, many software projects fail due to a lack of communication with the stakeholders but FDEMO eliminates ambiguity. When an information system is developed precisely as is presented in the study the shared correct understanding improves considerably. The mission and the strategy of the client and every department are known, and the requirements of their business process are retrieved in a more precise way. This improves the communication because the business processes and the information system are modeled in detail thanks to the DEMO methodology. The improvement of the analysis and a correct design phase has been of great importance for designing financial service in a better way. All these aspects contribute by preventing the

95


project to be cancelled and letting the budget overrun. It lets the software company to produce a better quality of information systems with fewer costs and maintenance. This leads to a more precise way of implementing and deducing business processes of the clients.

96

DEMO introduced to financial services Chapter 7. Recommendations & Future Research S.S.R.W. Algoe BSc. V.R.K. Boedhram BSc.

Chapter 7.

Recommendations & Future Research

The authors recommend ForMetis to use the F-DEMO methodology by following the steps as given in the new software developing methodology. A brief overview of the steps to be followed is given below: 1. Construct the Construction Model. This gives a clear and unambiguous view of the organization, leaving out the implementation details (3.1). It consists of the Interaction Model (3.1.1) and the Interstriction Model (3.1.2). 2. Construct the Process Structure Diagrams for all the business processes. The process order is determined and process requirements are obtained (3.2). 3. Construct the State Model. In this model, the import objects an information items are identified (3.3). 4. Determine the functional and process requirements from the models. These are the requirements that are needed to implement the transactions into a information system (5.4) 5. Determine user interface requirements; requirements regarding the user interface of the system. Note that this is not about how it is displayed (color, format, fonts etc.), but what is displayed on the screen (polis, client name, phone number, etc.) (5.4). 6. Start developing, testing, accepting and implementation with the DTAP method (5.5). 7. Check the evaluation result and start validating the system (5.6). 8. Deliver the complete system after it is finally accepted (5.6). If one needs more details about each step as stated above, refer to the given section or chapter. To underpin the results of this master thesis project, which states that DEMO and thus an ontological model can be used for building information systems, it is recommended to ForMetis to apply the F-DEMO methodology in future software development projects. It is also proved in this document that designing business processes of financial organizations are improved sufficiently and are made clearer and understandable for the organization into consideration using DEMO.

7.1 Revise planning phase by adding project management In the planning phase of the project, it is essential to set goals, define the project, develop a work breakdown schedule and identify the team resource according to a structural way. For ForMetis it is recommended to revise their “ad-hoc” planning that is sufficient for projects with a small budget, but for large project this method will fail and a better method is needed in this phase. Meredith and Mantel [Meredith & Mantel, 2006] describe that all projects are unique and are exposed to certain degree of risks and

97


therefore it is recommended to use project management frameworks for each project. For a better management control, companies subdivide projects into several manageable phases and work packages. Some key frameworks for project management are Work Breakdown Structure (WBS) and Project Live Cycle (PLC). The latter is often used in business re-engineering and IT system development projects. Within the PLC framework, the work is subdivided into sequential phases. Each phase consists of several sub-phases and activities and a project should successfully pass through each of the project phases to continue on to the next. Management reviews should occur after each phase to evaluate the project progress, likely success, and continued compatibility with the project‟s goals. Although the software engineering project cannot be done in a sequential way, the methods of planning can be used as an aid. PLC assumes that all actors completely understand the problem to be solved, capture everything in writing and getting all the stakeholders to agree. This is almost impossible for an IT system development[Meredith & Mantel, 2006]. In this thesis, it is shown that a correct methodology can be a huge aid in retrieving the correct and essential requirements. In Figure 7.1 it can be seen that who is saving costs in planning and concept pays it afterwards. This is also proved in this master thesis research.

Figure 7.1 Importance of the project-planning phase

7.2 Apply the Action Model to the study case It is recommended that for further research the Action Model have to be applied when using the F-DEMO methodology because it helps to improve the development of information systems and the business processes. The Action Model provides action rules that are formally specified and provides a complete description of essential operational decisions in the organization, leaving out the non-essential matters. This model can therefore be used to specify business rules, which is a growing interest nowadays.

98


7.3 Make use of automated testing when implementing Testing takes a lot of time when designing information systems, nearly half the time of the implementation phase are expended to testing. This will minimize implementation errors and gain more time for analysis and design to retrieve system requirements. In addition, when taking into account the amount of implementation related errors as given in Chapter 4, it is recommended that ForMetis have to improve their way of software testing. To do so they have to to do future research in how they can test the developed information systems in an automatic way. For example UNIT testing approaches can be used, which is a growing application field. UNIT testing is a software verification and validation method in which individual source code units are tested in an automated way. A unit is the smallest testable part of an application, think in a procedural programming language of methods, function, procedure, etc. While in object-oriented programming, you have to think of a Class that may belong to a base/super Class, abstract Class or derived/child Class.

7.4 Generate information systems from DEMO models Another recommendation is that for future work, further research has to be conducted on how information systems can be designed from ontological models in an automated way. This very challenging research will narrow the gap between the business and the information system developers. In [Nuffel et al, 2009] it is argued that because DEMO is fully correct it can be used to construct information system in an automated way. This is theoretically possible, but a project has to be carried out in which it is showed practically. Business components [Albani & Dietz, 2006] can be specified from the DEMO models as described by Albani. Its use can help to accomplish automated information design from ontological models.

7.5 Motivate business partners for using formal models ForMetis has included the DEMO methodology in its software development approach and has started to use it in their new information system design project. This is just one example of a successful DEMO application, but this success, even if it is rather small, is important to narrow the gap between the business and academics. The business is more interested in revenue and is not interested in scientific talks of academics, because in practice these talks are not profitable. On the contrary, the academics wish to test their work in practice to underpin their theories. DEMO is proven effective in the following selection of practical case studies more can be found on the website [DEMO Knowledge Center, 2008]. INQA quality management system In the quality management market familiarity with and assessment of a profession is of utmost importance. Especially because for organizations in this market the description of quality management is a labour-intensive process, thus resulting in high costs. The same applies here: good tools are half the work. Those who have good 'tools' to make process descriptions have the most chance of producing happy customers. Air France Cargo - KLM Cargo Aerospace Logistics

99


In the maintenance of aircrafts and aircraft motors, flexibility and availability are the most important factors for success. Every hour a Boeing 747 is not airbourne costs tens of thousands of euros. Planned maintenance, as well as unpredictable and unforeseeable activities must be carried out very quickly. Aerospace Logistic, a division of Air-France-KLM Cargo, is one of the important players in the supply of equipment for the necessary maintenance. The FuneralSuite On a daily basis, entrepeneurs in the funeral business find themselves in a high tension boundary area with tight planning and an internal organization on one side, and demanded involvement and care for customers, together with an attention to detail, on the other side. In addition to this, the funeral business is faced with a more critical and mouthy consumer. More and more demands are made for a custom-made product, which increases the complexity of the processes. Arrangement of supply chain processes subsidy Government subsidies are not granted 'just like that'. There are always certain goals which are pursued, for example the improvement of the competitive power of the Dutch economy by stimulating innovation; advancement in certain (investment) behaviors; stimulation of employment; development of exports and so forth. The people assigned to decide about the granting of a subsidy depends on the organization where the application is submitted. Now DEMO proves to be significantly better than other methods, the business world has to become aware of this and has to be interested accordingly to improve their business. Finally, from experience in the application of DEMO, if it is applied in the correct way organizations can derive many benefits from DEMO.

100

DEMO introduced to financial services Chapter 8. Discussion S.S.R.W. Algoe BSc. V.R.K. Boedhram BSc.

Chapter 8.

Discussion

In this chapter, a discussion about the relation between the theoretical and the practical improvement is given and why these improvement rates are not equal. Theoretically, an improvement of about 50 percent can be attained. This value can be seen as the boundary of the maximum improvement that can be achieved when using DEMO. However, in practice, none of the interviewees gave for every finding a full score of 100 percent on the improvement rate and therefore the measured average improvement is lower than the theoretical improvement. The practical improvement rate was about 33 percent. Obviously when reaching a lower a result then the theory states, the question is why. After examining the results, we have found that the average improvement of 33,1 percent is gained from two groups of improvement values. Let these groups be named Group A and Group B for the convenience. Group A has an average improvement of 37,3 percent and Group B has an average improvement of 20,5 percent. This indicates that the outcome of Group A lies nearer to the theoretical improvement than the outcome of Group B. Group B lets the total average improvement decrease to 33,1 percent. The two peaks in Figure 8.1 represent respectively the average improvement of group A and group B.

50,0% 40,0% 30,0% 20,0% 10,0% 0,0%

37,3% 20,5%

Group A

Group B

Figure 8.1 Two Peaks identified from survey results The low result of Group B makes it curious why this group came to such a low improvement rate. From the table below it became clear that Group A states that F-DEMO ensures an improvement of 25,9 if the finding is related to a requirement error and Group B states that this is 18,8 percent. This gives a difference of 7,2 percent. For the usability, wish and misunderstanding types, the differences are respectively 2,2 percent, 5,4 percent and 2,0 percent. To get a better understanding why these differences occur, the relevant findings have been examined. From this examination and sessions with the

101


interviewees, it is concluded that each group has a different opinion in how F-DEMO can affect or prevent the findings that still occur after the information system is designed. Table 8.1 Difference improvement rate per group

Group A Group B Difference

Irrele vant 0% 0% 0%

Requirements 25,9% 18,8% 7,2%

Implement -ation 0% 0% 0%

Usabilit y 2,3% 0.1% 2,2%

Wish 6,7% 1,3% 5,4%

Misunderstanding 2,3% 0,3% 2,0%

Total 37,3% 20,5% 16,8%

The first view is that of Group A in where all the findings from the categories, with a human-computer interaction aspect in it, are considered improvable regarding the category. In other words, all the findings that relates with the user interface of the system have been positively rated by the interviewees of Group A. This group has also taken into account the infological and datalogical transactions, which are needed to complete the ontological transaction, because they recognize that the infological transactions and datalogical transactions are considered, are needed for the implementation trajectory. They also state that in the user interface, it does not matter how the information is presented (user-interface looks), but the fact that the information needed is displayed (on the user-interface). On the other side, there is Group B that had also taken into account the infological and datalogical transaction, but they state that everything regarding the user interface is neglected and F-DEMO cannot provide anything extra for the improvement of user interfaces. This way of thinking makes the improvement rate fall drastically and come to an average improvement of all interviewees of 33,1 percent and not something nearer to 50 percent. The discussion is that whether the user interface is considered a human-computer interaction (view of Group B) or a human-human interaction (view of Group A). Let us consider that the user interface fulfills an actor role that communicates with the user of the system and the user interface has to provide the user with the requested information by displaying it on the screen. In this way, the style and format of the user interface is not essential, but the fact that the right information is on the screen is essential to the user of the system. From this point it can be stated that the process steps request, promise, state, accept, cancel and stop can also be perform between these actor roles. Therefore, the view of Group B is considered to be limited because they cannot guarantee that the right information is displayed which makes it come closer to the view of Group A. However, both groups agree on the fact that the findings that could be eliminated using F-DEMO are related to requirements specification errors. These errors are much harder to fix than just programming errors. As a result Group B has the opinion that if this weighing of findings is taken into account, the overall improvement is substantial higher than 20,5 percent. Therefore, the outcome of Group B can be seen as the lower boundary of the maximum improvement and the outcome of Group A lies between this lower boundary and the theoretical upper boundary.

102


103


104

DEMO introduced to financial services 0. References S.S.R.W. Algoe BSc. V.R.K. Boedhram BSc.

References Albani, A., & Dietz, J. L. (2006). The benefit of enterprise ontology in identifying. Springer Boston. Albani, A., & Dietz, J. L. (2006). The Benefit of Enterprise Ontology in Identifying Business Components. Boston: Springer. Barjis et al. (2002). Modelling dynamic behaviour of business organisations

- extension of DEMO from a semiotic perspective. Bergsma, J. (2007). Testen onder welke voorwaarden? Nieuwegein: TestNet. Boehm, B. W. (1981). Software Engineering Economics. New Jersey: Prentice Hall . Bouwmeester, B., & de Landsheer, B. (1997). Het OTAP-model. IT-beheer . BWise. (2009, May). Corporate Governance Management. Opgeroepen op May 2009, van BWise: http://www.bwise.nl Davis, A. M. (2004). Great Software Debates. New York: Wiley-IEEE Computer Society Press. DEMO Knowledge Center. (2008). Home. Opgeroepen op 2008, van DEMO Knowledge Center - Design & Engineering Methodology for Organizations: http://www.demo.nl/ Dennis, A., Wixom, B. H., & Tegarden, D. (2002). Systems Analysis & Design. New York: John Wiley & Sons Inc. Dietz, J. L. (2006). Enterprise Ontology. Berlin Heidelberg: Springer-Verlag Berlin Heidelberg. Dietz, J. L. (2008). The benefits of applying Enterprise Ontologies for developing World Ontologies. Delft: Delft University of Technology. Dietz, J. L. (1999). Understanding and Modeling Business Processes with

DEMO. Formetis Consultants BV. (1998-2009). Smart added value. Opgeroepen op May 2009, van Formetis: http://www.formetis.nl/ Fratianni, M., & Marchionne, F. (2009). The Role of Banks in the Supreme

Financial Crisis. Gamma et al. (1994). Design Patterns: Elements of Reusable. Baarn Nederland: Addison-Wesley Professional. IT Cortex. (2001). Statistics over IT Failure Rate. Opgeroepen op May 20, 2009, van IT Cortex: http://www.it-cortex.com/Stat_Failure_Rate.htm Jansen, N. (2003). De economie van het testen - testtrends in de ICT. Software Release Magazine . Kervel, S. v. (1999). Intelligent Electronic Dossiers. Opgeroepen op 2008, van Don Paparassos: http://www.donpaparassos.com Lethbridge, T. C., & Laganière, R. (2005). Object-Oriented Software Engineering. New York: McGraw-Hill Companies, Inc. Meredith, J. R., & Mantel, S. J. (2006). Project Management - A Managerial Approach. New Jersey: John Wiley and Sons Pte LTD.

105


Mulder, J. (2006). Rapid Enterprise Design. Den Haag: CIP-DATA Koninklijke Bibliotheek. Nuffel et al. (2009). Enhancing the Formal Foundations of BPMN by

Enterprise Ontology. Object Management Group. (2009, January). UML. Opgeroepen op May 2009, van Object Management Group - UML: http://www.uml.org/ OMG, O. M. (2008). Opgeroepen op June 2008, van Object Management Group: www.omg.org Van Lanschot Chabot. (2009). Van Lanschot Chabot. Opgeroepen op May 2009, van Van Lanschot Chabot: http://www.vanlanschotchabot.nl Wood, J., & Silver, D. (1989). Joint Application Design. New York: John Wiley & Sons. ZDNet. (2009, May). IT Project Failures. Opgeroepen op May 2009, van http://blogs.zdnet.com/projectfailures

106


107


108

DEMO introduced to financial services 0. Index S.S.R.W. Algoe BSc. V.R.K. Boedhram BSc.

Index

A

C

ABD ............................................................. 50 accept ..................................... 58, 69, 87, 101 Action Model 14, 26, 28, 39, 42, 64, 88, 93, 97 Actor Bank Diagram ........................ 15, 50, 52 actor role .... 36, 37, 38, 39, 43, 44, 47, 49, 50, 53, 57, 58, 59, 60, 87, 88, 90, 93, 101 Actor Transaction Diagram ......................... 43 ad-hoc ...................... 22, 25, 35, 85, 88, 90, 96 Ad-hoc Experience planning ....................... 85 AH-way ........................................... 16, 86, 89 analysis phase ......................26, 27, 32, 34, 90 applications 11, 19, 20, 21, 26, 30, 33, 39, 53, 62 ATD ........ 15, 27, 43, 44, 45, 46, 47, 48, 49, 50 axiom ............................. 13, 36, 37, 38, 43, 93

C4E ............................................ 11, 24, 69, 91 C-act .......................................... 36, 37, 38, 55 cancelation steps ........................................ 81 causal relationship ...................................... 56 checklists ........................... 28, 43, 70, 86, 143 Client ....................................... 45, 49, 59, 156 coherent ...................................... 9, 40, 69, 85 communication patterns ............................. 87 communication steps .................................. 80 Complaint Controller................. 47, 50, 52, 53 complaint handling ..................................... 49 components ........................ 21, 35, 40, 88, 98 composite actor .............................. 43, 45, 50 composite actor role ....................... 43, 45, 50 composite actors ......................................... 45 composite data bank................................... 52 composite production bank ........................ 53 comprehensive............................ 9, 69, 85, 88 concise ........... 9, 42, 43, 44, 69, 85, 87, 93, 94 concrete .............................. 11, 23, 27, 69, 85 conditional relationships ............................. 56 construction model ............................... 24, 50 coordination world ............................... 25, 55 cost.. 20, 21, 22, 25, 32, 34, 35, 50, 68, 89, 90, 92, 94 C-result ........................................................ 55 customer ....................... 20, 22, 32, 37, 48, 92

B Bank Content Table ........................ 17, 50, 51 BCT........................................................ 50, 53 benefits .................. 27, 28, 84, 90, 94, 99, 104 Boehm .......................................... 32, 94, 104 BPM ...................................................... 24, 92 business .. 9, 11, 14, 15, 16, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 34, 36, 37, 38, 40, 42, 43, 44, 47, 49, 50, 55, 56, 57, 58, 59, 60, 61, 62, 63, 66, 86, 87, 88, 90, 92, 93, 94, 96, 97, 98, 99, 104 business process . 9, 15, 16, 19, 22, 23, 25, 26, 27, 28, 34, 37, 42, 56, 57, 58, 59, 60, 61, 62, 86, 87, 88, 90, 93, 94, 96, 97 Business Process Management ............ 24, 92 business rules ......................21, 25, 88, 92, 97 business transaction43, 44, 49, 50, 55, 56, 63, 87 BWise .................................24, 26, 28, 92, 104

D damage claim ........................................ 49, 56 Damage Claimer .................................... 47, 53 Damage Expert ............................................ 45 damage expertise ...................... 49, 50, 56, 57 data model .................................................. 88 datalogical ........27, 38, 40, 43, 50, 62, 93, 101 Datalogical processes .................................. 62 decline ......................................................... 69

109


DEMO 9, 11, 13, 14, 15, 23, 24, 25, 26, 27, 28, 30, 35, 36, 37, 39, 40, 42, 43, 50, 64, 68, 71, 72, 75, 76, 79, 80, 81, 84, 85, 86, 87, 89, 90, 92, 93, 94, 96, 98, 99, 100, 104, 137 derivation rules ..................................... 63, 65 derived facts ............................................... 63 derived information .................................... 63 designing phase .......................................... 85 development .... 11, 15, 19, 20, 21, 22, 23, 24, 26, 27, 30, 32, 33, 34, 62, 66, 68, 80, 85, 87, 88, 89, 90, 93, 94, 97, 99 distinction axiom ............................ 38, 43, 93 D-organization ................................ 38, 50, 93 drawbacks ................ 14, 17, 34, 84, 87, 89, 90 DTAP ........................ 15, 32, 33, 85, 88, 89, 96

E E-dossier system ................................... 84, 85 elementary actor ...................... 43, 47, 60, 86 elementary natural language...................... 64 enterprise ontology ..... 11, 19, 27, 42, 90, 104 environment .................. 33, 34, 37, 43, 48, 70 essential .. 9, 19, 22, 32, 36, 43, 44, 53, 65, 69, 80, 85, 86, 87, 90, 93, 94, 96, 97, 101 executor...............................37, 45, 49, 50, 53 existential laws ............................... 63, 87, 88 external actors ............................ 9, 43, 44, 47

F failures ............................................ 19, 20, 34 F-DEMO .. 9, 13, 14, 15, 16, 17, 28, 30, 34, 35, 68, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 84, 85, 87, 89, 90, 91, 94, 96, 97, 100, 101 filtered findings............................... 15, 74, 80 financial business .................................. 24, 94 financial industry ...................... 19, 23, 24, 42 financial products ..................... 20, 27, 79, 91 financial services . 1, 11, 13, 20, 21, 22, 23, 24, 25, 26, 27, 28, 32, 42, 62, 86, 92, 93 finding ... 17, 20, 28, 68, 69, 70, 71, 72, 73, 74, 75, 76, 79, 80, 81, 93, 94, 100 ForMetis 1, 3, 9, 11, 13, 14, 15, 16, 17, 20, 21, 22, 23, 24, 25, 26, 27, 28, 30, 31, 32, 33, 34, 35, 42, 66, 68, 69, 70, 76, 84, 85, 86, 87, 88, 89, 91, 93, 94, 96, 98 ForMetis methodology ... 9, 13, 14, 15, 16, 17, 26, 28, 30, 32, 34, 35, 76, 84, 86, 87, 89, 91, 94

H human computer dialog .............................. 80

I implementation ..9, 11, 15, 19, 22, 25, 28, 30, 32, 33, 34, 35, 39, 68, 69, 70, 72, 73, 74, 75, 77, 80, 84, 85, 87, 88, 89, 90, 91, 92, 93, 94, 96, 98, 101 implementation error .. 69, 72, 73, 74, 75, 77, 80, 89, 90, 91, 94, 98 implementation phase . 33, 35, 68, 85, 88, 89, 90, 94, 98 improvements ............... 25, 72, 75, 76, 78, 93 infological .........27, 38, 40, 43, 50, 62, 93, 101 Infological processes ................................... 62 informal specification.................................. 85 information banks ........................... 43, 50, 90 information items ... 53, 55, 64, 65, 71, 87, 96 information systems 9, 14, 19, 20, 21, 22, 23, 27, 28, 30, 31, 36, 68, 79, 84, 87, 92, 94, 95, 96, 97, 98 Information Use Table ................................ 55 informative conversations .......................... 50 initiator ..................................... 37, 49, 50, 53 insurance..... 14, 20, 22, 23, 24, 25, 28, 42, 43, 44, 45, 49, 50, 51, 53, 56, 57, 58, 59, 61, 84, 92, 94, 113, 173, 174 Insurance Company .................................... 49 insurance damage claim ......... 49, 50, 51, 174 insurance product ........................... 23, 45, 50 intermediary . 9, 15, 17, 23, 24, 25, 26, 27, 28, 30, 42, 43, 44, 45, 46, 47, 48, 49, 50, 52, 53, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 84, 85, 86, 87, 88, 92, 93 interstriction model .................................... 50 interstriction relations .......................... 50, 53 I-organization .................................. 38, 50, 93 irrelevant ................... 9, 69, 70, 80, 91, 93, 94 IUT ................................................... 17, 55, 62

K Key Process Indicators ................................ 86 KPI ................................................... 86, 88, 89

L law of Boehm .............................................. 19

M managers information ................................ 84 mappable ........................................ 72, 75, 76

110


mapping ................... 17, 71, 72, 76, 77, 90, 93 maximum improvement ..71, 72, 75, 100, 101 methodology 9, 11, 14, 17, 19, 20, 21, 22, 23, 24, 26, 27, 28, 30, 34, 35, 39, 42, 62, 68, 71, 72, 74, 75, 76, 80, 81, 84, 85, 86, 87, 89, 90, 91, 92, 94, 96, 97, 98 minimum improvement.............................. 71 misunderstandings .......... 9, 69, 79, 81, 91, 93 modeling . 9, 20, 22, 23, 24, 25, 26, 27, 28, 35, 63, 85, 92, 94

N not mappable ............................................. 76

O Object Fact Diagram ................................... 63 Object Property List .................................... 63 Object Role Modeling ................................. 63 OCD ........................................... 15, 50, 53, 54 OFD ........................................... 15, 63, 64, 65 offer delivery .............................................. 49 ontological .. 19, 23, 27, 38, 39, 43, 49, 62, 92, 93, 96, 98, 101 ontological business processes ................... 62 operation axiom ................................... 36, 44 OPL ........................................... 17, 63, 64, 65 Organization Construction Diagram ..... 50, 53 Organization Theorem .................... 13, 38, 50 original facts ............................................... 63 original information .................................... 63 ORM ............................................................ 63 overall improvement .............. 17, 72, 77, 101

P P-act ................................................ 36, 38, 55 Performa-Informa-Forma Analysis ............. 43 P-fact ........................................ 36, 37, 38, 55 planning phase .............. 14, 16, 34, 85, 96, 97 PM ..................... 13, 39, 55, 56, 62, 87, 93, 94 policy .... 24, 45, 49, 51, 53, 59, 62, 64, 69, 84, 86, 173, 174 policy continuation ..................................... 49 policy delivery ............................................. 49 policy termination ...................................... 49 Potential Client ......................... 45, 49, 58, 59 practical .................................. 75, 76, 98, 100 prevented findings .......................... 74, 77, 78 process.. 15, 20, 23, 25, 28, 30, 31, 37, 39, 42, 43, 55, 56, 58, 59, 61, 62, 63, 81, 84, 86, 87, 88, 89, 90, 93, 96, 98, 101, 173 Process Model .. 13, 14, 28, 39, 42, 43, 55, 88, 90, 93

process step ............................ 55, 62, 87, 101 Process Structure Diagram .................... 55, 96 processes .... 19, 21, 22, 23, 24, 32, 37, 56, 62, 63, 71, 86, 88, 89, 92, 94, 99 producer................................................ 37, 48 product advice .............. 43, 45, 49, 51, 58, 65 Product Advisor ........................................... 47 production banks ........................................ 71 promise ............................. 37, 50, 69, 87, 101 PSD ......... 15, 55, 56, 57, 58, 59, 60, 61, 62, 94 PSI ......................................................... 35, 92

Q quality ... 11, 19, 20, 21, 22, 23, 24, 25, 26, 33, 34, 35, 66, 79, 80, 91, 92, 93, 95, 98 quality improvement....................... 26, 80, 91

R RAD ....................................................... 66, 90 Rapid Application Development ................. 66 request .......37, 49, 50, 58, 59, 61, 69, 87, 101 requirements 9, 11, 19, 22, 23, 31, 32, 34, 35, 62, 65, 69, 70, 72, 74, 77, 79, 80, 81, 85, 86, 87, 88, 89, 90, 91, 93, 94, 96, 97, 101, 137 requirements engineering............... 62, 65, 79 requirements error ............. 69, 72, 74, 79, 93 requirements errors .................. 69, 72, 79, 93

S service ... 19, 20, 21, 22, 25, 27, 44, 50, 84, 92, 93, 94, 154 service-hatch ............................................... 50 SM ......................13, 55, 63, 64, 65, 87, 93, 94 social systems ....................................... 36, 92 software development . 11, 19, 21, 24, 26, 27, 28, 30, 32, 33, 34, 35, 76, 93, 94, 96, 98 state .... 22, 25, 27, 42, 55, 63, 69, 87, 93, 101, 173 State Model... 9, 13, 14, 28, 39, 42, 50, 55, 63, 88, 90, 93, 96 survey 9, 11, 13, 14, 15, 16, 17, 26, 28, 68, 69, 71, 75, 76, 77, 80, 81, 94, 100 System (prototype) ............................... 85, 90 system requirements ................ 34, 35, 87, 98

T theorem ........................ 15, 36, 38, 39, 40, 93 theoretical boundary .................................. 71 theoretical improvement .......................... 100

111


time5, 9, 11, 19, 21, 25, 27, 28, 32, 34, 35, 36, 43, 62, 64, 68, 70, 76, 80, 85, 86, 88, 89, 90, 91, 92, 94, 98, 146, 173 timeless ...................................................... 43 transaction .... 9, 15, 22, 36, 37, 39, 42, 43, 45, 48, 49, 55, 56, 57, 58, 59, 60, 61, 63, 69, 71, 86, 87, 88, 90, 93, 101 transaction axiom ........................... 36, 55, 93 transaction pattern ................... 15, 37, 42, 93 Transaction Result Table....................... 27, 43 transaction type............. 39, 42, 43, 48, 87, 93 transactions 22, 25, 28, 36, 37, 38, 39, 43, 44, 45, 48, 49, 50, 55, 56, 57, 71, 87, 88, 93, 96, 101 transport certificate delivery ...................... 49 TRT .......................................17, 27, 43, 44, 49

U usability .. 9, 11, 33, 69, 70, 74, 79, 80, 89, 91, 93, 94, 100

112

usability errors ................................ 69, 79, 80 user interface ....32, 35, 69, 80, 87, 88, 90, 93, 96, 101

V validation ...................... 22, 26, 57, 76, 88, 98 verification ...................................... 76, 77, 98

W wish ..................69, 70, 74, 80, 93, 94, 98, 100 workflow ............... 19, 21, 39, 43, 62, 84, 149 World Ontology Specification Language ..... 63 WOSL........................................................... 63

Ψ Ψ-theory ....................... 35, 36, 37, 38, 92, 93

DEMO introduced to financial services Appendix A Checklist Pension and Life insurance S.S.R.W. Algoe BSc. V.R.K. Boedhram BSc.

113


114


Appendix A

Checklist Pension and Life insurance

115


116


117


118


119


120


121


122


123


124


125


126


127


128


129


130


131


132


133


134


135


136


137


138

DEMO introduced to financial services Appendix B Survey S.S.R.W. Algoe BSc. V.R.K. Boedhram BSc.

Appendix B

Survey

Beste deelnemer, Allereerst bedankt dat u wilt deelnemen aan dit onderzoek. Wij Shairesh en Vijay, 2 studenten aan de Technische Universiteit Delft doen onderzoek naar de impact die de DEMO methode (www.demo.nl) zou hebben als deze gebruikt zou worden bij het ontwerpen van een nieuw systeem. In dit geval gaat deze enquête over het systeem dat door Formetis Consultants BV is ontwikkeld voor Van Lanschot Chabot. Dit dossier systeem is ontwikkeld aan de hand van meerdere sessies die gehouden werden in een soort workshop, waarbij de klant (met name de gebruikers van het nieuwe systeem) hun wensen en ideeën naar voren konden brengen. Na invoering van het systeem is de gebruiker gevraagd hun feedback te geven over het systeem. We hebben deze bevindingen geanalyseerd en hiervan de dubbele meldingen van verschillende gebruikers eruit gefilterd. Vervolgens hebben wij deze bevindingen gecategoriseerd aan de hand van de volgende categorieën:

Gebruikersvriendelijkheid fout:

onduidelijkheden

in

de

GUI

(MMI

dialog)

Implementatie fout: Misvatting:

codeerfouten veroorzaakt door de programmeur de klant heeft niet goed (genoeg) gekeken of begrepen wat er precies verwacht werd

Requirement fout:

de klant heeft niet duidelijk genoeg aangegeven wat hij precies wilde hebben toen een bepaalde functionaliteit naar voren werd gebracht. een functionaliteit die bij het opstellen van de requirements over het hoofd werd gezien. Of een functionaliteit die pas later werd ontdekt. dit zijn opmerkingen die zich relateren tot invloeden van buitenaf het applicatiesysteem.

Wens:

Irrelevant: Stelling:

“Een op de DEMO gebaseerde methode zou de door de gebruiker aangegeven bevinding hebben weten te voorkomen.” Deze stelling kan per bevinding worden beantwoord met de volgende antwoorden: 1. Helemaal mee oneens 2. Mee oneens 3. Neutraal 4. Mee eens 5. Helemaal mee eens Gevraagd wordt aan de deelnemer antwoord te geven door slechts één cirkel in te kleuren (1e t/m 5e) bij de bijbehorende bevinding.

139


Bevi Omschrijving nd. 1 Vinkjes worden niet vastgehouden in de checklist 2 Vanuit rappel foutmelding bij klikken op knop "open dossier" 3 Bij toevoegen van een document vanuit Octopus met knop krijg je foutmelding en raak je het document kwijt 4 Bij terugplaatsen in Octopus met knop, document in geselecteerde postbus, niet eigen postbus zoals beschreven 5 Bij doorsturen is de termijntijd niet aan te passen 6 Bij het tabblad processen is de knop "Openen Dossier" uigegrijsd en kun je dus niet naar het dossier 7 Subdossiers kunnen in de software alleen onder relatie terwijl certificaten en naverrekening alleen onder een polis kunnen hangen en dus niet onder relatie 8 Klantbeeld is niet op te roepen vanuit polis- en schadedossier 9 Bij zelf aanmaken regel in logboek, kun je geen tijd invoeren door een fout masker 10 Bij pakketpolis vanuit polis geen schades te zien 11 Bij werklijst ontbreekt de deadline 12 Wanneer een checklijst afgewerkt is, kan hij nog steeds gewijzigd worden 13 Wanneer je in een schadedossier zit, wordt niet het schadenummer in de knoppenbalk weergegeven maar een ander nummer 14 Bij het opnieuw zoeken wordt het oude resultaat bewaard en dus niet ververst 15 Bij het openen van een klantdossier wordt geopend op het tabblad documenten (relatiedossier), makkelijker zou zijn tabblad polis- of schade naar gelang de werkzaamheden van de medewerker

140

Type Implementatie fout

1 2 3 4 5 . . . . . O O O O O

Implementatie fout

O O O O O

Implementatie fout

O O O O O

Implementatie fout

O O O O O

Requirement fout

O O O O O

Implementatie fout

O O O O O

Misvatting

O O O O O

Implementatie fout

O O O O O

Implementatie fout

O O O O O

O O O O O Implementatie fout Requirement fout Requirement fout

O O O O O O O O O O

Implementatie fout

O O O O O

Misvatting

O O O O O

Wens

O O O O O


16 Wanneer je in een dossier zit zie je alleen maar een nummer in de navigatiebalk en geen extra info in een kopregel zoals nu in SD het geval is. Bij Schadedossier dient nog wel de naam van de behandelaar in informatieregel worden toegevoegd 17 Lange relatienamen zijn niet zichtbaar in de navigatiebalk (button) 18 Bij het klantbeeld is het makkelijker wanneer alles is uitgeklapt, dit scheelt muisklikken 19 Bij het klantbeeld kan bij de polissen nr ext verwijderd worden polis: nummer is genoeg 20 Klantbeeld kan niet ververst worden 21 In klantbeeld missen knoppen a la Lotus Notes voor het eenvoudig open en dicht kunnen klappen van de structuur 22 Aantekenbalk in relatiedossier is weg, zo raken we informatie kwijt ten opzichte van de huidige situatie (conversie huidige dossieraantekeningen) 23 In de kop van de checklijst staat niet welke het is, dit zou wel makkelijk zijn, zeker als er ook nog twee versies van een checklijst zijn door tussentijdse aanpassingen 24 Bij elke knop moet een omschrijving komen wanneer je er met je muis overheen gaat. Op dit moment is dit nog niet overal zo, vooral op de 3e regel knoppen 25 In knoppen balk bij relatiedossier 2 keer hetzelde icoon op een knop, logboek en toevoegen sub-map 26 In Certificaatdossier kun je letters intikken (b.v. verzekerd bedrag en eigen risico) waarna een (voor gebruikers) onduidelijke foutmelding volgt 27 Bij aanmaken sub-dossiers komt steeds melding dat hij is aangemaakt. Geen scherm ter bevestiging meer.

Implementatie fout

O O O O O

Misvatting

O O O O O

Wens

O O O O O

Requirement fout

O O O O O

Requirement fout Wens

O O O O O O O O O O

Implementatie fout

O O O O O

Gebruikersvriendelijkh eid fout

O O O O O

Implementatie fout

O O O O O


O O O O O

Implementatie fout

O O O O O

Implementatie fout

O O O O O

141


28 Dossierheapcodes hoeven niet zichtbaar te zijn bij sub-dossiers 29 Bij aanmaken offerte-dossier meteen naar de soort vragen, nu lijkt het net of je twee keer dezelfde vraag krijgt. Na keuze offerte dossier is het overzichtelijker om in hetzelfde venster de vervolgkeuze (b.v. algemeen , leven, varia, brand etc.) te kunnen maken. 30 Bij schade bij het selecteren van de toe te voegen checklist .di0 weghalen 31 Mogelijkheid bieden om aangemaakte subdossiers te kunnen verwijderen. Uiteraard moet het verwijderen pas kunnen op het moment dat er geen documenten in een dossier aanwezig zijn. 32 Tonen historie van processen niet conform Systeemdefinitie. Zou dubbelklikken zijn per proces, is nu vinkje. Door vinkje is het mogelijk om afgesloten processen nog een keer door te sturen 33 Bij het afsluiten van een proces dat toegewezen is aan iemand anders, raakt het hele proces kwijt, dit hoort groen te worden 34 Fiatteringsproces is niet af te ronden, foutmelding 35 Lettertype van de checklijsten is erg klein en regelafstanden moeten groter 36 Bij offerte-dossiers (op dit moment nog maar 1 dossier "algemeen" beschikbaar) geen mogelijkheid tot het invullen van verwachte provisie 37 Bij het invullen van een datum en gedeeltelijk leeglaten daarvan (b.v. 01 enter of 01-12 enter), krijg je wel een foutmelding, maar wordt het item wel toegevoegd met 01-01-1900 38 In documentenlijst (relatieniveau) zijn de keuzes niet gelijk aan de types die in de documentproperties gekozen kunnen worden.

142

Gebruikersvriendelijkh eid fout Gebruikersvriendelijkh eid fout

O O O O O

Gebruikersvriendelijkh eid fout Requirement fout

O O O O O

Misvatting

O O O O O

Implementatie fout

O O O O O

Implementatie fout

O O O O O


O O O O O

Requirement fout

O O O O O

Implementatie fout

O O O O O

Implementatie fout

O O O O O

O O O O O

O O O O O


39 Je kunt zelf bij de invoer de datum van de Deadline voor Termijndatum leggen. Chronologisch klop dit niet 40 Kan het icoon voor het openen van octopus het octopus icoon gebruikt worden, op dit moment is dit icoon gelijk aan het icoon van het tabblad "Documenten" 41 Bij de processen kan er handmatig een fiatteringsslag opgestart worden, eigenlijk kan dit alleen vanuit een checklijst. 42 Als je in een checklijst zit, moet knop nieuwe checklijst opstarten niet te zien zijn, dit werkt verwarrend 43 Bij klikken op knop nvt in checklijst, wordt geen naam en datum ingevuld. Bij opslaan wordt als datum 01-011900 ingevuld en geen naam 44 Bij het toevoegen van een regel in het logboek, is datum niet verplicht 45 Bij het toevoegen van een regel in het logboek, is het mogelijk om een halve datum in te voeren 46 Het handmatig toevoegen van een proces (rappel enz.) is niet mogelijk in het offerte-,cetificaten-, klachten,naverrekenen protefuille-dossier 47 Bij het openen van een klantdossier met een klacht, dan krijg je hier geen melding van. Zie parkeerlijst regel 56 48 Bij het zetten van rappellen, moet uit standaard agenderingen gekozen kunnen worden zoals dat nu ook in Level kan 49 Bij het toevoegen van een nieuwe checklijst moet hij gelijk geopend worden 50 Toevoegen van een terug-knop waarbij het oude scherm (in het tabblad) wordt afgesloten 51 Bij wegam-polissen staan de verkeerde checklijsten 52 Bij rechtsbijstand collectief motorrijtuigen staan de verkeerde checklijsten (brand), er moet een verdeling op afdelingscode gedaan worden

Requirement fout

O O O O O


O O O O O

Requirement fout

O O O O O


O O O O O

Implementatie fout

O O O O O

Implementatie fout

O O O O O

Implementatie fout

O O O O O

Implementatie fout

O O O O O

Implementatie fout

O O O O O

Requirement fout

O O O O O


O O O O O

Wens

O O O O O

Implementatie fout

O O O O O

Implementatie fout

O O O O O

143


53 Dossierdata coll. rechtsbijstand moet gelijk zijn aan coll ongeval inzittende 54 Bij coll. Ongevallen inzitenden zijn geen checklijsten aanwezig 55 Dossierdata motorrijtuigen niet conform workshopoverleg 56 Bij checklijst aanmaken bij motorrijtuigen zijn die van transport niet relevant 57 In checklijsten is er geen mogelijkheid om dezelfde (repeterende) actie vast te leggen. Onderdelen onderzoek van schademelding t/m regres of verhaal zouden dus moeten repeteren 58 Checklijst wordt niet t automatisch gelinkt aan het polis- of schadedossier wat geselecteerd is. Aan de hand van de soort polis (beurs, provinciaal of volmacht) kan automatisch de juiste checklijst gestart worden 59 Bij het aanmaken van notities wordt niet automatisch het tijdstip vermeld 60 Bij tabblad processen worden geen tijdstippen vermeld, de processtappen worden ook niet chronologisch getoond 61 het aantal processen in het tabblad overzicht processen mag niet beperkt zijn. 62 De checklijst kan niet tegelijk met het dossier zichtbaar op het scherm worden getoond. De checklijst wordt automatisch gesloten wanneer er op een ander tabblad geklikt wordt 63 Na het starten van een actie in de checklijst (rappel, fiatteren enz.) na de actie ga is het veld omschrijving in de pop-up leeg, hierin zou standaard de beschrijving vanuit de checlijst gezet kunnen worden 64 Indien een checklijst uit meerdere pagina's bestaat, moeten per pagina wijzigingen worden opgeslagen en word je hierna uit de checklijst gegooid en moet je deze opnieuw opstarten

144

Implementatie fout

O O O O O

Implementatie fout

O O O O O

Requirement fout

O O O O O

Requirement fout

O O O O O

Wens

O O O O O

Requirement fout

O O O O O

Requirement fout

O O O O O


O O O O O

Implementatie fout

O O O O O


O O O O O

Requirement fout

O O O O O

Implementatie fout

O O O O O


65 In het logboek staan de regels niet op tijdsvolgorde 66 In de workshop was afgesproken dat er een beveiliging ingebouwd zou worden dat er bij het afwijzen of betalen van een schade verplicht gefiatteerd moet worden. Dit is niet het geval 67 Ondanks het opslaan van de checklijst, kan hierna gemuteerd worden. Tijdens de workshop is besproken dat dit (na een dag) niet meer mogelijk zou zijn 68 Bij sluiten van eerste zoekopdracht met de knop sluiten wordt heel SD afgesloten! Moet terug naar hoofdtabblad 69 Bij dossierdata op relatieniveau toevoegen: accountmanager, telefoonnummers rel. beh + accountm. Indien gekoppeld hoofdrelatienr naam neoemen, indien hoofdrelatie de gekoppelde klantnrs + naam noemen, de provisieopbrengst van de totale klant zichtbaar maken. Zie bevindingenformulier 70 Bij werklijst en dan item openen is de pop-up onduidelijk: Label en inhoud kunnen weg, bij proces verder doorsturen is niet duidelijk naar wie en graag volledige naam vermelden. Zie bevindingenformulier 71 In het overzicht van sub-dossiers, dient ook de branchecode getoond te worden. 72 Icoontjes in 1e regel + zoekactie worden niet grijs wanneer ze geselecteerd zijn 73 Wanneer je in een sub-dossier van het type offerte, dan zijn de aangemaakte checklists niet zichtbaar. Hiervoor moet je naar het tabblad gaan 74 Vraag voor opslaan checklijst bij sluiten is overbodig

Gebruikersvriendelijkh eid fout Requirement fout

O O O O O

Requirement fout

O O O O O

Implementatie fout

O O O O O

Requirement fout

O O O O O


O O O O O

Wens

O O O O O


O O O O O

Implementatie fout

O O O O O


O O O O O

O O O O O

145


75 Volgorde van iconen wijzigen: Klantbeeld, dossierdata, polissen, documenten, checklijst, schades, notities, processen, logboek, subdossiers 76 Het opslaan van informatie in een checklijst moet gaan via een knop opslaan en niet via icoon sluiten 77 Verschillende opmerkingen over dossierdata, zie bevindingenformulier 78 Nog niet alle dossierdata schermen zijn klaar of fout gekoppeld 79 In de checklijsten is het mogelijk om tegelijk een vinkje in nvt en klaar te zetten 80 Uniformiteit in benaming: tenaamstelling in tabblad, agendering moet werklijst worden 81 In werklijst kolommen toevoegen:

Misvatting

O O O O O


O O O O O

Requirement fout

O O O O O

Implementatie fout

O O O O O

Implementatie fout

O O O O O


O O O O O

Wens

O O O O O

Implementatie fout

O O O O O

Implementatie fout

O O O O O

Implementatie fout

O O O O O

Wens

O O O O O

Requirement fout

O O O O O

- naam klant (volledige relatienaam) - klantnr - extern polisnr of schadenr (voorbeeld opbouw schadenummer 507-07-10214 - verklaring opbouw schadenummer: medewerkernummer level7-jaar-volgnummer)

82 83 84 85

86

146

Kolommen eraf: - Deadline (is ook zichtbaar na dubbelklik op het item) - Tijd handeling Het scherm kan niet meer vastgezet worden zoals eerst het geval was Document eigenschappen pop-up moet er hetzelfde uitzien als nu Bij sub-dossiers op offerte na worden geen creators ingevuld Bij het bepalen van deadlines, dienen weekenden buiten beschouwing gelaten te worden Bij opstarten nieuwe offerte checklijst voor een prospect, kan deze pas gestart worden zodra relatie ingevoerd is. Dit is niet handig


87 In checklijst offerte ORV, OAV ontbreekt een tussenstap: voor offerte is gefiatteerd moet de keuze komen, offerte is ter fiattering aangeboden -> met doorsturen mogelijkheid 88 Bij het openen van een processtap die gestart is vanuit een checklijst, moet je bij het openen van het dossier direct in de checklijst terecht komen, als er op het proces twee fiatteringsacties openstaan, weet je ander niet voor welke die bedoeld is 89 Wanneer checklijst is afgewerkt is blijft deze zichtbaar, dit is voor het overzicht niet handig 90 Bij afsluiten en doorsturen checklijst en niet alle punten zijn gevuld (bv clientprofiel) dan graag pop-up dat niet alle velden zijn ingevuld 91 Iconen mogen wel iets kleiner 92 Er zitten geen checklijsten in Summum 93 Als je in een checklijst een vinkje zet en hem vervolgens weghaalt, dan blijven wel datum en behandelaar staan 94 Bij zoeken past naam niet in het tabblad 95 Kan de benaming van de checklijst in een ander lettertype en in wat vriendelijkere bewoordingen 96 Kan in de linkerkolom in de tabbladen de soort verz. Worden vermeld 97 Bij metadata van brand verschillende foutjes in dossierdata: tekstrisicoadres -> risicoadres, soortverzekering -> soort verzekering, bouwaardcode -> bouwaard, er staat clausulenummer, dit kunnen er meer zijn, voorwaarden ontbreken, data staan op amerikaanse wijze, verzekerdbedrag -> verzekerd bedrag

Requirement fout

O O O O O


O O O O O


O O O O O

Wens

O O O O O

Gebruikersvriendelijkh eid fout Implementatie fout

O O O O O

Implementatie fout

O O O O O


O O O O O

Requirement fout

O O O O O


O O O O O

O O O O O

O O O O O

147


98 Bij checklijst bvc_mutatie_brand_avb_beurs_zak. Een na laatste regel verwijderen en laatste regel moet worden: bevestiging naar klant gestuurd 99 Indien een document in SD dan worden gewijzigde gegevens niet opgeslagen, bij geeltje toevoegen en dan afsluiten krijg je de foutmelding: Run-time error 1178 unable to save specified image 100 Nummer polis in tabblad geeft verkeerde polis weer: K55810 geeft Prisma 166544 101 In klantbeeld niet alleen polisnummer maar ook productomschrijving en naam maatschappijen 102 Icoon "R" op tabblad dossierdata om terug te keren naar relatiedossier verfraaien (zie schermprint) 103 Bij dossierdata op relatieniveau maatschappij en type_product verwijderen en postcode toevoegen 104 Houdt niet vast naar wie iets is doorgestuurd 105 Geen pulldown menu nodig wanneer er maar een keuze is, is weer een muisklik mindern 106 2 personen kunnen gelijktuidig in zelfde checklijst, dit is niet wenselijk 107 in Logboek staat niet wat er is gedaan, door systeem automatisch, nu staat er bij elke actie test 108 Je kunt vanuit processen een stap afronden maar checklijst staat nog open. Dit is niet gewenst. Bij afronden in checklijst dan meteen uit agenda en procestabblad weg 109 In dossierdata van het schadedossier staat schadebehandelaar niet ingevuld en ontbreekt telefoonnummer 110 Toevoegen in dossierdata polisdossier: doorlopende provisie en tekencommissie 111 Verschillende data staan op de amerikaanse wijze

148

Requirement fout

O O O O O

Implementatie fout

O O O O O

Implementatie fout

O O O O O

Wens

O O O O O


O O O O O

Requirement fout

O O O O O

Misvatting

O O O O O


O O O O O

Requirement fout

O O O O O

Implementatie fout

O O O O O

Requirement fout

O O O O O

Implementatie fout

O O O O O

Requirement fout

O O O O O

Implementatie fout

O O O O O


112 Bij dossierdata in relatiedossier mist bankkantoorcode met daarbij de naam van het bankkantoor 113 In een checklijst is het mogelijk om tegelijkertijd naar verschillende personen dezelfde vervolgopdracht te versturen, dit is niet wenselijk omdat je dan met dubbel werk kunt komen te zitten 114 Dossierdata Particulier schade is niet volledig overgenomen uit de workshops 115 Er zijn geen persoonlijke werklijsten. Dit is onwerkbaar 116 Dossierdata is nauwelijks ingevuld 117 Eerste indruk is dat je dingen dubbel aan het doen bent. Je werkt vanaf je werklijst en vanuit daar kun je opdrachten doorsturen, maar ook vanuit de checklijst kun je opdrachten doorsturen. Dit werkt fouten in de hand ook omdat niet op de checklijst zichtbaar is wie die in behandeling heeft. Als je dus een werklijst item hebt afgerond, moet je ook nog de (eventuele) checklijst gaan zoeken om daar te gaan vinken of af te ronden. Dit is praktisch gewoon niet makkelijk 118 Bij het openen van een checklijst , krijg je alle checklijsten uit een bepaalde groep. De checklijsten zouden eigenlijk zichtbaar moeten zijn per productcode. Dit bespaart zoekwerk 119 Aangemaakte notities kunnen op dit moment niet verwijderd worden. Dit zou wel mogelijk moeten zijn. Het zou in ieder geval mogelijk moeten zijn om je eigen notities te verwijderen. 120 Checklijst controle RC staat onder relatie maar moet zijn maatschappijen 121 Logboek geeft te weinig info, bijvoorbeeld agenda afgeron/doorsturen of proces afgerond/doorsturen

Requirement fout

O O O O O

Requirement fout

O O O O O

Implementatie fout

O O O O O

Requirement fout

O O O O O

Requirement fout Requirement fout

O O O O O O O O O O

Requirement fout

O O O O O

wens

O O O O O

Requirement fout

O O O O O

Requirement fout

O O O O O

149


122 Checklijsten: betwiste factuur, voortzetting incasso prov en rc relatie missen 123 Na het aanmaken van de checklijst kan je de notitie niet meer aanpassen 124 Bij het toevoegen van een checklijst in een klachtdossier staan daar de verkeerde checklijsten 125 Bij afsluiten van het programma krijg je niet de vraag of je het zeker weet. 126 TR en MV voor checklijst zetten en geen MR. Transport rn motorrijtuigen hebben niks met elkaar te maken 127 Datum velden zijn te klein, niet hele datum wordt getoond. Op scherm staat 2-12-2007 terwijl de datum bij het groter maken van de kolom 1212-2007 blijkt te zijn. 128 Checklijst afhandelen individuele klacht is niet conform workshopverslag 129 Zie tabblad 136 130 Klantbeeld is niet op te roepen vanuit het klachtendossier - voorbeeld relatie 50211 131 Sub-dossier Klacht: Bij het aanmaken van een klachtendossier is er op dit moment geen mogelijkheid om een type klacht aan het dossier te koppelen. Net zoals dat bij subdossier Offerte is ingeregeld onderstaande type keuze mogelijkheden inregelen: - Schadebehandeling - Leven individueel - Leven collectief - Schade particulier - Schade zakelijk - Algemeen / overig Bij meerder klachten in het overzicht geeft dit een duidelijker beeld.

150

Implementatie fout

O O O O O

Implementatie fout

O O O O O

Implementatie fout

O O O O O

Wens

O O O O O

Requirement fout

O O O O O


O O O O O

Implementatie fout

O O O O O

Geen Implementatie fout

O O O O O O O O O O

Wens

O O O O O


132 De doorstuuracties in de checklijsten zijn (nog) niet conform workshopverslag ingericht. Een aantal doorstuuracties moeten naar "Fin. Adm. - Team Debiteuren". Dit is nog niet in de checklijsten automatisch opgenomen. 133 Bij doorstuur acties waarbij bekend is naar welke werklijst de actie moet worden doorgestuurd zou het erg praktisch zijn als daarvoor één enkele knop de functionaliteit geeft. Nu moeten daarvoor 3 muisklikken voor worden gegeven. 134 Het gebruik van de checklijst is toetsenbord onvriendelijk. Met de tabtoets is de verwachting dat er logisch door het formulier kan worden getabt. Helaas werkt dat niet zo. Met name bij de vinkjes kun je niet zien waar je zit met de cursor. Verwachting is dat het aan te vinken viekantje omlijst wordt met een kader. 135 Opdrachten verzonden vanuit een checklijst worden als processtappen vertaald naar het tabblad processen. Er is nu geen duidelijk zicht op de status van een "doorgestuurde" opdracht. Binnen het tabblad processen zie je uitsluitend de uitgevoerde processen door wie op welke datum uitgevoerd en bij wie in behandeling. 136 Wat zijn de ideen omtrent Man. Info.? Op welke manier wordt dit in Fase 1 uitgewerkt? Wordt dit uberhaupt wel in Fase 1 uitgewerkt? Welke akties worden er genomen om de workflow te monitoren en te managen? Doorlooptijden, tijdig afwerken van werklijst-items e.d.. Controle op onafgewerkte / onvoltooide checklijsten (status).

Implementatie fout

O O O O O


O O O O O


O O O O O

Requirement fout

O O O O O

Geen

O O O O O

151


137 Zoals de checklijsten nu zijn ingericht kan eenieder alle checklijsten inzien en bewerken. Inzien is geen probleem. Voor het kunnen bewerken van een checklijst zou men "geautoriseerd" moeten zijn. Met name financiele checklijsten zouden uitsluitend door geautoriseerde medewerkers bewerkt mogen worden. M.a.w. medewerkers die geautoriseerd zijn voor dat specifieke proces. 138 aanpassing checklijst betwiste factuur. - stap 7 factuur gedeeltelijk betwist => doorstuur actie weghalen. Er moeten 2 stappen onder stap 7 worden toegevoegd met aanvink mogelijkheid. Stap 7a en 7b. - betwiste factuur => doorsturen => Ga - onbetwiste factuur => doorsturen => Ga Zie voor deze laatste stap bevinding nr 142 139 checklijsten niet uniform bij de benaming van de processtappen. Soms wordt er wel een afdeling vermeld soms niet. 140 Checklijst poliscontrole voor pensioen en leven. Bij processtap fiatteren default de juiste fiatteursgroep adresseren. 141 checklijst Polis-aanvraag-pensioenleven. Onderdeel: klant heeft niet geaccepteerd of aanvraag……. Het laaste deel van de tekst is weggevallen en deze volledige regel hoort boven het onderdeel te staan op de tweede pagina van de checklijst.

152

Requirement fout

O O O O O

Requirement fout

O O O O O

Requirement fout

O O O O O

Requirement fout

O O O O O


O O O O O


142 checklijst Polis-aanvraag-pensioenleven. Onderdeel: tegenvoorstel van de maatschappij. Volgorde klopt niet. Nieuwe volgorde moet worden: 3, 4, 1*,2,5,6

Requirement fout

O O O O O


O O O O O

Implementatie fout

O O O O O


O O O O O

Requirement fout

O O O O O

Bij openen sub-dossier geen keuzemogelijkheid product "Leven" 147 ckecklijst offerte ORV, AOV, etc

Requirement fout

O O O O O

"offerte ter fiattering aanbieden" deze processtap moet er nog tussen komen. 148 Offerte fiatteren werkt niet

Requirement fout

O O O O O

143

144

145

146

* De tekst moet aangepast worden in: Tegenvoorstel mag naar relatie <doorsturen> In de checklijst kan een omschrijving worden meegegeven. Deze omschrijving dient met een knop te worden opgeslagen. Beter zou zijn om deze knop te laten vervallen en dat bij het sluiten van de checklijst alle (gewijzigde) gegevens (vinkjes, notities e.d.) automatisch worden opgeslagen. checklijst Polis-aanvraag Onderdeel: medische keuring regelen, aanvrager is geinformeerd over datum, dan kun je kiezen bij "ga verder met" uit twee keer "email". Dit moet er uiteraard één keer zijn. Dit gebeurd bij meerdere "ga verder met" processen. Bij het maken van een rappel moet je eerst kiezen voor "doorsturen naar" Ik denk dat je deze keuze hier niet hoeft te maken anders kies je in eerste instantie wel voor doorsturen i.p.v. rappel. Ontbrekende items bij kiezen offertevorm: -Leven -Pensioen -AOV

153


149 Voorbeeld werking checklijst nu. In een checklijst is agendering gestart. Datum agenda wordt twee weken verder gezet. Echter de gevraagde stukken komen eerder (binnen een week binnen). We gaan door met de checklijst. In de checklijst ziet de gebruiker niet dat er een agenda in de toekomst op zit. Deze agenda zou eigenlijk, met het vervolg van de processen via de checklijst, (vervolg vinkjes zetten) automatisch verwijderd (afgerond) moeten worden. Ook de daarbij behorende processtap zou hiermee automatisch afgerond moeten worden. 150 checklijst offertes orv, aov etc Aanvrager is geinformeerd => Keuze <doorsturen> moet volgens ons <email> zijn. 151 Als een checklijst niet compleet is afgevinkt kun je de checklijst toch als afgehandeld markeren en afsluiten. Daarna is de checklijst niet meer te bewerken. Er zou eigenlijk een controle/melding op moeten komen. "U wilt de checklijst afhandelen. U heeft niet alle processen afgewerkt. U kunt pas kiezen voor afhandelen als alle processtappen zijn verwerkt" => vervolgens een keuzeknop . De checklijst wordt hierdoor niet afgehandeld en keert de gebruiker terug naar de checklijst.

154

Wens

O O O O O

Requirement fout

O O O O O

Requirement fout

O O O O O


152 Intermediairswijziging. Verzoek m.b.t. hele nieuwe relatie komt binnen bij relatiebeheer leven. Het proces via Slim Dossier kan nog niet worden opgestart omdat er nog geen relatie/polis gegevens in Level7 en dus ook niet in Slim Dossier aanwezig is. Hoe nu te handelen? Nu worden de stukken digitaal via octopus doorgestuurd naar Operations (na controle) en die zorgen ervoor dat de relatie in Level7 wordt ingevoerd. In de gewijzigde processen fase 1 zou dat niet meer kunnen, want het proces moet door relatiebeheer worden opgestart. 153 Intermediairswijziging. Relatie is al wel ingevoerd en via Slim Dossier beschikbaar. Toch kan er geen checklijst worden geopend want er moet eerst een polis worden ingevoerd. Dit is niet werkbaar. Oplossing kan zijn om een checklijst intermediairswijziging zowel op relatieniveau (als er nog geen polis is ingevoerd) als ook op polisniveau (als de polis al wel is ingevoerd) beschikbaar te stellen. 154 In checklijst exp. pensioen/lijfrente Onderdeel: nieuwe offerte traject Klant: aanvullende info gevraagd hoort niet in offerte traject, maar in het bovenstaande onderdeel. 155 Bij een rappel of doorsturen twee extra keuzemogelijkheden naast afronden en doorsturen: - Dossier aanhouden - Ter behandeling 156 Offerte types toevoegen: - Leven Collectief - Leven Individueel 157 Scherm Slim Dossier moet men kunnen verkleinen / vergroten. Dit kan nu niet.

Misvatting

O O O O O

Misvatting

O O O O O

Requirement fout

O O O O O

Wens

O O O O O

Wens

O O O O O


O O O O O

155


158 Na moet de checklijst automatisch worden afgesloten. Nu blijft de checklijst openstaan en kan het gebeuren dat een gebruiker denkt dat de vervolgactie nog niet is verzonden. Er wordt wellicht door gebruiker onterecht nog een actie uitgevoerd waardoor er meerdere werklijst-items ontstaan. 159 checklijst servicecontract collectief - achter AM is geinformeerd (2e stap) niet maar <email> - achter "specialist heeft voorstel opgemaakt" <doorsturen> toevoegen - achter "klant is schriftelijk geinformeerd aangepast" - achter "origineel service contract en vw zijn getekend ontvangen" <doorsturen> (naar specialist) 160 checklijst - polis verlengen bij collectief pensioen - 1e stap opzegging is beoordeeld moet zijn <doorsturen> - 2e stap contract is opgezegd toevoegen - stap toevoegen tussen contract is opgezegd / offerte traject => "bevestiging opzegging van maatschappij ontvangen". Omschrijving van deze processtap is een controle ter voorkoming "kwijtraking opzegging" bij de maatschappij. - bij verlengingsvoorstel is akkoord bevonden en het verlengingsvoorstel is niet akkoord ook de mogelijkheid <email> aan collega te sturen. - laatste stap "verlenging akkoord polis muteren" voor stap "verlenging is doorgevoerd in level-7" - als laatste toevoegen "royement is gefiatteerd"

156

Wens

O O O O O

Requirement fout

O O O O O

Requirement fout

O O O O O


161 Bij checklijst is bij stap "klant niet akkoord voorstel (b.v. polis verlengen bij collectief pensioen) opm zie notitie toegevoegd! Wederom meerdere stappen. Afspraak was dat er een pulldown kwam met (door Menno v.d. Weide) vastgestelde redenen van niet doorgaan offerte. 162 In de worshopverslagen in de beschrijving van de checklijsten is bij elke stap een uitgebreide omschrijving opgenomen waaruit blijkt wat de processtap behelst. Deze uitgebreide omschrijving is in het systeem nergens terug te vinden. Gaarne toevoegen middels een schermpje als je de muis erover beweegt (tooltip) of informatieicoontje waarop je kunt klikken 163 Systeem zoals nu gebouwd is niet conform verwachtingen. Verwacht was dat je door processen geleid wordt. Nu worden agenda's niet automatisch afgelegd als je volgende stap in de checklijst opstart. Krijgt dan administratie extra om gelijk af te stemmen met je werkzaamheden. Risico dat er veel tijd wordt gebruikt om zaken te corrigeren (extra aangemaakte werkopdrachten / agenda's die niet afgelegd worden. 164 in sub-dossier - offerte kun je wijziging één keer toepassen. Nog een keer wijzigen (en opslaan) is niet meer mogelijk. 165 checklijst poliscontrole collectief provinciaal bij vinkje "eerste bewijs is gecontroleerd door specialist" kan de actie eruit.

Implementatie fout

O O O O O

Wens

O O O O O

Requirement fout

O O O O O

Implementatie fout

O O O O O

Requirement fout

O O O O O

157


166 In de test zijn bij Operations Leven een aantal opdrachten geplaatst vanuit een checklijst. Bij het openen van een willekeurige werklijst-item en vervolgens "open dossier" wordt er een foutmelding "basic 4 message……" gegeven en kan het dossier niet worden geopend. (schermprints bij functioneel beheer aanwezig) 167 Bij dossierdata ontbreekt de "kantoornaam" (=FvL bankkantoor) 168 checklijst polis muteren uitdiensttreding - de stap "prolongatieteam wordt geinformeerd" kan eruit. I.v.m. nieuwe pensioenwet is er geen tp incasso meer. 169 bij opstarten van diverse processen (t.b.v. werklijst) zijn de datumvelden bij foutief invoeren niet te wijzigen door gebruikt te maken van de delete knop of de backspace knop. Dit zou echter wel zo moeten werken. 170 als je een checklijst of nieuw proces doorzend, hoe weet iemand dan wat hij moet doen? De documentatie zit niet gekoppeld aan de checklijst/proces en is hier ook niet aan te koppelen, dus moet je in het dossier gaan zoeken naar de bijbehorende documentatie/opdracht. Dit is tijdrovend en onwenselijk. 171 In checklijst coulance moet de uitkering is gefiatteerd en vrijgegeven vervangen worden door de uitkering is gefiatteerd 172 In regres nemen/rappel moet omschrijving rappel worden: rappel tegenpartij / tegenassuradeur 173 In checklijst VAS Expert, omschrijving moet zijn rappel expert 174 In checklijst VAS Volmachtgever, omschrijving moet zijn rappel volmachtgever 175 Client afwijkend banknummer, omschrijving rappel client

158

Implementatie fout

O O O O O

Implementatie fout

O O O O O

Requirement fout

O O O O O


O O O O O

Wens

O O O O O

Requirement fout

O O O O O

Requirement fout

O O O O O

Requirement fout

O O O O O

Requirement fout

O O O O O

Requirement fout

O O O O O


176 In checklijst coulance toegewezen manager, omschrijving coulanceverzoek 177 In checklijst afhandeling schade provinciaal kopie afwijziging naar account manager/relatiebeheerder wijzigen in afwijzing 178 Checklijsten volmacht/beurs/provinciaal stap betalingsopdracht vrijgen kan eruit 179 Notities niet apart zetten maar bij correspondentie. Ook moet de mogelijkheid er zijn om meteen een proces op te starten 180 Op checklijsten volmacht/prov/beurs na registreren in Level 7 de mogelijkheid doorsturen, 1440, medewerker schadebehandeling 181 Op checklijsten volmacht/prov/beurs na behandelaar toewijzen de deadline veranderen in 2880 182 Metadata is niet volledig 183 Bij opstarten van een rappel, standaar de medeweker invullen dit het rappel aanmaakt 184 Wanneer je meteen op Ga klikt krijg je een foutmelding terwijl er al wel een proces in de keuze staat. Je krijgt dan de foutmelding: Selecteer een proces 185 Wanneer het laatste vinkje in de checklijst gezet is, kan hij op afgehandeld gezet worden. Dan hoeft dit niet handmatig te gebeuren 186 Bij invoer van een datum die niet bestaat b.v. 30-02 geeft het systeem een onbegrijpelijke foutmelding 187 Als de totaalknop NVT wordt aangeklikt, blijven in status de vinkjes gewoon staan. Er staan dan dus twee vinkjes per regel 188 Procesbeschrijving maken: Relatie: Checklijst is afgehandeld als alle identificatiegegevens aanwezig zijn 189 Actie afgerond verwijderen

Requirement fout

O O O O O

Requirement fout

O O O O O

Requirement fout

O O O O O

Requirement fout

O O O O O

Requirement fout

O O O O O

Requirement fout

O O O O O

Implementatie fout Gebruikersvriendelijkh eid fout

O O O O O O O O O O

Implementatie fout

O O O O O

Misvatting

O O O O O

Implementatie fout

O O O O O

Implementatie fout

O O O O O

Wens

O O O O O

Requirement fout

O O O O O

159


190 Checklijst aanpassen, wat is het verschil tussen klantgegevens zijn invgevoerd en klantgegevens zijn correct ingevoerd. Svp laatste optie wijzigen in klantgegevens zijn compleet of gewoon weglaten 191 Als alle vinkjes zijn geplaatst dan niet meer laten zien. Actie is dan volledig afgewerkt 192 Omschrijving checklijst identificatie aanpassen: uittrekesel moet uittreksel zijn 193 Checklijst ps_mt_invoeren_klant en gp_identificatie_klant samenvoegen 194 In checklijst "notitie" wijzigen in omschrijving checklijst oid, elke keer notitie is verwarrend 195 Wanneer je in een checklijst zit en je wil de correspondentie bekijken en je gaat weer terug, is de checklijst weer afgesloten. Checklijst moet open blijven staan 196 Opslaan knop in de checklijsten is verwarrend. Deze geldt alleen maar voor de notitie en actief/afgesloten. Dit is niet logisch 197 Functionaliteit uitbreiden met openstaande offertes, klachten, spelen er contractverlengingen etc 198 Waarom toestaan dat vanuit processen een brief aangemaakt kan worden? Dit mag alleen maar vanuit checklijst 199 Klachtknop + subdossiers uit elkaar halen. Altijd icoon subdossiers laten staan. Klacht gewoon ernaast zetten 200 Mogelijkheid om checklijsten te heropenen (op schade gebeurd dit nog wel eens) 201 Afgeronde processen niet meer standaard laten zien maar zichtbaar maken dmv knop 202 Popup schermen bij het aanmaken van nieuwe checklijsten in het Slim Dossier venster laten opkomen. Gebeurd nu erbuiten 203 Bezoekrapport toevoegen aan type documentenlijst in Slim Dossier

160


O O O O O


O O O O O

Implementatie fout

O O O O O

Requirement fout

O O O O O


O O O O O


O O O O O

Misvatting

O O O O O

Wens

O O O O O

Requirement fout

O O O O O

Wens

O O O O O

Requirement fout

O O O O O


O O O O O

Implementatie fout

O O O O O

Wens

O O O O O


204 Benamingen van de checklijsten aanpassen. In de benaming de afdeling noemen die de checklijst als eerste zal oppakken (wellicht FO MO BO) 205 Zie tabblad 227 206 Het is noodzakelijk dat aan de checklijst de onderliggende ingescande documenten gelinkt kunnen worden. Het is met een werkvoorraad van enkele honderden mutaties ondoenlijk om bij elke opdracht naar de onderliggende stukken te gaan zoeken. Ook als je later een keer terugvalt op een oude mutatie/checklijst is het niet meer te achterhalen welke checklijst bij welke documenten horen. 207 Checklijst BVC offerte BCA provinciaal zakelijk

Wens

O O O O O

Requirement fout Wens

O O O O O O O O O O

Requirement fout

O O O O O

Requirement fout

O O O O O

4e hokje Openingsbalans bij starten wijzigen in Openingsbalans 8e en 10e hokje het woord "aanwezig" verwijderen. Uittreksel Kvk is aanwezig Organogram is aanwezig 9e hokje jaarverslag wijzigen in meest recente jaarverslag 208 Checklijst: Intermediairwijziging inkomend voor volmacht- particulier Onderdeel: Bij een meer-jarig contract - Polis is afgekocht voor een bedrag tussen 250 en ? Euro - Polis is afgekocht voor bedrag hoger dan ? euro * vraagteken moet worden € 500,00

161


209 Checklijst: Royement Volmacht Onderdeel: Royement verwerken - Op termijn royeren (of royeer per direct) Deze processtap splitsen in twee processtappen - Op termijn royeren + - Royeren per direct + 210 Checklijst: Portefeuille analyse particulier Deze checklijst in sub-dossier offerte plaatsen. Zo komt deze meer tot zijn recht. 211 Checklijst: Portefeuille analyse particulier (168)

Requirement fout

O O O O O

Requirement fout

O O O O O

Requirement fout

O O O O O

Requirement fout

O O O O O


O O O O O

Requirement fout

O O O O O

Checklijst termijn en deadline zijn vaak gelijk. Dit klopt niet en moet worden aangepast. Termijn: dezelfde dag Deadline: 7 dagen later 212 Checklijst: Portefeuille analyse particulier Onderdeel: Organiseren Na processtap "Private banker is geinformeerd over advies" toevoegen: "Contactpersoon aanvraag is geinformeerd" + 30 dagen om zodoende een maand later er aan te kunnen herinneren als stukken nog niet retour zijn. 213 Bij het afsluiten van een dossier kom je in het bovenliggende dossier altijd terecht in hetzelfde tabblad terecht waar het oude dossier in is afgesloten. Dit zou afhankelijk van de afdeling polis of schade moeten zijn 214 Checklist offertes ontbreekt op relatieniveau moet hier ook staan alsmede op polisniveau

162


215 Bij openen checklijst alleen de onderdelen zichtbaar maken en mogelijkheid geven deze per onderdeel separaat te openen 216 Maar één checklijst offerte met daarin de keuze naar branche, daarna naar soort (volmacht/prov/beurs) zodat de checklijst geopend kan worden met alleen de relevante vragen. (belastingdienst) 217 Checklijst offerte_brand_beurs_zakelijk bij onderdeel "offerte is goedgekeurd" 4e blok bevestiging naar klant verwijderen, 5e blokje mutatie formulier is één woord. Onderdeel "offerte is afgekeurd" optie doorsturen toevoegen. Dit geld voor alle offertes varia 218 Checklijst offerte_avb_beurs_zakelijk onderdeel "inventarisatie en offerte" drop down box uitbreiden met doorsturen (allemaal) 219 Checklijst offerte_avb_beurs_zakelijk en offerte_brand_beurs_zakelijk in onderdeel "offerete" wijziging tekst: offerte is aangegaan in offerte(s) zijn binnen 220 Checklijst offerte_avb_beurs_zakelijk onderdeel "offeret is goedgekeurd" wijziging tekst offerte is getekend ontvangen in offerte is door klant getekend. Dit geld ook voor offerte_brand_beurs en CAR 221 legitimatie is aanwezig verwijderen uit alle checklijsten 222 Allebei de sluitnota vermeldingen verwijderen op alle checklijsten 223 Bij onderdeel offerte is afgekeurd. De drie mogelijkheden in een dropdown box zetten 224 Naam bvc_offerte_brand_varia_provianciaal _zakelijk wijzigen in bvc_offerte_brand_varia_provinciaal_ zakelijk

Wens

O O O O O

Wens

O O O O O

Requirement fout

O O O O O

Requirement fout

O O O O O

Requirement fout

O O O O O

Requirement fout

O O O O O

Requirement fout

O O O O O

Requirement fout

O O O O O

Wens

O O O O O

Implementatie fout

O O O O O

163


225 Naam bvc_offerte_varia_ba_provianciaal wijzigen in provinciaal 226 Checklijst bvc_offerte_varia_ba_provinciaal, 4e hokje jaarverslag laatste 2 jaar wijzigen in meest recente jaarverslag, 9e hokje: cv is aanwezig wijzigen in cv 227 Checklijst bvc_offerte_varia_ba_provinciaal onderdeel "verwerken offerte" wijzigen in "Offerte" 228 Checklijst bvc_offerte_varia_ba_provinciaal onderdeel "Offerte" 1e blokje tekst wijzigen in assuradeuren zijn benaderd, toevoegen aanvullende informatie is bij klant opgevraagd, 3e blokje offertes zijn ontvangen in offerte(s) is/zijn binnen, 4e blokje tekst wijzigen in offerte is uitgebracht 229 In het klantbeeld zijn alle modules van summum te zien. Dit is niet erg handig. Kunnen deze als subs van het de hoofdpolis getoond worden? 230 Kan in het offerte-dossier een summum dossier toegevoegd worden 231 In subdossier offerte de naam PS_Schadebehandeling_particulier wijzigen in PS_Schadeverzekering_particulier om verwarring met de afdeling schadeafhandeling te voorkomen 232 Bij offerte schadeverzekering particulier private banker is geinformeerd wijzigen in private banker en/of api is geinformeerd en achter deze regel een rappel toevoegen van een maand 233 Bij checklijst Invoeren klant kunnen stap 1 en 2 niet gevinkt worden voordat de relatie is ingevoerd, eventueel weglaten en starten met relatiegegevens zijn ingevoerd

164

Implementatie fout

O O O O O

Requirement fout

O O O O O

Requirement fout

O O O O O

Requirement fout

O O O O O

Implementatie fout

O O O O O

Wens

O O O O O

Misvatting

O O O O O

Requirement fout

O O O O O

Requirement fout

O O O O O


234 Checklijst intermediairswijziging hoort op relatieniveau omdat de polis nog niet is ingevoerd. Kopie polis komt binnen bij relatiebeheer en deze maakt een checklijst aan voor operations om de polis intermediar te wijzigen 235 Checklijst intermediairswijziging regel polis is doorgehaald door relatiebeheer wijzigen in polis wordt doorgehaald door volmachtgever 236 Checklijst portefuille_analyse_particulier bij regel private banker rappel toevoegen 237 Afsluiten van dossiers in het tabblad met rechtermuisknop mogelijk maken ipv alleen met archiefkast 238 Checklijst intermediairswijziging inkomend voor volmacht herschrijven in eenjarig of meerjarig ipv 100% volmacht of pool 239 In checklijst intermediairswijziging inkomend voor beurs na makelaarsverklaring is ontvangen toevoegen: oude makelaar is geinformeerd 240 In checklijst certificaat afgeven, laten vervallen: er is geen dekking op de polis,bij regel er is dekking op de polis doorstuuractie toevoegen naar Specialisten Transport, in de checklijst excellijst vervangen door orderboek 241 In checklijst Continuatie wagenpark offerteer vervangen voor leader. Bij onderdeel Voorstel verwerken toevoegen aangepast wagenparkblad naar functioneel beheer voor inregeling nieuwe contractgegevens 242 In checklijst Naverrekening provinciaal Verwijderen gedeelte brief met consequenties en rappel openemen bij eerste punt

Requirement fout

O O O O O

Requirement fout

O O O O O

Requirement fout

O O O O O

Wens

O O O O O

Requirement fout

O O O O O

Requirement fout

O O O O O

Requirement fout

O O O O O

Requirement fout

O O O O O

Requirement fout

O O O O O

165


243 In checklijst naverrekening goederentransport volmacht: Opnemen rappel bij kopje naverrekening bij klant 244 Discussiepunt: Bij checklijst naverrekening goederentransport volmacht: Opnemen als gegevens van klant zijn ontvangen naar relatiebeheer voor controle 245 In checklijst Polis opmaak motorrijtuigen volmacht klopt kop verwerking aanhangsel maatschappij niet. Wijzigen: Aanvraagformulier is correct ontvangen in is volledig ingevuld en ondertekend ontvangen 246 Documenten moeten vanuit een offertedossier in een polisdossier te slepen zijn 247 In checklijst polis opmaak transport beurs bij in kop onderdeel: invoeren polis / wijzgigen polis toevoegen 248 Bij het toevoegen van eenzelfde checklijst als al aanwezig dan koppelt hij de oude checklijst. Je krijgt dan dus een deels ingevulde lijst 249 Checklijsten zz_naverrekening zijn allemaal leeg 250 Bij het starten van een proces in de checklijst wordt als datum 1900 neergezet en geen gebruiker 251 In checklijst is de dropdownbox te klein voor het woord afgehandeld 252 Als een medewerker een werklijst item door wil zetten (doorsturen rappel / doorsturen fiatteren etc.) dan moet de waterval methode worden gebruikt om het werklijst item opnieuw te adresseren. Eerst moet gekozen worden voor afdeling - dit gaat goed. Daarna moet worden gekozen voor subafdeling - daar gaat het fout. Bij de tweede stap, als een keuze is gemaakt, klapt de systeem automatisch terug naar het overzichtscherm van de werklijst. Het werklijst item kan niet worden doorgezet naar een andere afdeling/subafdeling of medewerker.

166

Requirement fout

O O O O O

Requirement fout

O O O O O

Requirement fout

O O O O O

Wens

O O O O O

Requirement fout

O O O O O

Implementatie fout

O O O O O

Implementatie fout

O O O O O

Implementatie fout

O O O O O


O O O O O O O O O O


253 Wanneer in een checklijst de regel dossier afgelegd een vinkje zet, zou de checlijst eigenlijk automatisch afgehandeld kunnen worden (wordt dus een rode regel). 254 Checklijst niet te verwijderen indien per ongeluk een verkeerde aangemaakt is 255 Checklijst intermediairswijziging uitgaand niet benaderbaar op polisniveau. Dit is wel noodzakelijk 256 Het schermpje notitie is VEEL te klein. Als we hier een tekst in willen zetten zoals in levelagenda dan is het heel erg klein om te lezen 257 Het scherm van de werklijst is HELAAS niet groter te maken waardoor de kolommen heel smal zijn. Je kunt zo alleen maar verbreden via de muis (constant) 258 Niet blij met feit dat bij afsluiten checklijst, processen/doorstuuracties niet automatisch worden afgesloten OF dat er een waarschuwing komt bij aflsuiten checklijst 259 Is er gedacht aan aanlevering management info? Ik wil weten wat er aan werk op afdeling ligt en hoe verdeelt over medewerkers. Wat vervalt er vervolgens deze week zodat werk herverdeelt kan worden 260 Bij klantbeeld krijg je een klein schermpje links wat je alleen met muisslepen kan vergroten. Gaarne een maximaliseer-knop rechtsboven (zoals in windows). Houdt hij de instelling vast als je hem opnieuw opent? 261 Systeem is zeer traag, je ziet het scherm opgebouwd worden. 262 Bij relatiebeheerder staat naam AM in dossierdatascherm, deze naamgeving is dus niet juist. Zie klant 141392 263 Documenten zijn niet te openen 264 Wanneer vind afstemming plaats over "wat/waar" in systeem wordt ingevuld.


O O O O O

Requirement fout

O O O O O

Requirement fout

O O O O O


O O O O O


O O O O O

Wens

O O O O O

Geen

O O O O O

Wens

O O O O O

Geen

O O O O O

Implementatie fout

O O O O O

Geen Misvatting

O O O O O O O O O O

167


265 Als je een checklijst wil afhandelen, moet je als bevestiging op de knop "Terug naar overzicht" klikken. Dit is niet logisch. 266 Rappel wordt meteen afgerond en dus niet zichtbaar in de werklijst als je eerst een vinkje zet en dan een rappel. Dit moet wel mogelijk zijn 267 Het scherm van de werklijsten zou je groeter moeten kunnen maken 268 Als paperclip niet werkt, al een hele goede uniforme werkbeschrijving moeten komen om duidelijk te maken welke documenten bij welke checklijst hoort 269 Hoe om te gaan met rappellen. Onze checklijsten zijn nu opgemaakt met vinken en daarna rappel maken. Dat gaat nu niet 270 In SlimDossier kun je op bepaalde vensters (waar wel een scrollbalk verschijnt) niet met het scrollwieltje scrollen. Je moet dit dan doen met de muisklik, dat is niet altijd even pretiig werken. 271 Het is mogelijk om handmatig een proces toe te voegen (rappel enz.) binnen de subdossiers: offerte-, certificaten-, klachten-, naverrekenen- en portefeuilledossier. Bij het niet invoeren van het pop-up scherm en direct OK geven worden een gebruikers-onvriendelijke foutmelding gegenereerd. Zorg dragen dat er een nette foutmelding verschijnt. 272 Dit is een aanvullend verzoek voor de aanmaak van checklisten. Op verzoek van Nico stuur ik dit verhaal aan jullie door voor verdere verwerking. 273 Als Octopus open staat en je sluit Slim Dossier, dan kun je Slim Dossier inet meer openen omdat Octopus nog open staan

168

Misvatting

O O O O O

Requirement fout

O O O O O

Gebruikersvriendelijkh eid fout Geen

O O O O O

Requirement fout

O O O O O


O O O O O

Implementatie fout

O O O O O

Geen

O O O O O

Implementatie fout

O O O O O

O O O O O


274 Bij doorsturen naar altijd dezelfde afdeling staat deze niet standaard gemeld. Maar heb je de keuze uit alle afdelingen 275 checklijst 119, fiattering rentevergoeding mag alleen geaccordeerd worden door directie 276 Relatiebeheerder en accountmanagers zien graag alle checklijsten welke openstaan in 1 scherm. En niet zoals nu los in alle verschillende dossiers 277 Checklijst 128 niet hele tekst zichtbaar 278 Bij meerdere tabs open en de eerste wordt afgesloten dan sluit de hele applicatie 279 Het rappelsysteem werkt onlogisch. Wanneer bijvoorbeeld een aanvraagformulier wordt verzonden, dan kan hier een rappel aangehangen worden. Omdat deze stap is afgerond, zou je deze afvinken. Wanneer dit echter wordt gedaan, vervalt de rappel! Het systeem denkt op dat moment dat deze niet meer nodig is. Deze werking van het systeem gaat geheid voor problemen zorgen. Ik ben bang dat er veel rappel verloren zullen gaan. Je moet er op bedacht zijn om de afgewerkte stap, niet af te vinken. Deze kan nu pas afgevinkt worden wanneer, in mijn voorbeeld, de reactie van de maatschappij is ontvangen. Op dat moment vink je ook de stap af inzake de ontvangst van de reactie van de maatschappij. Ofwel 2 vinken in één keer. Logischer is dat de rappel gaat lopen op het moment dat de stap van verzenden is afgevinkt en de rappel eruit gaat na afvinken van de stap ontvangen van de reactie;


O O O O O

Requirement fout

O O O O O

Wens

O O O O O


O O O O O

Requirement fout

O O O O O

O O O O O

169


280 Op diverse plaatsen wordt in de tekst gesproken over de mogelijkheid om opmerkingen in te voeren. Dit is echter niet mogelijk. Dit is een gewenste optie voor de toekomst. 281 Bij het opstarten van een proces vanuit alle checklijsten schadebehandeling: Doorsturen/fiatteren/rappel moet standaard worden gevuld met Afdeling: Schadebehandeling, Subafdeling -- (of sub afdeling al vervangen door tabel medewerkers). Voor Schadebehandelaars: Bij aanmaken proces "Rappel" standaard vullen met de medewerker die de rappel aanmaakt. PS wel de mogelijkheid "wijzigen" behouden. 282 Bij het opstarten van een proces "fiatteren" het omschrijvingsvak vergroten, omschrijving niet geheel leesbaar. 283 Proces "e-mail". Zodra het proces "email" wordt opgestart wordt de verzonden e-mail meteen in het juiste dossier in SlimDossier opgeslagen? 284 checklijst 172 Bij "wachtuitkering aanmaken in Level-7" is er geen proces aanwezig. Moet zijn "Level-7" 285 voorbeeld schadedossier 07-10669 (AVB Beurs) - clausuleteksten niet compleet en niet volledig leesbaar - eigen risico staat ten ontrechte op 0,00 - voorwaarden niet vermeld => streepjes?? 286 voorbeeld schadedossier 07-10669 (AVB Beurs) Naam medewerker niet volledig zichtbaar in het SlimDossier venster (bovenin venster, in rood weergegeven aanvullende gegevens) 287 voorbeeld schadedossier 07-10669 (AVB Beurs) Het logboek is ondanks diverse acties leeg ???

170

Wens

O O O O O


O O O O O


O O O O O

Misvatting

O O O O O

Requirement fout

O O O O O

Implementatie fout

O O O O O


O O O O O

Implementatie fout

O O O O O


288 Ook zou het handig zijn wanneer er de mogelijkheid zou zijn om een of meerdere notities te koppelen aan een checklist. Daarin kan bijv. een toelichting gegeven worden, een overzicht worden gegeven van de maatschappijen waar offertes worden opgevraagd, welke offertes binnen zijn, welke aanvullende info is opgevraagd. Kortom, alles wat niet in een vaste vorm gegoten kan worden. 289 Als ik een nieuwe checklist aan heb gemaakt, maar die niet meteen kan afwerken of kan doorsturen, zou deze naar mijn mening in mijn werklijst moeten komen te staan. Net zoals checklisten die ik in de rappel heb gezet of die naar mij zijn doorgestuurd. Helaas is dat nu niet het geval: de checklist zweeft min of meer. De enige manier om de checklist terug te vinden is op polis- of relatieniveau te gaan zoeken, en dat is niet handig/logisch. 290 Checklist 175 Offerte CO, Zkn, WIA, Zgeld. Stap 1 is 'identificeren van de klant (KvK)' Die suggestie is 100% zeker niet van mij afkomstig. Het is mij dan ook geheel onduidelijk wat deze stap inhoudt. Graag nadere info. 291 Het woordjes "status" bij de checklisten vervangen door "gereed" 292 offertedossier automatisch middels knop o.i.d. te laten overzetten naar de afgesloten polis 293 Kleur afgehandelde checklijst onlogisch waarom niet groen zoals bij processen? 294 Bij opvragen polis de toekomstige agenda's tonen, zodat hier rekening mee gehouden kan worden (in L7 is dit nu ook). 295 Rode items zijn niet meteen door te sturen omdat je de melding krijgt dat de deadline in het verleden ligt.

Wens

O O O O O

Requirement fout

O O O O O

Misvatting

O O O O O

Gebruikersvriendelijkh eid fout Wens

O O O O O


O O O O O

Wens

O O O O O

Implementatie fout

O O O O O

O O O O O

171


296 In werklijst op meerdere kolommen kunnen selecteren 297 Het moet mogelijk worden om eenvoudig een omschrijving in de werklijst aan te passen 298 Na het doorsturen van een werklijstitem, wordt de werklijst zelf niet ververst waardoor de oude datum blijft staan 299 Vasthouden van de kolom breedtes 300 Toevoegen van Sub-dossier Wagenpark 301 Mogelijk heid tot het verwijderen van notities. 302 Alleen lopende processen laten zien. Afgesloten processen zichtbaar maken met vinkje 303 Bij het afsluiten van de relatie, ook meteen alle polissen afsluiten 304 Notitieveld bij checklijst is te klein 305 Op werklijst contractnummer toevoegen 306 In werklijst moet je meerdere letters in kunnen tikken zodat je niet alles met de muis hoeft te doen. 307 Kleur van offertedossiers anders o.b.v. lopend of afgelegd 308 Bij het selecteren van een offertedossier word de info in de balk niet aangepast. 309 Het moet mogelijk worden om een afgehandelde checklijst te heropenen 310 Geroyeerde polissen en afgehandelde schades rood weergeven 311 Ingevulde werklijstitem vasthouden bij wisseling van tabblad 312 Het zou handig zijn als op de plek van gebruiker ook een blanko balk of iets dergelijks zou zijn, zodat je dan de werklijsten van dee afdeling krijgt en niet helemaal weer terug hoeft. 313 Bij offertedossier is naam van de klant niet te zien. Wel wenselijk.

172


O O O O O

Implementatie fout

O O O O O


O O O O O

Wens

O O O O O

Wens

O O O O O

Wens

O O O O O


O O O O O


O O O O O


O O O O O

Requirement fout

O O O O O

Wens

O O O O O

Wens

O O O O O

Misvatting

O O O O O


O O O O O

O O O O O

O O O O O

O O O O O

O O O O O


314 Is het ook mogelijk een werklijst te printen? 315 In Klantdossier zijn niet de nieuwe polissen zichtbaar (vaak onder naam ingevoerd). 316 Bij het wijzigen van documentgegevens, is de dropdownlist niet alfabetisch gesorteerd 317 Drop-down menu is bijna niet te selecteren door schuifbalken. Er dienen alleen balken getoond te worden wanneer dit nodig is. 318 IS het mogelijk een geheel overzicht te krijgen, dus correspondentie en de notitie's die in SD aangemaakt zijn in 1 overzicht. desnoods met een ander letter type aangeven dat dat een notitie is. 319 Het zou een optie moeten zijn om in 1x een aantal werklijst items tegelijk door te zetten naar een bepaalde medewerker. 320 Bij het zoek op voorletter, moet gezocht worden zonder punt omdat er onders niets gevonden wordt. 321 de knop ladenblok sluiten, staat nu uiterst rechts. Wanneer, bij een lagere schermresolutie, Octopus en Digiklant naast elkaar staan valt hij uit het beeld. Is de knop naar links verplaatsen, zodat hij altijd zichtbaar is een mogelijkheid? 322 Bij openen van schadedossier uit werklijst, wordt schadenummer niet ingevuld 323 Zet documenten nog niet op logische tijdsvolgorde in SD 324 standaard bij openen SlimDossier werklijst tonen 325 vakje waarin schadenummer van een geopend dossier staat te donker

Wens

O O O O O

Implementatie fout

O O O O O


O O O O O


O O O O O

Wens

O O O O O

Requirement fout

O O O O O

Implementatie fout

O O O O O


O O O O O

Implementatie fout

O O O O O


O O O O O


O O O O O

O O O O O

173


174

DEMO introduced to financial services Appendix C Specific Information Table S.S.R.W. Algoe BSc. V.R.K. Boedhram BSc.

Appendix C

Specific Information Table

Finding 5 7, 55, 244 11 12, 14, 56, 97, 98, 105, 116, 118, 145, 152, 153, 154, 155, 156, 162, 171, 177, 181, 209, 219, 238, 239, 242, 243, 249, 250, 251,259, 293, 294, 297, 299, 302, 314, 325 15 17 18, 20, 21, 25, 31, 81 19 23, 121, 182, 202 28 29, 41, 42, 49, 50, 87, 88, 150, 151, 157, 166, 173, 201, 208, 211, 214, 215, 216, 218, 220, 221, 222, 223, 224, 225,226, 230, 231, 232, 234, 235, 236, 305 30 32 36 39, 85 48 58 59 60 66 67 69

71 77 86, 122 90, 117, 191, 194, 197, 237, 240, 268, 274, 284, 285, 288, 295, 306 96 101 104 109, 174, 183, 204, 286, 289, 324 111 113 120 123 128 133 138 140 141 142 143

transaction T02 T06 T08 T03

Information items (object class, fact type or result type) maximum_offerperiod CERTIFICATE damagehandling_deadline POLICY

PB03 PB07 PB04 PB03

T08 T03 T03 T03 T05 T08 T02

POLICY, DAMAGE contact_person CLIENT policy_number COMPLAINT dossier_heapcode POLICY

PB03,PB04 PB01 PB02 PB03 PB08 PB06 PB03

T08 T08 T02 T03 T02 T08 T05 T08 T09 T03 T03

damage_checklistid damage_handling_completed normal_expected_fee policyhandling_deadline standard_recall_time policy_checklistid current_datetime process_datetime damage_payment_refusal policy_checklist_modifiable name_account_manager, phone_account_manager, phone_contact_person, total_fee branch_code CLIENT contact_person CLIENT insurance_type product_description postalcode_contact_person DAMAGE continous_fee bank_code PRODUCT agenda_status checklist_acronym complaint_type realtime_process_state active_user_isauthorized CLIENT department_name default_authorization_group

PB04 PB04 PB03 PB03 PB03 PB03 CPB03 CPB03 PB04 PB03 CPB02

T03 T05 T02 T01 T07 T05 T02 T08 T03 T03 T01 T05 T06 T05 T03 T07 T07 T05 T03

175

p-bank

CPB01 PB02 PB01 PB02 CPB01 CPB01 PB01 PB04 PB03 PB01 CPB01 CPB03 PB03 PB08 CPB02 CPB02 PB02 CPB02 CPB03

DEMO introduced to financial services Appendix C Specific Information Table S.S.R.W. Algoe BSc. V.R.K. Boedhram BSc.

149, 159 158 163, 245 168 175 176

transaction T02 T02 T07 T03 T09 T10

178 179

T01 T09

Finding

176

180

T09

184 186 193 207 210 212 213, 246, 247, 248 258 280 281 310 318

T08 T10 T02 T01 TO3 T03 T04 T05 T03 T02 T03 T02

Information items (object class, fact type or result type) offer_type send_options POLICY policy_iscontrolled DAMAGE expertise of the damage of claim CL has been given client_description damage_claim_handler insurance damage claim CL has been handled default_damage_deadline racall_creator offer_iscreated PRODUCT ADVICE POLICY compansation_treshold_value POLICY POLICY user_interest_modification_isauthorized checklist_status contract_number client_name

p-bank PB03 CPB03 PB03 PB03 PB04 CPB04 PB02 PB06 PB06 PB04 CPB02 PB03 PB01 PB03 PB03 PB03 PB03 PB01 PB03 CPB03 PB02

DEMO introduced to financial services Appendix D Mapping Table S.S.R.W. Algoe BSc. V.R.K. Boedhram BSc.

Appendix D Bevind. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43

AVG 0,00% 0,00% 0,00% 0,00% 0,26% 0,00% 0,21% 0,00% 0,00% 0,00% 0,21% 0,26% 0,00% 0,17% 0,17% 0,02% 0,13% 0,15% 0,22% 0,15% 0,17% 0,00% 0,15% 0,00% 0,04% 0,00% 0,00% 0,11% 0,13% 0,07% 0,22% 0,15% 0,00% 0,00% 0,13% 0,26% 0,00% 0,00% 0,22% 0,04% 0,26% 0,15% 0,00%

MAPABLE 0 0 0 0 1 0 1 0 0 0 1 1 0 1 1 0 1 1 1 1 1 0 1 0 1 0 0 1 1 1 1 1 0 0 0 1 0 0 1 0 1 1 0

definitief 0,00% 0,00% 0,00% 0,00% 0,26% 0,00% 0,21% 0,00% 0,00% 0,00% 0,21% 0,26% 0,00% 0,17% 0,17% 0,00% 0,13% 0,15% 0,22% 0,15% 0,17% 0,00% 0,15% 0,00% 0,04% 0,00% 0,00% 0,11% 0,13% 0,07% 0,22% 0,15% 0,00% 0,00% 0,00% 0,26% 0,00% 0,00% 0,22% 0,00% 0,26% 0,15% 0,00%

Bevind. 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86

Mapping Table AVG 0,00% 0,00% 0,00% 0,02% 0,22% 0,13% 0,13% 0,00% 0,00% 0,00% 0,00% 0,24% 0,28% 0,13% 0,28% 0,24% 0,21% 0,00% 0,17% 0,17% 0,00% 0,09% 0,21% 0,22% 0,00% 0,26% 0,17% 0,11% 0,09% 0,00% 0,11% 0,15% 0,13% 0,19% 0,00% 0,00% 0,11% 0,17% 0,00% 0,00% 0,00% 0,15% 0,22%

MAPABLE 0 0 0 0 1 1 1 0 0 0 0 1 1 0 1 1 1 0 0 0 0 0 1 1 0 1 0 1 0 0 0 0 0 1 0 0 0 1 0 0 0 1 1

definitief 0,00% 0,00% 0,00% 0,00% 0,22% 0,13% 0,13% 0,00% 0,00% 0,00% 0,00% 0,24% 0,28% 0,00% 0,28% 0,24% 0,21% 0,00% 0,00% 0,00% 0,00% 0,00% 0,21% 0,22% 0,00% 0,26% 0,00% 0,11% 0,00% 0,00% 0,00% 0,00% 0,00% 0,19% 0,00% 0,00% 0,00% 0,17% 0,00% 0,00% 0,00% 0,15% 0,22%

177


Bevind. 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133

178

AVG 0,30% 0,09% 0,11% 0,09% 0,07% 0,00% 0,00% 0,06% 0,06% 0,15% 0,06% 0,22% 0,00% 0,00% 0,22% 0,07% 0,21% 0,15% 0,11% 0,21% 0,00% 0,24% 0,07% 0,26% 0,00% 0,22% 0,24% 0,06% 0,28% 0,13% 0,19% 0,17% 0,15% 0,24% 0,21% 0,02% 0,00% 0,00% 0,06% 0,21% 0,09% 0,00% 0,00% 0,00% 0,17% 0,00% 0,15%

MAPABLE 1 1 0 1 0 0 0 0 0 1 1 1 0 0 1 0 1 1 0 0 0 1 0 1 0 1 0 0 1 1 1 1 1 1 1 0 0 0 0 1 0 0 0 0 1 0 0

definitief 0,30% 0,09% 0,00% 0,09% 0,00% 0,00% 0,00% 0,00% 0,00% 0,15% 0,06% 0,22% 0,00% 0,00% 0,22% 0,00% 0,21% 0,15% 0,00% 0,00% 0,00% 0,24% 0,00% 0,26% 0,00% 0,22% 0,00% 0,00% 0,28% 0,13% 0,19% 0,17% 0,15% 0,24% 0,21% 0,00% 0,00% 0,00% 0,00% 0,21% 0,00% 0,00% 0,00% 0,00% 0,17% 0,00% 0,00%

Bevind. 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180

AVG 0,06% 0,24% 0,00% 0,24% 0,30% 0,21% 0,22% 0,06% 0,24% 0,09% 0,00% 0,17% 0,26% 0,28% 0,19% 0,19% 0,24% 0,21% 0,19% 0,24% 0,24% 0,21% 0,21% 0,09% 0,07% 0,24% 0,28% 0,00% 0,09% 0,24% 0,00% 0,24% 0,00% 0,02% 0,26% 0,06% 0,15% 0,24% 0,24% 0,22% 0,22% 0,24% 0,26% 0,24% 0,26% 0,19% 0,26%

MAPABLE 0 1 0 1 1 1 1 0 1 0 0 0 1 1 1 1 1 1 1 1 1 1 1 0 0 1 1 0 0 1 0 1 0 0 1 0 1 1 1 1 1 1 1 1 1 1 1

definitief 0,00% 0,24% 0,00% 0,24% 0,30% 0,21% 0,22% 0,00% 0,24% 0,00% 0,00% 0,00% 0,26% 0,28% 0,19% 0,19% 0,24% 0,21% 0,19% 0,24% 0,24% 0,21% 0,21% 0,00% 0,00% 0,24% 0,28% 0,00% 0,00% 0,24% 0,00% 0,24% 0,00% 0,00% 0,26% 0,00% 0,15% 0,24% 0,24% 0,22% 0,22% 0,24% 0,26% 0,24% 0,26% 0,19% 0,26%


Bevind. 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227

AVG 0,22% 0,02% 0,13% 0,00% 0,15% 0,00% 0,00% 0,19% 0,17% 0,13% 0,11% 0,00% 0,17% 0,07% 0,11% 0,13% 0,22% 0,26% 0,09% 0,19% 0,13% 0,00% 0,17% 0,11% 0,21% 0,15% 0,24% 0,22% 0,28% 0,22% 0,21% 0,28% 0,13% 0,19% 0,15% 0,17% 0,26% 0,28% 0,26% 0,21% 0,13% 0,22% 0,15% 0,04% 0,00% 0,22% 0,22%

MAPABLE 1 0 1 0 0 0 0 1 1 1 0 0 1 0 0 0 1 1 0 1 0 0 1 1 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 1 0 0 0 1 1

definitief 0,22% 0,00% 0,13% 0,00% 0,00% 0,00% 0,00% 0,19% 0,17% 0,13% 0,00% 0,00% 0,17% 0,00% 0,00% 0,00% 0,22% 0,26% 0,00% 0,19% 0,00% 0,00% 0,17% 0,11% 0,21% 0,15% 0,24% 0,22% 0,28% 0,22% 0,21% 0,28% 0,00% 0,19% 0,15% 0,17% 0,26% 0,28% 0,26% 0,21% 0,13% 0,22% 0,00% 0,00% 0,00% 0,22% 0,22%

Bevind. 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274

AVG 0,22% 0,02% 0,17% 0,15% 0,21% 0,24% 0,22% 0,22% 0,22% 0,17% 0,24% 0,26% 0,26% 0,24% 0,26% 0,22% 0,28% 0,21% 0,15% 0,26% 0,00% 0,00% 0,00% 0,07% 0,00% 0,07% 0,17% 0,24% 0,09% 0,07% 0,15% 0,00% 0,11% 0,00% 0,00% 0,00% 0,09% 0,09% 0,11% 0,06% 0,00% 0,19% 0,07% 0,00% 0,00% 0,00% 0,11%

MAPABLE 1 0 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 1 0 0 0 0 1 0 0 0 0 0

definitief 0,22% 0,00% 0,17% 0,15% 0,21% 0,24% 0,22% 0,22% 0,22% 0,00% 0,24% 0,26% 0,26% 0,24% 0,26% 0,22% 0,28% 0,21% 0,15% 0,26% 0,00% 0,00% 0,00% 0,00% 0,00% 0,00% 0,17% 0,24% 0,00% 0,00% 0,00% 0,00% 0,00% 0,00% 0,00% 0,00% 0,09% 0,00% 0,00% 0,00% 0,00% 0,19% 0,00% 0,00% 0,00% 0,00% 0,00%

179


Bevind. 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301

180

AVG 0,26% 0,15% 0,07% 0,00% 0,19% 0,15% 0,09% 0,06% 0,17% 0,19% 0,00% 0,07% 0,00% 0,17% 0,17% 0,19% 0,11% 0,15% 0,13% 0,15% 0,02% 0,11% 0,17% 0,02% 0,06% 0,21% 0,15%

MAPABLE 1 1 0 0 1 1 1 0 1 1 0 0 0 1 1 1 0 1 0 1 0 0 1 0 0 1 1

definitief 0,26% 0,15% 0,00% 0,00% 0,19% 0,15% 0,09% 0,00% 0,17% 0,19% 0,00% 0,00% 0,00% 0,17% 0,17% 0,19% 0,00% 0,15% 0,00% 0,15% 0,00% 0,00% 0,17% 0,00% 0,00% 0,21% 0,15%

Bevind. 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325

AVG 0,09% 0,13% 0,06% 0,17% 0,09% 0,09% 0,00% 0,26% 0,17% 0,15% 0,13% 0,09% 0,09% 0,00% 0,11% 0,07% 0,17% 0,19% 0,00% 0,07% 0,00% 0,07% 0,15% 0,07% 41,34%

MAPABLE 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1 0 0 0 0 0 0 164

definitief 0,00% 0,00% 0,00% 0,17% 0,00% 0,00% 0,00% 0,26% 0,00% 0,00% 0,00% 0,09% 0,00% 0,00% 0,00% 0,00% 0,17% 0,19% 0,00% 0,00% 0,00% 0,00% 0,00% 0,00% 33,12%

DEMO introduced to financial services Appendix E Don Paparassos S.S.R.W. Algoe BSc. V.R.K. Boedhram BSc.

Appendix E

Don Paparassos

181


182


183


184


185


186


187


188


189


190


191


192


193


194


195


196


197


198

Applied to financial services

Recommend Documents