Modelling Business Capabilities withEnterprise Architecture

A Case Study at a Swedish Pension Managing Company

SOFIA BERGSTROM

Master’s Degree ProjectStockholm, Sweden September 2015

TRITA-EE 2015:69

Modelling Business Capabilities with

Enterprise Architecture

A Case Study at a Swedish Pension Managing

Company

Sofia Bergstrom

A Master Thesis Report written at

Department of Industrial Information and Control Systems

KTH Royal Institute of Technology

Stockholm, Sweden

September, 2015

Abstract: This master thesis looks at the use of business capabilities within enterprisearchitecture, and investigates how the concept is used within the Swedish pension managingcompany Folksam. Based on interviews with stakeholders an enterprise architecture meta-model centred on the business capability is constructed. The meta-model is then edited andrevised according to a questionnaire aimed at removing irrelevant elements, and a secondset of interviews discussing a capability’s health status and well being. This second set ofinterviews resulted in the removal of elements not affecting the well being of a capability.The final meta-model has the business capability and the capability health status at itscore. It consists of the Capability element, with two attributes, surrounded by nine otherelements connected by eleven relations in total.

Sammanfattning: Detta examensarbete undersoker hur verksamhetsformagor anvandsinom enterprisearkitektur, och vidare hur formage-konceptet anvands pa det svenska pen-sionsforetaget Folksam. Baserat pa intervjuer med intressenter skapas en metamodell medverksamhetsformagan i centrum. Metamodellen revideras och andras sedan enligt ett frage-formular vars mal var att ta bort ej relevanta element, och enligt en andra omgang intervjuerdar en formagas halsa diskuteras. Denna andra omgang intervjuer resulterade i att elementsom inte paverkade formagans halsa togs bort. Den slutgiltiga metamodellen har verk-samhetsformagan och dess halsostatus i fokus. Den bestar av formage-elementet, med tvaattribut, omgardat av nio andra element som binds ihop av totalt elva olika relationer.

Keywords: Enterprise Architecture, Business Capabilities, Meta-modelling, Health Status,Case Study

Table of Contents

1 INTRODUCTION 51.1 Folksam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 MAIN OBJECTIVE 62.1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2 Delimitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3 THEORY 73.1 Enterprise Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.2 Enterprise Architecture Modelling . . . . . . . . . . . . . . . . . . . . . . . . 103.3 Business Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.4 Business Capabilities and Modelling within this Research . . . . . . . . . . . 15

4 METHOD 164.1 Step 1 - Initial Interviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.2 Step 2 - Meta-Model Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.3 Step 3 - Meta-Model Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . 184.4 Step 4 - Meta-Model Editing and Finalisation . . . . . . . . . . . . . . . . . . 19

5 DATA 205.1 Step 1 - Initial Interviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205.2 Step 2 - Meta-Model Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . 245.3 Step 3 - Meta-Model Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . 265.4 Step 4 - Meta-Model Editing and Finalisation . . . . . . . . . . . . . . . . . . 30

6 RESULTS 326.1 Element: Capability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326.2 Element: Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326.3 Element: Competence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336.4 Element: Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336.5 Element: KPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336.6 Element: Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346.7 Element: Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346.8 Element: Requirement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346.9 Element: Resource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356.10 Attribute: Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356.11 Attribute: Health Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

7 ANALYSIS 367.1 Elements Relevant to Connect to the Capability . . . . . . . . . . . . . . . . 367.2 Why Connect Capabilities to Other Elements? . . . . . . . . . . . . . . . . . 447.3 Affecting or affected? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447.4 A Healthy Capability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

8 DISCUSSION 468.1 Interview Difficulties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468.2 Definition Differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

9 CONCLUSIONS 479.1 Future Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3

A Interviews 50A.1 Interview set 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50A.2 Intervierw set 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

4

1 INTRODUCTION

When working with enterprise architecture, there are several ways to describe a company.Depending on the purpose or the intended recipient, for example, three ways to describe acompany can be to use the Who?, How?, or What? views. By asking Who?, one might endup with a description of who runs the company, chains of command, personal responsibilities,or an employee structure. If the question is How?, the answer could be the company’sprocesses or production chains, showing how value is produced at the company. These aretwo common ways to describe companies, ways that have been used for many years andprobably will be used for years to come.

To answer the question What?, companies have since the early 2000’s started usinga concept called Business Capabilities. These capabilities define what a company does,and each capability can be decomposed into more specific capabilities. For example, the”Procurement Management” capability could be decomposed into the capabilities ”VendorManagement” and ”Manage Product Acquisition”, which in turn could be decomposed evenfurther.

This report looks at the concept of business capabilities and its use within the Swedishinsurance company Folksam. A study is carried out concerning what capabilities are usedfor at Folksam today as well as what they could be used for in the future, and an enterprisearchitecture meta-model is constructed based on the findings from the study.

1.1 Folksam

Folksam is a Swedish insurance company with 3900 employees and 4 million customers. Thecompany was founded in 1908, and is now insuring every second person in Sweden. Folksamis a mutual company, which means that the customers own the company, and any profitgoes back to the company and the customers, instead of being handed out to shareholders.Apart from personal risk insurance Folksam also provides pension investments and propertyand casualty insurance. The company is divided into three separate business areas - Private,Partner, and Collective Agreement - which operate across 11 different firms [8],[15].

5

2 MAIN OBJECTIVE

The main objective of this master’s thesis was to create an enterprise architecture meta-model with regards both to the business capabilities within Folksam, and the differentdepartmental needs within the company. The meta-model should also encompass the healthstatus of the capability. Therefore, the main objective of this thesis consisted of two parts,seen below.

1. Create a meta-model for Folksam’s business capabilities, meeting the ex-pectations and fulfilling the requirements of identified stakeholders.

2. Modify the meta-model so that it encompasses the stakeholders’ views onbusiness capability health status.

Research was conducted through literature studies, interviews with stakeholders, and thecreation and test of a meta-model. The results are documented in this report.

2.1 Scope

Folksam is currently in the process of creating a new, company-wide map of their businesscapabilities. As a part of the process, this report looked at what views the different stake-holders have of the business capability concept. They were asked how they would like to usethe business capabilities, what they might have used them for before, and what they wouldlike to be able to connect and relate them to in order to achieve these applications. Theaim was to create a meta-model that can be of use at Folksam when creating this map, andto provide a perspective from outside the company.

2.2 Delimitations

To be able to participate in the study, the Enterprise Architect Team Leader deemed itnecessary that, the respondents had to have some previous insight into the work with ca-pabilities, since Folksam are still working with how to use capabilities. It was therefore hertask to find suitable stakeholders to interview for this study.

6

3 THEORY

3.1 Enterprise Architecture

Enterprise architecture can be described as the practice of performing, among other things,enterprise analysis, planning, and design, with the goal of easing the execution of companystrategies used to steer decision-making towards creating a desired architecture state [11],[5].It has emerged since the early 2000’s as an integral part of governance and transformationswithin a company, striving to provide a common ground for it for all the company’s stake-holders [23]. In the book Enterprise Architecture: Modelling, Communication and AnalysisMarc Lankhorst et al. compare the aims of enterprise architecture to the practises of archi-tecture when it comes to buildings and construction: there you have a common framework,since everyone knows what ”room”, ”door” or ”window” refers to, which makes for efficientcommunication [20]. In a similar way, the ISO 42010:2011 standard pertains to systems andsoftware engineering, and describes architecture in that context as ”fundamental conceptsor properties of a system in its environment embodied in its elements, relationships, and inthe principles of its design and evolution” [1]. In other words, when it comes to buildingsand their architecture, most people know how to correlate a blueprint or a floor plan toan actual building, and that you need to have walls in order to be able to have windows.The ISO 42010:2011 standard strives to provide a similar working ground when mappingcompanies and their systems, making communication and planning easier.

TOGAF - The Open Group Architecture Framework

One way to develop an enterprise architecture is to use the TOGAF framework, developedby the Open Group. It contains methods and tools for creating an enterprise architecturethrough an Architecture Development Method consisting of eight basic phases enumeratedA to H (seen below).

A Architecture Vision Phase defines the scope of the initiative, identifies stakeholdersand other information needed to proceed with the development.

B Business Architecture Phase describes the Business Architecture needed to supportthe Architecture Vision.

C Information Systems Architecture Phase describes the Information Systems Archi-tecture needed to support the Architecture Vision.

D Technology Architecture Phase describes the Technology Architecture needed tosupport the Architecture Vision.

E Opportunities and Solutions Phase conducts initial planning and identifies deliveryvehicles (such as projects or programs) for the decided architecture.

F Migration Planning Phase describes how to move from current Baseline Architectureto future Target Architecture and finalises an Implementation and Migration Plan.

G Implementation Governance Phase provides an architectural oversight of the imple-mentation.

H Architecture Change Management Phase establishes procedures for changing tothe new architecture.

When reaching the last step the process is repeated to make sure that the enterprise ar-chitecture continues to be as up-to-date as possible. Connected to all these steps is theRequirements Management Phase that examines the process of creating architecturerequirements throughout the architecture development. There is also a Preliminary Phasethat describes the preparation needed to be able to create an enterprise architecture. Theimage used to describe TOGAF and this process can be found in figure 1 [18].

7

Figure 1: The TOGAF phases and their relations [18].

The Zachman Framework

To describe an existing enterprise architecture, the Zachman framework is commonly used.This framework consists of a matrix with six columns and six rows, where each columnrepresents a question and each row a perspective of a certain kind of employee. The officialmatrix can be seen in figure 2, and a simplified version can be seen in figure 3. Thecolumn labels, the questions, are ”What?”, ”How?”, ”Where?”, ”Who?”, ”When?”, and”Why?”. These are, according to Zachman, the primitive interrogatives and therefore thefundamentals of communication. The row labels, the perspectives, are the perspectivesof Executives, Business Management, Architects, Engineers, Technicians, and an overallEnterprise perspective. The 36 cells that make up the matrix would then be the differentviews that need to be modelled to fully describe an enterprise.

8

Figure 2: The official Zachman framework matrix [28].

Figure 3: A simplified version of the Zachman framework [13].

9

3.2 Enterprise Architecture Modelling

There are many tools that can be used when modelling an enterprise and its architecture, aswell as several different modelling languages. A common modelling language is ArchiMate,developed by the Open Group. ArchiMate separates the enterprise into three different layers,the Business, Application, and Infrastructure layers. These are defined as follows:

• The Business layer, the topmost layer, models products and services delivered toexternal customers, as well as how they are realised within the enterprise.

• The Application layer, in the middle, shows the applications that support e.g. thedifferent services and processes in the business layer.

• The Technology layer, at the bottom, models the infrastructure that is needed torun the applications in the application layer.

The ArchiMate language has been designed to be as small as possible while still beingusable in most cases of enterprise architecture modelling. The language defines three coretypes of elements, as described below, which can be compared to the three grammaticalparts of a regular sentence [4].

• Active structure elements are entities that can perform behaviour, compared tothe subject in a sentence.

• Behaviour elements is a unit of activity that is performed by active structure ele-ments, compared to the predicate in a sentence.

• Passive structure elements are objects on which behaviour is performed, comparedto the object in a sentence.

UML, the Unified Modelling Language, is another language commonly used in enterprisearchitecture modelling. It is developed and maintained by OMG, the Object ManagementGroup. The UML language also consists of three model element categories, albeit differentones from those in ArchiMate. The UML element categories are classifiers (describing aset of objects), events (describing a set of occurrences), and behaviours (describing a setof executions) [6]. UML has been standardised in ISO/IEC 19505-1 and ISO/IEC 19505-2[2],[3].

Another framework is MODAF (the Ministry of Defence Architecture Framework), de-veloped and maintained by the British Ministry of Defence. It consists of ”views” dividedinto seven categories, supporting interests for different stakeholders. The categories are:

1. Strategic views (StVs)

2. Operational views (OVs)

3. Service oriented views (SOVs)

4. Systems views (SVs)

5. Acquisition views (AcVs)

6. Technical standard views (TVs)

7. All views (AVs)

Each category corresponds to a viewpoint. The Strategic Viewpoint consists of six differentStVs that together defines the capabilities needed to reach a desired business outcome,aligning capabilities with an enterprise strategy and identifying possible capability gaps.The Operational Viewpoint has seven main views, some of which are split up into sub-views, making the total number of views for this viewpoint eleven. It provides an abstract

10

view of a solution, showing e.g. processes and information needed, but not what the actualsolution could look like. The Service Oriented Viewpoint provides seven views and is usedto specify services and their requirements for use in a Service Oriented Architecture (SOA).The Systems Viewpoint describes the resources needed to e.g. implement a capability,and it consists of seventeen different views (including sub-views) specifying requirementsfor a system or solution. The Acquisition Viewpoint consists of two views that describedependencies between projects as well as the ownership and structure of them. The TechnicalStandards Viewpoint is made up of two views and describes e.g. standards and policies (bothtechnical and non-technical) that apply to different parts and aspects of the architecture.The All Views Viewpoint is made up of two different views, and presents support andreference information for the architectural models, rather than any actual models [22].

Sparx Enterprise Architect

The tool used for enterprise architecture modelling at Folksam is called Enterprise Archi-tect, and is developed by Sparx Systems1. This tool is based on UML 2.5, and supportsseveral different languages and frameworks, such as ArchiMate, TOGAF, and the Zachmanframework [7]. The models created as a part of this research are created in Sparx EnterpriseArchitect.

3.3 Business Capabilities

In Cutter Consortium’s Executive Report ”The Business Capability Map”, the businesscapabilities are described as the ”Rosetta stone of Business/IT alignment” [26]. Theirview corresponds with Folksam’s view of business capabilities, and Cutter Consortium’sten business capability principles have been the base for the capability work at Folksam.The principles state that:

1. Capabilities define what a business does, not how a business does something.

2. Capabilities are nouns, not verbs.

3. Capabilities are defined in business terms, not technical terms.

4. Capabilities are stable, not volatile.

5. Capabilities are not redundant.

6. There is one capability map for a business.

7. Capabilities map to, but are not the same as, a line of business, business unit, businessprocess, or value stream.

8. Capabilities have relationships to IT deployments and future-state IT architecture.

9. Automated capabilities are still business capabilities - not IT capabilities.

10. Capabilities are of most value when incorporated into a larger view of an enterprise’secosystem [26].

The first principle is a concise way to explain what a business capability is: what a com-pany does, not how it does it. A capability could for example be ”Property management”or ”Product development”. This definition can be compared to what a business process is:linked procedures, collaborative activities, a series of executed steps to produce a deliverable- in essence how a company does something [25].The second principle helps reinforce the first. By using nouns such as ”product manage-ment”, the difference between capabilities and processes or value streams is enhanced. The

1http://www.sparxsystems.com/

11

third principle makes it easier for people to understand a business capability map, even ifthey do not know many technical terms. Principle number four explains that capabilitiesrarely change within a company. How they are deployed might change, if for example acapability is automated, but entirely new capabilities usually only comes with changes tothe business strategy or model. The fifth and sixth principles clarifies that capabilities existsonly once on a map, even if it is realised at several places throughout the company, and thata company has only one capability map - no duplicate capabilities, and no duplicate maps.A map can be decomposed into several parts, but it will still be only one capability map forthe company. Principle number seven sets the capability apart from other concepts such asa process, line of business, or value stream, even if there can be similarities and correspon-dences these concepts are different abstractions of a business. The eighth principle explainsthat capabilities align directly to service-oriented architecture implementations, even if theymay be manual. Principle number nine differs between an IT capability (a capability thatthe IT department has) and an automated capability (a capability implemented in an ap-plication). The tenth and last principle states that while a single capability might be goodfor planning and discussion, capabilities contribute the most to a company when mapped inan overall picture of the business [26].

Another explanation of what a capability is comes from the article Capability-based Busi-ness Model Transformation, where the authors describe a capability as ”the ability of anorganisation to manage its resources to accomplish a task”, and says that an organisationexhibits a capability if it repeatedly can apply it [17].

[10] defines capability as ”the ability to employ resources to achieve some goal”, which isclosely related to the definition used in TOGAF, the Open Group Architecture Framework,which states that a capability is ”an ability that an organisation, person, or system possesses”[18].

MODAF has capabilities at its core, and describes a capability as ”a high level specifi-cation of the enterprise’s ability”, and adds that they do not change over time and as suchcan be specified even if the company does not have the capability at the moment [21].

There are several people who have investigated how to model capabilities when workingwith enterprise architecture [27],[12],[24], and who have also suggested that in a meta-modelthe capability should be connected to e.g. requirements, resources, values, services, products,roles, and processes. According to [24], a capability is ”an ability, capacity or potential thatan organisation, person or system possesses”. Two examples of meta-models can be seen infigure 4.

12

Figure 4: Two examples of meta-models containing the (business) capability [12],[27].

In [12], seen to the left in figure 4, the author defines a Business Capability as ”the abilityto execute a specified course of action, to achieve specific strategic goals and objectives”and says that it is used to manage strategic business changes. He stresses that it is notthe same thing as a Business Function, but that a capability encompasses many otherelements such as Business Functions, Roles, Policies and Business Services. He connectsthe Business Capability to an Enterprise, a Business Value, a Product, a Business Service,and an unspecified MetaObject. [27] says that Capability could be added to ArchiMateas an aggregate of other objects from its core meta-model, and explains capability as ”theability to produce results”. His suggested meta-model can be seen to the right in figure4, and connects the Capability to a Product, an Artifact, a Function (be it Infrastructure,Application, or Business), a Business Process, a Node, an Application Component, and anActor.

Working with Business Capabilities

In [17] a procedure for figuring out an organisation’s capabilities is described, where theauthors suggest to start with the organisation’s ”main capability”, the capability that pro-vides the organisation with customers. The resources needed for this main capability shouldthen be listed, as well as the sub-capabilities needed to be able to provide those resources.The process is then iterated for the sub-capabilities, until a desired level of abstraction isreached. This process is similar to the one in [26], but differs since it not only uses thebusiness capabilities but includes resources as a complement as well. In [26] it is said thata decomposition down to three levels of capabilities is the most common way to work, andthat using more than six levels is very uncommon but can be important when mappingbusiness to IT architecture.

When it comes to the more widely used enterprise architecture frameworks and modellinglanguages, the implementations of capabilities differ. In ArchiMate 2.12 there is no exactimplementation of the capability, however they suggest that their business processes or

2http://www.opengroup.org/subjectareas/enterprise/archimate

13

functions may be used instead [4]. There, the business process/function is connected to fourentities beside itself: the business role, object, service, and event [4].

In [19], an extension to ArchiMate is proposed, with the capability connected to re-sources, requirements, and behavioural elements. This extension introduces resources andcompetences to ArchiMate, besides capabilities, and in [10] this extension is further analysedand named the Business Strategy and Valuation Concepts extension. In [19] the extensionwas used to align business strategy, enterprise architecture, and portfolio management.

The Swedish enterprise architecture consultancy firm IRM3 wrote about the Zachmanframework in 2010, stating that even though the framework for a long time has been seen asthe ”holy grail” when it comes to enterprise architecture, it is only one of several functioningmodels. It has its drawbacks, for example when it comes to modelling capabilities. Whenmodelling a capability, it can be seen as a separate entity that can be analysed as an enter-prise of its own, a simplification that would not be allowed within the Zachman framework[14].

Business Capabilities at Folksam

At Folksam, business capabilities were approached as a part of the work with their ITstrategy. This strategy states that IT should be a support for Folksam when moving forward,be of help when coordinating important business areas, and enhance the long-term effects ofadvancements. To do this, they chose to start working with business capabilities, since theysaw them as a way to plan strategies on a higher level, independently of what organisationsor departments were involved. They state their purposes with business capabilities to be:

• Provide a coherent description of the company.

• Provide a foundation for setting goals and strategies for advancement.

• Be able to govern, measure, and do follow-ups of effects for central business areas, de-spite that the value-creating processes might be spread out over several organisations.

• Show the areas of the on-going projects and if they align with goals and strategieswithin the area.

• A synchronised way of analysing the scope of advancement initiatives.

They stress that it is important that the business capabilities are organisationally inde-pendent, so that it is possible to govern, measure, and follow-up regardless of responsibilitiesfor e.g. processes or functions [16]. Since 2014, the Risk Managers at Folksam has used theLevel 1 capabilities to structure their semi-annual risk reports, to in an easy way be ableto show the company executives how the risks are spread over the company [9]. Today, thecapabilities are also used for portfolio planning, and the capabilities on Level 2 are used toidentify dependencies between projects.

At Folksam, they do not differ between ”Business Capabilities” and ”Capabilities”, andwhen starting the work with business capabilities, Folksam created something they called”Capability cards”. These cards describe a capability and its implementation. They con-tain a description of the capability or area, and what goals, measurements, strategies, andbusiness requirements are associated with it. They also describe its implementation, withprocesses, organisations, competences, and supplies of information. This card can also con-tain a rough estimate of how well the capability is working, shown by assigning it one ofthree colours: Red (Not working), Yellow (Improvements needed), or Greed (Working as itshould) [16],[15].

Business capabilities were introduced at a local level at Folksam about five years ago,and two years ago on an enterprise level when the Enterprise Architects started developing a

3http://www.irm.se/

14

corporate capability map. In parallel with the research presented in this paper, a revision ofthe capability map at Folksam was carried out, and guidelines for how and when to use thecapability concept were developed. A key part of these guidelines was to define a commoncapability meta-model.

3.4 Business Capabilities and Modelling within this Research

The definition of a business capability used within this research is the same definition asis used at Folksam, and it is the one provided by the Cutter Consortium [26] described insection 3.3. The key principle is that a capability is what a company does.

Since Folksam does not differ between ”Capabilities” and ”Business Capabilities”, thisreport will also use the words interchangeably.

The meta-model created in this report is a draft, and implementation of the actual meta-model was not a part of this research. The model drafts were made in Sparx EnterpriseArchitect, using UML structural class diagrams. The elements discussed in this report weremodelled as classes, with relations and attributes.

15

4 METHOD

To answer the stated research question, data from several sources needed to be gathered,relating to the different aspects of the question.

• The meta-modelThe meta-model drafts were made as drawings only, to identify what different elementsand relations were needed for the final version. The meta-model could then later beimplemented in Sparx EA4, the enterprise architecture tool used at Folksam.

• The business capabilitiesFolksam started working with capabilities on an enterprise level about two years ago,developing a joint enterprise map. The Enterprise Architects have learnt a lot aboutthe capabilities of the company and in which areas it could be relevant to use thebusiness capability concept. Right now, they are revising their business capabilitymap, and within the research in this paper, the capabilities were analysed on a moreabstract and general level, which is why there was no need to delve deeper into theactual business capabilities at Folksam.

• The stakeholdersThe main stakeholders of this research are the Enterprise Architects working with busi-ness capabilities at Folksam. These Enterprise Architects, and mainly the EnterpriseArchitect Team Leader, were consulted in the process of identifying other stakeholdersthat had some insight into the work with business capabilities. Some previous insightinto the matter was needed, since the work with business capabilities within Folksamis still in progress and not everyone is affected by it as of today.

• The expectations and requirementsAs of today, Folksam had already connected metrics to the business capabilities. Tomake the model complete they wished to survey what other features the stakeholderswanted to connect, and then implement this into a meta-model. This survey was donethrough interviews with the stakeholders.

• The thoughts on capability health statusFolksam previously had ”capability cards” showing the health status of a capability.To be able to make these cards, and the meta-model, more relevant the respondentswere asked about their thoughts on the health status of a capability, and what couldaffect it.

The data gathering was divided into several steps, focusing on interviews with the stake-holders at Folksam. These interviews were the basis for the meta-model of the businesscapability and the elements connected to it.

4.1 Step 1 - Initial Interviews

The first step was to interview the stakeholders at Folksam. The stakeholders were identifiedwith the help of the Enterprise Architect team leader at Folksam’s Enterprise ArchitectureDepartment. The stakeholders were asked about their attitude towards the business capa-bility concept and the use of it. Would they like to use them and, if so, how? What wouldthey like to be able to connect to the capabilities (e.g. projects, requirements, or people)?

The interviews were recorded (with permission from the respondents) and the answerstranscribed. Since Folksam is a Swedish company and all the interviewed stakeholders,as well as the author, have Swedish as their native language, the interviews were held inSwedish. The transcribed answers are therefore in Swedish as well. However, summaries,

4http://www.sparxsystems.com/products/ea/

16

quotes, and other excerpts from the interviews used in this report are translated to English.The transcribed answers can be found in their entirety in the appendix, section A.1. Thisprocedure was the same for all interviews held during this project.

The questions in table 1 were used in this first set of interviews, to help with the first partof the main objective, to create a meta-model for Folksam’s business capabilities, meeting theexpectations and fulfilling the requirements set by the stakeholders In table 1 the questionsare listed along with possible answers and what the answers could be used for in the analysis.The first five questions considered the background of the respondent, and their knowledgeand involvement in the work with business capabilities. These were mainly used for furtheranalysis, for example to see if what elements a respondent wanted to connect to the capabilitydiffered with their background or their position. The last five questions concerned thebusiness capability and what the respondent thought it could be used for, and how. Thesewere mainly used to construct the meta-model. The question numbers Q1.1 to Q1.10 areused when referring to the different questions.

The elements listed as suggestions in Q1.8 are selected from the literature presented insection 3.3 as elements that might be relevant for the respondents, but also might be difficultfor the respondents to suggest on their own (in Q1.7).

Table 1: The questions used during the first set of interviews with stakeholders at Folksam,along with possible answers, and what the answers were used for.

No. Question Possible answers Why is it asked?Q1.1 What is your position,

and how long have youbeen working at Folk-sam?

Business architect, ITstrategist, since 2010.

To see if later answers dif-fer between positions or timeemployed.

Q1.2 In short, what do youknow about businesscapabilities?

What a company doesor other specificationsfrom the Cutter Con-sortium list of prin-ciples. If they haveworked with capabili-ties at Folksam.

How do answers to laterquestions differ between peo-ple with different knowledgelevels? (Will people with amore ”correct” view of whata capability is give answersthat are more “correct”?)

Q1.3 For how long have youbeen working with (theconcept of) businesscapabilities?

Time spans betweensome months and acouple of years.

To see if they have famil-iarised themselves with theconcept of business capabil-ities for a while, or if theyhave seen it for the first timerecently.

Q1.4 How did you first comeacross the concept ofbusiness capabilities?

Presented by archi-tects, to use for analy-sis, in a project.

To see what manner it wasintroduced in, and what itwas supposed to be used for,if anything.

Q1.5 Have you used businesscapabilities, and, if so,how?

No, for analysis, in aproject.

To see what capabilities havebeen used for and what isneeded in the meta-model inorder to show this.

Q1.6 What applications canyou see for the busi-ness capabilities? Foryourself/your depart-ment/the company/aproject.

Support when plan-ning projects, identifyflaws in process chain,manage external re-quirements.

To learn what they want touse the capabilities for, andto get some ideas about whatcould be connected to the ca-pability in the meta-model.

17

Table 1: The questions used during the first set of interviews with stakeholders at Folksam,along with possible answers, and what the answers were used for.

No. Question Possible answers Why is it asked?Q1.7 To achieve this appli-

cation, what elementswould you like to beable to connect to abusiness capability?

Requirements, roles,projects, strategies.

To find elements to connectto the capability in the meta-model, according to the re-spondent’s own suggestions,and to see if they match theelements from the literature.

Q1.8 Which, of the follow-ing would you like tobe able to connect to abusiness capability?

• Requirement

• Resource

• Role

• Service

• Event

Zero to all of thesestated elements.

To find elements to connectto the meta-model, based onthe literature.

Q1.9 Why would you like toconnect these specificelements, and when doyou think it would beuseful?

For easy structuring ofprojects, when testingcompliance.

Find out about the elementsand attributes they couldhave, why they are useful,and what the relations to thecapability could be called

Q1.10 How do you think theelements would affectthe capability, or be af-fected by it, if changesoccur?

Make it better/worse,increase/decrease ca-pacity.

To help identify what the re-lations should be, and howthe elements and relationsshould be structured.

4.2 Step 2 - Meta-Model Creation

With the aid of the answers from the first set of interviews, a meta-model draft was cre-ated. The meta-model was centred on the business capability. The elements added to themeta-model were the ones suggested and mentioned by the interview respondents. Whena respondent described a relation between the capability and an element, that relation wasadded as well. If no such relation was described, a possible relation was found by searchingthe literature, or with the help of the Enterprise Architect Team Leader.

4.3 Step 3 - Meta-Model Evaluation

The meta-model draft was sent back to the interview respondents, along with a request forfeedback. The respondents were sent a questionnaire via Google Forms5 where they wereasked to mark all elements as relevant or not, for them in their own work. They also gotanother set of questions to be answered, either in an interview or via email. These questions,seen in table 2, pertained to the performance and well being of a business capability, andhow the respondents felt that it was affected by the different elements connected to it.This considered the second part of the main objective, to modify the meta-model so that

5https://www.google.com/forms/about/

18

it encompasses the stakeholders’ views on business capability health status. As with theprevious interviews, transcripts of the interviews can be found in the appendix, section A.2.

Table 2: Questions asked to the respondents in order to find out what they think makes abusiness capability perform well or not, and how it could be affected by other elements.

No. Question Possible answers Why is it asked?Q2.1 How can you tell if a ca-

pability is performing wellor not?

Connected processesrun smoothly, outputis correct.

Establishes respondents”ideal capability”, ifneeded for future refer-ence.

Q2.2 What do you think affectsthe well being of a capa-bility the most?

Up time of supportingsystems.

Get a notion of which el-ements could be involvedand connected.

Q2.3 What attributes of the ca-pability affects the wellbeing and performance ofit the most?

Information quality. Find attributes of the ca-pability that could be af-fected.

Q2.4 Which of the elementsconnected to the capabil-ity do you think affectits well being and perfor-mance the most?

Requirements, Pro-cesses.

To know which elementsshould be connected to thecapability.

Q2.5 What attributes of theseelements do you think af-fect the capability, andwhich attributes of the ca-pability do you think theyaffect?

Up time of service af-fects quality of capabil-ity information.

Find out which attributesshould connect elementand capability.

4.4 Step 4 - Meta-Model Editing and Finalisation

To optimise the meta-model, all elements that had been marked as not relevant by all ofthe respondents were to be removed, since the goal of this project was to create a meta-model relevant to the respondents. Elements not mentioned or described as affecting thecapability and its health status were also removed, since the meta-model should encompassthe stakeholders’ views on capability health status. When this was done, the remainingelements and their connections to the capability were modelled according to the answersand descriptions gained from the second set of interviews.

19

5 DATA

The data gathered in the four separate steps described in sections 4.1 to 4.4 is presented inthe corresponding sections below.

5.1 Step 1 - Initial Interviews

Seventeen people were approached about interviews by the Enterprise Architect TeamLeader, and twelve agreed to participate. In table 3 the participants’ occupations can befound, as well as how long they have been working at Folksam, and when they first cameacross the concept of business capabilities (the answers to Q1.1 and Q1.3).

Table 3: The occupations of the interview respondents as well as how long they have workedat Folksam and when they started working with capabilities.

Respondent ID Occupation At Folksam since Saw capabilities inRespondent 1 Business Architect 2015 2010-2011Respondent 2 Business Architect 2002 2013Respondent 3 Business Architect 2013 Middle of 2013Respondent 4 Risk Manager 2013 2013Respondent 5 Risk Manager 2013 Middle of 2013Respondent 6 Business Developer 2001 2012-2013Respondent 7 Business Architect 2014 2000Respondent 8 Business Developer 2000 2011Respondent 9 Business Developer 2009 Middle of 2013Respondent 10 Governance Specialist 1979 2010-2011Respondent 11 IT Strategist 2015 2015Respondent 12 Business Architect 2003 2011-2012

