Your SlideShare is downloading. ×
Enterprise Architecture.doc
Enterprise Architecture.doc
Enterprise Architecture.doc
Enterprise Architecture.doc
Enterprise Architecture.doc
Enterprise Architecture.doc
Enterprise Architecture.doc
Enterprise Architecture.doc
Enterprise Architecture.doc
Enterprise Architecture.doc
Enterprise Architecture.doc
Enterprise Architecture.doc
Enterprise Architecture.doc
Enterprise Architecture.doc
Enterprise Architecture.doc
Enterprise Architecture.doc
Enterprise Architecture.doc
Enterprise Architecture.doc
Enterprise Architecture.doc
Enterprise Architecture.doc
Enterprise Architecture.doc
Enterprise Architecture.doc
Enterprise Architecture.doc
Enterprise Architecture.doc
Enterprise Architecture.doc
Enterprise Architecture.doc
Enterprise Architecture.doc
Enterprise Architecture.doc
Enterprise Architecture.doc
Enterprise Architecture.doc
Enterprise Architecture.doc
Enterprise Architecture.doc
Enterprise Architecture.doc
Enterprise Architecture.doc
Enterprise Architecture.doc
Enterprise Architecture.doc
Enterprise Architecture.doc
Enterprise Architecture.doc
Enterprise Architecture.doc
Enterprise Architecture.doc
Enterprise Architecture.doc
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Enterprise Architecture.doc

542

Published on

