Modelling Business Capabilities With Enterprise

Transcript

Modelling Business Capabilities with Enterprise Architecture A Case Study at a Swedish Pension Managing Company ¨ SOFIA BERGSTROM Master’s Degree Project Stockholm, Sweden September 2015 TRITA-EE 2015:69 Modelling Business Capabilities with Enterprise Architecture A Case Study at a Swedish Pension Managing Company Sofia Bergstr¨om 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 enterprise architecture, and investigates how the concept is used within the Swedish pension managing company Folksam. Based on interviews with stakeholders an enterprise architecture metamodel centred on the business capability is constructed. The meta-model is then edited and revised according to a questionnaire aimed at removing irrelevant elements, and a second set of interviews discussing a capability’s health status and well being. This second set of interviews 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 its core. It consists of the Capability element, with two attributes, surrounded by nine other elements connected by eleven relations in total. Sammanfattning: Detta examensarbete unders¨oker hur verksamhetsf¨orm˚ agor anv¨ands inom enterprisearkitektur, och vidare hur f¨orm˚ age-konceptet anv¨ands p˚ a det svenska pensionsf¨ oretaget Folksam. Baserat p˚ a intervjuer med intressenter skapas en metamodell med verksamhetsf¨ orm˚ agan i centrum. Metamodellen revideras och ¨andras sedan enligt ett fr˚ ageformul¨ ar vars m˚ al var att ta bort ej relevanta element, och enligt en andra omg˚ ang intervjuer d¨ ar en f¨ orm˚ agas h¨ alsa diskuteras. Denna andra omg˚ ang intervjuer resulterade i att element som inte p˚ averkade f¨ orm˚ agans h¨ alsa togs bort. Den slutgiltiga metamodellen har verksamhetsf¨ orm˚ agan och dess h¨ alsostatus i fokus. Den best˚ ar av f¨orm˚ age-elementet, med tv˚ a attribut, omg¨ ardat 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 1.1 Folksam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5 2 MAIN OBJECTIVE 2.1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Delimitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6 6 3 THEORY 3.1 Enterprise Architecture . . . . . . . . . . . . . 3.2 Enterprise Architecture Modelling . . . . . . . 3.3 Business Capabilities . . . . . . . . . . . . . . . 3.4 Business Capabilities and Modelling within this . . . . . . . . . . . . . . . . . . Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 . 7 . 10 . 11 . 15 4 METHOD 4.1 Step 1 4.2 Step 2 4.3 Step 3 4.4 Step 4 - Initial Interviews . . . . Meta-Model Creation . . Meta-Model Evaluation Meta-Model Editing and . . . . . . . . . . . . . . . . . . . . . Finalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 16 18 18 19 5 DATA 5.1 Step 5.2 Step 5.3 Step 5.4 Step Initial Interviews . . . . Meta-Model Creation . . Meta-Model Evaluation Meta-Model Editing and . . . . . . . . . . . . . . . . . . . . . Finalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 20 24 26 30 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 32 32 33 33 33 34 34 34 35 35 35 7 ANALYSIS 7.1 Elements Relevant to Connect to the Capability 7.2 Why Connect Capabilities to Other Elements? . 7.3 Affecting or affected? . . . . . . . . . . . . . . . . 7.4 A Healthy Capability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 36 44 44 45 1 2 3 4 - 6 RESULTS 6.1 Element: Capability . . 6.2 Element: Application . . 6.3 Element: Competence . 6.4 Element: Information . 6.5 Element: KPI . . . . . . 6.6 Element: Organisation . 6.7 Element: Process . . . . 6.8 Element: Requirement . 6.9 Element: Resource . . . 6.10 Attribute: Goal . . . . . 6.11 Attribute: Health Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 DISCUSSION 46 8.1 Interview Difficulties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 8.2 Definition Differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 9 CONCLUSIONS 47 9.1 Future Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 3 A Interviews 50 A.1 Interview set 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 A.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 a company can be to use the Who?, How?, or What? views. By asking Who?, one might end up 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’s processes or production chains, showing how value is produced at the company. These are two common ways to describe companies, ways that have been used for many years and probably will be used for years to come. To answer the question What?, companies have since the early 2000’s started using a 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 ”Vendor Management” and ”Manage Product Acquisition”, which in turn could be decomposed even further. This report looks at the concept of business capabilities and its use within the Swedish insurance company Folksam. A study is carried out concerning what capabilities are used for at Folksam today as well as what they could be used for in the future, and an enterprise architecture 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. The company was founded in 1908, and is now insuring every second person in Sweden. Folksam is a mutual company, which means that the customers own the company, and any profit goes 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 property and 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 metamodel with regards both to the business capabilities within Folksam, and the different departmental needs within the company. The meta-model should also encompass the health status 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 expectations and fulfilling the requirements of identified stakeholders. 2. Modify the meta-model so that it encompasses the stakeholders’ views on business capability health status. Research was conducted through literature studies, interviews with stakeholders, and the creation 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 business capabilities. As a part of the process, this report looked at what views the different stakeholders have of the business capability concept. They were asked how they would like to use the business capabilities, what they might have used them for before, and what they would like to be able to connect and relate them to in order to achieve these applications. The aim was to create a meta-model that can be of use at Folksam when creating this map, and to provide a perspective from outside the company. 2.2 Delimitations To be able to participate in the study, the Enterprise Architect Team Leader deemed it necessary that, the respondents had to have some previous insight into the work with capabilities, since Folksam are still working with how to use capabilities. It was therefore her task to find suitable stakeholders to interview for this study. 6 3 3.1 THEORY 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 company strategies 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 transformations within a company, striving to provide a common ground for it for all the company’s stakeholders [23]. In the book Enterprise Architecture: Modelling, Communication and Analysis Marc Lankhorst et al. compare the aims of enterprise architecture to the practises of architecture 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 efficient communication [20]. In a similar way, the ISO 42010:2011 standard pertains to systems and software engineering, and describes architecture in that context as ”fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution” [1]. In other words, when it comes to buildings and their architecture, most people know how to correlate a blueprint or a floor plan to an 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 mapping companies 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, developed by the Open Group. It contains methods and tools for creating an enterprise architecture through an Architecture Development Method consisting of eight basic phases enumerated A to H (seen below). A Architecture Vision Phase defines the scope of the initiative, identifies stakeholders and other information needed to proceed with the development. B Business Architecture Phase describes the Business Architecture needed to support the Architecture Vision. C Information Systems Architecture Phase describes the Information Systems Architecture needed to support the Architecture Vision. D Technology Architecture Phase describes the Technology Architecture needed to support the Architecture Vision. E Opportunities and Solutions Phase conducts initial planning and identifies delivery vehicles (such as projects or programs) for the decided architecture. F Migration Planning Phase describes how to move from current Baseline Architecture to future Target Architecture and finalises an Implementation and Migration Plan. G Implementation Governance Phase provides an architectural oversight of the implementation. H Architecture Change Management Phase establishes procedures for changing to the new architecture. When reaching the last step the process is repeated to make sure that the enterprise architecture continues to be as up-to-date as possible. Connected to all these steps is the Requirements Management Phase that examines the process of creating architecture requirements throughout the architecture development. There is also a Preliminary Phase that describes the preparation needed to be able to create an enterprise architecture. The image 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 column represents a question and each row a perspective of a certain kind of employee. The official matrix can be seen in figure 2, and a simplified version can be seen in figure 3. The column labels, the questions, are ”What?”, ”How?”, ”Where?”, ”Who?”, ”When?”, and ”Why?”. These are, according to Zachman, the primitive interrogatives and therefore the fundamentals of communication. The row labels, the perspectives, are the perspectives of Executives, Business Management, Architects, Engineers, Technicians, and an overall Enterprise perspective. The 36 cells that make up the matrix would then be the different views 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, as well 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 to external customers, as well as how they are realised within the enterprise. • The Application layer, in the middle, shows the applications that support e.g. the different services and processes in the business layer. • The Technology layer, at the bottom, models the infrastructure that is needed to run the applications in the application layer. The ArchiMate language has been designed to be as small as possible while still being usable in most cases of enterprise architecture modelling. The language defines three core types of elements, as described below, which can be compared to the three grammatical parts of a regular sentence [4]. • Active structure elements are entities that can perform behaviour, compared to the subject in a sentence. • Behaviour elements is a unit of activity that is performed by active structure elements, compared to the predicate in a sentence. • Passive structure elements are objects on which behaviour is performed, compared to the object in a sentence. UML, the Unified Modelling Language, is another language commonly used in enterprise architecture modelling. It is developed and maintained by OMG, the Object Management Group. The UML language also consists of three model element categories, albeit different ones from those in ArchiMate. The UML element categories are classifiers (describing a set of objects), events (describing a set of occurrences), and behaviours (describing a set of 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), developed and maintained by the British Ministry of Defence. It consists of ”views” divided into 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 different StVs 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 subviews, 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 actual solution could look like. The Service Oriented Viewpoint provides seven views and is used to 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 requirements for a system or solution. The Acquisition Viewpoint consists of two views that describe dependencies between projects as well as the ownership and structure of them. The Technical Standards Viewpoint is made up of two views and describes e.g. standards and policies (both technical 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 and reference 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 Architect, and is developed by Sparx Systems1 . This tool is based on UML 2.5, and supports several different languages and frameworks, such as ArchiMate, TOGAF, and the Zachman framework [7]. The models created as a part of this research are created in Sparx Enterprise Architect. 3.3 Business Capabilities In Cutter Consortium’s Executive Report ”The Business Capability Map”, the business capabilities are described as the ”Rosetta stone of Business/IT alignment” [26]. Their view corresponds with Folksam’s view of business capabilities, and Cutter Consortium’s ten 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, business process, 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’s ecosystem [26]. The first principle is a concise way to explain what a business capability is: what a company 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 management”, the difference between capabilities and processes or value streams is enhanced. The 1 http://www.sparxsystems.com/ 11 third principle makes it easier for people to understand a business capability map, even if they do not know many technical terms. Principle number four explains that capabilities rarely change within a company. How they are deployed might change, if for example a capability is automated, but entirely new capabilities usually only comes with changes to the business strategy or model. The fifth and sixth principles clarifies that capabilities exists only once on a map, even if it is realised at several places throughout the company, and that a 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 for the company. Principle number seven sets the capability apart from other concepts such as a process, line of business, or value stream, even if there can be similarities and correspondences these concepts are different abstractions of a business. The eighth principle explains that capabilities align directly to service-oriented architecture implementations, even if they may be manual. Principle number nine differs between an IT capability (a capability that the IT department has) and an automated capability (a capability implemented in an application). The tenth and last principle states that while a single capability might be good for planning and discussion, capabilities contribute the most to a company when mapped in an overall picture of the business [26]. Another explanation of what a capability is comes from the article Capability-based Business Model Transformation, where the authors describe a capability as ”the ability of an organisation to manage its resources to accomplish a task”, and says that an organisation exhibits a capability if it repeatedly can apply it [17]. [10] defines capability as ”the ability to employ resources to achieve some goal”, which is closely 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 specification of the enterprise’s ability”, and adds that they do not change over time and as such can 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 working with enterprise architecture [27],[12],[24], and who have also suggested that in a meta-model the 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 that an organisation, person or system possesses”. Two examples of meta-models can be seen in figure 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 ability to 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 not the same thing as a Business Function, but that a capability encompasses many other elements such as Business Functions, Roles, Policies and Business Services. He connects the 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 ArchiMate as an aggregate of other objects from its core meta-model, and explains capability as ”the ability to produce results”. His suggested meta-model can be seen to the right in figure 4, 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 an Actor. Working with Business Capabilities In [17] a procedure for figuring out an organisation’s capabilities is described, where the authors suggest to start with the organisation’s ”main capability”, the capability that provides the organisation with customers. The resources needed for this main capability should then 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 is reached. This process is similar to the one in [26], but differs since it not only uses the business capabilities but includes resources as a complement as well. In [26] it is said that a decomposition down to three levels of capabilities is the most common way to work, and that using more than six levels is very uncommon but can be important when mapping business to IT architecture. When it comes to the more widely used enterprise architecture frameworks and modelling languages, the implementations of capabilities differ. In ArchiMate 2.12 there is no exact implementation of the capability, however they suggest that their business processes or 2 http://www.opengroup.org/subjectareas/enterprise/archimate 13 functions may be used instead [4]. There, the business process/function is connected to four entities beside itself: the business role, object, service, and event [4]. In [19], an extension to ArchiMate is proposed, with the capability connected to resources, requirements, and behavioural elements. This extension introduces resources and competences to ArchiMate, besides capabilities, and in [10] this extension is further analysed and named the Business Strategy and Valuation Concepts extension. In [19] the extension was used to align business strategy, enterprise architecture, and portfolio management. The Swedish enterprise architecture consultancy firm IRM3 wrote about the Zachman framework in 2010, stating that even though the framework for a long time has been seen as the ”holy grail” when it comes to enterprise architecture, it is only one of several functioning models. It has its drawbacks, for example when it comes to modelling capabilities. When modelling a capability, it can be seen as a separate entity that can be analysed as an enterprise 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 IT strategy. 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 of advancements. To do this, they chose to start working with business capabilities, since they saw them as a way to plan strategies on a higher level, independently of what organisations or 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, despite 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 strategies within the area. • A synchronised way of analysing the scope of advancement initiatives. They stress that it is important that the business capabilities are organisationally independent, so that it is possible to govern, measure, and follow-up regardless of responsibilities for e.g. processes or functions [16]. Since 2014, the Risk Managers at Folksam has used the Level 1 capabilities to structure their semi-annual risk reports, to in an easy way be able to show the company executives how the risks are spread over the company [9]. Today, the capabilities are also used for portfolio planning, and the capabilities on Level 2 are used to identify dependencies between projects. At Folksam, they do not differ between ”Business Capabilities” and ”Capabilities”, and when starting the work with business capabilities, Folksam created something they called ”Capability cards”. These cards describe a capability and its implementation. They contain a description of the capability or area, and what goals, measurements, strategies, and business requirements are associated with it. They also describe its implementation, with processes, organisations, competences, and supplies of information. This card can also contain a rough estimate of how well the capability is working, shown by assigning it one of three colours: Red (Not working), Yellow (Improvements needed), or Greed (Working as it should) [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 3 http://www.irm.se/ 14 corporate capability map. In parallel with the research presented in this paper, a revision of the capability map at Folksam was carried out, and guidelines for how and when to use the capability concept were developed. A key part of these guidelines was to define a common capability 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 as is used at Folksam, and it is the one provided by the Cutter Consortium [26] described in section 3.3. The key principle is that a capability is what a company does. Since Folksam does not differ between ”Capabilities” and ”Business Capabilities”, this report will also use the words interchangeably. The meta-model created in this report is a draft, and implementation of the actual metamodel was not a part of this research. The model drafts were made in Sparx Enterprise Architect, using UML structural class diagrams. The elements discussed in this report were modelled 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-model The meta-model drafts were made as drawings only, to identify what different elements and relations were needed for the final version. The meta-model could then later be implemented in Sparx EA4 , the enterprise architecture tool used at Folksam. • The business capabilities Folksam started working with capabilities on an enterprise level about two years ago, developing a joint enterprise map. The Enterprise Architects have learnt a lot about the capabilities of the company and in which areas it could be relevant to use the business capability concept. Right now, they are revising their business capability map, and within the research in this paper, the capabilities were analysed on a more abstract and general level, which is why there was no need to delve deeper into the actual business capabilities at Folksam. • The stakeholders The main stakeholders of this research are the Enterprise Architects working with business capabilities at Folksam. These Enterprise Architects, and mainly the Enterprise Architect Team Leader, were consulted in the process of identifying other stakeholders that had some insight into the work with business capabilities. Some previous insight into the matter was needed, since the work with business capabilities within Folksam is still in progress and not everyone is affected by it as of today. • The expectations and requirements As of today, Folksam had already connected metrics to the business capabilities. To make the model complete they wished to survey what other features the stakeholders wanted to connect, and then implement this into a meta-model. This survey was done through interviews with the stakeholders. • The thoughts on capability health status Folksam 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 respondents were asked about their thoughts on the health status of a capability, and what could affect it. The data gathering was divided into several steps, focusing on interviews with the stakeholders at Folksam. These interviews were the basis for the meta-model of the business capability 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 identified with the help of the Enterprise Architect team leader at Folksam’s Enterprise Architecture Department. The stakeholders were asked about their attitude towards the business capability concept and the use of it. Would they like to use them and, if so, how? What would they 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 answers transcribed. 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 in Swedish. The transcribed answers are therefore in Swedish as well. However, summaries, 4 http://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. This procedure 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 part of the main objective, to create a meta-model for Folksam’s business capabilities, meeting the expectations and fulfilling the requirements set by the stakeholders In table 1 the questions are 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 knowledge and involvement in the work with business capabilities. These were mainly used for further analysis, for example to see if what elements a respondent wanted to connect to the capability differed with their background or their position. The last five questions concerned the business capability and what the respondent thought it could be used for, and how. These were mainly used to construct the meta-model. The question numbers Q1.1 to Q1.10 are used when referring to the different questions. The elements listed as suggestions in Q1.8 are selected from the literature presented in section 3.3 as elements that might be relevant for the respondents, but also might be difficult for 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. Q1.1 Q1.2 Question What is your position, and how long have you been working at Folksam? In short, what do you know about business capabilities? Possible answers Business architect, IT strategist, since 2010. Why is it asked? To see if later answers differ between positions or time employed. What a company does or other specifications from the Cutter Consortium list of principles. If they have worked with capabilities at Folksam. Time spans between some months and a couple of years. How do answers to later questions differ between people with different knowledge levels? (Will people with a more ”correct” view of what a capability is give answers that are more “correct”?) To see if they have familiarised themselves with the concept of business capabilities for a while, or if they have seen it for the first time recently. To see what manner it was introduced in, and what it was supposed to be used for, if anything. To see what capabilities have been used for and what is needed in the meta-model in order to show this. To learn what they want to use the capabilities for, and to get some ideas about what could be connected to the capability in the meta-model. Q1.3 For how long have you been working with (the concept of) business capabilities? Q1.4 How did you first come across the concept of business capabilities? Presented by architects, to use for analysis, in a project. Q1.5 Have you used business capabilities, and, if so, how? No, for analysis, in a project. Q1.6 What applications can you see for the business capabilities? For yourself/your department/the company/a project. Support when planning projects, identify flaws in process chain, manage external requirements. 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. Q1.7 Question To achieve this application, what elements would you like to be able to connect to a business capability? Possible answers Requirements, roles, projects, strategies. Q1.8 Which, of the following would you like to be able to connect to a business capability? Zero to all of these stated elements. Why is it asked? To find elements to connect to the capability in the metamodel, according to the respondent’s own suggestions, and to see if they match the elements from the literature. To find elements to connect to the meta-model, based on the literature. • Requirement • Resource • Role • Service • Event Q1.9 Q1.10 4.2 Why would you like to connect these specific elements, and when do you think it would be useful? How do you think the elements would affect the capability, or be affected by it, if changes occur? For easy structuring of projects, when testing compliance. Make it better/worse, increase/decrease capacity. Find out about the elements and attributes they could have, why they are useful, and what the relations to the capability could be called To help identify what the relations should be, and how the elements and relations should be structured. Step 2 - Meta-Model Creation With the aid of the answers from the first set of interviews, a meta-model draft was created. The meta-model was centred on the business capability. The elements added to the meta-model were the ones suggested and mentioned by the interview respondents. When a respondent described a relation between the capability and an element, that relation was added as well. If no such relation was described, a possible relation was found by searching the 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 for feedback. The respondents were sent a questionnaire via Google Forms5 where they were asked to mark all elements as relevant or not, for them in their own work. They also got another 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, and how 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 5 https://www.google.com/forms/about/ 18 it encompasses the stakeholders’ views on business capability health status. As with the previous 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 a business capability perform well or not, and how it could be affected by other elements. No. Question Q2.1 How can you tell if a capability is performing well or not? Possible answers Connected processes run smoothly, output is correct. Q2.2 What do you think affects the well being of a capability the most? Q2.3 What attributes of the capability affects the well being and performance of it the most? Q2.4 Which of the elements connected to the capability do you think affect its well being and performance the most? Q2.5 What attributes of these elements do you think affect the capability, and which attributes of the capability do you think they affect? Up time of supporting systems. 4.4 Information quality. Requirements, cesses. Why is it asked? Establishes respondents ”ideal capability”, if needed for future reference. Get a notion of which elements could be involved and connected. Find attributes of the capability that could be affected. Pro- To know which elements should be connected to the capability. Up time of service affects quality of capability information. Find out which attributes should connect element and capability. Step 4 - Meta-Model Editing and Finalisation To optimise the meta-model, all elements that had been marked as not relevant by all of the respondents were to be removed, since the goal of this project was to create a metamodel relevant to the respondents. Elements not mentioned or described as affecting the capability and its health status were also removed, since the meta-model should encompass the stakeholders’ views on capability health status. When this was done, the remaining elements and their connections to the capability were modelled according to the answers and 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 in the corresponding sections below. 5.1 Step 1 - Initial Interviews Seventeen people were approached about interviews by the Enterprise Architect Team Leader, and twelve agreed to participate. In table 3 the participants’ occupations can be found, as well as how long they have been working at Folksam, and when they first came across 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 worked at Folksam and when they started working with capabilities. Respondent ID Respondent 1 Respondent 2 Respondent 3 Respondent 4 Respondent 5 Respondent 6 Respondent 7 Respondent 8 Respondent 9 Respondent 10 Respondent 11 Respondent 12 Occupation Business Architect Business Architect Business Architect Risk Manager Risk Manager Business Developer Business Architect Business Developer Business Developer Governance Specialist IT Strategist Business Architect At Folksam since 2015 2002 2013 2013 2013 2001 2014 2000 2009 1979 2015 2003 Saw capabilities in 2010-2011 2013 Middle of 2013 2013 Middle of 2013 2012-2013 2000 2011 Middle of 2013 2010-2011 2015 2011-2012 When asked to describe what they knew about capabilities, in short (Q1.2), some of the respondents were more familiar with the definition of a capability than others. Respondents 2, 3, 4, 6, 8, 11, and 12 in some way stated that a capability was what a business does, not how 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 for everyone to understand. Respondents 3, 5, 7 and 10 had used capabilities when mapping a business and e.g. its projects, risks, requirements, and systems. Respondent 4 thought that 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 of projects 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 Enterprise Architect Team Leader at Folksam. Respondents 1 and 12 discovered capabilities at their previous workplaces, when trying to describe what the companies did, and respondent 11 got an introduction to capabilities along with the introduction to Folksam when they started working there. Respondent 2 felt that processes were an out-dated way of describing a company, and discovered that capabilities were more in line with what they needed, whereas respondent 7 found that capabilities were useful when setting requirements for a proposal. Respondent 9 was introduced to capabilities by a Business Developer colleague that had taken a course in enterprise architecture, and respondent 10 learnt it from the Enterprise Architects 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 to connect to the capability) were summarised in table 4 that was then used in the next step to 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 each element. 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 both questions Q1.7 and Q1.8. Respondent no. Application Competence Cost Distribution Channel Event* Goal Health Status Information Input/Output IT Support KPI Law/Rule/Policy Organisation Process Requirement* Resource* Risk Role* Screening Service* System Value Tree 1 2 3 4 5 6 x 7 x x x x x 8 9 10 11 12 x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x SUM 2 3 1 1 7 1 1 5 2 3 1 1 6 11 11 10 2 10 1 7 7 1 Regarding the elements, the respondents also got to answer why they wanted to connect the specific elements that they mentioned (Q1.9) and if they had any thoughts on if the elements affected the capability in some way, or if it was the other way around (Q1.10). The answers to these questions can be found in table 5. Table 5: The answers to the interview questions Why would you like to connect these elements, and when would it be useful? (Q1.9) and How do you think these elements would affect the capability, or be affected by it, when changes occur? (Q1.10). Resp. ID 1 2 3 Answer to Q1.9 Capabilities with these elements connected is one important piece of the puzzle when measuring change. To describe ”What kind of business are we running?”, and to see who is responsible for what. To get a structured view of the whole company. It feels like an approach that should actually manage to finish a company-wide map. 21 Answer to Q1.10 The elements support the capability, but they both affect each other. The elements support the capability, so rather that a good process contributes to a good capability, than the other way around. The elements affect the capability, at least in most cases. Table 5: The answers to the interview questions Why would you like to connect these elements, and when would it be useful? (Q1.9) and How do you think these elements would affect the capability, or be affected by it, when changes occur? (Q1.10). Resp. ID 4 5 6 7 8 9 10 Answer to Q1.9 When working with changes or when mapping the organisation. To find where there are risks and what they are associated with. Important when working with changes, or optimisation. When you are looking at the business development process, or are in need of moving certain parts of the business somewhere else. To be able to relate the capabilities to something, so that other people in the organisation do not deem them as too abstract. Useful in all sorts of resource and competence planning. Good when analysing requirements, and for projects. Hard to connect it to the actual enterprise at some points, though. To improve the ability to govern and control, through finding out which elements connect. 11 In general, it increases your understanding of the business and why it works or not. 12 To analyse. Knowing rules is needed when performing changes, so you know which capabilities they affect, for example. Answer to Q1.10 The elements affect the capability. The capability is a framework for the elements. More that the elements affect the capability, but the whole concept feels a bit abstract. It could go both ways, it depends on a lot of variables. Has no clear answer to the question. The capability consists of the elements, it is a container for everything else, to remove the need of getting overly complex. It could be both ways. When purchasing an IT solution, the capability is affected by the chosen solution. On the other hand, there are critical capabilities that affect whatever is inside them, such as company specific questions. The capability should be affected by other things, and it needs to adapt to what we want to do. If you control a capability by examining the connected elements, that capability controlling will affect the elements. It depends. There is probably an aspect of time or culture as well, which affects the other might depend on what was the point of origin, if it was the capability or e.g. a process. The capability does not change, but how it is implemented might. As long as you are not changing your business model, the other elements might change, but not the capability. From this first set of interviews information was also gathered on what the respondents have used the business capabilities for, and if they could see any other areas where they could 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 capabilities, and, if so, how?” (Q1.5) and ”What other applications can you see for the business capabilities?” (Q1.6). Resp. ID 1 2 3 4 5 6 7 8 9 10 Answer to Q1.5 To map different models to one single concept, for easier analysis, for quality assurance, and to ensure that projects have the right scope. To describe responsibilities within the Economics area. Also trying to describe ”How well is a capability working?” by assessing the status of elements connected to it. When analysing new projects or initiatives, looking at which capabilities will be affected. Also to compare projects and see how the affected capabilities differ. To describe the business without the need for process responsibility, and to structure a risk report. For structuring the risk reports, since the last two reports. When analysing large campaigns, to see what will be affected. Mainly when mapping a business or an organisation, to find out how to organise in an efficient way, or find out how a new strategy affects the company. To find which capabilities are within the scope of a project, and to find changes needed to be done to achieve a strategy or a goal. To see which capabilities you are responsible for, how they perform, and if they can be improved. To map your own organisation. When building a governance system, and seeing the connections between secure information processing, information assets, and capabilities. When mapping risks. 23 Answer to Q1.6 To see the whole, and compare projects and investments. Not to measure the capabilities. Almost anything you want. It is a good, neutral way to describe a company and its business. When needing an overview of your work, to compare departments, or looking to increase efficiency. Essentially, whenever working with changes or improvements. To easily find which capabilities are not performing well, and which people have some kind of responsibility for the capability and its performance. Also to see where we are performing changes. When working with changes and IT improvements. Assessing how hard or complex a campaign could be. To prioritise the steps needed to maximise the outcome with regards to the resources used. Capabilities are used very widely at Folksam, but it would be nice to use it in an agile method in a better way. State what an organisation does, which organisation is responsible for what. Can be used for practically anything. For projects and organisations, to see what needs to be done and what is known at the moment. To see how the capabilities map to other things, and why they perform well or not. Practically everything. Control and follow-up to be able to reach goals, so that it in the end can correlate with the economic follow-ups. 11 When determining the goals for our application park, since it is supposed to support the capabilities. 12 To simplify when working with processes, finding out where something is affected without going through all Diagram Report activity flows. To identify where are needed when performFörmågetestcontrols 1 diagram ing changes. Map to Organisations and Systems, to understand what needs to be done e.g. to perform changes. Also good to understand which capabilities are ”yours”, and where they are and what they do. To identify responsibilities, and when planning initiatives. Page: 4 Class diagram in package 'Förmågetest' 5.2 Förmågetest 1 Version 1.0 FSBE25 created on 2015-07-15. Last modified 2015-07-15 Step 2 - Meta-Model Creation Role Organisation Health Status Distribution Channel Competence Resource Screening Risk IT Support Event Information Capability Process Goal Input/Output Application KPI Cost Service Law/Rule/Policy Value tree System Requirement Figure 4: Förmågetest 1 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 was created, see figure 5. This meta-model was centred on the business capability (here: Capability), 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 comments. The comments resulted in the following changes: the suggested elements ”Goal” and Diagram Report Page: 3 ”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 separate Förmågetest diagram elements considered specialisations of the Requirement element, and Input/Output was also Class diagram in package 'Förmågetest' split into separate elements. Distribution Channel and Screening were both removed, since they were considered capabilities of their own, rather than elements liked to oneFörmågetest [15]. The Version 1.0 final draft in this step can be seen in figure 6 FSBE25 created on 2015-04-23. Last modified 2015-05-08 Resource Risk Organisation Role Input Information Event Process IT Support Capability - G oal: int Health Status : int Competence Output KPI Cost Application Service System Value tree Requirement Rule Law Policy Figure 3: Förmågetest Figure 6: The first meta-model draft, based on the initial interviews and edited according to comments from the Enterprise Architect Team Leader. The relations between the elements were modelled as described by the respondents, as found in the literature, or as discussed with the Enterprise Architects at Folksam. The relations can be found in table 7. 25 Table 7: The relations between the different elements in the meta-model draft. Element Capability Capability Capability Capability Capability Capability Capability Capability Capability Capability Capability Capability Capability Capability Capability Capability Cost Event Event IT Support Information Role Role Role Role Output Law Policy Rule Organisation Organisation 5.3 Relation to supports isSupportedBy needs isInitialisedBy isSupportedBy uses uses isMeasuredBy delivers isRealisedBy isConstrictedBy needs isAssociatedWith contributesTo isSupportedBy contributesTo isSpecialisationOf isAssociatedWith has is is is isResponsibleFor has belongsTo dependsOn isSpecialisationOf isSpecialisationOf isSpecialisationOf has isResponsibleFor Element Application Application Competence Event IT Support Information Input KPI Output Process Requirement Resource Risk Service System Value Tree KPI Process Risk Resource Resource Resource Capability Competence Organisation Input Requirement Requirement Requirement Competence Capability Step 3 - Meta-Model Evaluation The meta-model draft was sent to the interview respondents, along with a questionnaire that asked them to rate each element and attribute as ”Relevant” or ”Not relevant”. The answers 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 be inferred from table 8, respondent 8 did not complete the questionnaire, and as a result, their column was left blank. Below are listed the definitions for the different elements that were used in the questionnaire. The last two in the list, Goal and Health Status, are attributes of 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 in its 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 a capability. • Law A specific kind of requirement. • Organisation The organisation that is responsible for the capability and its realisation. • 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 direction. • Resource What is needed for the capability to function. Can be e.g. money, competence, or information. • Risk A risk associated with the capability. Compare to how the Risk Report has been structured 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, compared to 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 summary of how many respondents thought each element was relevant. The last two rows are Capability element attributes rather than elements of their own, and the column for respondent 8 is intentionally left blank, since they did not complete the questionnaire. Respondent ID Application (supported) Application (supporting) Competence Cost Event Information Input IT Support KPI Law Organisation Output Policy Process Requirement Resource Risk Role Rule Service System Value Tree Goal Health Status 1 x x x 2 x x x x x x x x x x x x x x x x x x 3 4 5 x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x 6 x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x 7 x x x x x x x x x x x x x x x x x x x x x x 8 9 10 x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x 11 x x 12 x x x x x x x x x x x x x x x x x x x x x x x x x x x SUM 1 9 9 8 5 10 6 9 8 6 7 7 6 11 8 7 7 6 5 7 10 11 9 10 Questionnaire Comments Some of the respondents had comments to the questionnaire, most of them pertaining to the definitions of the elements and what they thought about them. Respondent 4 said that they 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 organisation independent, all elements that were organisation dependent should be marked ”Not Relevant”. 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 Systems that were connected to the capability, rather than to the Capability element, and in that case they would be relevant. This respondent also stated that Organisation and Role would be relevant if it were the ones supporting the capability, instead of the ones being responsible for it, since there can be no single entity responsible for a capability. They also said that they did not think that Resources could be allocated in that way, and that Goals only would be relevant if broken down to a lower level. Respondent 12 thought that Application and System as well as IT Support were similar, and that it therefore was hard to say which ones could be relevant or not. They also thought that a distinction was needed between Resource and the different elements connected to it, such as Role, Information, or Competence, and that Law was an external Requirement, whereas Rule and Policy were internal. Furthermore, they said that they did not like the concept of Goal and Health Status, 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 the original 12 respondents, one of who chose to answer via email. Their thoughts and opinions about 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 can be found in table 9. Respondent 1 The first respondent thought that there was no element in particular that could be said to always affect the well being of a capability. They say that it might be possible to say in specific cases, but that it would take more information on how each element and capability is defined. They would check the performance of a capability by looking at all the different parts that connect to the capability and see how they perform and cooperate. Relating element attributes to the well being of a capability is something they personally do not do, but think it could probably be done, even if they cannot see any gains 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 affected by several things, but says that what they can use to measure it today is the current state and the business requirements of a capability. Organisation and Competence are key elements to measure it in the future, but they cannot say anything about element attributes that might affect it. Respondent 4 Could not be reached for a second interview. Respondent 5 The well being and performance of a capability could be measured by setting goals for it and see how well it reaches them, says the fifth respondent. Processes and Resources are the elements that affect it the most, and it is important to have a set Goal to work towards. The governance model is also important. As for element attributes that might affect a capability and its performance, they cannot say. Respondent 6 - answered via email Says that to measure the well being of a capability you have to accumulate values for its performance and its importance to the business. It could be decreased by e.g. long lead times, faulty results, or lack of resources, and the deficiencies would be rated differently depending on the importance of the capability. They have no opinion about element attributes that might affect a capability. Respondent 7 Respondent number seven thinks that establishing good KPIs that show what goal you have is a good way to measure the performance of a capability. They also say that the governance model will affect they way the capability functions, and therefore its performance as well, since it will play an important role for e.g. the structure of the organisation, the requirements set, or which systems you connect. Flaws in supporting systems 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 understanding its performance and well being, as well as that the concept of capabilities needs to be accepted throughout the company for it to perform well at all. Organisations with a clear structure are important for a healthy capability, as well as KPIs to measure it, but they have 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 needs to 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 attributes that might affect a capability, but think it is important that the people who work with it feel 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 how you define ”well being” and what is good or not, but that nonetheless Rules and Processes are important for its performance, as well as measuring the processes connected to the capability. 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 think that 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 the well being of a capability. Respondent ID 1 3 5 6 7 10 11 12 5.4 Suggested elements Process, System Competence, Organisation, Requirement Goal, Process, Resource Resource Goal, KPI KPI, Organisation Application (supporting), Information, IT Support, Organisation, Process, System Process, Requirement, Rule 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 the respondents. 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 performance and 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 defining the 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 this report have been called ”Application”, ”IT Support”, and ”System”. Hence, those three elements 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 diagram Class diagram in package 'Förmågetest' Förmågemodell2 Version 1.0 FSBE25 created on 2015-07-16. Last modified 2015-07-16 Rule Application Requirement Organisation KPI Capability - Goal: int Health Status: int Competence Information P rocess Resource Figure 2: Förmågemodell2 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. The relations for the final meta-model can be found in table 10 Table 10: The relations between the elements in the final meta-model. Element Application Competence Competence Information Information KPI Organisation Process Requirement Requirement Resource Relation to supports isNeededBy belongsTo isUsedBy is measures isResponsibleFor realises constricts hasSpecialisation isNeededBy 31 Element Capability Capability Organisation Capability Resource Capability Capability Capability Capability Rule Capability 6 RESULTS In figure 7 the final meta-model can be seen. It contains nine elements, apart from the Capability 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. The ones 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 in the second set of interviews. Here, the elements and relations in the final meta-model are described more in detail, as well as the reasons for why they are in it. Since the Application element 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 business does. 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-model are 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 element are 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 by respondents 7 and 12. Respondent 7 said that they thought it was important to model the applications when working with strategy and logical solution architecture, and respondent 12 that Application is one of the key elements that are affected by changes. They said that capabilities do not change, as long as you do not change you business model, but you can change 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 suggested by respondent 12, in that they said that the applications are what can be called technical support systems that can be connected to a capability. Respondent 6 said that one key question when breaking down capabilities into other parts was to see what IT support (here: Application) is needed. Aggregated Element: IT Support The element was suggested by respondents 5, 6, and 8. Both respondents 6 and 8 thinks that IT Support is important to connect when looking at capabilities from a strategic point of 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 are connected to a capability, and respondent 7 would like to connect systems to capabilities for strategic solution architecture purposes. Respondent 10 works with integrating different processes and systems, and with developing governance systems, and thinks that connecting systems to capabilities helps when analysing a complex organisation. To get a good view of a 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 which systems 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 the Capability. This element was suggested by respondents 7 and 8. Respondent 7 likes to connect capabilities to the concept of business objects, and says competences are a key part of that. Respondent 8 says that capabilities is a way of showing which competences are needed within a company, and that capabilities in that way are a good tool for competence planning - ”Which competences do we need where?”. Relation: isNeededBy (Capability) This relation shows which competences are needed by the Capability for it to function as it should. This relation was suggested by respondent 8, when they stated that capabilities is a 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 specific competence. The relation was suggested by respondent 7, saying that they would like to know which competences they have within a capability, and where they belong within the company and its organisations. 6.4 Element: Information This element shows which information is needed by the Capability for it to be able to function. The element was suggested by respondents 1, 3, 4, 10, and 12. Respondent 1 said that in their view, the Capability was connected to four other elements, one of which was the Information element, a view that was largely shared by respondent 12. Respondent 3 stated that connecting Information objects to the Capability would help in visualising which capabilities are affected in different projects, and respondent 4 is of the opinion that the information 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 a governance and control level is important, and that a good way to keep track of everything is to connect it to capabilities as well. Relation: isUsedBy (Capability) The relation shows that the Capability uses certain information in order to function and perform. Respondent 10 said that everyone and everything today is dependent on information in some way, and capabilities are no exception. Relation: is (Resource) Resources can be of different kind, and this relation expresses that information is considered a Resource. This view was expressed by respondents 4, 10, and 12. Respondent 10 stated that ”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 the Capability performs. This element was suggested by respondent 4, who said that they would like to break down a capability into several KPIs that could be used to measure its performance. 33 Relation: measures (Capability) As stated above, the KPI measures the Capability in some way. This relation also stems from the statement of respondent 4 saying that they would like to measure capabilities using KPIs. 6.6 Element: Organisation The Organisation is the part of a company that has responsibility for the execution of the Capability, and that it performs as it should. This element was suggested by respondents 1, 2, 7, 8, 9, and 11. Respondent 1 says that Organisation is one of the four key parts connected to a capability, and respondent 2 that while the capability does not belong to an organisation, it can still have a relation to one. Respondent 7 thinks that connecting organisations 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 is responsible for what. Respondent 9 states that they would like to use capabilities to know that things are done at the right place within their organisation, and respondent 11 says that in order for them to understand why they do what they do it is crucial to connect the capabilities to the organisations that work with them. Relation: isResponsibleFor (Capability) This relation shows that an organisation has a responsibility for the Capability and that it performs as it should. It is possible for several organisations within a company to have this relation to the same capability, since several organisations could be working with a single capability. It is suggested by respondent 8, who says that mapping organisations to capabilities 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 good idea to connect Processes to the Capability. Respondent 1 sees Processes as one of the four key elements connected to a capability, and that it is useful when mapping the scope of projects, something that respondents 3, 6, 8, and 12 agree with. Respondent 2 says that measuring the performance of the connected processes is a good way of establishing if the capability performs or not, and respondents 4 and 5 think that it is easier to map a business using capabilities instead of processes, but it is easier to work with a map of the processes, so connecting the two helps. Respondent 7 says that processes are part of what helps a capability create value, and respondent 9 thinks it is easier to see the entirety when processes and capabilities are connected. Respondent 10 says that in order to get any benefits from working with capabilities, you have to break them down into smaller parts and connects them to e.g. Processes. Relation: realises (Capability) A capability describes what a company does, and a process how it is done. From this follows that the Capability is realised by the connected Processes, a relation suggested and confirmed by all respondents. 6.8 Element: Requirement A Requirement on the Capability can have several different origins, and can be everything from a law to an internal guideline for a project. All respondents except respondent 1 agreed that 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 you have a purpose for doing so. Respondent 3 has previously worked with connecting business requirements to capabilities to see which capabilities are affected by them, and respondent 4 says that connecting requirements to capabilities is crucial, because if you do not have any 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 is mapping changes, and since requirements are important for defining changes, they would like to connect the two. Respondent 6 says that they think it is relevant, but that they are used to other terminology and hence cannot expand on the subject. Respondent 8 has used capabilities as a way of prioritising requirements, starting with one capability and its requirements 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 is used 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 might be of different degrees of importance, but they all affect the Capability and how it is implemented or performed in some way. This relation stems from respondents 4 and 10 describing how 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, competence, or information. All respondents except three (1, 10, and 12) thought that connecting resources to capabilities would be useful. Respondents 3 and 5 say that comparing resources needed to perform a capability that exists in several places within a company is a good way of understanding if the capability can be optimised in some way, and respondent 4 says that resources 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 relation was suggested by several of the respondents, among them respondent 4 stating that resources are 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 it is, how it would work if it was ideal. This attribute was suggested by respondent 8, with the description stated here. 6.11 Attribute: Health Status The Health Status attribute shows how well the Capability performs and functions. This attribute was suggested by respondent 11, who said that it would be helpful to see which projects 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 other data. As described in section 5.4, the elements Application, IT Support and System have here been aggregated to one element, Application, in the way that if one or more of the three aggregated elements was marked in the original table (in section 5), the Application element is marked in the corresponding table in this section. For example: table 12 in this section is table 4 but sorted in a specific way. In table 4, the Application element is suggested by respondents 7 and 12, the IT Support element by respondents 5, 6, and 8, and the 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 other elements. 7.1 Elements Relevant to Connect to the Capability In table 4, the elements that each respondent thought relevant to connect to the Capability can 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 that it is easier to say ”Yes” when asked if an element is relevant, than to figure out relevant elements 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 if it is suggested to them, than to come up with relevant elements themselves. This tendency can also be seen when looking at table 4, where most respondents agreed that the elements suggested in Q1.8 would be relevant, but only four out of the forty-five instances of positive answers 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 the most relevant ones was not in Q1.8 but suggested by the respondents themselves. This could partly 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 the concept 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 way answered that a capability is what a business does, while 10 out of 12 respondents answered what they had used capabilities for. 36 Table 11: Tables showing the elements sorted according to ”relevance”, the number of respondents 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 according to relevance. The number reaches from 1 (one respondent) to 11 (all but one respondent). Rank 1 2 3 4 5 6 7 8 Element Process Requirement Application Resource Role Event Service Organisation Information Competence Input/Output Risk Cost Distribution Channel Goal Health Status KPI Law/Rule/Policy Screening Value Tree Relevance 11 11 10 10 10 7 7 6 5 3 2 2 1 1 (b) Table 8 sorted according to relevance. The maximum score here is 11, since one respondent did not answer the questionnaire. Those marked with * are here attributes of the Capability rather than elements. Rank 1 2 3 4 5 1 1 1 1 1 1 6 7 Element Application Process Value Tree Health Status* Information Competence Goal* Cost Requirement KPI Organisation Output Resource Risk Service Input Law Policy Role Event Rule Relevance 11 11 11 10 10 9 9 8 8 8 7 7 7 7 7 6 6 6 6 5 5 When sorting the elements in tables 4 and 8 according to the respondents’ time working at 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 for a 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 when grouping 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, (see table 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 connect Service 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 group are Business Architects, the second Business Developers, and the third Risk Managers. The two remaining respondents are a Governance Specialist and an IT Strategist. Respondent ID Application Competence Cost Distribution Channel Event Goal Health Status Information Input/Output KPI Law/Rule/Policy Organisation Process Requirement Resource Risk Role Screening Service Value Tree 1 x 2 3 x 7 x x 12 x 6 x 8 x x 9 4 x 5 x 10 x 11 x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x 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 Application Competence Cost Distribution Channel Event Goal Health Status Information Input/Output KPI Law/Rule/Policy Organisation Process Requirement Resource Risk Role Screening Service Value Tree 10 x 8 x x 6 x 2 12 x 9 3 x 4 x 5 x 7 x x 1 x 11 x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x 38 x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x Table 14: This shows table 4 sorted according to the time the respondents have worked with capabilities. The time spans from 2000 (to the right) to 2015 (to the right). Respondent ID Application Competence Cost Distribution Channel Event Goal Health Status Information Input/Output KPI Law/Rule/Policy Organisation Process Requirement Resource Risk Role Screening Service Value Tree 7 x x 1 x 10 x 8 x x 12 x 6 x 2 3 x 4 x 5 x 9 11 x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x 39 x x x x x x x x x x x x x x x x x x x x x x x x x x x Table 15: These are the answers to the questionnaire (table 8) sorted according to the respondents’ positions. The first group are Business Architects, the second Business Developers, and the third Risk Managers. The last two are a Governance Specialist and an IT Strategist. 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 Application Competence Cost Event Information Input KPI Law Organisation Output Policy Process Requirement Resource Risk Role Rule Service Value Tree Goal* Health Status* 1 x x x 2 x x x x x x x x x x x x x x x x 3 x x x x x x x x x x x x x x x x x x x x x 7 x x x x x x x x x x x x x x x x x x x x 40 12 x 6 x x x x x x x x x x x x x x x x x x x x x x x 4 x x x x x x x 5 x x x 10 x x x 11 x x x x x x x x x x x x x x x x x x x x x x x x x x x x x 9 x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x Table 16: This is table 8 sorted according to the time the respondents had been working at 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 Application Competence Cost Event Information Input KPI Law Organisation Output Policy Process Requirement Resource Risk Role Rule Service Value Tree Goal* Health Status* 10 x x x x x x x x x x x x x x 6 x x x x x 2 x x x 12 x x x x x x x x x x x x x x x x x 9 x x x x x x x x x x x x x x x x x x x x x x x x x 41 x x x x 3 x x x x x x x x x x x x x x x x x x x x x 4 x x x x x x x 5 x x x x x x x x x x x x x x x x x x x x x x x x x 7 x x x x x x x x x x x x x x x x x x x x 1 x x 11 x x x x x x x x x x x x x x x x x x x x x Table 17: Table 8 sorted according to how long the respondents had been working with capabilities. 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 Application Competence Cost Event Information Input KPI Law Organisation Output Policy Process Requirement Resource Risk Role Rule Service Value Tree Goal* Health Status* 7 x x x x x x x x x x x x x x x x x x x x 1 x x x x 10 x x x 12 x x x x x x x x x x x x 6 x x x x x x x 2 x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x 3 x x x x x x x x x x x x x x x x x x x x x 4 x x x x x x x 5 x x x x x 9 x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x 11 x x x x x x x x x 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 showed that they knew the key point: a capability is what a company does. Would this have any impact 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 a capability 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: those with a better understanding of what a capability is tended to have more suggestions for elements that would be relevant to connect to it. They suggested an average of 8.3 elements per 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 in some way showed that they knew what a capability was what a company does. The right group did not show this when asked what they knew about capabilities. Respondent ID Application Competence Cost Distribution Channel Event Goal Health Status Information Input/Output KPI Law/Rule/Policy Organisation Process Requirement Resource Risk Role Screening Service Value Tree SUM 2 3 x 4 x 6 x 8 x x 11 x x x x x 12 x 1 x 5 x 7 x x 9 10 x x x x x x x x x x x x x x x x x x x x x x x x x x x x x 8 7 x x x x x x 11 x x x x x x x x x x x x x 7 10 x x 9 x x x x x x x x 6 5 x x x x x x x x x x x x x x 5 10 x x x x 7 5 Does it matter how the respondents were introduced to the concept of business capabilities? The answers to Q1.4 (How did you first come across the concept of business capabilities? ) differ, but 6 out of the 12 respondents got an introduction to capabilities by the Enterprise Architect Team Leader at Folksam. When comparing this half to the other half, who came across the capability concept in some other way (see table 19), one small difference was seen. Those who had not gotten the introduction saw Risk as an irrelevant element, but otherwise their views were similar. 43 Table 19: Table 4 sorted into two different groups. The group to the left first came across the concept of business capabilities when it was introduced to them by the Enterprise Architect Team Leader at Folksam, whereas the group to the right came across it in several other ways. 2 Application Competence Cost Distribution Channel Event Goal Health Status Information Input/Output KPI Law/Rule/Policy Organisation Process Requirement Resource Risk Role Screening Service Value Tree 7.2 3 x 4 x 6 x 8 x x 11 x x x x x 1 x 5 x 7 x x 9 10 x 12 x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x Why Connect Capabilities to Other Elements? In table 5 the respondents’ answers to the question Why would you like to connect these elements, and when would it be useful? (Q1.9). Two themes stand out as reasons for using capabilities connected to other elements: describing a company, and govern changes. Eight out of the twelve respondents state one or both of these as at least one of the reasons to why they want to connect capabilities to other elements. When looking at what the respondents use capabilities for today (Q1.5), describing and mapping a company or an organisation was also among the top areas, but together with determining the scope of a project. Seeing which capabilities could be affected to what degree, and comparing different projects, is what several of the respondents used capabilities for today. Seven out of twelve respondents said 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 on changes and how to see where they affect the company. Another important area was to assign and see responsibility, who is responsible for a certain capability or what capabilities you have responsibility for. Half of the respondents suggested one or both of these as potential areas 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 thought that the elements affected the Capability, or if it was the other way around, e.g. in the event of changes. Respondents 1 and 2 said that the elements support a capability, but respondent 1 also said that they both affect each other. Respondents 3, 4, 5, and 9 all said that the Capability is affected by the elements, and respondents 4 and 7 also said that a capability is 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 also could be affected by time or corporate culture. Respondent 10 said that if you control a capability by examining its connected elements, then the controlling and its goals will affect the connected elements, and respondent 12 stated that the elements might change, but the capability 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 the Capability is affected by its connected elements, and fewer respondents (4 out of 12) thought that it was the other way around, counting the three who thought that it could go both ways in both groups. One of the respondents simply stated that a capability consists of the elements, 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 could tell if a capability was performing well or not. Respondent 6 simply stated that there used to be ID cards for each capability stating its health status, and respondent 3 said that the closest thing they do today is checking the current state and business requirements of a capability. Respondents 7 and 8 suggested the use of KPIs showing your goal, and that these would be measured before, during, and after the introduction of a capability to show if improvements were made. Respondent 12 suggested measuring Processes connected to a capability, and respondent 11 added Organisations and Systems to the list of elements that should 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 the connected elements work and cooperate. This shows that most of the respondents agree on that the best way of understanding the well being of a capability is to measure and assess the status of its connected elements, even if it differs which elements should be measured. The Health Status could then be presented in an ID card for each capability, so that employees who had gotten used to information presented in that way could continue using it. As for what affects the well being of a capability the most, and if any of the suggested elements affected it more than others, the respondents had several different views. The respondents that suggested that particular elements would affect the well being of a capability were most prone to suggest that Organisation and Process would affect it, something 3 out of 8 respondents did, while two respondents suggested that Resource would be affecting the Capability the most. Respondents 1, 3, 6, and 12 also said that what affects the well being of a capability depends a lot on the capability, and respondent 10 said that the level of acceptance throughout the company is the most crucial part for them right now - ”If the capability concept is not accepted, we cannot work with it”, they said. How those who work with the capability feel 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 that outer and inner requirements matter, as well as how easy it is to apply the capability and the 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 seems important for the capability’s well being that processes connected to the capability run smoothly, and that there is a clear structure of responsibility in the organisations connected to it. The capability concept also has to be accepted throughout the company, and those who work with a capability need to feel that everything works as it should. Elements connected to the Capability, such as Processes and Requirements, should then be measured through set 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 any statistical conclusions from the data. The conclusions drawn in section 7 might therefore not apply on a larger scale. It is possible that the variations in the answers differ on a personal 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 relevant than coming up with relevant elements themselves. Hence, if Folksam wants to know which elements are relevant for most people in the organisation, or most people involved in the work with capabilities, they should provide the stakeholders with a list of all possible elements from 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 respondents were unable to answer the third question (Q2.3 What attributes of the Capability affects the well being and performance of it the most? ), and two of the respondents were unable to answer question number five (Q2.5 What attributes of these elements do you think affect the Capability, and which attributes of the Capability do you think they affect? ). This suggests that the questions might have been formulated in a less than optimal way. The concept of element attributes seems to be unfamiliar for these respondents, and a more thorough description of the concept might have been needed. If elements attributes should be added through a process including interviews with stakeholders, the concept should be made clear beforehand 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 ”Application” 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 being combined into one, since when looking at the interview results with the Enterprise Architect Team Leader, it was concluded that the respondents had used different words for the same thing. However, this showcases the risk that the respondents were confronted with a vocabulary that they were not used to, which in turn might have affected their answers. To make sure that this risk was significantly lowered in later steps, the respondents were given a description of each element when completing the questionnaire (with the results seen in section 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 it possible 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 process connected to a capability, but not for the Capability itself. This definition differs from the one used when making the meta-model in this report (see e.g. section 6.6), which states that the relation between an organisation and a capability is Organisation isResponsibleFor Capability. This is due to the fact that the meta-model presented in this report is based solely on the answers, opinions, and suggestions of the interview respondents. The respondents expressed that it would be of interest to them to know which capabilities their organisation were responsible for performing and executing. Six out of twelve respondents stated in the first set of interviews that they have used or would like to use capabilities as a way of organising 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 nine other elements, connected by eleven relations in total. The meta-model was created based on opinions of stakeholders and their views of business capabilities and their well being, expressed through interviews and questionnaires. The Health Status of the Capability has been incorporated as one of the Capability element attributes, and the elements surrounding the Capability have been described by the respondents as affecting it and the Capability’s well being. From the interview results can be seen that people who have a better understanding of what a capability is have a tendency to want to connect it to many elements. It is also noted that most respondents agreed on the usefulness of capabilities when it came to analysing the scope of advancements and projects, and what parts of the company would be affected by them. 9.1 Future Research The meta-model created within this research is only a draft, and has not been incorporated into the enterprise architecture repository at Folksam. The meta-model should hence provide a 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 relation between capabilities and organisations, to decide if they should use one that corresponds with the theory (that no organisation can have responsibility for a capability), or one that is preferred by the employees (that shows which organisations have a responsibility for the capability). If Folksam wants to further investigate if certain elements are relevant or not for specific positions or departments, another survey as the questionnaire described in section 4.3 could be sent out to more respondents. A quantitative study could yield more reliable data for analysis. References [1] Systems and software engineering – Architecture description. Standard ISO/IEX/IEEE 42010:2011, International Organization for Standardization, Geneva, CH, December 2011. [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, December 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, Object 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. Accessed 2015-05-21. [9] Respondent 5. Personal communication, first set of interviews, 2015. Risk Manager at Folksam. [10] Carlos LB Azevedo, M-E Iacob, Jo˜ao Paulo A Almeida, Marten van Sinderen, Luis Ferreira Pires, and Giancarlo Guizzardi. An ontology-based well-founded proposal for modeling resources and capabilities in archimate. In Enterprise Distributed Object Computing 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 g˚ a vidare fr˚ an 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 Enterprise Architect Team Leader at Folksam. [16] Charlotte Frank. Syfte verksamhetsf¨orm˚ agor. Internal presentation, 2015. [17] Martin Henkel, Ilia Bider, and Erik Perjons. Capability-Based Business Model Transformation. In Advanced Information Systems Engineering Workshops, pages 88–99. Springer, 2014. [18] Dave Hornford, Tara Paider, Chris Forde, Andrew Josey, Garry Doherty, and Cathy Fox. 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 Value in Enterprise Architecture to Support Portfolio Valuation. In Enterprise Distributed Object Computing Conference (EDOC), 2012 IEEE 16th International, pages 11–20. IEEE, 2012. [20] Marc Lankhorst et al. Enterprise Architecture at Work: Modelling, Communication and 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, February 2009. 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, Accessed 2015-03-09. [25] Jon Siegel. In OMG’s OCEB Certification Program, What is the Definition of Business Process? http://www.omg.org/oceb/defbusinessprocess.htm, June 2012. Accessed 2015-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) Capability? 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 stated in 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 what question was discussed rather than showing its exact wording. A.1 Interview set 1 Respondent 1 Bakgrund: Jag b¨ orjade jobba p˚ a Folksam h¨ ar 19e januari, s˚ a jag har inte jobbat h¨ar j¨attel¨ange. Jag jobbar h¨ ar som verksamhetsarkitekt p˚ a koncernarkitektur. Innan dess s˚ a har jag jobbat p˚ a SEB, som deras motsvarighet till aff¨ arsarkitekt, d¨ar kallas det Enterprise Business Architect. D¨ ar jobbade jag p˚ a verksamhets-sidan, och det ¨ar v¨al d¨ar egentligen som jag ocks˚ a kom i kontakt och jobbade med f¨ orm˚ agor, fr˚ an b¨orjan d˚ a. Och, vad ska man s¨aga h¨ar. Jag har kommit in h¨ ar p˚ a Folksam och kommer jobba litegrann inom riskomr˚ adet, och ¨aven arkitekturst¨ odjande d˚ a. Och d¨ ar har vi b¨ orjat titta p˚ a det h¨ar med f¨orm˚ agor. Man har ju jobbat ganska l¨ ange med f¨ orm˚ agor, och jag diskuterade ocks˚ a med Charlotte tidigt, n¨ar vi hade v˚ ar dialog ikring hur vi hade jobbat p˚ a SEB och hur de jobbar h¨ar. S˚ a det ¨ar v¨al litegrann bakgrund. Innan jag jobbade p˚ a SEB, d¨ar jag b¨orjade 2011, s˚ a har jag jobbat ett par ˚ ar som konsult inom m˚ anga olika delar, i b¨orjan som utvecklare, har jobbat som projektledare, har jobbat mycket inom management strategi-konsulting och s˚ a. En bit bakgrund. S˚ a, kortfattat: vad vet du om f¨ orm˚ agor och verksamhetsf¨ orm˚ agor, och hur anv¨ ander ni det? Jag jobbar med det ungef¨ ar sen 2011, som egentligen ett verktyg i Enterprise Architecturearbetet. Jag har ganska tidigt b¨ orjat jobba med Enterprise Architecture, typ 2001 n˚ an g˚ ang b¨ orjade jag med de tankarna, sen har jag kontinuerligt byggt p˚ a olika verktygss¨att att arbeta med d¨ ar d˚ a, och f¨ orm˚ agor ser jag som ett s¨att att skapa en h¨ogre niv˚ a av diskussion med intressenter, s˚ a man inte beh¨ over g˚ a ner och fastna i detaljer f¨or att scopa in saker och ting, f¨ or att identifiera problemomr˚ aden och s˚ a vidare. Det blir s˚ a l¨att annars att man utifr˚ an kanske ett aff¨ arsomr˚ ade eller en specifik kunskap fastnar i en detalj som ¨ar ganska oviktig p˚ a totalen, men det f¨ or inte dialogen fram˚ at. Jag kan s¨aga att n¨ar vi tittade p˚ a f¨orm˚ agor, n¨ar jag b¨ orjade titta p˚ a det d˚ a, kring 2011, d˚ a anv¨ande vi oss mer ur ett aff¨arsfunktionskoncept, allts˚ a egentligen en beh˚ allare du kan l¨agga aff¨aren i d˚ a, olika delar. Och det var mycket ur analysh¨ anseende d˚ a, s˚ a at man kunde p˚ a ett enkelt s¨att mappa ner det, men ”vad ¨ar det f¨ or n˚ anting ett speciellt initiativ eller en satsning kommer ber¨ora?” ”Vad ¨ar det vi beh¨over t¨ anka p˚ a s˚ a att vi f˚ ar med allting?” S˚ a det var mer ur det perspektivet ¨an att vara specifik p˚ a att ”det ¨ ar precis det h¨ ar” eller ”det a¨r bara 20% av den h¨ar delen”, utan vi bara markerade i form av en heat map att det h¨ ar och det h¨ar och det h¨ar omr˚ adet, det ber¨ors. Sen b¨orjade ju vi v¨ ava ihop egentligen, s¨ att att se, men ”hur f¨orh˚ aller sig f¨orm˚ agor till aff¨arsmodeller”, ”hur f¨ orh˚ aller de sig till v¨ ardekedjor” osv. Och det jobbade vi ganksa mycket med att f˚ a ihop det t¨ anket, s˚ a vi kunde ha olika typer av verktyg, och prata med olika personer i verksamheten, beroende p˚ a var de var och vad de hade f¨or , egentligen bakgrund och kunde f¨orst˚ a. Vissa kunde vi prata f¨ orm˚ agor med, andra pratade vi aff¨arsmodeller, och s˚ a mappade vi ner sj¨alva till f¨ orm˚ agor. Och det ¨ ar v¨ al det s¨ attet som jag har sett att det funkat b¨ast. Man kan ju ta d˚ a som exempel att om vi f˚ ar ett lagkrav p˚ a oss, ja men d˚ a kanske man tittar p˚ a en specifik aff¨ arsmodell, ja men ”vad var det n˚ anstans det h¨ar kommer r¨ora?” ”Jo men det kommer r¨ ora rapportering”, ”det kommer r¨ ora kunderbjudande” och s˚ a vidare. Har man tagit den niv˚ an, ja men d˚ a kan man ploppa ner det sen p˚ a f¨orm˚ agor, och se ”Vilka f¨orm˚ agor ¨ar det 50 som det ber¨ or?” Och d˚ a beror det ju p˚ a vad vi l¨agger i den h¨ar f¨orm˚ agecontainern d˚ a. Och mitt syns¨ att p˚ a det har ganska pragmatiskt varit fyra komponenter: det har varit organisatoriska, det har varit process, det har varit information, och det har varit system. F¨or att kunna, liksom, har du landat i en f¨ orm˚ aga ”Ber¨or det organisation?”, ”nej, det ber¨or inte organisation”, ”ber¨ or det processer?”, ”ja, det ber¨or det”, och sen ” okej, automatiserade processer” och i s˚ a fall vilka. S˚ a att man liksom har kommit ner till n˚ agon typ av att man kan g¨ ora analyser. S˚ a det ¨ ar s˚ a liksom, de s¨attet man h¨anger ihop det p˚ a. Det mindset’et har jag. N¨ ar d¨ ok det h¨ ar upp, konceptet med f¨ orm˚ agor, och p˚ a vilket s¨ att, i vilket sammanhang? Sammanhanget var egentligen att, och det var tillbaka n¨ar jag jobbade p˚ a SEB, att vi hade en funktionskarta. N¨ ar vi b¨ orjade titta p˚ a den och hur den funkade, och ¨aven hade omv¨ arldsbevakning och man b¨ orjade diskutera mer och mer f¨orm˚ agor, det d¨ok upp n˚ an stans d¨ ar 2010-2011, det var d˚ a jag b¨orjade f˚ a upp det p˚ a kartan. D˚ a b¨orjade vi titta p˚ a det ”Ja, men det h¨ ar ¨ ar ju i stort sett f¨ orm˚ agor”, s˚ a. Sen hade vi ett ganska pragmatiskt s¨att att se att vi hade den h¨ ar aff¨ arsfunktionaliteten, den h¨ar komponenten eller f¨orm˚ agan, det var en niv˚ a 1:a f¨ or oss, och sen det vi hade under den direkt, vi br¨ot inte ner den i separata f¨ orm˚ agor utan vi sa att ”nej men vi tar v˚ ara processer, s˚ a l¨agger vi huvudprocesserna i den f¨ orm˚ agan, s˚ a vet vi att de h˚ aller n˚ agon typ av funktionalitet p˚ a det s¨attet”. Sen kan man ju titta p˚ a den och se att det fanns ju f¨or- och nackdelar med att g¨ora det. Processerna ¨ar ju bara en del av en f¨ orm˚ aga egentligen, men det fyller den funktionen som vi ville ha d˚ a. S˚ a s¨ ag 2011 d¨ arikring. 2010-2011. Hur har du anv¨ ant dig av f¨ orm˚ agor? Det ¨ ar just egentligen, jag har jobbat mycket med Quality Assurance, p˚ a projekt och s˚ a vidare, och en del i det var att vi i dokumentationen hade att projekten skulle fylla i med vilka komponenter det ¨ ar de sp¨ anner ¨over. Och det var ju f¨orm˚ age-delen, s˚ a att s¨aga. D˚ a fick de egentligen beskriva, till den niv˚ a som de visste vid tillf¨allet. Det ¨ar ju olika delar i olika faser f¨ or olika projekt hur mycket de vet men, f¨orst b¨orja ¨overgripande ”Ja, men det kanske bara r¨ orde en f¨ orm˚ aga p˚ a toppniv˚ a”, och sen kunde de g˚ a ner och markera ”ah, men just det, den och den processen r¨or det d˚ a, och sen den h¨ar organisationen”. S˚ a att det var egentligen ur att s¨ akerst¨ alla d˚ a att jag som stakeholder fr˚ an verksamhets/IT-sidan s¨ akrade upp att projekten hade r¨ att scope. Och likadant att var de i ett visst omr˚ ade man kunde se p˚ a den h¨ ar kartan om det var andra saker ”Ja, men det h¨ar r¨or sig d¨ar” man kunde f˚ a n˚ an typ av korsreferens hur projekten r¨orde sig. S˚ a mycket ur liksom analys och planering. F¨ orutom d˚ a Quality Assurance, vilka andra anv¨ andningsomr˚ aden kan du se f¨ or f¨ orm˚ agor? F¨ or dig/avd... Nej men det ¨ ar just.. En del det ¨ar ju att kunna f˚ a grepp om helheten, f¨or det ¨ar ju det som liksom ¨ ar huvudsyftet tycker jag, att kunna se ”Ja man hur sl˚ ar det h¨ar” och ”hur sl˚ ar det i j¨ amf¨ orelse med andra satsningar” och s˚ a vidare. Jag ¨ar v¨aldigt f¨orsiktig med att liksom hitta, ja men ”nu ska vi m¨ ata p˚ a f¨orm˚ agor” f¨or en f¨orm˚ aga den ¨ar egentligen konceptuell, den ¨ ar inte specifik. Den kan best˚ a eller st¨odjas av m˚ anga olika saker, en process till exempel. Och en process, den kan du m¨ata. Du kan tidsm¨ata, och vad har den f¨or genomstr¨ omning och vad har du f¨ or resultat och s˚ a vidare. Men det ¨ar bara en liten del. Om man skulle liksom, rita en cirkel h¨ar som ¨ar f¨orm˚ agan, s˚ a den h¨ar delen, 60% eller vad det nu ¨ ar (ritat 30-40), best˚ ar av m¨atbara delar, som process, organisation osv. Den h¨ar andra delen h¨ ar, det ¨ ar annat. Det kan vara liksom, du r˚ akar s¨atta tre personer som har en viss bakgrund i samma rum och anv¨ander olika saker och d˚ a f˚ ar du en en effekt, men den ar liksom inte s˚ ¨ a h¨ ar p˚ ataglig. Och d¨arf¨or s˚ a tror jag att det kan vara sv˚ art att m¨ata p˚ a f¨ orm˚ agor. Du kan m¨ ata p˚ a st¨ odjande 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 det utanf¨ or Folksam, s˚ a¨ ar det inte s¨ akert att du f˚ ar samma resultat i f¨orm˚ agan i vilket fall. S˚ a d¨ arf¨ or ¨ ar jag lite f¨ orsiktig n¨ ar man s¨ager att man ska m¨ata p˚ a f¨orm˚ agor. Jag tror att man kan m¨ ata p˚ a process och information osv. Sen kan det ge en indikation p˚ a hur f¨orm˚ agan m˚ ar, s˚ a det ¨ ar lite s˚ a. Men m¨ atbarhet, ja, till viss del, subjektiv d˚ a. Och det kan ocks˚ a vara d˚ a att har du identifierat omr˚ aden som du k¨anner att du m˚ aste f¨orb¨attra, ja men d˚ a kanske du g˚ ar ner ¨ annu mer och kollar p˚ a, ja, men ”Kan vi ut¨oka den delen som vi vet, och minska det h¨ ar fr˚ agetecknet?” Vad ser du skulle vara relevant att mappa till en f¨ orm˚ aga, utom just process, information, organisation (och system)? Jag skulle s¨ aga att du skulle egentligen kunna koppla vad som helst till en f¨orm˚ aga, det beror bara p˚ a vad du s¨ atter f¨ or relation, och p˚ a den kopplingen. Litegrann den h¨ar cirkeln som jag ritade d¨ ar, det kan vara system som st¨oder saker och ting, det kan vara kompetenser, organisatoriska upps¨ attningar, ja men hur du s¨atter upp din organisation, det kan vara de ing˚ aende kompetenserna ocks˚ a. Det kan vara, du skulle kunna ta till exempel att v˚ aran VD har ett kontaktn¨ at ute i organisationen, eller ute p˚ a marknaden, som g¨or att vi f˚ ar bra kontaktytor och kan g¨ ora bra avtal, s˚ a. Det ¨ar ju n˚ agot som f¨orb¨attrar v˚ ar f¨orm˚ aga att g¨ ora f¨ ors¨ aljning, men den ¨ ar ju inte s˚ a j¨attep˚ ataglig, men den skulle kunna finnas d¨ar. S˚ a att jag tror att det ¨ ar mycket som bygger upp f¨orm˚ agorna. Sen ¨ar det vissa delar som vi kan pinpointa och analysera och f¨orb¨attra, och andra saker sitter i v¨aggarna. S˚ a att jag skulle kunna s¨ aga att de h¨ ar sakerna som du har r¨aknat upp h¨ar: Krav, ja, du kanske kan s¨ atta n˚ an typ av krav p˚ a den, men jag tror inte du ska koppla krav till en f¨orm˚ aga. Du kan f¨ orb¨ attra en f¨ orm˚ aga, men kraven kommer du att s¨atta p˚ a en organisation, process eller n˚ at s˚ ant. Resurser, ja, du m˚ aste ha resurser som st¨odjer en f¨orm˚ aga, men att troligtvis s˚ a st¨ odjer de ing˚ aende delar i den ist¨ allet, och inte f¨orm˚ agan som s˚ adan. Resultatet av det blir att f¨ orm˚ agan f¨ orb¨ attras eller f¨ ors¨amras. S˚ a att jag tror att, direkt och indirekt, och jag vet inte om vi har n˚ an nytta av att liksom, s¨atta hela fulla metamodellen f¨or den, utan jag tror att det ¨ ar viktigare att vi riktar in oss p˚ a saker och ting som vi ser ¨ar relevanta f¨or oss som vi kan f¨ or¨ andra. Och jag skulle s¨aga att huvudingredienserna ¨ar egentligen de h¨ar fyra. L¨ agg till/ta bort personal, utveckla personal, f¨orb¨attra din process, eller s˚ a. Det ¨ar det som i en f¨ or¨ andringsprocess ¨ ar s˚ apass p˚ atagligt. Sen kan man ju, man m˚ aste se det som en helhet. Man kan inte bara modernisera det ena eller det andra, s˚ a. S˚ a att jag skulle inte vilja begr¨ ansa mig till att du inte kan koppla saker och ting till en f¨orm˚ aga, men fr˚ agan ¨ar: Ger det dig n˚ agon reell nytta i ett f¨ or¨andringsh¨anseende? Och det tycker jag ¨ar viktigt. De som du tycker ¨ ar vettiga att koppla till f¨ orm˚ agan ¨ ar allts˚ a de fyra du har n¨ amnt? Ja, men det ¨ ar de h¨ ar fyra som jag sa: organisation, information, system, och process. Och det kan man ju, liksom, det a¨r litegrann d¨arf¨or jag skickade det h¨ar till dig ocks˚ a, det h¨ ar med verksamhetsf¨ orm˚ aga, vad ¨ar en verksamhetsf¨orm˚ aga eller en f¨orm˚ aga eller en IT-f¨ orm˚ aga? Det ¨ ar ingen ide att kalla den, s¨ager du verksamhetsf¨orm˚ aga d˚ a finns det n˚ an annan typ av f¨ orm˚ aga ocks˚ a, implicit. Och pratar du om IT-f¨orm˚ agor, ja men det ¨ar ju egentligen en f¨ orm˚ aga som ¨ ar automatiserad, s˚ a. S˚ a att vi vinner ingenting p˚ a att l¨agga upp flera olika begrepp. Vi har haft diskussioner om aff¨arsf¨orm˚ agor och verksamhetsf¨orm˚ agor. Aff¨ arsmodell, ja, men en aff¨ arsf¨ orm˚ aga..? Nja. Jag tycker det ¨ar att skapa on¨odiga konflikter. Men sen har vi ju samtidigt haft, aprop˚ a att man av¨ander f¨orm˚ agor, f¨orm˚ aga inom HR d˚ a, och d˚ a¨ ar det ocks˚ a, ja, f¨ orvisso. Vi anv¨ander ju tj¨anst och andra begrepp ocks˚ a beroende p˚ a hur verksamheten ser ut. S˚ a jag tror inte man ska ta n˚ at patent p˚ a det, men det ¨ar ju viktigt att f¨ orst˚ a vad vi anv¨ andet det till, och varf¨or kallar vi det f¨orm˚ aga. P˚ a engelska, capability, ja, det ¨ ar v¨ aldigt n¨ ara ability och s˚ a vidare, men vi har inte s˚ a bra svenska ord f¨or allting. 52 S˚ a de h¨ ar fyra som du tycker ¨ ar relevanta.. Och de tror jag ocks˚ a att vi b¨ or modellera i FAR6 , s˚ a vi f˚ ar liksom ett meta-st¨od f¨or dem. De ¨ ar ganska uppenbara, de finns p˚ a alla f¨orm˚ agor. S˚ a varf¨ or och vilka element det skulle vara har vi ju d˚ a avhandlat lite redan.. Sen tror jag som man har satt som inriktning h¨ar p˚ a Folksam ¨ar ju att man vill ha m¨ojlighet att m¨ ata p˚ a f¨ or¨ andring. Som 2018 d˚ a vi ska ha genomf¨ort ett visst antal saker, det ¨ar ju bra att kunna se, s˚ a att s¨ aga, hur g¨ or vi d˚ a den f¨orflyttningen? D¨ar tror jag att f¨orm˚ agorna har en roll, men det ¨ ar en pusselbit bland andra, s˚ a att s¨aga. Sen finns det ju det h¨ar begreppet ”Tala med b¨ onder p˚ a b¨ onders vis” och s˚ a vidare, men det ¨ar ju litegrann det. Vissa kommer du beh¨ ova prata f¨ orm˚ agor med, andra f˚ ar du prata, liksom, systemkartor med, och en tredje kommer det vara informationsmodeller. Men det g¨aller att de h¨anger ihop och att.. Att man kan mappa allt till sammma? Ja, men liksom, pratar du om en sak med en, d˚ a f˚ ar ju inte det divergera mot andra typer av modeller f¨ or att d˚ a kommer du inte n˚ a ett gemensamt resultat. Men sen att det finns olika typer av verktyg. Jag kan se att till viss del skulle man kunna ha verktygsl˚ adan i form av f¨ orm˚ agor, ja, men den skulle kunna vara en intern angel¨agenhet f¨or arkitektur, s˚ a. Man beh¨ over inte s¨ alja p˚ a den, men d¨aremot s˚ a pratar man kanske utifr˚ an den f¨or att ha ett gemensamt ramverk, men f¨ or den delen s˚ a beh¨over man inte trycka upp en modell i ansiktet p˚ a verksamheten och s¨ aga ”Det h¨ ar ska vi anv¨anda nu!”. F¨or att det ¨ar min erfarenhet ocks˚ a, att, liksom, powerpoint i all ¨ ara, men du m˚ aste ha en acceptans fr˚ an den mottagare du har, p˚ a det s¨ attet som du vill jobba. Och visst, vill de jobba med f¨orm˚ agor och f¨orst˚ ar det och s˚ a vidare, ja, men d˚ a ska du g¨ora det. Men jag tror inte du kan tvinga p˚ a n˚ agon det, d˚ a f˚ ar man hitta p˚ a andra s¨ att. Och sen mappa hemma ist¨allet. S˚ a det ¨ar lite arbetss¨att. De h¨ ar fyra elementen, tror du de p˚ averkar f¨ orm˚ agan, eller blir p˚ averkade av den, om det sker f¨ or¨ andringar? Min syn p˚ a det ¨ ar att allts˚ a ing˚ aende delarna st¨odjer f¨orm˚ agan. S˚ a att svaret p˚ a det du sa det ¨ ar v¨ al b˚ ade och. F¨ or eftersom p˚ a n˚ at s¨att f¨or¨andrar du ingredienserna, ja men d˚ a kommer resultatet bli n˚ agot annat. Men.. Det blir s˚ a h¨ar meta-meta.. Jag menar, f¨orm˚ agan att genomf¨ ora en process, ja men det ¨ ar ju en sak, men hur den processen st¨odjer en f¨orm˚ aga, det beh¨ over ju inte vara samma f¨ orm˚ aga den st¨odjer liksom. Abstrakta saker. Vilka delar av en f¨ orm˚ aga eller elementen p˚ averkas av varandra? Hur ser mappningen mellan dem ut? Du kan ju ha beroenden mellan f¨ orm˚ agor, det kan du ju ha, i och f¨or sig, om du ska ha ett resultat. Det vi.. Jag kan visa bara hur vi f¨ors¨okte f˚ a ihop den h¨ar r¨oda tr˚ aden p˚ a SEB. D˚ a hade vi aff¨ arsmodeller, och d˚ a anv¨ande vi Business Model Canvas f¨or den. D˚ a ¨ar det egentligen en flerf¨ arltare som best˚ ar av att du har ett v¨ardeerbjudande, Value Proposition, i mitten. Du har hur du vill ha relation till dina kunder, du har dina kunder, du har kanaler. Sen p˚ a den h¨ ar sidan s˚ a har du Key Activities, Key Resources och Partners. S˚ a kan man l¨ agga en aspekt p˚ a det att man har Cost och Income. Vad vi gjorde med den h¨ ar, det var att vi hade aff¨ arsmodeller, fyra-fem stycken, inom den aff¨ar jag jobbade d˚ a. D˚ a sa vi det att det som ligger h¨ ar, Key Resources och Key Activities, det motsvarar de f¨ orm˚ agor som vi har. P˚ a en h¨ og eller en l˚ ag niv˚ a, vi satte ingen aspekt p˚ a det, men h¨ar skulle det till exempel kunna innefatta en Key Activity h¨ar ¨ar rapportering f¨or att du ska 6 Folksam’s Architecture Repository 53 f˚ a ut n˚ agon typ av v¨ ardeerbjudande till kunden h¨ar d˚ a. Det skulle kunna vara att du har IT-resurser h¨ ar eller n˚ anting annat som st¨odjer f¨orm˚ agan. S˚ a d˚ a sa vi att den kopplingen finns d˚ a. Sen sa vi ocks˚ a det att de h¨ar delarna, Key Activities och Key Resources, de kan aven bygga v¨ ¨ ardekedjor, liksom, fr˚ an b¨orjan till slut i n˚ an typ av leverans. Och d˚ a skulle de h¨ ar f¨ orm˚ agorna, s˚ a att s¨ aga, vara staplade p˚ a led d˚ a. Den anv¨ande vi inte s˚ a mycket, men den fanns i varje fall. Och sen h¨ angde vi p˚ a de h¨ar andra sakerna d˚ a, organisation och s˚ a vidare. S˚ a det var liksom v˚ aran r¨ oda tr˚ ad vi jobbade efter d¨ar. Men det man kan s¨aga h¨ar, om man skulle bortse fr˚ an den d¨ ar (BMC), och bara titta p˚ a f¨orm˚ agedelen, s˚ a skulle ju en f¨ orm˚ aga kunna best˚ a och st¨ odjas av en process p˚ a det h¨ar s¨attet. Den processen skulle ju kunna st¨ odja en annan f¨ orm˚ aga ocks˚ a. S˚ a att h¨ar har du ju ett beroende mellan f¨orm˚ agor p˚ a n˚ agot s¨ att, och likadant en organisation skulle ju kunna st¨odja olika typer av f¨orm˚ agor. Man skulle ju kunna ha en f¨ orm˚ aga, en d˚ alig f¨orm˚ aga som heter bara rapportering, det ¨ar inte s˚ a mycket av en f¨ orm˚ aga, men m¨ ojligheten att g¨ora myndighetsrapportering. Vi kommer ju g¨ ora det i en m¨ angd olika processer, f¨or en m¨angd olika rapporter. Vi kommer g¨ora det i olika organisationer ocks˚ a. Det beh¨over inte vara myndighetsrapportering, det kan vara bolagsstyrningsrapporter, eller det kan vara Solvens, det kan vara vad som helst, men det ¨ar m˚ anga saker som st¨ odjer den. Men d¨aremot att f¨orm˚ agor skulle vara beroende av f¨orm˚ agor p˚ a det h¨ ar s¨ attet (direkt kopplade), den blir lite knasigare ur ett analysh¨anseende. F¨or att d˚ a f˚ ar du liksom att en f¨ orm˚ aga, d˚ a kan du aldrig liksom lyfta ut det eller s˚ a, och d˚ a tror jag att d˚ a har man hamnat lite knasigt i vad en f¨orm˚ aga ¨ar, om man b¨orjar f˚ a beroenden mellan f¨ orm˚ agor p˚ a toppniv˚ aer. Sen l¨angre ner s˚ a kan det ju, klart, om du ska bygga ihop en v¨ ardekedja, ja men det m˚ aste ju finnas, s˚ a att s¨aga, bitar ur olika typer av f¨orm˚ agor, s˚ a, f¨or att det ska funka. Men p˚ a toppniv˚ a s˚ a tror jag att det inte ska vara kopplingar mellan. Se det mera som byggklossar som du anv¨ander f¨or att bygga ihop det st¨od du beh¨over ha d˚ a. Och litegrann den ocks˚ a, relaterat till det h¨ar med aff¨arsmodeller. Har du d˚ a en legol˚ ada h¨ ar (f¨ orm˚ agorna), s˚ a skulle du kunna bygga helt nya aff¨arsmodeller om du anv¨ander de f¨ orm˚ agorna som du har, bara det att du konfigurerar dem p˚ a ett annat s¨att. S˚ a, lite s˚ a ¨ar mina tankar. Respondent 2 Vilken position har du, hur l¨ ange har du haft den, och hur l¨ ange har du jobbat p˚ a Folksam? Jobbar som verksamhetsarkitekt, och nu jobbar jag med n˚ anting som heter Koncerngemensamt. Och det har vi v¨ al inte gjort s˚ a d¨ar j¨attel¨ange, det ¨ar v¨aldigt nytt, s˚ a det ¨ar bara n˚ agra m˚ anader gammalt. Innan dess jobbade jag som verksamhetsarkitekt inom produkt och ekonomi, och det gjorde jag i ungef¨ar tv˚ a˚ ar, knappt. Och innan dess jobbade jag ganska l¨ ange inom skadeorganisationen, ocks˚ a som verksamhetsarkitekt. Det kanske r¨acker s˚ a, men totalt sett s˚ a har jag v¨ al varit p˚ a Folksam i ungef¨ar 13 och ett halt ˚ ar, och varit i princip n¨ astan ¨ overallt utom i k¨ oket. Kortfattat, vad vet du om f¨ orm˚ agor? Ja, att det finns ju lika m˚ anga uppfattningar om vad en f¨orm˚ aga ¨ar och vad det borde vara som det finns n¨ astan personer. Sen finns det m˚ anga som vill anv¨anda olika typer av standardmodeller att utg˚ a ifr˚ an. Och jag har v¨al kommit till det l¨aget att det ¨ar v¨al klart att de ¨ ar bra, men jag tror att vi kommer aldrig bli f¨ardiga liksom ”Det h¨ar ¨ar exakt v˚ ara f¨ orm˚ agor”. Men det ¨ ar viktigt att vi har n˚ agnting att diskutera med verksamheten som de f¨ orst˚ ar och k¨ anner igen sig i, i alla fall p˚ a ett n˚ agorlunda bra s¨att. Sen kommer den ju alltid att beh¨ ova justeras. Men de beskriver ju som sagt vad man ska hantera i en aff¨ arsverksamhet, inte hur d˚ a, vilket d˚ a ¨ar en process. Hur l¨ ange har du jobbat med f¨ orm˚ agor? 54 N¨ ar det d¨ ok upp? Som f¨ orsta g˚ angen h¨ar p˚ a Folksam s˚ a har det nog varit, ja, jag skulle gissa att vi har h˚ allit p˚ a och provfuskat i ungef¨ar 2 ˚ ars tid, mer eller mindre, i olika omg˚ angar. Men det ¨ ar v¨ al egentligen inte f¨ orr¨ an nu p˚ a sistone som det har tagit lite mera skruv, om man s¨ ager s˚ a. Hur kom du i kontakt med f¨ orm˚ agor? Hur introducerades det? Var kom det ifr˚ an? Var det kom ifr˚ an? Ja, det kom i yrket, d¨arf¨or att vi har ju valt att beskriva verksamheten.. Man kan ju beskriva en verksamhet p˚ a massa olika s¨att, och vi har ju l¨ange f¨ors¨okt att dokumentera saker och beskriva saker i processer. Och vi fann d˚ a att det fanns, att det har blivit lite, s˚ a att s¨ aga, f¨ orbrukat, om man uttrycker sig s˚ a. Det vi vill hitta ¨ar en mera, s˚ a att s¨ aga, neutral beskrivning av verksamheten, och det var d˚ a som vi hittade de h¨ar, liksom, f¨ orm˚ agorna. Och f¨ ordelen med f¨ orm˚ agorna ¨ar ju att de ¨ar inte knutna till en organisation p˚ a samma s¨ att som kanske processer ¨ar, p˚ a det s¨attet. Har du anv¨ ant dig av f¨ orm˚ agor? Oh ja. Bland annat s˚ a har vi anv¨ ant det f¨or att f¨ors¨oka beskriva vad ¨ar det n˚ anting som man har f¨ or ansvar, och vad ¨ ar det som man jobbar med inom omr˚ adet Ekonomi. Och d˚ a menar jag inte organisationen Ekonomi utan hela omr˚ adet ekonomi. Att f¨ors¨oka beskriva vad ¨ ar det f¨ or verksamhet, eftersom man m˚ aste f¨ors¨oka h˚ alla r¨att p˚ a, och styra och kontrollera. Och vi kommer ocks˚ a anv¨ anda det i strategiarbetet som vi h˚ aller p˚ a med nu, inom koncerngemensamt, d¨ ar vi f¨ ors¨ oker att bed¨oma ”Hur bra m˚ ar en f¨orm˚ aga?”. Och d˚ a har vi liksom en skala, fr˚ an R¨ ott - fungerar inte alls, Orange, Gult, och Gr¨ont - fungerar kanonbra. Men sen har vi g˚ att vidare och tittat litegrann p˚ a varf¨or m˚ ar en f¨orm˚ aga inte Gr¨ont, vad beror det p˚ a? Och d˚ a g¨ or vi samma ber¨akning d¨ar, eller bed¨omning d¨ar, s˚ a h¨ar ”Beror det p˚ a processerna?”, dvs hur bra m˚ ar processerna? Och ”Hur jobbar vi gentemot andra?”. Det ar ocks˚ ¨ a huruvida vi har god kvalitet p˚ a den information vi hanterar, och allt vi tar med, det p˚ averkar ocks˚ a. En tredje viktig aspekt ¨ar ju d˚ a vilken kompetens ¨ar det egentligen vi besitter och har f¨ or att hantera den h¨ar f¨orm˚ agan. Den ytterligare biten ¨ar d˚ a ”Hur m˚ ar systemst¨ oden som ska st¨ otta de h¨ ar f¨orm˚ agorna?”, och slutligen har vi ocks˚ a en ytterligare extra variabel, det handlar ju ocks˚ a om integration, f¨or information sp¨anns ju inte mellan bara tv˚ a applikationer, utan det kan vara en hel skog med saker. Och det d¨ar f¨ors¨oker vi d˚ a anv¨ anda f¨ or att bed¨ omma, om inte en f¨orm˚ aga m˚ ar speciellt bra, vad beror den p˚ a? F¨or annars ¨ ar det ju ofta att man vill anv¨anda argument att ”Vi beh¨over ett nytt IT-st¨od”, eller ”Vi beh¨ over ett f¨ or¨ andrat arbetsst¨ od”, men ett IT-st¨od hj¨alper inte en d˚ alig process. Om man automatiserar en d˚ alig process s˚ a blir den inte b¨attre. Om man har d˚ alig information, s˚ a blir den inte b¨ attre f¨ or att de f˚ ar ett IT-st¨od. Har man inte kompetens s˚ a hj¨alper det heller inte, liksom, s˚ a det ¨ ar flera aspekter. S˚ a s˚ a h˚ aller vi, just nu i alla fall, i dagsl¨aget p˚ a att f¨ ors¨ oka beskriva ”Hur m˚ ar f¨ orm˚ agor?”, ”Hur m˚ ar verksamheten?”, och ”vad beror de h¨ ar olika sakerna p˚ a?” Vad kan du se f¨ or andra anv¨ andningsomr˚ aden f¨ or f¨ orm˚ agor? Oh, det finns en hel skog med olika typer av anv¨andningsomr˚ aden. Nej, men det ¨ar ju en lite mer neutral, s˚ a att s¨ aga, kl¨ adh¨angare d˚ a, som man kan realisera f¨orm˚ agorna till. Nu ar det ju inte s˚ ¨ a att om man nu skulle v¨alja att, till exempel, bryta ner en f¨orm˚ aga, s˚ a har vi ju sagt litegrann nu d˚ a att en f¨ orm˚ aga kan inte bli n˚ anting annat ¨an en f¨orm˚ aga. D¨aremot s˚ a kan den ha relationer med massa olika typer av saker, l¨ost h¨angande. Till exempel processer, organisation, information, kompetens, och s˚ a vidare. Men n¨ar du bryter ner en f¨orm˚ aga s˚ a blir det ingenting annat ¨ an en f¨ orm˚ aga, litegrann s˚ a. Finns det n˚ agra andra element ¨ an de du n¨ amnde, process, organisation, som du skulle vilja 55 kunna koppla ihop med en f¨ orm˚ aga? Ja, det beror sig ju alldeles p˚ a vad man ska ha det till. F¨or nu har ju vi mest anv¨ant det f¨ or att vi, s˚ a att s¨ aga, vill g¨ ora olika typer av f¨orflyttningar inom de h¨ar prim¨ara omr˚ adena. Det finns s¨ akert anledningar att titta p˚ a andra saker, till exempel Risk, vilka risker har vi? Men det h˚ aller ju liksom litegrann Risk och Compliance p˚ a att jobba litegrann med, s˚ a d¨ar f¨ ors¨ oker vi ocks˚ a anv¨ anda det litegrann. S˚ a det finns s¨akret flera s˚ ana till¨amningar d¨ar man kan, s˚ a att s¨ aga, ut¨ oka det h¨ ar f¨ or att f˚ a det lite mera neutralt. De element som ¨ ar listade h¨ ar, ¨ ar det n˚ agra du ser skulle vara relevanta att koppla till en f¨ orm˚ aga? Krav, till exempel? Ja, n¨ ar jag sen visar dig den h¨ ar bilden kan du se, vi h˚ aller p˚ a att titta lite p˚ a det, vilken information ¨ ar det som ¨ ar intressant utifr˚ an, s˚ a att s¨aga, f¨or¨andringsarbete? Och d˚ a ¨ar det ju, vilka som ¨ ar direkt kopplade till en f¨orm˚ aga, eller vilka kommer i ett senare led. S˚ a att sj¨ alvklart kan vi koppla alla dem egentligen, mer eller mindre, direkt eller indirekt, till f¨ orm˚ aga. S˚ a jag svarar ja p˚ a alla. Om man nu vill det. Men det finns inget sj¨alv¨andam˚ al, utan det ¨ ar ju, liksom, man vill ju liksom beskriva en verksamhet, man beh¨over ha n˚ an nytta, det ¨ ar d˚ a man vill ha en koppling ¨aven till f¨orm˚ agorna. S˚ a att egentligen ser jag inga direkta begr¨ ansningar, till skillnad fr˚ an till exempel processer eller andra grejer, d¨ar det kan finnas, vara lite mer ol¨ ampligt att koppla ihop olika saker. De h¨ ar elementen, varf¨ or ¨ ar just de relevanta, och hur anv¨ ander ni dem? Ja, det handlar ju f¨ orst om att f¨ ors¨ oka beskriva ”Vad har vi f¨or verksamhet?”, vi har ocks˚ a vem som ansvarar litegrann. Det ¨ ar vi inte riktigt ¨overens om, om det ska finnas n˚ agon som ansvarar f¨ or en f¨ orm˚ aga, det h˚ aller vi p˚ a och tr¨ater litegrann om. Men jag ser att det i alla fall finns ett ansvar att f¨ or¨ andra, eller f¨orb¨attra, eller att ha ett ansvar att, s˚ a att s¨aga, f¨ orm˚ agan fungerar. Men nu har vi ju inte process¨agare heller, s˚ a n¨ar vi kommer till, ja, f¨ orm˚ age¨ agare, s˚ a kanske det ligger en bit fram˚ at i tiden. Dessa element, p˚ averkar de eller blir de p˚ averkade? Ja, alla de h¨ ar elementen kan ju bidra till den h¨ar f¨orm˚ agan, p˚ a mer eller b¨attre s¨att. S˚ a tror jag det snarare ¨ ar. Att du kan, s˚ a att s¨aga, bra processer kan bidra till att vi har en bra f¨ orm˚ aga, har vi bra systemst¨od kan vi ha en bra f¨orm˚ aga, att vi har bra risk och kontroll kan bidra till den h¨ ar f¨ orm˚ agan, men kanske inte tv¨art om. S˚ a det ¨ar kanske ˚ at det h˚ allet. Men det ¨ ar s˚ a som jag spontant svarar p˚ a fr˚ agan just nu. Respondent 3 Bakgrund: Jag ¨ ar verksamhetsarkitekt p˚ a Folksam, och det har jag varit i snart tv˚ a˚ ar. S˚ a jag sitter i.. under Fredrik Wahlstr¨ om som Chef och Charlotte som teamledare, Charlotte Frank. Och bakgrunden ¨ ar ju att jag har jobbat inom IT-management och verksamhetsutveckling i 19 ˚ ar ungef¨ ar, p˚ a olika s¨ att, som konsult eller som chef, f¨or de h¨ar olika delarna d˚ a: aff¨ arsutveckling, verksamhetsutveckling och IT-management, kan man s¨aga. Och du har jobbat p˚ a Folksam sen..? Snart tv˚ a˚ ar. Kortfattat, vad vet du om f¨ orm˚ agor? 56 Ja, jag vet egentligen det som jag har.. p˚ a det s¨atter som jag har jobbat med f¨orm˚ agor h¨ ar p˚ a Folksam d˚ a i snart tv˚ a˚ ar, som vi i v˚ aran grupp har byggt upp en f¨orm˚ agekarta. Och det ¨ ar ju f¨ or att kunna beskriva vad vi utf¨or, vad vi g¨or inom Folksam. Ja, s˚ a kan man ju.. Vi har tagit fram en karta, vi har tagit fram ett index som ska ringa in hela Folksams verksamhet, allt vi g¨ or, inom alla olika delar. Och att sen kring varje f¨orm˚ aga s˚ a finns det ju en rad information, det finns processer, och ett antal olika information som h¨or till f¨orm˚ agan. Och vi brukar jobba med dem p˚ a det s¨attet att vi brukar titta vilka f¨orm˚ agor som p˚ averkas i olika f¨ or¨ andringsprojekt, f¨ or att se skillnaden mellan olika projekt. Och kunna f¨orst˚ a vilka som, ja, vilka som ber¨ or olika f¨ orm˚ agor d˚ a, olika projekt, och kunna j¨amf¨ora dem. Och prioritera mellan dem ocks˚ a. Hur l¨ ange har du jobbat med f¨ orm˚ agor? Ja det b¨ orjade jag med p˚ a Folksam, det var f¨orsta g˚ angen. S˚ a det ¨ar ett och ett halvt ˚ ar kan man s¨ aga. Hur kom du i kontakt med f¨ orm˚ agor? Hur introducerades det? Ja, det var Charlotte Frank som b¨orjade introducera det, och hon hade ¨aven hj¨alp av andra medarbetare och konsulter d˚ a, som beskrev ett uppl¨agg med en f¨orm˚ agekarta som central i det man jobbade fram. Som hade lite mallar att visa f¨or vilken information man kan kartl¨ agga i varje f¨ orm˚ aga ocks˚ a. Har du anv¨ ant dig av f¨ orm˚ agor, och i s˚ a fall hur? Ja det ¨ ar i de analyserna vi g¨ or, kring v˚ ara nya projekt eller nya initiativ. D˚ a ¨ar det i omfattningsanalyserna oftast d˚ a, som vi jobbar med att titta p˚ a vilka f¨orm˚ agor som p˚ averkas. Och det kan ocks˚ a vara d˚ a, n¨ ar vi ska j¨ amf¨ora olika projekt med varandra, omfattningsanalys eller inte, men just att se p˚ averkan p˚ a organisationen, s˚ a kan vi anv¨anda oss av f¨orm˚ agor och titta hur aff¨ arskraven tr¨ affar f¨ orm˚ agorna, det ¨ar det vanligaste s¨attet som jag har gjort i alla fall. Kan du se n˚ agra andra anv¨ andningsomr˚ aden f¨ or f¨ orm˚ agor? Ja, det ¨ ar ju egentligen i alla fall d¨ar man beh¨over ha en ¨oversikt av var man ¨ar och driver sitt arbete. Man kan j¨ amf¨ ora olika avdelningar, om det finns andra som har samma f¨ orm˚ agor, eller liknande f¨ orm˚ agor. D˚ a kan man se om man skulle kunna hj¨alpa varandra att utf¨ ora f¨ orm˚ agan p˚ a ett b¨ attre s¨ att. Eller om man kanske kan skrota f¨orm˚ agan p˚ a det ena st¨ allet och f˚ a till en effektivisering p˚ a det s¨attet d˚ a, och tj¨ana tid och resurser. Det kan ju vara i allt f¨ or¨ andringsarbete egentligen, eller f¨orb¨attringsarbete, att man b¨orjar att titta p˚ a vilka f¨ orm˚ agor man har, vilka man kanske skulle beh¨ova. Det kan vara ett annat s¨atta att t¨ anka. Och vad som saknas d˚ a, eller vad som ¨ar gap inom den nya f¨orm˚ aga som man onskar. Eller ¨ ¨ aven om det ¨ ar en befintlig f¨orm˚ aga som man har, kan det vara ett gap mellan nul¨ age och b¨ orl¨ age, d˚ a kan det vara ett s¨att att b¨orja. Vilka element vill du koppla till en f¨ orm˚ aga? Det k¨ anns som att det kan variera beroende p˚ a olika situationer, i och f¨or sig. Men hur vi jobbar inom f¨ orm˚ agan och vilka processer som finns d¨ar, ¨ar ju en del i alla fall. Och om det ¨ ar inputs/outputs eventuellt ocks˚ a, till f¨orm˚ agan. Vilka informationsobjekt som finns inom f¨ orm˚ agan, kan hj¨ alpa till. Kanske ¨aven vilka IT-system som finns d¨ar. Det h¨ar ¨ar v¨al det som ligger n¨ armast mitt jobb d˚ a, s˚ ana h¨ar delar som jag rapar upp nu d˚ a. 57 Fem attribut fr˚ an litteraturen, vilka ¨ ar relevanta? Ja, men krav ¨ ar ju ett s¨ att som vi jobbar idag faktiskt, att l¨agga in, eller koppla till f¨orm˚ agor, aff¨ arskrav oftast, ¨ ar det som ¨ ar just i v˚ aran roll d˚ a. Nu f˚ ar vi n¨astan ta en i taget d¨ar. Absolut. Resurs? Resurser. Ja precis, det kan ju vara om man j¨amf¨or hur f¨orm˚ agan utf¨ors d˚ a inom organisationen, om den finns p˚ a flera st¨allen exempelvis, och titta p˚ a hur m˚ anga resurser som jobbar med den. Att kunna j¨ amf¨ ora d˚ a i n¨asta steg, hur jobbar de med den, och varf¨or beh¨ ovs det fler resurser p˚ a ett st¨ alle ¨an ett annat st¨alle. Finns det delar i vad den h¨ar resursen utf¨ or som man kan samordna eller inte. Roller? Roller, ja. Det kanske var lite det jag touchade h¨ar precis nyss d˚ a, det kan vara flera olika roller som jobbar inom f¨ orm˚ agan, och de kan ligga n¨ara varandra eller l˚ angt ifr˚ an varandra, de kan utf¨ ora samma saker eller lite olika saker. Och det kan ju vara ett s¨att att strukturera upp ocks˚ a, s˚ a att det blir ¨annu tydligare hur f¨orm˚ agan skiljer sig p˚ a olika organisatoriska delar i f¨ oretaget. Service? ¨ det tj¨ Tj¨ anst. Ar anst p˚ a n˚ at speciellt s¨att du t¨anker, tj¨anst p˚ a v˚ ar websida, p˚ a det s¨attet, eller mer en tj¨ anst som en process. Mer ˚ at, inte s˚ a mycket websidan, utan snarare process.. N˚ anting vi utf¨ or f¨ or kunden, en s˚ an tj¨anst? Precis. Ja, hur g¨ or vi d¨ ar d˚ a. Nu ska vi se. Ja, i ett projekt s˚ a har vi ju relaterat v˚ ara nya tj¨ anster till f¨ orm˚ agor faktiskt. Det a¨r i Digitala Aff¨arer, har vi gjort. Sen har vi kanske inte sett effekterna av att jobba med det ¨an, om man s¨ager s˚ a, att vi har f˚ att ut s˚ a mycket av det. Men vi har gjort den kartl¨ aggningen i alla fall. H¨ andelser? H¨ andelser, ja, d˚ a g˚ ar ju mina tankar till v˚ ara CRM-projekt d˚ a, och CRM-verksamhet. D¨ ar har vi ju, det bygger vi helt enkelt mycket p˚ a dialoger med kunden n¨ar det h¨ander en viss, n¨ ar en viss h¨ andelse intr¨ affar f¨ or respektive kund s˚ a s¨oker vi ju kontakt f¨or att se om de har behov d˚ a, efter att den h¨ ar h¨ andelsen har intr¨affat. Om de har f˚ att barn, eller om de ar p˚ ¨ a v¨ ag att f˚ a barn, om de vill ha en gravidf¨ors¨akring exempelvis. D˚ a ¨ar det en h¨andelse. Och, ja, den skulle man beh¨ ova fundera lite mer p˚ a. Varf¨ or tycker du dessa element ¨ ar relevanta att koppla ihop med f¨ orm˚ agor, och i vilka situationer vill du anv¨ anda det? Allts˚ a, det ¨ ar sv˚ art att s¨ aga att det ¨ar klockrent i samtliga fall h¨ar och nu, men man kan se att det finns m¨ ojligheter, och att vissa delar utav dem jobbar vi med, och vissa inte lika mycket. Men om man ska, s˚ a att s¨aga, sortera upp v˚ aran verksamhet och allt vi g¨or, s˚ a 58 ¨r det v¨ a al ¨ and˚ a f¨ orm˚ agor d¨ ar vi har kommit ganska l˚ angt nu, det ¨ar d¨arf¨or jag ser att man kan bygga vidare p˚ a det. Och ¨ aven d˚ a sortera upp olika tj¨anster exempelvis. Det k¨anns som en vettig approach f¨ or att komma vidare med kartl¨aggningar som vi, som man har en chans att komma i m˚ al med ocks˚ a f¨ or hela f¨oretaget. F¨or det blir ganska stora arbeten och b¨ orja med en ny approach d˚ a tar troligtvis l¨angre tid ¨an att jobba med f¨orm˚ agor som vi har kommit en bit med. Och det k¨ anns lite enklare ¨an att jobba med processer, i m˚ anga niv˚ aer. F¨ orm˚ agor s¨ ager ganska mycket p˚ a typ, niv˚ a 3, d˚ a har man kommit ganska l˚ angt. Tror du att elementen till st¨ ortsta del blir p˚ averkade av f¨ orm˚ agan, eller p˚ averkar f¨ orm˚ agan? Hur menar du nu? Om det sker f¨ or¨ andringar, ¨ ar det elementen som p˚ averkar f¨ orm˚ agan, eller tv¨ artom? Aha. Hmm. Ja, det var en bra fr˚ aga faktiskt. Jag funderar p˚ a vad man skulle kunna ta f¨ or exempel d¨ ar. Om kraven f¨ or¨ andras inom en f¨orm˚ aga, i en f¨or¨andring, d˚ a kommer de att driva f¨ or¨ andringen p˚ a f¨ orm˚ agan, i det fallet i alla fall. Finns det n˚ agot du kan t¨ anka som skulle kunna g˚ a˚ at andra h˚ allet? Hmm. Det som h¨ ander utifr˚ an det ¨ar ju hur vi, vilka regelkrav vi har p˚ a oss, eller vilka lagar vi har. Det betyder att vi m˚ aste utveckla v˚ aran f¨orm˚ aga f¨or att kunna ta hand om nya lagar, om det ¨ ar s˚ a man t¨ anker h¨ar, jag vet inte. Och likas˚ a nya omv¨arldstrender d˚ a, det driver ju krav p˚ a nya erbjudanden d˚ a exempelvis, och f¨orb¨attrade erbjudanden. De f¨ orm˚ agorna som har att g¨ ora med att hantera erbjudanden och utveckla erbjudanden. Jag vet inte om det var ett exakt svar. Respondent 4 Bakgrund: Bakgrund p˚ a Folksam, jag har varit h¨ar i tv˚ a˚ ar, jobbar som Risk Manager, fr¨amst med operativa risker, eller verksamhetsrisker, begreppet har lite olika ben¨amningar. P˚ a det s¨attet som jag kom i kontakt med f¨ orm˚ agor, eller arkitektur, det var egentligen p˚ a grund utav att i min roll s˚ a beh¨ over vi kartl¨ agga, vi har ett behov av att beskriva en verksamhet och kartl¨ agga den p˚ a n˚ at s¨ att. F¨ or att kunna titta p˚ a var n˚ an stans i verksamheten finns det risker, och var finns det kontroller. S˚ a det var utg˚ angspunkten till f¨orm˚ agan. Kortfattat: vad vet du om f¨ orm˚ agor? I b¨ orjan, inte s˚ a mycket. Jag var mer bekant med processer. Men jag kan inte s¨aga att jag har liksom l¨ ast processteori. Och jag har jobbat med processkartl¨aggning liksom, p˚ a en v¨ aldigt oteoretisk niv˚ a. N¨ ar vi b¨ orjade med f¨orm˚ agorna s˚ a blev det ju liksom mer teoretiserat, vilket var bra. Och ¨ aven den h¨ar bakgrunden till processer, att den kommer fr˚ an processindustrin, s˚ a f¨ orm˚ agor ¨ ar liksom n¨asta steg, kan man s¨aga, i mer i , hur det fungerar i tj¨ anstef¨ oretag. Det ¨ ar l¨ attare att jobba med f¨orm˚ agor p˚ a det s¨attet. N¨ar vi b¨orjade jobba med det h¨ ar s˚ a, grundf¨ orklaringen var att f¨orm˚ agor ¨ar, ja, men ”Vad g¨or man”, medans processer ¨ ar ”Hur g¨ or man det”, vilket var ganska l¨attsm¨alt f¨orklaring. Vi har f¨ors¨okt, sen har man liksom l¨ art sig mer, och f¨ orst˚ att mer om f¨orm˚ agorna, vilket var v¨aldigt kul. Att f¨ orst˚ a hur man ska se p˚ a dem, hur de avgr¨ansar sig och f¨orh˚ aller sig till processer och var processer kan jacka in n˚ anstans. Hur l¨ ange har ni jobbat med f¨ orm˚ agor? 59 Sen tv˚ a˚ ar tillbaks, precis n¨ ar jag b¨orjade egentligen. F¨or jag hade, som en huvuduppgift var att b¨ orja processkartl¨ agga verksamheten. Och i Folksam ¨ar ju det, det har ju gjorts 100 g˚ anger, kan man s¨ aga, p˚ a lika m˚ anga niv˚ aer, med lika m˚ anga syften, ungef¨ar. Och d˚ a, s˚ a att b¨ orja, att ha utg˚ angspunkten nu, i alla fall hos oss, s˚ a var, f¨orm˚ agorna kom in som ett arkitekturst¨ od, f¨ or att kunna bygga upp ett repository kring det h¨ar. Och d˚ a vill ju vi vara med, f¨ or att vi st¨ aller krav p˚ a att vi ska ha, vi vill g¨arna f˚ a in n˚ agon form utav notation f¨ or kontroll och risk. S˚ a att man snabbt kunde f˚ a med det i repositoryt. Sen har inte det riktigt blivit s˚ a vad jag vet, sen har det liksom spritts d¨ar. Eller det har blivit lite olika, jag vet inte om det finns n˚ an notation f¨or det nu, jag vet att man i vissa projekt har byggt in kontroller, men d˚ a har man kallat det n˚ at annat ist¨allet f¨or kontroll. Det sprids ju direkt, beroende p˚ a orsakerna. N¨ amen, och det som var intressant med f¨orm˚ agorna var just det att, att f˚ a den h¨ ar bilden och beskrivning utav v¨arksamheten f¨or att kunna f¨or¨andra p˚ a ett mer effektivt s¨ att. Det ¨ ar det, det har vi ocks˚ a ett intresse utav. Hur kom du i kontakt med f¨ orm˚ agor? Kontakten kom liksom tack vare att jag tr¨affade Charlotte, eller koncernarkitektur. Och de, d˚ a var de i ett ganska tidigt stadie av att anamma f¨orm˚ agor, och b¨orja jobba med dem. S˚ a det tog en ganska l˚ ang stund innan jag f¨orstod vad det var som avs˚ ags och hur det skulle funka. Och mycket var f¨ or att, hur man, att det h¨ar med att f¨orm˚ agorna inte var tydligt beskrivna. Sen hade Charlotte med sig tv˚ a konsulter som liksom, argumenterade f¨ or f¨ orm˚ agor, och det var ju liksom inte r¨att l¨age. Jag beh¨ovde inte h¨ora argument f¨or, jag beh¨ ovde f¨ orst˚ a vad det var, liksom, och varf¨or, ist¨allet. Sen pratade de v¨aldigt mycket om kravst¨ allning p˚ a f¨ orm˚ agorna, och det liksom, nu kanske det blir dumt n¨ar du spelar in om jag ritar h¨ ar, men det som var det luriga med f¨orm˚ agorna i b¨orjan, som de liksom direkt f¨ ors¨ okte g˚ a in och f¨ orklara var att det h¨ar ¨ar f¨orm˚ agan (cirkel). Det d¨ar vet vi (fyller i 20-30%). Sen det h¨ ar (resten) vet vi inte. Och det liksom, f¨orm˚ agan s¨atts ju utifr˚ an vad den har f¨ or krav, och vad vi kravst¨ allde p˚ a. Och det var inte helt l¨att att, liksom, f¨orst˚ a. Att det var n˚ at som var p˚ a n˚ at s¨ att odefinierat, och att man skulle definiera upp det. Medans en process ¨ ar ju p˚ a n˚ at s¨ att mer definierad. S˚ a, ja. Det var lite, d¨ar i b¨orjan var det r¨origt, helt enkelt. Har du anv¨ ant dig av f¨ orm˚ agor, och hur? J¨ attemycket. Vi har ju.. I Folksam s˚ a, p˚ a grund utav hur organisationen ser ut, och en massa olika orsaker som du f˚ ar st¨ alla f¨oljdfr˚ agor p˚ a i s˚ a fall, s˚ a ¨ar det s˚ a att, som jag var inne p˚ a, att det finns j¨ attem˚ anga processer, och i en verksamhet s˚ a, om man skulle anv¨ anda processer f¨ or att beskriva verksamheten, s˚ a beh¨over man ha ett processansvar eller ett ¨ agarskap f¨ or processen, ja, processansvar. Och det ¨ar sv˚ art eftersom organisationen ¨ar v¨ aldigt stupr¨ orslik. D˚ a s˚ ag vi f¨ ordelen med f¨orm˚ agorna, eftersom f¨orm˚ agorna ¨ar liksom inte kopplade till en, det ¨ ar ingen som a¨ger f¨orm˚ agan, vilket var v¨aldigt bra. Utan f¨orm˚ agan finns d¨ ar den uppst˚ ar och d¨ ar det finns, vad ska man s¨aga, behov utav den. S˚ a det var en stor f¨ ordel som vi s˚ ag, f¨ or att det gjorde oss, plus att koncernarkitektur jobbade med det, och om vi hakade p˚ a och b¨ orjade prata om det h¨ar och jobba med det, s˚ a hj¨alpte vi dem, och de hj¨ alpte oss ˚ a andra sidan. Vi kunde s¨aga att det h¨ar finns, det har ett syfte f¨or att vi ska kunna g¨ ora den h¨ ar f¨ or¨ andringsresan enklare. Och vi beh¨ovde ocks˚ a ha n˚ agonting som funkade p˚ a en ganska h¨ og niv˚ a. Och som var best¨andigt ¨over tid. Det var viktigt, f¨or att vi beh¨ over kunna rapportera p˚ a det h¨ar, fram¨over. S˚ a ansvarsdelen, best¨andigt ¨over tid, lagom h¨ og niv˚ a men ¨ and˚ a begripligt. Man liksom f¨orst˚ ar, den s¨ager dem vad man g¨or, vad man har f¨ or f¨ orm˚ aga, sin kapabilitet. Det g˚ ar att j¨amf¨ora ocks˚ a med andra om man skulle vilja det eller f˚ ar tag i det. S˚ a.. Nu har jag tappat bort fr˚ agan.. Vad har du anv¨ and f¨ orm˚ agorna till? 60 Juste, jaja. Ja, men det var, vi tyckte det var v¨aldigt anv¨andbart. Sen s˚ a tog koncernarkitektur fram en karta som i det skedet blev n˚ agon form utav, man b¨orjade bygga den utifr˚ an en processkarta som fanns. Det hade gjorts en stor processkartl¨aggning p˚ a ett aff¨arsomr˚ ade, och sen, det h¨ ar m˚ aste du kolla med Charlotte, det h¨ar ¨ar min kvalificerade, subjektiva uppfattning om hur det ¨ ar. Att man utgick ifr˚ an det. Man tar n˚ at som man har, s˚ a utgick man ifr˚ an det, och sen s˚ a f¨ orm˚ agefisierade man det n˚ agot. Och s˚ a f¨ors¨okte man liksom bygga upp n˚ anting. Det gjorde att vi landade i en hybrid mellan f¨orm˚ aga och processkarta, vilket f¨ or mitt ¨ andam˚ al var utm¨ arkt. Det passade j¨attebra. Och det var ocks˚ a, anledningen till att det passade s˚ a bra var att vi tyckte att, ja men nu f˚ ar vi det h¨ar high-fly, p˚ a en overgripande niv˚ ¨ a, men vi f˚ ar samtidigt direkt det som jackar in, det vill s¨aga.. P˚ a en viss niv˚ a, som jag f¨ orst˚ att det, i f¨ orm˚ agorna, s˚ a kommer processer in, man brukar rita det s˚ a h¨ ar... (se foto) En f¨ orm˚ aga kan definieras av en f¨orm˚ aga, och sen kan processer komma in h¨ ar, s˚ a. Och vad skulle jag s¨ aga med det d˚ a? Jo men hybridkartan var ju redan, d˚ a hade vi f¨ orm˚ agor, och sen var processerna liksom, l˚ ag de undertill. Och vi har olika niv˚ aer, i hybridkartan hade vi niv˚ a 1, 2, och 3. Och egentligen niv˚ a 3 var processer. Och det passade alldeles utm¨ arkt f¨ or v˚ ara ¨ andam˚ al. D¨aremot s˚ a var det v¨aldigt m˚ anga, hybridkartan blev ganska stor. Det som har h¨ ant nu, som vi har gjort, det ¨ar att vi har delat upp den i en, vi har slagit is¨ ar hybridkartan, vi har renodlat den till en mer f¨orm˚ agebaserad karta och en mer processorienterad karta. Men vi har inte landat i ¨overs¨attningen, f¨or det ¨ar det man skulle vilja ha. Att se vart processerna p˚ a niv˚ a 3, vart de jackar in i f¨orm˚ agorna p˚ a niv˚ a 2, blir det v¨ al. F¨ orutom dessa, kan du se n˚ agra andra anv¨ andningsomr˚ aden f¨ or f¨ orm˚ agor? F¨ or dig, f¨ oretaget, projekt? Ja,allts˚ a, f¨ or att det du r¨ aknade upp i stort s¨att. Jag skulle vilja s¨aga att, vi strukturerade ju v˚ aran riskrapport. P˚ a riskfunktionen s˚ a skriver vi en rapport tv˚ a g˚ anger per ˚ ar. Det ¨ ar av olika anlendingar s˚ a finns det s˚ ana krav st¨allda p˚ a oss. Men det ¨ar ocks˚ a en del i st¨ odet till ledningen, i att styra verksamheten. S˚ a vi genererar de h¨ar rapporterna, och rapporterna strukturerade vi utifr˚ an f¨orm˚ agorna, p˚ a niv˚ a 1 d˚ a, som fanns. F¨or vi tyckte att, men det ¨ ar ju s˚ a bra att kunna l¨agga det p˚ a den niv˚ an, f¨or d˚ a ser man, det h¨ar ¨ar v˚ ara kapabiliteter, det h¨ ar ¨ ar v˚ ara f¨ orm˚ agor. Vad ¨ar det som det finns n˚ anstans att vi riskerar att inte kunna genomf¨ ora det h¨ ar p˚ a ett bra s¨att, eller vart brister vi i v˚ ara f¨orm˚ agor. F¨or d¨ar b¨ or man ju r¨ atta till det, om det ¨ ar en viktig f¨orm˚ aga. Och d˚ a skulle man ocks˚ a, nackdelen med det d˚ a, det ¨ ar att, eller f¨ ordelen beroende p˚ a hur man ser det, man har ju ingen som ar superansvarig, ˚ ¨ a andra sida s˚ a ¨ ar alla lite ansvariga f¨or det h¨ar. S˚ a man skulle kunna peka p˚ a flera, och oftast ¨ ar det s˚ a, att det ¨ar inte bara en som kan r¨atta till n˚ anting, utan man beh¨ over samarbeta f¨ or att f˚ a det att funka. Det ¨ar oftast det som ¨ar grundorsaken till att n˚ at g˚ ar snett, det ¨ ar att man samarbetar inte inom f¨orm˚ agan. S˚ a det var det ena. Sen det andra ¨ ar ju ocks˚ a att se vart beh¨over, vart driver vi f¨or¨andring, och vart finns det risker inom det f¨ or¨ andringsarbetet. Ja. Jag tror jag stannar d¨ar. Vilka element skulle du tycka var intressant att koppla ihop med en f¨ orm˚ aga? F¨ or mig d˚ a, om jag f˚ ar helt.. Risker, kontroller, information, system. Sen kan man ju m¨ ata det h¨ ar p˚ a olika s¨ att, det vore ocks˚ a sp¨annande. Men d˚ a ¨ar vi inne p˚ a KPI, som ¨ar Key Performance Indicator. Kostnader, men det kanske landar inom KPIer. Naturligtvis, den ¨ ar ju sj¨ alvklar, processer. Processer, system. Ja, det skulle v¨al vara ocks˚ a m¨anniskor, eller resurser. Resurser som m¨ anniskor, eller personer. Men jag vet inte riktigt hur, f¨or de kan ju liksom, nej. Ja, n˚ anting s˚ ant d¨ar. Vilka av dessa fem element tycker du ¨ ar relevanta eller inte? Krav, resurs, roll, service, 61 h¨ andelse. Kraven var jag ju inne p˚ a tidigare, resurser ocks˚ a. Service, vad kan det vara? Allts˚ a vilken service f¨ orm˚ agan, framg˚ ar inte det av sj¨alva f¨orm˚ agan? Nej, kanske inte. Det beror p˚ a, naturligtvis, hur man har beskrivit f¨orm˚ agan. Men som f¨orm˚ agan att hantera betalning eller, vi har ju en, det kan ju vara.. D˚ a ¨ar det ju p˚ a n˚ at s¨att, servicen ¨ar att vi betalar ut pengar, ja.. Okej, jag ska f¨ ors¨ oka svara p˚ a din fr˚ aga. Krav, resurser, ja, de skulle jag h˚ alla med om. Roll, service, och h¨ andelse? 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 p˚ a ocks˚ a. Men vad skulle det s¨aga? Vad ger det oss i, jo vi ser vilka personer som har, om n˚ an 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 d¨ar definitionen. F¨or jag menar resurser kan ju vara system eller information.. Ja, precis. s˚ a resurser kanske f˚ as med automatiskt om man tar med det andra du skrivit upp. Ja, det beror p˚ a hur man definierar det. Men service funderar jag p˚ a, hur det kommer ¨ det som output av f¨ in. Ar orm˚ agan, eller input till f¨orm˚ agan, eller? Snarare en output. Av f¨ orm˚ agan? Vilken service f¨ orm˚ agan levererar. Typ s˚ a? Ja. Ja. Nej, jag s˚ ag nog det som, v¨ anta. Vad ¨ar skillnaden d˚ a? Vi har en f¨orm˚ aga, vad ¨ar kapabilitet och service? Vi har en f¨ orm˚ aga att kunna levererar n˚ anting, eller g¨ora n˚ anting. Jag tyckte de var, begreppen blir liksom ganska.. Begreppen h¨ anger ihop ¨ and˚ a? Typ. Det beror lite p˚ a. Ja men som f¨orm˚ agan att g¨ora rapporter, jag tror vi har en s˚ an f¨ orm˚ aga, f¨ orm˚ agan att rapportera. Vad ¨ar servicen, jo det ¨ar en rapport, eller.. S˚ a det blir sv˚ art att s¨ arskilja? Ja, precis. Det ligger ju p˚ a n˚ at s¨ att i, kan man t¨anka n˚ at som ¨ar v˚ ar f¨orm˚ aga att g¨ora n˚ anting annat, som inte leder till n˚ an service? Allts˚ a, f¨orm˚ aga.. Kan man komma p˚ a n˚ at? F¨ orm˚ aga att drifta system? Det ¨ ar en service att... Nja, jag tycker de ¨ar n¨arliggande. Sen har vi h¨ andelser ocks˚ a. H¨ andelse. Det skulle ju vara risk, f¨ or s˚ a brukar vi ben¨amna det. Och h¨andelser, d˚ a kan det 62 vara en positiv h¨ andelse, men det kan ocks˚ a vara, oftast, en negativ h¨andelse som man vill.. Varf¨ or vill du koppla ihop just de h¨ ar elementen med f¨ orm˚ agor, och i vilka situationer skulle det vara anv¨ andbart? Egentligen i.. Okej, om jag b¨ orjar med varje attribut d˚ a. Ettan, risk. Som jag sa, i f¨ or¨ andringsarbete, eller i, framf¨ or allt en kartl¨aggning utav organisationen. F¨or att se vart n˚ anstans har vi risker. Och f¨ or att ha en risk, m˚ aste man ha ett m˚ al, det ¨ar liksom det f¨orsta, om man g˚ ar in p˚ a riskteori. Har vi inget m˚ al med n˚ anting, ja, men d˚ a har vi ju inga risker. Och det kan ju ge sig lite utav f¨ orm˚ agan. Om vi har en f¨orm˚ aga som s¨ager, vi ska leverera, vi ska g¨ ora utbetalningar. D˚ a kan man ju t¨anka sig att m˚ alet ¨ar att utbetalningarna ska komma till r¨ att person, vid r¨ att tid, och r¨att belopp. F¨or annars s˚ a k¨anns det som att vi inte levererar. D˚ a har vi f¨ orm˚ agan att g¨ora felutbetalningar i s˚ ana fall. Men det ligger i korten p˚ a n˚ at s¨ att, att m˚ alet ¨ ar att det ska bli r¨att, det ¨ar ett kvalitetskrav d˚ a, eller ett kvalitetsm˚ al. Men d¨ ar kan vi ju se om vi har, d¨ar ¨ar det ju relevant med risk, f¨or d˚ a skulle vi kunna titta p˚ a, okej, har vi n˚ agra risker kopplade till den h¨ar f¨orm˚ agan? Ja, till exempel att vi inte betalar ut i r¨ att tid, till r¨att kund, med r¨att belopp. Okej, hur bra ¨ar vi p˚ a att hantera det h¨ ar, eller finns der n˚ agra kontroller, vilket kommer in till n¨asta. Och d˚ a kan man kartl¨ agga, ja men vi s¨ akerst¨ aller den h¨ar f¨orm˚ agan, genom de h¨ar kontrollerna, och de finns h¨ ar och h¨ ar i verksamheten. Eller inom den h¨ar f¨orm˚ agan d˚ a, f¨orm˚ agan hanteras utav, d˚ a kommer vi in p˚ a, i de h¨ ar processerna, med de h¨ar rollerna eller resurserna, med de h¨ar systemen, nu namnger jag de h¨ ar olika attributen, och med den h¨ar informationen. Och det kan ju finnas risker i alla de h¨ ar olika attributen ocks˚ a, det kan ju vara systemen som ¨ar en orsak till att vi inte klarar av det. Det kan ju vara processen som s˚ adan som haltar, eller att vi inte har r¨ att roller eller att kraven inte finns tydliggjorda p˚ a vad som faktiskt ska levereras. S˚ a att i sj¨ alva riskdelen s˚ a kommer v¨aldigt m˚ anga av de h¨ar attributen in. F¨oljdfr˚ agor? Nej, det k¨ anns ganska helt¨ ackande. ¨ det n˚ Ar an som jag missade? KPIer? Det beror ju p˚ a, det ¨ar ju mer om man styr, om du har ett, om du v¨ aljer att koppla ihop.. KPIer ¨ar ocks˚ a kopplade till kanske m˚ al, i alla fall teoretiskt, s˚ a s¨ atter man m˚ al f¨ or verksamheten som man bryter ner, och g¨or om till m¨atbara m˚ al. Vi ska ha de n¨ ojdaste kunderna. Okej, men vad ¨ar en n¨ojd kund? Hur m¨ater vi det? Hur vet vi att vi n˚ ar m˚ alet? Ja, d˚ a s¨ager vi att n¨ojd kund ¨ar n¨ar 95% av v˚ ara kunder i en kundunders¨ okning s¨ ager att de ¨ ar v¨ aldigt n¨ojda p˚ a en skala 1-5, och d˚ a vill vi ha 90% ¨over 4, och sen ett visst antal 5or. D˚ a har vi en KPI, d˚ a m¨ater vi det, och d˚ a kan vi s¨aga att vi har en god f¨ orm˚ aga att, den kanske sl˚ ar p˚ a flera f¨orm˚ agor, men det kanske finns saker som man kan bryta ner utifr˚ an m˚ als¨attningar kopplade till f¨orm˚ agor, som landar n˚ anstans, till exempel. Det skulle kunna vara betalning, det skulle kunna vara svarstid i telefon, det skulle kunna vara antal annullationer eller s˚ a. Det finns en massa KPIer att bryta ner. De olika elementen, p˚ averkar de f¨ orm˚ agan eller blir de p˚ averkade? St¨ all fr˚ agan en g˚ ang till. De h¨ ar elementen, p˚ averkar de f¨ orm˚ agan, eller ¨ ar det snarare s˚ a att de blir p˚ averkade av f¨ orm˚ agan? F¨ orm˚ agan ¨ ar ju ingenting i sig. F¨ orm˚ agan best˚ ar ju av de olika attributen, hur de samverkar. S˚ a jag skulle vilja s¨ aga, f¨ orm˚ agan p˚ averkar, nu ska vi se h¨ar. Jag t¨anker h¨ogt nu. Om vi tar f¨ orm˚ agan betalningar, att g¨ ora betalningar. Om vi s¨ager att vi ska ha det som en f¨orm˚ aga, d˚ a f˚ ar vi ju indirekt ett m˚ al, att vi ska g¨ora det med n˚ an form utav kvalitet, eller enligt n˚ an form utav krav. Har vi inga krav p˚ a betalningar, d˚ a har vi inga, d˚ a kan vi g¨ora vad vi 63 vill. Har vi inga krav p˚ a f¨ orm˚ agan, a¨r det ens en f¨orm˚ aga d˚ a, om vi inte har n˚ agra krav p˚ a den? D˚ a kommer vi in p˚ a den h¨ ar definitionen, vad ¨ar en f¨orm˚ aga? D˚ a m˚ aste vi p˚ a n˚ at s¨att definiera upp. Jag skulle vilja s¨ aga att det ¨ar de h¨ar komponenterna, elementen, som bygger upp f¨ orm˚ agan. Och vissa har vi ju definierat, st¨allt krav p˚ a, som vi k¨anner till. Ja, jag skulle nog vilja se det s˚ a h¨ ar, att det ¨ ar snarare t˚ artbiten h¨ar ( 20-30% k¨anda) som p˚ averkar resten (ok¨ anda), s˚ a h¨ ar, som kommer in som en pil och p˚ averkar den h¨ar f¨orm˚ agan, ¨an att den d¨ar (ok¨ anda) p˚ averkar pilen. Det h¨ ar uppst˚ ar ju, enligt min, nu har ju jag inte l¨ast n˚ an teori om det h¨ ar, men enligt min uppfattning, s˚ a, saker h¨ar ute kan ju uppst˚ a i olika interaktioner med de h¨ ar olika elementen som vi har sagt. Det ¨ar vissa roller som, tillsammans med andra resurser, och en specifik information, som g¨or att vi kan leverera en delm¨angd av den h¨ar f¨ orm˚ agan till en specifik intressent, eller n˚ anting s˚ ant. Ja, men nu n¨ar jag liksom pratar om det och f¨ ors¨ oker beskriva det s˚ a tror jag nog mer att det ¨ar s˚ a, ¨an att det ¨ar f¨orm˚ agan som p˚ averkar de olika elementen. Jag v¨ aljer nog att se det s˚ a. Och det h¨anger nog ihop med ocks˚ a, med den h¨ ar definitionen. Att vi har processer som jackar in i f¨orm˚ agan, det kan ju h¨ anda grejer i processen som p˚ averkar den h¨ar. F¨orm˚ agan i sig s¨atter ju bara ramarna f¨ or vad vi ska g¨ ora, p˚ a n˚ agot s¨ att. Den p˚ averkar.. Ja den s¨atter nog mer ramarna. Skulle vi ha en f¨ orm˚ aga som ¨ ar, vi ska ha en f¨orm˚ aga att g¨ora d˚ aliga utbetalningar, vi ska ha en of¨ orm˚ aga, ja, en bristande f¨ orm˚ aga att g¨ora betalningar, d˚ a hade det kanske p˚ averkat. D˚ a beh¨ over vi inte ha s˚ a mycket system, vi beh¨over ¨and˚ a inte g¨ora n˚ an utbetalning i r¨att tid, allts˚ a vi kan g¨ ora den n¨ ar n˚ an kommer hit och skriker liksom. Ja, s˚ a kanske ramarna. Jo, men det blir v¨ al bra! Titta, det h¨ ar (ramarna) p˚ averkar den d¨ar (k¨anda?) delen utav t˚ artan, p˚ a n˚ at s¨ att. Ja. Respondent 5 Bakgrund: Jag har v¨ al titeln Risk Manager, och jobbar inom Risk- och Compliance-avdelningen p˚ a Folksam Sak. Jag har jobbat p˚ a Folksam i ganska precis tv˚ a˚ ar. Kortfattat: vad vet du om f¨ orm˚ agor? Ja, innan jag b¨ orjade h¨ ar s˚ a hade jag ju aldrig, inte medvetet i alla fall, kommit i kontakt med begreppet f¨ orm˚ agor, utan mer med processer. Och att, intresset h¨ar var ju f¨or att det finns ju ingen ¨ overenskommen processkarta p˚ a Folksam, och n¨ar vi d˚ a p˚ a Risk skriver riskrapporter s˚ a beh¨ ovde vi hitta n˚ at slags struktur. Man kan strukturera risker p˚ a m˚ anga olika s¨ att. Och man kan ju, till exempel, jobba p˚ a tv¨arsen och klumpa ihop dem ¨over hela verksamheten, men d˚ a blir det ju inte s˚ a intressant att veta var riskerna finns. Utan d˚ a beh¨ ovde vi hitta n˚ anting som gjorde att man kunde, liksom, mappa ihop olika risker i verksamheten mot ¨ overgripande risker. Och d˚ a fanns den h¨ar f¨orm˚ agekartan som vi, jag vet inte hur vi st¨ otte p˚ a den egentligen. Jo, vi var intresserade av att rita processer, s˚ a d¨arf¨or tog vi kontakt med Koncernarkitektur, och l¨arde oss EA, jag och min kollega Marcus som du har intervjuat d˚ a. Och sen kom vi v¨ al p˚ a att, jo men vi kanske skulle, bara s˚ a d¨ar, h¨app, liksom, att vi kanske kan strukturera riskrapporten utifr˚ an f¨orm˚ agorna. Och d˚ a gjorde vi det! F¨or, vad kan det vara, f¨ orra h¨ osten m˚ aste det vara, n¨astan. S˚ a vi har skrivit tv˚ a rapporter enligt den strukturen, vi skriver tv˚ a g˚ anger om ˚ aret. Precis, vi skriver en ny nu i h¨ost ja. Och, ja, men sen visade det sig ju d˚ a att den h¨ar f¨orm˚ agekartan som man hade tagit fram p˚ a Folksam, den var ju inte helt korrekt, utan den var ju lite en mix d˚ a mellan processer och f¨ orm˚ agor. Men jag ser ju forfarande att f¨orm˚ agorna ¨ar intressanta ur ett riskperspektiv, d¨ arf¨ or att man kan ju sk¨ ara risker p˚ a olika s¨att. Jag vet inte hur v¨al du vet hur man jobbar med risk, men det blir ju som en matris, allts˚ a f¨orm˚ agorna kontra processerna. Om vi till exempel s¨ ager att vi har stora risker i en utbetalningsprocess inom en specifik del av verksamheten. D˚ a¨ ar det ju mest intressant f¨or verksamheten att veta att det finns stora risker i den h¨ ar hanteringen, allts˚ a i den h¨ar processen. Att administrera pensioner, till exempel. 64 De ¨ ar ju inte s˚ a intresserade av att veta att det ¨ar f¨orm˚ agan Utbetala som har brister, eftersom processerna oftare f¨ oljer det organisatoriska ansvaret s˚ a ¨ar det l¨attare att anv¨anda processerna i relationen med ledningen. Men samtidigt d˚ a om man tittar p˚ a risker p˚ a en annan ledd, om man t¨ anker d˚ a IT-utveckling, p˚ a samma s¨att som Koncernarkitektur jobbar, s˚ a¨ ar det ju intressant att kunna l¨ agga ihop och titta just ”Oj, men vi har j¨attemycket risker just kopplade till utbetalningar”. Och det ¨ar ju viktigt f¨or d¨ar hanterar man ju, allt˚ a, g˚ ar det fel i utbetalningarna s˚ a¨ ar det ju v¨arre ¨an om det kanske g˚ ar fel i den h¨ar processen. S˚ a b˚ ada dimensionerna ¨ ar intressanta f¨or oss. Men vi som jobbar p˚ a Risk kommer nog alltid att vara mer intresserade av processer, egentligen. S˚ a ¨ar det. Hur l¨ ange har ni jobbat med f¨ orm˚ agor? Ja, det var ju d˚ a sen, ja men n¨ astan sen jag b¨orjade s˚ a b¨orjade vi nog nosa lite p˚ a det. Men att vi b¨ orjade ju att beskriva riskerna, fast d˚ a blir det ju lite fel att s¨aga att vi gjorde det enligt f¨ orm˚ agor, f¨ or egentligen har vi ju gjort det enligt processer, eftersom kartan ¨ar mixad. Ja, hybridkartan, s˚ a. Men ungef¨ ar tv˚ a˚ ar? Eller, ja, ett och ett halvt d˚ a kanske. Hur kom du i kontakt med konceptet f¨ orm˚ agor? Det har vi ju redan diskuterat lite. Via Koncernarkitektur, ja. Vi ville rita processer, och s˚ a fick vi reda p˚ a att de fanns. F¨ or h¨ ar hade man ju diskuterat hur Folksams processkarta s˚ ag ut fram˚ at och bak˚ at och aldrig kom till n˚ anting, och h¨ ar fanns det ju liksom en f¨ardig karta som man bara kunde s¨ aga att ”Ja, men nu anv¨ ander vi den h¨ar!”. S˚ a det var ju bra. Har du anv¨ ant dig av f¨ orm˚ agor vid n˚ agot annat tillf¨ alle ¨ an riskrapporterna? Nej, vi har inte anv¨ ant det p˚ a n˚ at annat s¨att. Jag vet inte, om det h¨ar hade varit helt r¨ att fr˚ an b¨ orjan, s˚ a vet jag inte hur vi hade anv¨ant det d˚ a, men nu var det ju inte riktigt r¨ att uppst¨ allt. Men det ¨ ar nyttigt att sk¨ara verksamheten p˚ a olika ledder, s˚ a p˚ a s˚ a s¨att tillf¨ or det n˚ at. Kan du se n˚ agra andra anv¨ andningsomr˚ aden f¨ or f¨ orm˚ agorna? Ja, men i f¨ or¨ andringsarbete ser jag det framf¨or allt. Och samtidigt m˚ aste man ju kunna beskriva verksamheten b˚ ade i ett nul¨ age och i ett.. ett nul¨age, ett m˚ all¨age, och ett f¨or¨andringsl¨age utifr˚ an n˚ an viss typ av struktur. Och d¨ar fyller det ju ett syfte. P˚ a samma s¨att som man kan beskriva processerna, men det har ju lite olika syften. S˚ a jag ser nog att, om man t¨anker ur ett organisatoriskt perspektiv, allts˚ a som chef, s˚ a tror jag att man l¨attare f¨orst˚ ar processer. Men n¨ ar man tittar p˚ a verksamheten som en helhet, s˚ a kan det ju vara mer effektivt att anv¨ anda f¨ orm˚ agorna, tror jag. Och s¨arskilt n¨ar det g¨aller IT-utveckling eller f¨or¨andring over huvud taget. F¨ ¨ or det blir ju l¨ attare suboptimering om man bara tittar i processerna, s˚ a. Finns det n˚ agra s¨ arskilda element eller s¨ arskild information du skulle vilja kunna koppla ihop med f¨ orm˚ agor? Till exempel just processer? Ja, f¨ or oss s˚ a k¨ anns det relevant. Finns det n˚ agot annat ¨ an processer? 65 Jag har nog inte t¨ ankt s˚ a l˚ angt. Det har varit tillr¨ackligt besv¨arligt att koppla ihop det med processerna. Ja, men IT-st¨ od givetvis, allts˚ a, ja. Om man t¨anker personalf¨orlyttning, allts˚ a allting som har att g¨ ora med att man f¨or¨andrar n˚ anting som ¨ar en typ av gemensam massa, s˚ a kan man ju applicera.. Ja, men du ska f¨orflytta din personal, d˚ a kan det ju vara intressant att t¨ anka ur ett f¨ orm˚ ageperspektiv ocks˚ a. H¨ ar ¨ ar fem element, fr˚ an min litteraturstudie, som du f˚ ar ta st¨ allning till om de ¨ ar relevanta eller inte. Krav, resurser, roller, service, h¨ andelse. Om man kan koppla det till f¨ orm˚ agor? Ja, om du tycker att n˚ agot spontant k¨ anns relevent eller inte. Krav k¨ anns v¨ al viktigt. Allts˚ a om man ska kravst¨alla, nu ¨ar vi inne p˚ a f¨or¨andring igen. Och resurser ¨ ar ju lite samma sak. Du anv¨ander ju olika typer av resurser i olika f¨orm˚ agor. Man kan ju effektivisera genom att t¨anka f¨orm˚ aga, tror jag. Det ska man ju inte s¨aga till de som ¨ ar processn¨ ordar, att man kan effektivisera genom att sk¨ara det p˚ a andra ledden, det beror lite p˚ a hur man vill effektivisera. Kund-effektivitet uppn˚ ar man v¨al kanske inte med f¨ orm˚ agor, men man kan internt effektivisera. Vad sa du mer? Roller, service, h¨ andelse? Roller? Krav och personal, eller resurser, k¨andes ju mest r¨att. Klart man kan koppla roller, allts˚ a, man kan koppla allt till en f¨ orm˚ aga. Men roller, h¨andelser, och vad sa du nu den sista? Service. Service. Ja, men servicen k¨ anns ju lite mer som det h¨ar med krav och s˚ a, allts˚ a om man nu vill t¨ anka utifr˚ an ett kundperspektiv, kanske att service h¨ander med. Men de andra tv˚ a ¨ar v¨ al, tror jag hellre jag skulle koppla till en.. Nej, ja.. Men det ¨ar klart, om man tittar p˚ a Utbetalning, ja men d˚ a har du ju olika roller. Och d˚ a kanske det ¨ar viktigt, d˚ a kan man ju liksom koppla, inom Utbetalning har man de h¨ar rollerna och de b¨or liksom vara likadant i alla, i all Utbetalning. Och tittar man p˚ a processen s˚ a kanske man t¨anker roller p˚ a ett annat s¨ att. Det var ingenting som jag k¨ande s˚ a h¨ar ”Nej, det g˚ ar inte”. De olika elementen, i vilka situationer skulle det vara anv¨ andbart, och varf¨ or just dessa attribut? Men det har vi nog redan tagit. Ja, precis, det tror jag nog. Kommer elementen att p˚ averka f¨ orm˚ agan, eller tv¨ artom? F¨ orm˚ agan ¨ ar v¨ al en beskrivning, s˚ a den borde v¨al inte.. Ja, men krav borde ju p˚ averka f¨ orm˚ agan. Ja, det var nog lite f¨ or abstrakt f¨or mig k¨anner jag. Det beror nog p˚ a hur man.. ¨ inte en f¨ Ar orm˚ aga en beskrivning av n˚ anting? Och d˚ a menar du att d˚ a skulle beskrivningen p˚ averka? Ja, det kanske den kan, jag vet inte. S˚ a det k¨ anns naturligare att resten p˚ averkar f¨ orm˚ agan, som krav till exempel? Ja, det g¨ or det nog. 66 Respondent 6 Bakgrund: P˚ a Folksam har jag jobbat i, det bli 14 ˚ ar nu. Time flies when you have fun. Och jobbat med just aff¨ arsarkitektur har jag gjort sedan 2010. Och det blir v¨al senaste 2 och ett halvt ˚ aren har jag suttit p˚ a aff¨ arssidan, innan dess satt jag p˚ a ITstabs-niv˚ a, med Charlotte och g¨ anget. S˚ a Aff¨ arsarkitekt? Ja. Eller, min titel p˚ a Aff¨ aren ¨ ar Aff¨arsutvecklare, men jag ¨ar certifierad aff¨arsarkitekt. Kortfattat: vad vet du om f¨ orm˚ agor? Ja, det ¨ ar ju s˚ a man ringar in vad ett f¨oretag g¨or, vad man har f¨or g¨orom˚ al, f¨or att leverera det man ska. Vi har ju jobbat mycket med processer just inom Partneraff¨aren som jag sitter p˚ a d˚ a. Vi b¨ orjade d¨ ar, till att sen utveckla det till ett f¨orm˚ aget¨ank, under ett program vi k¨ orde, under resans g˚ ang. Och kom en bit med det, f¨or att processer s¨ager inte allt, utan man f˚ angar mer saker som p˚ averkar utifr˚ an ett f¨orm˚ ageperspektiv. Men processerna finns ju d¨ ar i f¨ orst˚ as. Hur l¨ ange har du jobbat med f¨ orm˚ agor? Ja, det var, jag och Charlotte satt ju och jobbade med det h¨ar. Det var 2012-2013, satt vi och b¨ orjade. Hur kom ni i kontakt med konceptet f¨orm˚ agor? Det var Charlotte som introducerade det t¨anket lite mer. Jag hade v¨al h¨ort det, lite s˚ a d¨ ar, men inte tagit reda p˚ a riktigt mer om det s˚ a. Just d˚ a var v¨al det i ropet lite det h¨ar med industrimodeller, som i och f¨ or sig ¨ar en typ av f¨orm˚ agor, och IBMs industrimodell som sen visade sig inte funka i verkligheten. Det var lite roligt, jag tr¨affade en enterprisearkitekt hos en av v˚ ara konkurrenter, som var eld och l˚ agor ¨over IBMs modell. Och sen s˚ a st¨otte jag p˚ a honom vid n˚ at seminarie om det var tv˚ a˚ ar senare och fr˚ agade honom lite ”Ja, men hur gick det?” och han sa att ”Nej, den har vi lagt ner, det gick inte”, det funkade inte i verkligheten, s˚ a. Det var lite sp¨ annande att h¨ora. Har du anv¨ ant dig av f¨ orm˚ agor, och p˚ a vilket s¨ att? Ja, vi anv¨ ander det n¨ ar vi ska g¨ ora stora satsningar. Fr¨amst stora satsningar, man kan g¨ ora det ¨ aven p˚ a mindre men det ¨ ar mest anv¨andbart n¨ar man ska g¨ora stora satsningar, f¨ or att ringa in vad ¨ ar det som p˚ averkas av det h¨ar initiativet ni nu ska genomf¨ora. Vi vill ta oss fr˚ an plats A till plats B, hur p˚ averkar det vad vi g¨or idag? S˚ a det ¨ar ju ett v¨aldigt bra s¨ att att ringa in vad som p˚ averkas. Vi har en stor och komplex verksamhet. Gammal, over 100 ˚ ¨ ar. S˚ a att, m˚ anga saker g¨ or vi, och vi f¨ors¨oker att f˚ a en karta ¨over, men vad ¨ar det vi egentligen g¨ or i v˚ ar komplexa verksamhet. P˚ a b¨asta s¨att ringa in, man hittar ju aldrig allt, s˚ a¨ ar det ju, men man har st¨ orre chans att hitta r¨att om man ˚ atminstone har ringat in p˚ a f¨ orm˚ ageniv˚ a vad det ¨ ar som ber¨ ors. F¨ orutom detta, kan du se n˚ agra andra anv¨ andningsomr˚ aden f¨ or f¨ orm˚ agor? Ja, f¨ or dels ¨ ar det ju att ringa in vad ¨ar det som ber¨ors. Sen beh¨over man ju ocks˚ a g¨ora en bed¨ omning ”Hur sv˚ art ¨ ar det h¨ ar?”, vad ¨ar det f¨or komplexitet inbyggd i det h¨ar. F¨or 67 sen anv¨ ander man ju det f¨ or att g¨ ora en roadmap ¨over vilka steg b¨or vi ta, hur sv˚ art ¨ar de olika stegen. Och sen kan ju det ocks˚ a vara en grund till prioritering, j¨amf¨ort d˚ a med vilka ¨ det n˚ effekter man tror att man uppn˚ ar. Ar anting som ¨ar extremt sv˚ art att g¨ora, men som bara bidrar till en pyttedel av effekten, ja men d˚ a f˚ ar man kanske t¨anka om. S˚ a det ¨ar ju en bra utg˚ angspunkt f¨ or prioritering i vart man ska l¨agga sitt krut i f¨or¨andringen. Vilka element skulle du vilja kunna koppla ihop med en f¨ orm˚ aga? Eftersom jag ¨ ar aff¨ arsarkitekt s˚ a tittar jag ju p˚ a hela aff¨arsarkitekturen. Det vill s¨aga d˚ a, vi har ju liksom en ¨ overgripande strategi och inriktning. Aff¨arsmodeller, som du d˚ a vill f¨ or¨ andra ocks˚ a. Och sen utifr˚ an det d˚ a s˚ a ser man ju d˚ a p˚ a processer och f¨orm˚ agor, f¨orm˚ aga ar v¨ ¨ al d˚ a liksom en inringning av m˚ anga saker, men dels processer. Hur p˚ averkar det vad vi g¨ or i en verksamhet? Och sen s˚ a spiller ju det ocks˚ a ¨over p˚ a hur styr du arbetet som utf¨ ors, vilka kompetenser beh¨ ovs, vilket typ av IT-st¨od beh¨ovs? Och d˚ a kommer du ner p˚ a information och tekninska plattformar och allt s˚ ant. Fem element fr˚ an litteraturen, k¨ anns de relevanta eller inte? Krav, resurs, roll service, h¨ andelse. Ja, det beror p˚ a vilken fas man ¨ ar i, i f¨or¨andrningen. Vi sk¨ar det nog inte riktigt p˚ a den ledden, i det t¨ ank vi har, ¨ ar liksom min spontana k¨ansla. Men nu har ju jag inte liksom pluggat in hur vi har skivat upp v˚ ara f¨orm˚ agor just nu. Jag var bara med i b¨orjan, d˚ a hade vi beh¨ ov av att ringa in ”Vad ¨ ar det som ber¨ors?”. Och d˚ a tittade vi p˚ a vad ¨ar det f¨or typ av information, och kopplat till vilka processer g¨ors det h¨ar med h¨alp av. Och vilken typ av roller. Jag kommer inte ih˚ ag om vi kom s˚ a l˚ angt att vi kopplade p˚ a organisation eller inte. S˚ a att, liksom, ja, det g˚ ar v¨ al att ¨ overs¨atta, kan jag t¨anka. Men det a ¨r ingen av dem som spontant k¨ anns relevant? Ja men det g¨ or de nog, fast vi har kallat det f¨or annat, om man s¨ager s˚ a. ¨ det n˚ Ar agra d˚ a som verkade relevantare ¨ an andra, eller tv¨ artom? Jag tror nog att vi ser det, det d¨ ar ¨ar v¨aldigt, om vi nu uttrycker oss i IT-spr˚ ak, s˚ a ¨ar det d¨ ar IT-spr˚ ak. Vi uttrycker kanske motsvarande fast p˚ a ett annat spr˚ ak, om vi s˚ a s¨ ager. F¨ or det d¨ ar blir lite, om man t¨anker sig att man ska ha en dialog med en aff¨arssida, eller en verksamhetssida, d˚ a st¨ anger man av ”Aja, men det d¨ar ¨ar s˚ ant d¨ar tekninskt som h¨ or till IT”, det ¨ ar en r¨ att viktig aspekt, om man ska f˚ a det h¨ar att funka hela v¨agen. Eller om man vill ha det IT-internt, eller arkitektur-internt, allts˚ a, urs¨akta uttrycket, men p˚ a ”n¨ ordarkitekturniv˚ a”, s˚ a funkar det d¨ar bra. Men beh¨over man ha en dialog med en aff¨ arssida och aff¨ arschefer och alla m¨ojliga typer av roller s˚ a kanske man ska fundera p˚ a, men, de d¨ ar begreppen st¨ ammer, om man t¨anker sig rent generelt, men man kan nog f˚ a sv˚ art att f˚ a med sig alla roller i en verksamhet, genom att anv¨anda just de begreppen. Det ar min personliga erfarenhet. Men alla ¨ar ju relevanta, f¨orst˚ ¨ as. De h¨ ar elementen, i vilka situationer skulle det vara anv¨ andbart att koppla ihop dem med f¨ orm˚ agan, och varf¨ or just de elementen? Det ¨ ar egentligen om man tittar p˚ a aff¨arsutvecklingsprocessen. N¨ar man har ideer, eller man ser att man beh¨ over g¨ ora en f¨ orflyttning. Det ¨ar det h¨ar, om du t¨anker dig en projektmetodik, f¨ or att komma fram till en BP1a, faktiskt, och ringa in vad ¨ar det vi vill, och varf¨ or, och vad inneb¨ ar det h¨ ar d˚ a. Innan man k¨or liksom, go, nu k¨or vi ett eller flera projekt. S˚ a det ¨ ar ju egentligen aff¨ arsarkitekturprocessen d¨ar man d˚ a g˚ ar igenom de h¨ar stegen 68 och fyller p˚ a med den h¨ ar informationen, p˚ a en lagom ¨overgripande niv˚ a f¨orst˚ as. Annars kommer man ju in i verksamhetsanalysen och det ¨ar ju inte meningen. Utan liksom, f¨or att ha ringat in, men ”Det ¨ ar det h¨ ar vi ska g¨ora fram¨over, f¨or att..”, och g¨arna kopplat d˚ a till relevanta afff¨ arsh¨ andelser som man d˚ a kan checka av mot. Det ¨ar aff¨arsh¨andelser som styr. Elementen, p˚ averkar de f¨ orm˚ agan, eller tv¨ artom? Jamen, f¨ orm˚ agan beskriver ju den verklighet man lever i. I och f¨or sig, d¨ar kan man s¨akert ocks˚ a g¨ ora as-is och to-be. Men om du har koll p˚ a as-is, s˚ a kan du ju n¨ar du vill g¨ora en f¨ orflyttning fr˚ an punkt A till punkt B, s˚ a tittar du ner, i sin l˚ ada av f¨orm˚ agor, ja, men ”S˚ a h¨ ar ser den ut”. D˚ a kan det ju vara mer eller mindre sv˚ art. Det ¨ar ju det man f˚ ar fram d˚ a. Och sen s˚ a¨ ar det ju s˚ a, antingen ¨ ar det s˚ a att den h¨ar f¨orm˚ agan, ja, den kan vara s˚ a att, otur, det ¨ ar j¨ attesv˚ art att ¨ andra p˚ a den av n˚ an anledning, nu vet ju inte jag vad det kan vara, men, det kan ju finnas s˚ ant. Eller att den, det ¨ar s˚ a m˚ anga andra saker som str˚ alar ner i samma f¨ orm˚ aga s˚ a man kan inte ¨andra p˚ a den ur ett perspektiv, f¨or d˚ a liksom rasslar det till och f¨ orst¨ or i massa andra h¨ orn, n˚ an annan stans, som g¨or att man inte kan f¨or¨andra f¨ or mycket. Ja, d˚ a blir ju det en aspekt att ta h¨ansyn till. Eller s˚ a ¨ar det s˚ a att man tittar ner d˚ a och ser att den h¨ ar f¨ orm˚ agan ¨ar f¨or d˚ alig, vi m˚ aste f¨or¨andra den. F¨or det gagnar inte bara den h¨ ar initiativet eller den h¨ ar aff¨arsh¨andelsen, som vi ¨ar ute p˚ a marknaden med, d˚ a kan man ju f¨ or¨ andra f¨ orm˚ agan i sig. S˚ a det beror ju alldeles p˚ a. S˚ a det finns inget rakt svar p˚ a den, nej. N˚ agot annat du k¨ anner ¨ ar relevant att lyfta fram? Nej men det ¨ ar just det h¨ ar att i aff¨arsutvecklingsprocessen, inf¨or att man beh¨over s¨atta ig˚ ang ett initiativ, ett eller flera projekt som det kan vara d˚ a, s˚ a anv¨ander vi oss av det f¨or att g¨ ora komplexitetsbed¨ omningar och omfattningsanalyser och s˚ a. Som ¨ar liksom, f¨or att kunna ta fram en roadmap, som projektet ska kunna basera sitt arbete p˚ a. Respondent 7 Bakgrund: Jag ¨ ar verksamhetsarkitekt. Jag b¨ orjade p˚ a Folksam september 2013, tror jag. Jag har jobbat h¨ ar ett och ett halvt ˚ ar, kanske det blir. S˚ a att, och innan dess hade jag samma position i typ 6 ˚ ar ocks˚ a, s˚ a att jag har jobbat ganska l¨ange som verksamhetsarkitekt. Kortfattat: vad vet du om f¨ orm˚ agor? Ja, vad ska jag s¨ aga. Det ¨ ar ett omdebatterat ¨amne inom arkitektur. Jag har jobbat mycket med olika typer av f¨ orm˚ agor, ¨aven innan jag jobbade som verksamhetsarkitekt har jag jobbat med krav och kartl¨ aggningar av olika slag, jag har jobbat med upphandlingar och anv¨ ant mig av f¨ orm˚ agor ganska m˚ anga g˚ anger. S˚ a det ¨ar egentligen samla in kravst¨allning, identifiera olika hanteringar i ett f¨ oretag. Jag vet inte riktigt hur mycket, jag kan ber¨atta en hel dag om de d¨ ar olika kapabiliteter hit och dit, finns olika former. Hur l¨ ange har du jobbat med f¨ orm˚ agor? Oj. Ja, m˚ aste t¨ anka, det var kanske 2000, n¨ar jag blev konsult, som det d¨ok upp. Jag har jobbat ganska mycket med upphandlingar och d˚ a ¨ar det v¨aldigt praktiskt att jobba med f¨ orm˚ agor. F¨ or d˚ a, innan man vet hur man vill jobba, och kanske kravst¨aller p˚ a vad man beh¨ over, tj¨ anster och funktionalitet, av externa f¨oretag och service providers. Jag tror faktiskt att det ¨ ar s˚ a l¨ ange, det l˚ ater v¨aldigt.. 69 2000? Ja, d˚ a blev jag konsult, s˚ a det var v¨al d˚ a man b¨orjade t¨anka p˚ a s˚ ana saker. Hur kom du i kontakt med konceptet f¨ orm˚ agor? Det ¨ ar inom, allts˚ a, inom kartl¨ aggningar. Ofta s˚ a b¨orjar man med nul¨aget, hur ser det ut idag, och vad ¨ ar det vi hanterar idag. Vad beh¨over vi hantera i morgon f¨or att st¨otta aff¨ aren. Vi har v¨ al, som anst¨ alld inom arkitektur som jag har varit d˚ a i sju ˚ ar, ja, det ¨ar sju och ett halvt, ˚ atta ˚ ar, d˚ a blir det ju mer att man f¨orvaltar f¨orm˚ agor och kartl¨aggningar, och f¨ ors¨ oker f˚ a till n˚ agon slags ˚ ateranv¨ andbarhet i det hela. S˚ a det blir lite mer strukturerad form som linjeanst¨ alld. Har du anv¨ ant dig av f¨ orm˚ agor, och hur? Jag har ju redan n¨ amnt n˚ agra stycken. Ja det ¨ar ju massor av s¨att, i m˚ anga olika sammanhang. Men framf¨ or allt kartl¨ aggningar av verksamheter, kartl¨aggningar av ¨overgripande aff¨ arsarkitektur. Kartl¨ aggningar av organisationer, man kan titta p˚ a, till exempel, dels hur organisationsstrukturen ser ut, vad man hanterar inom dem, eller hur ska vi organisera oss f¨ or att vara effektiva. Hur ska vi jobba och hur ser v˚ ara processer ut f¨or att vara effektiva. Och sen kapsla in n˚ an slags ¨ overgripande, strategisk, allts˚ a man kartl¨agger strategiskt ”Hur p˚ averkar en ny strategi v˚ art f¨ oretag?”, och s˚ a ist¨allet f¨or att g˚ a f¨or djupt ner i processer och system, ha n˚ an slags ¨ overgripande inringning. F¨ orutom detta, ser du n˚ agra andra anv¨ andningsomr˚ aden? Allts˚ a p˚ a Folksam tycker jag att man anv¨ander f¨orm˚ agor ganska brett. B˚ ade strategiskt, och sen verksamhetsanalysm¨ assigt, och s˚ a ¨aven kravst¨allningsm¨assigt. Jag tycker att man kan dra nytta av det i en agil metod b¨attre. Jag jobbade agilt i sex ˚ ar och f¨ors¨okte f˚ a till det lite grann, f¨ or d¨ ar m¨ oter ju arkitektur agila, de h¨ar anv¨andarcentrerade metoderna. Och det ¨ ar ju, det kan vara lite sp¨ annande att se hur det fungerar ihop. Finns det n˚ agra element du vill kunna koppla ihop med en f¨ orm˚ aga? Ja, det finns egentligen.. Processer tycker jag ¨ar j¨atterelevant att koppla in, och det har jag ocks˚ a gjort i verktyg sj¨ alv. S˚ a vi har sett att det fungerar verkligen. Aff¨arsobjekt, j¨ attecentralt. Vad kommer in i en f¨orm˚ aga, och saker h¨ander inom f¨orm˚ agan med processer, organisation, och kompetenser, och sen kommer n˚ anting av v¨arde ut i f¨orm˚ agan, det aff¨ arsobjektst¨ anket gillar jag. Sen tycker jag ocks˚ a att det ¨ar intressant att koppla ihop med, vilket man inte alltid g¨ or, den logiska arkitekturen, l¨osningsarkitekturen. Den, allts˚ a g˚ a ner mer mot applikation och lyfta applikationsparken p˚ a ett logiskt l¨osningst¨ank. Och system, att inte f¨ orgl¨ omma. Allts˚ a vilka system, x, y, oxh z, alla systemen. Och sen ocks˚ a organisation. Vilka kompetenser och roller har vi i en f¨orm˚ aga, och var sitter de placerade i v˚ ar organisation. Fem element fr˚ an litteraturstudie, relevanta eller inte? Krav, resurs, roll, service, h¨ andelse. H¨ andelse? Hur t¨ anker du d˚ a, ett event? Ja, precis. Ja. Men jag tror nog att alla ¨ ar relevanta. Jag har inte kopplat ihop det med service, vilken service t¨ anker man h¨ ar? Det finns m˚ anga olika d¨ar ocks˚ a. 70 Vilken service bidrar f¨ orm˚ agan till? Okej, det som ligger inom f¨ orm˚ agan, vad ¨ar det f¨or service som man kan f¨orv¨anta sig.. Om vi s¨ ager att vi k¨ oper det externt, outsource’ar. F¨or tj¨anster, p˚ a Folksam h¨ar finns ju inte tj¨ anster i arkitekturen i den utstr¨ackning som det finns p˚ a andra bolag. d¨ar jag var tidigare i sex ˚ ar, d¨ ar byggde vi ju upp tj¨ anstearkitekturen, och det tycker jag, ja, det var ganska bra, f¨ or d˚ a beh¨ ovde man inte alltid f˚ a in det h¨ar med process, det kan ju ligga utanf¨or, om man t¨ anker mer tj¨ anst. S˚ a alla k¨ anns relevanta? Ja, men jag tycker tj¨ ansterna ¨ ar inte s˚ a, det ¨ar ocks˚ a lite infekterat ¨over ˚ aren. Men det ar inte s˚ ¨ a mycket s˚ ant t¨ ank h¨ ar. Varf¨ or k¨ anns dessa element relevanta och i vilka situationer skulle det vara anv¨ andbart att koppla dem till f¨ orm˚ agor? Alla? Eller ta en i taget, om du vill. Av de du n¨ amnde? Ja, eller av de du t¨ ankte p˚ a ocks˚ a. Okej. Nej, men det ¨ ar ju verkligen olika sammanhang. Det vi anv¨ander mest h¨ar, de h¨ ar aff¨ arsobjekten, det ¨ ar ju f¨ or att s¨akerst¨alla sj¨alva f¨orm˚ agans h˚ allbarhet, och att det ¨ar r¨ att abstraktion p˚ a den. S˚ a det ¨ ar ju, n¨ar man ringar in f¨orm˚ agor och s¨ager att vi ska ha f¨ orm˚ aga x, y, och z, hur vet vi det? Hur vet vi att det ¨ar r¨att x, y, och z, och inte t, till exempel. S˚ a att, f¨ or att kl¨ a en f¨ orm˚ aga med aff¨arsobjekt och sen organisation, allts˚ a hitta centrala delar som man vill kl¨ a sin f¨ orm˚ aga med, s˚ a man vet vad man pratar om, f¨or annars ar det bara rubriker. Och d˚ ¨ a n˚ ar man s¨allan fram till m¨anniskor med f¨orm˚ agor, d˚ a tycker de att det ¨ ar f¨ or abstrakt, de kan inte relatera till f¨orm˚ agan. S˚ a jag tror att, f¨or att f˚ a folk att relatera till f¨ orm˚ agor s˚ a¨ ar det v¨ aldigt viktigt med just aff¨arsobjekt. Sen ocks˚ a organisation, tycker jag ¨ ar viktigt. Men jag vet inte, det ¨ar s˚ a m˚ anga olika sammanhang d¨ar man kan.. ¨ Strategiskt s¨ att s˚ a tror jag att kanaler ¨ar ocks˚ a ganska intressant, distributionskanaler. Ar det digitalt, eller ¨ ar det via kundtj¨ anst, eller vilken, den har vi inte n¨amnt men den tycker jag ¨ ar, ocks˚ a, bra. R¨ acker det som svar? Jajaja, absolut. Jag ska skapa en metamodell utifr˚ an intervjuerna och det ni tycker ¨ ar intressant att koppla till f¨ orm˚ agor, som ni sen kommer f˚ a ta st¨ allning till, och f¨ orhoppningsvis kunna inkorporera den i EA Sparx ocks˚ a. Jaja, men d˚ a tror jag nog process ¨ar ganska viktigt, p˚ a en v¨aldigt h¨og niv˚ a, typ niv˚ a 2 eller n˚ anting s˚ ant. Det skulle vara bra att f˚ a en koppling till. Organisation ¨ar ju mera, allts˚ a, f¨ or¨ anderligt, eller vad man ska s¨aga, men det kan ocks˚ a vara relevant att titta p˚ a vilken enhet eller aff¨ arsomr˚ ade som florerar i vilken. P˚ averkar elementen f¨ orm˚ agan, eller tv¨ art om? Att de p˚ averkar f¨ orm˚ agan.. F¨ orm˚ agan, om man s¨ager, byggs ju upp av alla elementen. Det ¨ ar s˚ a jag bektraktar f¨ orm˚ agan, att det ¨ar en container f¨or allt det andra, f¨or att man 71 ska slippa prata om det andra f¨ or att det blir s˚ a detaljerat. Jag k¨anner s˚ a, att den, man kan ju ha en f¨ orm˚ aga och inte anv¨ anda den alls, men fr˚ agan ¨ar ju d˚ a hur l¨ange man har den f¨ orm˚ agan, i verkligheten. Allts˚ a, det finns ju en verklighet och s˚ a finns det en teori bakom f¨ orm˚ agekartl¨ aggningar, och ibland blir det ju liksom mer en teoretisk diskussion, vad som p˚ averkar det ena och det andra. Men f¨or att s¨akerst¨alla en b¨attre bild, av att man har identifierat sin f¨ orm˚ aga, liksom, i balans med de andra arkitekturniv˚ aerna, d˚ a m˚ aste man nog kl¨ a in den lite f¨ or att se, den h¨ ar omfattningen, den ¨ar relevant att ringa in en f¨orm˚ aga p˚ a. S˚ a drar man bort n˚ anting och jackar in den andra, ja, d˚ a p˚ averkas ju inringningen av f¨ orm˚ agorna, men den ¨ ar ju bara en abstraktion av den andra. S˚ a egentligen ¨ar inte f¨orm˚ agan ¨ du med vad jag menar? n˚ anting utan allt det andra. Ar Jad˚ a, inga problem. N˚ agot mer du vill f˚ a fram? Jag tror s˚ a h¨ ar, man kan ha en teoretisk bild, och det ¨ar j¨attebra att beskriva det, f¨or d˚ a kan alla f˚ a samma grund. Men sen s˚ a n¨ar man ¨ar i samtal med m¨anniskor s˚ a g¨aller det att ¨ and˚ a f˚ a grepp om behovet och grunden f¨or samtalet, och huruvida man betraktar f¨ orm˚ agan p˚ a samma s¨ att. Om den samtalspartner man har i ett m¨ote inte har samma grund, d˚ a m˚ aste 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 b¨ orjar med Folksam, l¨ange. Jag har varit h¨ar i 14 ˚ ar. 15 ˚ ar snart. Jag jobbar som Aff¨ arsarkitekt, inom ett omr˚ ade som heter AO Privat. Det ¨ar ett utav de tre aff¨ arsomr˚ adena som finns, jag vet inte hur v¨al du ¨ar bekant med organisationen? Jo, men det har jag sett. Bra. S˚ a d¨ ar sitter jag. Mitt ansvar g¨aller b˚ ade AO Privat, och det handlar framf¨or allt om distribution och v˚ art erbjudande, eget varum¨arke, och det handlar ¨aven om ansvar f¨or f¨ ors¨ aljningsdistributionskanalerna. Det ligger ocks˚ a under d¨ar. S˚ a att, s˚ a, d˚ a har vi ramat in det. Jag har haft aff¨ arsarkitektrollen sen i somras, s˚ a snart ett ˚ ar. Jag har jobbat med aff¨ arsutveckling tidigare, det ¨ ar bara det att vi har gjort en liten omorganisation, fr˚ agorna ar de samma, den ¨ ¨ ar en lite annan roll bara. Kortfattat: vad vet du om f¨ orm˚ agor? Ja, ja vad vet jag om dem? Hyfsat mycket. Sen finns det v¨al alltid mer att l¨ara sig, absolut. Jag har varit med sen vi b¨orjade arbeta med f¨orm˚ agor i Folksam. Och det vi gjorde de f¨ orsta trevande f¨ ors¨ oken, eller trevande, vi tog dem i ett praktiskt fall och anv¨ande dem, vad har vi k¨ ort det i, en fyra-fem ˚ ar, ungef¨ar. S˚ a d¨ar satt jag och Charlotte Frank, som du s¨ akert k¨ anner sedan tidigare, tillsammans med en kille som heter Roland Karlstr¨om. Och d˚ a anv¨ ande vi f¨ orm˚ agorna n¨ ar vi jobbade med strategiarbete inom f¨oretagsaff¨ar. S˚ a det ar sen dess. Sen, jag har ju.. Det ¨ ¨ ar ju f¨orm˚ agor som vi beh¨over besitta, eller besitter. Eller som vi besitter, det ¨ ar inte alltid man beh¨over dem, men f¨orm˚ agor vi besitter. Och speglar v¨ al p˚ a n˚ at s¨ att vilka kompetenser vi beh¨over. St¨od i arbetet, det ¨ar allt ifr˚ an IT-system till andra kompetenser ocks˚ a i form av st¨od. Processer, ocks˚ a. Nej men det har varit ett bra s¨att att ˚ ask˚ adligg¨ ora vad vi faktiskt g¨ or, och det ¨ar ett bra s¨att att ocks˚ a scopa in fr˚ agest¨allningar. Hur l¨ ange har ni jobbat med f¨ orm˚ agor? Jag tror vi har jobbat i drygt 4 ˚ ar. Tror jag. Vi gjorde ett jobb, och det gjorde vi runt ˚ arsskiftet, det m˚ aste ha varit fyra ˚ ar sen. Den kan vara tre, men jag tror det ¨ar fyra. 72 Hur kom du i kontakt med f¨ orm˚ agor? Det var faktiskt Charlotte som introducerade det. Vi hade gjort, vi gjorde faktiskt ett visst f¨ ors¨ ok, till och med ett ˚ ar innan dess. Det st¨ammer, det var n¨astan fem ˚ ar sen. Och jag tror att vi fick lite input ifr˚ an Sandvik, om inte jag missminner mig helt fel. Annars, den som driver sj¨ alva arbetet, s˚ a som jag ser det, det ¨ar ju Charlotte, absolut. Har du anv¨ ant dig av f¨ orm˚ agor, och hur? Absolut. Vi kan v¨ al ta ett praktexempel. Projekt, d¨ar vi talar om vilka f¨orm˚ agor som ar inom scope f¨ ¨ or projektet. Man kan ocks˚ a tydligt tala om vilka som ¨ar utanf¨or. Det ar ett s¨ ¨ att. Ett annat s¨ att som vi anv¨ander idag, det ¨ar, givet, om vi tittar p˚ a de olika aff¨ arernas olika intressen, att dra ˚ at ett eller ett annat h˚ all, ˚ at det vi vill, s˚ a kan vi tala om, p˚ a f¨ orm˚ ageniv˚ a, vilken typ av f¨ orflyttning som beh¨ovs f¨or att st¨otta det. Till exempel en strategi eller en aff¨ arsplan. S˚ a att, det ¨ar ett bra s¨att att p˚ a n˚ at s¨att f¨orst˚ a, vilken f¨orm˚ aga har vi idag, givet vad vi s¨ ager, och vad beh¨over vi f¨or¨andra. S˚ a ¨ar det, det ¨ar en bra yta att dela p˚ a, och folk verkar gilla det, det ¨ar s˚ a. Annars brukar det vara v¨aldigt sv˚ art att f˚ a olika roller att prata med varandra. S˚ a det har varit en bra spelplan. Och, som sagt, bara man har en spelplan s˚ a har vi, liksom, en gemensam syn, och bara det ¨ar bra. Kan du se n˚ agra andra anv¨ andningsomr˚ aden f¨ or f¨ orm˚ agor? Absolut. ˚ Aterigen, precis som ett projekt kan scopa in vad vi ska och inte ska g¨ora s˚ a kan man ocks˚ a tydligt tala om vad en organisation g¨or. Vi har anv¨ant den, och det ¨ar v¨ al inte bara vad jag kan se, men vi har ocks˚ a anv¨ant den n¨ar vi pratar om ansvar mellan organisationer, vem har egentligen ett ansvar. D˚ a kan man b¨orja p˚ a f¨orm˚ ageniv˚ a och mappa in vilka organisatoriska delar som har ett ansvar. Och d¨ar kanske fler tr¨affar p˚ a samma f¨ orm˚ aga, d˚ a b¨ orjar man ju undra ”Har vi ett samlat ansvar? Eller ¨ar det s˚ a att den d¨ ar f¨ orm˚ agan best˚ ar av egentligen tv˚ a delar?” S˚ a att, det har varit en bra yta att ¨aven diskutera ansvar, befogenheter, mandat. Det kan v¨al anv¨andas till allting. Jag vet att man anv¨ ander det idag f¨ or att mappa ut risker, till exempel. ˚ Aterigen, har vi valt en spelplan att beskriva, p˚ a en ¨ overgripande niv˚ a, den verksamhet vi bedriver, s˚ a kan den ju, utifr˚ an den h¨ar verksamhetens alla behov, ganska tydligt anv¨andas till allt ifr˚ an liksom, resursplaneringar, kompetensplanering, du kan g¨ ora i stort s¨att vad som helst. Vilka element vill du koppla ihop med f¨ orm˚ agorna f¨ or att det ska funka som b¨ ast f¨ or dessa anv¨ andningsomr˚ aden? Jag tyckte det var bra n¨ ar vi p˚ a n˚ at s¨att ocks˚ a mappade, mot f¨orm˚ agor, vilken organisatorisk del har ett ansvar. Den blir v¨aldigt organisatoriskt bunden, s˚ a det finns ju en ganska stor fara med det, i och f¨ or sig d˚ a. Men man kan i varje fall p˚ a en ¨overgripande niv˚ a prata om produkt till exempel, vi kommer ha en produktorganisation p˚ a ett eller annat s¨ att. Det har den varit bra f¨ or, som ett exempel. Andra bitar, ja. Det jag skulle vilja se i den annars, det ¨ ar just ”Vilka ¨ ar det som jobbar h¨ar?”, alts˚ a, vi pratar roller. Vad besitter de h¨ ar rollerna, eller beh¨ over de besitta, f¨or typ av kompetenser. Det ¨ar kanske att ta det lite f¨ or l˚ angt just nu d˚ a, men att f¨ orst˚ a rollerna, f¨orst˚ a processen eller processerna som bor i den f¨ orm˚ agan. Och det ¨ ar v¨ al ungef¨ ar det vi jobbar med just nu. Sen kommer det ju ta ett tag innan det ¨ ar klart. Sen kan man ¨onska v¨aldigt mycket, men man beh¨over f˚ a ett grepp om det som beh¨ ovs idag d˚ a. F¨ or att ˚ aterigen, en f¨orm˚ aga givet behovet av f¨orflyttning, s˚ a ar det ¨ ¨ and˚ a n¨ ar du kommer ner p˚ a processniv˚ a som saker h¨ander. Fem element fr˚ an litteraturen, k¨ anns de relevanta eller inte? Krav, resurs, roll, service, 73 h¨ andelse. Ja, vi tar dem uppifr˚ an och ner d˚ a! Okej, krav? Krav, vi har arbetat med krav. Beroende p˚ a hur man nu, vad du menar n¨ar du s¨ager krav, men om det ¨ ar n˚ agons krav inom ramen f¨or den h¨ar f¨orm˚ agan, s˚ a har vi jobbat p˚ a det s¨ attet att definiera krav. Med hj¨ alp av f¨orm˚ agor tala om hur stor, hur m˚ anga krav har vi inom en f¨ orm˚ aga. Och det handlar ocks˚ a att om man nu g¨or en utveckling, s˚ a kan det vara sv˚ art att g¨ ora n˚ agonting som ¨ ar v¨ aldigt spretigt, det tar fokus ifr˚ an fr˚ agest¨allningar, och det blir v¨ aldigt omfattande. D¨ arf¨ or ¨ar det oftast viktigt att man isolerar en aktivitet eller h¨ andelse till ett givet omr˚ ade. Och d˚ a ¨ar det bra att anv¨anda f¨orm˚ agor som ett s¨att att prioritera krav. S˚ a att, ”Vi tar den h¨ar f¨orm˚ agan f¨orst, och g¨or den bra. Sen b¨orjar vi med nummer tv˚ a och nummer tre.” Och det har vi ocks˚ a anv¨ant praktiskt. Sen har vi v¨al hittat lite andra sk¨ arningar, f¨ or f¨ orm˚ agor ¨ ar inte l¨osningen p˚ a all huvudv¨ark, men det var en bra, det var ett bra, en bra f¨ orsta grej. Och prioriterar man till exempel bort d˚ a en f¨orm˚ aga, d˚ a f¨ orsvinner ju alla krav d¨ arunder, och d˚ a kan man liksom sl¨appa den diskussionen. Det var krav. Och sen hade du? Resurs. Resurser. Ja, allt ifr˚ an IT-st¨ od 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 p˚ a hur man ser det. Service, tj¨ anst? ¨ det vilka typer av tj¨ Ar anster som beh¨ovs.. Vilka st¨ottande tj¨anster som beh¨ovs f¨or att den f¨ orm˚ agan ska uppfylla..? Ja, ungef¨ ar. D˚ a blir den v¨ aldigt teknisk. Ja, nej men absolut. ˚ Aterigen, l¨osningen p˚ a den h¨ar f¨orm˚ agan ¨r ju inte bara vilka som jobbar och hur ser processerna ut, utan hur ser faktiskt st¨odet ut. a ¨ s˚ Om de h¨ ar st¨ oden i sin tur beh¨ over, liksom, olika tj¨anster ifr˚ an A till O, a, s˚ a ¨ar det v¨al bra att man har koll p˚ a dem ocks˚ a. Men, ja, jag flummar ut lite i svaret d¨ar f¨or jag vet inte exakt vad som avses med service, d¨ ar, s˚ a att. H¨ andelse. Aktivitet d˚ a, process, aktiviteter, h¨ andelser. Som skulle bo i en f¨orm˚ aga d˚ a? Ja, eller p˚ a n˚ agot s¨ att p˚ averka f¨ orm˚ agan. Ja, jo, men s˚ a ¨ ar det v¨ al, det ¨ ar v¨al alltid en h¨andelse som p˚ a ett eller annat s¨att triggar den h¨ ar f¨ orm˚ agan att, liksom, aktiveras. Och den kan v¨al komma fr˚ an olika st¨allen och i sin tur s˚ a l¨ amnar den ju faktiskt ¨over n˚ anting. Vi ¨ar inne lite i processperspektivet p˚ a f¨ orm˚ agan d˚ a, men absolut. Men det ¨ar ju h¨andelser, de ¨ar ju h¨ogst relevanta, och de blir ju v¨ aldigt relevanta ocks˚ a n¨ ar man b¨orjar prata om f¨orflyttningar av, speciellt st¨orre 74 organisationer. ˚ Aterigen, du kan inte g¨ora allt p˚ a en och samma g˚ ang. Och d˚ a m˚ aste man f¨ orst˚ a frekvenser av h¨ andelser. Men ocks˚ a n¨ar h¨andelserna kan t¨ankas intr¨affa. F¨or d˚ a kan man ocks˚ a effektivt styra utveckling. Om n˚ anting inte h¨ander f¨orr¨an om tio ˚ ar d˚ a kanske det inte ¨ ar v¨ art att vi g¨ or det idag, d˚ a kan vi v¨anta nio ˚ ar till, s˚ a, till exempel. Varf¨ or k¨ anns dessa element k¨ anns relevanta att koppla till f¨ orm˚ aga, och skulle det vara anv¨ andbart i n˚ agra specifika situationer? Nej men det var v¨ al, de som du n¨ amnde och sen n¨amnde jag n˚ agra innan dess, det var v¨ al ungef¨ ar same same. Ja, allts˚ a, givet d˚ a att om det ¨ar verksamhetens spelplan, och d¨ar vi har f¨ orm˚ agor som sl˚ ar b˚ ade ¨ over aff¨ar, och verksamhet, och IT. Vi delar, i min v¨arld, p˚ a samma f¨ orm˚ agekarta, de finns inte i olika lager eller p˚ a andra s¨att. D˚ a kan vi anv¨anda den till precis vad som helst. Planera outsourcing, till exempel. Du kan, ˚ aterigen, hur du hanterar kompetenser i de h¨ ar, ju mer st¨od vi f˚ ar i v˚ art vardagliga arbete, desto mindre, minskar ocks˚ a kompetensbehovet p˚ a ett st¨alle men det kanske ¨okar p˚ a n˚ agot annat d˚ a. Det handlar om resurs- och kompetensplanering, absolut. Du kan koppla m˚ al till f¨orm˚ agor. Givet hur den h¨ ar f¨ orm˚ agan p˚ a n˚ agot s¨att uttrycks, hur den m˚ ar idag, hur bra b¨or den m˚ a? Sen, vi anv¨ ander ocks˚ a, jag kanske n¨amnde det tidigare, vi anv¨ander det till strategiska krav, k¨ art barn har m˚ anga namn, strategiska aff¨arskrav, aff¨arskrav, taktiska aff¨arskrav, det finns m˚ ana olika begrepp. Men strategiska krav, p˚ a ett eller annat s¨att, som har sin k¨alla i n˚ at strategidokument, oftast, kan ocks˚ a, d˚ a, mappas mot f¨orm˚ agor, vilka strategiska krav bor i den h¨ ar f¨ orm˚ agan. Fast de ligger lite ovanf¨or, ser jag ¨and˚ a, s˚ a de bor inte riktigt d¨ar, men de p˚ averkar. Elementen, p˚ averkar de f¨ orm˚ agan, eller tv¨ art om? Oj, det d¨ ar var ingen l¨ att fr˚ aga. Jag tror inte att det finns n˚ an, det ¨ar inte svart p˚ a vitt. Jag kan ge tv˚ a exempel. P˚ a ett st¨ alle d¨ar vi till exempel p˚ averkas av, d¨ar f¨orm˚ agan p˚ averkas av det som bor d¨ arinne, och tar vi mycket av den f¨orflyttning vi till exempel g¨or nu inom Folksam, s˚ a handlar mycket om att standardisera, framf¨or allt till stor del processer, och processerna bor, till n¨ astan 100%, i n˚ agt IT-st¨od. N¨ar vi k¨oper de IT-system ifr˚ a standardleverant¨ orer, s˚ a p˚ averkas ju vi av hur det h¨ar standardsystemet ¨ar utformat. Allts˚ a p˚ averkas f¨ orm˚ agan och vad som g¨ ors d¨ ar av vilket st¨od vi faktiskt har valt att anv¨anda. Och g¨or den det s˚ a kommer den att p˚ averka andra saker. S˚ a det ¨ar ett s¨att som f¨orm˚ agan p˚ averkas av det som bor d¨ arinne. Men sen finns det ju andra f¨orm˚ agor som ¨ar av kritisk karakt¨ar, mer, som har sin ram, s˚ a. Och d˚ a p˚ averkar den snarare det som bor d¨ar i. Exempel p˚ a dem ¨ar s˚ ana h¨ ar bolagsspecifika fr˚ agor. Vi har en viss typ av bolagsstruktur, och den g˚ ar inte att g¨ora v˚ ald p˚ a, inte p˚ a dag ett i varje fall. Vi har vissa juridiska perspektiv, compliance, aktuariella perspektiv som ¨ ar v¨ aldigt viktiga f¨ or oss. Och de h¨ar kraven d˚ a, inom ramen f¨or den h¨ar ¨ f¨ orm˚ agan, kommer att p˚ averka allt som hamnar d¨ar. Aven om vi k¨oper in standardsystem. Respondent 9 Bakgrund: Jag har jobbat p˚ a Folksam i sex ˚ ar. Jag ¨ar sedan augusti chef f¨or en avdelning som heter Kundanalys, som ligger under Kundstrategi, aff¨arsomr˚ ade Privat. Och jag har inte jobbat med f¨ orm˚ agor, jag har jobbat lite med aff¨arsutveckling tidigare h¨ar. S˚ a, kortfattat: vad vet du om f¨ orm˚ agor? Ja, jo, men jag har ju varit med i n˚ agra s˚ ana aff¨arsutvecklingsprojekt, s˚ a jag har kommit i kontakt med det s˚ a. Det f¨ ordes v¨al in h¨ar f¨or runt ett och ett halvt ˚ ar sen, helt pl¨ otsligt s˚ a b¨ orjade alla prata capabilities, s˚ a det var s˚ a h¨ar ”Vad ¨ar det h¨ar f¨or n˚ anting?”, 75 och d˚ a k¨ ande jag att om jag ska kunna f¨orst˚ a vad man pratar om och, liksom, hamna p˚ a samma niv˚ a s˚ a man inte f˚ ar ett spr˚ akligt ¨overtag s˚ a vill jag l¨ara mig det h¨ar. Och ocks˚ a vill jag, b¨ orjade jag tillsammans med Charlotte och Carina titta p˚ a vilka f¨orm˚ agor som finns inom mitt ansvarsomr˚ ade, f¨ or att vi ska kunna se ”Vilka f¨orm˚ agor m˚ ar inte bra?”, ”Vilka f¨ orm˚ agor m˚ ar bra?”, och hur ska vi kunna utveckla dem. Bara liksom, f¨or mig, att f˚ a upp alla korten p˚ a bordet, f¨ or det ¨ ar s˚ a l¨att att det hamnar i projekt, s˚ a det ¨ar d¨ar man jobbar med dem. Men jag har ju min vardag och det var d¨ar jag ville.. S˚ a jag p˚ ab¨orjade det arbetet i julas, och sen har jag haft en alldeles f¨or h¨og arbetsbelastning s˚ a jag har inte haft n˚ an m¨ ojlighet att forts¨ atta. Men jag har, kunde inte riktigt, se fullt ut hur man skulle anv¨anda det, men sen n¨ ar vi b¨ orjade titta p˚ a det s˚ a k¨ande jag att ”Ja, men okej, om vi b¨orjar beskriva verksamheten utifr˚ an f¨ orm˚ agor s˚ a kanske”, men jag var inte helt hemma ¨an. Du sa att det d¨ ok upp f¨ or ett och ett halvt ˚ ar sen, ungef¨ ar? Ja, jag tror det. I alla fall f¨ or mig. Cordial var ett bolag som kom hit. Och s˚ a helt pl¨ otsligt k¨ andes det som n¨ ar de kom, och man gjorde den h¨ar nya arkitekturfunktionen, man omstrukturerade massor som var, och d˚ a k¨andes det som att helt pl¨otsligt b¨orjade man prata f¨ orm˚ agor. Fr˚ an att, jag vet inte vad man pratade innan i och f¨or sig, men det k¨andes som att helt pl¨ otsligt s˚ a b¨ orjade m˚ anga prata om det. Hur kom du i kontakt med f¨ orm˚ agor? Ja, det var ju just genom ett s˚ ant aff¨arsutvecklingsprojekt, som hette ITJP, som jag var med i litegrann ett tag. Och det var d¨ar jag h¨orde ordet, och sen, d˚ a var det ocks˚ a, tillsammans med Carina Eriksson som du kanske har tr¨affat, aff¨arsarkitekt. S˚ a hon hade g˚ att n˚ an s˚ an d¨ ar aff¨ arsarkitekturutbildning, och det var d¨ar som, f¨or det ¨ar m˚ anga som har gjort den p˚ a Folksam, och d˚ a k¨ anns det pl¨ otsligt som om man kommer med ett gemensamt spr˚ ak, som inte riktigt alla f¨ orst˚ ar. Har du anv¨ ant dig av f¨ orm˚ agor? Det var ju just f¨ or att f˚ a en bild av min egen verksamhet som jag f¨ors¨okte anv¨anda, jag har inte n˚ att fullt hela v¨ agen fram, men jag kan tycka att det ¨ar ett bra s¨att att t¨anka. Men jag f˚ ar ¨ and˚ a inte ihop det riktigt med kanske processer och s˚ ad¨ar. Jag kan se hur liksom, ”Okej, det ¨ ar det h¨ ar vi ska g¨ ora”, men det, jag ¨ar inte riktigt klar. Men det kanske ¨ar f¨or att jag inte kan det heller, och jag kanske inte ska kunna det heller. Finns det n˚ agonstans d¨ ar du tror att det skulle vara anv¨ andbart att anv¨ anda f¨ orm˚ agor? Ja, men jag tror, eller jag ser det ju framf¨or allt i projekten d˚ a, vad ¨ar det vi ska g¨ora, vad ¨ ar det vi beh¨ over kunna. Men ocks˚ a just f¨or den egna verksamheten, allts˚ a, s˚ a s˚ ag jag det, utifr˚ an mitt perspektiv, att jag t¨anker att ”Vad ¨ar det vi ska g¨ora? Vad har vi f¨or f¨ orm˚ agor inom mitt verksamhetsomr˚ ade?”, och ”Vad ¨ar det vi g¨or? Hur mappar de, och vad ¨ ar det som inte m˚ ar bra?”, ”Okej, den h¨ar f¨orm˚ agan kan vi inte leverera, f¨or att..” och s˚ a kan man d˚ a hitta orsaker och kanske kan b¨orja jobba med det, s˚ a man f˚ ar upp n˚ agon slags karta. Men sen ¨ ar det ett konstigt s¨att att uttrycka sig, s˚ a jag har sv˚ art att, liksom, dra det vidare till min grupp och s¨ aga ”Nu ska vi titta p˚ a vilka f¨orm˚ agor vi har”, de bara tittar p˚ a mig, s˚ a att jag har inte riktigt hittat hur man ska, hur ska man kunna anv¨anda det i verksamheten utan att alla ska beh¨ova l¨ara sig det? Det tycker jag ¨ar sv˚ art. Finns det n˚ agot du skulle vilja koppla ihop med en f¨ orm˚ aga? Men jag t¨ anker lite s˚ a h¨ ar p˚ a processer, och hur det liksom h¨anger ihop helheten. F¨or 76 det ¨ ar ju en sak i en f¨ orm˚ aga. Men jag vet inte, jag kan f¨or lite om det. ¨ det n˚ Ar agot f¨ orutom processer som du k¨ anner vore intressant att kunna relatera till en f¨ orm˚ aga? Det har jag inte reflekterat ¨ over, men det finns det s¨akert. Ja, men det ¨ar klart att det m˚ aste finnas det. Ja, men, jag vet inte om det ¨ar s˚ a du menar, men jag t¨anker att inom mitt omr˚ ade, om man g¨ or r¨ att saker p˚ a r¨att st¨alle i organisationen. S˚ a att vi inte sitter med samma f¨ orm˚ agekort p˚ a flera st¨ allen. Jag vet inte. Lista p˚ a fem element fr˚ an literaturen, k¨ anns de relevanta att koppla till f¨ orm˚ aga eller inte? Krav, resurs, roll, tj¨ anst, h¨ andelse. Ja, men det l˚ ater ju relevant alltihopa. S˚ aklart. Det ¨ar l¨attare d˚ a, om man t¨anker utifr˚ an ett projekt, s˚ a blir det ganska tydligt. Men jag t¨ankte utifr˚ an min egen verksamhet. Finns det n˚ an s¨ arskild situation d¨ ar n˚ agon av dessa ¨ ar anv¨ andbar att koppla ihop med f¨ orm˚ aga? Ja, men i kravsituationer k¨ anns det ju ocks˚ a.. Vad hade du mer, roller och.. Resurs, tj¨ anst.. Ja, men allts˚ a, det ¨ ar ju alla de h¨ ar, som det ¨ar superrelevant, s˚ a klart. Men det k¨anns som att, i all fall utifr˚ an mitt perspektiv, s˚ a till¨ampar man det h¨ar s¨attet v¨aldigt mycket i projekt, och det ¨ ar ju j¨ attebra. Men det blir sv˚ art eftersom man har en verksamhet som man ska driva ocks˚ a, som inte riktigt ¨ar uppbyggd p˚ a samma s¨att, ¨overallt, och d˚ a ¨ar det sv˚ art, tycker jag. De h¨ ar elementen, p˚ averkar de f¨ orm˚ agan, eller tv¨ artom? Nu m˚ aste jag t¨ anka lite. Det borde ju vara s˚ a att det ¨ar f¨omr˚ agan som ska f˚ a, eller v¨anta. Att det ska vara, om man t¨ anker sig att det ¨ar en aff¨arsh¨andelse som vi m˚ aste agera p˚ a, s˚ a m˚ aste vi ju se till att vi har f¨ orm˚ agan att kunna hantera den, med kompetens och massor, krav och allt d¨ ar i. S˚ a det ¨ ar klart det m˚ aste finnas n˚ an hierarki i det d¨ar. Vi m˚ aste ju anpassa v˚ aran f¨ orm˚ aga till vad vi vill g¨ora. S˚ a t¨anker jag. Respondent 10 Bakgrund: Jag har jobbat l¨ ange p˚ a Folksam. I hela min yrkeskarri¨ar i princip, i v¨aldigt m˚ anga olika roller. Kommer fr˚ an aff¨ arssidan, verksamhet, jag har s˚ alt f¨ors¨akringar. Jobbade l¨ange med produktutveckling, haft ledande befattningar i 20-25 ˚ ar. Nu ¨ar jag specialist, men jag jobbar med styrningsfr˚ agor, governance-fr˚ agor. Och just precis nu s˚ a sitter jag och utvecklar ledningssystem f¨ or informationss¨ akerhet och kvalitet, bland annat tagit fram en certifiering. Och det som g¨ or att jag ¨ ar intresserad av f¨orm˚ agor, det egentligen grundar sig litegrann p˚ a mitt intresse, min erfarenhet, min insikt om hur vi jobbar i s˚ ana h¨ar stora, komplexa organisationer. Det ¨ ar v¨ aldigt l¨ att, vet du, att det blir dubbelkommandon, spagettisystem, dubbellagring. I verksamheten speglas det av att man har parallella processer f¨or att g¨ora samma saker. S˚ a att jag har f¨ ors¨ okt, i det jag gjort, liksom genomsyrar mitt arbete, att hitta l¨ osningar f¨ or integrera olika typer av processer och system och s˚ ana saker d˚ a. Och ur det perspektivet, n¨ ar jag blev bekant med f¨orm˚ agor, var det litegrann ”Aha, h¨ar har vi n˚ at”. S˚ a d¨ ok det upp. 77 Kortfattat: vad vet du om f¨ orm˚ agor? Ingen teoretisk grund. Men jag har st¨ott p˚ a det, jag har jobbat och ¨ar v¨aldigt bekant med arkitekturfr˚ agorna, jobbat n¨ ara dem, s˚ a att s¨aga, s˚ a jag har f˚ att information. Litegrann har jag l¨ ast, s˚ a jag f¨ orst˚ ar ju ungef¨ ar principerna f¨or det. Men det ¨ar inte min specialitet, s˚ a att s¨ aga. N¨ ar d¨ ok konceptet med f¨ orm˚ agor upp? Hur l¨ ange har du jobbat med det? Jag har varit bekant med det, tror jag relativt tidigt, sedan 4-5 ˚ ar tillbaks. Jag har f˚ att, liksom, underhandsinformation genom att jag har goda relationer till koncernarkitektur. Hur kom du i kontakt med f¨ orm˚ agor? Ja, dels har jag f˚ att information som jag sa, men konkret till¨ampning var f¨or ett par ˚ ar sen, n¨ ar jag f¨ ors¨ okte se hur jag kunde applicera det p˚ a det jag gjorde just d˚ a, n¨amligen informationss¨ akerhet. D¨ ar man s˚ ag sambanden mellan informationshantering, allt vi g¨or p˚ a Folksam handlar om information egentligen, det ¨ar immateriella tillg˚ angar, det ¨ar processer och det ¨ ar system, och s˚ a¨ ar det mycket information d˚ a. N¨ar man jobbar med arkitektur s˚ a¨ ar liksom informationshanteringen central, vilket speglas i f¨orm˚ agor, s˚ a att s¨aga d˚ a. Och det jag jobbar med ¨ ar egentligen samma sak d˚ a, n¨ar jag jobbar med ledningssystemet. Det var s¨ aker informationshantering. ”Aha.” N¨ar vi d˚ a ska, som det heter, nu ¨ar vi inne p˚ a informationss¨ akerhetsteori. N¨ ar vi d˚ a, som jag skulle g¨ora d˚ a, hitta en modell f¨or att identifiera informationstillg˚ angar, d˚ a st˚ ar ju liksom tv˚ a teorier mot varandra. D˚ a ¨ar hela det h¨ar med informationss¨ akerhet baserat p˚ a standard d˚ a, ”Vad ¨ar en informationstillg˚ ang?”, ”Hur definierar man den?”, kontra ”Hmm, vad ¨ar f¨orm˚ agor? Hur definierar man dem?”. Och d˚ a s˚ ag vi sambanden d˚ a mellan s¨ aker informationshantering, informationshantering, det vill s¨ aga informationstillg˚ angar, och f¨ orm˚ agor. Och den, i det, det var liksom en aha-upplevelse. ”Det h¨ ar kanske vi kan g¨ ora n˚ agot riktigt bra av, ist¨allet f¨or att k¨ora parallella sp˚ ar n¨ar vi ska bygga upp tv˚ a olika ledningssystem.” Det var det, n˚ an slags id´e d˚ a, som b˚ ade koncernarkitektur, som jag fick lite st¨ od av just vid det tillf¨allet, och jag d˚ a som representerade infomationss¨ akerheten n¨ ar vi skulle bygga upp ledningssystemet s˚ ag att h¨ar ¨ar n˚ anting vi kan samarbeta kring d˚ a. Det var det ena. Det andra som egentligen ¨ar samma sak, nu ¨ar det annu mer teori d˚ ¨ a, men operativ risk, Solvens-regelverk, alla pratar om risker idag, det ¨ar s˚ a mycket risker f¨ orknippat med framf¨ or allt anv¨andandet av IT, s˚ a att s¨aga va. Sociala medier, allt ¨ ar information, alla ¨ ar beroende av information. Och f¨or att, om vi ska bedriva den h¨ ar typen av verksamhet som vi g¨ or p˚ a Folksam, s˚ a m˚ aste kunder och intressenter f¨ors¨akra sig om att vi har just en s¨ aker informationshantering, f¨or annars tar vi risker, och finansinspektionen, den ¨ overvakande myndigheten, de st¨aller v¨aldigt mycket krav, och det g¨or ¨aven det h¨ ar kommande Solvens-regelverket, p˚ a operativ riskhantering. Operativ riskhantering och informationss¨ akerhet ¨ ar ungef¨ ar samma sak kan man s¨aga d˚ a. Det var en l˚ ang, f¨or att komma dit, men i alla fall. I arbetet med att identifiera, hantera, och rapportera operativa risker till ledningen s˚ a s˚ ag vi ocks˚ a en m¨ojlighet att rapportera de operativa riskerna p˚ a verksamhetsf¨ orm˚ agor till ledningen, f¨or att hitta n˚ agot s¨att att bygga upp strukturen p˚ a. Som ett alternativ till, som det hade varit dittills, att man hade gjort riskbed¨omningarna p˚ a funktionsniv˚ a. Det finns m˚ anga funktioner p˚ a Folksam, typ hundratals. Och sen s˚ a bakar man ihop det och s˚ a ger man n˚ anting, men funktionerna speglar ju inte vad man g¨or eller hur man vill att det ska vara, utan bara var m¨anniskor sitter n˚ agonstans. S˚ a det ger inte ledningen en bra bild av risksituationen i f¨oretaget. Genom att relatera till f¨orm˚ agor och en id´e om, kanske man kan koppla ihop i framtiden, att formulera m˚ al p˚ a f¨orm˚ agor, och hantera risker, allts˚ a riskerna att man inte kan uppfylla m˚ alen. F¨or det ¨ar egentligen det som risker handlar om. Det var liksom bara, s˚ a h¨ar, l¨osa tankar om det d˚ a. Nu kanske jag 78 svarar p˚ a andra fr˚ agor ocks˚ a. Men sen s˚ a var man ganska progressiva d˚ a p˚ a risksidan, och du kommer s¨ akert prata med dem ocks˚ a d˚ a, som v˚ agade ta klivet, att b¨orja rapportera, utan att man hade en underliggande struktur p˚ a verksamhetsf¨orm˚ agor, s˚ a b¨orjade man rapportera riskerna till koncernledningen p˚ a verksamhetsf¨orm˚ agor. Ja, och i det arbetet har jag liksom st¨ ott och uppmuntrat, kan man s¨ aga. Eftersom risk och informationss¨akerhet h¨anger ihop. Du har kommit in lite p˚ a n¨ asta fr˚ aga: har du anv¨ ant dig av f¨ orm˚ agor, och hur? Har du n˚ agra fler exempel? Nej, det som jag konkret har f¨ ors¨ okt anv¨anda det till, det var de tv˚ a, konkreta anv¨andningsomr˚ aden som jag f¨ ors¨ okt, liksom, bidra till eller har till¨ampat d˚ a, s˚ a att s¨aga. Naturligtvis andra, men det ¨ ar inte mitt bord d˚ a, s˚ a att s¨aga. Kan du se n˚ agra andra anv¨ andningsomr˚ aden f¨ or f¨ orm˚ agor? Man kan v¨ anda p˚ a det, vad kan det inte anv¨andas till? Nej, ja men fokus d˚ a i allt som har, vi ¨ ar styrda av, nu f¨ ors¨ oker jag t¨anka h¨ar, vi m˚ aste rapportera ekonomier p˚ a produkter och bolag. Och kostnadsst¨ allen d¨ar pengarna finns ligger ju p˚ a funktioner, det kan vi inte g¨ ora s˚ a mycket ˚ at. Det driver s˚ a att s¨aga ett funktionellt arbetss¨att, f¨or vi m˚ aste ha ekonomierna kring de h¨ ar parametrarna. Men det ¨ar ju inte det vi vill uppn˚ a, vi vill inte vara funktionsorienterade eller produktorienterade, utan vi vill ju n˚ a v˚ ara m˚ al fram¨over. Och f¨ or att n˚ a dit, allt d˚ a, ut¨ over ekonomierna, s˚ a vi kan styra mot och f¨olja upp mot, d¨ ar skulle jag vilja peta in f¨ orm˚ agorna. Allts˚ a oavsett om det ¨ar verksamhet eller den h¨ar typen av flummiga fr˚ agorna som jag jobbar med, det ¨ar risk och GRC compliance och s˚ ana saker, som underl¨ attar f¨ or ledningen att f˚ a en vy ¨over f¨oretaget i f¨orh˚ allande till var vill vi vara i framtiden, hur ser de l˚ angsiktiga m˚ alen ut, hur tar vi oss dit d˚ a, all styrning. Och kanske d˚ a fram¨ over, ¨ aven m˚ att och m¨atetal, och de delarna. S˚ a m˚ aste det sen m¨ota den ekonomiska uppf¨ oljningen, s˚ a klart. Det ¨ar min lilla v˚ ata dr¨om, om hur man ska kunna anv¨ anda f¨ orm˚ agorna fram¨ over. Utan att ha den d¨ar teoretiska, liksom, grunden f¨or vad man kan g¨ ora med f¨ orm˚ agor och s˚ a. Men jag ser, man blir l¨att euforisk n¨ar man ser de m¨ ojligheterna, den h¨ ar silverkulan i verksamheten som sk¨ar igenom allting, som inte funnits tidigare. Jag h¨ oll p˚ a att tr¨ oska r¨ att mycket med processer p˚ a 90-talet, och tyckte v¨al inte att man uppn˚ adde riktigt de effekterna med processorientering. Vilka element vill du koppla till f¨ orm˚ agan f¨ or att det ska vara anv¨ andbart i dessa situationer? Ja, jag tror att jag delvis l¨ amnade svar p˚ a det n¨ar jag sa ”Inte de ekonomiska rapporterna”, och det betyder ju allting annat, ur perspektivet styra och f¨olja upp verksamheten. D˚ a ¨ar det allts˚ a all information ur ett styrnings- och uppf¨oljningsperspektiv d˚ a. Och det betyder ju ocks˚ a att man m˚ aste sammankoppla en hel del saker. Informationsm¨angder, processer. Man m˚ aste bryta ner f¨ orm˚ agor, koppla dem till processer, koppla det till system, och g¨ora den h¨ ar kopplingen, allts˚ a det ¨ ar ju en s˚ a otroligt komplex organisation. Och det ¨ar ju den analysen som ˚ aterst˚ ar, d¨ arf¨ or kan jag inte svara p˚ a den mer konkret ¨an vad jag g¨or just nu. F¨ orutom processer och system, finns det n˚ agra andra element du k¨ anner vore intressanta? Nej, det ¨ ar ju allts˚ a process, och med process menar jag ju d˚ a liksom arbetsrutiner p˚ a operativ niv˚ a, sen ¨ ar ju det i de olika verksamheterna oavsett om det ¨ar HR eller IT, eller om det ¨ ar n˚ anting annat som g¨ ors i verksamheten. Det ¨ar ju liksom ingenting som ¨ar uteslutet d˚ a, utan det ¨ ar det som g¨ ors, d˚ a kan man hitta det p˚ a operativ niv˚ a, som ¨ar mer generiskt, d¨ ar de sen har en drivkraft d¨ar man s¨atter m˚ al p˚ a f¨orm˚ agor och sen utformar man processer, och processerna g¨ or olika saker, varf¨or man suboptimerar och springer ˚ at olika h˚ all d˚ a. S˚ a det m˚ aste ju ner p˚ a operativ niv˚ a f¨or att man ska kunna styra verksamheten i 79 ¨nskad riktning d˚ o a. Det ¨ ar s˚ a l˚ angt ner man m˚ aste komma, d˚ a tror jag inte man kan, d˚ a ska man nog ha utg˚ angspunkten att man inte exkluderar n˚ agon verksamhet. Men sen ¨ar ju det, jag menar, det ¨ ar ju ett s˚ ant d¨ ar arbete som aldrig blir klart, det ¨ar ett f¨orh˚ allningss¨att eller ett syns¨ att d˚ a. Fem element fr˚ an litteraturen, k¨ anns de relevanta att koppla till f¨ orm˚ agor? Krav, resurs, roll, tj¨ anst, h¨ andelse. Krav, ja, det ¨ ar styrning. Resurs, det beror p˚ a vad man menar med resurs. Om man menar med resurser mer typ av personal och kostnader, s˚ a ¨ar det en ekonomisk fr˚ aga och d˚ a har vi ett styrsystem som s¨ ager att det ska hanteras p˚ a ett visst s¨att. Men sen kan ju resurser vara andra typer av tillg˚ angar, det kan ju vara fastigheter, lokaler, och s˚ ana saker va, s˚ a att, man ska vara noga med definitionerna va, jag m˚ aste veta vilka resurser det avses, f¨ or vi m˚ aste hantera.. Du f˚ ar g¨ arna ha en ˚ asikt om b˚ ada. Men resurser i form utan tillg˚ angar, d˚ a kan jag vrida det p˚ a mitt s¨att och s¨aga att en resurs ¨ ar en tillg˚ ang, information ¨ ar v˚ ar viktigaste tillg˚ ang, s˚ a alla typer utav informationtillg˚ angar i den meningen att de utg¨or resurser, det m˚ aste relateras till f¨orm˚ agor om man vill uppn˚ a n˚ agonting. Och krav st¨ aller man ju p˚ a informationen. S˚ a styrning av, egentligen l¨ opande verksamheten, de resurser i form utav informationstillg˚ angar och krav p˚ a informationstillg˚ angar ur ett f¨ orm˚ ageperspektiv blir ju en viktig styrningsfr˚ aga om man ska uppn˚ a n˚ agonting. Dels det l¨ opande arbetet i sig, och sen f¨or¨andringsarbetet. Vad sa du mer? Roll, tj¨ anst, och h¨ andelse. Roll. Ja, det blir nog kanske n¨ ar man har mognat i det h¨ar om man t¨anker roller, ansvar f¨ or att utf¨ ora arbetsuppgifter, ¨ agarskap och de fr˚ agorna, s˚ a kan man ju t¨anka sig att om man har kommit en bit p˚ a v¨ ag, man m˚ aste ju mogna i det h¨ar ocks˚ a. Man kan inte b¨orja utse ¨ agare och ansvar och roller mer ¨an kanske p˚ a arkitektursidan, f¨or att driva arbete, men n¨ ar man har mognat i det h¨ ar s˚ a tror jag att fr˚ agorna addreseras, hur man ska jobba rent praktiskt, vilka roller som ska finnas. Men d¨ar ¨ar man nog inte ¨an, det tror jag man ska ta det lite f¨ orsiktigt med. S˚ a man inte tror att det ¨ar l¨osningar p˚ a den h¨ar fr˚ agan hur man ska ˚ astadkomma resultat med f¨ orm˚ agor som drivare i arbetet. Sen tj¨ anst och h¨ andelse. Ja, tj¨ anst. Det definieras ocks˚ a p˚ a olika s¨att va, beroende p˚ a vad man menar med det, men utf¨ ora en tj¨ anst eller leverera en produkt, menar jag, det ¨ar ju samma sak. Egentligen att vi utf¨ or de tj¨ anster i arbetet, levererar den produkt som kunden kr¨aver, det menar jag, i och med att vi jobbar med immateriella tillg˚ angar, det vill s¨aga utf¨or tj¨anster, vi ¨ar inte en snickerifabrik eller tillverkar bilar, s˚ a ¨ar det det l¨opande arbetet, s˚ a sj¨alvklart, ja, tj¨anst. Men du kommer f˚ a, n¨ ar du fr˚ agar runt i Folksam om tj¨anst, s˚ a kommer du f˚ a olika svar p˚ a det. Jag svarar utifr˚ an ett ISO 9001-perspektiv som ¨ar den allm¨ant vedertagna definitionen p˚ a vad tj¨ anst ¨ ar, utanf¨ or det h¨ ar f¨ oretaget. Sen finns det mycket annat som ¨ar tj¨anster ocks˚ a. H¨ andelse. Nej, det har jag ingen uppfattning om. De relevanta elementen, i vilka situationer skulle det vara anv¨ andbart att koppla dem tillf¨ orm˚ aga, och varf¨ or vill du koppla just dessa? 80 Sv˚ ar fr˚ aga. Ocks˚ a definitionsfr˚ aga, men jag tror att det har ju att g¨ora med v˚ art dagliga arbete, det ¨ ar ju objekt som du tar upp som, det finns ju naturligtvis flera, och sen ¨ar det ju som sagt definitionsfr˚ agor, men det a¨r ju s˚ adant som om man s¨ager, min uppfattning om det, att man ska styra verksamheten s˚ a att vi ˚ astadkommer ett resultat i ¨onskad riktning, och f¨ oljer upp verksamheten. D˚ a blir ju de h¨ar parametrarna, d˚ a m˚ aste man ju uppm¨arksamma dem. D˚ a h¨ anger ju v¨ aldigt mycket p˚ a det. F¨or sen liksom att konkretisera det, d˚ a m˚ aste man ner i geggan och hitta de h¨ ar entiteterna d¨ar man kopplar ihop det, och det kan jag inte ha n˚ an uppfattning om. Jag sv¨avar ganska h¨ogt d¨ar. D˚ a ¨ar det n¨astan l¨attare att kanske ta n˚ agon slags konkret exempel, och det liksom k¨anns lite sv˚ art att komma p˚ a, d˚ a m˚ aste jag fundera litegrann. Men jag tog ju ett exempel genom det som vi hade gjort i v˚ art arbete, det g˚ ar ju att oms¨ atta i produktutveckling till exempel, man kan hitta gemensamma komponenter kopplade till f¨ orm˚ agan, hur man vill att produkterna ska utformas, till processutvecklingen, gemensamma komponenter som om man definierar det som tj¨anst eller h¨ andelse eller krav f¨ or att man ska f¨or¨andra processerna, det ¨ar ju lite situationsanpassat ocks˚ a. Men det var ju det d¨ ar, man hittar det i alla verksamheter som utf¨ors oavsett om det ¨ ar IT eller mer p˚ a verksamhetssidan, i de olika ledningssystemen s˚ a hittar man ju det som m˚ aste styras f¨ or att vi ska kunna n˚ a dit. Elementen, p˚ averkar de f¨ orm˚ agan, eller tv¨ art om? Ja, det ¨ ar klart att f¨ orm˚ agan, om man s¨ager, jag ska styra, om man bryter ner styrningen i m˚ att och f¨ oljer upp att elementen r¨or p˚ a sig bara f¨or att man vill styra, s˚ a p˚ averkar ju f¨ orm˚ agestyrningen alla elementen. Annars ¨ar det meningsl¨ost att h˚ alla p˚ a. Om man f¨oljer upp s˚ a p˚ averkar ju avvikelserna i styrningen, allts˚ a att man inte har n˚ att avsett resultat, d˚ a p˚ averkar de ju f¨ orm˚ agan att uppfylla, s˚ a att s¨aga. Det ¨ar s˚ a jag vill att man ska se det. D˚ a blir det ett ledningsverktyg om man anv¨ander det p˚ a det s¨attet, och jag tror att koncernarkitektur uttalat eller outtalat har de ambitionerna, att det ¨ar ett viktigt verktyg f¨ or att kunna f¨ orflytta Folksam, och d˚ a m˚ aste man t¨anka Styrning, hmm, Uppf¨oljning, Avvikelser, M˚ al, M˚ att, bryta ner det. Respondent 11 Bakgrund: Jag ¨ ar nyanst¨ alld p˚ a Folksam. Jag b¨orjade vid ˚ arsskiftet, och har en roll som heter ITstrateg. S˚ a jag jobbar p˚ a Strategisk IT, d¨ar koncernarkitekterna sitter, men jag ¨ar d˚ a en, vad ska man s¨ aga, som en egen liten roll. Jag rapporterar till Daniel Leideberg som ¨ar chef f¨ or Strategisk IT, och sitter i den ledningsgruppen, men har inte en egen organisation. Jag ar liksom n˚ ¨ an form av specialist d˚ a. Och tanken med min roll ¨ar v¨al att jobba och st¨otta hela IT-organisationen i strategiska fr˚ agor, och driva liksom lite olika initiativ. Jag jobbar i princip bara uppdragsbaserat och har inga linjeansvar, f¨orutom kring fusioner och uppk¨op s˚ a¨ ar jag inblandad ur IT-perspektivet d˚ a. Och framf¨or allt nu s˚ a h˚ aller jag p˚ a och jobbar med en systemstrategi f¨ or utvecklingsomr˚ adet inom koncerngemensamt st¨od, som ekonomi och HR och s˚ ad¨ ar. Kortfattat: vad vet du om f¨ orm˚ agor? Ja, begreppet som s˚ adant ¨ ar v¨ al lite nytt f¨or mig. Jag har ofta, jag tror nog att jag har, s˚ a att s¨ aga, arbetat med det innan, ¨aven om jag ofta sj¨alv har t¨ankt i termer av, liksom, funktioner, allts˚ a det ¨ ar n˚ anting vi g¨or, och det ¨ar v¨al, tror jag, i mitt huvud, bara en anna label p˚ a vad det handlar om d˚ a. Och nu innan jag b¨orjade p˚ a Folksam s˚ a har jag jobbat som konsult p˚ a Accenture sen 2007, och d¨ar har jag ju ofta liksom hanterat de fr˚ agest¨allningarna, ”Vad a¨r det vi vill ˚ astadkomma?”, “Vad ¨ar det f¨or n˚ at vi ska kunna g¨ora?”, och liksom, hur 81 g¨ or vi de f¨ or¨ andringarna d˚ a. S˚ a, som tanke ¨ar det v¨al i mitt huvud, men just att kalla det f¨ or f¨ orm˚ agor har jag v¨ al b¨ orjat g¨ ora h¨ar p˚ a Folksam d˚ a, tror jag. S˚ a n¨ ar du b¨ orjade jobba med just f¨ orm˚ agor var n¨ ar du b¨ orjade p˚ a Folksam? Ja, som begrepp s˚ a. Men som definition har det v¨al ofta funnits med mig. Hur kom du i kontakt med f¨ orm˚ agor? Ja, h¨ ar ¨ ar det ju f¨ or att i det team som jag leder kring den h¨ar systemstrategin s˚ a ¨ar det tre stycken arkitekter som jag jobbar med, och d˚ a, och ¨aven i min introduktion till f¨ oretaget s˚ a satt jag ner med Charlotte, till exempel, ja, och med Robert och Stefan Reifalk och s˚ a, s˚ a det kom v¨ al in ganska snabbt d¨ar, hur man jobbar med den kartl¨aggningen. Och vi satt och tittade p˚ a en del arbete som har gjorts kring f¨orm˚ agekartl¨aggning inom ekonomiorganisationen och s˚ ad¨ ar. Har du anv¨ ant dig av f¨ orm˚ agor, och i s˚ a fall hur? Ja, vi, i systemstrategiarbetet s˚ a har vi ju, en del i det ¨ar ju att, vi f¨ors¨oker ju m˚ ala upp en m˚ albild f¨ or v˚ art applikationslandskap. Och det ska ju st¨odja funktionalitet, eller f¨ orm˚ agor. Och ¨ an s˚ a l¨ ange s˚ a pratar vi v¨aldigt mycket om de m˚ albilderna och den h¨ar m˚ alfunktionaliteten, eller logiska IT-st¨odet, eller f¨orm˚ agor. S˚ a i de termerna har vi v¨al b˚ ade varit i det gr¨ anslandet, och sen nu de n¨asta steg som kommer, s˚ a handlar det mycket om att se ”Var ¨ ar vi i nul¨ aget?” och ”Vad ¨ar det f¨or n˚ at vi klarar av att g¨ora idag?” och ”Vad ar det f¨ ¨ or gap mot det vi vill?”. Och i det s˚ a handlar det ju b˚ ade om att titta p˚ a systemen men ocks˚ a d˚ a ta f¨ orm˚ agekartl¨ aggningen ett steg l¨angre och k¨anna att vi har tr¨affat r¨att d¨ar. Kan du se n˚ agra andra anv¨ andningsomr˚ aden f¨ or f¨ orm˚ agor? Ja, allts˚ a, jag tycker v¨ al, generellt, s˚ a n¨ar man kommer som ny p˚ a Folksam, om vi nu antar att det h¨ ar blir Folksam-specifikt, s˚ a ¨ar det ganska sv˚ art att f˚ a en ¨overblick och f¨orst˚ aelse f¨ or vad ¨ ar det man g¨ or var, och g¨ or man samma typ av sak p˚ a flera st¨allen, och varf¨or g¨or man det, och s˚ ad¨ ar. Och i det d¨ ar arbetet vi h˚ aller p˚ a med nu, s˚ a jobbar vi ju ¨aven med FAR, framf¨ or allt f¨ or att b¨ orja f¨ ors¨ oka f˚ a till en annan dokumentation kring de system som vi har. Men d¨ ar ser, m˚ aste ju f¨ orm˚ agorna komma in s˚ a att man kan f˚ a en koppling b˚ ade till organisation, som, vad s¨ ager man, st¨oder eller genomf¨or de h¨ar f¨orm˚ agorna. Systemen som ska st¨ otta och liksom hur de h¨ anger ihop, s˚ a det ¨ar ju, liksom, att f˚ a ¨overblicken, och kunna f¨ orst˚ a om vi nu ska g¨ ora f¨ or¨ andringar h¨ar, och liksom, flytta p˚ a n˚ anting, eller ja, fusioner och uppk¨ op, om vi k¨ oper ett bolag. Hur passar det in i v˚ arat pussel, och vad ¨ar det f¨or typ av synergier vi kan f˚ a, eller vad ¨ar det f¨or problem det h¨ar kommer att st¨alla till, eller kommer vi. D¨ ar tror jag att man har v¨aldigt stor nytta av att f¨orst˚ a sin egen f¨orm˚ aga, vilka de ¨ ar och var de finns och hur vi arbetar med det. Men jag tror att det ¨ar v¨aldigt viktigt att, ja men, FAR eller n˚ at typ av verktyg som, s˚ a att man kan ha all den h¨ar informationen. F¨ or bara en f¨ orm˚ agekartl¨ aggning i n˚ an form av bild som inte r¨or p˚ a sig, eller bild som inte har kopplingar till annat, den blir ju inaktuell och till slut ganska v¨ardel¨os, n¨ar man inte ser hur det h¨ anger ihop med m¨ anniskorna som utf¨or det eller systemen som st¨oder det eller vad det nu ¨ ar. S˚ a, ja, var det ett svar? Jad˚ a. Vilka element vore intressanta att relatera till f¨ orm˚ agor? Du n¨ amnde organisationer och system, finns det n˚ agra andra? Ja, det tycker jag. Man har ju tagit fram ett v¨ardedrivartr¨ad, eller en v¨ardedrivarlogik, som vi s˚ a att s¨ aga ska mappa in de olika initiativ och projekt som vi har. Det ¨ar liksom, 82 vad ¨ ar det f¨ or, ”Vad bidrar det h¨ ar med?”, och s˚ a finns det ett antal huvudgrupper p˚ a v¨ arden och sen s˚ a nedbrutet. D¨ ar tycker jag ju man b¨or kunna hitta en koppling, att en f¨ orm˚ aga kan s¨ akert bidra till, eller b¨or ju bidra till en eller flera av v˚ ara toppv¨ardedrivande koncept d˚ a. F¨ or g¨ or de inte det kan man ju fr˚ aga sig ”Varf¨or har vi den h¨ar?”. Och d˚ a b¨ or man ocks˚ a kunna f¨ orst˚ a vilka f¨ orm˚ agor ¨ar det som ¨ar viktiga, och vi kanske ser, fattas det f¨ orm˚ agor, eller? Och sen s˚ a skulle man ju ¨aven vilja f˚ a n˚ agon form av, ja, vad ska man kalla det? H¨ alsom¨ atning? Allts˚ a, hur ¨ar f¨orm˚ agan, hur m˚ ar den? Och vad best˚ ar den av? ¨ det bara kunskap, eller ¨ar Vad ¨ ar det som kr¨ avs f¨ or att f¨ orm˚ agan ska uppr¨atth˚ allas? Ar det systemst¨ od, eller vad ¨ ar det f¨ or n˚ at vi beh¨over f¨or att kunna exekvera p˚ a den h¨ar, och hur m˚ ar vi. F¨ or d˚ a kan man ju ocks˚ a b¨orja f¨orst˚ a vad ¨ar det vi beh¨over, liksom, var kan vi bli mer effektiva eller mer duktiga. Och p˚ a samma s¨att som att f¨orm˚ agor d˚ a knyter an till v˚ ara v¨ ardedrivare, s˚ a b¨ or man ju ¨aven, tycker jag, f¨or att f¨orst˚ a, om man t¨anker liksom f¨ orflyttningsperspektivet, vart ¨ ar vi p˚ a v¨ag, s˚ a b¨or man ju p˚ a samma s¨att som man kopplar initiativ och projekt till liksom v¨ arden och effekter s˚ a b¨or man ju f¨orhoppningsvis kunna se vilka s˚ ana arbetsinsater som bidrar till en st¨arkt f¨orm˚ ageh¨alsa, s˚ a. S˚ a det h¨anger ju ihop, men, ja. Fem element fr˚ an litteraturen, k¨ anns de relevanta? Krav, resurs, roll, tj¨ anst, h¨ andelse. Ja. Krav k¨ anns ju absolut relevant. Vad sa du sen, resurs? Ja. Kan du f¨ orklara vad du menar med resurs? Det kan vara dels till exempel pengar, dels material och s˚ adant som byggnader, beroende p˚ a hur man vill modellera det. Men, har det ocks˚ a, f¨ or resurs kan ju ocks˚ a vara, allts˚ a, arbetskraft eller datorst¨od, och i s˚ a fall tycker jag ju att det ¨ ar relevant, det sa jag ju. Ja, men det k¨anns ju relevant, att man kopplar vad ¨ ar det f¨ or n˚ at som f˚ ar det h¨ar att h¨anda. Sen roll. Ja, de ¨ ar ju lite lika resurser, just det. Och tj¨ anst och h¨ andelse. Och tj¨ anst i perspektivet arkitektur? Tj¨ anst som p˚ a n˚ at s¨ att bidrar till f¨ orm˚ agan, tj¨ anst som f¨ orm˚ agan bidrar till att det g˚ ar att erbjuda. ¨ det f¨ Ar orm˚ agan som bidrar till tj¨ ansten, eller ¨ar det tj¨ansten som ¨ar, ja, en del av f¨orm˚ agan? F¨ or man kan ju t¨ anka, men tj¨ ansten ¨ar i n˚ agon form av, ja, det erbjuds en tj¨anst p˚ a ett eller annat s¨ att, som g¨ or n˚ agonting, och ja, det b¨or ju vara en del av en f¨orm˚ aga. Sen om det, vem det ¨ ar som utf¨ or den h¨ ar tj¨ansten, det kan ju antingen vara vi h¨ar, eller vi k¨oper en tj¨ anst n˚ an annan stans. Men f¨ or att en tj¨anst ska vara relevant f¨or oss, antingen att erbjuda, allts˚ a att IT erbjuder en tj¨ anst f¨or verksamheten, eller att vi erbjuder en tj¨anst f¨or v˚ ara kunder, eller att vi k¨ oper en tj¨ anst f¨or n˚ at s˚ ant d¨ar, d˚ a b¨or ju den koppla till n˚ an typ av f¨ orm˚ aga, det k¨ anns ju rimligt, s˚ a. Givet att man arbetar med den typen av paketering. Och d¨ ar ¨ ar jag lite os¨ aker vad, hur Folksam g¨or just nu. Om det liksom finns n˚ an form av tj¨ anstekatalog eller liksom att man arbetar p˚ a det s¨attet, eller om man vill r¨ora sig lite ˚ at 83 det, det vet jag inte. Och h¨ andelse. Vad t¨ anker du p˚ a f¨ or h¨ andelse d˚ a? N˚ agon slags h¨ andelse eller event som kan p˚ averka f¨ orm˚ agan eller f¨ oretaget. T¨ anker man d˚ a, vad vet jag, skulle det kunna vara att jag vill k¨opa en f¨ors¨akring, som kund, och att ja, vi ska ha en f¨ orm˚ aga som heter, som handlar om att vi uppr¨attar f¨ors¨akringsavtal, eller att vi f˚ ar en premieinbetalning och vi har en f¨orm˚ aga som heter hantera betalningar, s˚ a? Ja. Ja, men absolut, det ¨ ar klart att det ¨ar relevant. F¨or troligen s˚ a ¨ar ju en h¨andelse relaterad till flera f¨ orm˚ agor. Och om vi tar h¨ andelsen k¨opa f¨ors¨akring, s˚ a b¨or vi b˚ ade kunna uppr¨atta n˚ an form av avtal, vi m˚ aste ju ha en f¨orm˚ aga att ha koll p˚ a hur v˚ ara f¨ors¨akringsprodukter ser ut, vi m˚ aste kunna ta hand om betalningar, vi m˚ aste kunna k¨opa produkter, eller ja, liksom, skadematerial och annat. S˚ a de relaterar ju, om man f¨or¨andrar den s˚ a kommer man ju beh¨ ova s¨ akert f¨ or¨ andra annat. S˚ a det ¨ar s¨akert klokt. Dessa element, varf¨ or k¨ anns de relevanta att koppla ihop med f¨ orm˚ aga, och finns det n˚ agon s¨ arskild situation d¨ ar det skulle vara anv¨ andbart? Allts˚ a, generellt f¨ or att jag tror man f¨orst˚ ar b¨attre vad det ¨ar som antingen inte fungerar bra eller vad som, genom att g¨ ora n˚ anting b¨attre s˚ a blir liksom helheten b¨attre. Det ¨ar ett, A och O, det h¨ ar med att, som f¨ ors¨ akringsbolag s˚ a b¨or vi ju ha ett antal ¨overgripande f¨orm˚ agor som inte f¨ or¨ andras, vi ska s¨ alja f¨ ors¨ akringar, vi ska f¨ors¨akra m¨anniskor, och sen s˚ a kan vi ju hantera det p˚ a olika s¨ att, men jag tror att man f˚ ar ett s¨att att f¨orst˚ a hur helheten h¨anger ihop, med en j¨ akla massa bolag och det ¨ar ju liksom lite lokala v¨arldar i liksom skador och i pension och man h˚ aller p˚ a och, det ¨ar inte s¨akert att man f¨orst˚ ar att en f¨or¨andring h¨ar faktiskt p˚ averkar en massa andra saker, och d˚ a ¨ar det h¨ar ju ett s¨att att f˚ a koll p˚ a det. Det var v¨ al det generella. Elementen, tror du att de p˚ averkar f¨ orm˚ agan, eller tv¨ artom? Det var ju ingen l¨ att fr˚ aga. Vem kom f¨orst, h¨onan eller ¨agget? Jag tror nog att, jag skulle vilja s¨ aga att det beror nog p˚ a. Och jag tror ocks˚ a att det kan ha att g¨ora med, allts˚ a, p˚ a vilket s¨ att, kulturellt, allts˚ a, hur ¨ar de h¨ar f¨orm˚ agorna definierade, och har de, om man f˚ ar liksom vara lite fr¨ ack och s¨ aga att, om det ¨ar n˚ an form av, liksom, efterkonstruktion, i att, okej, det h¨ ar med f¨ orm˚ agor ¨ ar ju praktiskt och bra, vi ser ett v¨arde i det. D˚ a s¨ager vi, “Vad har vi f¨ or f¨ orm˚ agor?”. D˚ a¨ ar ju de s¨akert drivna ur antingen om det nu ¨ar h¨andelser eller om det ¨ ar processer som vi har, s˚ a har man ju p˚ a n˚ at s¨att kommit fram till de h¨ar f¨ orm˚ agorna. Man har s¨ akert tittat p˚ a om det finns n˚ an industristandard eller olika s˚ ant d¨ar, visst. Men man ¨ ar ju p˚ averkad av hur saker och ting har varit. Och d˚ a skulle jag v¨al tro att, ja men, hur l¨ ange vissa saker har funnits, och n˚ an form av mognadsgrad och s˚ ant d¨ar, ¨ det, s˚ s˚ a finns det s¨ akert olika typer av p˚ averkan. Ar a att s¨aga, aff¨arsh¨andelsen som styr, eller ¨ ar det s˚ a att det kanske ¨ ar n˚ an f¨orm˚ aga som ¨ar v¨aldigt central, som har funnits v¨aldigt l¨ ange eller som styr andra saker. Men jag har ju ingen k¨ansla eller kunskap kring vilken som ar styrande i de h¨ ¨ ar sammanhangen, tror jag. Men jag tror att det finns en, ja, l˚ at oss s¨aga kulturell eller tidsaspekt p˚ a det. 84 Respondent 12 Bakgrund: Jag ¨ ar verksamhetsarkitekt, p˚ a koncernarkitektur, och har varit h¨ar sen september, ett halv˚ ar. Har jobbat som verksamhetsarkitekt, ja, tolv ˚ ar kanske. Kortfattat: vad vet du om f¨ orm˚ agor? Vad jag vet, ja, jag vet ganska mycket. Vad man har det till, och hur man bygger upp dem, och strukturen, och varf¨ or man beh¨over dem. Kortfattat: vad ¨ ar det? En f¨ orm˚ aga ¨ ar n˚ anting som beh¨ ovs i verksamheten f¨or att man ska kunna utf¨ora sin business. Utan att man s¨ ager hur eller n¨ ar eller vem som g¨or det. Till skillnad mot processerna som talar om det. En f¨ orm˚ aga finns bara en enda g˚ ang i en f¨orm˚ agekarta, om man nu uttrycker sig s˚ a. Hur l¨ ange har du jobbat med f¨ orm˚ agor? Jag har nog h˚ allt p˚ a i en tre till fyra ˚ ar med det. Hur kom du i kontakt med det? Ja, det var nog n¨ ar vi skulle, det var p˚ a min f¨orra arbetsplats d˚ a, n¨ar vi skulle f¨ors¨oka beskriva vad vi g¨ or, vad vi har f¨ or olika systemst¨od, vad vi beh¨over kunna hantera. F¨or vi hade v¨ aldigt mycket olika processer, mycket olika systeml¨osningar, och vi ville se att om vi ska g¨ ora en ny f¨ or¨ andring av n˚ anting, hur, vad har vi d˚ a som skulle kunna hj¨alpa oss, finns det n˚ at annat systemst¨ od idag som g¨or samma sak. Det var ocks˚ a i, n¨ar vi skulle f¨ors¨oka klassificera vilka olika initiativ vi hade, vad var de inom f¨or omr˚ aden? Det var d˚ a vi b¨orjade f¨ orst˚ a att vi beh¨ over en s˚ an karta. Har du anv¨ ant dig av f¨ orm˚ agor, och i s˚ a fall hur? Ja. Dels har jag ju anv¨ ant det i att, n¨ar vi har tittat p˚ a processer. Att slippa g˚ a ner och g¨ ora aktivitetsfl¨ oden, kan man s¨aga, “Vad ¨ar det f¨or n˚ anting du utf¨or i den h¨ar processen?”. F¨ or att kunna hitta, just om man g¨or en f¨or¨andring i en f¨orm˚ aga, ”Var sl˚ ar det?”, i vilka processer sl˚ ar det, f¨ or att se att vi f˚ angar alla. Som, till exempel om vi ska ta Kund d˚ a, som ¨ ar ett ganska vanligt, s˚ a d˚ a kan man ju Hantera Kund p˚ a olika s¨att. N¨ar man, f¨orsta g˚ angen man m¨ oter den, eller n¨ ar man ¨andrar den, eller n¨ar man avslutar, och det ¨ar ju olika processer. Om man ¨ andrar n˚ anting i Kund, s˚ a m˚ aste man kolla alla de h¨ar processerna, s˚ a d¨ ar, det var viktigt. Vad var fr˚ agan? ¨ det v¨ Om du anv¨ ant dig av f¨ orm˚ agor, och i s˚ a fall hur? Ar aldigt m˚ anga beh¨ over du ju inte r¨ akna upp alla i detalj. Men det var i s˚ a fall identifiera var vi m˚ aste g˚ a in och kontrollera n¨ar vi ska g¨ora en f¨ or¨ andring. Kan du se n˚ agra andra anv¨ andningsomr˚ aden f¨ or f¨ orm˚ agor? Det ¨ ar ju ett bra s¨ att att identifiera ansvar inom organisationen, vem som har ansvar f¨or vissa delar. Och sen ¨ ar det ju, ja, just i planering, vi anv¨ander det ju p˚ a ganska m˚ anga, det 85 ar planeringen av olika initiativ, s˚ ¨ a¨ ar det ju bra. Vilka element tycker du vore intressanta att koppla ihop med f¨ orm˚ aga? Ja, det ¨ ar ju processer, det ¨ ar ju applikationer, eller tekniskt systemst¨od. Det kan vara organisation, men det beh¨ over det inte vara, tycker jag, riktigt. Det ¨ar ju information, det ar ju lagar och policy och regler, regelverk, aff¨arsregler d˚ ¨ a. Det ¨ar ju det jag ¨ar intresserad av. Sen finns det ju krav d˚ a, men d˚ a ¨ar det ju mer kravsidan, s˚ a det ¨ar inte det jag anv¨ander. Fem element fr˚ an litteraturen, k¨ anns de relevanta? Krav, resurs, roll, tj¨ anst, h¨ andelse. Ja, krav, just f¨ or mig, jag beh¨ over ju inte krav, f¨or jag, det ¨ar mer krav. Men man beh¨over kunna koppla krav till, ett krav ¨ ar ju ofta n˚ anting som bara g¨aller nu, n¨ar jag g¨ora det h¨ar. Sen om ett ˚ ar s˚ a¨ ar ju kravet annorlunda. Vad var det, sen hade du resurs? Resurs, ja? Och resurs, d˚ a¨ ar det kanske information vi t¨anker p˚ a eller, och system? Ja, det kan vara information, det kan vara pengar, det kan vara annat som byggnader. Du f˚ ar g¨ arna ha en ˚ asikt om flera. Jag ser det nog som att det ¨ ar information och systemst¨od d˚ a, och det tycker jag absolut, ja. Sen ¨ ar det roll. Ja, om man d˚ a t¨ anker p˚ a ut¨ ovar.. Jag tycker inte rollen ¨ar j¨atteviktig, faktiskt. Men d¨ aremot kan det vara om man vill dela upp ett ansvar, vem som har ansvar f¨or det d¨ar, inom en business, men ut¨ ovarrollen, nej. Ansvarsrollen m¨ ojligtvis, men inte ut¨ ovarrollen? Ja, och det ¨ ar ju ur aspekten att om man vill g¨ora en f¨or¨andring i den h¨ar f¨orm˚ agan, s˚ a m˚ aste man g˚ a via den ansvariga f¨or att veta. Tj¨ anst? En tj¨ anst, det ¨ ar ju hur det ¨ ar implementerat. Det ¨ar inte jag heller intresserad av, men det ar ju IT intresserade av. ¨ Och sen h¨ andelse. En h¨ andelse. Ja, det a ¨r ju ocks˚ a mer det som h¨or till, jag skulle s¨aga att det ¨ar processerna som beskriver h¨ andelserna litegrann. Ja, jag a¨r lite tveksam p˚ a den. Dessa element, varf¨ or vill du koppla just dem, och skulle det vara anv¨ andbart i n˚ agra specifika situationer? Det ¨ ar i analyssynpunkt. Dels ¨ ar det ju f¨or att veta vilka regler som g¨aller, lagar och regler och aff¨ arsregler. Om man nu vill styra om sin business p˚ a n˚ agot s¨att, d˚ a vet man var regeln h¨ or hemma n˚ anstans, och en regel kan ju sl˚ a p˚ a flera f¨orm˚ agor. Sen ¨ar det ju analysen d˚ a, hur en f¨ or¨ andring av den h¨ ar f¨ orm˚ agan sl˚ ar i organisationen, om jag beh¨over g¨ora om 86 n˚ an process. Eller om jag g˚ ar fr˚ an andra h˚ allet, om jag har en process jag vill modifiera, vad inneb¨ ar det? Ja, det ¨ ar de h¨ ar f¨orm˚ agorna som kommer att st¨oras, och vad har de f¨or regelverk? Det ¨ ar, liksom, sp˚ arbarheten d¨ar. Det ¨ar ocks˚ a om jag beh¨over byta ut mitt systempark, om jag drar i systemet X, var n˚ anstans, d˚ a ser jag ju vilka processer de jobbar i, och s˚ a ser jag ju ocks˚ a vilka f¨ orm˚ agor, eller jag kan kanske koppla dem direkt till f¨orm˚ agan. Elementen, p˚ averkar de f¨ orm˚ agan, eller blir det p˚ averkade? F¨ orm˚ agan ¨ ar ju, den ¨ ar ju best¨ andig, kan man s¨aga. Sen hur den f¨orm˚ agan appliceras i verksamheten, den kan ju f¨ or¨ andras. Jag menar, du kan ju ha en manuell hantering av en f¨ orm˚ aga som sen blir automatiserad. D˚ a har du ju ¨andrat systemst¨od eller processen. S˚ a processen kommer ju, eller, f¨ orm˚ agan kommer ju inte ¨andras, om du inte ¨andrar din aff¨ arsmodell, d¨ ar du s¨ ager att “Jag ska g¨ora n˚ anting annat”, eller kommer p˚ a n˚ anting, utan de ¨ ar snarare de andra attributen, processen, applikationerna, som kommer att styras. A.2 Intervierw set 2 Respondent 1 Hur kan man se om en f¨ orm˚ aga fungerar bra eller inte? D˚ a m˚ aste man titta p˚ a vad det ¨ ar som bygger upp f¨orm˚ agan, och d˚ a ¨ar man tillbaka till organisation, processer, system och s˚ a vidare. Aggregatet av den sammanst¨allningen bygger f¨ orm˚ agan. S˚ a man m˚ aste kolla p˚ a ing˚ aende delar, och hur de samverkar. Vad tror du p˚ averkar en f¨ orm˚ agas v¨ alm˚ aende mest? Det tror inte jag man kan s¨ aga, f¨ or det beror p˚ a vilken f¨orm˚ aga och vad den ¨ar uppbyggd av. Du kan ju s¨ aga att en f¨ orm˚ aga, att vi inte har automatiserat n˚ agot st¨od i den, d˚ a har vi ju organisation och processer, det finns inget systemst¨od ¨over huvud taget. S˚ a d˚ a kan du ju inte s¨ aga generellt att en f¨ orm˚ aga m˚ ar alltid s¨amst i IT-delen eller i process-delen eller s˚ a, utan, nej, det beror p˚ a vad det ¨ ar f¨ or f¨orm˚ aga och vad den byggs upp av. Finns det n˚ agra egenskaper hos f¨ orm˚ agan du tror p˚ averkar hur f¨ orm˚ agan m˚ ar mer eller mindre a ¨n andra? Nej, jag vet inte vad det skulle vara f¨or n˚ anting, vad f¨or egenskaper den skulle ha. De, s˚ a att s¨ aga, den ¨ ar en gruppering eller ett aggregat av andra delar, s˚ a att f¨orm˚ agan, egenskaper f¨ or f¨ orm˚ agan, byggs ju upp av andra. Pratar vi egenskaper, ja, men f¨arg, bl˚ a, r¨od, gr¨ on, blablabla. Nej, jag kan inte relatera till det just nu. Av elementen, ¨ ar det n˚ agra du tror p˚ averkar f¨ orm˚ agan mer ¨ an andra? Finns det n˚ agra specifika situationer? Inte vad jag kan komma p˚ a s˚ a, nej. Det kanske ¨ar enklare om man tar ett specifikt fall eller n˚ anting s˚ ant, men rent generellt sett, om vi s¨ager att de byggs upp av de h¨ar byggklossarna, s˚ a¨ ar det ju hur de samverkar, det kommer ju vara olika vad du ¨an tittar p˚ a. Och likadant kommer det vara olika om du tittar p˚ a det p˚ a Folksam, eller om du tittar p˚ a det p˚ a If eller n˚ an annan stans, du kommer inte titta p˚ a samma saker f¨or det kommer att vara uppbyggt p˚ a olika s¨ att. Tror du att det finns n˚ agra egenskaper hos elementen som p˚ averkar f¨ orm˚ agan mer ¨ an andra? Vad pratar vi om f¨ or element? 87 De vi har g˚ att igenom, som kan kopplas till f¨ orm˚ agan. S˚ a kanske till exempel upp/nertid f¨ or en viss applikation, finns det n˚ agot s˚ ant som kan p˚ averka mer ¨ an annat? Det beror ju p˚ a vad du l¨ agger i definitionen av, om man tittar p˚ a, om man bara g˚ ar tillbaka n˚ at ˚ ar, n¨ ar man inte anv¨ ande sig av f¨orm˚ agebegreppet ¨over huvud taget, d˚ a kallade man s˚ ana saker icke-funktionella krav eller egenskaper p˚ a system, uppetider till exempel, och s˚ a vidare. Jag relaterar inte dem till f¨orm˚ agor, jag relaterar dem fortfarande till ickefunktionella krav p˚ a ett system, ”vi m˚ aste vara uppe 24/7/365”, s˚ a, ja, d˚ a ¨ar det ett krav snarare ¨ an att, p˚ a systemets egenskaper, eller det som bygger upp systemet, servrar och s˚ a . Sen kan man naturligtvis s¨ aga att det kan kopplas till en f¨orm˚ aga. Vinner man n˚ anting p˚ a det? Jag tror inte det. Respondent 2 Could not be reached for a second interview. Respondent 3 Hur kan man se om en f¨ orm˚ aga m˚ ar bra eller inte? Idag tycker jag inte att vi har kommit dit att vi kollar det, s˚ a det ¨ar sv˚ art att svara p˚ a. Jag har inte varit med i s˚ ana jobb d¨ar vi kollar specifikt p˚ a en f¨orm˚ aga riktigt. Ja, eller s˚ a, jag vet inte hur jag ska t¨ anka d¨ ar. Samtidigt s˚ a kollar vi ju d˚ a p˚ a ”vad ¨ar nul¨aget kring en f¨ orm˚ aga idag?” i n˚ agot avseende, vilken f¨orflyttning sker kring en f¨orm˚ aga, det g¨or vi i systemstrategin, nya, f¨ or kundm¨ ote. D˚ a har vi ju litegrann ett systemperspektiv i det vi ska leverera men samtidigt s˚ a tittar vi ju j¨attemycket p˚ a aff¨arskraven som ligger p˚ a en viss f¨ orm˚ aga, d˚ a ser vi massa ¨ onskem˚ al eller behov d˚ a helt enkelt, genom aff¨arskraven. Och det inneb¨ ar ju d˚ a att vi vill flytta f¨orm˚ agan fram˚ at, vilket vi kan g¨ora. S˚ a om man ser det p˚ a det s¨ attet, det kanske ¨ ar det som ¨ar till¨ampningen d˚ a, s˚ a absolut, d˚ a jobbar vi med h¨ alsotillst˚ and idag d˚ a, det g¨ or vi ju. Och p˚ a samma s¨att g¨or vi olika omfattningsanalyser f¨or initiativ d˚ a. Ska man bygga vidare p˚ a det och mer mappa upp exakt var vill man titta p˚ a f¨ orm˚ agor, vilken information vill man titta p˚ a eller s˚ a d¨ar, d˚ a kan man ju bli ¨annu tydligare d˚ a i vad som ¨ ar ett h¨ alsotillst˚ and eller inte, j¨amf¨ort med den niv˚ an som vi ¨ar p˚ a idag d˚ a, som ¨ ar kanske lite mer ¨ overgripande. Men man tittar ju ¨and˚ a p˚ a olika delar i olika initiativ och olika strategiarbeten d˚ a. Ja, vi g¨or det, men det g˚ ar absolut att g¨ora ¨annu mer. Finns det n˚ agot som p˚ averkar hur bra en f¨ orm˚ aga m˚ ar mer ¨ an n˚ agot annat? Ja, det f¨ orsta svaret blir att det ¨ ar sv˚ art att peka ut n˚ agot specifikt, att det varierar alltid, om det liksom ¨ ar kompetensen eller organisationen eller informationen, och att det, oftast ar det mer ¨ ¨ an en sak som g¨ or att det inte fungerar perfekt om det inte g¨or det, och att det ar ett samspel mellan flera olika. Det kan s¨akert finnas fall rent specifikt, men d˚ ¨ a m˚ aste man ju titta p˚ a ett exempel i s˚ a fall och se vilket ¨ar det just nu d˚ a. Det ¨ar v¨al, ja. Har f¨ orm˚ agan n˚ agra inneboende egenskaper som kan p˚ averka hur den m˚ ar? Ta det en g˚ ang till. Senast pratade vi om element kopplade till f¨ orm˚ agan, som Process, Organisation osv. Tror du att, f¨ orutom detta, f¨ orm˚ agan har n˚ agra egna, inneboende egenskaper som p˚ averkar hur den m˚ ar? Jag tror inte jag f¨ orst˚ ar hur du menar faktiskt. 88 Finns det n˚ agot du tycker ¨ ar en egenskap hos f¨ orm˚ agan snarare ¨ an ett element kopplat till den, som p˚ averkar hur den m˚ ar? S˚ a en egenskap, allts˚ a, om vi s¨ ager, processerna, det ¨ar element som ¨ar kopplade till den, det ¨ ar inte egenskaper p˚ a f¨ orm˚ agan? Precis. Vad ¨ ar exempel p˚ a egenskaper d˚ a? Det ¨ ar vad jag undrar om du kommer p˚ a n˚ agra. Ja, kommer jag p˚ a n˚ at just h¨ ar och nu d˚ a? Nej, men vi passar p˚ a den d˚ a. Absolut. Finns det n˚ agra element som p˚ averkar f¨ orm˚ agan och dess v¨ alm˚ aende mer ¨ an andra? D˚ a skulle man n¨ astan beh¨ ova se hela listan d˚ a. Du kan absolut f˚ a listan. Hela listan, eller de du kryssade f¨ or som relevanta? Ja, d˚ a tar vi de jag kryssade f¨ or d˚ a. Applikation; h¨ andelse; information; input; IT-st¨ od; kompetens; kostnad; KPI; Krav och specialfallen Lag, Regel, och Policy; Organisation; Output; Process; Resurs; Risk; Roll; System; Tj¨ anst; V¨ ardetr¨ ad. Och jag skulle svara p˚ a om jag tyckte att n˚ an var mer viktig ¨an n˚ an annan? ¨ det n˚ Ja, precis. Ar agra du spontant k¨ anner p˚ averkar mer ¨ an n˚ agon annan? Vad ska vi ta d˚ a, om det ¨ ar en f¨ orm˚ aga inom f¨ors¨aljning som ¨ar att Teckna f¨ors¨akring, exempelvis. D˚ a m˚ aste man ha kompetensen f¨or att kunna st¨otta informationen, processen, nyckeltal. Ja, det blir en stor fr˚ aga tycker jag, att ta st¨allning kring d˚ a. Det beror ju p˚ a vilken f¨ orm˚ aga det handlar om, igen, tror jag, vad som ¨ar viktigast d˚ a. Men f¨or att kunna hantera en fr˚ aga, det ¨ ar ju p˚ a n˚ agot s¨att grundl¨aggande att det i alla fall finns en organisation med kompetens, om vi, allts˚ a, det ¨ar grunden f¨or att kunna g¨ora det p˚ a r¨att s¨att, med process och hitta information, det tycker jag ¨ar grundl¨aggande, annars kommer man ingenstans. Om man har en tom box, utan ansvariga, utan medarbetare, d˚ a blir det v¨aldigt sv˚ art, man f˚ ar s¨ atta det, f˚ a det p˚ a plats f¨orst d˚ a. Det, ¨aven om vi liksom kan hantera f¨ orm˚ agor med hj¨ alp av prylar, eller Internet of Things, s˚ a, p˚ a det s¨attet, s˚ a tror jag ¨and˚ a att n˚ an m˚ aste d˚ a s¨ atta upp hur det ska funka. S˚ a kan man ju t¨anka vidare att det eventuellt finns d˚ a anst¨ allda inom andra f¨ orm˚ agor som ser till att den funkar, helt utan n˚ an personlig resurs, men det ¨ ar v¨ al lite l¨ angre fram tror jag, jag tror inte vi har s˚ a m˚ anga s˚ ana f¨orm˚ agor idag i alla fall. Elementen, har n˚ agot av dem n˚ agra egenskaper som p˚ averkar f¨ orm˚ agan? T.ex. upptid f¨ or ett system eller liknande? Inom systemsidan? Eller elementen o ¨ver huvud taget. 89 Men inom en systemf¨ orm˚ aga? Snarare allm¨ ant, oavsett f¨ orm˚ aga. De h¨ ar elementen, som man kan koppla till f¨ orm˚ agan, finns det n˚ agra av dem som har egenskaper som p˚ averkar f¨ orm˚ agans v¨ alm˚ aende, som exempelvis om ett system p˚ averkar s˚ a¨ ar det snarare systemets upptid som ¨ ar viktig. Jaha, vilka element har vi d˚ a? Ska jag ta dem en g˚ ang till? Ja, f¨ or d˚ a m˚ aste man ju svara per element, eller hur? Ja, eller om du kommer p˚ a n˚ agra a ¨nd˚ a. Ta en i taget d˚ a. Applikation. Mmh, vad ¨ ar det f¨ or applikation, vad skulle det kunna finnas p˚ a den som ¨ar viktigare an annat d˚ ¨ a, det ¨ ar det som ¨ ar fr˚ agan? Ja, om det ¨ ar n˚ agot hos det elementet du tror specifikt p˚ averkar f¨ orm˚ agan. Det ¨ ar lite sv˚ art att svara p˚ a s˚ a h¨ ar, d˚ a f˚ ar man n¨astan g¨ora p˚ a papper, allts˚ a dokumentera d˚ a, i en matris d˚ a. Och det kanske andra f˚ ar ta, som har valt att svara p˚ a det s¨attet d˚ a, f¨or det k¨ anns som att det blir lite sv˚ art att f˚ a ut. Respondent 4 Could not be reached for a second interview. Respondent 5 Hur ser man om en f¨ orm˚ aga m˚ ar bra eller inte? Mitt problem ¨ ar att jag k¨ anner att jag kanske inte riktigt kan det h¨ar med f¨orm˚ agebegreppen d˚ a, eftersom jag d˚ a har f˚ att fel ing˚ ang fr˚ an b¨orjan. S˚ a att, ja. S˚ a, f¨or mig ¨ar det just det h¨ ar med matris-tanken. Det ¨ ar ju l¨attare om man bara har en f¨orm˚ aga som finns p˚ a ett st¨ alle i verksamheten. Det ¨ ar sv˚ arare om du har en f¨orm˚ aga som till exempel Utbetalning, eller Betala ut, eller vad det nu heter, f¨or det ¨ar ju en f¨orm˚ aga som finns p˚ a massor med olika st¨ allen, och d˚ a¨ ar det ju ganska sv˚ art att bed¨oma om just, du m˚ aste du ju titta p˚ a s˚ a m˚ anga saker. Annars kan du ju m˚ als¨atta f¨orm˚ agan, p˚ a samma s¨att som man kan m˚ als¨atta en delprocess. Allts˚ a, s˚ a t¨ anker jag, fast jag vet inte om det ¨ar r¨att. Om vi nu tar, kan du ge mig n˚ at exempel p˚ a en f¨ orm˚ aga som ¨ar singul¨ar, finns p˚ a ett st¨alle? Anst¨ alla personal, kanske? Ja, och f¨ or mig ¨ ar det d˚ a, d˚ a hamnar jag i den h¨ar sv˚ arigheten: ”¨ar det en process eller ¨ar det en f¨ orm˚ aga?”. Det ¨ ar det jag har lite, f¨or n¨ar jag t¨anker process s˚ a t¨anker jag ofta in mycket mer ¨ an bara sj¨ alva fl¨ odet, jag t¨anker ju resurser och IT-st¨od och allting. Men om jag, i och f¨ or sig, s˚ a d˚ a kan man ju s¨aga att, d˚ a kan man ju fundera p˚ a hur bra vi ¨ar p˚ a att anst¨ alla personal, och d˚ a kan man ju i och f¨or sig utv¨ardera processen p˚ a ett s¨att, man kan utv¨ ardera de som g¨ or det. Ja, n˚ anstans m˚ aste man ju s¨atta m˚ al, f¨or att bed¨oma en f¨orm˚ aga. Det ¨ ar v¨ aldigt sv˚ art att bara ”out of the blue” s¨aga n˚ at. Eller ocks˚ a s˚ a kan man ju i och f¨or 90 sig k¨ anna p˚ a sig ”men det h¨ ar ¨ ar ju vi nog j¨attebra p˚ a”, s˚ a d˚ a kanske man kan bed¨oma det. Men det ¨ ar l¨ attare med f¨ orm˚ agor som finns i en implementation, det ¨ar ju l¨attare ¨an s˚ ana som finns i flera, f¨ or d˚ a m˚ aste du ju faktiskt g¨ora en ordentlig analys och t¨anka igenom. Finns de n˚ agot som du tror p˚ averkar en f¨ orm˚ agas v¨ alm˚ aende mer ¨ an annat, till exempel av de h¨ ar olika elementen? Ja, det ¨ ar ju ganska m˚ anga. Det ¨ ar ju de h¨ar standard, processer, resurser, allts˚ a de som utf¨ or processen, och hur de styrs, allts˚ a om de f¨orst˚ ar vad det ¨ar som ¨ar viktigt med den h¨ar processen, och sen de eventuella st¨ od vi har, men jag menar, den kan ju fungera bra ¨aven om vi sitter och g¨ or allting f¨ or hand ocks˚ a. S˚ a att det beror ju mer p˚ a hur man m˚ als¨atter den, men s¨ attet vi g¨ or det p˚ a och de som g¨or det, och de f¨oruts¨attningar de har f¨or att faktiskt g¨ ora ett bra jobb, tror jag p˚ averkar. Finns det n˚ agra egenskaper hos f¨ orm˚ agan som p˚ averkar hur den m˚ ar? Ja, det ¨ ar d¨ ar jag har lite sv˚ art att veta vad det skulle vara, ¨ar inte elementen delar av ¨ inte processerna och resurserna och IT-st¨oden en del av sj¨alva f¨orm˚ f¨ orm˚ agan, eller? Ar agan? Jo, du kan nog se det p˚ a det s¨ attet. Annars kan man se det mer som att elementen ¨ ar l¨ ankade till och ihopkopplade med f¨ orm˚ agan, men inte en del av den. Men det ¨ ar okej att inte kunna svara ocks˚ a. Ja, jag tycker det ¨ ar sv˚ art, och jag k¨ anner att jag kan inte uttala mig om n˚ at jag inte f¨orst˚ ar. Elementen som kan p˚ averka f¨ orm˚ agan, har de n˚ agra specifika egenskaper som p˚ averkar den? Finns det n˚ agra specifika, som till exempel upptid f¨ or system? Ja, jag vet inte om styrning ¨ ar ett element, men jag tror ju att det ¨ar v¨aldigt viktigt att, ja, men, design och styrning av elementen m˚ aste ju vara viktig. Du kan ju stoppa in v¨arldens b¨ asta IT-st¨ od och j¨ attekompetenta m¨anniskor men inte f˚ a ut n˚ anting ¨and˚ a d¨arf¨or att du inte har definierat, s˚ a n˚ anstans kr¨ aver man ju, beh¨over man ju styrning, och uppf¨oljning, av ¨ f¨ orm˚ agor ocks˚ a, tror jag. Aven om jag t¨anker process s˚ a tror jag att det g˚ ar att applicera p˚ a f¨ orm˚ agor ocks˚ a. Men det ¨ ar ju det h¨ar att du m˚ aste veta vad du vill ha ut, ˚ aterigen, du m˚ aste ju ha n˚ an typ av m˚ al eller ¨ onskv¨art resultat, annars har du ju ingen aning om ifall det fungerar bra eller inte. Respondent 6 - answers sent via mail Hur ser man om en f¨ orm˚ aga m˚ ar/fungerar bra eller inte? Fanns initialt ”id-kort” framtagna per f¨orm˚ aga d¨ar det framgick. Nu p˚ ag˚ ar arbete med att strukturera om f¨ orm˚ agekartan och jag vet inte om de hunnit till den delen ¨annu. Vad tror du p˚ averkar en f¨ orm˚ agas v¨ alm˚ aende mest? Upptid f¨ or systemen h¨ anger ihop med ”IT-f¨orm˚ aga” p˚ a en mer detaljerad niv˚ a s˚ a d¨ar ¨ar det v¨ al viktigt. . . Om man ser p˚ a en f¨ orm˚ aga ur ett aff¨ars- och verksamhetsperspektiv (utifr˚ an m˚ alen kring n¨ ojd kund och l¨ onsamhet) s˚ a ¨ar det ett sammanlagt v¨arde utifr˚ an hur viktig f¨ orm˚ agan ¨ ar f¨ or aff¨ aren/verksamheten samt hur prestandan p˚ a den ¨ar. D¨ar kan v¨ardet ibland dras ner pga f¨ or l˚ anga ledtider, felaktiga resultat, otilr¨ackliga resurser mm. Baserat p˚ a hur viktig f¨ orm˚ agan ¨ ar viktas de olika bristerna d˚ a olika h¨ogt. Finns det n˚ agra inneboende egenskaper hos f¨ orm˚ agan som p˚ averkar dess v¨ alm˚ aende? 91 Tror jag ber¨ ort detta i svaret ovan. . . Av de elementen som a ¨r kopplade till f¨ orm˚ agan, vilka tycker du p˚ averkar f¨ orm˚ agan mest? Tror jag ber¨ ort detta i svaret ovan. . . Vilka egenskaper hos dessa element tycker du p˚ averkar vilka egenskaper hos f¨ orm˚ agan? Har inte tillr¨ acklig detaljkunskap p˚ a den tekniska niv˚ an. . . Respondent 7 Hur kan man se om en f¨ orm˚ aga m˚ ar bra eller inte? Vad avg¨ or hur den m˚ ar? Ja, men man kan ju hitta m¨ atetal, och m¨ata f¨orm˚ agan. Ibland, det v¨arsta scenariot ¨ar v¨ al att man i verksamheten inte m¨ ater, och d˚ a vet man ju inte om f¨orm˚ agan. Och d˚ a tittar man snarare p˚ a vad det kostar i organisationen att driva en verksamhet. Det kanske inte ¨ar s˚ a bra m¨ atetal, utan kanske snarare hitta effektiva KPIer som visar p˚ a, liksom, vilka m˚ al man har, s˚ a man s¨ atter m˚ alen p˚ a r¨ att niv˚ a, och hela tiden har en f¨orb¨attringsambition. Finns det n˚ agor, tex n˚ agra KPIer, som p˚ averkar en f¨ orm˚ aga mer ¨ an andra? Hur menar du? Kan du komma p˚ a n˚ agra KPIer eller liknande som du tror p˚ averkar f¨ orm˚ agan och som skulle vara bra att m¨ ata f¨ or att se om den m˚ ar bra eller inte? Jag kan, om du ¨ ar ute efter exempel, liksom, i konkreta verkligheten.. Om du har n˚ agra exempel, s˚ a absolut. Ja, till exempel merf¨ ors¨ aljning i f¨ ors¨aljningskanalerna. En f¨orm˚ aga kring, s¨ag att vi har en f¨ orm˚ aga i f¨ ors¨ aljning, och sen en underf¨orm˚ aga som heter merf¨ors¨aljning, d¨ar kan det vara bristf¨ alligt, s˚ a att i vissa kanaler har man inte n˚ agon m˚ als¨attningar kring merf¨ors¨aljning, men i en annan kanal kanske man har det. Och d˚ a kan ju det bero p˚ a att, dels kan det vara naturligt s˚ a att man i den h¨ ar kanalen inte ¨ar effektiv n¨ar man f¨ors¨oker s¨alja, kunden vill inte. Men det kan ocks˚ a vara s˚ a som det vi uppt¨acker h¨ar, vi har ett projekt i Folksam, d¨ ar vi inte har n˚ agra verktyg f¨ or att s¨alja, f¨or vi ser inte kundens helhetsengagemang. Och d˚ a vet vi ju inte vad vi ska erbjuda heller. Och d˚ a har man inte satt upp m˚ al d¨ar, i den, i det h¨ ar exemplet, att just i den h¨ ar kanalen s˚ a har vi inte s¨aljm˚ al p˚ a de h¨ar delarna d˚ a, det g¨ aller vissa produkter d˚ a. Och det ¨ar brister i systemst¨oden helt enkelt. Det ¨ar bara s˚ ant som jag st¨ ott p˚ a h¨ ar, men det ¨ar ju m˚ anga andra, jag ¨ar ju mycket s¨aljinriktad som arkitekt, och jobbar mycket med f¨ ors¨aljning och marknadsf¨oring, mycket digital f¨ors¨aljning, d¨ ar m¨ ater man ju, det finns specifika m¨atv¨arden som man m¨ater p˚ a. Och d˚ a vet jag inte hur det ¨ ar just h¨ ar p˚ a Folksam, s˚ a jag ska inte ta de exemplena, f¨or jag har inte jobbat inom digital utveckling h¨ ar. Tror du att det finns n˚ agra egenskaper hos f¨ orm˚ agan som p˚ averkar dess v¨ alm˚ aende? Jag tror det ¨ ar snarare s˚ a att det ¨ ar de som ¨ar kopplade till f¨orm˚ agan, d¨arf¨or att f¨orm˚ agan i sig ¨ ar mer en abstraktionsrubrik. F¨or mig ¨ar det s˚ a i alla fall, att det ¨ar snarare man f˚ ar titta p˚ a ”Vad ¨ ar det i f¨ orm˚ agan som..”, utan jag vill snarare h¨arr¨ora mig v¨aldigt strategiskt eller h¨ ogt uppe n¨ ar jag pratar f¨ orm˚ agor. Och sen n¨ar man g˚ ar in i praktiken och analyserar 92 som arkitekt, d˚ a tittar man ju verkligen p˚ a ”¨ar det organisation, eller roll, eller process, logisk arkitektur, eller, vad ¨ ar det f¨ or n˚ anting?”. Av elementen kopplade till f¨ orm˚ agan, tror du att n˚ agra p˚ averkar f¨ orm˚ agans v¨ alm˚ aende mer ¨ an andra? Ja, styrmodellen, tror jag. D¨ arf¨ or att styrmodellen spiller ¨over p˚ a de andra delarna, hur du s¨ atter upp din organisation, hur du m¨ater f¨orm˚ agan, hur du kravst¨aller mot IT f¨or nya st¨od, det tycker jag nog ¨ ar, det ¨ ar nog liksom det som g˚ ar, i mitt huvud direkt s˚ a h¨ar, det ¨ar nog det som g˚ ar f¨ orst. Finns det n˚ agra egenskaper hos dessa element du tror p˚ averkar f¨ orm˚ agan mer ¨ an andra? Till exempel upptid f¨ or ett IT-system. Ja, jag tror att det ¨ ar mycket kring, lite egenskaper f¨or processen d˚ a, eller f¨ordjupningar av processer, d¨ ar man g¨ or dubbla, man g¨or upprepade, dubbla aktiviteter. Du har ett manuellt arbetss¨ att att koordinera, till exempel, mellan olika system, eller olika silos, och det blir merarbete, och det ¨ ar v¨ aldigt ineffektivt. S˚ a att du har inte automatiserade fl¨oden, s˚ a att n¨ ar du g¨ or en sak, d˚ a har du transparens ut i applikationer och system, du beh¨over bara g¨ ora en g˚ ang eller s˚ a g˚ ar det med automatik. H¨ar i v˚ ar moderniseringsresa s˚ a inneb¨ar det ju att du g¨ or massa saker flera g˚ anger, du har dubblerade informationsmodeller i olika system, s˚ a att tolkningar, koordineringar, det tror jag. V¨alm˚ aende, sen i ¨ovrigt, ja, men tolkningar, att man har olika informationsmodeller i f¨orm˚ agan beroende p˚ a att man har historik n¨ar man har utvecklat parallella IT-landskap f¨or olika produktomr˚ aden till exempel, det, ja. N˚ agot att till¨ agga? Nej, jag tror att det var det. Ha greppet om f¨orm˚ agan, om du vet inneh˚ allet i den. F¨or jag tror att du, ibland beskriver man f¨ orm˚ agan men man missar halva inneh˚ allet f¨or att man ¨ar inriktad p˚ a ”ja, men nu jobbar jag med det h¨ar initiativet” att det blir lite f¨or l˚ angt ner i organisationen, man jobbar p˚ a projektniv˚ a med en f¨orm˚ aga, d˚ a vill man bara scopa in det h¨ ar, ja, men hela f¨ orm˚ agan d˚ a? Om du konsoliderar allting som ¨ar i det omr˚ adet, s˚ a kanske det blir ett annat perspektiv p˚ a hur bra den m˚ ar. Just det h¨ar att man jobbar silos, det t¨ anker man inte alltid p˚ a, det ¨ ar viktigt som arkitekt att just f¨orm˚ agan generaliserar och konsoliderar 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 f¨ orm˚ aga m˚ ar bra eller inte? Kan man se om en process m˚ ar bra, eller n˚ anting annat? Det vet inte jag. Men jag kan inbilla mig att, som med mycket annat, f¨or att veta n˚ anting om det s˚ a m˚ aste man m¨ata, n˚ an form utav framsteg eller progress, utifr˚ an KPIer, beroende p˚ a vad det ¨ar man vill uppn˚ a. Det ¨ ar det enda s¨ attet tror jag. Det andra ¨ar den h¨ar typen av intervjuer, men de tycker jag inte du ska lita p˚ a. Men m¨ ata, allts˚ a, inf¨orandet av f¨orm˚ agor, n¨ar man har inf¨ort dem, hur de m˚ ar, det borde ju g˚ a, tycker jag, teoretiskt i alla fall. 93 Finns det n˚ agot du tror p˚ averkar hur bra en f¨ orm˚ aga m˚ ar eller fungerar mer ¨ an n˚ agot annat? Allts˚ a, det h¨ ar med f¨ orm˚ agor, det har vi ju framf¨or oss, det vill s¨aga vi pratar om ett f¨ or¨ andringsarbete. Jag t¨ anker s˚ a h¨ar, n¨ar man ska driva in n˚ anting, det ¨ar liksom i en utvecklingsfas d˚ a, d˚ a m˚ aste man utg˚ a fr˚ an det h¨ar med vilken mognadsgrad vi har d˚ a, och vi ¨ ar ju bara i b¨ orjan d¨ ar. S˚ a en grej som p˚ averkar v¨aldigt mycket ¨ar vilken acceptans vi har f¨ or f¨ orm˚ agesyns¨ attet. F¨ or har vi inte det s˚ a kan vi inte arbeta med f¨orm˚ agor. Och det ar ungef¨ ¨ ar d¨ ar vi ¨ ar just nu. Sen n¨ ar man har inf¨ort det s˚ a ¨ar det en annan sak d˚ a. Jag vet inte om det var ett svar p˚ a fr˚ agan, men det ¨ar liksom en f¨oruts¨attning f¨or att en f¨orm˚ aga ska kunna existera och m˚ a bra. S˚ a ser jag p˚ a det. Kan en f¨ orm˚ aga ha n˚ agra inneboende egenskaper som p˚ averkar hur den m˚ ar? S¨ akert, men det ¨ ar ingenting jag kommer att t¨anka p˚ a. ¨ det n˚ Ar agra av elementen som du tror p˚ averkar hur f¨ orm˚ agan m˚ ar eller fungerar mer ¨ an n˚ agra andra? Kan du repetera snabbt vilka det var? Absolut. Applikation, som ¨ ar st¨ odjande. Information. Input, IT-st¨ od. Kompetens. Kostnad. KPI. Krav, lag policy. Organisation. Output. Process. Resurs. Risk. System. Tj¨ anst. V¨ ardetr¨ ad. Det var sv˚ art. Men som p˚ averkar mer? ¨ det n˚ Precis. Ar agra du k¨ anner sticker ut och p˚ averkar mer hur f¨ orm˚ agan m˚ ar eller fungerar? Ja, Organisation, och med det menar jag tydlighet i ansvar i organisationen, till exempel mellan funktion, process, och f¨ orm˚ aga. Och jag tror att det ¨ar v¨aldigt sv˚ art att ˚ astadkomma det, s˚ a jag tror ocks˚ a att just det h¨ar med m˚ al och m¨atetal, om man kan b¨orja m¨ata p˚ a f¨ orm˚ agan. S˚ a Organisation och M¨ atetal, att f˚ a det att lira ihop f¨or att utveckla och f¨olja upp f¨ orm˚ agan, hur den m˚ ar eller progressen i den, det tror jag ¨ar viktigt. Finns det n˚ agra egenskaper hos elementen du tror p˚ averkar mer? Exempelvis kanske upptid f¨ or ett system. Det ¨ ar ju en komplex organisation, och f¨orm˚ agan vill jag ju se som att den sk¨ar igenom organisationen och det vi g¨ or, f¨ or att uppn˚ a det som ¨ar viktigt, det vill s¨aga vad. Och d˚ a tror jag att det ¨ ar en utmaning. Och nu sa jag m¨atetal, KPIer, d˚ a tror jag att man f˚ ar t¨anka till, s˚ a att de KPIer som man s¨ atter, dels att man s¨atter dem r¨att, och sen att vi utvecklar f¨ orm˚ agan att f¨ olja upp det. Det ¨ar l¨att att man utvecklar n˚ agonting, i det h¨ar fallet f¨ orm˚ agor, och sen l¨ agger man mycket energi p˚ a det, och sen utvecklar man ett m¨atsystem, och sen rasar det mellan fingrarna f¨ or att man orkar inte h˚ alla i, orkar inte f¨olja upp. Man m˚ aste ha ett, f¨ or det h¨ ar ¨ ar sv˚ art, om man ska sk¨ara ut f¨orm˚ agan, f˚ a acceptans f¨or det, och sen m¨ ata och f¨ olja upp s˚ a vi n˚ ar de resultat vi vill. D˚ a tror jag vi m˚ aste verkligen ha tryck i den fr˚ agan och acceptans fr˚ an h¨ogsta ledningen, och lyckas koppla till organisation som ska utf¨ ora d˚ a n˚ agonting, s˚ a vi n˚ ar det vi ska m¨ata. Det tror jag ¨ar v¨aldigt viktigt, att man t¨ anker till d¨ ar. Det f˚ ar inte vara heller ett teoretiskt ramverk, f¨or det ¨ar l¨att, som du intervjuar mig nu, s˚ a blir det ju v¨ aldigt mycket mer teori, utan det m˚ aste vara n˚ agonting som organisationen kan hantera, utifr˚ an den mognadstrappa d¨ar vi st˚ ar just nu, d¨ar vi ¨ar 94 ganska l˚ angt ner. S˚ a man f˚ ar inte bygga ett teoretiskt ramverk som vi inte kan r˚ a p˚ a helt enkelt, vare sig ledningen eller organisationen d˚ a. Jag tror p˚ a att m¨ata, jag tror att vi m˚ aste tydligg¨ ora relationen mot organisationen som ska g¨or n˚ anting kring det h¨ar, det tror jag ¨ar viktigt. Respondent 11 Hur tycker du att man kan se om en f¨ orm˚ aga m˚ ar bra eller inte? Oj. Det var ju en sv˚ ar fr˚ aga. K¨ anner du att du inte kan svara f˚ ar du s¨ aga det ocks˚ a. Jo, nej, men n˚ at svar m˚ aste jag ju kunna ha, eller en fundering. Det finns v¨al olika s¨att, k¨ anns det som. Och att det kanske ¨ar n˚ agon form av sammanv¨avd bild som ger svaret. F¨ or, allts˚ a, dels s˚ a kan man ju n˚ anstans s¨akert m¨ata, beroende p˚ a vad det ¨ar f¨or f¨orm˚ aga vi pratar om, men liksom, ”Hur m˚ anga, vad det nu ¨ar man hanterar, klarar vi av att hantera per tidsenhet?”. Och ¨ ar det n˚ anstans i paritet med vad man har som m˚ al eller som branschen g¨ or eller s˚ a d¨ ar, s˚ a kan man ju tycka att, ja, d˚ a m˚ ar den ju bra p˚ a ett visst s¨att. Men sen m˚ aste man ju f˚ a in, de som jobbar, med den h¨ar f¨orm˚ agan, kanske ¨ar frustrerade ¨over n˚ anting. Och det kan vara olika saker, systemst¨od eller att det ¨ar n˚ at knasigt i processen, eller s˚ a d¨ ar. S˚ a, jag tror att det ¨ ar sv˚ art att se, liksom, p˚ a en g˚ ang, ”Den h¨ar f¨orm˚ agan m˚ ar inte bra”, jag tror man m˚ aste dela upp det i liksom, n˚ an form av, process, organisation, system, kanske n˚ at mer, och liksom f¨ors¨oka f¨orst˚ a, ¨ar allt gr¨ont, s˚ a kanske f¨orm˚ agan m˚ ar v¨ aldigt bra. Sen kan det s¨ aker vara n˚ at som ¨ar r¨ott, men det m˚ ar ¨and˚ a n¨astan bra f¨or vi klarar av det genom en heroisk insats, liksom. D˚ a kan man ju fundera p˚ a vad som ¨ar viktigast, liksom. F¨ or levererar man efter det man borde kunna g¨ora s˚ a kan man ¨and˚ a s¨aga att den m˚ ar ganska bra. Det ¨ ar ett sv¨avande svar, men ja. Finns det n˚ agot som p˚ averkar en f¨ orm˚ agas v¨ alm˚ aende mer ¨ an annat? Ja, jag tror att.. Vilken sv˚ ar fr˚ aga. Jag tror nog mycket, allts˚ a, hur, det ¨ar inte den enda sanningen, men, de som, s˚ a att s¨aga, utf¨or arbetet, hur de m˚ ar och tycker att det fungerar tror jag ¨ ar ganska centralt. Sen s˚ a kan ju de vara ink¨orda p˚ a, liksom, sneda sp˚ ar, och liksom, det g˚ ar att g¨ ora, n¨ ar man liksom b¨orjar skrapa p˚ a ytan s˚ a inser man att ”Den h¨ ar f¨ orm˚ agan m˚ ar inte s˚ a bra”, ¨ aven fast de ¨ar j¨atten¨ojda f¨or ‘’det flyter ju j¨attefint och bra”. Me ˚ a andra sidan, ¨ ar det n˚ at som inte funkar s˚ a kommer ju de vara, liksom, d˚ a kommer det ju m¨ arkas. Men sen s˚ a tror jag v¨ al, det tror jag ¨ar en sak, och sen s˚ a tror jag v¨al att, allts˚ a, st¨ od, om det ¨ ar, liksom, IT i form av h˚ ardvara eller mjukvara, eller om det ¨ar n˚ at annat, ja, men, liksom, ja, st¨ od i det arbetet, det tror jag ocks˚ a ¨ar v¨aldigt viktigt. Tror du att det finns n˚ agra egenskaper hos f¨ orm˚ agan som p˚ averkar hur den m˚ ar? Kan du ge n˚ at exempel p˚ a..? Nja, vi kollade ju p˚ a det h¨ ar med element som kan p˚ averka, element som ¨ ar kopplade utifr˚ an, s˚ a det h¨ ar ¨ ar mer om hur ni tycker att f¨ orm˚ agan har n˚ agra egenskaper som a ¨r dess egna snarare ¨ an kopplade till den, som p˚ averkar hur den m˚ ar. Jag f¨ ors¨ oker ocks˚ a fundera p˚ a vad.. Spontant s˚ a skulle jag ju s¨aga, eller tycka, jag kommer inte p˚ a n˚ at bra. Det ¨ ar ocks˚ a ett svar. 95 F¨ or det ¨ ar v¨ al lite min ˚ ask˚ adning, att det ¨ar olika typer av komponenter som g¨or att man g¨ or n˚ agonting, och det ¨ ar de tillsammans som bildar den h¨ar f¨orm˚ agan. ¨ det n˚ Ar agra av elementen vi pratat om tidigare som du tror p˚ averkar f¨ orm˚ agan och dess v¨ alm˚ aende mer ¨ an andra? Vad blir skillnaden d¨ ar mot f¨ orrf¨ orra fr˚ agan? Den var mer en chans f¨ or er att prata allm¨ ant, nu ¨ ar det mer specifikt vilka av elementen det kan r¨ ora sig om. Har du listan ¨ over vilka jag klickade som relevanta? Absolut. Applikation, dels st¨ odjande och som st¨ ods. Ja, det tror jag ju. Fr˚ agan var om det var n˚ agon som var extra viktig? Ja, precis, om det ¨ ar n˚ agon som p˚ averkar mer ¨ an andra. Alla kanske p˚ averkar p˚ a n˚ agot s¨ att eftersom de a ¨r kopplade till f¨ orm˚ agan, men vissa kanske ¨ ar mer avg¨ orande f¨ or f¨ orm˚ agans v¨ alm˚ aende. Det k¨ anns ju som att det beror p˚ a vad det ¨ar f¨or f¨orm˚ aga man pratar om. Men Applikation tror jag ¨ ar centralt, i de flesta. Det ¨ar f˚ a f¨orm˚ agor, finns s¨akert en del, men de flesta har ju n˚ agon form av systemst¨ od. Information? Ja, det tror jag g˚ ar ˚ at skogen om man inte har bra information. IT-st¨ od? H¨ anger ihop med Applikation. Kostnad och KPIer? Och ¨ ar det allts˚ a kostnad f¨ or att utf¨ora f¨orm˚ agan? De kostnader som ¨ ar associerade med f¨ orm˚ agan, ja. Den tycker jag ju d˚ a kanske inte a¨r lika viktig ur ett v¨alm˚ aendeperspektiv, f¨or jag tror att f¨ orm˚ agan kan m˚ a j¨ attebra, ¨ aven fast det kostar f¨or mycket pengar. KPIer? Ja, allts˚ a, d¨ ar handlar det ju mer om att f¨orst˚ a om den m˚ ar bra, men jag tror, det ¨ar ju inte n¨ odv¨ andigtvis s˚ a att den m˚ ar d˚ aligt, ¨aven om vi inte kan p˚ avisa att den m˚ ar bra. S˚ a nej. D¨ aremot s˚ a tror jag den ¨ ar viktig f¨or att kunna fintrimma f¨orm˚ agor, men det ¨ar inte centralt f¨ or att den ska kunna m˚ a bra. Krav, och specialfallen Lag, Regel, Policy? Nej, den tror jag ocks˚ a ¨ ar lite s˚ a d¨ar, det ¨ar centralt om det visar sig att f¨orm˚ agan inte m˚ ar bra, f¨ or d˚ a m˚ aste man g¨ ora n˚ anting. Men det kan ju vara s˚ a att den funkar j¨attebra 96 ¨ven fast vi har j¨ a atted˚ alig koll p˚ a kraven, d¨arf¨or att de m¨anniskor som h˚ aller p˚ a med det h¨ ar faktiskt vet vad de g¨ or. Organisation? Ja, det ¨ ar ju viktigt, av samma anledningar som jag sa d¨ar i b¨orjan, jag tror att de som g¨or det beh¨ over tycka att det k¨ anns bra. Process? Ja, den tror jag ¨ ar viktig. Risk? Ja, vad menar vi d¨ ar, egentligen. Nej, den tror jag, allts˚ a, det k¨anns ocks˚ a som en s˚ an h¨ ar, mer kontroll. Det har egentligen ingenting med hur bra den m˚ ar, utan det handlar ju om hur vi sk¨ oter den. System? H¨ anger ihop med Applikation och IT-st¨od. Tj¨ anst? Nej, den k¨ anns inte som att den riktigt passar in. V¨ ardetr¨ adet? Ja, allts˚ a, om det ¨ ar s˚ a att man inte kan mappa en del av v¨aredtr¨adet till f¨orm˚ agan, d˚ a borde man ju ifr˚ agas¨ atta varf¨ or vi har den f¨orm˚ agan, givet att v¨ardetr¨adet ¨ar komplett. Sen kan ju f¨ orm˚ agan m˚ a v¨ aldigt bra, ¨ aven om det ¨ar en redundant f¨orm˚ aga. S˚ a ur det perspektivet tycker jag inte den ¨ ar viktig. Det ¨arju lite som KPIerna, allts˚ a den beh¨ovs inte f¨or att f¨ orm˚ agan m˚ ar bra, d¨ aremot ¨ ar det viktigt att f¨orst˚ a hur den passar in i v˚ art v¨ardeskapande. Har n˚ agra av elementen egenskaper som p˚ averkar f¨ orm˚ agans v¨ alm˚ aende? Exempelvis kanske upptiden hos ett system. Ja, allts˚ a, det tror jag. Mycket just kring, om man knyter tillbaka till den utf¨orande organisationens v¨ al och ve, ¨ ar ju ofta t¨ att sammankopplat med, allts˚ a, att sytemst¨od eller st¨od fungerar friktionsfritt. Att det ¨ ar uppe, att det ¨ar snabba svarstider, att man inte f˚ ar felmeddelanden man inte borde f˚ a och liksom skapar irritation i det d¨ar, utan att man f¨orv¨antar sig att f˚ a ett st¨ od, och det f˚ ar jag. S˚ a, allts˚ a, den typen av tekniska f¨oruts¨attningar, som inte har med, liksom, det mer specifika f¨orm˚ agest¨odet att g¨ora utan snarare vad alla tycker ar hygienfaktorer, det tror jag har v¨aldigt stor p˚ ¨ averkan. Respondent 12 Hur kan man se om en f¨ orm˚ aga m˚ ar bra eller inte? D˚ a m˚ aste man ju veta var den finns implementerad, allts˚ a vilka processer. Och processerna kan man ju alltid m¨ ata och f¨ orst˚ a hur effektiva de ¨ar d˚ a. S˚ a p˚ a s˚ a s¨att s˚ a ser du ju om f¨ orm˚ agan m˚ ar bra eller d˚ aligt. Vad tror du p˚ averkar en f¨ orm˚ agas v¨ alm˚ aende mest? 97 Jag tror att det ¨ ar en definition ”Vad ¨ar en v¨alm˚ aende f¨orm˚ aga?” som man m˚ aste fundera p˚ a. Betyder det att vi kan utf¨ ora den? Betyder det att den ¨ar effektiv? Beroende p˚ a vad du l¨ agger f¨ or dimension i, allts˚ a, och det ¨ar ju fortfarande, om vi g¨or en f¨orm˚ aga som vi inte har ett enda systemst¨ od f¨ or, m˚ ar den d˚ aligt d˚ a? Det beh¨over den ju inte g¨ora. Har f¨ orm˚ agan n˚ agra egenskaper som kan p˚ averka hur den m˚ ar? Som inte ¨ ar element kopplade till den utan egenskaper hos den. Ja, allts˚ a, en f¨ orm˚ aga. Ja, det beror ju p˚ a vad man menar med element kopplade. T¨anker du p˚ a regelverk, ¨ ar det ett element som kopplas till? Ja, det skulle jag s¨ aga. Ja, f¨ or beroende p˚ a hur, ja, yttre krav och inre krav p˚ a en f¨orm˚ aga, s˚ a ¨ar ju det hur l¨ att den ¨ ar att applicera, skulle jag vilja s¨aga. Och d˚ a ¨ar det v¨al kanske, det kan ju vara lagkrav det kan vara interna m¨ atgrejer som g¨or att den ¨ar helt hoppl¨os. Elementen kopplade till f¨ orm˚ agan, ¨ ar det n˚ agra som p˚ averkar f¨ orm˚ agans v¨ alm˚ aende mer ¨ an andra? Jag kan l¨ asa upp dem om du vill. Ja tack. Har du gjort n˚ an definition p˚ a vad det betyder ”att m˚ a bra”? Nej, det a ¨r det jag fr˚ agar er nu i de h¨ ar intervjuerna. Ja, f¨ or dels s˚ a kan man ju s¨ aga, det ¨ar ju liksom, hur v¨al f¨orst˚ ar vi hur den ska funka, hur v¨ al har vi f¨ orberedda processer f¨or den, b˚ ade digitala och manuella. Det ¨ar, om man s¨ ager, att den m˚ ar bra. Ja, vem ¨ ar det som bed¨omer att den m˚ ar bra? K¨anner vi att vi f¨ orst˚ ar den eller att vi kan utf¨ ora den, m˚ ar den bra d˚ a? Allts˚ a, man skulle nog beh¨ova ha en liten definition p˚ a ”att m˚ a bra” tror jag. F¨or det kan vara s˚ a h¨ar ”vet jag vad jag ska g¨ ora, ja d˚ a m˚ ar den bra”, ”vet jag hur jag ska g¨ora det, ja d˚ a m˚ ar den ¨annu b¨attre”. ”Har jag inget systemst¨ od utan g¨ or allt manuellt, d˚ a m˚ ar den ganska d˚ aligt”, eller? Det ¨ar tycke och smak, s˚ a jag tror att man m˚ aste tala om litegrann vad man menar med ”att m˚ a bra”, eller att det kan vara olika grader av bra d˚ a. Okej. Nu, vill du ha alla element eller de du kryssade f¨ or som relevanta? L¨ as upp alla. F¨ or nu var fr˚ agan vilka som p˚ averkade? Ja, om det ¨ ar n˚ agra som du tycker p˚ averkar f¨ orm˚ agans v¨ alm˚ aende mer ¨ an andra. Applikation, st¨ odjande och som st¨ ods. H¨ andelse. Information. Input. IT-st¨ od. Kompetens. Kostnad och KPI. Krav, och specialfallen Lag, Regel, och Policy. Organisation. Output. Process. Resurs: Risk. Roll, System. Tj¨ anst. V¨ ardetr¨ ad. Vilka som f˚ ar den att m˚ a bra? Ja, om det ¨ ar n˚ agra du tycker sticker ut och p˚ averkar mer ¨ an andra. Ja, det ¨ ar regler, d˚ a, det ¨ ar ju en , och processer ¨ar en. De tv˚ a skulle jag ju highlighta. Har elementen n˚ agra egenskaper som p˚ averkar f¨ orm˚ agan v¨ alm˚ aende? Tex kanske upptid hos ett system. 98 Alts˚ a, det ¨ ar ju, kompetens och kunskap om f¨orm˚ agan, det ¨ar ju det som ¨ar A och O. Om vi inte har kompetens runt vad det h¨ar inneb¨ar eller hur man ska g¨ora det h¨ar, vad det nu kan vara f¨ or n˚ agonting, d˚ a m˚ ar man ju riktigt illa. N˚ agot att till¨ agga? Det som man b¨ or t¨ anka p˚ a ¨ ar att f¨orm˚ agan i sig, den bor ju i ett kontext. S˚ a det ¨ar sv˚ art att s¨ aga, ja, ”hall˚ a”. Utan det ¨ar ju allting, jag menar, har du ingen, f¨or att utf¨ora det h¨ ar, din f¨ orm˚ aga, vad du beh¨ over g¨ora, d˚ a m˚ aste du ju ha b˚ ade resurser och processer och eventuellt systemst¨ od d˚ a, och sen beror det ju p˚ a hur komplex den d¨ar ¨ar, p˚ a vilket s¨att du m˚ aste ha st¨ od. S˚ a om man skulle g˚ a och fr˚ aga en verksamhet s˚ a h¨ar ”Var g¨or det ont hos er?”, ja d˚ a kommer de s¨ aga ”Det g¨or ont h¨ar, f¨or vi vet inte hur vi ska g¨ora”, eller ”Det g¨ or ont h¨ ar, f¨ or det tar s˚ a j¨ adra l˚ ang tid’, s˚ a det ¨ar ju det, d¨arf¨or tror jag att det ¨ar bra om man f¨ ors¨ oker definiera ”Hur m˚ ar en f¨orm˚ aga?”, ja, ur vilket perspektiv? 99