When asked to describe what they knew about capabilities, in short (Q1.2), some of therespondents were more familiar with the definition of a capability than others. Respondents2, 3, 4, 6, 8, 11, and 12 in some way stated that a capability was what a business does, nothow it does it. Respondents 1, 2, and 8 said that it was a good tool in discussions with e.g.stakeholders, presenting a view of the whole rather than details, which made it easier foreveryone to understand. Respondents 3, 5, 7 and 10 had used capabilities when mappinga business and e.g. its projects, risks, requirements, and systems. Respondent 4 thoughtthat capabilities was a natural next step from modelling processes, and respondents 6, 8,and 9 thought capabilities to be a good way to visualise the company, and set the scope ofprojects while seeing which parts of the company will be affected by it.

How the respondents came across the capability concept differs (the answers to Q1.4),but respondents 3, 4, 5, 6, and 8 said that it was introduced to them by the EnterpriseArchitect Team Leader at Folksam. Respondents 1 and 12 discovered capabilities at theirprevious workplaces, when trying to describe what the companies did, and respondent 11 gotan introduction to capabilities along with the introduction to Folksam when they startedworking there. Respondent 2 felt that processes were an out-dated way of describing acompany, and discovered that capabilities were more in line with what they needed, whereasrespondent 7 found that capabilities were useful when setting requirements for a proposal.Respondent 9 was introduced to capabilities by a Business Developer colleague that hadtaken a course in enterprise architecture, and respondent 10 learnt it from the EnterpriseArchitects when they together were working with information security and immaterial assets.

The answers to Q1.7 and Q1.8 (about which elements the respondents would like toconnect to the capability) were summarised in table 4 that was then used in the next stepto create a draft of the meta-model.

20

Table 4: Elements that the interview respondents suggested to connect to the capability,which respondents suggested which elements, and how many respondents suggested eachelement. Elements marked with * were those suggested to the respondents in Q1.8, and x(a bold x) marks an element that was mentioned by the respondent in the answers to bothquestions Q1.7 and Q1.8.

Respondent no. 1 2 3 4 5 6 7 8 9 10 11 12 SUMApplication x x 2Competence x x x 3Cost x 1Distribution Channel x 1Event* x x x x x x x 7Goal x 1Health Status x 1Information x x x x x 5Input/Output x x 2IT Support x x x 3KPI x 1Law/Rule/Policy x 1Organisation x x x x x x 6Process x x x x x x x x x x x 11Requirement* x x x x x x x x x x x 11Resource* x x x x x x x x x x 10Risk x x 2Role* x x x x x x x x x x 10Screening x 1Service* x x x x x x x 7System x x x x x x x 7Value Tree x 1

Regarding the elements, the respondents also got to answer why they wanted to connectthe specific elements that they mentioned (Q1.9) and if they had any thoughts on if theelements affected the capability in some way, or if it was the other way around (Q1.10). Theanswers to these questions can be found in table 5.

Table 5: The answers to the interview questions Why would you like to connect theseelements, and when would it be useful? (Q1.9) and How do you think these elements wouldaffect the capability, or be affected by it, when changes occur? (Q1.10).

Resp. ID Answer to Q1.9 Answer to Q1.101 Capabilities with these elements

connected is one important pieceof the puzzle when measuringchange.

The elements support the capability,but they both affect each other.

2 To describe ”What kind of busi-ness are we running?”, and to seewho is responsible for what.

The elements support the capability,so rather that a good process con-tributes to a good capability, thanthe other way around.

3 To get a structured view of thewhole company. It feels likean approach that should actuallymanage to finish a company-widemap.

The elements affect the capability,at least in most cases.

21

Table 5: The answers to the interview questions Why would you like to connect theseelements, and when would it be useful? (Q1.9) and How do you think these elements wouldaffect the capability, or be affected by it, when changes occur? (Q1.10).

Resp. ID Answer to Q1.9 Answer to Q1.104 When working with changes or

when mapping the organisation.To find where there are risks andwhat they are associated with.

The elements affect the capability.The capability is a framework forthe elements.

5 Important when working withchanges, or optimisation.

More that the elements affect the ca-pability, but the whole concept feelsa bit abstract.

6 When you are looking at thebusiness development process, orare in need of moving certainparts of the business somewhereelse.

It could go both ways, it dependson a lot of variables. Has no clearanswer to the question.

7 To be able to relate the capabil-ities to something, so that otherpeople in the organisation do notdeem them as too abstract.

The capability consists of the ele-ments, it is a container for every-thing else, to remove the need of get-ting overly complex.

8 Useful in all sorts of resource andcompetence planning.

It could be both ways. When pur-chasing an IT solution, the capabil-ity is affected by the chosen solution.On the other hand, there are criti-cal capabilities that affect whateveris inside them, such as company spe-cific questions.

9 Good when analysing require-ments, and for projects. Hardto connect it to the actual enter-prise at some points, though.

The capability should be affected byother things, and it needs to adaptto what we want to do.

10 To improve the ability to governand control, through finding outwhich elements connect.

If you control a capability by exam-ining the connected elements, thatcapability controlling will affect theelements.

11 In general, it increases your un-derstanding of the business andwhy it works or not.

It depends. There is probably an as-pect of time or culture as well, whichaffects the other might depend onwhat was the point of origin, if itwas the capability or e.g. a process.

12 To analyse. Knowing rulesis needed when performingchanges, so you know whichcapabilities they affect, forexample.

The capability does not change, buthow it is implemented might. Aslong as you are not changing yourbusiness model, the other elementsmight change, but not the capabil-ity.

From this first set of interviews information was also gathered on what the respondentshave used the business capabilities for, and if they could see any other areas where theycould be useful. The answers to these questions (Q1.5-6) can be seen in table 6.

22

Table 6: The respondents’ answers to the questions ”Have you used the business capabil-ities, and, if so, how?” (Q1.5) and ”What other applications can you see for the businesscapabilities?” (Q1.6).

Resp. ID Answer to Q1.5 Answer to Q1.61 To map different models to one sin-

gle concept, for easier analysis, forquality assurance, and to ensurethat projects have the right scope.

To see the whole, and compareprojects and investments. Not tomeasure the capabilities.

2 To describe responsibilities withinthe Economics area. Also trying todescribe ”How well is a capabilityworking?” by assessing the status ofelements connected to it.

Almost anything you want. It is agood, neutral way to describe a com-pany and its business.

3 When analysing new projects or ini-tiatives, looking at which capabili-ties will be affected. Also to com-pare projects and see how the af-fected capabilities differ.

When needing an overview of yourwork, to compare departments, orlooking to increase efficiency. Es-sentially, whenever working withchanges or improvements.

4 To describe the business without theneed for process responsibility, andto structure a risk report.

To easily find which capabilities arenot performing well, and which peo-ple have some kind of responsibil-ity for the capability and its per-formance. Also to see where we areperforming changes.

5 For structuring the risk reports,since the last two reports.

When working with changes and ITimprovements.

6 When analysing large campaigns, tosee what will be affected.

Assessing how hard or complex acampaign could be. To prioritise thesteps needed to maximise the out-come with regards to the resourcesused.

7 Mainly when mapping a business oran organisation, to find out how toorganise in an efficient way, or findout how a new strategy affects thecompany.

Capabilities are used very widely atFolksam, but it would be nice to useit in an agile method in a better way.

8 To find which capabilities are withinthe scope of a project, and tofind changes needed to be done toachieve a strategy or a goal.

State what an organisation does,which organisation is responsible forwhat. Can be used for practicallyanything.

9 To see which capabilities you are re-sponsible for, how they perform, andif they can be improved. To mapyour own organisation.

For projects and organisations, tosee what needs to be done and whatis known at the moment. To see howthe capabilities map to other things,and why they perform well or not.

10 When building a governance system,and seeing the connections betweensecure information processing, in-formation assets, and capabilities.When mapping risks.

Practically everything. Control andfollow-up to be able to reach goals,so that it in the end can correlatewith the economic follow-ups.

23

11 When determining the goals for ourapplication park, since it is sup-posed to support the capabilities.

Map to Organisations and Systems,to understand what needs to bedone e.g. to perform changes. Alsogood to understand which capabili-ties are ”yours”, and where they areand what they do.

12 To simplify when working with pro-cesses, finding out where somethingis affected without going through allactivity flows. To identify wherecontrols are needed when perform-ing changes.

To identify responsibilities, andwhen planning initiatives.

5.2 Step 2 - Meta-Model Creation

Diagram Report Page: 4

Förmågetest 1 diagramClass diagram in package 'Förmågetest'

Förmågetest 1Version 1.0

FSBE25 created on 2015-07-15. Last modified 2015-07-15

Process

Organisation

Resource

System

Requirement

Role

Service

Event

Information

Risk

KPI

IT Support

Competence

Application

Value tree

Cost

Distribution Channel

Goal

Health Status

Capability

Input/Output

Law/Rule/Policy

Screening

Förmågetest 1Figure 4: Figure 5: The meta-model draft based on the first set of interviews.

Using the answers aggregated in table 4 as a starting point, a meta-model draft wascreated, see figure 5. This meta-model was centred on the business capability (here: Capa-bility), and contained all the elements suggested in the interviews. At this stage, however,it did not contain any descriptions of the relations between the elements. The draft was

24

then presented to the Enterprise Architect Team Leader, and edited according to her com-ments. The comments resulted in the following changes: the suggested elements ”Goal” and”Health Status” were seen as attributes of the Capability rather than separate elements,and were therefore modelled in that way. Law, Rule and Policy were split up into separateelements considered specialisations of the Requirement element, and Input/Output was alsosplit into separate elements. Distribution Channel and Screening were both removed, sincethey were considered capabilities of their own, rather than elements liked to one [15]. Thefinal draft in this step can be seen in figure 6

Diagram Report Page: 3

Förmågetest diagramClass diagram in package 'Förmågetest'

FörmågetestVersion 1.0

FSBE25 created on 2015-04-23. Last modified 2015-05-08

Capability

- Goal: int- Health Status: int

Process

Organisation

Resource

System

Requirement

Role

Service

EventInformation

Risk

Input

KPI

IT Support

Competence

Application

Value tree

Output

Rule Law Policy

Cost

FörmågetestFigure 3: Figure 6: The first meta-model draft, based on the initial interviews and edited accordingto comments from the Enterprise Architect Team Leader.

The relations between the elements were modelled as described by the respondents, asfound in the literature, or as discussed with the Enterprise Architects at Folksam. Therelations can be found in table 7.

25

Table 7: The relations between the different elements in the meta-model draft.

Element Relation to ElementCapability supports ApplicationCapability isSupportedBy ApplicationCapability needs CompetenceCapability isInitialisedBy EventCapability isSupportedBy IT SupportCapability uses InformationCapability uses InputCapability isMeasuredBy KPICapability delivers OutputCapability isRealisedBy ProcessCapability isConstrictedBy RequirementCapability needs ResourceCapability isAssociatedWith RiskCapability contributesTo ServiceCapability isSupportedBy SystemCapability contributesTo Value TreeCost isSpecialisationOf KPIEvent isAssociatedWith ProcessEvent has RiskIT Support is ResourceInformation is ResourceRole is ResourceRole isResponsibleFor CapabilityRole has CompetenceRole belongsTo OrganisationOutput dependsOn InputLaw isSpecialisationOf RequirementPolicy isSpecialisationOf RequirementRule isSpecialisationOf RequirementOrganisation has CompetenceOrganisation isResponsibleFor Capability

5.3 Step 3 - Meta-Model Evaluation

The meta-model draft was sent to the interview respondents, along with a questionnairethat asked them to rate each element and attribute as ”Relevant” or ”Not relevant”. Theanswers to this questionnaire can be seen in table 8, where elements chosen as ”Relevant”are marked with an ”x”. Unmarked elements were those chosen as ”Not relevant”. As can beinferred from table 8, respondent 8 did not complete the questionnaire, and as a result, theircolumn was left blank. Below are listed the definitions for the different elements that wereused in the questionnaire. The last two in the list, Goal and Health Status, are attributesof the Capability element rather than elements of their own, as illustrated in figure 6.

• Application (supported) An application that is supported by the capability.

• Application (supporting) An application that supports the capability and aids inits realisation.

• Competence The competence needed to perform the capability.

• Cost The costs associated with the capability.

26

• Event An event that will trigger the capability.

• Information The information that is needed for the capability to be able to function.

• Input What the capability uses to deliver an Output.

• IT Support The IT Support that is needed for the capability to function.

• KPI Key Performance Indicators, measurable values and variables associated with acapability.

• Law A specific kind of requirement.

• Organisation The organisation that is responsible for the capability and its realisa-tion.

• Output The output delivered by the capability.

• Policy A specific kind of requirement.

• Process One or several processes that realise the capability.

• Requirement A requirement that limits the capability or steers it in a certain direc-tion.

• Resource What is needed for the capability to function. Can be e.g. money, compe-tence, or information.

• Risk A risk associated with the capability. Compare to how the Risk Report has beenstructured based on capabilities.

• Role The role that has main responsibility for the capability and its realisation.

• Rule A specific kind of requirement.

• Service A service that the capability aids in delivering.

• System A system that helps to perform and realise the capability.

• Value Tree Shows which of Folksam’s main values the capability is related to.

• Goal (Attribute) What should or will the capability be like in the future, comparedto today?

• Health Status (Attribute) How well is the capability? Does it function as it should?

27

Table 8: The elements marked as ”Relevant” by the different respondents, and a summaryof how many respondents thought each element was relevant. The last two rows are Capa-bility element attributes rather than elements of their own, and the column for respondent8 is intentionally left blank, since they did not complete the questionnaire.

Respondent ID 1 2 3 4 5 6 7 8 9 10 11 12 SUMApplication (supported) x 1Application (supporting) x x x x x x x x x 9Competence x x x x x x x x x 9Cost x x x x x x x x 8Event x x x x x 5Information x x x x x x x x x x 10Input x x x x x x 6IT Support x x x x x x x x x 9KPI x x x x x x x x 8Law x x x x x x 6Organisation x x x x x x x 7Output x x x x x x x 7Policy x x x x x x 6Process x x x x x x x x x x x 11Requirement x x x x x x x x 8Resource x x x x x x x 7Risk x x x x x x x 7Role x x x x x x 6Rule x x x x x 5Service x x x x x x x 7System x x x x x x x x x x 10Value Tree x x x x x x x x x x x 11

Goal x x x x x x x x x 9Health Status x x x x x x x x x x 10

Questionnaire Comments

Some of the respondents had comments to the questionnaire, most of them pertaining tothe definitions of the elements and what they thought about them. Respondent 4 said thatthey had a hard time relating to the concepts, and hence marked most of the elements as”Relevant”, whereas Respondent 5 thought that since they saw capabilities as organisationindependent, all elements that were organisation dependent should be marked ”Not Rele-vant”. Respondent 1 had several comments, and thought that elements such as Information,Cost, KPI, Risk, Requirement and Resource should be connected to the Processes or Sys-tems that were connected to the capability, rather than to the Capability element, and inthat case they would be relevant. This respondent also stated that Organisation and Rolewould be relevant if it were the ones supporting the capability, instead of the ones beingresponsible for it, since there can be no single entity responsible for a capability. Theyalso said that they did not think that Resources could be allocated in that way, and thatGoals only would be relevant if broken down to a lower level. Respondent 12 thought thatApplication and System as well as IT Support were similar, and that it therefore was hardto say which ones could be relevant or not. They also thought that a distinction was neededbetween Resource and the different elements connected to it, such as Role, Information, orCompetence, and that Law was an external Requirement, whereas Rule and Policy wereinternal. Furthermore, they said that they did not like the concept of Goal and HealthStatus, and would prefer to instead look at analysis areas.

28

Follow-Up Interviews

The follow-up interviews with the questions from table 2 were conducted with 8 of theoriginal 12 respondents, one of who chose to answer via email. Their thoughts and opinionsabout what and which elements might affect the well being and performance of a capability(the capability’s health status) can be found below, and a summary of these elements canbe found in table 9.

Respondent 1 The first respondent thought that there was no element in particular thatcould be said to always affect the well being of a capability. They say that it might bepossible to say in specific cases, but that it would take more information on how eachelement and capability is defined. They would check the performance of a capability bylooking at all the different parts that connect to the capability and see how they performand cooperate. Relating element attributes to the well being of a capability is somethingthey personally do not do, but think it could probably be done, even if they cannot see anygains from it.

Respondent 2 Could not be reached for a second interview.

Respondent 3 Respondent 3 thinks that the well being of a capability would be affectedby several things, but says that what they can use to measure it today is the current state andthe business requirements of a capability. Organisation and Competence are key elements tomeasure it in the future, but they cannot say anything about element attributes that mightaffect it.

Respondent 4 Could not be reached for a second interview.

Respondent 5 The well being and performance of a capability could be measured bysetting goals for it and see how well it reaches them, says the fifth respondent. Processesand Resources are the elements that affect it the most, and it is important to have a setGoal to work towards. The governance model is also important. As for element attributesthat might affect a capability and its performance, they cannot say.

Respondent 6 - answered via email Says that to measure the well being of a capabilityyou have to accumulate values for its performance and its importance to the business. Itcould be decreased by e.g. long lead times, faulty results, or lack of resources, and thedeficiencies would be rated differently depending on the importance of the capability. Theyhave no opinion about element attributes that might affect a capability.

Respondent 7 Respondent number seven thinks that establishing good KPIs that showwhat goal you have is a good way to measure the performance of a capability. They alsosay that the governance model will affect they way the capability functions, and thereforeits performance as well, since it will play an important role for e.g. the structure of theorganisation, the requirements set, or which systems you connect. Flaws in supportingsystems and repeated parts of processes they say decrease the well being of a capability,something duplicate systems do as well.

Respondent 8 Could not be reached for a second interview.

Respondent 9 Could not be reached for a second interview.

29

Respondent 10 Thinks using KPIs to measure the capability is key when understandingits performance and well being, as well as that the concept of capabilities needs to beaccepted throughout the company for it to perform well at all. Organisations with a clearstructure are important for a healthy capability, as well as KPIs to measure it, but theyhave no opinion on element attributes and if they might affect a capability.

Respondent 11 To measure the performance of a capability, they say that one needsto measure connected elements and see if they perform well according to measurements.Their suggested elements to measure are Information, Process, Organisation, IT Support,System, and supporting Applications. They cannot say anything about element attributesthat might affect a capability, but think it is important that the people who work with itfeel that the capability is performing well, and that they get the support they need.

Respondent 12 She thinks that what affects the well being of a capability depends on howyou define ”well being” and what is good or not, but that nonetheless Rules and Processesare important for its performance, as well as measuring the processes connected to thecapability. Outer and inner Requirements are attributes that would affect the capability,and how easy the capability is to implement would also affect its performance. They thinkthat Competence and knowledge about the capability is key for its well being.

Table 9: A summary of which elements the different respondents thought might affect thewell being of a capability.

Respondent ID Suggested elements1 Process, System3 Competence, Organisation, Requirement5 Goal, Process, Resource6 Resource7 Goal, KPI10 KPI, Organisation11 Application (supporting), Information, IT Support, Organisation,

Process, System12 Process, Requirement, Rule

5.4 Step 4 - Meta-Model Editing and Finalisation

As can be seen in table 8, no element or attribute was chosen as ”Not relevant” by all of therespondents. Hence, nothing was removed from the meta-model for that reason. However,the elements not described by the respondents as affecting the capability and its performanceand well being, i.e. the elements not appearing in table 9, were removed.

In parallel with this research, the Enterprise Architects at Folksam worked with definingthe names and terms that should be used when working with the enterprise architecture.They decided that the term ”Application” should be used in the cases that previously in thisreport have been called ”Application”, ”IT Support”, and ”System”. Hence, those threeelements were combined into one element called ”Application”.

All these changes resulted in the meta-model that can be seen in figure 7.

30

Diagram Report Page: 2

Förmågemodell2 diagramClass diagram in package 'Förmågetest'

Förmågemodell2Version 1.0

FSBE25 created on 2015-07-16. Last modified 2015-07-16

Capability

- Goal: int- Health Status: int

Process

Requirement

Organisation

Competence

Resource

Application

Information

Rule

KPI

Förmågemodell2Figure 2:

Figure 7: The meta-model after the removal process described in section 5.4.

As in the meta-model draft, the relations are defined as described by the respondents,as found in the literature, or as discussed with the Enterprise Architects at Folksam. Therelations for the final meta-model can be found in table 10

Table 10: The relations between the elements in the final meta-model.

Element Relation to ElementApplication supports CapabilityCompetence isNeededBy CapabilityCompetence belongsTo OrganisationInformation isUsedBy CapabilityInformation is ResourceKPI measures CapabilityOrganisation isResponsibleFor CapabilityProcess realises CapabilityRequirement constricts CapabilityRequirement hasSpecialisation RuleResource isNeededBy Capability

31

6 RESULTS

In figure 7 the final meta-model can be seen. It contains nine elements, apart from theCapability element, and eleven different relations. The relations can be found in table 10.The first meta-model draft contained 21 elements, plus the Capability, and 31 relations. Theones that remain were in the questionnaire marked as ”Relevant” by several respondents,and then described as having an impact on the capability by at least one respondent inthe second set of interviews. Here, the elements and relations in the final meta-model aredescribed more in detail, as well as the reasons for why they are in it. Since the Applicationelement in the end was aggregated from the elements Application, IT Support, and System,the latter two can be found as ”Aggregated Elements” under the Application element.

6.1 Element: Capability

The Capability is the central element in this meta-model, and it describes what a businessdoes. For further information on the capability definition used in this report, see section 3.3.The relations between the Capability element and the other elements in this meta-modelare described in the subsections regarding those respective elements.

6.2 Element: Application

The Application element describes an application that supports the Capability.This element is an aggregate of elements Application, IT Support and System used during

the first three meta-model construction steps. The arguments for the Application elementare described here, and for the other elements in their separate subsections below.

In the first set of interviews, the Application element was mentioned as relevant byrespondents 7 and 12. Respondent 7 said that they thought it was important to model theapplications when working with strategy and logical solution architecture, and respondent12 that Application is one of the key elements that are affected by changes. They said thatcapabilities do not change, as long as you do not change you business model, but you canchange how they are implemented in the business, through for example applications.

Relation: supports (Capability)

The Application supports the Capability and its implementation. This relation was sug-gested by respondent 12, in that they said that the applications are what can be calledtechnical support systems that can be connected to a capability. Respondent 6 said thatone key question when breaking down capabilities into other parts was to see what ITsupport (here: Application) is needed.

Aggregated Element: IT Support

The element was suggested by respondents 5, 6, and 8. Both respondents 6 and 8 thinksthat IT Support is important to connect when looking at capabilities from a strategic pointof view.

Aggregated Element: System

This element was deemed helpful to connect to the Capability by respondents 1, 3, 4, 7,10, 11, and 12. Respondent 1 says that Systems are one of the four key parts that areconnected to a capability, and respondent 7 would like to connect systems to capabilitiesfor strategic solution architecture purposes. Respondent 10 works with integrating differentprocesses and systems, and with developing governance systems, and thinks that connectingsystems to capabilities helps when analysing a complex organisation. To get a good view ofa business in the event of e.g. fusions with other companies, respondent 11 thinks mapping

32

systems to capabilities is helpful, and respondent 12 says that it is important to know whichsystems connect to which capabilities in the event of changes and system replacements.

6.3 Element: Competence

The Competence element shows what competence is needed to be able to implement theCapability. This element was suggested by respondents 7 and 8. Respondent 7 likes toconnect capabilities to the concept of business objects, and says competences are a key partof that. Respondent 8 says that capabilities is a way of showing which competences areneeded within a company, and that capabilities in that way are a good tool for competenceplanning - ”Which competences do we need where?”.

Relation: isNeededBy (Capability)

This relation shows which competences are needed by the Capability for it to function as itshould. This relation was suggested by respondent 8, when they stated that capabilities isa way of showing which competences are needed where in a company.

Relation: belongsTo (Organisation)

The belongsTo relation shows which organisation within a company that has a specificcompetence. The relation was suggested by respondent 7, saying that they would like toknow which competences they have within a capability, and where they belong within thecompany and its organisations.

6.4 Element: Information

This element shows which information is needed by the Capability for it to be able tofunction. The element was suggested by respondents 1, 3, 4, 10, and 12. Respondent 1 saidthat in their view, the Capability was connected to four other elements, one of which wasthe Information element, a view that was largely shared by respondent 12. Respondent 3stated that connecting Information objects to the Capability would help in visualising whichcapabilities are affected in different projects, and respondent 4 is of the opinion that theinformation is part of what makes it possible for a capability to deliver value to a stakeholder.Respondent 10 works with secure information handling, and says that all information on agovernance and control level is important, and that a good way to keep track of everythingis to connect it to capabilities as well.

Relation: isUsedBy (Capability)

The relation shows that the Capability uses certain information in order to function and per-form. Respondent 10 said that everyone and everything today is dependent on informationin some way, and capabilities are no exception.

Relation: is (Resource)

Resources can be of different kind, and this relation expresses that information is considereda Resource. This view was expressed by respondents 4, 10, and 12. Respondent 10 statedthat ”a resource is an asset, and information is our most important asset”.

6.5 Element: KPI

KPI is a Key Performance Indicator. These are used to compare and measure how theCapability performs. This element was suggested by respondent 4, who said that theywould like to break down a capability into several KPIs that could be used to measure itsperformance.

33

Relation: measures (Capability)

As stated above, the KPI measures the Capability in some way. This relation also stemsfrom the statement of respondent 4 saying that they would like to measure capabilities usingKPIs.

6.6 Element: Organisation

The Organisation is the part of a company that has responsibility for the execution of theCapability, and that it performs as it should. This element was suggested by respondents1, 2, 7, 8, 9, and 11. Respondent 1 says that Organisation is one of the four key partsconnected to a capability, and respondent 2 that while the capability does not belong toan organisation, it can still have a relation to one. Respondent 7 thinks that connectingorganisations to capabilities is useful for e.g. making organisational mappings of a company,and respondent 8 thinks that this is a good way of showing which part of the company isresponsible for what. Respondent 9 states that they would like to use capabilities to knowthat things are done at the right place within their organisation, and respondent 11 saysthat in order for them to understand why they do what they do it is crucial to connect thecapabilities to the organisations that work with them.

Relation: isResponsibleFor (Capability)

This relation shows that an organisation has a responsibility for the Capability and thatit performs as it should. It is possible for several organisations within a company to havethis relation to the same capability, since several organisations could be working with asingle capability. It is suggested by respondent 8, who says that mapping organisations tocapabilities is a good way of showing where the responsibility for something lies.

6.7 Element: Process

A Process shows how something is done at a company, in which order steps are taken,what leads to what. All the respondents, except respondent 11, thought it was a goodidea to connect Processes to the Capability. Respondent 1 sees Processes as one of thefour key elements connected to a capability, and that it is useful when mapping the scopeof projects, something that respondents 3, 6, 8, and 12 agree with. Respondent 2 saysthat measuring the performance of the connected processes is a good way of establishingif the capability performs or not, and respondents 4 and 5 think that it is easier to mapa business using capabilities instead of processes, but it is easier to work with a map ofthe processes, so connecting the two helps. Respondent 7 says that processes are part ofwhat helps a capability create value, and respondent 9 thinks it is easier to see the entiretywhen processes and capabilities are connected. Respondent 10 says that in order to get anybenefits from working with capabilities, you have to break them down into smaller partsand connects them to e.g. Processes.

Relation: realises (Capability)

A capability describes what a company does, and a process how it is done. From thisfollows that the Capability is realised by the connected Processes, a relation suggested andconfirmed by all respondents.

6.8 Element: Requirement

A Requirement on the Capability can have several different origins, and can be everythingfrom a law to an internal guideline for a project. All respondents except respondent 1 agreedthat it would be useful to connect requirements to a capability. Respondent 2 is of the opinion

34

that you can connect most anything, including requirements, to a capability, as long as youhave a purpose for doing so. Respondent 3 has previously worked with connecting businessrequirements to capabilities to see which capabilities are affected by them, and respondent4 says that connecting requirements to capabilities is crucial, because if you do not haveany requirements on a capability, ”What stops it from deteriorating to a bad quality?”,a view that is shared by respondent 10. One thing respondent 5 uses capabilities for ismapping changes, and since requirements are important for defining changes, they wouldlike to connect the two. Respondent 6 says that they think it is relevant, but that theyare used to other terminology and hence cannot expand on the subject. Respondent 8 hasused capabilities as a way of prioritising requirements, starting with one capability and itsrequirements and see to it that they are fulfilled, before moving on to the next one.

Sub-element: Rule

One kind of Requirement is a Rule. This element was suggested by respondent 12, and isused to show that the Requirement is of a certain kind.

Relation: constricts (Capability)

The Capability will be constricted by Requirements connected to it. The restrictions mightbe of different degrees of importance, but they all affect the Capability and how it is imple-mented or performed in some way. This relation stems from respondents 4 and 10 describinghow a capability’s performance might change with the requirements.

Relation: hasSpecialisation (Rule)

Shows that a Rule is a kind of Requirement. This relation was suggested by respondent 12.

6.9 Element: Resource

A Resource is something that is needed for the Capability to function, e.g. money, compe-tence, or information. All respondents except three (1, 10, and 12) thought that connectingresources to capabilities would be useful. Respondents 3 and 5 say that comparing resourcesneeded to perform a capability that exists in several places within a company is a good wayof understanding if the capability can be optimised in some way, and respondent 4 says thatresources play a key part in a capability being able to deliver value to stakeholders.

Relation: isNeededBy (Capability)

The relation shows that the Capability needs resources to function ad perform. This relationwas suggested by several of the respondents, among them respondent 4 stating that resourcesare key for a capability to deliver value.

6.10 Attribute: Goal

The Goal is an attribute of the Capability that express what the desired future state of itis, how it would work if it was ideal. This attribute was suggested by respondent 8, withthe description stated here.

6.11 Attribute: Health Status

The Health Status attribute shows how well the Capability performs and functions. Thisattribute was suggested by respondent 11, who said that it would be helpful to see whichprojects and initiatives that increase the well being of certain capabilities.

35

7 ANALYSIS

In this analysis, the data from section 5 is analysed with regard to both theory and otherdata. As described in section 5.4, the elements Application, IT Support and System havehere been aggregated to one element, Application, in the way that if one or more of thethree aggregated elements was marked in the original table (in section 5), the Applicationelement is marked in the corresponding table in this section. For example: table 12 inthis section is table 4 but sorted in a specific way. In table 4, the Application element issuggested by respondents 7 and 12, the IT Support element by respondents 5, 6, and 8, andthe System element by respondents 1, 3, 4, 7, 10, 11, and 12. This results that in table 12,the Application element will be marked as suggested by respondents 1, 3, 4, 5, 6, 7, 8, 10,11, and 12. The Application element will then be analysed in the same way as the otherelements.

7.1 Elements Relevant to Connect to the Capability

In table 4, the elements that each respondent thought relevant to connect to the Capabilitycan be seen. The number of respondents deeming an element as relevant varies from one(for seven elements) to all (for one element). When sorting the elements according to their”relevance” (more respondents deeming it relevant equals higher relevance, see table 11a),the five elements suggested in Q1.8 can be found in the high ranks. This would suggest thatit is easier to say ”Yes” when asked if an element is relevant, than to figure out relevantelements on your own. If table 8 is sorted in the same manner (as can be seen in table 11b),it shows that all elements has been marked as relevant by at least 5 respondents out of 11.This increases the evidence for that people are more prone to deem an element as relevant ifit is suggested to them, than to come up with relevant elements themselves. This tendencycan also be seen when looking at table 4, where most respondents agreed that the elementssuggested in Q1.8 would be relevant, but only four out of the forty-five instances of positiveanswers for those elements were suggested by the respondents on their own in Q1.7.