Published in: Economy & Finance, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
542
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
23
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Business Enterprise Architecture of German Insurance Group University of Applied Sciences Northwestern Switzerland MSc Business Information Systems Information System Architecture Elaborated by: - Roger Böhlen - Renato Melliger - Marcel Dubach January 23th, 2009
  • 2. Business Enterprise Architecture of the German Insurance Group Table of contents Table of contents......................................................................................................................................................2 Preface .........................................................................................................................................2 1 Introduction.............................................................................................................................................................3 1.1 Purpose of this Document...................................................................................................................................3 1.2 The German Insurance Group Company............................................................................................................3 1.3 Insurance Market in Germany and the Settlements............................................................................................3 1.3.1 German Insurance Market................................................................................................................................3 1.3.2 Settlement Insurance Market............................................................................................................................3 1.4 Approach of Analyzing the Enterprise Architecture of the German Insurance Company....................................3 1.4.1 The Zachman Framework.................................................................................................................................4 1.4.2 Business Motivation Model (BMM)...................................................................................................................5 1.4.3 Business Rules (SBVR)....................................................................................................................................7 1.4.4 Business Processes (BPMN) ...........................................................................................................................7 2 Motivation...............................................................................................................................................................8 2.1 Vision 8 2.2 Goals 8 2.3 Objectives............................................................................................................................................................8 2.4 Mission.................................................................................................................................................................9 2.5 Strategy...............................................................................................................................................................9 2.6 Tactics 9 2.7 Influencers.........................................................................................................................................................10 2.7.1 External Influencers........................................................................................................................................10 2.7.2 Internal Influencers.........................................................................................................................................10 2.8 Assessment.......................................................................................................................................................11 2.8.1 Strengths........................................................................................................................................................11 2.8.2 Weaknesses...................................................................................................................................................11 2.8.3 Opportunities..................................................................................................................................................11 2.8.4 Threats............................................................................................................................................................12 3 Vocabularies and Business Rules .......................................................................................................................12 3.1 Language Dependent Vocabulary.....................................................................................................................12 3.2 Common Vocabulary.........................................................................................................................................12 3.2.1 Numbers.........................................................................................................................................................12 3.2.2 Time 12 3.2.3 Key Words and Phrases for Logical Formulations.........................................................................................13 3.2.4 Other Key Words............................................................................................................................................14 3.2.5 Categories of Business Rules.........................................................................................................................14 3.2.6 Guidance Types..............................................................................................................................................14 3.2.7 Levels of Enforcement....................................................................................................................................15 3.3 GIG Concepts and Vocabulary..........................................................................................................................15 3.3.1 Name Concept................................................................................................................................................16 3.3.2 Term Concept.................................................................................................................................................19 3.3.3 Individual Concept..........................................................................................................................................26 3.4 Product Development Rules of GIG..................................................................................................................26 4 Models 31 4.1 Process Map......................................................................................................................................................31 4.2 Business Process Model...................................................................................................................................32 4.2.1 Evaluation Process.........................................................................................................................................32 4.2.2 Implementation Process.................................................................................................................................33 4.2.3 Maintenance Process.....................................................................................................................................36 4.3 Working Environment Model .........................................................................................................................38 4.4 IT Systems Model..............................................................................................................................................38 4.5 Document Model................................................................................................................................................39 5 Limits of ADONIS .................................................................................................................................................40 Directories / Glossary.............................................................................................................................................40 Illustration Directory................................................................................................................................................40 Table Directory.......................................................................................................................................................41 Glossary 41 Preface The objective of this document is to describe a part of the enterprises architecture for the German Insurance Group Company (GIG). The document has been elaborated during the study of Master in Business Information Elaborated by: Renato Melliger, Roger Böhlen, Marcel Dubach 08.06.2010 / Page 2 of 41
  • 3. Business Enterprise Architecture of the German Insurance Group Systems. The assignment is the practical experience of the methods and techniques which have been discussed during the Master lectures. The following assignment was elaborated in a group work of three students. It is not intended to cover the whole enterprise architecture of the German Insurance Group. The main focus is on the departments and activities which are relevant for the development of new insurance products. 1 Introduction The Introduction part gives an overview, what the content of the assignment comprised. In addition the case study company will be presented and the different methodologies, models and techniques which will be used for the analysis of the enterprise architecture for the German Insurance Group will be briefly described. 1.1 Purpose of this Document This document describes the business enterprise architecture of the German Insurance Group company. The focus on the assignment is the product development and additional relevant departments of the German Insurance Group. 1.2 The German Insurance Group Company The German Insurance Group company competes mainly in the health care and health insurance market within Germany. Due to various acquisitions the company expanded its scope geographical as well as product wise. The main focus of the German Insurance Company is health insurance and further it provides other insurance products. The insurance has in addition different settlements in Italy, Luxembourg, Belgium, Norway, Sweden, Spain, United Kingdom, China, India and South Korea. Currently the main markets where the GIG is competing are Europe and Asia. The German Insurance Group company’s headquarter is based in Germany. The company occupies 45’000 employees. They serve world wide 16 Million costumers and achieved a net premium income of 17 Billion Euro in 2007. 1.3 Insurance Market in Germany and the Settlements The German Insurance Group company has various competitors within Germany and different partners in European and Asian countries. 1.3.1 German Insurance Market Within Germany the company is in competitions with its main rivals like, Allianz, AOK, AXA and Barmenia. Currently the GIG is the third biggest health insurer in Germany. In addition the company is the fourth biggest home insurance and liability insurer as well as the fifth biggest motor insurance company based on the market share. Due to the mix of health products as well as a few other line of business (LoB) like personal insurance, mobility, finance and motor the German Insurance Group can not be compared one to one with its rivals because they serve mostly only one line of business which is health insurance. Other rivals who provide as well more than one line of business are hard to compare with the German Insurance Group company because they provide a total different product portfolio. This means that they are offering neither health insurance products or serve health insurance products in addition with other products which are not offered by the GIG. 1.3.2 Settlement Insurance Market The German Insurance Company covers the market within Europe with different settlements and partners in different European countries. In addition the company servers different locations out side Europe like China, India and South Korea. The investment in the Asian market is a strategic future focus. It is intended to cover the European as well as the Asian market with the same product which are already available in Germany. Due various laws in the different counties the products need legal adjustments to fulfill the requirements for them. 1.4 Approach of Analyzing the Enterprise Architecture of the German Insurance Company The approach for the enterprise architecture of the German Insurance Company is to define the business motivations, business rules, business processes and afterwards application systems. It is very important, that the starting point is the business itself and not an IT view. To analyze the enterprise architecture of the German Insurance Group Company the framework from John Zachman will be used as a basic. It describes what has to be regarded in reference to the different perspectives and aspects of a company. For the reason that the Zachman Framework shows only a high level view about what has to be investigated and nothing further about how the desired result will be achieved, the Business Motivation Model from OMG will be used to derive the aspect (why) for the German Insurance Group Company. To elaborate the How something has to be done, the Business Motivation Model (BMM) will be used. The Business Motivation Model provides a scheme or structure for developing, communicating and managing business plans in an organized manner. Elaborated by: Renato Melliger, Roger Böhlen, Marcel Dubach 08.06.2010 / Page 3 of 41
  • 4. Business Enterprise Architecture of the German Insurance Group To establish the business rules in the product development area of the GIG, the terms will be defined as a first step. Terms express business concepts. This means terms are used to designate the noun concepts. In a second step facts will be defined. Facts make assertions about the term concepts and rules constrain to support the term facts. The last step is to combine terms and facts together to business rules. 1.4.1 The Zachman Framework The Zachman Framework conceived in the 1980s (www.zifa.com) offers a methodology to analyze and elaborate the enterprise architecture. The Framework is often referenced as a standard approach for elaborating the basic elements of the enterprise architecture. The Framework defines what kind of different areas within a company are affected or should be covered to elaborate the enterprise architecture. The Framework itself says nothing about how it has to be done. The assignment concentrates on two aspects of the Zachman Framework to establish the enterprise architecture for the German Insurance Group. The two main aspects for this assignment are Why (motivation) and How (process). In searching for an objective, independent basis upon to develop a framework for information systems architecture John Zachman approach was to look to the field of classical architecture itself. John Zachman describes his work as follows: The Framework, as it applies to enterprises, is a logical structure for identifying and organizing the descriptive representations (models) that are important in the management of enterprises and to the development of the systems, both automated and manual, that comprise them. The Zachman Framework is a schema - the intersection between two historical classifications that have been in use for literally thousands of years. The first is the fundamentals of communication found in the primitive interrogatives: What, How, When, Who, Where, and Why. It is the integration of answers to these questions that enables the comprehensive, composite description of complex ideas. The second is derived from reification, the transformation of an abstract idea into an instantiation that was initially postulated by ancient Greek philosophers and is labeled in the Framework: Identification, Definition, Representation, Specification, Configuration and Instantiation. ... More specifically, the Zachman Framework is an ontology - a theory of the existence of a structured set of essential components of an object for which explicit expressions is necessary and perhaps even mandatory for creating, operating, and changing the object (the object being an Enterprise, a department, a value chain, a "sliver," a solution, a project, an airplane, a building, a product, a profession of whatever of whatever). The Zachman Framework shows horizontally the different “aspects” and vertically the “perspectives”. The framework is horizontally split in different views. The perspectives describe the different stakeholders of an enterprise. For example has the Planner another view than the Owner. Vertically the framework partitions the different questions WHAT, HOW, WHERE, WHO, WHEN and WHY. In italic and blue are the references to classical architecture. In reference to classical Data / Material Process / Network / People Time Motivation architecture it is possible to description Functional Location description description description describe Data as Material, Process description description addresses addresses addresses addresses as Functional and Location as WHAT addresses addresses WHO WHEN WHY Network HOW WHERE Elaborated by: Renato Melliger, Roger Böhlen, Marcel Dubach 08.06.2010 / Page 4 of 41
  • 5. Business Enterprise Architecture of the German Insurance Group Scope / objectives 1 Planner Model of the Business 4 5 2 Owener Model of the 6 7 3 information system Designer -> Technology Model -> Detailed Description -> Machine Language Builder -> Detailed Representations Subcontractor Illustration 1 - Zachman Framework The framework itself says nothing about how the different perspective / aspect levels can be achieved. It says only what has to be analyzed / regarded in reference to develop the enterprise architecture. As already mentioned, this assignment is focused on only a part of the Zachman Framework’s cells to describe the enterprise architecture of the German Insurance Group company. With cells the intersections between perspectives and aspects are understood. The assignment focuses on the following cells of the Zachman Framework. The numbers in the table refer to the Illustration 1 - Zachman Framework # Model Aspect Perspective Methodology / Technique 1. List of Business Goals / Strategies Scope Why BMM 2. Business Plan Business Why BMM 3. Business Rule Model System Why SBVR 4. Business Process Model Business How BPMN 5. Working Environment Model Business Who BPMN 6. Document Model System What BPMN 7. IT System Model System Where BPMN Table 1 - Cell Analysis of the Zachman Framework 1.4.2 Business Motivation Model (BMM) It is important to note that the Business Motivation Model (BMM) is not in any sense a methodology. Indeed, it is entirely neutral with respect to methodology or particular approach, with only several general exceptions:  The requirements development process should be business driven  Organized business plans should be a fundamental deliverable in any such process  Business Rules and Business Processes are key elements of such business plans The Business Motivation Model covers the following points:  It identifies factors that motivates the establishing of business plans  It identifies and defines the elements of business plan  It indicates how all these factors and elements inter-relate The Model provides the following:  A set of built-in concepts that define the elements of business plans.  Roles in the structure for three essential concepts: Business Process, Business Rule, and Organization Unit. They participate in associations within the Business Motivation Model, but also in other associations outside. Elaborated by: Renato Melliger, Roger Böhlen, Marcel Dubach 08.06.2010 / Page 5 of 41
  • 6. Business Enterprise Architecture of the German Insurance Group The Business Motivation Model will be used to investigate the Ends (Vision, Objective and Goals) and Means (Mission, Strategy, Tactic, Business Rule and Business Policy). The elements are associated in a structure that is methodology neutral. The Business Motivation Model is strong in supporting of processes that are driven by the business change. There are two major areas of the Business Motivation Model. 1. The first are Ends and Means of business plans. Among the Ends are things the enterprise wishes to achieve - for example Vision (describe the future state of the enterprise, without regard to how it is to be achieved), Goals (is a statement about a state or condition which the enterprise would achieve) and Objectives (is a statement of an attainable, time-targeted, and measurable target that the enterprise seeks to meet in order to achieve the goals). Among the Means are things the enterprise will employ to achieve those Ends - for example, Mission (indicates the ongoing operational activity of the enterprise. It describes what the business is or will be doing on a day-to-day basis), Strategies (is one component of the plan for the mission. It represents the essential course of action to achieve ends), Tactics (is a course of action that represents part of the detailing of strategies. It implements strategies). 2. The second is the Influencers that shape the elements of the business plans, and the assessments made about the impacts of such Influencers on Ends and Means (i.e., Strengths, Weaknesses, Opportunities, and Treats). The following illustration shows again this construct and the associations. Means End Mission MissionMakesOperativeVision ► Vision StrategyIsAComponent OfThePlanForMission ► GoalAmplifiesVision ▲ EnablingCourseOf Course of Action Desired Action ActionEnablesEnable ◄ BroaderDesired dCourseOfAction ▲ ResultIncludesMore Strategy SpecificDesiredResult Objective BroaderCourseOfActi TacticImplementsStrategy ▲ ObjectivesQuantifiesGoal ▲ onIncludesMoreSpeci ficCourseOfAction ▲ Tactic CourseOfActionChannelsEfforts Goal TowardsDesiredResults ► DirectiveGoverns TacticEffectsEnforcement DirectiveIsSourceOf CourseOfAction ▲ LevelOfBusinessRule ▼ CourseOfAction ▲ DirectiveSupportsAchievement OfDesiredResults ► Directive AssessmentAffects ◄ AssessmentAffects AchievmentOfEnd ▲ Business Rule EmploymentOfMeans BusinessPolicyBasis ForBusinessRule ▲ ◄ AssessmentProvides Assessment esUsedAssessment UsingAssessmentUs ImpeteusForDirective ◄ Business BroaderBusinessPoli cyIncludesMoreSpeci Policy Strength Weakness ficBusinessPolicy ▼ DirectiveActsAs ◄ PotentialImpact Opportunity Threat Regulation ▼ ProvidesImpetus ForDirective Influencer AssessmentIdentifies ◄ AssessmentIs PotentialImpact ▼ External Influencer JudgmentOfInfluencer Regulation Potential Impact Internal Influencer Potential Risk Reward InfluencingOrganizationIs SourceOfInfluencer ▼ Influencing Organization Illustration 2 - Business Motivation Model Elaborated by: Renato Melliger, Roger Böhlen, Marcel Dubach 08.06.2010 / Page 6 of 41
  • 7. Business Enterprise Architecture of the German Insurance Group 1.4.3 Business Rules (SBVR) The business rules define what must be the case rather than how it comes to be. They define the conditions under which a process is carried out or the new conditions that will exist after the process has been completed. The business rules define conditions that must hold true in specific situations. They are not descriptions of processes or proceeding. The most common means of expressing definitions and business rules is through statements, not diagrams. While diagrams are helpful for seeing how concepts are related, they are impractical as a primary means of defining vocabularies and expressing business rules. The SBVR specification defines an English vocabulary for describing vocabularies and stating rules. There are many different ways that this vocabulary and other English vocabularies described using SBVR can be combined with common English words and structures to express definitions and statements. There are four font styles for the SBVR specification with formal meaning:  Term  Name  Verb  Keyword The ’Term’ font is used for a designation of words and phrases that have a meaning to business people in the context where those terms are used. Terms are usually defined using lower case letters unless they include a proper noun. Terms are defined in singular form. The ‘Name’ font is used for a designation of an individual concept - a name. Names tend to be proper nouns (e.g., German Insurance Group). This style is applied to a name where it is defined and wherever it is used. Names of numerical values in formal statements are also shown in this style. Names appear using appropriate capitalization, which is usually the first letter of each word, but not necessarily. The ‘Verb’ font is used for designations of fact types - usually a verb, preposition, or combination thereof. Such a designation is defined in the context of a fact type form. Fact type forms shown as vocabulary entries use singular, active forms of verbs with the exception that present participles are sometimes used for characteristics. Infinitive, subjunctive, passive, and plural forms of verbs are implicitly usable in statements and definitions. For a binary fact type, the implicit passive form of a verb uses the past participle of the verb preceded by the word “is” and followed by the preposition “by.” The ‘Keyword’ font is used for linguistic symbols used to construct statements - the words that can be combined with other designations to form statements and definitions Quotation marks are also in the ‘keyword’ font. The text within quotes is in ordinary font if the meaning of the quotation is not interpreted text. The text within quotes is in styled text if the meaning of the quotation is formally represented. Single quotation marks are used to quote a designation or fact type form that is being mentioned. If a designation is mentioned (where the designation is itself the subject of a statement) it appears within single quote marks The combination of terms, names, verbs and keywords establishes the business rules. 1.4.4 Business Processes (BPMN) A standard Business Process Modelling Notation (BPMN) will provide businesses with the capability of understanding their internal business procedures in a graphical notation and will give organizations the ability to communicate these procedures in a standard manner. Furthermore, the graphical notation will facilitate the understanding of the performance collaborations and business transactions between the organizations. This will ensure that businesses will understand themselves and participants in their business and will enable organizations to adjust to new internal and business to business circumstances quickly. 1.4.4.1 Process Map The process map gives an overview of the different processes and the dependences of the main processes. 1.4.4.2 Business Process Model Business process model is a flow-chart notation standard for defining business processes. BPMN provides a mechanism to generate an executable business process from the business level notation. Business process model focuses on the following objectives:  Provides an easy to use process modeling notation for business users and business analysts Elaborated by: Renato Melliger, Roger Böhlen, Marcel Dubach 08.06.2010 / Page 7 of 41
  • 8. Business Enterprise Architecture of the German Insurance Group  Provides facilities to translate models into an executable form 1.4.4.3 Working Environment Model The working environment model shows the organizational structure of a company. It can be referenced from other models to e.g. define responsibility for processes. The working environment model allows showing relations between organizational units, performers, roles, and positions in order to provide a full picture of the company human resources. 1.4.4.4 IT Systems Model The IT system model gives an overview about all related IT systems and how the different IT systems interact with each other. 1.4.4.5 Document Model The document model is a pool model containing types of used documents. They can be referenced from other models. This enables the notation to represent complex relationships with several performers, inputs and outputs without compromising the clarity of the diagrams. 2 Motivation The mentioned approach in chapter 1.4 to elaborate the enterprise architecture for the German Insurance Group Company will be executed in this chapter. 2.1 Vision A vision describes the future state of the enterprise, without regard to how it is to be achieved. A vision is the ultimate, possibly unattainable, state the enterprise would like to achieve. A vision is often compound, rather than focused toward one particular aspect of the business problem. Vision of the German Insurance Group company: Be a European and Asian wide operative, leading insurance company and the number one health insurer within Germany. Our major goals are a superior cost performance ratio and the highest customer satisfaction ratio. 2.2 Goals A goal is a statement about a state or condition of the enterprise to be brought about or sustained through appropriate means. A goal amplifies a vision - that is, it indicates what must be satisfied on a continuing basis to effectively attain the vision. A goal should be narrow - focused enough that it can be quantified by objectives. # Goals G1 Become number one personal health insurance company within Germany based on market share. G2 Enter top eight ranking of personal insurers in each European settled country measured on market share. G3 Tightening the Asian position and extend the local presence. G4 Appear as a major innovator on health care products. G5 Extend services and products within Europe. G6 Provide superior cost performance ratio over the whole range of products. G7 Provide the best customer service in the personal insurance business. G8 Increase the efficiency of knowledge- and information exchange within the company. Table 2 - Goals 2.3 Objectives An objective is a statement of an attainable, time-targeted, and measurable target that the enterprise seeks to meet in order to achieve its goals. An objective has to be "SMART": Specific, Measurable, Attainable, Relevant, and Time-based. # Supported Objectives Goals O1 G3 Increase the product sales within the next 12 months by 15% in Asia. O2 G1 Increase of health insurances in Germany by 5% in the next 3 years. O3 G6, G7, G8 Issue 20% of the health care insurances in Germany via a web based platform as soon as this platform runs. O4 G2 Reach a minimum market share of about 7.5% in every settled country in Europe within the next 2 years. O5 G6, G7 Increase customer retention in general for 2009 to 80% and in 2010 to 85%. O6 G5, G6, G7 Increase the average customer satisfaction to 80% in the next 3 years in Europe. Elaborated by: Renato Melliger, Roger Böhlen, Marcel Dubach 08.06.2010 / Page 8 of 41
  • 9. Business Enterprise Architecture of the German Insurance Group O7 G3, G5, G7 By 2010 in each competing country a local presence must be established either by a partner or a settlement. O8 G4, G5, G7 Each year, develop a minimum of 3 new health care products based on costumer needs. O9 G7 By the end of the current year, answer 90% of customer request within 24 hours. O10 G4 By the end of 2009, expand the research and development by 15%. O11 G7, G8 Elaborate a concept which supports knowledge- and information exchange within the company by the end of 2009. O12 G8 Be ISO 9001:2000-12 certified by the end of 2010. Table 3 - Objectives 2.4 Mission A mission indicates the ongoing operational activity of the enterprise. The mission describes what the business is or will be doing on a day-to-day basis. A mission makes a vision operative - that is, it indicates the ongoing activity that makes the vision a reality. A mission is planned by means of strategies. # Mission M1 Provide personal insurances in Europe and Asia with a core competence in the health care insurance. M2 Provide tailor made high sophisticated products for each settled country. M3 Treat costumers with an over average customer service. Table 4 - Mission 2.5 Strategy A strategy is one component of the plan for the mission. A strategy represents the essential course of action to achieve ends - goals in particular. A strategy usually channels efforts towards those goals. # Supported Goals Supported Strategies Mission S1 G2, G3 M1, M2 Expand in Europe and Asia either through local settlements, partners or off taking. S2 G7 M2, M3 Establish a yearly customer survey. S3 G1, G2, G3 M1 Start an advertising campaign in all competing countries. S4 G6, G7, G8 M2, M3 Establish new quality insurance end-to-end processes which cover the whole supply chain. S5 G7 M2, M3 Build core competence center in reference to costumer care. S6 G1, G4, G5 M1, M2 Overtake an insurance company which provides complementary products and a strong health care product portfolio. S7 G7, G8 M3 Train the costumer care employees in order to work more efficient and increase the customer satisfaction. S8 G8 M3 Establish a new information management system. S9 G4, G7 M2 By the end of 2009, increase the investment in research and development by 20 Mio Euro. S10 G6 M3 Start and support a prevention campaign in all competing countries. Table 5 - Strategy 2.6 Tactics A tactic is a course of action that represents part of the detailing of strategies. A tactic implements strategies. Tactics generally channel efforts towards objectives. # Supported Supported Tactics Objectives Strategies T1 O1, O7 S1 Get in a partnership with CHI (China Health Insurance) Insurance in all Asian countries where we have no settlement. T2 O5, O6 S2 Establish a customer survey with 10 questions which will be conducted three times per year. T3 O6, O11, O9 S4, S8 Implement the SAP CRM-module by the end of the current year. T4 O1, O8 S1 Reuse 60% of the German products to provide the Asian Elaborated by: Renato Melliger, Roger Böhlen, Marcel Dubach 08.06.2010 / Page 9 of 41
  • 10. Business Enterprise Architecture of the German Insurance Group market with similar ones. T5 O6, O9, O11 S4, S7, S8 Implement a FAQ knowledge system (information system) and train the customer care employees on it as soon as possible. T6 O2, O3 S4 Launch a web based project in order to retail insurances via internet. T7 O1, O2, O4, O5 S3 Start with a product advertising campaign in all European and Asian settled countries to boost health care products. T8 O7 S1 In each European country in which we are competing we have either to establish a settlement or we pull out of the market by 2010. T9 O8, O10 S6 Get the sign off with Quelle health insurance for the prepared take over by the end of 2009 in order to amplify the research department. T10 O12 S4 Start project initializing phase for the ISO 9001:2000-12 certification in cooperation with Price Waterhouse Coopers by end of 2008. T11 O6, O9, O11 S5 Merge the different costumer care centres in a single one and centralized it in Germany in order to provide a single point of contact. T12 O10 S9 By the end of next year, increase the research team by recruiting 15 new researchers/analysts. T13 O5 S10 Establish partnerships with prevention companies and invite certain insured costumers for such an event. Table 6 - Tactics 2.7 Influencers An Influencer can be anything that has the capability to produce an effect without apparent exertion of tangible force or direct exercise of command, and often without deliberate effort or intent. The Influencers specifically of concern to business plans are those that can impact the enterprise in its employment of means or achievement of its ends. 2.7.1 External Influencers External Influencers are those outside an enterprise's organizational boundaries that can impact its employment of means or achievement of ends. # External Influencers Influencer Category IE1 With the entry barriers which fall through new European members, new Competitor competitors appear. IE2 With the fact, that more and more young children have problems with their Environment/Cu weights the costs for the health treatment will increases. stomer IE3 With the arrival of the financial crises it will become harder to get loans for new Environment investments in the near future. IE4 Customers are interested in tailor-made products which match exactly their Customer needs, fast services as well as consulting. IE5 The availability of the internet offers a chance for new insurance contract Technology distribution channel. IE6 New flues (i.e. bird flu) can occur. Environment IE7 The population gets older and older. Customer IE8 Partners prefer to sell their own products instead of the German Insurance Partner Group products. IE9 With falling entry barriers the insurance market gets more homogenous. Environment Table 7 - External Influencer 2.7.2 Internal Influencers Internal Influencers are those from within an enterprise that can impact its employment of means or achievement of ends. # Internal Influencers Influencer Category II1 The German Insurance Group offers high quality services and a very good cost Explicit performance ratio. Corporate Value II2 Two years ago the SAP FS-CD-module (finance module) has been successfully Infrastructure launched. SAP is already available as a basic system. Elaborated by: Renato Melliger, Roger Böhlen, Marcel Dubach 08.06.2010 / Page 10 of 41
  • 11. Business Enterprise Architecture of the German Insurance Group II3 All the different customer care centers will merge in one. Management Prerogative II4 The brand of the German Insurance Group is highly valued within Europe. Explicit Corporate Value II5 Due to an employee’s wider range of fringe benefits they are highly motivated. Internal Corporate Value II6 Wages will rise over the next years Resource II7 Scarcity of employees in research and development department. Resource II8 The German Insurance Groups management board has decided to set priority Management for business expansion in Asia. Prerogative Table 8 - Internal Influencer 2.8 Assessment An assessment is a judgment about some Influencer that affects the organization's ability to employ its means or achieve its ends. In other words, an assessment expresses a logical connection (i.e., fact type) between Influencers and the ends and/or means of the business plans. In this way, an assessment indicates which Influencers are relevant to which ends and/or means. 2.8.1 Strengths The strengths are identified within the organization. These are factors which affect companies internally. # Judged Affected Tactic Affects Influencer AS1 II2 T3, T10 Easy setup of new settlements. AS2 II3 T5, T10, T11 Cost savings and customer satisfaction due to single point of contact. AS3 II4, II1 T1, T2, T7 Get buy-in from the customers. AS4 II5 T2 Low fluctuation and a high willingness to perform. AS5 II8 T1, T4, T7, T8 Invest in emerging market to become a major player worldwide. Table 9 - Strengths 2.8.2 Weaknesses The Weaknesses are identified within the organization. These are factors which affect companies internally. # Judged Affected Tactic Affects Influencer AW1 II3 T11 Bad reputation within the customer care department. AW2 II5 T2 Less profit due to employee benefits. AW3 II6 T1, T4, T7, T8 Higher costs for the company. AW4 II7 T9, T12 Difficulties in product development due to insufficient staff. AW5 II8 T1, T8 Focus shifts from the German market to the Asian market. AW6 II3 T11 Due to the fact of the customer care center merge 20% of the Customer Care Center employees will resign from their job. Table 10 - Weaknesses 2.8.3 Opportunities The opportunities are identified from outside the organization. These are factors which affect the companies from outside. # Judged Affected Tactic Affects Influencer AO1 IE1 T7, T8, T9 There are more and more insurance companies which compete in the European insurance market which indicates in a higher rivalry. AO2 IE3 T9 Possibility to overtake another insurance company for low price. AO3 IE4 T2, T3, T12 Meet the customer needs and get a higher customer satisfaction. AO4 IE5 T6 Possibility to process faster, cheaper and more transparent insurance policies via internet  higher customer satisfaction. AO5 IE9 T4, T7, T9 Exchange possibilities of similar insurance products among different countries. Table 11 - Opportunities Elaborated by: Renato Melliger, Roger Böhlen, Marcel Dubach 08.06.2010 / Page 11 of 41
  • 12. Business Enterprise Architecture of the German Insurance Group 2.8.4 Threats The threats are identified from outside the organization. These are factors which affect the companies from outside. # Judged Affected Tactic Affects Influencer AT1 IE2, IE6, T5, T12, T13 Higher long-term costs for health treatments IE7 AT2 IE3 T8, T9 Risk for the expand strategy for the German Insurance Group Company AT3 IE4 T2, T4, T9, T12 High research, development and analysis costs. Much more administrative efforts to maintain the different products. AT4 IE5 T6 Losing direct personal contact with customers. AT5 IE8 T1 Losing customers and market shares. AT6 IE9 T7 Lower inhabitation threshold for a customer’s insurance company change. Table 12 - Threats 3 Vocabularies and Business Rules A vocabulary is described in document sub clause having glossary-like entries for concepts having representations in the vocabulary. The introduction to a vocabulary description includes the vocabulary’s name and can further include any of the several kinds of details like description, note etc. Following different vocabulary will be presented, which are used to define the business rules of the GIG company. The business rules of the German Insurance Group company are based on the different vocabularies and the fact types. 3.1 Language Dependent Vocabulary Certain term or name concepts are common descriptions which are not only valid for the German Insurance Group. For that reason the German Insurance Group reference common terms and names from the following sources: Business Dictionary Definition: An online vocabulary which defines business terms. Synonym: BD Reference Scheme: BD terms Link: http://www.businessdictionary.com A.M. Best Definition: An online vocabulary which defines insurance terms. Reference Scheme: A.M. Best terms Link: http://www.ambest.com/resource/glossary.html 3.2 Common Vocabulary The following vocabulary is a sub clause which illustrates some common SBVR vocabulary and has been adopted for the GIG company. 3.2.1 Numbers integer Definition: Number with no fractional part. 3.2.2 Time year Definition: A year is the time between two recurrences of an event related to the orbit of the earth around the Sun. Elaborated by: Renato Melliger, Roger Böhlen, Marcel Dubach 08.06.2010 / Page 12 of 41
  • 13. Business Enterprise Architecture of the German Insurance Group 3.2.3 Key Words and Phrases for Logical Formulations Key words and phrases are shown below for expressing each kind of logical formulation. The letters ‘p’ and ‘q’ represent expressions of propositions. 3.2.3.1 Quantification universal quantification Definition: Quantification that scopes over a logical formulation and that has the meaning. For each referent of the variable introduced by the quantification the meaning formulated by the logical formulation for the referent is true concept. Type: Logical formulation kind Necessity: Each universal quantification scopes over a logical formulation. Reference Scheme: The logical formulation that is scoped over by the universal quantification and the variable that is introduced by the universal quantification each universal quantification every universal quantification 3.2.3.2 Logical Operations conjunction Definition: Binary logical operation that formulates that the meaning of each of its logical operands is true Concept Type: Logical formulation kind Reference Scheme: The logical operand 1 of the conjunction and the logical operand 2 of the conjunction implication Definition: Binary logical operation that operates on an antecedent and a consequent and that formulates that the meaning of the consequent is true if the meaning of the antecedent is true Concept Type: Logical formulation kind Necessity: Each implication has exactly one antecedent. Necessity: Each implication has exactly one consequent. Reference Scheme: The antecedent of the implication and the consequent of the implication p and q conjunction q if p implication 3.2.3.3 Modal Operations obligation formulation Definition: Concept that specializes the concept ‘logical formulation’ and that classifies a logical formulation based on the presence or absence of a main logical operation or quantification it is obligatory that p obligation formulation necessity formulation Elaborated by: Renato Melliger, Roger Böhlen, Marcel Dubach 08.06.2010 / Page 13 of 41
  • 14. Business Enterprise Architecture of the German Insurance Group Definition: Modal formulation that formulates that the meaning of its embedded logical formulation is true in all possible worlds Concept Type: Logical formulation kind Reference Scheme: The logical formulation that is embedded in the necessity formulation must obligation formulation it is necessary that p necessity formulation 3.2.4 Other Key Words the 1. Used with a designation to make a pronominal reference to a previous use of the same designation. This is formally a binding to a variable of a quantification. 2. Introduction of a name of an individual thing or of a definite description. a, an Universal or existential quantification, depending on context based on English rules. a given Universal quantification pushed outside of a logical formulation where ‘a given’ is used such that it represents one thing at a time – this is used to avoid ambiguity where the ‘a’ by itself could otherwise be interpreted as an existential quantification. Within a definition, ‘a given’ introduces an auxiliary variable into the closed projection that formalizes the definition. that 1. When preceding a designation for a noun concept, this is a binding to a variable (as with ‘the’) 2. When after a designation for a noun concept and before a designation for a fact type, this is used to introduce a restriction on things denoted by the previous designation based on facts about them 3. When followed by a propositional statement, this used to introduce nominalization of the proposition or objectification, depending on whether the expected result is a proposition or an actuality is of The common preposition “of” is used as a shorthand for “that is of.” For any sentential form that takes the general form of ‘<placeholder 1> has <placeholder 2>’ there is an implicit reversed form of ‘<placeholder 2> is of <placeholder 1>’ that has the same meaning. 3.2.5 Categories of Business Rules The German Insurance Group company distinguishes between three different categories of business rules. Inference Definition: This business rule category derives new information form existing information. Constraint Definition: This business rule category makes assertions that have to be true, they reject any event that would cause a violation to occur. Process Definition: This business rule category enables, enforces or prevents actions. 3.2.6 Guidance Types Each entry in a rule set is an element of guidance. They are expressed as one of the following two. operative business rule Elaborated by: Renato Melliger, Roger Böhlen, Marcel Dubach 08.06.2010 / Page 14 of 41
  • 15. Business Enterprise Architecture of the German Insurance Group Definition: Governs what the business does. As soon as the process runs a result will be produced. structural business rule Definition: True by definition. For example: The GIG departments have three locations -> always three. 3.2.7 Levels of Enforcement Level of enforcement is a categorization scheme for business rules defined (or adopted) by the organization that owns the rules. GIG categories are listed below. Strict Definition: Strictly enforced: if the rule is violated, the sanction or other consequences always ensue. Deferred Definition: Deferred enforcement: strictly enforced, but enforcement may be delayed - e.g., waiting for resource with required skills. Pre-authorized Definition: Pre-authorized override: enforced, but exceptions allowed, with prior approval for actors with before-the-fact override authorization. Post-justified Definition: Post-justified override: if not approved after the fact, the sanction or other consequences will ensue. Override Definition: Override with explanation: comment must be provided when the violation occurs. Guideline Definition: Suggested, but not enforced. 3.3 GIG Concepts and Vocabulary The following sub chapter describes the business vocabulary of the German Insurance Group company. This vocabulary is used for a common understanding within the company. The following diagram illustrates the creation of concepts and related vocabulary mainly in the product development process. The boxes either describe a name- or a term concept. The relation between the boxes is the fact concept. The fact concept will be described together with the name- and terms concept. The orange boxes are described in the name concept 3.3.1. The blue boxes are described in the term concept 3.3.2. The red boxes define the concept type categorization type. The green box defines an individual concept EURO of the general concept currency. Elaborated by: Renato Melliger, Roger Böhlen, Marcel Dubach 08.06.2010 / Page 15 of 41
  • 16. Business Enterprise Architecture of the German Insurance Group improves ► skill development time has ▲ EURO currency Product running development Manager operates in ► Insurance Product ◄ is entered cost Product cost consults ► Imporovment on feedback Development Database Product operates in ► Developer Department has ▲ has ▲ Type by Indicator is : indicator type given ▲ gives key ▼ supports by ▼ informs ▼ develops ▼ development of value performance indicator board of amount of is derived directors deductable▲ by ▲ indicator type organization is interessting for ► customer function pays ► ◄ looks for Legal signs ► premium Department policy condition has ▼ in reference to ► has ▲ GIG Marketing insurance has ► Organization Department ◄ has product conducts ▼ insurance product Organization Unit by Function Product by Insurance Product Lifecycle lifecycle :organization function customer :insurance product lifecycle survey Type of Status of Operative Insurance Product : status of operative insurance status of operative is educated product insurance product on► new insurance reviews ► operative run -off Insurance product insurance insurance Agent product insurance product has ▼ product type is launched Names market on▼ Type of Insurance Product Type reassessed : insurance product type Terms non-reassessed insurance insurance product product categorization type is compatible individual concept with ► new is compatible new basic non-reassessed non-reassessed reassessed reassessed run -off run-off basic complementary with ► insurance complementary basic insurance complementary basic insurance complementary insurance insurance product product insurance product product insurance product product insurance product product Is compatible with ► Is compatible with ► Is compatible with ► Is compatible with ► Illustration 3 - GIG Concept Diagram 3.3.1 Name Concept Names are the descriptions of the blue boxes which are on Illustration 3 - GIG Concept Diagram GIG organization Definition: Name of the company Synonym: GIG Product Manager Source: BD [“product manager”] Necessity: Each product manager has one or more insurance products for which he/she is responsible. Note: The product manager is the leader of a group of product developers. Supporting fact types: Product Manager has skill Product Manager operates in Product Development Department Synonymous form: Product Development Department has Product Manager Product Developer Definition: A product developer helps to create/develop and maintain insurance products within the company. Necessity: Every product developer has exactly one product manager where s/he is reporting to. Elaborated by: Renato Melliger, Roger Böhlen, Marcel Dubach 08.06.2010 / Page 16 of 41
  • 17. Business Enterprise Architecture of the German Insurance Group Note: After a few years, the product developer has the chance to become a product manager. Supporting fact types: Product Developer has skill Product Developer operates in Product Development Department Product Developer develops new insurance product Synonymous form: Product Development Department has Product Developer new insurance product is developed by Product Developer Product Development Department Concept Type: organization function Source: BD [“product development”] Synonym: Product Development Necessity: The concept ‘product development department’ is included in Organization Units by Functions Note: The product development department is in addition responsible to reassess insurance products. Supporting fact types: Product Development Department consults Insurance Product Improvement Database Product Development Department reviews operative insurance product Product Development Department informs board of directors Synonymous form: Insurance Product Improvement Database is consulted by Product Development Department operative insurance product is reviewed by Product Development Department board of directors is inform by Product Development Department Legal Department Concept Type: organization function Definition: The legal department is the competence department for all legal questions and legal issues within the GIG. Necessity: The concept ‘Legal Department’ is included in Organization Units by Functions Necessity: Each policy condition has to be signed by the Legal Department Supporting fact types: Legal Department signs policy condition Legal Department reviews operative insurance product Elaborated by: Renato Melliger, Roger Böhlen, Marcel Dubach 08.06.2010 / Page 17 of 41
  • 18. Business Enterprise Architecture of the German Insurance Group Synonymous form: operative insurance product is reviewed by Legal Department Policy condition is signed by Legal Department Marketing Department Concept Type: organization function Definition: The Marketing Department is the organisation unit within the GIG company which is responsible for the preparation, planning and coordination of all marketing activities. Necessity: The concept ‘Marketing Department’ is included in Organization Units by Functions Necessity: For each new insurance product which is launched on the market a customer survey has to be conducted. Note: The marketing people operate the marketing department Supporting fact types: Marketing Department conducts customer survey Synonymous form: customer survey is conducted by Marketing Department Insurance Agent Source: A.M. Best [“agent”] Necessity: Every Insurance Agent has exactly one market. Note: The Insurance Agent is the interface to the customer. Synonym: Agent Synonym: Underwriter Supporting fact types: Insurance Agent is educated on new insurance product Insurance Agent has market Synonymous form: market belongs to Insurance Agent Insurance Product Improvement Database Definition: GIG database in which feedbacks from customers and improvements hints from different sources are stored. This database supports the Product Development Department in case of new product developments. Necessity: GIG has only one Insurance Product Improvement Database for the entire company. Note: The Insurance Product Improvement Database is a strategic factor for the product development process. Supporting fact types: Insurance Product Improvement Database supports development of new insurance product Product by Insurance Product Lifecycle Segmentation which is for the concept ‘insurance product’ and subdivides ‘insurance products’ based on product lifecycle. Elaborated by: Renato Melliger, Roger Böhlen, Marcel Dubach 08.06.2010 / Page 18 of 41
  • 19. Business Enterprise Architecture of the German Insurance Group Necessity: Product by Product Lifecycle contains the categories ‘new insurance product’, ‘operative insurance product’, ‘reassessed insurance product’. Organization Unit by Function Segmentation which is for the concept ‘GIG Organization’ and subdivides ‘GIG Organizations’ based on organization function. Necessity: Organization Unit by Function contains the categories ‘board of directors’, ‘Product Development Department’, ‘Legal Department’, ‘Marketing Department’. Type by Indicator Segmentation which is for the concept ‘key performance indicator’ and subdivides ‘key performance indicator’ based on indicator type. Necessity: Type by Indicator contains the categories ‘running cost’, ‘development cost’, ‘development time’. Type of Insurance Product Type Segmentation that is for the concept ‘new insurance product’, ‘reassessed insurance product’, ‘non-reassessed insurance product’ and ‘run-off insurance product’ and subdivides ‘new insurance product’, ‘reassessed insurance product’, ‘non-reassessed insurance product’ and ‘run-off insurance product’ based on insurance type. Necessity: Type of insurance type contains the categories ‘new complementary insurance product’, ‘new basic insurance product’, ‘non-reassessed complementary insurance product’, ‘non-reassessed basic complementary insurance product’, ‘reassessed complementary insurance product’, ‘reassessed basic complementary insurance product’, ‘run-off complementary insurance product’, ‘run-off basic complementary insurance product’. Type of Status of Operative Insurance Product Segmentation that is for the concept ‘operative insurance product’ and subdivides ‘operative insurance product’, based on status of the operative insurance product. Necessity: Type of status contains the categories ‘non-reassessed insurance product’ and ‘reassessed insurance product’. 3.3.2 Term Concept The blue as well as the red boxes are term concepts which are shown on Illustration 3 - GIG Concept Diagram. The blue boxes are general concepts where as the red boxes are the individual concepts. 3.3.2.1 General Term Concept Terms are the descriptions of the blue boxes which are on Illustration 3 - GIG Concept Diagram board of directors Source: BD [“board of directors”] Note: The GIG company directors board has 20 directors. Supporting fact types: board of directors is informed by Product Development Department Synonymous form: Product Development Department informs board of directors skill Source: BD [“skill”] Elaborated by: Renato Melliger, Roger Böhlen, Marcel Dubach 08.06.2010 / Page 19 of 41
  • 20. Business Enterprise Architecture of the German Insurance Group Note: People can improve their domain-general and domain-specific skills by advanced training in a certain area. customer survey Source: BD [“customer survey”] Note: A customer survey has a minimum of predefined public opinion poll. Supporting fact types: customer survey is conducted by Marketing Department Synonymous form: Marketing Department conducts customer survey market Source: BD [“market”] Note: A description of a market needs further information. A market can have different angle of vision. For example Asian market, complementary insurance market etc. Synonym: insurance market Supporting fact types: market has insurance product market belongs to Insurance Agent Synonymous form: new insurance product is launched on market Insurance Agent has market policy condition Source: A.M. Best [“coverage”] Synonym: policy condition Necessity: An insurance product has different policy conditions. Note: Each policy condition must be signed by the Legal Department. Supporting fact types: policy condition is signed by Legal Department policy condition belongs to insurance product Synonymous form: Legal Department is signed by policy condition insurance product has policy condition feedback Source: BD [“feedback”] Note: A feedback is information about a product improvement or product issue which has to be entered in the Insurance Product Improvement Database for future monitoring activities. Supporting fact types: feedback is entered in Insurance Product Improvement Database feedback is given by customer feedback in reference to insurance product feedback improves reassessed insurance product Synonymous form: customer gives feedback Elaborated by: Renato Melliger, Roger Böhlen, Marcel Dubach 08.06.2010 / Page 20 of 41
  • 21. Business Enterprise Architecture of the German Insurance Group insurance product is based on feedback reassessed insurance product is improved by feedback customer Source: BD (Definition 1) [“customer”] Synonym: client Necessity: A customer has always a relation to an Insurance Agent. Note: A GIG employee could be a customer. Supporting fact types: customer gives feedback customer pays premium customer looks for new insurance product customer has insurance product Synonymous form: feedback is given by customer premium is paid by customer insurance product is interesting for customer insurance product belongs to customer deductible amount Source: A.M. Best [“deductible”] Synonym: excess Note: A deductible amount is needed to keep the administrative effort as low as possible. If the deductible amount would be lower than 500 EURO the transaction costs would exceed the claims costs. value Source: BD (Definition 1) [“value”] Note: Value refers to price amount Supporting fact types: value has currency currency Source: BD [“currency”] Note: Has predefined population (see EURO 3.3.3) premium Synonym: insurance rate Definition: Regular payable insurance fee to hedge against the risk of sudden huge costs. Necessity: The premium of a policy has to be paid in one payment currency. Elaborated by: Renato Melliger, Roger Böhlen, Marcel Dubach 08.06.2010 / Page 21 of 41
  • 22. Business Enterprise Architecture of the German Insurance Group Supporting fact types: premium is derived by key performance indicator premium has currency premium is paid by customer premium belongs to insurance product Synonymous form: key performance indicator defines premium currency belongs to premium customer pays premium insurance product has premium insurance product Definition: A health care product to hedge against the risk of contingent health care costs. Necessity: Each insurance product has a product lifecycle. Note: GIG refers always to health insurance products if it speaks about insurance products. Supporting fact types: insurance product has amount of deductable insurance product has policy condition insurance product has premium insurance product has key performance indicator insurance product has deductable amount operative insurance product is reviewed by Legal Department Synonymous form: policy condition belongs to insurance product premium belongs to insurance product key performance indicator belongs to insurance product Legal Department reviews operative insurance product Concept type: is-property of fact type new insurance product Concept Type: product lifecycle Definition: The new insurance product is developed by the product developer. A new insurance product is interesting for a customer to have a protection against wealth losses or damages. The customer does payments in form of premiums for the insurance. Necessity: The concept ‘new insurance product’ is included in Product by product lifecycle Note: The Insurance Product Improvement Database supports the development of new products. Necessity: Every new insurance product has exactly one market Supporting fact types: new insurance product is launched on market Elaborated by: Renato Melliger, Roger Böhlen, Marcel Dubach 08.06.2010 / Page 22 of 41
  • 23. Business Enterprise Architecture of the German Insurance Group new insurance product is interesting for customer new insurance product is developed by Product Developer Synonymous form: customer looks for new insurance product Product Developer develops new insurance product Insurance Product Improvement Database supports development of new insurance product operative insurance product Concept Type: product lifecycle Definition: An operative insurance product is an insurance product which can be purchased from the GIG company. Note: All operative insurance products will be reassessment every two years after their launch. run-off insurance product Concept Type: product lifecycle Definition: A run-off insurance product is a product which was offered by the GIG company hut has been withdrawn from the market. The products have to be monitored as long as customers are still covered by such insurance product. Note: As soon as all contracts are run-off the products can be archived. reassessed insurance product Concept Type: product lifecycle Definition: Every two year an operative insurance product has to be reviewed. If a product has been reviewed at least once and is still available it belongs to the group reassessed insurance product. Supporting fact types: reassessed insurance product is improved by feedback Synonymous form: feedback improves reassessed insurance product non-reassessed insurance product Concept Type: product lifecycle Definition: Every two year an operative insurance product has to be reviewed. If a product has not been reviewed so far it belongs to the group non- reassessed insurance product. Note: Feedback can’t improve those insurance products because they have never been reviewed. new basic insurance product Concept Type: insurance product type Definition: new insurance product that can single-handed be ordered. Note: This new insurance product can be ordered without the need to buy other insurance products. Elaborated by: Renato Melliger, Roger Böhlen, Marcel Dubach 08.06.2010 / Page 23 of 41
  • 24. Business Enterprise Architecture of the German Insurance Group Supporting fact types: new basic insurance product is compatible with non-reassessed complementary insurance product new basic insurance product is compatible with reassessed complementary insurance product new basic insurance product is compatible with new complementary insurance product new complementary insurance product Concept Type: insurance product type Definition: New insurance products which can be attached to basic insurance products in order get additional coverage than only with the standard insurance coverage. Supporting fact types: new complementary insurance product is compatible with new basic insurance product new complementary insurance product is compatible with non- reassessed insurance product new complementary insurance product is compatible with reassessed insurance product reassessed basic insurance product Concept Type: insurance product type Definition: Reassessed basic insurance products are basic insurance products which have already been reassessment at least once by the Legal- and Product Development- Department. reassessed basic insurance product is compatible with new complementary insurance product reassessed basic insurance product is compatible with non- reassessed complementary insurance product reassessed basic insurance product is compatible with reassessed complementary insurance product reassessed complementary insurance product Concept Type: insurance product type Definition: Reassessed complementary insurance products are complementary insurance products which have already been reassessment at least once by the Legal- and Product Development- Department. reassessed complementary insurance product is compatible with new basic insurance product reassessed complementary insurance product is compatible with non- reassessed basic insurance product reassessed complementary insurance product is compatible with reassessed basic insurance product run-off basic insurance product Elaborated by: Renato Melliger, Roger Böhlen, Marcel Dubach 08.06.2010 / Page 24 of 41
  • 25. Business Enterprise Architecture of the German Insurance Group Concept Type: insurance product type Definition: Basic insurance products which have been withdrawn from the market by the GIG company. This product will no longer be sold but there are still some customers which have coverage by such a basic insurance product. run-off complementary insurance product Concept Type: insurance product type Definition: Complementary insurance products which have been withdrawn from the market by the GIG company. This product will no longer be sold but there are still some customers which have coverage by such a complementary insurance product. key performance indicator Definition: An indicator with high relevance that affects the premium of a new insurance product. Note: All key performance indicators create the basis for the premium of a new insurance product. Supporting fact types: key performance indicator derives premium Synonymous form: premium is derived by key performance indicator development cost Concept Type: indicator type Definition: Cost as a key performance indicator that emerges during the development period of a product. running cost Concept Type: indicator type Definition: Cost as a key performance indicator that emerges during the product life cycle. Note: The product life cycle starts when the insurance product is launched on the market and ends when the sale of the insurance product stops. development time Concept Type: indicator type Definition: Duration as a key performance indicator that emerges during the product development period of a product. 3.3.2.2 Categorization Type Terms are the descriptions of the red boxes which are on Illustration 3 - GIG Concept Diagram A categorization type is a concept whose instances are, or are in one-to-one correspondence with, meaningful-to- the business categories of another concept. A categorization type is either partial or complete. It is complete if it necessarily categorizes everything of the general concept that it is for. organization function Concept type: categorization type Elaborated by: Renato Melliger, Roger Böhlen, Marcel Dubach 08.06.2010 / Page 25 of 41
  • 26. Business Enterprise Architecture of the German Insurance Group Definition: Concept that specializes the concept ‘GIG Organization’ and that classifies an organization function based on different units inside an organization. indicator type Concept Type: categorization type Definition: Concept that specializes the concept ‘key performance indicator’ and that classifies the key performance indicators based on the period of time the key performance indicator is relevant and if the key performance indicator is a time indicator or a cost indicator. insurance product type Concept Type: categorization type Definition: Concept that specializes the concepts ‘new insurance product’, ‘reassessed insurance product’, ‘non-reassessed insurance product’ and ‘run-off insurance products’ and that classifies these insurance products based on if the insurance product can be ordered by itself or not. Note: Some (complementary) products can only be ordered in combination with other (basic) products. insurance product lifecycle Concept type: categorization type Definition: Concept that specializes the concept ‘insurance product’ and that classifies an insurance product lifecycle based on the phase in which an insurance product stays at the moment. status of operative insurance product Concept Type: categorization type Definition: Concept that specializes the concepts ‘operative insurance product’ that classifies these insurance products based on the fact if the product was already reassessed or not. 3.3.3 Individual Concept The individual concept is the description of the green box which is shown on Illustration 3 - GIG Concept Diagram. Euro Concept type: individual concept General concept: currency Synonym: EUR 3.4 Product Development Rules of GIG In the following sub chapter the business rules of the German Insurance Group company are presented. The business rules are described with the following attributes: The ‘Category of Business Rule’ is a common classification of business rules. The different business rule classifications are described in the sub chapter 3.2.5. The ‘Guidance Type’ caption is used to indicate the kind of element of guidance. The different guidance types are described in the sub chapter.3.2.6 The ‘Description’ caption is used to capture the expression of the element of guidance informally (as supplied by a business user). Elaborated by: Renato Melliger, Roger Böhlen, Marcel Dubach 08.06.2010 / Page 26 of 41
  • 27. Business Enterprise Architecture of the German Insurance Group The ‘Note’ caption is used to label explanatory notes. The ‘Enforcement Level’ caption labels the enforcement level that applies to an operative business rule. The different enforcement levels are described in the sub chapter. 3.2.7. The ‘Fact Type’ is an expression that can be substituted for a simple statement expressed using a fact type form of the fact type. Fact types are directly defined together with the terms and names in chapter 3.3. Color Legend: Term: The ‘term’ font is used for a designation for a noun concept (other than an individual concept), one that is part of a vocabulary being used or defined Name: The ‘name’ font is used for a designation of an individual concept — a name Verb: The ‘verb’ font is used for designations for fact types Keyword: The ‘keyword’ font is used for linguistic symbols used to construct statements – the words that can be combined with other designations to form statements and definitions Rule 1: Rule: During the product life cycle it is obligatory that the Product Development Department and the Legal Department review the operative insurance products every 2 years. Category of Business Rule: Process Guidance Type: structural business rule Description: During the life cycle of a insurance product, the Product Development Department and the Legal Department have to review at least every two years the policy conditions and the insurance product in general. Note: The Product Development Department and Legal Department are responsible to proactively monitor the deadline of two the years. This is one of their main tasks. Enforcement Level: Strict Fact Type: insurance product has product life cycle Product Development Department reviews insurance product Legal Department reviews insurance product operative insurance product specializes insurance product Rule 2: Rule: Before a new insurance product is launched on the market, it is obligatory that the Marketing Department has to conduct a customer survey. Category of Business Rule: Process Guidance Type: structural business rule Description: The Marketing Department tests the acceptance of new insurance products on the market with a customer survey. Elaborated by: Renato Melliger, Roger Böhlen, Marcel Dubach 08.06.2010 / Page 27 of 41
  • 28. Business Enterprise Architecture of the German Insurance Group Note: There are no guidelines how the Marketing Department has to execute this costumer survey. The department can always change the way of conducting the customer survey. Enforcement Level: Override Fact Type: new insurance product is launched on market new insurance product specializes insurance product Marketing Department conducts customer survey Rule 3: Rule: Each given feedback by costumers in reference to the insurance products must be entered on the Insurance Product Improvement Database. Category of Business Rule: Constraint Guidance Type: operative business rule Description: The feedbacks of customers are part of the product development process. For that reason it is very important, that customer feedbacks are gathered on a central database for future products and product improvements. Note: The Product Development Department is responsible to consult the Insurance Product Improvement Database for future products. Note: Each employee who gathers a feedback about an insurance product from a customer is obliged to enter the feedback to the Insurance Product Development Database. Enforcement Level: Strict Fact Type: feedback in reference to insurance products feedback is given by customer feedback is entered in Insurance Product Improvement Database Rule 4: Rule: It is obligatory that the Legal Department signs the policy conditions of a new insurance product before it can be launched on the market. Category of Business Rule: Process Guidance Type: structural business rule Description: A prerequisite before a new insurance product can be launched is that the Legal Department has signed off the policy conditions and the go live for all other legal questions about the insurance product have the agreement from the Legal Department Note: The sign of which the Legal Department has to do is one of the most important steps and milestone in the product development process. Enforcement Level: Strict Fact Type: Legal Department signs policy condition insurance product has policy condition Elaborated by: Renato Melliger, Roger Böhlen, Marcel Dubach 08.06.2010 / Page 28 of 41
  • 29. Business Enterprise Architecture of the German Insurance Group new insurance product is launched on market new insurance product specializes insurance product Rule 5: Rule: Each new basic insurance product must be compatible with new complementary insurance product and non-complementary insurance product and reassessed complementary insurance products. Category of Business Rule: Constraint Guidance Type: structural business rule Description: When a new basic insurance product is in the development phase it has always to be compatible with the already existing complementary insurance products which are offered by other competitors and our own products. Enforcement Level: Strict Fact Type: new basic insurance product is compatible with new complementary insurance product new basic insurance product is compatible with non-reassessed complementary insurance product new basic insurance product is compatible with reassessed complementary insurance product new basic insurance product specializes new insurance product non-reassessed insurance product specializes operative insurance product reassessed insurance product specializes operative insurance product Rule 6: Rule: For each insurance product exactly one of the deductible amount must be chosen from: 500, 1000, 2000 Euro per year. Category of Business Rule: Constraint Guidance Type: operative business rule Description: Each insurance product has a deductible amount. The different deductible amounts for new insurance products must be either 500, 1000 or 2000 Euro per year. Note: Customer is able to change the deductible amount after each year. Enforcement Level: Strict Fact Type: insurance product has deductible amount deductable amount is in Euro Rule 7: Rule: If the key performance indicators of a new insurance product are violated it is obligatory that the board of directors has to be informed by the Product Development Department. Elaborated by: Renato Melliger, Roger Böhlen, Marcel Dubach 08.06.2010 / Page 29 of 41
  • 30. Business Enterprise Architecture of the German Insurance Group Category of Business Rule: Process Guidance Type: structural business rule Description: This rule avoids too high development costs of a new insurance product. Note: New developments of insurance products are not allowed to exceed a certain amount of development costs. This amount is a mixture between development time, development costs and running costs. Enforcement Level: Strict Fact Type: insurance product has key performance indicator new insurance product specializes insurance product Product Development Department informs board of directors Rule 8: Rule: The premium of a new insurance product must be derived by the key performance indicators: development time, development costs, running costs. Category of Business Rule: Inference Guidance Type: operative business rule Description: To set a premium for a new insurance product the price is based on the key performance indicators. Note: Running costs are extrapolated in advance before the new insurance product is launched. At the year end an adjustment is undertaken for each insurance product due to the increasing of costs in the health sector. Enforcement Level: Pre-authorized Fact Type: insurance product has premium premium is derived by key performance indicator new insurance product specializes insurance product development time specializes key performance indicator development cost specializes key performance indicator running cost specializes key performance indicator insurance product has key performance indicator Rule 9: Rule: It is necessary that the Insurance Agent is educated on the new insurance product before it is launched on the market. Category of Business Rule: Process Guidance Type: structural business rule Description: Before a new insurance product is presented to potential customer the Insurance Agents must be trained and educated on the new insurance product. Elaborated by: Renato Melliger, Roger Böhlen, Marcel Dubach 08.06.2010 / Page 30 of 41
  • 31. Business Enterprise Architecture of the German Insurance Group Note: Prospectuses and booklets will be handed out to the Insurance Agents during the training sessions. Enforcement Level: Override Fact Type: Insurance Agent is educated on new insurance product new insurance product is launched on market Insurance Agent has market new insurance product specializes insurance product 4 Models In the following chapter the process map, the business processes, the working environment model, the IT system model and the document model of the product development will be presented. A few comments about the models Swim lanes: Swim lanes have been used in the following manner. If the activities were linkable to a identified role the name of the role was used for the swim lane. If the activity of the task was not clear assignable to a clear role the department name has been assigned to the swim lane. Data object: When a data object follows the process an additional document flow will not be created for the processes. The only exceptions are when the data object is created in a sub task and flows in to a later activity. In this case the document flow has been designed. Sources for process: For each process a short statement is given where the information of the process is coming from. The sources which were available for the processes were the interviews of the GIG company, in addition the business rules which have been defined in the sub chapter 3.4 Product Development Rules of GIG. Over all the following interviews were considered regarding the product development process: 2, 4, 5, 12, 19, 23, 26. But most of the relevant interview content were modeled in a more coarse-grained way. At the same time some adjustments were done to get a consistent overall picture about the development processes. Relationship between Activities and IT Systems: All processes were modeled without directly include the supported IT system in activities. The idea was to separately model the IT systems in the IT system model and afterwards to reference from activities (in the process model) to IT systems in the IT system model. Due to the fact that Adonis does not support this feature at this time, this relationship is missing yet. 4.1 Process Map The following process map presents the GIG Product Department process map. It is composed of three main processes. The Evaluation process contains the decision if a new insurance product should be implemented or not. To make a proper decision, different information, like a customer survey or a draft for a marketing budget has to be gathered. If the decision has been made to realize the new insurance product, the Implementation process will be executed. This process covers all procedures to realize the product. That means the implementation in the IT systems as well as legal (like the check for brand name) and marketing aspects. The implementation of a project will be organized in a project, for that reason different IT project steps are also designed in the implementation process. Finally the Maintenance process helps to keep the already existing insurance products up to date through reviews and provides figures out of the current insurance products for the Actuary- and Controlling Department. Illustration 4 - GIG Product Development Process Map Elaborated by: Renato Melliger, Roger Böhlen, Marcel Dubach 08.06.2010 / Page 31 of 41
  • 32. Business Enterprise Architecture of the German Insurance Group 4.2 Business Process Model In the following sub chapter the Evaluation, Implementation and Maintenance process of the product development department will be introduced. Because the main processes have different sub processes, these sub processes will be explained too. 4.2.1 Evaluation Process During the evaluation process a new insurance product is evaluated by the Product Developer. The task assignment is given by the supervisor of the Product Developer, the Product Manager. The objective of the process is to elaborate a product order. The product order contains a few information how the new insurance product could look like. To find out if a product is needed and it is worthy to realize it, a customer survey about the new product will be conducted and a marketing budget for the new insurance product would be set up. At the end of the process the decision will be made if the insurance product will be realized or not. This decision depends on the elaborated analysis of the evaluation process. The final decision whether the project is realized or not is made by the Product Decision Board. Process source information: Interview 4 Illustration 5 - GIG Product Development Evaluation Process 4.2.1.1 Sub Process Gather Information In the sub process Gather information the insurance product is drafted and a product proposal is created. The process shows in detail the different documents which are produced (by the product developer, legal and marketing department) or used for different activities. Process source information: Interview 4 Illustration 6 - GIG Product Development Gather Information Sub Process of the Evaluation Process 4.2.1.1.1 Sub Process Conduct Customer Survey The process Conduct customer survey shows how a customer survey is conducted to support the decision if a new insurance product should be realized. Before this customer survey can be done the border for the new insurance product must be defined. 250 customer surveys are necessary for a significant result. The result of the customer survey is a document called customer survey result document which flows into the product proposal. Elaborated by: Renato Melliger, Roger Böhlen, Marcel Dubach 08.06.2010 / Page 32 of 41
  • 33. Business Enterprise Architecture of the German Insurance Group Process source information: Business rule 2 Illustration 7 - GIG Product Development Conduct Customer Survey Sub Process of the Gather Information Process 4.2.1.1.2 Sub Process Plan Marketing Budget The process Plan marketing budget is executed to get the estimated costs for the marketing of the new insurance product. The most important point to evaluate the costs is to define the region / area where the new insurance product should be launched. All the other costs can afterwards easily be extracted from before launched products. The most important document which is produced in this sub task is the product marketing budget which flows into the product proposal. Process source information: Interview 15 Illustration 8 - GIG Product Development Plan Marketing Budget Sub Process of the Gather Information Process 4.2.2 Implementation Process The Implementation process is executed to implement the new insurance product which has been elaborated during the evaluation phase. As a first major step during the process the IT Department checks whether the new insurance product can be implemented or not. If it is not possible to implement the new product an economical statement has to be written. The statement covers all the costs which would be necessary to implement the new product on the IT systems. Based on the economical statement it would be decided if it is worthy to implement the product, if not the project will be stopped. If it is no problem to implement the product into the IT system, the process will go to the next step. The next step inside the process is the estimation and execution of the implementation project for the new insurance product. Both processes are described in subtasks. Process source information: Elaborated by: Renato Melliger, Roger Böhlen, Marcel Dubach 08.06.2010 / Page 33 of 41
  • 34. Business Enterprise Architecture of the German Insurance Group Illustration 9 - GIG Product Development Implementation Process 4.2.2.1 Sub Process Estimate Project Effort The first tasks inside the process Estimate project effort are the review of the figures from former implemented products. Out of this information work packages can be defined by the Product Developer. With the information about the packages the Project Management Office (PMO) are assigned to define the overall efforts which are needed from the different departments to implement the new product. If the total effort is higher than 40 full time equivalent (FTE) a sign off from the Executive Board of IT is necessary. The PMO plans afterwards the different resources for the packages and sends a note to the Product Developer as soon as all work is done. Process source information: Illustration 10 - GIG Product Development Estimate Project Effort Sub Process of the Implementation Process 4.2.2.2 Sub Process Execute Product Development Project The process Executes product development project is the physical process of a new product implementation. As soon as this process is started the key performance indicators are monitored every day. If one of the key performance indicator is violated the Board of Directors is informed. They decide afterwards if the project will be continued or cancelled. The product proposal which has been elaborated during the evaluation process is reviewed again and additional details are added to the document. Afterwards the Marketing Department also reviews the document and signs the document off. After the final sign off by the Marketing Department the product proposal document is forwarded to the Legal Department. They check then the product proposal for brand names, which is described in a sub Elaborated by: Renato Melliger, Roger Böhlen, Marcel Dubach 08.06.2010 / Page 34 of 41
  • 35. Business Enterprise Architecture of the German Insurance Group process, and forward it again to the Product Developer who does the final changes on the document. The document needs afterwards the final sign off from the Legal Department. This is a critical step in the process. In addition the product proposal will be renamed to product definition due to the final status. The product proposal is afterwards handed over to the IT Department for the IT realization. After the realization the Insurance Agents are trained on the new product and a memo is written internally about the new product. After all the Mathematics and Actuary Department calculate a premium price for the product and the Board of Directors gives the sign off for the product start. Process source information: Business rules 7, 8, 9 Illustration 11 - GIG Product Development Execute Product Development Project Sub Process of the Implementation Process 4.2.2.2.1 Sub Process Check for Product Compatibility The sub process Check for product compatibility is a control sub process to clarify whether the new defined insurance product is compatible with the previous defined insurance products. This is very important because a basic insurance product must be compatible with the complementary insurance product. Process source information: Business rules 5 Illustration 12 - GIG Product Development Check for Product Compatibility Sub Process of the Execute Product Development Project Sub Process 4.2.2.2.2 Sub Process Check for Brand Name The different brand names which are used in the product proposal are checked by the Legal Department if the names are not used for any other products. Elaborated by: Renato Melliger, Roger Böhlen, Marcel Dubach 08.06.2010 / Page 35 of 41
  • 36. Business Enterprise Architecture of the German Insurance Group Process source information: Interview 19 Illustration 13 - GIG Product Development Check for Brand Name Sub Process of the Execute Product Development Project Sub Process 4.2.3 Maintenance Process The Maintenance process is split in two different processes. Answer request is covered in one process and in the other maintenance process Product review is covered. 4.2.3.1 Process Answer Request Request about insurance product parameters are handled by the Mathematics / Actuary Department. If the incoming question gives good hints for product improvements, a new record will be opened in the Insurance Improvement Database. For product improvements and new products the Insurance Improvement Database is one of the sources for new ideas. Process source information: Interview 2, Business rule 3 Illustration 14 - GIG Product Development Answer request Process 4.2.3.2 Process Product Review Every second year or on demand an insurance product is reviewed by the Product Development Department. This review should check whether the policy conditions are still up to date and if the insurance product parameters are still valid, it is also checked if the product is still profitable. If a deviation is present the issues will be fixed by using the sub processes Estimate project effort and Execute product development project. Another decision of the Product Developer could be to decommission the insurance product. Process source information: Business rules 1 Elaborated by: Renato Melliger, Roger Böhlen, Marcel Dubach 08.06.2010 / Page 36 of 41
  • 37. Business Enterprise Architecture of the German Insurance Group Illustration 15 - GIG Product Development Product review Process 4.2.3.2.1 Sub Process Analyse Status The sub process Analyse status is executed to update the knowledge about the insurance product. If the Legal Department suggests to change the policy conditions they will be directly amended. If changes in the IT systems must be done the IT Department executes them directly. Process source information: Interview 23 Illustration 16 - GIG Product Development Analyse status Sub Process of the Product review Process 4.2.3.2.2 Sub Process Calculation The sub process Calculation is executed to investigate the current parameters of the product. The parameters are responsible for the cost estimation of the premium on the product. Process source information: Interview 2 Elaborated by: Renato Melliger, Roger Böhlen, Marcel Dubach 08.06.2010 / Page 37 of 41
  • 38. Business Enterprise Architecture of the German Insurance Group Illustration 17 - GIG Product Development Calculation sub process of Analyse status sub process 4.3 Working Environment Model The working environment model shows all departments, teams and individual employees who are related to the product development process of the German Insurance Group company. Employees are performing roles which are linked to the document and processes model. Illustration 18 - GIG Product Development Working Environment Model 4.4 IT Systems Model The IT system model shows all application which are currently in use by the German Insurance Group company. Especially highlighted are the application / services / infrastructure elements which are used for the product development process. Elaborated by: Renato Melliger, Roger Böhlen, Marcel Dubach 08.06.2010 / Page 38 of 41
  • 39. Business Enterprise Architecture of the German Insurance Group Illustration 19 - GIG Product Development IT System Model 4.5 Document Model The document model shows all different document which are either created during the different activities in the processes or flow into the activities for decision purposes. The documents are split by the different departments. Elaborated by: Renato Melliger, Roger Böhlen, Marcel Dubach 08.06.2010 / Page 39 of 41
  • 40. Business Enterprise Architecture of the German Insurance Group Illustration 20 - GIG Product Development Document Model 5 Limits of ADONIS Adonis unfortunately has some restrictions. Here is a list with the restrictions which have been identified during the assignment:  It should be possible to link activities with roles  It should be possible to link data objects which are used on the processes with the Document Model  It should be possible to link systems from the IT System Model with activities  The process map should be linkable with the processes This list only provides some useful functionality which would help to support the activity of process design with BPMN. Directories / Glossary In the following chapter the illustration and table directory will be summarized. In addition a glossary about mentioned words in this document are listed. Illustration Directory Illustration 1 - Zachman Framework..........................................................................................................................5 Illustration 2 - Business Motivation Model.................................................................................................................6 Illustration 3 - GIG Concept Diagram......................................................................................................................16 Illustration 4 - GIG Product Development Process Map..........................................................................................31 Illustration 5 - GIG Product Development Evaluation Process................................................................................32 Illustration 6 - GIG Product Development Gather Information Sub Process of the Evaluation Process..................32 Illustration 7 - GIG Product Development Conduct Customer Survey Sub Process of the Gather Information Process 33 Illustration 8 - GIG Product Development Plan Marketing Budget Sub Process of the Gather Information Process 33 Illustration 9 - GIG Product Development Implementation Process........................................................................34 Illustration 10 - GIG Product Development Estimate Project Effort Sub Process of the Implementation Process. .34 Elaborated by: Renato Melliger, Roger Böhlen, Marcel Dubach 08.06.2010 / Page 40 of 41
  • 41. Business Enterprise Architecture of the German Insurance Group Illustration 11 - GIG Product Development Execute Product Development Project Sub Process of the Implementation Process..........................................................................................................................................35 Illustration 12 - GIG Product Development Check for Product Compatibility Sub Process of the Execute Product Development Project Sub Process..........................................................................................................................35 Illustration 13 - GIG Product Development Check for Brand Name Sub Process of the Execute Product Development Project Sub Process..........................................................................................................................36 Illustration 14 - GIG Product Development Answer request Process......................................................................36 Illustration 15 - GIG Product Development Product review Process.......................................................................37 Illustration 16 - GIG Product Development Analyse status Sub Process of the Product review Process...............37 Illustration 17 - GIG Product Development Calculation sub process of Analyse status sub process......................38 Illustration 18 - GIG Product Development Working Environment Model................................................................38 Illustration 19 - GIG Product Development IT System Model..................................................................................39 Illustration 20 - GIG Product Development Document Model..................................................................................40 Table Directory Table 1 - Cell Analysis of the Zachman Framework..................................................................................................5 Table 2 - Goals..........................................................................................................................................................8 Table 3 - Objectives...................................................................................................................................................9 Table 4 - Mission.......................................................................................................................................................9 Table 5 - Strategy......................................................................................................................................................9 Table 6 - Tactics......................................................................................................................................................10 Table 7 - External Influencer....................................................................................................................................10 Table 8 - Internal Influencer.....................................................................................................................................11 Table 9 - Strengths..................................................................................................................................................11 Table 10 - Weaknesses...........................................................................................................................................11 Table 11 - Opportunities..........................................................................................................................................11 Table 12 - Threats...................................................................................................................................................12 Table 13 - Glossary.................................................................................................................................................41 Glossary AOK One of the biggest health insurances within Germany, Allgemeine Ortskrankenkasse AXA French insurance company for personal as well as enterprise insurances BMM See Business Motivation Model BPMN Business Process Modeling Notation Business Motivation The Business Motivation Model provides a scheme or structure for developing, Model communicating and managing business plans in an organized manner. Business Rule Is an adopted standard of the Object Management Group (OMG) intended to be the Manifesto basis for a formal and detailed natural language declarative description of a complex entity, such as a business. CHI China Health Insurance (Health insurer in China) Course of action Is an approach or plan for configuring some aspects of the enterprise involving things, processes, locations, people, timing, or motivation undertaken to achieve desired results. CRM Customer relationship management Ends Are things the enterprise wishes to achieve FAQ Friendly Asked Questions GIG German Insurance Group ISO 9001:2000-12 The International Organization for Standardization is an international-standard-setting body composed of representatives from various national standards organizations LoB Line of Business -> Insurance expression for the different products like motor, health etc. Means Are things the enterprise will employ to achieve the Ends OMG Object Management Group is a consortium, originally aimed at setting standards for distributed object-oriented systems, and is now focused on modeling (programs, systems and business processes) and model-based standards. PMO Project Management Office SBVR Semantic for Business Vocabulary and Business Rules Zachman Framework Overview about the enterprise architecture. Gives information about what has to be addressed. Table 13 - Glossary Elaborated by: Renato Melliger, Roger Böhlen, Marcel Dubach 08.06.2010 / Page 41 of 41

×