When looking at table 11a, it can be seen that only one element (Process) among themost relevant ones was not in Q1.8 but suggested by the respondents themselves. This couldpartly stem from that the concept of business capabilities is still not widely used at Folksam,which means that practically everyone has their own, rough picture of what it is. That theconcept is not as familiar to everyone can also be seen in the answers to Q1.2 (”In short,what do you know about business capabilities?”), where 7 out of 12 respondents in some wayanswered that a capability is what a business does, while 10 out of 12 respondents answeredwhat they had used capabilities for.

36

Table 11: Tables showing the elements sorted according to ”relevance”, the number ofrespondents who thought that the element would be relevant to connect to the Capability,and the internal ranking in the separate tables.

(a) The elements in table 4, sorted accordingto relevance. The number reaches from 1 (onerespondent) to 11 (all but one respondent).

Rank Element Relevance

1Process 11Requirement 11

2Application 10Resource 10Role 10

3Event 7Service 7

4 Organisation 65 Information 56 Competence 3

7Input/Output 2Risk 2

8

Cost 1DistributionChannel

1

Goal 1Health Status 1KPI 1Law/Rule/Policy 1Screening 1Value Tree 1

(b) Table 8 sorted according to relevance. Themaximum score here is 11, since one respon-dent did not answer the questionnaire. Thosemarked with * are here attributes of the Capa-bility rather than elements.

Rank Element Relevance

1Application 11Process 11Value Tree 11

2Health Status* 10Information 10

3Competence 9Goal* 9

4Cost 8Requirement 8KPI 8

5

Organisation 7Output 7Resource 7Risk 7Service 7

6

Input 6Law 6Policy 6Role 6

7Event 5Rule 5

When sorting the elements in tables 4 and 8 according to the respondents’ time workingat Folksam (see tables 13 and 16) or time working with capabilities (see tables 14 and 17),no clear patterns can be seen. It might be that those who have worked with capabilities fora longer time does not deem Risk or Role to be relevant elements.

If the results could be considered statistically significant, the following can be seen whengrouping table 4 according to the respondents’ positions (see table 12:

• Input/Output is deemed a relevant element only by the Business Architects.

• Everyone except the Business Developers think Information is relevant.

• Organisation and Service are seen as not relevant only by the Risk Managers

This can be compared to table 8 sorted according to the positions of the respondents, (seetable 15), where the following conclusions can be drawn:

• Law, Rule, and Policy are all deemed as not relevant only by the Business Developers.

• The Risk Managers are still the only ones who think that it is not relevant to connectService to Capability.

From this can be concluded that Service is not a relevant element for the Risk Managers.

37

Table 12: This is table 4 sorted according to the respondents’ positions. The first groupare Business Architects, the second Business Developers, and the third Risk Managers. Thetwo remaining respondents are a Governance Specialist and an IT Strategist.

Respondent ID 1 2 3 7 12 6 8 9 4 5 10 11Application x x x x x x x x x xCompetence x xCost xDistribution Channel xEvent x x x x x x xGoal xHealth Status xInformation x x x x xInput/Output x xKPI xLaw/Rule/Policy xOrganisation x x x x x xProcess x x x x x x x x x x xRequirement x x x x x x x x x x xResource x x x x x x x x x xRisk x xRole x x x x x x x x x xScreening xService x x x x x x xValue Tree x

Table 13: This shows table 4 sorted according to the respondents’ time working at Folksam,with longest time (since 1979) to the left and shortest time (since 2015) to the right.

Respondent ID 10 8 6 2 12 9 3 4 5 7 1 11Application x x x x x x x x x xCompetence x xCost xDistribution Channel xEvent x x x x x x xGoal xHealth Status xInformation x x x x xInput/Output x xKPI xLaw/Rule/Policy xOrganisation x x x x x xProcess x x x x x x x x x x xRequirement x x x x x x x x x x xResource x x x x x x x x x xRisk x xRole x x x x x x x x x xScreening xService x x x x x x xValue Tree x

38

Table 14: This shows table 4 sorted according to the time the respondents have workedwith capabilities. The time spans from 2000 (to the right) to 2015 (to the right).

Respondent ID 7 1 10 8 12 6 2 3 4 5 9 11Application x x x x x x x x x xCompetence x xCost xDistribution Channel xEvent x x x x x x xGoal xHealth Status xInformation x x x x xInput/Output x xKPI xLaw/Rule/Policy xOrganisation x x x x x xProcess x x x x x x x x x x xRequirement x x x x x x x x x x xResource x x x x x x x x x xRisk x xRole x x x x x x x x x xScreening xService x x x x x x xValue Tree x

39

Table 15: These are the answers to the questionnaire (table 8) sorted according to therespondents’ positions. The first group are Business Architects, the second Business Devel-opers, and the third Risk Managers. The last two are a Governance Specialist and an ITStrategist. Respondent 8, who did not answer the questionnaire, was a Business Developer.Those marked with * are here attributes of the Capability rather than elements.

Respondent ID 1 2 3 7 12 6 9 4 5 10 11Application x x x x x x x x x x xCompetence x x x x x x x x xCost x x x x x x x xEvent x x x x xInformation x x x x x x x x x xInput x x x x x xKPI x x x x x x x xLaw x x x x x xOrganisation x x x x x x xOutput x x x x x x xPolicy x x x x x xProcess x x x x x x x x x x xRequirement x x x x x x x xResource x x x x x x xRisk x x x x x x xRole x x x x x xRule x x x x xService x x x x x x xValue Tree x x x x x x x x x x xGoal* x x x x x x x x xHealth Status* x x x x x x x x x x

40

Table 16: This is table 8 sorted according to the time the respondents had been workingat Folksam. It spans from 1979 (to the left) to 2015 (to the right). Those marked with *are here attributes of the Capability rather than elements.

Respondent ID 10 6 2 12 9 3 4 5 7 1 11Application x x x x x x x x x x xCompetence x x x x x x x x xCost x x x x x x x xEvent x x x x xInformation x x x x x x x x x xInput x x x x x xKPI x x x x x x x xLaw x x x x x xOrganisation x x x x x x xOutput x x x x x x xPolicy x x x x x xProcess x x x x x x x x x x xRequirement x x x x x x x xResource x x x x x x xRisk x x x x x x xRole x x x x x xRule x x x x xService x x x x x x xValue Tree x x x x x x x x x x xGoal* x x x x x x x x xHealth Status* x x x x x x x x x x

41

Table 17: Table 8 sorted according to how long the respondents had been working withcapabilities. It ranges from 2000 (to the left) to 2015 (to the right). Those marked with *are here attributes of the Capability rather than elements.

Respondent ID 7 1 10 12 6 2 3 4 5 9 11Application x x x x x x x x x x xCompetence x x x x x x x x xCost x x x x x x x xEvent x x x x xInformation x x x x x x x x x xInput x x x x x xKPI x x x x x x x xLaw x x x x x xOrganisation x x x x x x xOutput x x x x x x xPolicy x x x x x xProcess x x x x x x x x x x xRequirement x x x x x x x xResource x x x x x x xRisk x x x x x x xRole x x x x x xRule x x x x xService x x x x x x xValue Tree x x x x x x x x x x xGoal* x x x x x x x x xHealth Status* x x x x x x x x x x

When, during their first interview, the respondents were asked to describe, in short,what they knew about capabilities, seven out of the twelve respondents in some way showedthat they knew the key point: a capability is what a company does. Would this have anyimpact on their answer to which elements would be relevant to connect to the Capability?If table 4 is divided into two groups (see table 18) - those who knew the key aspect of acapability and those who did not - there are no clear differences. The respondents in the”did not know” group never suggested Risk to be a relevant element, but apart from that,the suggestions are spread evenly between the groups. One trend can be seen though: thosewith a better understanding of what a capability is tended to have more suggestions forelements that would be relevant to connect to it. They suggested an average of 8.3 elementsper respondent, compared to the other group’s 6.4 elements per respondent.

42

Table 18: Table 4 separated into two groups. The left group are the respondents that insome way showed that they knew what a capability was what a company does. The rightgroup did not show this when asked what they knew about capabilities.

Respondent ID 2 3 4 6 8 11 12 1 5 7 9 10Application x x x x x x x x x xCompetence x xCost xDistribution Channel xEvent x x x x x x xGoal xHealth Status xInformation x x x x xInput/Output x xKPI xLaw/Rule/Policy xOrganisation x x x x x xProcess x x x x x x x x x x xRequirement x x x x x x x x x x xResource x x x x x x x x x xRisk x xRole x x x x x x x x x xScreening xService x x x x x x xValue Tree xSUM 8 7 11 7 10 9 6 5 5 10 7 5

Does it matter how the respondents were introduced to the concept of business ca-pabilities? The answers to Q1.4 (How did you first come across the concept of businesscapabilities? ) differ, but 6 out of the 12 respondents got an introduction to capabilities bythe Enterprise Architect Team Leader at Folksam. When comparing this half to the otherhalf, who came across the capability concept in some other way (see table 19), one smalldifference was seen. Those who had not gotten the introduction saw Risk as an irrelevantelement, but otherwise their views were similar.

43

Table 19: Table 4 sorted into two different groups. The group to the left first cameacross the concept of business capabilities when it was introduced to them by the EnterpriseArchitect Team Leader at Folksam, whereas the group to the right came across it in severalother ways.

2 3 4 6 8 11 1 5 7 9 10 12Application x x x x x x x x x xCompetence x xCost xDistribution Channel xEvent x x x x x x xGoal xHealth Status xInformation x x x x xInput/Output x xKPI xLaw/Rule/Policy xOrganisation x x x x x xProcess x x x x x x x x x x xRequirement x x x x x x x x x x xResource x x x x x x x x x xRisk x xRole x x x x x x x x x xScreening xService x x x x x x xValue Tree x

7.2 Why Connect Capabilities to Other Elements?

In table 5 the respondents’ answers to the question Why would you like to connect theseelements, and when would it be useful? (Q1.9). Two themes stand out as reasons for usingcapabilities connected to other elements: describing a company, and govern changes. Eightout of the twelve respondents state one or both of these as at least one of the reasons to whythey want to connect capabilities to other elements. When looking at what the respondentsuse capabilities for today (Q1.5), describing and mapping a company or an organisationwas also among the top areas, but together with determining the scope of a project. Seeingwhich capabilities could be affected to what degree, and comparing different projects, iswhat several of the respondents used capabilities for today. Seven out of twelve respondentssaid that they already used capabilities doing organisational mappings or scoping projects.When asked what other uses they could see for capabilities (Q1.6), focus was once again onchanges and how to see where they affect the company. Another important area was to assignand see responsibility, who is responsible for a certain capability or what capabilities youhave responsibility for. Half of the respondents suggested one or both of these as potentialareas where capabilities could be used.

7.3 Affecting or affected?

The last question in the first interview set (Q1.10) asked the respondents if they thoughtthat the elements affected the Capability, or if it was the other way around, e.g. in the eventof changes. Respondents 1 and 2 said that the elements support a capability, but respondent1 also said that they both affect each other. Respondents 3, 4, 5, and 9 all said that theCapability is affected by the elements, and respondents 4 and 7 also said that a capabilityis a container for the other elements. Respondents 6 and 8 said that it could go both ways,

44

and respondent 11 was of the opinion that it would depend on the situation, but that it alsocould be affected by time or corporate culture. Respondent 10 said that if you control acapability by examining its connected elements, then the controlling and its goals will affectthe connected elements, and respondent 12 stated that the elements might change, but thecapability will stay the same as long as you do not change your business model.

This shows that most of the respondents (10 out of 12) in some way think that theCapability is affected by its connected elements, and fewer respondents (4 out of 12) thoughtthat it was the other way around, counting the three who thought that it could go bothways in both groups. One of the respondents simply stated that a capability consists of theelements, but showed no preference as to which one would affect the other.

7.4 A Healthy Capability

When it comes to the well being of a capability, the respondents were asked how they couldtell if a capability was performing well or not. Respondent 6 simply stated that there usedto be ID cards for each capability stating its health status, and respondent 3 said that theclosest thing they do today is checking the current state and business requirements of acapability. Respondents 7 and 8 suggested the use of KPIs showing your goal, and thatthese would be measured before, during, and after the introduction of a capability to showif improvements were made. Respondent 12 suggested measuring Processes connected to acapability, and respondent 11 added Organisations and Systems to the list of elements thatshould be measured. Respondent 5 also said that you should set goals for your capability,and respondent 1 that the well being of a capability could be concluded from how theconnected elements work and cooperate.

This shows that most of the respondents agree on that the best way of understanding thewell being of a capability is to measure and assess the status of its connected elements, evenif it differs which elements should be measured. The Health Status could then be presentedin an ID card for each capability, so that employees who had gotten used to informationpresented in that way could continue using it.

As for what affects the well being of a capability the most, and if any of the suggestedelements affected it more than others, the respondents had several different views. The re-spondents that suggested that particular elements would affect the well being of a capabilitywere most prone to suggest that Organisation and Process would affect it, something 3 outof 8 respondents did, while two respondents suggested that Resource would be affecting theCapability the most.

Respondents 1, 3, 6, and 12 also said that what affects the well being of a capabilitydepends a lot on the capability, and respondent 10 said that the level of acceptance through-out the company is the most crucial part for them right now - ”If the capability concept isnot accepted, we cannot work with it”, they said. How those who work with the capabilityfeel that everything is working is important as well, says respondent 11.

As for if there are any attributes of the elements that affect the Capability’s well being,most of the respondents had no opinion or could not say. However, respondent 12 says thatouter and inner requirements matter, as well as how easy it is to apply the capability andthe knowledge you have about it. Respondent 7 says that redundancies in the organisation,such as duplicate systems or repeated parts of processes, will affect the capability a lot,and respondent 11 says that it is important that supporting systems work as they should,without downtime or error messages.

So, what makes a healthy capability, and how can you measure its well being? It seemsimportant for the capability’s well being that processes connected to the capability runsmoothly, and that there is a clear structure of responsibility in the organisations connectedto it. The capability concept also has to be accepted throughout the company, and those whowork with a capability need to feel that everything works as it should. Elements connectedto the Capability, such as Processes and Requirements, should then be measured throughset KPIs and Goals, which would then give each capability a Health Status. This Health

45

Status can then be graded as Green (working as it should), Yellow (improvements needed),or Red (not working), to easily show which capabilities need the most focus.

8 DISCUSSION

Since this study was qualitative rather than quantitative, it is not possible to draw anystatistical conclusions from the data. The conclusions drawn in section 7 might thereforenot apply on a larger scale. It is possible that the variations in the answers differ on apersonal level rather than e.g. on a corporate position level.

As tables 11a and 11b show, it is easier for people to mark a suggested element as relevantthan coming up with relevant elements themselves. Hence, if Folksam wants to know whichelements are relevant for most people in the organisation, or most people involved in the workwith capabilities, they should provide the stakeholders with a list of all possible elementsfrom which they can choose which elements they think are relevant.

8.1 Interview Difficulties

When looking at the answers to the second set of interviews, four out of the eight respondentswere unable to answer the third question (Q2.3 What attributes of the Capability affects thewell being and performance of it the most? ), and two of the respondents were unable toanswer question number five (Q2.5 What attributes of these elements do you think affect theCapability, and which attributes of the Capability do you think they affect? ). This suggeststhat the questions might have been formulated in a less than optimal way. The conceptof element attributes seems to be unfamiliar for these respondents, and a more thoroughdescription of the concept might have been needed. If elements attributes should be addedthrough a process including interviews with stakeholders, the concept should be made clearbeforehand for all of the respondents.

8.2 Definition Differences

As mentioned in section 5.4, a study at Folksam parallel to this one decided that ”Appli-cation” should be the term used when talking about what in this study had been called”Application”, ”IT Support”, or ”System”. This resulted in those three elements beingcombined into one, since when looking at the interview results with the Enterprise Archi-tect Team Leader, it was concluded that the respondents had used different words for thesame thing. However, this showcases the risk that the respondents were confronted with avocabulary that they were not used to, which in turn might have affected their answers. Tomake sure that this risk was significantly lowered in later steps, the respondents were givena description of each element when completing the questionnaire (with the results seen insection 5.3).

One of the key characteristics of a capability, according to the IT strategy at Folksam,is that a capability is organisation independent (see section 3.3). This, they state, makes itpossible to govern, measure, and follow-up regardless of where the responsibilities lie for e.g.processes or functions. In other words: an organisation can be responsible for e.g. a processconnected to a capability, but not for the Capability itself. This definition differs from theone used when making the meta-model in this report (see e.g. section 6.6), which statesthat the relation between an organisation and a capability is Organisation isResponsibleForCapability. This is due to the fact that the meta-model presented in this report is based solelyon the answers, opinions, and suggestions of the interview respondents. The respondentsexpressed that it would be of interest to them to know which capabilities their organisationwere responsible for performing and executing. Six out of twelve respondents stated in thefirst set of interviews that they have used or would like to use capabilities as a way oforganising responsibility, either for themselves or for a department.

46

9 CONCLUSIONS

This research has resulted in a final meta-model that can be seen in figure 7 in section 5.4.This model contains a central Capability element with two attributes, surrounded by nineother elements, connected by eleven relations in total. The meta-model was created basedon opinions of stakeholders and their views of business capabilities and their well being,expressed through interviews and questionnaires. The Health Status of the Capability hasbeen incorporated as one of the Capability element attributes, and the elements surroundingthe Capability have been described by the respondents as affecting it and the Capability’swell being.

From the interview results can be seen that people who have a better understanding ofwhat a capability is have a tendency to want to connect it to many elements. It is also notedthat most respondents agreed on the usefulness of capabilities when it came to analysingthe scope of advancements and projects, and what parts of the company would be affectedby them.

9.1 Future Research

The meta-model created within this research is only a draft, and has not been incorporatedinto the enterprise architecture repository at Folksam. The meta-model should hence providea starting point for further research into a business capability meta-model at the company.

It is also suggested that Folksam continues to work with how to define the relationbetween capabilities and organisations, to decide if they should use one that correspondswith the theory (that no organisation can have responsibility for a capability), or one thatis preferred by the employees (that shows which organisations have a responsibility for thecapability).

If Folksam wants to further investigate if certain elements are relevant or not for specificpositions or departments, another survey as the questionnaire described in section 4.3 couldbe sent out to more respondents. A quantitative study could yield more reliable data foranalysis.

References

[1] Systems and software engineering – Architecture description. Standard ISO/IEX/IEEE42010:2011, International Organization for Standardization, Geneva, CH, December2011.

[2] Information technology – Object Management Group Unified Modeling Language(OMG UML) – Part 1: Infrastructure. Standard ISO/IEC 19505-1:2012, April 2012.

[3] Information technology – Object Management Group Unified Modeling Language(OMG UML) – Part 2: Superstructure. Standard ISO/IEC 19505-2:2012, April 2012.

[4] ArchiMate 2.1 Specification. Specification US ISBN 1-937218-43-0, Open Group, De-cember 2013.

[5] Definition of Enterprise Architecture, Gartner IT Glossary. http://www.gartner.com/it-glossary/enterprise-architecture-ea/, 2013. Accessed 2015-05-07.

[6] OMG Unified Modeling Language 2.5 Specification. Specification ptc/2013-09-05, Ob-ject Management Group, September 2013.

[7] Enterprise Architect information page. http://www.sparxsystems.com/products/

ea/, 2015. Accessed 2015-05-12.

47

[8] This is Folksam. http://omoss.folksam.se/inenglish/aboutfolksam, 2015. Ac-cessed 2015-05-21.

[9] Respondent 5. Personal communication, first set of interviews, 2015. Risk Manager atFolksam.

[10] Carlos LB Azevedo, M-E Iacob, Joao Paulo A Almeida, Marten van Sinderen, LuisFerreira Pires, and Giancarlo Guizzardi. An ontology-based well-founded proposal formodeling resources and capabilities in archimate. In Enterprise Distributed ObjectComputing Conference (EDOC), 2013 17th IEEE International, pages 39–48. IEEE,2013.

[11] Brian Cameron and Nick Malik. A Common Perspective on Enterprise Architecture.Architecture & Governance Magazine, 9(4), 2013.

[12] Adrian Campbell. Modelling behaviour. https://ingenia.wordpress.com/2010/10/19/modelling-behaviour, October 2010.

[13] Wikimedia Commons. The Zachman Framework. https://upload.wikimedia.org/

wikipedia/commons/4/4e/Zachman_Framework_Rows.jpg. Accessed 2015-07-14.

[14] Robert Elm and Peter Tallungs. EA-spaning nr 11 – Dags att ga vidare fran Zachman.http://www.irm.se/ea-spaning-nr-11--dags-att-ga-vidare-fran-zachman,September 2010. Accessed 2015-05-19.

[15] Charlotte Frank. Personal communication, 2015. Master Thesis Supervisor and Enter-prise Architect Team Leader at Folksam.

[16] Charlotte Frank. Syfte verksamhetsformagor. Internal presentation, 2015.

[17] Martin Henkel, Ilia Bider, and Erik Perjons. Capability-Based Business Model Trans-formation. In Advanced Information Systems Engineering Workshops, pages 88–99.Springer, 2014.

[18] Dave Hornford, Tara Paider, Chris Forde, Andrew Josey, Garry Doherty, and CathyFox. TOGAF Version 9.1, Enterprise Edition. Standard G116, The Open Group, 2011.

[19] M-E Iacob, Dick Quartel, and Henk Jonkers. Capturing Business Strategy and Valuein Enterprise Architecture to Support Portfolio Valuation. In Enterprise DistributedObject Computing Conference (EDOC), 2012 IEEE 16th International, pages 11–20.IEEE, 2012.

[20] Marc Lankhorst et al. Enterprise Architecture at Work: Modelling, Communicationand Analysis (The Enterprise Engineering Series), 2013.

[21] Ministry of Defence, UK. Creating Capability Architectures with MODAF.https://www.gov.uk/government/uploads/system/uploads/attachment_data/

file/36727/20090217_CreatingCapabilityArchitectures_V1_0_U.pdf, February2009. Accessed 2015-07-14.

[22] Ministry of Defence, UK. MODAF Website Download v1.2.004. https:

//www.gov.uk/government/uploads/system/uploads/attachment_data/file/

36757/20100602MODAFDownload12004.pdf, December 2012. Accessed 2015-07-14.

[23] Martin Op’t Land, Erik Proper, Maarten Waage, Jeroen Cloo, and Claudia Steghuis.Enterprise Architecture: Creating Value by Informed Governance. Springer Science &Business Media, 2008.

48

[24] Anastasios Papazoglou. Capability-based planning with TOGAF and ArchiMate.Master’s thesis, University of Twente, July 2014. http://www.slideshare.net/

AnastasiosPapazoglou/capabilitybased-planning-with-togaf-archimate, Ac-cessed 2015-03-09.

[25] Jon Siegel. In OMG’s OCEB Certification Program, What is the Definition of BusinessProcess? http://www.omg.org/oceb/defbusinessprocess.htm, June 2012. Accessed2015-05-18.

[26] William Ulrich and Michael Rosen. The Business Capability Map: The ”Rosetta Stone”of Business/IT Alignment. Cutter Consortium, Enterprise Architecture, 24(4), 2011.

[27] Gerben Wierda. Missing from ArchiMate: (Business) Ca-pability? http://masteringarchimate.com/2012/12/27/

missing-from-archimate-business-capability/, December 2011.

[28] John A. Zachman. John Zachman’s Concise Definition of The Zachman Framework.http://www.zachman.com/about-the-zachman-framework. Accessed 2015-05-19.

49

A Interviews

These are the transcripts of the recorded interview answers. Since the questions are statedin tables 1 (for the first set of interviews) and 2 (for the second set) above in the report,the interviewer’s questions (in italics) are shortened and are shown here to indicate whatquestion was discussed rather than showing its exact wording.

A.1 Interview set 1

Respondent 1

Bakgrund:

Jag borjade jobba pa Folksam har 19e januari, sa jag har inte jobbat har jattelange. Jagjobbar har som verksamhetsarkitekt pa koncernarkitektur. Innan dess sa har jag jobbat paSEB, som deras motsvarighet till affarsarkitekt, dar kallas det Enterprise Business Architect.Dar jobbade jag pa verksamhets-sidan, och det ar val dar egentligen som jag ocksa kom ikontakt och jobbade med formagor, fran borjan da. Och, vad ska man saga har. Jag harkommit in har pa Folksam och kommer jobba litegrann inom riskomradet, och aven arkitek-turstodjande da. Och dar har vi borjat titta pa det har med formagor. Man har ju jobbatganska lange med formagor, och jag diskuterade ocksa med Charlotte tidigt, nar vi hadevar dialog ikring hur vi hade jobbat pa SEB och hur de jobbar har. Sa det ar val litegrannbakgrund. Innan jag jobbade pa SEB, dar jag borjade 2011, sa har jag jobbat ett par arsom konsult inom manga olika delar, i borjan som utvecklare, har jobbat som projektledare,har jobbat mycket inom management strategi-konsulting och sa. En bit bakgrund.

Sa, kortfattat: vad vet du om formagor och verksamhetsformagor, och hur anvander nidet?

Jag jobbar med det ungefar sen 2011, som egentligen ett verktyg i Enterprise Architecture-arbetet. Jag har ganska tidigt borjat jobba med Enterprise Architecture, typ 2001 nan gangborjade jag med de tankarna, sen har jag kontinuerligt byggt pa olika verktygssatt att arbetamed dar da, och formagor ser jag som ett satt att skapa en hogre niva av diskussion medintressenter, sa man inte behover ga ner och fastna i detaljer for att scopa in saker och ting,for att identifiera problemomraden och sa vidare. Det blir sa latt annars att man utifrankanske ett affarsomrade eller en specifik kunskap fastnar i en detalj som ar ganska oviktig patotalen, men det for inte dialogen framat. Jag kan saga att nar vi tittade pa formagor, narjag borjade titta pa det da, kring 2011, da anvande vi oss mer ur ett affarsfunktionskoncept,alltsa egentligen en behallare du kan lagga affaren i da, olika delar. Och det var mycket uranalyshanseende da, sa at man kunde pa ett enkelt satt mappa ner det, men ”vad ar detfor nanting ett speciellt initiativ eller en satsning kommer berora?” ”Vad ar det vi behovertanka pa sa att vi far med allting?” Sa det var mer ur det perspektivet an att vara specifik paatt ”det ar precis det har” eller ”det ar bara 20% av den har delen”, utan vi bara markerade iform av en heat map att det har och det har och det har omradet, det berors. Sen borjade juvi vava ihop egentligen, satt att se, men ”hur forhaller sig formagor till affarsmodeller”, ”hurforhaller de sig till vardekedjor” osv. Och det jobbade vi ganksa mycket med att fa ihop dettanket, sa vi kunde ha olika typer av verktyg, och prata med olika personer i verksamheten,beroende pa var de var och vad de hade for , egentligen bakgrund och kunde forsta. Vissakunde vi prata formagor med, andra pratade vi affarsmodeller, och sa mappade vi ner sjalvatill formagor. Och det ar val det sattet som jag har sett att det funkat bast. Man kan ju tada som exempel att om vi far ett lagkrav pa oss, ja men da kanske man tittar pa en specifikaffarsmodell, ja men ”vad var det nanstans det har kommer rora?” ”Jo men det kommerrora rapportering”, ”det kommer rora kunderbjudande” och sa vidare. Har man tagit dennivan, ja men da kan man ploppa ner det sen pa formagor, och se ”Vilka formagor ar det

50

som det beror?” Och da beror det ju pa vad vi lagger i den har formagecontainern da. Ochmitt synsatt pa det har ganska pragmatiskt varit fyra komponenter: det har varit organ-isatoriska, det har varit process, det har varit information, och det har varit system. For attkunna, liksom, har du landat i en formaga ”Beror det organisation?”, ”nej, det beror inteorganisation”, ”beror det processer?”, ”ja, det beror det”, och sen ” okej, automatiseradeprocesser” och i sa fall vilka. Sa att man liksom har kommit ner till nagon typ av att man kangora analyser. Sa det ar sa liksom, de sattet man hanger ihop det pa. Det mindset’et har jag.

Nar dok det har upp, konceptet med formagor, och pa vilket satt, i vilket sammanhang?

Sammanhanget var egentligen att, och det var tillbaka nar jag jobbade pa SEB, att vihade en funktionskarta. Nar vi borjade titta pa den och hur den funkade, och aven hadeomvarldsbevakning och man borjade diskutera mer och mer formagor, det dok upp nanstans dar 2010-2011, det var da jag borjade fa upp det pa kartan. Da borjade vi titta pa det”Ja, men det har ar ju i stort sett formagor”, sa. Sen hade vi ett ganska pragmatiskt sattatt se att vi hade den har affarsfunktionaliteten, den har komponenten eller formagan, detvar en niva 1:a for oss, och sen det vi hade under den direkt, vi brot inte ner den i separataformagor utan vi sa att ”nej men vi tar vara processer, sa lagger vi huvudprocesserna i denformagan, sa vet vi att de haller nagon typ av funktionalitet pa det sattet”. Sen kan manju titta pa den och se att det fanns ju for- och nackdelar med att gora det. Processerna arju bara en del av en formaga egentligen, men det fyller den funktionen som vi ville ha da.Sa sag 2011 darikring. 2010-2011.

Hur har du anvant dig av formagor?

Det ar just egentligen, jag har jobbat mycket med Quality Assurance, pa projekt och savidare, och en del i det var att vi i dokumentationen hade att projekten skulle fylla i medvilka komponenter det ar de spanner over. Och det var ju formage-delen, sa att saga. Dafick de egentligen beskriva, till den niva som de visste vid tillfallet. Det ar ju olika delari olika faser for olika projekt hur mycket de vet men, forst borja overgripande ”Ja, mendet kanske bara rorde en formaga pa toppniva”, och sen kunde de ga ner och markera ”ah,men just det, den och den processen ror det da, och sen den har organisationen”. Sa attdet var egentligen ur att sakerstalla da att jag som stakeholder fran verksamhets/IT-sidansakrade upp att projekten hade ratt scope. Och likadant att var de i ett visst omrade mankunde se pa den har kartan om det var andra saker ”Ja, men det har ror sig dar” man kundefa nan typ av korsreferens hur projekten rorde sig. Sa mycket ur liksom analys och planering.

Forutom da Quality Assurance, vilka andra anvandningsomraden kan du se for formagor?For dig/avd...

Nej men det ar just.. En del det ar ju att kunna fa grepp om helheten, for det ar judet som liksom ar huvudsyftet tycker jag, att kunna se ”Ja man hur slar det har” och ”hurslar det i jamforelse med andra satsningar” och sa vidare. Jag ar valdigt forsiktig med attliksom hitta, ja men ”nu ska vi mata pa formagor” for en formaga den ar egentligen kon-ceptuell, den ar inte specifik. Den kan besta eller stodjas av manga olika saker, en processtill exempel. Och en process, den kan du mata. Du kan tidsmata, och vad har den forgenomstromning och vad har du for resultat och sa vidare. Men det ar bara en liten del.Om man skulle liksom, rita en cirkel har som ar formagan, sa den har delen, 60% eller vaddet nu ar (ritat 30-40), bestar av matbara delar, som process, organisation osv. Den harandra delen har, det ar annat. Det kan vara liksom, du rakar satta tre personer som har enviss bakgrund i samma rum och anvander olika saker och da far du en en effekt, men denar liksom inte sa har pataglig. Och darfor sa tror jag att det kan vara svart att mata paformagor. Du kan mata pa stodjande delar, men du kanske inte vet exakt alla delar. Om

51

du tar samma personer, samma processer och samma setup i en organisation, och tar detutanfor Folksam, sa ar det inte sakert att du far samma resultat i formagan i vilket fall. Sadarfor ar jag lite forsiktig nar man sager att man ska mata pa formagor. Jag tror att mankan mata pa process och information osv. Sen kan det ge en indikation pa hur formaganmar, sa det ar lite sa. Men matbarhet, ja, till viss del, subjektiv da. Och det kan ocksa varada att har du identifierat omraden som du kanner att du maste forbattra, ja men da kanskedu gar ner annu mer och kollar pa, ja, men ”Kan vi utoka den delen som vi vet, och minskadet har fragetecknet?”

Vad ser du skulle vara relevant att mappa till en formaga, utom just process, information,organisation (och system)?

Jag skulle saga att du skulle egentligen kunna koppla vad som helst till en formaga, detberor bara pa vad du satter for relation, och pa den kopplingen. Litegrann den har cirkelnsom jag ritade dar, det kan vara system som stoder saker och ting, det kan vara kompe-tenser, organisatoriska uppsattningar, ja men hur du satter upp din organisation, det kanvara de ingaende kompetenserna ocksa. Det kan vara, du skulle kunna ta till exempel attvaran VD har ett kontaktnat ute i organisationen, eller ute pa marknaden, som gor att vifar bra kontaktytor och kan gora bra avtal, sa. Det ar ju nagot som forbattrar var formagaatt gora forsaljning, men den ar ju inte sa jattepataglig, men den skulle kunna finnas dar.Sa att jag tror att det ar mycket som bygger upp formagorna. Sen ar det vissa delar somvi kan pinpointa och analysera och forbattra, och andra saker sitter i vaggarna. Sa att jagskulle kunna saga att de har sakerna som du har raknat upp har: Krav, ja, du kanske kansatta nan typ av krav pa den, men jag tror inte du ska koppla krav till en formaga. Dukan forbattra en formaga, men kraven kommer du att satta pa en organisation, process ellernat sant. Resurser, ja, du maste ha resurser som stodjer en formaga, men att troligtvis sastodjer de ingaende delar i den istallet, och inte formagan som sadan. Resultatet av detblir att formagan forbattras eller forsamras. Sa att jag tror att, direkt och indirekt, och jagvet inte om vi har nan nytta av att liksom, satta hela fulla metamodellen for den, utan jagtror att det ar viktigare att vi riktar in oss pa saker och ting som vi ser ar relevanta foross som vi kan forandra. Och jag skulle saga att huvudingredienserna ar egentligen de harfyra. Lagg till/ta bort personal, utveckla personal, forbattra din process, eller sa. Det ardet som i en forandringsprocess ar sapass patagligt. Sen kan man ju, man maste se det somen helhet. Man kan inte bara modernisera det ena eller det andra, sa. Sa att jag skulle intevilja begransa mig till att du inte kan koppla saker och ting till en formaga, men fragan ar:Ger det dig nagon reell nytta i ett forandringshanseende? Och det tycker jag ar viktigt.

De som du tycker ar vettiga att koppla till formagan ar alltsa de fyra du har namnt?

Ja, men det ar de har fyra som jag sa: organisation, information, system, och process.Och det kan man ju, liksom, det ar litegrann darfor jag skickade det har till dig ocksa,det har med verksamhetsformaga, vad ar en verksamhetsformaga eller en formaga eller enIT-formaga? Det ar ingen ide att kalla den, sager du verksamhetsformaga da finns det nanannan typ av formaga ocksa, implicit. Och pratar du om IT-formagor, ja men det ar juegentligen en formaga som ar automatiserad, sa. Sa att vi vinner ingenting pa att lagga uppflera olika begrepp. Vi har haft diskussioner om affarsformagor och verksamhetsformagor.Affarsmodell, ja, men en affarsformaga..? Nja. Jag tycker det ar att skapa onodiga konflikter.Men sen har vi ju samtidigt haft, apropa att man avander formagor, formaga inom HR da,och da ar det ocksa, ja, forvisso. Vi anvander ju tjanst och andra begrepp ocksa beroende pahur verksamheten ser ut. Sa jag tror inte man ska ta nat patent pa det, men det ar ju viktigtatt forsta vad vi anvandet det till, och varfor kallar vi det formaga. Pa engelska, capabil-ity, ja, det ar valdigt nara ability och sa vidare, men vi har inte sa bra svenska ord for allting.

52

Sa de har fyra som du tycker ar relevanta..

Och de tror jag ocksa att vi bor modellera i FAR6, sa vi far liksom ett meta-stod for dem.De ar ganska uppenbara, de finns pa alla formagor.

Sa varfor och vilka element det skulle vara har vi ju da avhandlat lite redan..

Sen tror jag som man har satt som inriktning har pa Folksam ar ju att man vill ha mojlighetatt mata pa forandring. Som 2018 da vi ska ha genomfort ett visst antal saker, det ar jubra att kunna se, sa att saga, hur gor vi da den forflyttningen? Dar tror jag att formagornahar en roll, men det ar en pusselbit bland andra, sa att saga. Sen finns det ju det har be-greppet ”Tala med bonder pa bonders vis” och sa vidare, men det ar ju litegrann det. Vissakommer du behova prata formagor med, andra far du prata, liksom, systemkartor med, ochen tredje kommer det vara informationsmodeller. Men det galler att de hanger ihop och att..

Att man kan mappa allt till sammma?

Ja, men liksom, pratar du om en sak med en, da far ju inte det divergera mot andratyper av modeller for att da kommer du inte na ett gemensamt resultat. Men sen att detfinns olika typer av verktyg. Jag kan se att till viss del skulle man kunna ha verktygsladan iform av formagor, ja, men den skulle kunna vara en intern angelagenhet for arkitektur, sa.Man behover inte salja pa den, men daremot sa pratar man kanske utifran den for att ha ettgemensamt ramverk, men for den delen sa behover man inte trycka upp en modell i ansiktetpa verksamheten och saga ”Det har ska vi anvanda nu!”. For att det ar min erfarenhetocksa, att, liksom, powerpoint i all ara, men du maste ha en acceptans fran den mottagaredu har, pa det sattet som du vill jobba. Och visst, vill de jobba med formagor och forstardet och sa vidare, ja, men da ska du gora det. Men jag tror inte du kan tvinga pa nagondet, da far man hitta pa andra satt. Och sen mappa hemma istallet. Sa det ar lite arbetssatt.

De har fyra elementen, tror du de paverkar formagan, eller blir paverkade av den, om detsker forandringar?

Min syn pa det ar att alltsa ingaende delarna stodjer formagan. Sa att svaret pa det du sadet ar val bade och. For eftersom pa nat satt forandrar du ingredienserna, ja men da kom-mer resultatet bli nagot annat. Men.. Det blir sa har meta-meta.. Jag menar, formagan attgenomfora en process, ja men det ar ju en sak, men hur den processen stodjer en formaga,det behover ju inte vara samma formaga den stodjer liksom. Abstrakta saker.

Vilka delar av en formaga eller elementen paverkas av varandra? Hur ser mappningenmellan dem ut?

Du kan ju ha beroenden mellan formagor, det kan du ju ha, i och for sig, om du skaha ett resultat. Det vi.. Jag kan visa bara hur vi forsokte fa ihop den har roda traden paSEB. Da hade vi affarsmodeller, och da anvande vi Business Model Canvas for den. Da ardet egentligen en flerfarltare som bestar av att du har ett vardeerbjudande, Value Propo-sition, i mitten. Du har hur du vill ha relation till dina kunder, du har dina kunder, duhar kanaler. Sen pa den har sidan sa har du Key Activities, Key Resources och Partners.Sa kan man lagga en aspekt pa det att man har Cost och Income. Vad vi gjorde med denhar, det var att vi hade affarsmodeller, fyra-fem stycken, inom den affar jag jobbade da.Da sa vi det att det som ligger har, Key Resources och Key Activities, det motsvarar deformagor som vi har. Pa en hog eller en lag niva, vi satte ingen aspekt pa det, men harskulle det till exempel kunna innefatta en Key Activity har ar rapportering for att du ska

6Folksam’s Architecture Repository

53

fa ut nagon typ av vardeerbjudande till kunden har da. Det skulle kunna vara att du harIT-resurser har eller nanting annat som stodjer formagan. Sa da sa vi att den kopplingenfinns da. Sen sa vi ocksa det att de har delarna, Key Activities och Key Resources, de kanaven bygga vardekedjor, liksom, fran borjan till slut i nan typ av leverans. Och da skulle dehar formagorna, sa att saga, vara staplade pa led da. Den anvande vi inte sa mycket, menden fanns i varje fall. Och sen hangde vi pa de har andra sakerna da, organisation och savidare. Sa det var liksom varan roda trad vi jobbade efter dar. Men det man kan saga har,om man skulle bortse fran den dar (BMC), och bara titta pa formagedelen, sa skulle ju enformaga kunna besta och stodjas av en process pa det har sattet. Den processen skulle jukunna stodja en annan formaga ocksa. Sa att har har du ju ett beroende mellan formagor panagot satt, och likadant en organisation skulle ju kunna stodja olika typer av formagor. Manskulle ju kunna ha en formaga, en dalig formaga som heter bara rapportering, det ar intesa mycket av en formaga, men mojligheten att gora myndighetsrapportering. Vi kommerju gora det i en mangd olika processer, for en mangd olika rapporter. Vi kommer gora deti olika organisationer ocksa. Det behover inte vara myndighetsrapportering, det kan varabolagsstyrningsrapporter, eller det kan vara Solvens, det kan vara vad som helst, men det armanga saker som stodjer den. Men daremot att formagor skulle vara beroende av formagorpa det har sattet (direkt kopplade), den blir lite knasigare ur ett analyshanseende. For attda far du liksom att en formaga, da kan du aldrig liksom lyfta ut det eller sa, och da trorjag att da har man hamnat lite knasigt i vad en formaga ar, om man borjar fa beroendenmellan formagor pa toppnivaer. Sen langre ner sa kan det ju, klart, om du ska bygga ihop envardekedja, ja men det maste ju finnas, sa att saga, bitar ur olika typer av formagor, sa, foratt det ska funka. Men pa toppniva sa tror jag att det inte ska vara kopplingar mellan. Sedet mera som byggklossar som du anvander for att bygga ihop det stod du behover ha da.Och litegrann den ocksa, relaterat till det har med affarsmodeller. Har du da en legoladahar (formagorna), sa skulle du kunna bygga helt nya affarsmodeller om du anvander deformagorna som du har, bara det att du konfigurerar dem pa ett annat satt. Sa, lite sa armina tankar.

Respondent 2

Vilken position har du, hur lange har du haft den, och hur lange har du jobbat pa Folksam?

Jobbar som verksamhetsarkitekt, och nu jobbar jag med nanting som heter Koncernge-mensamt. Och det har vi val inte gjort sa dar jattelange, det ar valdigt nytt, sa det ar baranagra manader gammalt. Innan dess jobbade jag som verksamhetsarkitekt inom produktoch ekonomi, och det gjorde jag i ungefar tva ar, knappt. Och innan dess jobbade jag ganskalange inom skadeorganisationen, ocksa som verksamhetsarkitekt. Det kanske racker sa, mentotalt sett sa har jag val varit pa Folksam i ungefar 13 och ett halt ar, och varit i principnastan overallt utom i koket.

Kortfattat, vad vet du om formagor?

Ja, att det finns ju lika manga uppfattningar om vad en formaga ar och vad det bordevara som det finns nastan personer. Sen finns det manga som vill anvanda olika typerav standardmodeller att utga ifran. Och jag har val kommit till det laget att det ar valklart att de ar bra, men jag tror att vi kommer aldrig bli fardiga liksom ”Det har ar exaktvara formagor”. Men det ar viktigt att vi har nagnting att diskutera med verksamhetensom de forstar och kanner igen sig i, i alla fall pa ett nagorlunda bra satt. Sen kommerden ju alltid att behova justeras. Men de beskriver ju som sagt vad man ska hantera i enaffarsverksamhet, inte hur da, vilket da ar en process.

Hur lange har du jobbat med formagor?

54

Nar det dok upp? Som forsta gangen har pa Folksam sa har det nog varit, ja, jag skulle gissaatt vi har hallit pa och provfuskat i ungefar 2 ars tid, mer eller mindre, i olika omgangar.Men det ar val egentligen inte forran nu pa sistone som det har tagit lite mera skruv, omman sager sa.

Hur kom du i kontakt med formagor? Hur introducerades det? Var kom det ifran?

Var det kom ifran? Ja, det kom i yrket, darfor att vi har ju valt att beskriva verksamheten..Man kan ju beskriva en verksamhet pa massa olika satt, och vi har ju lange forsokt attdokumentera saker och beskriva saker i processer. Och vi fann da att det fanns, att det harblivit lite, sa att saga, forbrukat, om man uttrycker sig sa. Det vi vill hitta ar en mera, saatt saga, neutral beskrivning av verksamheten, och det var da som vi hittade de har, liksom,formagorna. Och fordelen med formagorna ar ju att de ar inte knutna till en organisationpa samma satt som kanske processer ar, pa det sattet.

Har du anvant dig av formagor?

Oh ja. Bland annat sa har vi anvant det for att forsoka beskriva vad ar det nanting somman har for ansvar, och vad ar det som man jobbar med inom omradet Ekonomi. Och damenar jag inte organisationen Ekonomi utan hela omradet ekonomi. Att forsoka beskrivavad ar det for verksamhet, eftersom man maste forsoka halla ratt pa, och styra och kon-trollera. Och vi kommer ocksa anvanda det i strategiarbetet som vi haller pa med nu, inomkoncerngemensamt, dar vi forsoker att bedoma ”Hur bra mar en formaga?”. Och da har viliksom en skala, fran Rott - fungerar inte alls, Orange, Gult, och Gront - fungerar kanonbra.Men sen har vi gatt vidare och tittat litegrann pa varfor mar en formaga inte Gront, vadberor det pa? Och da gor vi samma berakning dar, eller bedomning dar, sa har ”Beror detpa processerna?”, dvs hur bra mar processerna? Och ”Hur jobbar vi gentemot andra?”. Detar ocksa huruvida vi har god kvalitet pa den information vi hanterar, och allt vi tar med,det paverkar ocksa. En tredje viktig aspekt ar ju da vilken kompetens ar det egentligen vibesitter och har for att hantera den har formagan. Den ytterligare biten ar da ”Hur marsystemstoden som ska stotta de har formagorna?”, och slutligen har vi ocksa en ytterligareextra variabel, det handlar ju ocksa om integration, for information spanns ju inte mellanbara tva applikationer, utan det kan vara en hel skog med saker. Och det dar forsoker vida anvanda for att bedomma, om inte en formaga mar speciellt bra, vad beror den pa? Forannars ar det ju ofta att man vill anvanda argument att ”Vi behover ett nytt IT-stod”, eller”Vi behover ett forandrat arbetsstod”, men ett IT-stod hjalper inte en dalig process. Omman automatiserar en dalig process sa blir den inte battre. Om man har dalig information,sa blir den inte battre for att de far ett IT-stod. Har man inte kompetens sa hjalper detheller inte, liksom, sa det ar flera aspekter. Sa sa haller vi, just nu i alla fall, i dagslaget paatt forsoka beskriva ”Hur mar formagor?”, ”Hur mar verksamheten?”, och ”vad beror dehar olika sakerna pa?”

Vad kan du se for andra anvandningsomraden for formagor?

Oh, det finns en hel skog med olika typer av anvandningsomraden. Nej, men det ar juen lite mer neutral, sa att saga, kladhangare da, som man kan realisera formagorna till. Nuar det ju inte sa att om man nu skulle valja att, till exempel, bryta ner en formaga, sa har viju sagt litegrann nu da att en formaga kan inte bli nanting annat an en formaga. Daremot sakan den ha relationer med massa olika typer av saker, lost hangande. Till exempel processer,organisation, information, kompetens, och sa vidare. Men nar du bryter ner en formaga sablir det ingenting annat an en formaga, litegrann sa.

Finns det nagra andra element an de du namnde, process, organisation, som du skulle vilja

55

kunna koppla ihop med en formaga?

Ja, det beror sig ju alldeles pa vad man ska ha det till. For nu har ju vi mest anvant detfor att vi, sa att saga, vill gora olika typer av forflyttningar inom de har primara omradena.Det finns sakert anledningar att titta pa andra saker, till exempel Risk, vilka risker har vi?Men det haller ju liksom litegrann Risk och Compliance pa att jobba litegrann med, sa darforsoker vi ocksa anvanda det litegrann. Sa det finns sakret flera sana tillamningar dar mankan, sa att saga, utoka det har for att fa det lite mera neutralt.

De element som ar listade har, ar det nagra du ser skulle vara relevanta att koppla tillen formaga? Krav, till exempel?

Ja, nar jag sen visar dig den har bilden kan du se, vi haller pa att titta lite pa det, vilkeninformation ar det som ar intressant utifran, sa att saga, forandringsarbete? Och da ar detju, vilka som ar direkt kopplade till en formaga, eller vilka kommer i ett senare led. Saatt sjalvklart kan vi koppla alla dem egentligen, mer eller mindre, direkt eller indirekt, tillformaga. Sa jag svarar ja pa alla. Om man nu vill det. Men det finns inget sjalvandamal,utan det ar ju, liksom, man vill ju liksom beskriva en verksamhet, man behover ha nannytta, det ar da man vill ha en koppling aven till formagorna. Sa att egentligen ser jag ingadirekta begransningar, till skillnad fran till exempel processer eller andra grejer, dar det kanfinnas, vara lite mer olampligt att koppla ihop olika saker.

De har elementen, varfor ar just de relevanta, och hur anvander ni dem?

Ja, det handlar ju forst om att forsoka beskriva ”Vad har vi for verksamhet?”, vi har ocksavem som ansvarar litegrann. Det ar vi inte riktigt overens om, om det ska finnas nagonsom ansvarar for en formaga, det haller vi pa och trater litegrann om. Men jag ser att det ialla fall finns ett ansvar att forandra, eller forbattra, eller att ha ett ansvar att, sa att saga,formagan fungerar. Men nu har vi ju inte processagare heller, sa nar vi kommer till, ja,formageagare, sa kanske det ligger en bit framat i tiden.

Dessa element, paverkar de eller blir de paverkade?

Ja, alla de har elementen kan ju bidra till den har formagan, pa mer eller battre satt.Sa tror jag det snarare ar. Att du kan, sa att saga, bra processer kan bidra till att vi haren bra formaga, har vi bra systemstod kan vi ha en bra formaga, att vi har bra risk ochkontroll kan bidra till den har formagan, men kanske inte tvart om. Sa det ar kanske at dethallet. Men det ar sa som jag spontant svarar pa fragan just nu.

Respondent 3

Bakgrund:

Jag ar verksamhetsarkitekt pa Folksam, och det har jag varit i snart tva ar. Sa jag sit-ter i.. under Fredrik Wahlstrom som Chef och Charlotte som teamledare, Charlotte Frank.Och bakgrunden ar ju att jag har jobbat inom IT-management och verksamhetsutveck-ling i 19 ar ungefar, pa olika satt, som konsult eller som chef, for de har olika delarna da:affarsutveckling, verksamhetsutveckling och IT-management, kan man saga.

Och du har jobbat pa Folksam sen..?

Snart tva ar.

Kortfattat, vad vet du om formagor?

56

Ja, jag vet egentligen det som jag har.. pa det satter som jag har jobbat med formagorhar pa Folksam da i snart tva ar, som vi i varan grupp har byggt upp en formagekarta. Ochdet ar ju for att kunna beskriva vad vi utfor, vad vi gor inom Folksam. Ja, sa kan man ju..Vi har tagit fram en karta, vi har tagit fram ett index som ska ringa in hela Folksams verk-samhet, allt vi gor, inom alla olika delar. Och att sen kring varje formaga sa finns det ju enrad information, det finns processer, och ett antal olika information som hor till formagan.Och vi brukar jobba med dem pa det sattet att vi brukar titta vilka formagor som paverkasi olika forandringsprojekt, for att se skillnaden mellan olika projekt. Och kunna forsta vilkasom, ja, vilka som beror olika formagor da, olika projekt, och kunna jamfora dem. Ochprioritera mellan dem ocksa.

Hur lange har du jobbat med formagor?

Ja det borjade jag med pa Folksam, det var forsta gangen. Sa det ar ett och ett halvtar kan man saga.

Hur kom du i kontakt med formagor? Hur introducerades det?

Ja, det var Charlotte Frank som borjade introducera det, och hon hade aven hjalp avandra medarbetare och konsulter da, som beskrev ett upplagg med en formagekarta somcentral i det man jobbade fram. Som hade lite mallar att visa for vilken information mankan kartlagga i varje formaga ocksa.

Har du anvant dig av formagor, och i sa fall hur?

Ja det ar i de analyserna vi gor, kring vara nya projekt eller nya initiativ. Da ar det i omfat-tningsanalyserna oftast da, som vi jobbar med att titta pa vilka formagor som paverkas. Ochdet kan ocksa vara da, nar vi ska jamfora olika projekt med varandra, omfattningsanalyseller inte, men just att se paverkan pa organisationen, sa kan vi anvanda oss av formagoroch titta hur affarskraven traffar formagorna, det ar det vanligaste sattet som jag har gjorti alla fall.

Kan du se nagra andra anvandningsomraden for formagor?

Ja, det ar ju egentligen i alla fall dar man behover ha en oversikt av var man ar ochdriver sitt arbete. Man kan jamfora olika avdelningar, om det finns andra som har sammaformagor, eller liknande formagor. Da kan man se om man skulle kunna hjalpa varandraatt utfora formagan pa ett battre satt. Eller om man kanske kan skrota formagan pa detena stallet och fa till en effektivisering pa det sattet da, och tjana tid och resurser. Det kanju vara i allt forandringsarbete egentligen, eller forbattringsarbete, att man borjar att tittapa vilka formagor man har, vilka man kanske skulle behova. Det kan vara ett annat sattaatt tanka. Och vad som saknas da, eller vad som ar gap inom den nya formaga som manonskar. Eller aven om det ar en befintlig formaga som man har, kan det vara ett gap mellannulage och borlage, da kan det vara ett satt att borja.

Vilka element vill du koppla till en formaga?

Det kanns som att det kan variera beroende pa olika situationer, i och for sig. Men hurvi jobbar inom formagan och vilka processer som finns dar, ar ju en del i alla fall. Och omdet ar inputs/outputs eventuellt ocksa, till formagan. Vilka informationsobjekt som finnsinom formagan, kan hjalpa till. Kanske aven vilka IT-system som finns dar. Det har ar valdet som ligger narmast mitt jobb da, sana har delar som jag rapar upp nu da.

57

Fem attribut fran litteraturen, vilka ar relevanta?

Ja, men krav ar ju ett satt som vi jobbar idag faktiskt, att lagga in, eller koppla till formagor,affarskrav oftast, ar det som ar just i varan roll da. Nu far vi nastan ta en i taget dar.

Absolut. Resurs?

Resurser. Ja precis, det kan ju vara om man jamfor hur formagan utfors da inom or-ganisationen, om den finns pa flera stallen exempelvis, och titta pa hur manga resurser somjobbar med den. Att kunna jamfora da i nasta steg, hur jobbar de med den, och varforbehovs det fler resurser pa ett stalle an ett annat stalle. Finns det delar i vad den harresursen utfor som man kan samordna eller inte.

Roller?

Roller, ja. Det kanske var lite det jag touchade har precis nyss da, det kan vara fleraolika roller som jobbar inom formagan, och de kan ligga nara varandra eller langt ifranvarandra, de kan utfora samma saker eller lite olika saker. Och det kan ju vara ett sattatt strukturera upp ocksa, sa att det blir annu tydligare hur formagan skiljer sig pa olikaorganisatoriska delar i foretaget.

Service?

Tjanst. Ar det tjanst pa nat speciellt satt du tanker, tjanst pa var websida, pa det sattet,eller mer en tjanst som en process.

Mer at, inte sa mycket websidan, utan snarare process..

Nanting vi utfor for kunden, en san tjanst?

Precis.

Ja, hur gor vi dar da. Nu ska vi se. Ja, i ett projekt sa har vi ju relaterat vara nyatjanster till formagor faktiskt. Det ar i Digitala Affarer, har vi gjort. Sen har vi kanske intesett effekterna av att jobba med det an, om man sager sa, att vi har fatt ut sa mycket avdet. Men vi har gjort den kartlaggningen i alla fall.

Handelser?

Handelser, ja, da gar ju mina tankar till vara CRM-projekt da, och CRM-verksamhet.Dar har vi ju, det bygger vi helt enkelt mycket pa dialoger med kunden nar det hander enviss, nar en viss handelse intraffar for respektive kund sa soker vi ju kontakt for att se omde har behov da, efter att den har handelsen har intraffat. Om de har fatt barn, eller om dear pa vag att fa barn, om de vill ha en gravidforsakring exempelvis. Da ar det en handelse.Och, ja, den skulle man behova fundera lite mer pa.

Varfor tycker du dessa element ar relevanta att koppla ihop med formagor, och i vilka situ-ationer vill du anvanda det?

Alltsa, det ar svart att saga att det ar klockrent i samtliga fall har och nu, men mankan se att det finns mojligheter, och att vissa delar utav dem jobbar vi med, och vissa intelika mycket. Men om man ska, sa att saga, sortera upp varan verksamhet och allt vi gor, sa

58

ar det val anda formagor dar vi har kommit ganska langt nu, det ar darfor jag ser att mankan bygga vidare pa det. Och aven da sortera upp olika tjanster exempelvis. Det kannssom en vettig approach for att komma vidare med kartlaggningar som vi, som man har enchans att komma i mal med ocksa for hela foretaget. For det blir ganska stora arbeten ochborja med en ny approach da tar troligtvis langre tid an att jobba med formagor som vi harkommit en bit med. Och det kanns lite enklare an att jobba med processer, i manga nivaer.Formagor sager ganska mycket pa typ, niva 3, da har man kommit ganska langt.

Tror du att elementen till stortsta del blir paverkade av formagan, eller paverkar formagan?

Hur menar du nu?

Om det sker forandringar, ar det elementen som paverkar formagan, eller tvartom?

Aha. Hmm. Ja, det var en bra fraga faktiskt. Jag funderar pa vad man skulle kunnata for exempel dar. Om kraven forandras inom en formaga, i en forandring, da kommer deatt driva forandringen pa formagan, i det fallet i alla fall.

Finns det nagot du kan tanka som skulle kunna ga at andra hallet?

Hmm. Det som hander utifran det ar ju hur vi, vilka regelkrav vi har pa oss, eller vilkalagar vi har. Det betyder att vi maste utveckla varan formaga for att kunna ta hand omnya lagar, om det ar sa man tanker har, jag vet inte. Och likasa nya omvarldstrender da,det driver ju krav pa nya erbjudanden da exempelvis, och forbattrade erbjudanden. Deformagorna som har att gora med att hantera erbjudanden och utveckla erbjudanden. Jagvet inte om det var ett exakt svar.

Respondent 4

Bakgrund:

Bakgrund pa Folksam, jag har varit har i tva ar, jobbar som Risk Manager, framst med op-erativa risker, eller verksamhetsrisker, begreppet har lite olika benamningar. Pa det sattetsom jag kom i kontakt med formagor, eller arkitektur, det var egentligen pa grund utavatt i min roll sa behover vi kartlagga, vi har ett behov av att beskriva en verksamhet ochkartlagga den pa nat satt. For att kunna titta pa var nan stans i verksamheten finns detrisker, och var finns det kontroller. Sa det var utgangspunkten till formagan.

Kortfattat: vad vet du om formagor?

I borjan, inte sa mycket. Jag var mer bekant med processer. Men jag kan inte saga attjag har liksom last processteori. Och jag har jobbat med processkartlaggning liksom, pa envaldigt oteoretisk niva. Nar vi borjade med formagorna sa blev det ju liksom mer teore-tiserat, vilket var bra. Och aven den har bakgrunden till processer, att den kommer franprocessindustrin, sa formagor ar liksom nasta steg, kan man saga, i mer i , hur det fungerari tjansteforetag. Det ar lattare att jobba med formagor pa det sattet. Nar vi borjade jobbamed det har sa, grundforklaringen var att formagor ar, ja, men ”Vad gor man”, medansprocesser ar ”Hur gor man det”, vilket var ganska lattsmalt forklaring. Vi har forsokt, senhar man liksom lart sig mer, och forstatt mer om formagorna, vilket var valdigt kul. Attforsta hur man ska se pa dem, hur de avgransar sig och forhaller sig till processer och varprocesser kan jacka in nanstans.

Hur lange har ni jobbat med formagor?

59

Sen tva ar tillbaks, precis nar jag borjade egentligen. For jag hade, som en huvuduppgiftvar att borja processkartlagga verksamheten. Och i Folksam ar ju det, det har ju gjorts 100ganger, kan man saga, pa lika manga nivaer, med lika manga syften, ungefar. Och da, saatt borja, att ha utgangspunkten nu, i alla fall hos oss, sa var, formagorna kom in som ettarkitekturstod, for att kunna bygga upp ett repository kring det har. Och da vill ju vi varamed, for att vi staller krav pa att vi ska ha, vi vill garna fa in nagon form utav notationfor kontroll och risk. Sa att man snabbt kunde fa med det i repositoryt. Sen har inte detriktigt blivit sa vad jag vet, sen har det liksom spritts dar. Eller det har blivit lite olika, jagvet inte om det finns nan notation for det nu, jag vet att man i vissa projekt har byggt inkontroller, men da har man kallat det nat annat istallet for kontroll. Det sprids ju direkt,beroende pa orsakerna. Namen, och det som var intressant med formagorna var just detatt, att fa den har bilden och beskrivning utav varksamheten for att kunna forandra pa ettmer effektivt satt. Det ar det, det har vi ocksa ett intresse utav.

Hur kom du i kontakt med formagor?

Kontakten kom liksom tack vare att jag traffade Charlotte, eller koncernarkitektur. Ochde, da var de i ett ganska tidigt stadie av att anamma formagor, och borja jobba med dem.Sa det tog en ganska lang stund innan jag forstod vad det var som avsags och hur detskulle funka. Och mycket var for att, hur man, att det har med att formagorna inte vartydligt beskrivna. Sen hade Charlotte med sig tva konsulter som liksom, argumenteradefor formagor, och det var ju liksom inte ratt lage. Jag behovde inte hora argument for, jagbehovde forsta vad det var, liksom, och varfor, istallet. Sen pratade de valdigt mycket omkravstallning pa formagorna, och det liksom, nu kanske det blir dumt nar du spelar in omjag ritar har, men det som var det luriga med formagorna i borjan, som de liksom direktforsokte ga in och forklara var att det har ar formagan (cirkel). Det dar vet vi (fyller i20-30%). Sen det har (resten) vet vi inte. Och det liksom, formagan satts ju utifran vad denhar for krav, och vad vi kravstallde pa. Och det var inte helt latt att, liksom, forsta. Attdet var nat som var pa nat satt odefinierat, och att man skulle definiera upp det. Medansen process ar ju pa nat satt mer definierad. Sa, ja. Det var lite, dar i borjan var det rorigt,helt enkelt.

Har du anvant dig av formagor, och hur?

Jattemycket. Vi har ju.. I Folksam sa, pa grund utav hur organisationen ser ut, och enmassa olika orsaker som du far stalla foljdfragor pa i sa fall, sa ar det sa att, som jagvar inne pa, att det finns jattemanga processer, och i en verksamhet sa, om man skulleanvanda processer for att beskriva verksamheten, sa behover man ha ett processansvar ellerett agarskap for processen, ja, processansvar. Och det ar svart eftersom organisationen arvaldigt stuprorslik. Da sag vi fordelen med formagorna, eftersom formagorna ar liksom intekopplade till en, det ar ingen som ager formagan, vilket var valdigt bra. Utan formaganfinns dar den uppstar och dar det finns, vad ska man saga, behov utav den. Sa det var enstor fordel som vi sag, for att det gjorde oss, plus att koncernarkitektur jobbade med det,och om vi hakade pa och borjade prata om det har och jobba med det, sa hjalpte vi dem,och de hjalpte oss a andra sidan. Vi kunde saga att det har finns, det har ett syfte for attvi ska kunna gora den har forandringsresan enklare. Och vi behovde ocksa ha nagontingsom funkade pa en ganska hog niva. Och som var bestandigt over tid. Det var viktigt, foratt vi behover kunna rapportera pa det har, framover. Sa ansvarsdelen, bestandigt over tid,lagom hog niva men anda begripligt. Man liksom forstar, den sager dem vad man gor, vadman har for formaga, sin kapabilitet. Det gar att jamfora ocksa med andra om man skullevilja det eller far tag i det. Sa.. Nu har jag tappat bort fragan..

Vad har du anvand formagorna till?

60

Juste, jaja. Ja, men det var, vi tyckte det var valdigt anvandbart. Sen sa tog koncernarkitek-tur fram en karta som i det skedet blev nagon form utav, man borjade bygga den utifran enprocesskarta som fanns. Det hade gjorts en stor processkartlaggning pa ett affarsomrade,och sen, det har maste du kolla med Charlotte, det har ar min kvalificerade, subjektivauppfattning om hur det ar. Att man utgick ifran det. Man tar nat som man har, sa utgickman ifran det, och sen sa formagefisierade man det nagot. Och sa forsokte man liksombygga upp nanting. Det gjorde att vi landade i en hybrid mellan formaga och processkarta,vilket for mitt andamal var utmarkt. Det passade jattebra. Och det var ocksa, anledningentill att det passade sa bra var att vi tyckte att, ja men nu far vi det har high-fly, pa enovergripande niva, men vi far samtidigt direkt det som jackar in, det vill saga.. Pa en vissniva, som jag forstatt det, i formagorna, sa kommer processer in, man brukar rita det sahar... (se foto) En formaga kan definieras av en formaga, och sen kan processer komma inhar, sa. Och vad skulle jag saga med det da? Jo men hybridkartan var ju redan, da hadevi formagor, och sen var processerna liksom, lag de undertill. Och vi har olika nivaer, ihybridkartan hade vi niva 1, 2, och 3. Och egentligen niva 3 var processer. Och det passadealldeles utmarkt for vara andamal. Daremot sa var det valdigt manga, hybridkartan blevganska stor. Det som har hant nu, som vi har gjort, det ar att vi har delat upp den i en,vi har slagit isar hybridkartan, vi har renodlat den till en mer formagebaserad karta och enmer processorienterad karta. Men vi har inte landat i oversattningen, for det ar det manskulle vilja ha. Att se vart processerna pa niva 3, vart de jackar in i formagorna pa niva 2,blir det val.

Forutom dessa, kan du se nagra andra anvandningsomraden for formagor? For dig, foretaget,projekt?

Ja,alltsa, for att det du raknade upp i stort satt. Jag skulle vilja saga att, vi struktur-erade ju varan riskrapport. Pa riskfunktionen sa skriver vi en rapport tva ganger per ar.Det ar av olika anlendingar sa finns det sana krav stallda pa oss. Men det ar ocksa en deli stodet till ledningen, i att styra verksamheten. Sa vi genererar de har rapporterna, ochrapporterna strukturerade vi utifran formagorna, pa niva 1 da, som fanns. For vi tyckteatt, men det ar ju sa bra att kunna lagga det pa den nivan, for da ser man, det har ar varakapabiliteter, det har ar vara formagor. Vad ar det som det finns nanstans att vi riskerar attinte kunna genomfora det har pa ett bra satt, eller vart brister vi i vara formagor. For darbor man ju ratta till det, om det ar en viktig formaga. Och da skulle man ocksa, nackdelenmed det da, det ar att, eller fordelen beroende pa hur man ser det, man har ju ingen somar superansvarig, a andra sida sa ar alla lite ansvariga for det har. Sa man skulle kunnapeka pa flera, och oftast ar det sa, att det ar inte bara en som kan ratta till nanting, utanman behover samarbeta for att fa det att funka. Det ar oftast det som ar grundorsaken tillatt nat gar snett, det ar att man samarbetar inte inom formagan. Sa det var det ena. Sendet andra ar ju ocksa att se vart behover, vart driver vi forandring, och vart finns det riskerinom det forandringsarbetet. Ja. Jag tror jag stannar dar.

Vilka element skulle du tycka var intressant att koppla ihop med en formaga?

For mig da, om jag far helt.. Risker, kontroller, information, system. Sen kan man jumata det har pa olika satt, det vore ocksa spannande. Men da ar vi inne pa KPI, som arKey Performance Indicator. Kostnader, men det kanske landar inom KPIer. Naturligtvis,den ar ju sjalvklar, processer. Processer, system. Ja, det skulle val vara ocksa manniskor,eller resurser. Resurser som manniskor, eller personer. Men jag vet inte riktigt hur, for dekan ju liksom, nej. Ja, nanting sant dar.

Vilka av dessa fem element tycker du ar relevanta eller inte? Krav, resurs, roll, service,

61

handelse.

Kraven var jag ju inne pa tidigare, resurser ocksa. Service, vad kan det vara? Alltsavilken service formagan, framgar inte det av sjalva formagan? Nej, kanske inte. Det berorpa, naturligtvis, hur man har beskrivit formagan. Men som formagan att hantera betalningeller, vi har ju en, det kan ju vara.. Da ar det ju pa nat satt, servicen ar att vi betalar utpengar, ja.. Okej, jag ska forsoka svara pa din fraga. Krav, resurser, ja, de skulle jag hallamed om.

Roll, service, och handelse?

Roll. Vad menar man med roll?

Att man kopplar ihop det med en position kanske snarare an en specifik person.

Aha. Det har vi varit inne pa ocksa. Men vad skulle det saga? Vad ger det oss i, jovi ser vilka personer som har, om nan slutar. Ja, precis, det skulle kunna vara en.. Roll,krav, resurs.

Roller och resurser blir ju lite lika, men resurser kan ju vara annat an personer.

Ja, men precis, det var ju det som var, det ar den dar definitionen. For jag menar resurserkan ju vara system eller information..

Ja, precis. sa resurser kanske fas med automatiskt om man tar med det andra du skrivit upp.

Ja, det beror pa hur man definierar det. Men service funderar jag pa, hur det kommerin. Ar det som output av formagan, eller input till formagan, eller?

Snarare en output.

Av formagan? Vilken service formagan levererar. Typ sa?

Ja.

Ja. Nej, jag sag nog det som, vanta. Vad ar skillnaden da? Vi har en formaga, vad arkapabilitet och service? Vi har en formaga att kunna levererar nanting, eller gora nanting.Jag tyckte de var, begreppen blir liksom ganska..

Begreppen hanger ihop anda?

Typ. Det beror lite pa. Ja men som formagan att gora rapporter, jag tror vi har ensan formaga, formagan att rapportera. Vad ar servicen, jo det ar en rapport, eller..

Sa det blir svart att sarskilja?

Ja, precis. Det ligger ju pa nat satt i, kan man tanka nat som ar var formaga att gorananting annat, som inte leder till nan service? Alltsa, formaga.. Kan man komma pa nat?Formaga att drifta system? Det ar en service att... Nja, jag tycker de ar narliggande.

Sen har vi handelser ocksa.

Handelse. Det skulle ju vara risk, for sa brukar vi benamna det. Och handelser, da kan det

62

vara en positiv handelse, men det kan ocksa vara, oftast, en negativ handelse som man vill..

Varfor vill du koppla ihop just de har elementen med formagor, och i vilka situationer skulledet vara anvandbart?

Egentligen i.. Okej, om jag borjar med varje attribut da. Ettan, risk. Som jag sa, iforandringsarbete, eller i, framfor allt en kartlaggning utav organisationen. For att se vartnanstans har vi risker. Och for att ha en risk, maste man ha ett mal, det ar liksom det forsta,om man gar in pa riskteori. Har vi inget mal med nanting, ja, men da har vi ju inga risker.Och det kan ju ge sig lite utav formagan. Om vi har en formaga som sager, vi ska leverera,vi ska gora utbetalningar. Da kan man ju tanka sig att malet ar att utbetalningarna skakomma till ratt person, vid ratt tid, och ratt belopp. For annars sa kanns det som att viinte levererar. Da har vi formagan att gora felutbetalningar i sana fall. Men det ligger ikorten pa nat satt, att malet ar att det ska bli ratt, det ar ett kvalitetskrav da, eller ettkvalitetsmal. Men dar kan vi ju se om vi har, dar ar det ju relevant med risk, for da skullevi kunna titta pa, okej, har vi nagra risker kopplade till den har formagan? Ja, till exempelatt vi inte betalar ut i ratt tid, till ratt kund, med ratt belopp. Okej, hur bra ar vi pa atthantera det har, eller finns der nagra kontroller, vilket kommer in till nasta. Och da kanman kartlagga, ja men vi sakerstaller den har formagan, genom de har kontrollerna, och definns har och har i verksamheten. Eller inom den har formagan da, formagan hanteras utav,da kommer vi in pa, i de har processerna, med de har rollerna eller resurserna, med de harsystemen, nu namnger jag de har olika attributen, och med den har informationen. Och detkan ju finnas risker i alla de har olika attributen ocksa, det kan ju vara systemen som ar enorsak till att vi inte klarar av det. Det kan ju vara processen som sadan som haltar, eller attvi inte har ratt roller eller att kraven inte finns tydliggjorda pa vad som faktiskt ska lever-eras. Sa att i sjalva riskdelen sa kommer valdigt manga av de har attributen in. Foljdfragor?

Nej, det kanns ganska heltackande.

Ar det nan som jag missade? KPIer? Det beror ju pa, det ar ju mer om man styr, omdu har ett, om du valjer att koppla ihop.. KPIer ar ocksa kopplade till kanske mal, i alla fallteoretiskt, sa satter man mal for verksamheten som man bryter ner, och gor om till matbaramal. Vi ska ha de nojdaste kunderna. Okej, men vad ar en nojd kund? Hur mater vi det?Hur vet vi att vi nar malet? Ja, da sager vi att nojd kund ar nar 95% av vara kunder i enkundundersokning sager att de ar valdigt nojda pa en skala 1-5, och da vill vi ha 90% over4, och sen ett visst antal 5or. Da har vi en KPI, da mater vi det, och da kan vi saga attvi har en god formaga att, den kanske slar pa flera formagor, men det kanske finns sakersom man kan bryta ner utifran malsattningar kopplade till formagor, som landar nanstans,till exempel. Det skulle kunna vara betalning, det skulle kunna vara svarstid i telefon, detskulle kunna vara antal annullationer eller sa. Det finns en massa KPIer att bryta ner.

De olika elementen, paverkar de formagan eller blir de paverkade?

Stall fragan en gang till.

De har elementen, paverkar de formagan, eller ar det snarare sa att de blir paverkade avformagan?

Formagan ar ju ingenting i sig. Formagan bestar ju av de olika attributen, hur de samverkar.Sa jag skulle vilja saga, formagan paverkar, nu ska vi se har. Jag tanker hogt nu. Om vi tarformagan betalningar, att gora betalningar. Om vi sager att vi ska ha det som en formaga,da far vi ju indirekt ett mal, att vi ska gora det med nan form utav kvalitet, eller enligtnan form utav krav. Har vi inga krav pa betalningar, da har vi inga, da kan vi gora vad vi

63

vill. Har vi inga krav pa formagan, ar det ens en formaga da, om vi inte har nagra krav paden? Da kommer vi in pa den har definitionen, vad ar en formaga? Da maste vi pa nat sattdefiniera upp. Jag skulle vilja saga att det ar de har komponenterna, elementen, som byggerupp formagan. Och vissa har vi ju definierat, stallt krav pa, som vi kanner till. Ja, jag skullenog vilja se det sa har, att det ar snarare tartbiten har ( 20-30% kanda) som paverkar resten(okanda), sa har, som kommer in som en pil och paverkar den har formagan, an att den dar(okanda) paverkar pilen. Det har uppstar ju, enligt min, nu har ju jag inte last nan teori omdet har, men enligt min uppfattning, sa, saker har ute kan ju uppsta i olika interaktionermed de har olika elementen som vi har sagt. Det ar vissa roller som, tillsammans med andraresurser, och en specifik information, som gor att vi kan leverera en delmangd av den harformagan till en specifik intressent, eller nanting sant. Ja, men nu nar jag liksom pratar omdet och forsoker beskriva det sa tror jag nog mer att det ar sa, an att det ar formagan sompaverkar de olika elementen. Jag valjer nog att se det sa. Och det hanger nog ihop medocksa, med den har definitionen. Att vi har processer som jackar in i formagan, det kanju handa grejer i processen som paverkar den har. Formagan i sig satter ju bara ramarnafor vad vi ska gora, pa nagot satt. Den paverkar.. Ja den satter nog mer ramarna. Skullevi ha en formaga som ar, vi ska ha en formaga att gora daliga utbetalningar, vi ska ha enoformaga, ja, en bristande formaga att gora betalningar, da hade det kanske paverkat. Dabehover vi inte ha sa mycket system, vi behover anda inte gora nan utbetalning i ratt tid,alltsa vi kan gora den nar nan kommer hit och skriker liksom. Ja, sa kanske ramarna. Jo,men det blir val bra! Titta, det har (ramarna) paverkar den dar (kanda?) delen utav tartan,pa nat satt. Ja.

Respondent 5

Bakgrund:

Jag har val titeln Risk Manager, och jobbar inom Risk- och Compliance-avdelningen paFolksam Sak. Jag har jobbat pa Folksam i ganska precis tva ar.

Kortfattat: vad vet du om formagor?

Ja, innan jag borjade har sa hade jag ju aldrig, inte medvetet i alla fall, kommit i kon-takt med begreppet formagor, utan mer med processer. Och att, intresset har var ju for attdet finns ju ingen overenskommen processkarta pa Folksam, och nar vi da pa Risk skriverriskrapporter sa behovde vi hitta nat slags struktur. Man kan strukturera risker pa mangaolika satt. Och man kan ju, till exempel, jobba pa tvarsen och klumpa ihop dem over helaverksamheten, men da blir det ju inte sa intressant att veta var riskerna finns. Utan dabehovde vi hitta nanting som gjorde att man kunde, liksom, mappa ihop olika risker i verk-samheten mot overgripande risker. Och da fanns den har formagekartan som vi, jag vet intehur vi stotte pa den egentligen. Jo, vi var intresserade av att rita processer, sa darfor tog vikontakt med Koncernarkitektur, och larde oss EA, jag och min kollega Marcus som du harintervjuat da. Och sen kom vi val pa att, jo men vi kanske skulle, bara sa dar, happ, liksom,att vi kanske kan strukturera riskrapporten utifran formagorna. Och da gjorde vi det! For,vad kan det vara, forra hosten maste det vara, nastan. Sa vi har skrivit tva rapporter enligtden strukturen, vi skriver tva ganger om aret. Precis, vi skriver en ny nu i host ja. Och,ja, men sen visade det sig ju da att den har formagekartan som man hade tagit fram paFolksam, den var ju inte helt korrekt, utan den var ju lite en mix da mellan processer ochformagor. Men jag ser ju forfarande att formagorna ar intressanta ur ett riskperspektiv,darfor att man kan ju skara risker pa olika satt. Jag vet inte hur val du vet hur man jobbarmed risk, men det blir ju som en matris, alltsa formagorna kontra processerna. Om vi tillexempel sager att vi har stora risker i en utbetalningsprocess inom en specifik del av verk-samheten. Da ar det ju mest intressant for verksamheten att veta att det finns stora riskeri den har hanteringen, alltsa i den har processen. Att administrera pensioner, till exempel.

64

De ar ju inte sa intresserade av att veta att det ar formagan Utbetala som har brister,eftersom processerna oftare foljer det organisatoriska ansvaret sa ar det lattare att anvandaprocesserna i relationen med ledningen. Men samtidigt da om man tittar pa risker pa enannan ledd, om man tanker da IT-utveckling, pa samma satt som Koncernarkitektur jobbar,sa ar det ju intressant att kunna lagga ihop och titta just ”Oj, men vi har jattemycket riskerjust kopplade till utbetalningar”. Och det ar ju viktigt for dar hanterar man ju, allta, gardet fel i utbetalningarna sa ar det ju varre an om det kanske gar fel i den har processen. Sabada dimensionerna ar intressanta for oss. Men vi som jobbar pa Risk kommer nog alltidatt vara mer intresserade av processer, egentligen. Sa ar det.

Hur lange har ni jobbat med formagor?

Ja, det var ju da sen, ja men nastan sen jag borjade sa borjade vi nog nosa lite pa det.Men att vi borjade ju att beskriva riskerna, fast da blir det ju lite fel att saga att vi gjordedet enligt formagor, for egentligen har vi ju gjort det enligt processer, eftersom kartan armixad. Ja, hybridkartan, sa.

Men ungefar tva ar?

Eller, ja, ett och ett halvt da kanske.

Hur kom du i kontakt med konceptet formagor? Det har vi ju redan diskuterat lite.

Via Koncernarkitektur, ja. Vi ville rita processer, och sa fick vi reda pa att de fanns.For har hade man ju diskuterat hur Folksams processkarta sag ut framat och bakat ochaldrig kom till nanting, och har fanns det ju liksom en fardig karta som man bara kundesaga att ”Ja, men nu anvander vi den har!”. Sa det var ju bra.

Har du anvant dig av formagor vid nagot annat tillfalle an riskrapporterna?

Nej, vi har inte anvant det pa nat annat satt. Jag vet inte, om det har hade varit heltratt fran borjan, sa vet jag inte hur vi hade anvant det da, men nu var det ju inte riktigtratt uppstallt. Men det ar nyttigt att skara verksamheten pa olika ledder, sa pa sa satttillfor det nat.

Kan du se nagra andra anvandningsomraden for formagorna?

Ja, men i forandringsarbete ser jag det framfor allt. Och samtidigt maste man ju kunnabeskriva verksamheten bade i ett nulage och i ett.. ett nulage, ett mallage, och ett forandringslageutifran nan viss typ av struktur. Och dar fyller det ju ett syfte. Pa samma satt som mankan beskriva processerna, men det har ju lite olika syften. Sa jag ser nog att, om man tankerur ett organisatoriskt perspektiv, alltsa som chef, sa tror jag att man lattare forstar pro-cesser. Men nar man tittar pa verksamheten som en helhet, sa kan det ju vara mer effektivtatt anvanda formagorna, tror jag. Och sarskilt nar det galler IT-utveckling eller forandringover huvud taget. For det blir ju lattare suboptimering om man bara tittar i processerna, sa.

Finns det nagra sarskilda element eller sarskild information du skulle vilja kunna kopplaihop med formagor? Till exempel just processer?

Ja, for oss sa kanns det relevant.

Finns det nagot annat an processer?

65

Jag har nog inte tankt sa langt. Det har varit tillrackligt besvarligt att koppla ihop detmed processerna. Ja, men IT-stod givetvis, alltsa, ja. Om man tanker personalforlyttning,alltsa allting som har att gora med att man forandrar nanting som ar en typ av gemensammassa, sa kan man ju applicera.. Ja, men du ska forflytta din personal, da kan det ju varaintressant att tanka ur ett formageperspektiv ocksa.

Har ar fem element, fran min litteraturstudie, som du far ta stallning till om de ar rel-evanta eller inte. Krav, resurser, roller, service, handelse.

Om man kan koppla det till formagor?

Ja, om du tycker att nagot spontant kanns relevent eller inte.

Krav kanns val viktigt. Alltsa om man ska kravstalla, nu ar vi inne pa forandring igen.Och resurser ar ju lite samma sak. Du anvander ju olika typer av resurser i olika formagor.Man kan ju effektivisera genom att tanka formaga, tror jag. Det ska man ju inte saga till desom ar processnordar, att man kan effektivisera genom att skara det pa andra ledden, detberor lite pa hur man vill effektivisera. Kund-effektivitet uppnar man val kanske inte medformagor, men man kan internt effektivisera. Vad sa du mer?

Roller, service, handelse?

Roller? Krav och personal, eller resurser, kandes ju mest ratt. Klart man kan koppla roller,alltsa, man kan koppla allt till en formaga. Men roller, handelser, och vad sa du nu den sista?

Service.

Service. Ja, men servicen kanns ju lite mer som det har med krav och sa, alltsa om man nuvill tanka utifran ett kundperspektiv, kanske att service hander med. Men de andra tva arval, tror jag hellre jag skulle koppla till en.. Nej, ja.. Men det ar klart, om man tittar paUtbetalning, ja men da har du ju olika roller. Och da kanske det ar viktigt, da kan man juliksom koppla, inom Utbetalning har man de har rollerna och de bor liksom vara likadanti alla, i all Utbetalning. Och tittar man pa processen sa kanske man tanker roller pa ettannat satt. Det var ingenting som jag kande sa har ”Nej, det gar inte”.

De olika elementen, i vilka situationer skulle det vara anvandbart, och varfor just dessaattribut? Men det har vi nog redan tagit.

Ja, precis, det tror jag nog.

Kommer elementen att paverka formagan, eller tvartom?

Formagan ar val en beskrivning, sa den borde val inte.. Ja, men krav borde ju paverkaformagan. Ja, det var nog lite for abstrakt for mig kanner jag. Det beror nog pa hur man..Ar inte en formaga en beskrivning av nanting? Och da menar du att da skulle beskrivningenpaverka? Ja, det kanske den kan, jag vet inte.

Sa det kanns naturligare att resten paverkar formagan, som krav till exempel?

Ja, det gor det nog.

66

Respondent 6

Bakgrund:

Pa Folksam har jag jobbat i, det bli 14 ar nu. Time flies when you have fun. Och job-bat med just affarsarkitektur har jag gjort sedan 2010. Och det blir val senaste 2 och etthalvt aren har jag suttit pa affarssidan, innan dess satt jag pa ITstabs-niva, med Charlotteoch ganget.

Sa Affarsarkitekt?

Ja. Eller, min titel pa Affaren ar Affarsutvecklare, men jag ar certifierad affarsarkitekt.

Kortfattat: vad vet du om formagor?

Ja, det ar ju sa man ringar in vad ett foretag gor, vad man har for goromal, for att levereradet man ska. Vi har ju jobbat mycket med processer just inom Partneraffaren som jag sitterpa da. Vi borjade dar, till att sen utveckla det till ett formagetank, under ett program vikorde, under resans gang. Och kom en bit med det, for att processer sager inte allt, utanman fangar mer saker som paverkar utifran ett formageperspektiv. Men processerna finnsju dar i forstas.

Hur lange har du jobbat med formagor?

Ja, det var, jag och Charlotte satt ju och jobbade med det har. Det var 2012-2013, satt vioch borjade.

Hur kom ni i kontakt med konceptet formagor?

Det var Charlotte som introducerade det tanket lite mer. Jag hade val hort det, lite sadar, men inte tagit reda pa riktigt mer om det sa. Just da var val det i ropet lite det harmed industrimodeller, som i och for sig ar en typ av formagor, och IBMs industrimodell somsen visade sig inte funka i verkligheten. Det var lite roligt, jag traffade en enterprisearkitekthos en av vara konkurrenter, som var eld och lagor over IBMs modell. Och sen sa stottejag pa honom vid nat seminarie om det var tva ar senare och fragade honom lite ”Ja, menhur gick det?” och han sa att ”Nej, den har vi lagt ner, det gick inte”, det funkade inte iverkligheten, sa. Det var lite spannande att hora.

Har du anvant dig av formagor, och pa vilket satt?

Ja, vi anvander det nar vi ska gora stora satsningar. Framst stora satsningar, man kangora det aven pa mindre men det ar mest anvandbart nar man ska gora stora satsningar,for att ringa in vad ar det som paverkas av det har initiativet ni nu ska genomfora. Vi villta oss fran plats A till plats B, hur paverkar det vad vi gor idag? Sa det ar ju ett valdigtbra satt att ringa in vad som paverkas. Vi har en stor och komplex verksamhet. Gammal,over 100 ar. Sa att, manga saker gor vi, och vi forsoker att fa en karta over, men vad ar detvi egentligen gor i var komplexa verksamhet. Pa basta satt ringa in, man hittar ju aldrigallt, sa ar det ju, men man har storre chans att hitta ratt om man atminstone har ringat inpa formageniva vad det ar som berors.

Forutom detta, kan du se nagra andra anvandningsomraden for formagor?

Ja, for dels ar det ju att ringa in vad ar det som berors. Sen behover man ju ocksa goraen bedomning ”Hur svart ar det har?”, vad ar det for komplexitet inbyggd i det har. For

67

sen anvander man ju det for att gora en roadmap over vilka steg bor vi ta, hur svart ar deolika stegen. Och sen kan ju det ocksa vara en grund till prioritering, jamfort da med vilkaeffekter man tror att man uppnar. Ar det nanting som ar extremt svart att gora, men sombara bidrar till en pyttedel av effekten, ja men da far man kanske tanka om. Sa det ar juen bra utgangspunkt for prioritering i vart man ska lagga sitt krut i forandringen.

Vilka element skulle du vilja kunna koppla ihop med en formaga?

Eftersom jag ar affarsarkitekt sa tittar jag ju pa hela affarsarkitekturen. Det vill sagada, vi har ju liksom en overgripande strategi och inriktning. Affarsmodeller, som du da villforandra ocksa. Och sen utifran det da sa ser man ju da pa processer och formagor, formagaar val da liksom en inringning av manga saker, men dels processer. Hur paverkar det vadvi gor i en verksamhet? Och sen sa spiller ju det ocksa over pa hur styr du arbetet somutfors, vilka kompetenser behovs, vilket typ av IT-stod behovs? Och da kommer du ner painformation och tekninska plattformar och allt sant.

Fem element fran litteraturen, kanns de relevanta eller inte? Krav, resurs, roll service,handelse.

Ja, det beror pa vilken fas man ar i, i forandrningen. Vi skar det nog inte riktigt paden ledden, i det tank vi har, ar liksom min spontana kansla. Men nu har ju jag inte liksompluggat in hur vi har skivat upp vara formagor just nu. Jag var bara med i borjan, da hadevi behov av att ringa in ”Vad ar det som berors?”. Och da tittade vi pa vad ar det for typav information, och kopplat till vilka processer gors det har med halp av. Och vilken typ avroller. Jag kommer inte ihag om vi kom sa langt att vi kopplade pa organisation eller inte.Sa att, liksom, ja, det gar val att oversatta, kan jag tanka.

Men det ar ingen av dem som spontant kanns relevant?

Ja men det gor de nog, fast vi har kallat det for annat, om man sager sa.

Ar det nagra da som verkade relevantare an andra, eller tvartom?

Jag tror nog att vi ser det, det dar ar valdigt, om vi nu uttrycker oss i IT-sprak, sa ardet dar IT-sprak. Vi uttrycker kanske motsvarande fast pa ett annat sprak, om vi sasager. For det dar blir lite, om man tanker sig att man ska ha en dialog med en affarssida,eller en verksamhetssida, da stanger man av ”Aja, men det dar ar sant dar tekninskt somhor till IT”, det ar en ratt viktig aspekt, om man ska fa det har att funka hela vagen.Eller om man vill ha det IT-internt, eller arkitektur-internt, alltsa, ursakta uttrycket, menpa ”nordarkitekturniva”, sa funkar det dar bra. Men behover man ha en dialog med enaffarssida och affarschefer och alla mojliga typer av roller sa kanske man ska fundera pa,men, de dar begreppen stammer, om man tanker sig rent generelt, men man kan nog fasvart att fa med sig alla roller i en verksamhet, genom att anvanda just de begreppen. Detar min personliga erfarenhet. Men alla ar ju relevanta, forstas.

De har elementen, i vilka situationer skulle det vara anvandbart att koppla ihop dem medformagan, och varfor just de elementen?

Det ar egentligen om man tittar pa affarsutvecklingsprocessen. Nar man har ideer, ellerman ser att man behover gora en forflyttning. Det ar det har, om du tanker dig en pro-jektmetodik, for att komma fram till en BP1a, faktiskt, och ringa in vad ar det vi vill, ochvarfor, och vad innebar det har da. Innan man kor liksom, go, nu kor vi ett eller flera pro-jekt. Sa det ar ju egentligen affarsarkitekturprocessen dar man da gar igenom de har stegen

68

och fyller pa med den har informationen, pa en lagom overgripande niva forstas. Annarskommer man ju in i verksamhetsanalysen och det ar ju inte meningen. Utan liksom, for attha ringat in, men ”Det ar det har vi ska gora framover, for att..”, och garna kopplat da tillrelevanta afffarshandelser som man da kan checka av mot. Det ar affarshandelser som styr.

Elementen, paverkar de formagan, eller tvartom?

Jamen, formagan beskriver ju den verklighet man lever i. I och for sig, dar kan man sakertocksa gora as-is och to-be. Men om du har koll pa as-is, sa kan du ju nar du vill gora enforflyttning fran punkt A till punkt B, sa tittar du ner, i sin lada av formagor, ja, men ”Sahar ser den ut”. Da kan det ju vara mer eller mindre svart. Det ar ju det man far fram da.Och sen sa ar det ju sa, antingen ar det sa att den har formagan, ja, den kan vara sa att,otur, det ar jattesvart att andra pa den av nan anledning, nu vet ju inte jag vad det kanvara, men, det kan ju finnas sant. Eller att den, det ar sa manga andra saker som stralarner i samma formaga sa man kan inte andra pa den ur ett perspektiv, for da liksom rasslardet till och forstor i massa andra horn, nan annan stans, som gor att man inte kan forandrafor mycket. Ja, da blir ju det en aspekt att ta hansyn till. Eller sa ar det sa att man tittarner da och ser att den har formagan ar for dalig, vi maste forandra den. For det gagnar intebara den har initiativet eller den har affarshandelsen, som vi ar ute pa marknaden med, dakan man ju forandra formagan i sig. Sa det beror ju alldeles pa. Sa det finns inget rakt svarpa den, nej.

Nagot annat du kanner ar relevant att lyfta fram?

Nej men det ar just det har att i affarsutvecklingsprocessen, infor att man behover sattaigang ett initiativ, ett eller flera projekt som det kan vara da, sa anvander vi oss av det foratt gora komplexitetsbedomningar och omfattningsanalyser och sa. Som ar liksom, for attkunna ta fram en roadmap, som projektet ska kunna basera sitt arbete pa.

Respondent 7

Bakgrund:

Jag ar verksamhetsarkitekt. Jag borjade pa Folksam september 2013, tror jag. Jag harjobbat har ett och ett halvt ar, kanske det blir. Sa att, och innan dess hade jag sammaposition i typ 6 ar ocksa, sa att jag har jobbat ganska lange som verksamhetsarkitekt.

Kortfattat: vad vet du om formagor?

Ja, vad ska jag saga. Det ar ett omdebatterat amne inom arkitektur. Jag har jobbatmycket med olika typer av formagor, aven innan jag jobbade som verksamhetsarkitekt harjag jobbat med krav och kartlaggningar av olika slag, jag har jobbat med upphandlingar ochanvant mig av formagor ganska manga ganger. Sa det ar egentligen samla in kravstallning,identifiera olika hanteringar i ett foretag. Jag vet inte riktigt hur mycket, jag kan berattaen hel dag om de dar olika kapabiliteter hit och dit, finns olika former.

Hur lange har du jobbat med formagor?

Oj. Ja, maste tanka, det var kanske 2000, nar jag blev konsult, som det dok upp. Jaghar jobbat ganska mycket med upphandlingar och da ar det valdigt praktiskt att jobbamed formagor. For da, innan man vet hur man vill jobba, och kanske kravstaller pa vadman behover, tjanster och funktionalitet, av externa foretag och service providers. Jag trorfaktiskt att det ar sa lange, det later valdigt..

69

2000?

Ja, da blev jag konsult, sa det var val da man borjade tanka pa sana saker.

Hur kom du i kontakt med konceptet formagor?

Det ar inom, alltsa, inom kartlaggningar. Ofta sa borjar man med nulaget, hur ser detut idag, och vad ar det vi hanterar idag. Vad behover vi hantera i morgon for att stottaaffaren. Vi har val, som anstalld inom arkitektur som jag har varit da i sju ar, ja, det ar sjuoch ett halvt, atta ar, da blir det ju mer att man forvaltar formagor och kartlaggningar, ochforsoker fa till nagon slags ateranvandbarhet i det hela. Sa det blir lite mer struktureradform som linjeanstalld.

Har du anvant dig av formagor, och hur?

Jag har ju redan namnt nagra stycken. Ja det ar ju massor av satt, i manga olika sam-manhang. Men framfor allt kartlaggningar av verksamheter, kartlaggningar av overgripandeaffarsarkitektur. Kartlaggningar av organisationer, man kan titta pa, till exempel, dels hurorganisationsstrukturen ser ut, vad man hanterar inom dem, eller hur ska vi organisera ossfor att vara effektiva. Hur ska vi jobba och hur ser vara processer ut for att vara effektiva.Och sen kapsla in nan slags overgripande, strategisk, alltsa man kartlagger strategiskt ”Hurpaverkar en ny strategi vart foretag?”, och sa istallet for att ga for djupt ner i processer ochsystem, ha nan slags overgripande inringning.

Forutom detta, ser du nagra andra anvandningsomraden?

Alltsa pa Folksam tycker jag att man anvander formagor ganska brett. Bade strategiskt,och sen verksamhetsanalysmassigt, och sa aven kravstallningsmassigt. Jag tycker att mankan dra nytta av det i en agil metod battre. Jag jobbade agilt i sex ar och forsokte fa tilldet lite grann, for dar moter ju arkitektur agila, de har anvandarcentrerade metoderna. Ochdet ar ju, det kan vara lite spannande att se hur det fungerar ihop.

Finns det nagra element du vill kunna koppla ihop med en formaga?

Ja, det finns egentligen.. Processer tycker jag ar jatterelevant att koppla in, och det harjag ocksa gjort i verktyg sjalv. Sa vi har sett att det fungerar verkligen. Affarsobjekt,jattecentralt. Vad kommer in i en formaga, och saker hander inom formagan med pro-cesser, organisation, och kompetenser, och sen kommer nanting av varde ut i formagan, detaffarsobjektstanket gillar jag. Sen tycker jag ocksa att det ar intressant att koppla ihopmed, vilket man inte alltid gor, den logiska arkitekturen, losningsarkitekturen. Den, alltsaga ner mer mot applikation och lyfta applikationsparken pa ett logiskt losningstank. Ochsystem, att inte forglomma. Alltsa vilka system, x, y, oxh z, alla systemen. Och sen ocksaorganisation. Vilka kompetenser och roller har vi i en formaga, och var sitter de placeradei var organisation.

Fem element fran litteraturstudie, relevanta eller inte? Krav, resurs, roll, service, handelse.

Handelse? Hur tanker du da, ett event?

Ja, precis.

Ja. Men jag tror nog att alla ar relevanta. Jag har inte kopplat ihop det med service,vilken service tanker man har? Det finns manga olika dar ocksa.

70

Vilken service bidrar formagan till?

Okej, det som ligger inom formagan, vad ar det for service som man kan forvanta sig..Om vi sager att vi koper det externt, outsource’ar. For tjanster, pa Folksam har finns juinte tjanster i arkitekturen i den utstrackning som det finns pa andra bolag. dar jag var tidi-gare i sex ar, dar byggde vi ju upp tjanstearkitekturen, och det tycker jag, ja, det var ganskabra, for da behovde man inte alltid fa in det har med process, det kan ju ligga utanfor, omman tanker mer tjanst.

Sa alla kanns relevanta?

Ja, men jag tycker tjansterna ar inte sa, det ar ocksa lite infekterat over aren. Men detar inte sa mycket sant tank har.

Varfor kanns dessa element relevanta och i vilka situationer skulle det vara anvandbart attkoppla dem till formagor?

Alla?

Eller ta en i taget, om du vill.

Av de du namnde?

Ja, eller av de du tankte pa ocksa.

Okej. Nej, men det ar ju verkligen olika sammanhang. Det vi anvander mest har, dehar affarsobjekten, det ar ju for att sakerstalla sjalva formagans hallbarhet, och att det arratt abstraktion pa den. Sa det ar ju, nar man ringar in formagor och sager att vi ska haformaga x, y, och z, hur vet vi det? Hur vet vi att det ar ratt x, y, och z, och inte t, tillexempel. Sa att, for att kla en formaga med affarsobjekt och sen organisation, alltsa hittacentrala delar som man vill kla sin formaga med, sa man vet vad man pratar om, for annarsar det bara rubriker. Och da nar man sallan fram till manniskor med formagor, da tycker deatt det ar for abstrakt, de kan inte relatera till formagan. Sa jag tror att, for att fa folk attrelatera till formagor sa ar det valdigt viktigt med just affarsobjekt. Sen ocksa organisation,tycker jag ar viktigt. Men jag vet inte, det ar sa manga olika sammanhang dar man kan..Strategiskt satt sa tror jag att kanaler ar ocksa ganska intressant, distributionskanaler. Ardet digitalt, eller ar det via kundtjanst, eller vilken, den har vi inte namnt men den tyckerjag ar, ocksa, bra. Racker det som svar?

Jajaja, absolut. Jag ska skapa en metamodell utifran intervjuerna och det ni tycker ar in-tressant att koppla till formagor, som ni sen kommer fa ta stallning till, och forhoppningsviskunna inkorporera den i EA Sparx ocksa.

Jaja, men da tror jag nog process ar ganska viktigt, pa en valdigt hog niva, typ niva 2eller nanting sant. Det skulle vara bra att fa en koppling till. Organisation ar ju mera,alltsa, foranderligt, eller vad man ska saga, men det kan ocksa vara relevant att titta pavilken enhet eller affarsomrade som florerar i vilken.

Paverkar elementen formagan, eller tvart om?

Att de paverkar formagan.. Formagan, om man sager, byggs ju upp av alla elementen.Det ar sa jag bektraktar formagan, att det ar en container for allt det andra, for att man

71

ska slippa prata om det andra for att det blir sa detaljerat. Jag kanner sa, att den, mankan ju ha en formaga och inte anvanda den alls, men fragan ar ju da hur lange man harden formagan, i verkligheten. Alltsa, det finns ju en verklighet och sa finns det en teoribakom formagekartlaggningar, och ibland blir det ju liksom mer en teoretisk diskussion, vadsom paverkar det ena och det andra. Men for att sakerstalla en battre bild, av att man haridentifierat sin formaga, liksom, i balans med de andra arkitekturnivaerna, da maste mannog kla in den lite for att se, den har omfattningen, den ar relevant att ringa in en formagapa. Sa drar man bort nanting och jackar in den andra, ja, da paverkas ju inringningen avformagorna, men den ar ju bara en abstraktion av den andra. Sa egentligen ar inte formagannanting utan allt det andra. Ar du med vad jag menar?

Jada, inga problem. Nagot mer du vill fa fram?

Jag tror sa har, man kan ha en teoretisk bild, och det ar jattebra att beskriva det, forda kan alla fa samma grund. Men sen sa nar man ar i samtal med manniskor sa gallerdet att anda fa grepp om behovet och grunden for samtalet, och huruvida man betraktarformagan pa samma satt. Om den samtalspartner man har i ett mote inte har samma grund,da maste man anpassa sig i sin arkitektroll. Jag tror det ar A och O att man ar flexibel.

Respondent 8

Bakgrund:

Du, jag har varit, om vi borjar med Folksam, lange. Jag har varit har i 14 ar. 15 arsnart. Jag jobbar som Affarsarkitekt, inom ett omrade som heter AO Privat. Det ar ettutav de tre affarsomradena som finns, jag vet inte hur val du ar bekant med organisationen?

Jo, men det har jag sett.

Bra. Sa dar sitter jag. Mitt ansvar galler bade AO Privat, och det handlar framfor alltom distribution och vart erbjudande, eget varumarke, och det handlar aven om ansvar forforsaljningsdistributionskanalerna. Det ligger ocksa under dar. Sa att, sa, da har vi ramatin det. Jag har haft affarsarkitektrollen sen i somras, sa snart ett ar. Jag har jobbat medaffarsutveckling tidigare, det ar bara det att vi har gjort en liten omorganisation, fragornaar de samma, den ar en lite annan roll bara.

Kortfattat: vad vet du om formagor?

Ja, ja vad vet jag om dem? Hyfsat mycket. Sen finns det val alltid mer att lara sig,absolut. Jag har varit med sen vi borjade arbeta med formagor i Folksam. Och det vigjorde de forsta trevande forsoken, eller trevande, vi tog dem i ett praktiskt fall och anvandedem, vad har vi kort det i, en fyra-fem ar, ungefar. Sa dar satt jag och Charlotte Frank,som du sakert kanner sedan tidigare, tillsammans med en kille som heter Roland Karlstrom.Och da anvande vi formagorna nar vi jobbade med strategiarbete inom foretagsaffar. Sa detar sen dess. Sen, jag har ju.. Det ar ju formagor som vi behover besitta, eller besitter. Ellersom vi besitter, det ar inte alltid man behover dem, men formagor vi besitter. Och speglarval pa nat satt vilka kompetenser vi behover. Stod i arbetet, det ar allt ifran IT-system tillandra kompetenser ocksa i form av stod. Processer, ocksa. Nej men det har varit ett bra sattatt askadliggora vad vi faktiskt gor, och det ar ett bra satt att ocksa scopa in fragestallningar.

Hur lange har ni jobbat med formagor?

Jag tror vi har jobbat i drygt 4 ar. Tror jag. Vi gjorde ett jobb, och det gjorde vi runtarsskiftet, det maste ha varit fyra ar sen. Den kan vara tre, men jag tror det ar fyra.

72

Hur kom du i kontakt med formagor?

Det var faktiskt Charlotte som introducerade det. Vi hade gjort, vi gjorde faktiskt ettvisst forsok, till och med ett ar innan dess. Det stammer, det var nastan fem ar sen. Ochjag tror att vi fick lite input ifran Sandvik, om inte jag missminner mig helt fel. Annars,den som driver sjalva arbetet, sa som jag ser det, det ar ju Charlotte, absolut.

Har du anvant dig av formagor, och hur?

Absolut. Vi kan val ta ett praktexempel. Projekt, dar vi talar om vilka formagor somar inom scope for projektet. Man kan ocksa tydligt tala om vilka som ar utanfor. Detar ett satt. Ett annat satt som vi anvander idag, det ar, givet, om vi tittar pa de olikaaffarernas olika intressen, att dra at ett eller ett annat hall, at det vi vill, sa kan vi tala om,pa formageniva, vilken typ av forflyttning som behovs for att stotta det. Till exempel enstrategi eller en affarsplan. Sa att, det ar ett bra satt att pa nat satt forsta, vilken formagahar vi idag, givet vad vi sager, och vad behover vi forandra. Sa ar det, det ar en bra ytaatt dela pa, och folk verkar gilla det, det ar sa. Annars brukar det vara valdigt svart att faolika roller att prata med varandra. Sa det har varit en bra spelplan. Och, som sagt, baraman har en spelplan sa har vi, liksom, en gemensam syn, och bara det ar bra.

Kan du se nagra andra anvandningsomraden for formagor?

Absolut. Aterigen, precis som ett projekt kan scopa in vad vi ska och inte ska gora sakan man ocksa tydligt tala om vad en organisation gor. Vi har anvant den, och det arval inte bara vad jag kan se, men vi har ocksa anvant den nar vi pratar om ansvar mel-lan organisationer, vem har egentligen ett ansvar. Da kan man borja pa formageniva ochmappa in vilka organisatoriska delar som har ett ansvar. Och dar kanske fler traffar pasamma formaga, da borjar man ju undra ”Har vi ett samlat ansvar? Eller ar det sa attden dar formagan bestar av egentligen tva delar?” Sa att, det har varit en bra yta att avendiskutera ansvar, befogenheter, mandat. Det kan val anvandas till allting. Jag vet att mananvander det idag for att mappa ut risker, till exempel. Aterigen, har vi valt en spelplan attbeskriva, pa en overgripande niva, den verksamhet vi bedriver, sa kan den ju, utifran den harverksamhetens alla behov, ganska tydligt anvandas till allt ifran liksom, resursplaneringar,kompetensplanering, du kan gora i stort satt vad som helst.

Vilka element vill du koppla ihop med formagorna for att det ska funka som bast for dessaanvandningsomraden?

Jag tyckte det var bra nar vi pa nat satt ocksa mappade, mot formagor, vilken organ-isatorisk del har ett ansvar. Den blir valdigt organisatoriskt bunden, sa det finns ju enganska stor fara med det, i och for sig da. Men man kan i varje fall pa en overgripandeniva prata om produkt till exempel, vi kommer ha en produktorganisation pa ett eller annatsatt. Det har den varit bra for, som ett exempel. Andra bitar, ja. Det jag skulle vilja se iden annars, det ar just ”Vilka ar det som jobbar har?”, altsa, vi pratar roller. Vad besitterde har rollerna, eller behover de besitta, for typ av kompetenser. Det ar kanske att ta detlite for langt just nu da, men att forsta rollerna, forsta processen eller processerna som bor iden formagan. Och det ar val ungefar det vi jobbar med just nu. Sen kommer det ju ta etttag innan det ar klart. Sen kan man onska valdigt mycket, men man behover fa ett greppom det som behovs idag da. For att aterigen, en formaga givet behovet av forflyttning, saar det anda nar du kommer ner pa processniva som saker hander.

Fem element fran litteraturen, kanns de relevanta eller inte? Krav, resurs, roll, service,

73

handelse.

Ja, vi tar dem uppifran och ner da!

Okej, krav?

Krav, vi har arbetat med krav. Beroende pa hur man nu, vad du menar nar du sagerkrav, men om det ar nagons krav inom ramen for den har formagan, sa har vi jobbat pa detsattet att definiera krav. Med hjalp av formagor tala om hur stor, hur manga krav har viinom en formaga. Och det handlar ocksa att om man nu gor en utveckling, sa kan det varasvart att gora nagonting som ar valdigt spretigt, det tar fokus ifran fragestallningar, ochdet blir valdigt omfattande. Darfor ar det oftast viktigt att man isolerar en aktivitet ellerhandelse till ett givet omrade. Och da ar det bra att anvanda formagor som ett satt attprioritera krav. Sa att, ”Vi tar den har formagan forst, och gor den bra. Sen borjar vi mednummer tva och nummer tre.” Och det har vi ocksa anvant praktiskt. Sen har vi val hittatlite andra skarningar, for formagor ar inte losningen pa all huvudvark, men det var en bra,det var ett bra, en bra forsta grej. Och prioriterar man till exempel bort da en formaga, daforsvinner ju alla krav darunder, och da kan man liksom slappa den diskussionen. Det varkrav. Och sen hade du?

Resurs.

Resurser. Ja, allt ifran IT-stod till, det kan vara fysiska resurser, och andra saker, ja,absolut. Absolut.

Roller.

Ja det ar ju en sorts resurs. Eller, ja det beror ju pa hur man ser det.

Service, tjanst?

Ar det vilka typer av tjanster som behovs.. Vilka stottande tjanster som behovs for attden formagan ska uppfylla..?

Ja, ungefar.

Da blir den valdigt teknisk. Ja, nej men absolut. Aterigen, losningen pa den har formaganar ju inte bara vilka som jobbar och hur ser processerna ut, utan hur ser faktiskt stodet ut.Om de har stoden i sin tur behover, liksom, olika tjanster ifran A till O, sa, sa ar det valbra att man har koll pa dem ocksa. Men, ja, jag flummar ut lite i svaret dar for jag vet inteexakt vad som avses med service, dar, sa att.

Handelse.

Aktivitet da, process, aktiviteter, handelser. Som skulle bo i en formaga da?

Ja, eller pa nagot satt paverka formagan.

Ja, jo, men sa ar det val, det ar val alltid en handelse som pa ett eller annat satt trig-gar den har formagan att, liksom, aktiveras. Och den kan val komma fran olika stallenoch i sin tur sa lamnar den ju faktiskt over nanting. Vi ar inne lite i processperspektivetpa formagan da, men absolut. Men det ar ju handelser, de ar ju hogst relevanta, och deblir ju valdigt relevanta ocksa nar man borjar prata om forflyttningar av, speciellt storre

74

organisationer. Aterigen, du kan inte gora allt pa en och samma gang. Och da maste manforsta frekvenser av handelser. Men ocksa nar handelserna kan tankas intraffa. For da kanman ocksa effektivt styra utveckling. Om nanting inte hander forran om tio ar da kanskedet inte ar vart att vi gor det idag, da kan vi vanta nio ar till, sa, till exempel.

Varfor kanns dessa element kanns relevanta att koppla till formaga, och skulle det varaanvandbart i nagra specifika situationer?

Nej men det var val, de som du namnde och sen namnde jag nagra innan dess, det varval ungefar same same. Ja, alltsa, givet da att om det ar verksamhetens spelplan, och darvi har formagor som slar bade over affar, och verksamhet, och IT. Vi delar, i min varld,pa samma formagekarta, de finns inte i olika lager eller pa andra satt. Da kan vi anvandaden till precis vad som helst. Planera outsourcing, till exempel. Du kan, aterigen, hur duhanterar kompetenser i de har, ju mer stod vi far i vart vardagliga arbete, desto mindre,minskar ocksa kompetensbehovet pa ett stalle men det kanske okar pa nagot annat da. Dethandlar om resurs- och kompetensplanering, absolut. Du kan koppla mal till formagor.Givet hur den har formagan pa nagot satt uttrycks, hur den mar idag, hur bra bor den ma?Sen, vi anvander ocksa, jag kanske namnde det tidigare, vi anvander det till strategiskakrav, kart barn har manga namn, strategiska affarskrav, affarskrav, taktiska affarskrav, detfinns mana olika begrepp. Men strategiska krav, pa ett eller annat satt, som har sin kallai nat strategidokument, oftast, kan ocksa, da, mappas mot formagor, vilka strategiska kravbor i den har formagan. Fast de ligger lite ovanfor, ser jag anda, sa de bor inte riktigt dar,men de paverkar.

Elementen, paverkar de formagan, eller tvart om?

Oj, det dar var ingen latt fraga. Jag tror inte att det finns nan, det ar inte svart pa vitt. Jagkan ge tva exempel. Pa ett stalle dar vi till exempel paverkas av, dar formagan paverkasav det som bor darinne, och tar vi mycket av den forflyttning vi till exempel gor nu inomFolksam, sa handlar mycket om att standardisera, framfor allt till stor del processer, ochprocesserna bor, till nastan 100%, i nagt IT-stod. Nar vi koper de IT-system ifra standard-leverantorer, sa paverkas ju vi av hur det har standardsystemet ar utformat. Alltsa paverkasformagan och vad som gors dar av vilket stod vi faktiskt har valt att anvanda. Och gor dendet sa kommer den att paverka andra saker. Sa det ar ett satt som formagan paverkas av detsom bor darinne. Men sen finns det ju andra formagor som ar av kritisk karaktar, mer, somhar sin ram, sa. Och da paverkar den snarare det som bor dar i. Exempel pa dem ar sanahar bolagsspecifika fragor. Vi har en viss typ av bolagsstruktur, och den gar inte att goravald pa, inte pa dag ett i varje fall. Vi har vissa juridiska perspektiv, compliance, aktuariellaperspektiv som ar valdigt viktiga for oss. Och de har kraven da, inom ramen for den harformagan, kommer att paverka allt som hamnar dar. Aven om vi koper in standardsystem.

Respondent 9

Bakgrund:

Jag har jobbat pa Folksam i sex ar. Jag ar sedan augusti chef for en avdelning som heterKundanalys, som ligger under Kundstrategi, affarsomrade Privat. Och jag har inte jobbatmed formagor, jag har jobbat lite med affarsutveckling tidigare har.

Sa, kortfattat: vad vet du om formagor?

Ja, jo, men jag har ju varit med i nagra sana affarsutvecklingsprojekt, sa jag har kom-mit i kontakt med det sa. Det fordes val in har for runt ett och ett halvt ar sen, heltplotsligt sa borjade alla prata capabilities, sa det var sa har ”Vad ar det har for nanting?”,

75

och da kande jag att om jag ska kunna forsta vad man pratar om och, liksom, hamna pasamma niva sa man inte far ett sprakligt overtag sa vill jag lara mig det har. Och ocksa villjag, borjade jag tillsammans med Charlotte och Carina titta pa vilka formagor som finnsinom mitt ansvarsomrade, for att vi ska kunna se ”Vilka formagor mar inte bra?”, ”Vilkaformagor mar bra?”, och hur ska vi kunna utveckla dem. Bara liksom, for mig, att fa uppalla korten pa bordet, for det ar sa latt att det hamnar i projekt, sa det ar dar man jobbarmed dem. Men jag har ju min vardag och det var dar jag ville.. Sa jag paborjade det arbeteti julas, och sen har jag haft en alldeles for hog arbetsbelastning sa jag har inte haft nanmojlighet att fortsatta. Men jag har, kunde inte riktigt, se fullt ut hur man skulle anvandadet, men sen nar vi borjade titta pa det sa kande jag att ”Ja, men okej, om vi borjar beskrivaverksamheten utifran formagor sa kanske”, men jag var inte helt hemma an.

Du sa att det dok upp for ett och ett halvt ar sen, ungefar?

Ja, jag tror det. I alla fall for mig. Cordial var ett bolag som kom hit. Och sa heltplotsligt kandes det som nar de kom, och man gjorde den har nya arkitekturfunktionen,man omstrukturerade massor som var, och da kandes det som att helt plotsligt borjade manprata formagor. Fran att, jag vet inte vad man pratade innan i och for sig, men det kandessom att helt plotsligt sa borjade manga prata om det.

Hur kom du i kontakt med formagor?

Ja, det var ju just genom ett sant affarsutvecklingsprojekt, som hette ITJP, som jag varmed i litegrann ett tag. Och det var dar jag horde ordet, och sen, da var det ocksa, tillsam-mans med Carina Eriksson som du kanske har traffat, affarsarkitekt. Sa hon hade gatt nansan dar affarsarkitekturutbildning, och det var dar som, for det ar manga som har gjort denpa Folksam, och da kanns det plotsligt som om man kommer med ett gemensamt sprak,som inte riktigt alla forstar.

Har du anvant dig av formagor?

Det var ju just for att fa en bild av min egen verksamhet som jag forsokte anvanda, jag harinte natt fullt hela vagen fram, men jag kan tycka att det ar ett bra satt att tanka. Menjag far anda inte ihop det riktigt med kanske processer och sadar. Jag kan se hur liksom,”Okej, det ar det har vi ska gora”, men det, jag ar inte riktigt klar. Men det kanske ar foratt jag inte kan det heller, och jag kanske inte ska kunna det heller.

Finns det nagonstans dar du tror att det skulle vara anvandbart att anvanda formagor?

Ja, men jag tror, eller jag ser det ju framfor allt i projekten da, vad ar det vi ska gora,vad ar det vi behover kunna. Men ocksa just for den egna verksamheten, alltsa, sa sag jagdet, utifran mitt perspektiv, att jag tanker att ”Vad ar det vi ska gora? Vad har vi forformagor inom mitt verksamhetsomrade?”, och ”Vad ar det vi gor? Hur mappar de, ochvad ar det som inte mar bra?”, ”Okej, den har formagan kan vi inte leverera, for att..” ochsa kan man da hitta orsaker och kanske kan borja jobba med det, sa man far upp nagonslags karta. Men sen ar det ett konstigt satt att uttrycka sig, sa jag har svart att, liksom,dra det vidare till min grupp och saga ”Nu ska vi titta pa vilka formagor vi har”, de baratittar pa mig, sa att jag har inte riktigt hittat hur man ska, hur ska man kunna anvandadet i verksamheten utan att alla ska behova lara sig det? Det tycker jag ar svart.

Finns det nagot du skulle vilja koppla ihop med en formaga?

Men jag tanker lite sa har pa processer, och hur det liksom hanger ihop helheten. For

76

det ar ju en sak i en formaga. Men jag vet inte, jag kan for lite om det.

Ar det nagot forutom processer som du kanner vore intressant att kunna relatera till enformaga?

Det har jag inte reflekterat over, men det finns det sakert. Ja, men det ar klart att detmaste finnas det. Ja, men, jag vet inte om det ar sa du menar, men jag tanker att inommitt omrade, om man gor ratt saker pa ratt stalle i organisationen. Sa att vi inte sitter medsamma formagekort pa flera stallen. Jag vet inte.

Lista pa fem element fran literaturen, kanns de relevanta att koppla till formaga eller inte?Krav, resurs, roll, tjanst, handelse.

Ja, men det later ju relevant alltihopa. Saklart. Det ar lattare da, om man tanker utifranett projekt, sa blir det ganska tydligt. Men jag tankte utifran min egen verksamhet.

Finns det nan sarskild situation dar nagon av dessa ar anvandbar att koppla ihop medformaga?

Ja, men i kravsituationer kanns det ju ocksa.. Vad hade du mer, roller och..

Resurs, tjanst..

Ja, men alltsa, det ar ju alla de har, som det ar superrelevant, sa klart. Men det kannssom att, i all fall utifran mitt perspektiv, sa tillampar man det har sattet valdigt mycketi projekt, och det ar ju jattebra. Men det blir svart eftersom man har en verksamhet somman ska driva ocksa, som inte riktigt ar uppbyggd pa samma satt, overallt, och da ar detsvart, tycker jag.

De har elementen, paverkar de formagan, eller tvartom?

Nu maste jag tanka lite. Det borde ju vara sa att det ar fomragan som ska fa, eller vanta.Att det ska vara, om man tanker sig att det ar en affarshandelse som vi maste agera pa, samaste vi ju se till att vi har formagan att kunna hantera den, med kompetens och massor,krav och allt dar i. Sa det ar klart det maste finnas nan hierarki i det dar. Vi maste juanpassa varan formaga till vad vi vill gora. Sa tanker jag.

Respondent 10

Bakgrund:

Jag har jobbat lange pa Folksam. I hela min yrkeskarriar i princip, i valdigt manga olikaroller. Kommer fran affarssidan, verksamhet, jag har salt forsakringar. Jobbade lange medproduktutveckling, haft ledande befattningar i 20-25 ar. Nu ar jag specialist, men jag job-bar med styrningsfragor, governance-fragor. Och just precis nu sa sitter jag och utvecklarledningssystem for informationssakerhet och kvalitet, bland annat tagit fram en certifiering.Och det som gor att jag ar intresserad av formagor, det egentligen grundar sig litegrannpa mitt intresse, min erfarenhet, min insikt om hur vi jobbar i sana har stora, komplexaorganisationer. Det ar valdigt latt, vet du, att det blir dubbelkommandon, spagettisystem,dubbellagring. I verksamheten speglas det av att man har parallella processer for att gorasamma saker. Sa att jag har forsokt, i det jag gjort, liksom genomsyrar mitt arbete, atthitta losningar for integrera olika typer av processer och system och sana saker da. Ochur det perspektivet, nar jag blev bekant med formagor, var det litegrann ”Aha, har har vinat”. Sa dok det upp.

77

Kortfattat: vad vet du om formagor?

Ingen teoretisk grund. Men jag har stott pa det, jag har jobbat och ar valdigt bekant medarkitekturfragorna, jobbat nara dem, sa att saga, sa jag har fatt information. Litegrann harjag last, sa jag forstar ju ungefar principerna for det. Men det ar inte min specialitet, sa attsaga.

Nar dok konceptet med formagor upp? Hur lange har du jobbat med det?

Jag har varit bekant med det, tror jag relativt tidigt, sedan 4-5 ar tillbaks. Jag har fatt,liksom, underhandsinformation genom att jag har goda relationer till koncernarkitektur.

Hur kom du i kontakt med formagor?

Ja, dels har jag fatt information som jag sa, men konkret tillampning var for ett parar sen, nar jag forsokte se hur jag kunde applicera det pa det jag gjorde just da, namligeninformationssakerhet. Dar man sag sambanden mellan informationshantering, allt vi gor paFolksam handlar om information egentligen, det ar immateriella tillgangar, det ar processeroch det ar system, och sa ar det mycket information da. Nar man jobbar med arkitektursa ar liksom informationshanteringen central, vilket speglas i formagor, sa att saga da. Ochdet jag jobbar med ar egentligen samma sak da, nar jag jobbar med ledningssystemet. Detvar saker informationshantering. ”Aha.” Nar vi da ska, som det heter, nu ar vi inne painformationssakerhetsteori. Nar vi da, som jag skulle gora da, hitta en modell for att identi-fiera informationstillgangar, da star ju liksom tva teorier mot varandra. Da ar hela det harmed informationssakerhet baserat pa standard da, ”Vad ar en informationstillgang?”, ”Hurdefinierar man den?”, kontra ”Hmm, vad ar formagor? Hur definierar man dem?”. Ochda sag vi sambanden da mellan saker informationshantering, informationshantering, det villsaga informationstillgangar, och formagor. Och den, i det, det var liksom en aha-upplevelse.”Det har kanske vi kan gora nagot riktigt bra av, istallet for att kora parallella spar narvi ska bygga upp tva olika ledningssystem.” Det var det, nan slags ide da, som bade kon-cernarkitektur, som jag fick lite stod av just vid det tillfallet, och jag da som representeradeinfomationssakerheten nar vi skulle bygga upp ledningssystemet sag att har ar nanting vikan samarbeta kring da. Det var det ena. Det andra som egentligen ar samma sak, nu ar detannu mer teori da, men operativ risk, Solvens-regelverk, alla pratar om risker idag, det ar samycket risker forknippat med framfor allt anvandandet av IT, sa att saga va. Sociala me-dier, allt ar information, alla ar beroende av information. Och for att, om vi ska bedriva denhar typen av verksamhet som vi gor pa Folksam, sa maste kunder och intressenter forsakrasig om att vi har just en saker informationshantering, for annars tar vi risker, och finansin-spektionen, den overvakande myndigheten, de staller valdigt mycket krav, och det gor avendet har kommande Solvens-regelverket, pa operativ riskhantering. Operativ riskhanteringoch informationssakerhet ar ungefar samma sak kan man saga da. Det var en lang, for attkomma dit, men i alla fall. I arbetet med att identifiera, hantera, och rapportera operativarisker till ledningen sa sag vi ocksa en mojlighet att rapportera de operativa riskerna paverksamhetsformagor till ledningen, for att hitta nagot satt att bygga upp strukturen pa.Som ett alternativ till, som det hade varit dittills, att man hade gjort riskbedomningarna pafunktionsniva. Det finns manga funktioner pa Folksam, typ hundratals. Och sen sa bakarman ihop det och sa ger man nanting, men funktionerna speglar ju inte vad man gor ellerhur man vill att det ska vara, utan bara var manniskor sitter nagonstans. Sa det ger inteledningen en bra bild av risksituationen i foretaget. Genom att relatera till formagor ochen ide om, kanske man kan koppla ihop i framtiden, att formulera mal pa formagor, ochhantera risker, alltsa riskerna att man inte kan uppfylla malen. For det ar egentligen detsom risker handlar om. Det var liksom bara, sa har, losa tankar om det da. Nu kanske jag

78

svarar pa andra fragor ocksa. Men sen sa var man ganska progressiva da pa risksidan, och dukommer sakert prata med dem ocksa da, som vagade ta klivet, att borja rapportera, utan attman hade en underliggande struktur pa verksamhetsformagor, sa borjade man rapporterariskerna till koncernledningen pa verksamhetsformagor. Ja, och i det arbetet har jag liksomstott och uppmuntrat, kan man saga. Eftersom risk och informationssakerhet hanger ihop.

Du har kommit in lite pa nasta fraga: har du anvant dig av formagor, och hur? Hardu nagra fler exempel?

Nej, det som jag konkret har forsokt anvanda det till, det var de tva, konkreta anvandningsomradensom jag forsokt, liksom, bidra till eller har tillampat da, sa att saga. Naturligtvis andra,men det ar inte mitt bord da, sa att saga.

Kan du se nagra andra anvandningsomraden for formagor?

Man kan vanda pa det, vad kan det inte anvandas till? Nej, ja men fokus da i allt somhar, vi ar styrda av, nu forsoker jag tanka har, vi maste rapportera ekonomier pa produk-ter och bolag. Och kostnadsstallen dar pengarna finns ligger ju pa funktioner, det kan viinte gora sa mycket at. Det driver sa att saga ett funktionellt arbetssatt, for vi maste haekonomierna kring de har parametrarna. Men det ar ju inte det vi vill uppna, vi vill intevara funktionsorienterade eller produktorienterade, utan vi vill ju na vara mal framover.Och for att na dit, allt da, utover ekonomierna, sa vi kan styra mot och folja upp mot,dar skulle jag vilja peta in formagorna. Alltsa oavsett om det ar verksamhet eller den hartypen av flummiga fragorna som jag jobbar med, det ar risk och GRC compliance och sanasaker, som underlattar for ledningen att fa en vy over foretaget i forhallande till var vill vivara i framtiden, hur ser de langsiktiga malen ut, hur tar vi oss dit da, all styrning. Ochkanske da framover, aven matt och matetal, och de delarna. Sa maste det sen mota denekonomiska uppfoljningen, sa klart. Det ar min lilla vata drom, om hur man ska kunnaanvanda formagorna framover. Utan att ha den dar teoretiska, liksom, grunden for vadman kan gora med formagor och sa. Men jag ser, man blir latt euforisk nar man ser demojligheterna, den har silverkulan i verksamheten som skar igenom allting, som inte funnitstidigare. Jag holl pa att troska ratt mycket med processer pa 90-talet, och tyckte val inteatt man uppnadde riktigt de effekterna med processorientering.

Vilka element vill du koppla till formagan for att det ska vara anvandbart i dessa situationer?

Ja, jag tror att jag delvis lamnade svar pa det nar jag sa ”Inte de ekonomiska rapporterna”,och det betyder ju allting annat, ur perspektivet styra och folja upp verksamheten. Da ardet alltsa all information ur ett styrnings- och uppfoljningsperspektiv da. Och det betyderju ocksa att man maste sammankoppla en hel del saker. Informationsmangder, processer.Man maste bryta ner formagor, koppla dem till processer, koppla det till system, och goraden har kopplingen, alltsa det ar ju en sa otroligt komplex organisation. Och det ar ju denanalysen som aterstar, darfor kan jag inte svara pa den mer konkret an vad jag gor just nu.

Forutom processer och system, finns det nagra andra element du kanner vore intressanta?

Nej, det ar ju alltsa process, och med process menar jag ju da liksom arbetsrutiner paoperativ niva, sen ar ju det i de olika verksamheterna oavsett om det ar HR eller IT, ellerom det ar nanting annat som gors i verksamheten. Det ar ju liksom ingenting som aruteslutet da, utan det ar det som gors, da kan man hitta det pa operativ niva, som ar mergeneriskt, dar de sen har en drivkraft dar man satter mal pa formagor och sen utformar manprocesser, och processerna gor olika saker, varfor man suboptimerar och springer at olikahall da. Sa det maste ju ner pa operativ niva for att man ska kunna styra verksamheten i

79

onskad riktning da. Det ar sa langt ner man maste komma, da tror jag inte man kan, daska man nog ha utgangspunkten att man inte exkluderar nagon verksamhet. Men sen ar judet, jag menar, det ar ju ett sant dar arbete som aldrig blir klart, det ar ett forhallningssatteller ett synsatt da.

Fem element fran litteraturen, kanns de relevanta att koppla till formagor? Krav, resurs,roll, tjanst, handelse.

Krav, ja, det ar styrning. Resurs, det beror pa vad man menar med resurs. Om manmenar med resurser mer typ av personal och kostnader, sa ar det en ekonomisk fraga ochda har vi ett styrsystem som sager att det ska hanteras pa ett visst satt. Men sen kan juresurser vara andra typer av tillgangar, det kan ju vara fastigheter, lokaler, och sana sakerva, sa att, man ska vara noga med definitionerna va, jag maste veta vilka resurser det avses,for vi maste hantera..

Du far garna ha en asikt om bada.

Men resurser i form utan tillgangar, da kan jag vrida det pa mitt satt och saga att enresurs ar en tillgang, information ar var viktigaste tillgang, sa alla typer utav information-tillgangar i den meningen att de utgor resurser, det maste relateras till formagor om manvill uppna nagonting. Och krav staller man ju pa informationen. Sa styrning av, egentligenlopande verksamheten, de resurser i form utav informationstillgangar och krav pa informa-tionstillgangar ur ett formageperspektiv blir ju en viktig styrningsfraga om man ska uppnanagonting. Dels det lopande arbetet i sig, och sen forandringsarbetet. Vad sa du mer?

Roll, tjanst, och handelse.

Roll. Ja, det blir nog kanske nar man har mognat i det har om man tanker roller, ansvarfor att utfora arbetsuppgifter, agarskap och de fragorna, sa kan man ju tanka sig att omman har kommit en bit pa vag, man maste ju mogna i det har ocksa. Man kan inte borjautse agare och ansvar och roller mer an kanske pa arkitektursidan, for att driva arbete, mennar man har mognat i det har sa tror jag att fragorna addreseras, hur man ska jobba rentpraktiskt, vilka roller som ska finnas. Men dar ar man nog inte an, det tror jag man ska tadet lite forsiktigt med. Sa man inte tror att det ar losningar pa den har fragan hur man skaastadkomma resultat med formagor som drivare i arbetet.

Sen tjanst och handelse.

Ja, tjanst. Det definieras ocksa pa olika satt va, beroende pa vad man menar med det,men utfora en tjanst eller leverera en produkt, menar jag, det ar ju samma sak. Egentligenatt vi utfor de tjanster i arbetet, levererar den produkt som kunden kraver, det menar jag,i och med att vi jobbar med immateriella tillgangar, det vill saga utfor tjanster, vi ar inteen snickerifabrik eller tillverkar bilar, sa ar det det lopande arbetet, sa sjalvklart, ja, tjanst.Men du kommer fa, nar du fragar runt i Folksam om tjanst, sa kommer du fa olika svar padet. Jag svarar utifran ett ISO 9001-perspektiv som ar den allmant vedertagna definitionenpa vad tjanst ar, utanfor det har foretaget. Sen finns det mycket annat som ar tjanster ocksa.

Handelse.

Nej, det har jag ingen uppfattning om.

De relevanta elementen, i vilka situationer skulle det vara anvandbart att koppla dem tillformaga,och varfor vill du koppla just dessa?

80

Svar fraga. Ocksa definitionsfraga, men jag tror att det har ju att gora med vart dagligaarbete, det ar ju objekt som du tar upp som, det finns ju naturligtvis flera, och sen ar det jusom sagt definitionsfragor, men det ar ju sadant som om man sager, min uppfattning om det,att man ska styra verksamheten sa att vi astadkommer ett resultat i onskad riktning, ochfoljer upp verksamheten. Da blir ju de har parametrarna, da maste man ju uppmarksammadem. Da hanger ju valdigt mycket pa det. For sen liksom att konkretisera det, da masteman ner i geggan och hitta de har entiteterna dar man kopplar ihop det, och det kan jaginte ha nan uppfattning om. Jag svavar ganska hogt dar. Da ar det nastan lattare attkanske ta nagon slags konkret exempel, och det liksom kanns lite svart att komma pa, damaste jag fundera litegrann. Men jag tog ju ett exempel genom det som vi hade gjort ivart arbete, det gar ju att omsatta i produktutveckling till exempel, man kan hitta gemen-samma komponenter kopplade till formagan, hur man vill att produkterna ska utformas, tillprocessutvecklingen, gemensamma komponenter som om man definierar det som tjanst ellerhandelse eller krav for att man ska forandra processerna, det ar ju lite situationsanpassatocksa. Men det var ju det dar, man hittar det i alla verksamheter som utfors oavsett omdet ar IT eller mer pa verksamhetssidan, i de olika ledningssystemen sa hittar man ju detsom maste styras for att vi ska kunna na dit.

Elementen, paverkar de formagan, eller tvart om?

Ja, det ar klart att formagan, om man sager, jag ska styra, om man bryter ner styrnin-gen i matt och foljer upp att elementen ror pa sig bara for att man vill styra, sa paverkar juformagestyrningen alla elementen. Annars ar det meningslost att halla pa. Om man foljerupp sa paverkar ju avvikelserna i styrningen, alltsa att man inte har natt avsett resultat,da paverkar de ju formagan att uppfylla, sa att saga. Det ar sa jag vill att man ska sedet. Da blir det ett ledningsverktyg om man anvander det pa det sattet, och jag tror attkoncernarkitektur uttalat eller outtalat har de ambitionerna, att det ar ett viktigt verk-tyg for att kunna forflytta Folksam, och da maste man tanka Styrning, hmm, Uppfoljning,Avvikelser, Mal, Matt, bryta ner det.

Respondent 11

Bakgrund:

Jag ar nyanstalld pa Folksam. Jag borjade vid arsskiftet, och har en roll som heter IT-strateg. Sa jag jobbar pa Strategisk IT, dar koncernarkitekterna sitter, men jag ar da en,vad ska man saga, som en egen liten roll. Jag rapporterar till Daniel Leideberg som ar cheffor Strategisk IT, och sitter i den ledningsgruppen, men har inte en egen organisation. Jagar liksom nan form av specialist da. Och tanken med min roll ar val att jobba och stottahela IT-organisationen i strategiska fragor, och driva liksom lite olika initiativ. Jag jobbar iprincip bara uppdragsbaserat och har inga linjeansvar, forutom kring fusioner och uppkopsa ar jag inblandad ur IT-perspektivet da. Och framfor allt nu sa haller jag pa och jobbarmed en systemstrategi for utvecklingsomradet inom koncerngemensamt stod, som ekonomioch HR och sadar.

Kortfattat: vad vet du om formagor?

Ja, begreppet som sadant ar val lite nytt for mig. Jag har ofta, jag tror nog att jag har,sa att saga, arbetat med det innan, aven om jag ofta sjalv har tankt i termer av, liksom,funktioner, alltsa det ar nanting vi gor, och det ar val, tror jag, i mitt huvud, bara en annalabel pa vad det handlar om da. Och nu innan jag borjade pa Folksam sa har jag jobbat somkonsult pa Accenture sen 2007, och dar har jag ju ofta liksom hanterat de fragestallningarna,”Vad ar det vi vill astadkomma?”, “Vad ar det for nat vi ska kunna gora?”, och liksom, hur

81

gor vi de forandringarna da. Sa, som tanke ar det val i mitt huvud, men just att kalla detfor formagor har jag val borjat gora har pa Folksam da, tror jag.

Sa nar du borjade jobba med just formagor var nar du borjade pa Folksam?

Ja, som begrepp sa. Men som definition har det val ofta funnits med mig.

Hur kom du i kontakt med formagor?

Ja, har ar det ju for att i det team som jag leder kring den har systemstrategin sa ardet tre stycken arkitekter som jag jobbar med, och da, och aven i min introduktion tillforetaget sa satt jag ner med Charlotte, till exempel, ja, och med Robert och Stefan Reifalkoch sa, sa det kom val in ganska snabbt dar, hur man jobbar med den kartlaggningen.Och vi satt och tittade pa en del arbete som har gjorts kring formagekartlaggning inomekonomiorganisationen och sadar.

Har du anvant dig av formagor, och i sa fall hur?

Ja, vi, i systemstrategiarbetet sa har vi ju, en del i det ar ju att, vi forsoker ju malaupp en malbild for vart applikationslandskap. Och det ska ju stodja funktionalitet, ellerformagor. Och an sa lange sa pratar vi valdigt mycket om de malbilderna och den harmalfunktionaliteten, eller logiska IT-stodet, eller formagor. Sa i de termerna har vi val badevarit i det granslandet, och sen nu de nasta steg som kommer, sa handlar det mycket omatt se ”Var ar vi i nulaget?” och ”Vad ar det for nat vi klarar av att gora idag?” och ”Vadar det for gap mot det vi vill?”. Och i det sa handlar det ju bade om att titta pa systemenmen ocksa da ta formagekartlaggningen ett steg langre och kanna att vi har traffat ratt dar.

Kan du se nagra andra anvandningsomraden for formagor?

Ja, alltsa, jag tycker val, generellt, sa nar man kommer som ny pa Folksam, om vi nu antaratt det har blir Folksam-specifikt, sa ar det ganska svart att fa en overblick och forstaelsefor vad ar det man gor var, och gor man samma typ av sak pa flera stallen, och varfor gorman det, och sadar. Och i det dar arbetet vi haller pa med nu, sa jobbar vi ju aven medFAR, framfor allt for att borja forsoka fa till en annan dokumentation kring de system somvi har. Men dar ser, maste ju formagorna komma in sa att man kan fa en koppling bade tillorganisation, som, vad sager man, stoder eller genomfor de har formagorna. Systemen somska stotta och liksom hur de hanger ihop, sa det ar ju, liksom, att fa overblicken, och kunnaforsta om vi nu ska gora forandringar har, och liksom, flytta pa nanting, eller ja, fusioneroch uppkop, om vi koper ett bolag. Hur passar det in i varat pussel, och vad ar det fortyp av synergier vi kan fa, eller vad ar det for problem det har kommer att stalla till, ellerkommer vi. Dar tror jag att man har valdigt stor nytta av att forsta sin egen formaga, vilkade ar och var de finns och hur vi arbetar med det. Men jag tror att det ar valdigt viktigtatt, ja men, FAR eller nat typ av verktyg som, sa att man kan ha all den har informationen.For bara en formagekartlaggning i nan form av bild som inte ror pa sig, eller bild som intehar kopplingar till annat, den blir ju inaktuell och till slut ganska vardelos, nar man inteser hur det hanger ihop med manniskorna som utfor det eller systemen som stoder det ellervad det nu ar. Sa, ja, var det ett svar?

Jada. Vilka element vore intressanta att relatera till formagor? Du namnde organisationeroch system, finns det nagra andra?

Ja, det tycker jag. Man har ju tagit fram ett vardedrivartrad, eller en vardedrivarlogik,som vi sa att saga ska mappa in de olika initiativ och projekt som vi har. Det ar liksom,

82

vad ar det for, ”Vad bidrar det har med?”, och sa finns det ett antal huvudgrupper pavarden och sen sa nedbrutet. Dar tycker jag ju man bor kunna hitta en koppling, att enformaga kan sakert bidra till, eller bor ju bidra till en eller flera av vara toppvardedrivandekoncept da. For gor de inte det kan man ju fraga sig ”Varfor har vi den har?”. Och dabor man ocksa kunna forsta vilka formagor ar det som ar viktiga, och vi kanske ser, fattasdet formagor, eller? Och sen sa skulle man ju aven vilja fa nagon form av, ja, vad ska mankalla det? Halsomatning? Alltsa, hur ar formagan, hur mar den? Och vad bestar den av?Vad ar det som kravs for att formagan ska uppratthallas? Ar det bara kunskap, eller ardet systemstod, eller vad ar det for nat vi behover for att kunna exekvera pa den har, ochhur mar vi. For da kan man ju ocksa borja forsta vad ar det vi behover, liksom, var kanvi bli mer effektiva eller mer duktiga. Och pa samma satt som att formagor da knyter antill vara vardedrivare, sa bor man ju aven, tycker jag, for att forsta, om man tanker liksomforflyttningsperspektivet, vart ar vi pa vag, sa bor man ju pa samma satt som man kopplarinitiativ och projekt till liksom varden och effekter sa bor man ju forhoppningsvis kunna sevilka sana arbetsinsater som bidrar till en starkt formagehalsa, sa. Sa det hanger ju ihop,men, ja.

Fem element fran litteraturen, kanns de relevanta? Krav, resurs, roll, tjanst, handelse.

Ja. Krav kanns ju absolut relevant. Vad sa du sen, resurs?

Ja.

Kan du forklara vad du menar med resurs?

Det kan vara dels till exempel pengar, dels material och sadant som byggnader, beroendepa hur man vill modellera det.

Men, har det ocksa, for resurs kan ju ocksa vara, alltsa, arbetskraft eller datorstod, ochi sa fall tycker jag ju att det ar relevant, det sa jag ju. Ja, men det kanns ju relevant, attman kopplar vad ar det for nat som far det har att handa.

Sen roll.

Ja, de ar ju lite lika resurser, just det.

Och tjanst och handelse.

Och tjanst i perspektivet arkitektur?

Tjanst som pa nat satt bidrar till formagan, tjanst som formagan bidrar till att det garatt erbjuda.

Ar det formagan som bidrar till tjansten, eller ar det tjansten som ar, ja, en del av formagan?For man kan ju tanka, men tjansten ar i nagon form av, ja, det erbjuds en tjanst pa etteller annat satt, som gor nagonting, och ja, det bor ju vara en del av en formaga. Sen omdet, vem det ar som utfor den har tjansten, det kan ju antingen vara vi har, eller vi koperen tjanst nan annan stans. Men for att en tjanst ska vara relevant for oss, antingen atterbjuda, alltsa att IT erbjuder en tjanst for verksamheten, eller att vi erbjuder en tjanst forvara kunder, eller att vi koper en tjanst for nat sant dar, da bor ju den koppla till nan typav formaga, det kanns ju rimligt, sa. Givet att man arbetar med den typen av paketering.Och dar ar jag lite osaker vad, hur Folksam gor just nu. Om det liksom finns nan form avtjanstekatalog eller liksom att man arbetar pa det sattet, eller om man vill rora sig lite at

83

det, det vet jag inte.

Och handelse.

Vad tanker du pa for handelse da?

Nagon slags handelse eller event som kan paverka formagan eller foretaget.

Tanker man da, vad vet jag, skulle det kunna vara att jag vill kopa en forsakring, som kund,och att ja, vi ska ha en formaga som heter, som handlar om att vi upprattar forsakringsavtal,eller att vi far en premieinbetalning och vi har en formaga som heter hantera betalningar, sa?

Ja.

Ja, men absolut, det ar klart att det ar relevant. For troligen sa ar ju en handelse relateradtill flera formagor. Och om vi tar handelsen kopa forsakring, sa bor vi bade kunna upprattanan form av avtal, vi maste ju ha en formaga att ha koll pa hur vara forsakringsprodukterser ut, vi maste kunna ta hand om betalningar, vi maste kunna kopa produkter, eller ja,liksom, skadematerial och annat. Sa de relaterar ju, om man forandrar den sa kommer manju behova sakert forandra annat. Sa det ar sakert klokt.

Dessa element, varfor kanns de relevanta att koppla ihop med formaga, och finns det nagonsarskild situation dar det skulle vara anvandbart?

Alltsa, generellt for att jag tror man forstar battre vad det ar som antingen inte fungerar braeller vad som, genom att gora nanting battre sa blir liksom helheten battre. Det ar ett, Aoch O, det har med att, som forsakringsbolag sa bor vi ju ha ett antal overgripande formagorsom inte forandras, vi ska salja forsakringar, vi ska forsakra manniskor, och sen sa kan vi juhantera det pa olika satt, men jag tror att man far ett satt att forsta hur helheten hangerihop, med en jakla massa bolag och det ar ju liksom lite lokala varldar i liksom skador ochi pension och man haller pa och, det ar inte sakert att man forstar att en forandring harfaktiskt paverkar en massa andra saker, och da ar det har ju ett satt att fa koll pa det. Detvar val det generella.

Elementen, tror du att de paverkar formagan, eller tvartom?

Det var ju ingen latt fraga. Vem kom forst, honan eller agget? Jag tror nog att, jagskulle vilja saga att det beror nog pa. Och jag tror ocksa att det kan ha att gora med, alltsa,pa vilket satt, kulturellt, alltsa, hur ar de har formagorna definierade, och har de, om manfar liksom vara lite frack och saga att, om det ar nan form av, liksom, efterkonstruktion, iatt, okej, det har med formagor ar ju praktiskt och bra, vi ser ett varde i det. Da sager vi,“Vad har vi for formagor?”. Da ar ju de sakert drivna ur antingen om det nu ar handelsereller om det ar processer som vi har, sa har man ju pa nat satt kommit fram till de harformagorna. Man har sakert tittat pa om det finns nan industristandard eller olika sant dar,visst. Men man ar ju paverkad av hur saker och ting har varit. Och da skulle jag val troatt, ja men, hur lange vissa saker har funnits, och nan form av mognadsgrad och sant dar,sa finns det sakert olika typer av paverkan. Ar det, sa att saga, affarshandelsen som styr,eller ar det sa att det kanske ar nan formaga som ar valdigt central, som har funnits valdigtlange eller som styr andra saker. Men jag har ju ingen kansla eller kunskap kring vilken somar styrande i de har sammanhangen, tror jag. Men jag tror att det finns en, ja, lat oss sagakulturell eller tidsaspekt pa det.

84

Respondent 12

Bakgrund:

Jag ar verksamhetsarkitekt, pa koncernarkitektur, och har varit har sen september, etthalvar. Har jobbat som verksamhetsarkitekt, ja, tolv ar kanske.

Kortfattat: vad vet du om formagor?

Vad jag vet, ja, jag vet ganska mycket. Vad man har det till, och hur man bygger uppdem, och strukturen, och varfor man behover dem.

Kortfattat: vad ar det?

En formaga ar nanting som behovs i verksamheten for att man ska kunna utfora sin business.Utan att man sager hur eller nar eller vem som gor det. Till skillnad mot processerna somtalar om det. En formaga finns bara en enda gang i en formagekarta, om man nu uttryckersig sa.

Hur lange har du jobbat med formagor?

Jag har nog hallt pa i en tre till fyra ar med det.

Hur kom du i kontakt med det?

Ja, det var nog nar vi skulle, det var pa min forra arbetsplats da, nar vi skulle forsokabeskriva vad vi gor, vad vi har for olika systemstod, vad vi behover kunna hantera. For vihade valdigt mycket olika processer, mycket olika systemlosningar, och vi ville se att om viska gora en ny forandring av nanting, hur, vad har vi da som skulle kunna hjalpa oss, finnsdet nat annat systemstod idag som gor samma sak. Det var ocksa i, nar vi skulle forsokaklassificera vilka olika initiativ vi hade, vad var de inom for omraden? Det var da vi borjadeforsta att vi behover en san karta.

Har du anvant dig av formagor, och i sa fall hur?

Ja. Dels har jag ju anvant det i att, nar vi har tittat pa processer. Att slippa ga neroch gora aktivitetsfloden, kan man saga, “Vad ar det for nanting du utfor i den har pro-cessen?”. For att kunna hitta, just om man gor en forandring i en formaga, ”Var slar det?”,i vilka processer slar det, for att se att vi fangar alla. Som, till exempel om vi ska ta Kundda, som ar ett ganska vanligt, sa da kan man ju Hantera Kund pa olika satt. Nar man, forstagangen man moter den, eller nar man andrar den, eller nar man avslutar, och det ar ju olikaprocesser. Om man andrar nanting i Kund, sa maste man kolla alla de har processerna, sadar, det var viktigt. Vad var fragan?

Om du anvant dig av formagor, och i sa fall hur? Ar det valdigt manga behover du juinte rakna upp alla i detalj.

Men det var i sa fall identifiera var vi maste ga in och kontrollera nar vi ska gora enforandring.

Kan du se nagra andra anvandningsomraden for formagor?

Det ar ju ett bra satt att identifiera ansvar inom organisationen, vem som har ansvar forvissa delar. Och sen ar det ju, ja, just i planering, vi anvander det ju pa ganska manga, det

85

ar planeringen av olika initiativ, sa ar det ju bra.

Vilka element tycker du vore intressanta att koppla ihop med formaga?

Ja, det ar ju processer, det ar ju applikationer, eller tekniskt systemstod. Det kan varaorganisation, men det behover det inte vara, tycker jag, riktigt. Det ar ju information, detar ju lagar och policy och regler, regelverk, affarsregler da. Det ar ju det jag ar intresseradav. Sen finns det ju krav da, men da ar det ju mer kravsidan, sa det ar inte det jag anvander.

Fem element fran litteraturen, kanns de relevanta? Krav, resurs, roll, tjanst, handelse.

Ja, krav, just for mig, jag behover ju inte krav, for jag, det ar mer krav. Men man behoverkunna koppla krav till, ett krav ar ju ofta nanting som bara galler nu, nar jag gora det har.Sen om ett ar sa ar ju kravet annorlunda. Vad var det, sen hade du resurs?

Resurs, ja?

Och resurs, da ar det kanske information vi tanker pa eller, och system?

Ja, det kan vara information, det kan vara pengar, det kan vara annat som byggnader.Du far garna ha en asikt om flera.

Jag ser det nog som att det ar information och systemstod da, och det tycker jag abso-lut, ja.

Sen ar det roll.

Ja, om man da tanker pa utovar.. Jag tycker inte rollen ar jatteviktig, faktiskt. Mendaremot kan det vara om man vill dela upp ett ansvar, vem som har ansvar for det dar,inom en business, men utovarrollen, nej.

Ansvarsrollen mojligtvis, men inte utovarrollen?

Ja, och det ar ju ur aspekten att om man vill gora en forandring i den har formagan,sa maste man ga via den ansvariga for att veta.

Tjanst?

En tjanst, det ar ju hur det ar implementerat. Det ar inte jag heller intresserad av, men detar ju IT intresserade av.

Och sen handelse.

En handelse. Ja, det ar ju ocksa mer det som hor till, jag skulle saga att det ar pro-cesserna som beskriver handelserna litegrann. Ja, jag ar lite tveksam pa den.

Dessa element, varfor vill du koppla just dem, och skulle det vara anvandbart i nagra speci-fika situationer?

Det ar i analyssynpunkt. Dels ar det ju for att veta vilka regler som galler, lagar ochregler och affarsregler. Om man nu vill styra om sin business pa nagot satt, da vet man varregeln hor hemma nanstans, och en regel kan ju sla pa flera formagor. Sen ar det ju analysenda, hur en forandring av den har formagan slar i organisationen, om jag behover gora om

86

nan process. Eller om jag gar fran andra hallet, om jag har en process jag vill modifiera,vad innebar det? Ja, det ar de har formagorna som kommer att storas, och vad har de forregelverk? Det ar, liksom, sparbarheten dar. Det ar ocksa om jag behover byta ut mittsystempark, om jag drar i systemet X, var nanstans, da ser jag ju vilka processer de jobbari, och sa ser jag ju ocksa vilka formagor, eller jag kan kanske koppla dem direkt till formagan.

Elementen, paverkar de formagan, eller blir det paverkade?

Formagan ar ju, den ar ju bestandig, kan man saga. Sen hur den formagan appliceras iverksamheten, den kan ju forandras. Jag menar, du kan ju ha en manuell hantering aven formaga som sen blir automatiserad. Da har du ju andrat systemstod eller processen.Sa processen kommer ju, eller, formagan kommer ju inte andras, om du inte andrar dinaffarsmodell, dar du sager att “Jag ska gora nanting annat”, eller kommer pa nanting, utande ar snarare de andra attributen, processen, applikationerna, som kommer att styras.

A.2 Intervierw set 2

Respondent 1

Hur kan man se om en formaga fungerar bra eller inte?

Da maste man titta pa vad det ar som bygger upp formagan, och da ar man tillbaka tillorganisation, processer, system och sa vidare. Aggregatet av den sammanstallningen byggerformagan. Sa man maste kolla pa ingaende delar, och hur de samverkar.

Vad tror du paverkar en formagas valmaende mest?

Det tror inte jag man kan saga, for det beror pa vilken formaga och vad den ar uppbyggdav. Du kan ju saga att en formaga, att vi inte har automatiserat nagot stod i den, da har viju organisation och processer, det finns inget systemstod over huvud taget. Sa da kan du juinte saga generellt att en formaga mar alltid samst i IT-delen eller i process-delen eller sa,utan, nej, det beror pa vad det ar for formaga och vad den byggs upp av.

Finns det nagra egenskaper hos formagan du tror paverkar hur formagan mar mer ellermindre an andra?

Nej, jag vet inte vad det skulle vara for nanting, vad for egenskaper den skulle ha. De,sa att saga, den ar en gruppering eller ett aggregat av andra delar, sa att formagan, egen-skaper for formagan, byggs ju upp av andra. Pratar vi egenskaper, ja, men farg, bla, rod,gron, blablabla. Nej, jag kan inte relatera till det just nu.

Av elementen, ar det nagra du tror paverkar formagan mer an andra? Finns det nagraspecifika situationer?

Inte vad jag kan komma pa sa, nej. Det kanske ar enklare om man tar ett specifikt falleller nanting sant, men rent generellt sett, om vi sager att de byggs upp av de har byggk-lossarna, sa ar det ju hur de samverkar, det kommer ju vara olika vad du an tittar pa. Ochlikadant kommer det vara olika om du tittar pa det pa Folksam, eller om du tittar pa detpa If eller nan annan stans, du kommer inte titta pa samma saker for det kommer att varauppbyggt pa olika satt.

Tror du att det finns nagra egenskaper hos elementen som paverkar formagan mer an andra?

Vad pratar vi om for element?

87

De vi har gatt igenom, som kan kopplas till formagan. Sa kanske till exempel upp/ner-tid for en viss applikation, finns det nagot sant som kan paverka mer an annat?

Det beror ju pa vad du lagger i definitionen av, om man tittar pa, om man bara gar till-baka nat ar, nar man inte anvande sig av formagebegreppet over huvud taget, da kallademan sana saker icke-funktionella krav eller egenskaper pa system, uppetider till exempel,och sa vidare. Jag relaterar inte dem till formagor, jag relaterar dem fortfarande till icke-funktionella krav pa ett system, ”vi maste vara uppe 24/7/365”, sa, ja, da ar det ett kravsnarare an att, pa systemets egenskaper, eller det som bygger upp systemet, servrar och sa. Sen kan man naturligtvis saga att det kan kopplas till en formaga. Vinner man nantingpa det? Jag tror inte det.

Respondent 2

Could not be reached for a second interview.

Respondent 3

Hur kan man se om en formaga mar bra eller inte?

Idag tycker jag inte att vi har kommit dit att vi kollar det, sa det ar svart att svara pa.Jag har inte varit med i sana jobb dar vi kollar specifikt pa en formaga riktigt. Ja, eller sa,jag vet inte hur jag ska tanka dar. Samtidigt sa kollar vi ju da pa ”vad ar nulaget kringen formaga idag?” i nagot avseende, vilken forflyttning sker kring en formaga, det gor vii systemstrategin, nya, for kundmote. Da har vi ju litegrann ett systemperspektiv i detvi ska leverera men samtidigt sa tittar vi ju jattemycket pa affarskraven som ligger pa enviss formaga, da ser vi massa onskemal eller behov da helt enkelt, genom affarskraven. Ochdet innebar ju da att vi vill flytta formagan framat, vilket vi kan gora. Sa om man serdet pa det sattet, det kanske ar det som ar tillampningen da, sa absolut, da jobbar vi medhalsotillstand idag da, det gor vi ju. Och pa samma satt gor vi olika omfattningsanalyser forinitiativ da. Ska man bygga vidare pa det och mer mappa upp exakt var vill man titta paformagor, vilken information vill man titta pa eller sa dar, da kan man ju bli annu tydligareda i vad som ar ett halsotillstand eller inte, jamfort med den nivan som vi ar pa idag da,som ar kanske lite mer overgripande. Men man tittar ju anda pa olika delar i olika initiativoch olika strategiarbeten da. Ja, vi gor det, men det gar absolut att gora annu mer.

Finns det nagot som paverkar hur bra en formaga mar mer an nagot annat?

Ja, det forsta svaret blir att det ar svart att peka ut nagot specifikt, att det varierar alltid,om det liksom ar kompetensen eller organisationen eller informationen, och att det, oftastar det mer an en sak som gor att det inte fungerar perfekt om det inte gor det, och att detar ett samspel mellan flera olika. Det kan sakert finnas fall rent specifikt, men da masteman ju titta pa ett exempel i sa fall och se vilket ar det just nu da. Det ar val, ja.

Har formagan nagra inneboende egenskaper som kan paverka hur den mar?

Ta det en gang till.

Senast pratade vi om element kopplade till formagan, som Process, Organisation osv. Trordu att, forutom detta, formagan har nagra egna, inneboende egenskaper som paverkar hurden mar?

Jag tror inte jag forstar hur du menar faktiskt.

88

Finns det nagot du tycker ar en egenskap hos formagan snarare an ett element kopplattill den, som paverkar hur den mar?

Sa en egenskap, alltsa, om vi sager, processerna, det ar element som ar kopplade till den,det ar inte egenskaper pa formagan?

Precis.

Vad ar exempel pa egenskaper da?

Det ar vad jag undrar om du kommer pa nagra.

Ja, kommer jag pa nat just har och nu da? Nej, men vi passar pa den da.

Absolut. Finns det nagra element som paverkar formagan och dess valmaende mer an andra?

Da skulle man nastan behova se hela listan da.

Du kan absolut fa listan. Hela listan, eller de du kryssade for som relevanta?

Ja, da tar vi de jag kryssade for da.

Applikation; handelse; information; input; IT-stod; kompetens; kostnad; KPI; Krav ochspecialfallen Lag, Regel, och Policy; Organisation; Output; Process; Resurs; Risk; Roll; Sys-tem; Tjanst; Vardetrad.

Och jag skulle svara pa om jag tyckte att nan var mer viktig an nan annan?

Ja, precis. Ar det nagra du spontant kanner paverkar mer an nagon annan?

Vad ska vi ta da, om det ar en formaga inom forsaljning som ar att Teckna forsakring,exempelvis. Da maste man ha kompetensen for att kunna stotta informationen, processen,nyckeltal. Ja, det blir en stor fraga tycker jag, att ta stallning kring da. Det beror ju pavilken formaga det handlar om, igen, tror jag, vad som ar viktigast da. Men for att kunnahantera en fraga, det ar ju pa nagot satt grundlaggande att det i alla fall finns en organ-isation med kompetens, om vi, alltsa, det ar grunden for att kunna gora det pa ratt satt,med process och hitta information, det tycker jag ar grundlaggande, annars kommer maningenstans. Om man har en tom box, utan ansvariga, utan medarbetare, da blir det valdigtsvart, man far satta det, fa det pa plats forst da. Det, aven om vi liksom kan hanteraformagor med hjalp av prylar, eller Internet of Things, sa, pa det sattet, sa tror jag anda attnan maste da satta upp hur det ska funka. Sa kan man ju tanka vidare att det eventuelltfinns da anstallda inom andra formagor som ser till att den funkar, helt utan nan personligresurs, men det ar val lite langre fram tror jag, jag tror inte vi har sa manga sana formagoridag i alla fall.

Elementen, har nagot av dem nagra egenskaper som paverkar formagan? T.ex. upptidfor ett system eller liknande?

Inom systemsidan?

Eller elementen over huvud taget.

89

Men inom en systemformaga?

Snarare allmant, oavsett formaga. De har elementen, som man kan koppla till formagan,finns det nagra av dem som har egenskaper som paverkar formagans valmaende, som exem-pelvis om ett system paverkar sa ar det snarare systemets upptid som ar viktig.

Jaha, vilka element har vi da?

Ska jag ta dem en gang till?

Ja, for da maste man ju svara per element, eller hur?

Ja, eller om du kommer pa nagra anda.

Ta en i taget da.

Applikation.

Mmh, vad ar det for applikation, vad skulle det kunna finnas pa den som ar viktigarean annat da, det ar det som ar fragan?

Ja, om det ar nagot hos det elementet du tror specifikt paverkar formagan.

Det ar lite svart att svara pa sa har, da far man nastan gora pa papper, alltsa dokumenterada, i en matris da. Och det kanske andra far ta, som har valt att svara pa det sattet da, fordet kanns som att det blir lite svart att fa ut.

Respondent 4

Could not be reached for a second interview.

Respondent 5

Hur ser man om en formaga mar bra eller inte?

Mitt problem ar att jag kanner att jag kanske inte riktigt kan det har med formagebegreppenda, eftersom jag da har fatt fel ingang fran borjan. Sa att, ja. Sa, for mig ar det just dethar med matris-tanken. Det ar ju lattare om man bara har en formaga som finns pa ettstalle i verksamheten. Det ar svarare om du har en formaga som till exempel Utbetalning,eller Betala ut, eller vad det nu heter, for det ar ju en formaga som finns pa massor medolika stallen, och da ar det ju ganska svart att bedoma om just, du maste du ju titta pa samanga saker. Annars kan du ju malsatta formagan, pa samma satt som man kan malsattaen delprocess. Alltsa, sa tanker jag, fast jag vet inte om det ar ratt. Om vi nu tar, kan duge mig nat exempel pa en formaga som ar singular, finns pa ett stalle?

Anstalla personal, kanske?

Ja, och for mig ar det da, da hamnar jag i den har svarigheten: ”ar det en process eller ardet en formaga?”. Det ar det jag har lite, for nar jag tanker process sa tanker jag ofta inmycket mer an bara sjalva flodet, jag tanker ju resurser och IT-stod och allting. Men omjag, i och for sig, sa da kan man ju saga att, da kan man ju fundera pa hur bra vi ar pa attanstalla personal, och da kan man ju i och for sig utvardera processen pa ett satt, man kanutvardera de som gor det. Ja, nanstans maste man ju satta mal, for att bedoma en formaga.Det ar valdigt svart att bara ”out of the blue” saga nat. Eller ocksa sa kan man ju i och for

90

sig kanna pa sig ”men det har ar ju vi nog jattebra pa”, sa da kanske man kan bedoma det.Men det ar lattare med formagor som finns i en implementation, det ar ju lattare an sanasom finns i flera, for da maste du ju faktiskt gora en ordentlig analys och tanka igenom.

Finns de nagot som du tror paverkar en formagas valmaende mer an annat, till exempelav de har olika elementen?

Ja, det ar ju ganska manga. Det ar ju de har standard, processer, resurser, alltsa de somutfor processen, och hur de styrs, alltsa om de forstar vad det ar som ar viktigt med den harprocessen, och sen de eventuella stod vi har, men jag menar, den kan ju fungera bra aven omvi sitter och gor allting for hand ocksa. Sa att det beror ju mer pa hur man malsatter den,men sattet vi gor det pa och de som gor det, och de forutsattningar de har for att faktisktgora ett bra jobb, tror jag paverkar.

Finns det nagra egenskaper hos formagan som paverkar hur den mar?

Ja, det ar dar jag har lite svart att veta vad det skulle vara, ar inte elementen delar avformagan, eller? Ar inte processerna och resurserna och IT-stoden en del av sjalva formagan?

Jo, du kan nog se det pa det sattet. Annars kan man se det mer som att elementen arlankade till och ihopkopplade med formagan, men inte en del av den. Men det ar okej attinte kunna svara ocksa.

Ja, jag tycker det ar svart, och jag kanner att jag kan inte uttala mig om nat jag inte forstar.

Elementen som kan paverka formagan, har de nagra specifika egenskaper som paverkar den?Finns det nagra specifika, som till exempel upptid for system?

Ja, jag vet inte om styrning ar ett element, men jag tror ju att det ar valdigt viktigt att, ja,men, design och styrning av elementen maste ju vara viktig. Du kan ju stoppa in varldensbasta IT-stod och jattekompetenta manniskor men inte fa ut nanting anda darfor att duinte har definierat, sa nanstans kraver man ju, behover man ju styrning, och uppfoljning, avformagor ocksa, tror jag. Aven om jag tanker process sa tror jag att det gar att applicerapa formagor ocksa. Men det ar ju det har att du maste veta vad du vill ha ut, aterigen, dumaste ju ha nan typ av mal eller onskvart resultat, annars har du ju ingen aning om ifalldet fungerar bra eller inte.

Respondent 6 - answers sent via mail

Hur ser man om en formaga mar/fungerar bra eller inte?

Fanns initialt ”id-kort” framtagna per formaga dar det framgick. Nu pagar arbete medatt strukturera om formagekartan och jag vet inte om de hunnit till den delen annu.

Vad tror du paverkar en formagas valmaende mest?

Upptid for systemen hanger ihop med ”IT-formaga” pa en mer detaljerad niva sa dar ar detval viktigt. . . Om man ser pa en formaga ur ett affars- och verksamhetsperspektiv (utifranmalen kring nojd kund och lonsamhet) sa ar det ett sammanlagt varde utifran hur viktigformagan ar for affaren/verksamheten samt hur prestandan pa den ar. Dar kan vardet ib-land dras ner pga for langa ledtider, felaktiga resultat, otilrackliga resurser mm. Baserat pahur viktig formagan ar viktas de olika bristerna da olika hogt.

Finns det nagra inneboende egenskaper hos formagan som paverkar dess valmaende?

91

Tror jag berort detta i svaret ovan. . .

Av de elementen som ar kopplade till formagan, vilka tycker du paverkar formagan mest?

Tror jag berort detta i svaret ovan. . .

Vilka egenskaper hos dessa element tycker du paverkar vilka egenskaper hos formagan?

Har inte tillracklig detaljkunskap pa den tekniska nivan. . .

Respondent 7

Hur kan man se om en formaga mar bra eller inte? Vad avgor hur den mar?

Ja, men man kan ju hitta matetal, och mata formagan. Ibland, det varsta scenariot arval att man i verksamheten inte mater, och da vet man ju inte om formagan. Och da tittarman snarare pa vad det kostar i organisationen att driva en verksamhet. Det kanske inte arsa bra matetal, utan kanske snarare hitta effektiva KPIer som visar pa, liksom, vilka malman har, sa man satter malen pa ratt niva, och hela tiden har en forbattringsambition.

Finns det nagor, tex nagra KPIer, som paverkar en formaga mer an andra?

Hur menar du?

Kan du komma pa nagra KPIer eller liknande som du tror paverkar formagan och somskulle vara bra att mata for att se om den mar bra eller inte?

Jag kan, om du ar ute efter exempel, liksom, i konkreta verkligheten..

Om du har nagra exempel, sa absolut.

Ja, till exempel merforsaljning i forsaljningskanalerna. En formaga kring, sag att vi haren formaga i forsaljning, och sen en underformaga som heter merforsaljning, dar kan detvara bristfalligt, sa att i vissa kanaler har man inte nagon malsattningar kring merforsaljning,men i en annan kanal kanske man har det. Och da kan ju det bero pa att, dels kan det varanaturligt sa att man i den har kanalen inte ar effektiv nar man forsoker salja, kunden villinte. Men det kan ocksa vara sa som det vi upptacker har, vi har ett projekt i Folksam,dar vi inte har nagra verktyg for att salja, for vi ser inte kundens helhetsengagemang. Ochda vet vi ju inte vad vi ska erbjuda heller. Och da har man inte satt upp mal dar, i den,i det har exemplet, att just i den har kanalen sa har vi inte saljmal pa de har delarna da,det galler vissa produkter da. Och det ar brister i systemstoden helt enkelt. Det ar barasant som jag stott pa har, men det ar ju manga andra, jag ar ju mycket saljinriktad somarkitekt, och jobbar mycket med forsaljning och marknadsforing, mycket digital forsaljning,dar mater man ju, det finns specifika matvarden som man mater pa. Och da vet jag intehur det ar just har pa Folksam, sa jag ska inte ta de exemplena, for jag har inte jobbat inomdigital utveckling har.

Tror du att det finns nagra egenskaper hos formagan som paverkar dess valmaende?

Jag tror det ar snarare sa att det ar de som ar kopplade till formagan, darfor att formagani sig ar mer en abstraktionsrubrik. For mig ar det sa i alla fall, att det ar snarare man fartitta pa ”Vad ar det i formagan som..”, utan jag vill snarare harrora mig valdigt strategiskteller hogt uppe nar jag pratar formagor. Och sen nar man gar in i praktiken och analyserar

92

som arkitekt, da tittar man ju verkligen pa ”ar det organisation, eller roll, eller process,logisk arkitektur, eller, vad ar det for nanting?”.

Av elementen kopplade till formagan, tror du att nagra paverkar formagans valmaende meran andra?

Ja, styrmodellen, tror jag. Darfor att styrmodellen spiller over pa de andra delarna, hur dusatter upp din organisation, hur du mater formagan, hur du kravstaller mot IT for nya stod,det tycker jag nog ar, det ar nog liksom det som gar, i mitt huvud direkt sa har, det ar nogdet som gar forst.

Finns det nagra egenskaper hos dessa element du tror paverkar formagan mer an andra?Till exempel upptid for ett IT-system.

Ja, jag tror att det ar mycket kring, lite egenskaper for processen da, eller fordjupningar avprocesser, dar man gor dubbla, man gor upprepade, dubbla aktiviteter. Du har ett manuelltarbetssatt att koordinera, till exempel, mellan olika system, eller olika silos, och det blirmerarbete, och det ar valdigt ineffektivt. Sa att du har inte automatiserade floden, sa attnar du gor en sak, da har du transparens ut i applikationer och system, du behover baragora en gang eller sa gar det med automatik. Har i var moderniseringsresa sa innebar det juatt du gor massa saker flera ganger, du har dubblerade informationsmodeller i olika system,sa att tolkningar, koordineringar, det tror jag. Valmaende, sen i ovrigt, ja, men tolkningar,att man har olika informationsmodeller i formagan beroende pa att man har historik narman har utvecklat parallella IT-landskap for olika produktomraden till exempel, det, ja.

Nagot att tillagga?

Nej, jag tror att det var det. Ha greppet om formagan, om du vet innehallet i den. For jagtror att du, ibland beskriver man formagan men man missar halva innehallet for att man arinriktad pa ”ja, men nu jobbar jag med det har initiativet” att det blir lite for langt ner iorganisationen, man jobbar pa projektniva med en formaga, da vill man bara scopa in dethar, ja, men hela formagan da? Om du konsoliderar allting som ar i det omradet, sa kanskedet blir ett annat perspektiv pa hur bra den mar. Just det har att man jobbar silos, dettanker man inte alltid pa, det ar viktigt som arkitekt att just formagan generaliserar ochkonsoliderar helheten.

Respondent 8

Could not be reached for a second interview.

Respondent 9

Could not be reached for a second interview.

Respondent 10

Hur ser man om en formaga mar bra eller inte?

Kan man se om en process mar bra, eller nanting annat? Det vet inte jag. Men jag kaninbilla mig att, som med mycket annat, for att veta nanting om det sa maste man mata, nanform utav framsteg eller progress, utifran KPIer, beroende pa vad det ar man vill uppna.Det ar det enda sattet tror jag. Det andra ar den har typen av intervjuer, men de tyckerjag inte du ska lita pa. Men mata, alltsa, inforandet av formagor, nar man har infort dem,hur de mar, det borde ju ga, tycker jag, teoretiskt i alla fall.

93

Finns det nagot du tror paverkar hur bra en formaga mar eller fungerar mer an nagot annat?

Alltsa, det har med formagor, det har vi ju framfor oss, det vill saga vi pratar om ettforandringsarbete. Jag tanker sa har, nar man ska driva in nanting, det ar liksom i enutvecklingsfas da, da maste man utga fran det har med vilken mognadsgrad vi har da, ochvi ar ju bara i borjan dar. Sa en grej som paverkar valdigt mycket ar vilken acceptans vihar for formagesynsattet. For har vi inte det sa kan vi inte arbeta med formagor. Och detar ungefar dar vi ar just nu. Sen nar man har infort det sa ar det en annan sak da. Jag vetinte om det var ett svar pa fragan, men det ar liksom en forutsattning for att en formagaska kunna existera och ma bra. Sa ser jag pa det.

Kan en formaga ha nagra inneboende egenskaper som paverkar hur den mar?

Sakert, men det ar ingenting jag kommer att tanka pa.

Ar det nagra av elementen som du tror paverkar hur formagan mar eller fungerar meran nagra andra?

Kan du repetera snabbt vilka det var?

Absolut. Applikation, som ar stodjande. Information. Input, IT-stod. Kompetens. Kost-nad. KPI. Krav, lag policy. Organisation. Output. Process. Resurs. Risk. System. Tjanst.Vardetrad.

Det var svart. Men som paverkar mer?

Precis. Ar det nagra du kanner sticker ut och paverkar mer hur formagan mar ellerfungerar?

Ja, Organisation, och med det menar jag tydlighet i ansvar i organisationen, till exempelmellan funktion, process, och formaga. Och jag tror att det ar valdigt svart att astadkommadet, sa jag tror ocksa att just det har med mal och matetal, om man kan borja mata paformagan. Sa Organisation och Matetal, att fa det att lira ihop for att utveckla och foljaupp formagan, hur den mar eller progressen i den, det tror jag ar viktigt.

Finns det nagra egenskaper hos elementen du tror paverkar mer? Exempelvis kanske up-ptid for ett system.

Det ar ju en komplex organisation, och formagan vill jag ju se som att den skar igenomorganisationen och det vi gor, for att uppna det som ar viktigt, det vill saga vad. Och datror jag att det ar en utmaning. Och nu sa jag matetal, KPIer, da tror jag att man far tankatill, sa att de KPIer som man satter, dels att man satter dem ratt, och sen att vi utveck-lar formagan att folja upp det. Det ar latt att man utvecklar nagonting, i det har falletformagor, och sen lagger man mycket energi pa det, och sen utvecklar man ett matsystem,och sen rasar det mellan fingrarna for att man orkar inte halla i, orkar inte folja upp. Manmaste ha ett, for det har ar svart, om man ska skara ut formagan, fa acceptans for det,och sen mata och folja upp sa vi nar de resultat vi vill. Da tror jag vi maste verkligen hatryck i den fragan och acceptans fran hogsta ledningen, och lyckas koppla till organisationsom ska utfora da nagonting, sa vi nar det vi ska mata. Det tror jag ar valdigt viktigt, attman tanker till dar. Det far inte vara heller ett teoretiskt ramverk, for det ar latt, som duintervjuar mig nu, sa blir det ju valdigt mycket mer teori, utan det maste vara nagontingsom organisationen kan hantera, utifran den mognadstrappa dar vi star just nu, dar vi ar

94

ganska langt ner. Sa man far inte bygga ett teoretiskt ramverk som vi inte kan ra pa heltenkelt, vare sig ledningen eller organisationen da. Jag tror pa att mata, jag tror att vi mastetydliggora relationen mot organisationen som ska gor nanting kring det har, det tror jag arviktigt.

Respondent 11

Hur tycker du att man kan se om en formaga mar bra eller inte?

Oj. Det var ju en svar fraga.

Kanner du att du inte kan svara far du saga det ocksa.

Jo, nej, men nat svar maste jag ju kunna ha, eller en fundering. Det finns val olika satt,kanns det som. Och att det kanske ar nagon form av sammanvavd bild som ger svaret.For, alltsa, dels sa kan man ju nanstans sakert mata, beroende pa vad det ar for formaga vipratar om, men liksom, ”Hur manga, vad det nu ar man hanterar, klarar vi av att hanteraper tidsenhet?”. Och ar det nanstans i paritet med vad man har som mal eller som bran-schen gor eller sa dar, sa kan man ju tycka att, ja, da mar den ju bra pa ett visst satt. Mensen maste man ju fa in, de som jobbar, med den har formagan, kanske ar frustrerade overnanting. Och det kan vara olika saker, systemstod eller att det ar nat knasigt i processen,eller sa dar. Sa, jag tror att det ar svart att se, liksom, pa en gang, ”Den har formaganmar inte bra”, jag tror man maste dela upp det i liksom, nan form av, process, organisation,system, kanske nat mer, och liksom forsoka forsta, ar allt gront, sa kanske formagan marvaldigt bra. Sen kan det saker vara nat som ar rott, men det mar anda nastan bra forvi klarar av det genom en heroisk insats, liksom. Da kan man ju fundera pa vad som arviktigast, liksom. For levererar man efter det man borde kunna gora sa kan man anda sagaatt den mar ganska bra. Det ar ett svavande svar, men ja.

Finns det nagot som paverkar en formagas valmaende mer an annat?

Ja, jag tror att.. Vilken svar fraga. Jag tror nog mycket, alltsa, hur, det ar inte denenda sanningen, men, de som, sa att saga, utfor arbetet, hur de mar och tycker att detfungerar tror jag ar ganska centralt. Sen sa kan ju de vara inkorda pa, liksom, sneda spar,och liksom, det gar att gora, nar man liksom borjar skrapa pa ytan sa inser man att ”Denhar formagan mar inte sa bra”, aven fast de ar jattenojda for ‘’det flyter ju jattefint och bra”.Me a andra sidan, ar det nat som inte funkar sa kommer ju de vara, liksom, da kommer detju markas. Men sen sa tror jag val, det tror jag ar en sak, och sen sa tror jag val att, alltsa,stod, om det ar, liksom, IT i form av hardvara eller mjukvara, eller om det ar nat annat, ja,men, liksom, ja, stod i det arbetet, det tror jag ocksa ar valdigt viktigt.

Tror du att det finns nagra egenskaper hos formagan som paverkar hur den mar?

Kan du ge nat exempel pa..?

Nja, vi kollade ju pa det har med element som kan paverka, element som ar kopplade utifran,sa det har ar mer om hur ni tycker att formagan har nagra egenskaper som ar dess egnasnarare an kopplade till den, som paverkar hur den mar.

Jag forsoker ocksa fundera pa vad.. Spontant sa skulle jag ju saga, eller tycka, jag kommerinte pa nat bra.

Det ar ocksa ett svar.

95

For det ar val lite min askadning, att det ar olika typer av komponenter som gor att mangor nagonting, och det ar de tillsammans som bildar den har formagan.

Ar det nagra av elementen vi pratat om tidigare som du tror paverkar formagan och dessvalmaende mer an andra?

Vad blir skillnaden dar mot forrforra fragan?

Den var mer en chans for er att prata allmant, nu ar det mer specifikt vilka av elementendet kan rora sig om.

Har du listan over vilka jag klickade som relevanta?

Absolut. Applikation, dels stodjande och som stods.

Ja, det tror jag ju. Fragan var om det var nagon som var extra viktig?

Ja, precis, om det ar nagon som paverkar mer an andra. Alla kanske paverkar pa nagot satteftersom de ar kopplade till formagan, men vissa kanske ar mer avgorande for formagansvalmaende.

Det kanns ju som att det beror pa vad det ar for formaga man pratar om. Men App-likation tror jag ar centralt, i de flesta. Det ar fa formagor, finns sakert en del, men de flestahar ju nagon form av systemstod.

Information?

Ja, det tror jag gar at skogen om man inte har bra information.

IT-stod?

Hanger ihop med Applikation.

Kostnad och KPIer?

Och ar det alltsa kostnad for att utfora formagan?

De kostnader som ar associerade med formagan, ja.

Den tycker jag ju da kanske inte ar lika viktig ur ett valmaendeperspektiv, for jag troratt formagan kan ma jattebra, aven fast det kostar for mycket pengar.

KPIer?

Ja, alltsa, dar handlar det ju mer om att forsta om den mar bra, men jag tror, det arju inte nodvandigtvis sa att den mar daligt, aven om vi inte kan pavisa att den mar bra. Sanej. Daremot sa tror jag den ar viktig for att kunna fintrimma formagor, men det ar intecentralt for att den ska kunna ma bra.

Krav, och specialfallen Lag, Regel, Policy?

Nej, den tror jag ocksa ar lite sa dar, det ar centralt om det visar sig att formagan intemar bra, for da maste man gora nanting. Men det kan ju vara sa att den funkar jattebra

96

aven fast vi har jattedalig koll pa kraven, darfor att de manniskor som haller pa med dethar faktiskt vet vad de gor.

Organisation?

Ja, det ar ju viktigt, av samma anledningar som jag sa dar i borjan, jag tror att de som gordet behover tycka att det kanns bra.

Process?

Ja, den tror jag ar viktig.

Risk?

Ja, vad menar vi dar, egentligen. Nej, den tror jag, alltsa, det kanns ocksa som en sanhar, mer kontroll. Det har egentligen ingenting med hur bra den mar, utan det handlar juom hur vi skoter den.

System?

Hanger ihop med Applikation och IT-stod.

Tjanst?

Nej, den kanns inte som att den riktigt passar in.

Vardetradet?

Ja, alltsa, om det ar sa att man inte kan mappa en del av varedtradet till formagan, daborde man ju ifragasatta varfor vi har den formagan, givet att vardetradet ar komplett. Senkan ju formagan ma valdigt bra, aven om det ar en redundant formaga. Sa ur det perspek-tivet tycker jag inte den ar viktig. Det arju lite som KPIerna, alltsa den behovs inte for attformagan mar bra, daremot ar det viktigt att forsta hur den passar in i vart vardeskapande.

Har nagra av elementen egenskaper som paverkar formagans valmaende? Exempelvis kanskeupptiden hos ett system.

Ja, alltsa, det tror jag. Mycket just kring, om man knyter tillbaka till den utforande organ-isationens val och ve, ar ju ofta tatt sammankopplat med, alltsa, att sytemstod eller stodfungerar friktionsfritt. Att det ar uppe, att det ar snabba svarstider, att man inte far felmed-delanden man inte borde fa och liksom skapar irritation i det dar, utan att man forvantarsig att fa ett stod, och det far jag. Sa, alltsa, den typen av tekniska forutsattningar, sominte har med, liksom, det mer specifika formagestodet att gora utan snarare vad alla tyckerar hygienfaktorer, det tror jag har valdigt stor paverkan.

Respondent 12

Hur kan man se om en formaga mar bra eller inte?

Da maste man ju veta var den finns implementerad, alltsa vilka processer. Och processernakan man ju alltid mata och forsta hur effektiva de ar da. Sa pa sa satt sa ser du ju omformagan mar bra eller daligt.

Vad tror du paverkar en formagas valmaende mest?

97

Jag tror att det ar en definition ”Vad ar en valmaende formaga?” som man maste fun-dera pa. Betyder det att vi kan utfora den? Betyder det att den ar effektiv? Beroende pavad du lagger for dimension i, alltsa, och det ar ju fortfarande, om vi gor en formaga somvi inte har ett enda systemstod for, mar den daligt da? Det behover den ju inte gora.

Har formagan nagra egenskaper som kan paverka hur den mar? Som inte ar element kop-plade till den utan egenskaper hos den.

Ja, alltsa, en formaga. Ja, det beror ju pa vad man menar med element kopplade. Tankerdu pa regelverk, ar det ett element som kopplas till?

Ja, det skulle jag saga.

Ja, for beroende pa hur, ja, yttre krav och inre krav pa en formaga, sa ar ju det hurlatt den ar att applicera, skulle jag vilja saga. Och da ar det val kanske, det kan ju varalagkrav det kan vara interna matgrejer som gor att den ar helt hopplos.

Elementen kopplade till formagan, ar det nagra som paverkar formagans valmaende meran andra? Jag kan lasa upp dem om du vill.

Ja tack. Har du gjort nan definition pa vad det betyder ”att ma bra”?

Nej, det ar det jag fragar er nu i de har intervjuerna.

Ja, for dels sa kan man ju saga, det ar ju liksom, hur val forstar vi hur den ska funka,hur val har vi forberedda processer for den, bade digitala och manuella. Det ar, om mansager, att den mar bra. Ja, vem ar det som bedomer att den mar bra? Kanner vi att viforstar den eller att vi kan utfora den, mar den bra da? Alltsa, man skulle nog behova haen liten definition pa ”att ma bra” tror jag. For det kan vara sa har ”vet jag vad jag skagora, ja da mar den bra”, ”vet jag hur jag ska gora det, ja da mar den annu battre”. ”Harjag inget systemstod utan gor allt manuellt, da mar den ganska daligt”, eller? Det ar tyckeoch smak, sa jag tror att man maste tala om litegrann vad man menar med ”att ma bra”,eller att det kan vara olika grader av bra da.

Okej. Nu, vill du ha alla element eller de du kryssade for som relevanta?

Las upp alla. For nu var fragan vilka som paverkade?

Ja, om det ar nagra som du tycker paverkar formagans valmaende mer an andra. App-likation, stodjande och som stods. Handelse. Information. Input. IT-stod. Kompetens.Kostnad och KPI. Krav, och specialfallen Lag, Regel, och Policy. Organisation. Output.Process. Resurs: Risk. Roll, System. Tjanst. Vardetrad.

Vilka som far den att ma bra?

Ja, om det ar nagra du tycker sticker ut och paverkar mer an andra.

Ja, det ar regler, da, det ar ju en , och processer ar en. De tva skulle jag ju highlighta.

Har elementen nagra egenskaper som paverkar formagan valmaende? Tex kanske upptidhos ett system.

98

Altsa, det ar ju, kompetens och kunskap om formagan, det ar ju det som ar A och O.Om vi inte har kompetens runt vad det har innebar eller hur man ska gora det har, vad detnu kan vara for nagonting, da mar man ju riktigt illa.

Nagot att tillagga?

Det som man bor tanka pa ar att formagan i sig, den bor ju i ett kontext. Sa det arsvart att saga, ja, ”halla”. Utan det ar ju allting, jag menar, har du ingen, for att utforadet har, din formaga, vad du behover gora, da maste du ju ha bade resurser och processeroch eventuellt systemstod da, och sen beror det ju pa hur komplex den dar ar, pa vilket sattdu maste ha stod. Sa om man skulle ga och fraga en verksamhet sa har ”Var gor det onthos er?”, ja da kommer de saga ”Det gor ont har, for vi vet inte hur vi ska gora”, eller ”Detgor ont har, for det tar sa jadra lang tid’, sa det ar ju det, darfor tror jag att det ar bra omman forsoker definiera ”Hur mar en formaga?”, ja, ur vilket perspektiv?

99