Modelling Business Capabilities with
Enterprise Architecture
A Case Study at a Swedish Pension Managing Company
SOFIA BERGSTRÖM
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 Bergström
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 undersöker hur verksamhetsförmågor används
inom enterprisearkitektur, och vidare hur förmåge-konceptet används på det svenska pensionsföretaget Folksam. Baserat på intervjuer med intressenter skapas en metamodell med
verksamhetsförmågan i centrum. Metamodellen revideras och ändras sedan enligt ett frågeformulär vars mål var att ta bort ej relevanta element, och enligt en andra omgång intervjuer
där en förmågas hälsa diskuteras. Denna andra omgång intervjuer resulterade i att element
som inte påverkade förmågans hälsa togs bort. Den slutgiltiga metamodellen har verksamhetsförmågan och dess hälsostatus i fokus. Den består av förmåge-elementet, med två
attribut, omgärdat 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, João 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 gå vidare från 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 verksamhetsförmågor. 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 började jobba på Folksam här 19e januari, så jag har inte jobbat här jättelänge. Jag
jobbar här som verksamhetsarkitekt på koncernarkitektur. Innan dess så har jag jobbat på
SEB, som deras motsvarighet till affärsarkitekt, där kallas det Enterprise Business Architect.
Där jobbade jag på verksamhets-sidan, och det är väl där egentligen som jag också kom i
kontakt och jobbade med förmågor, från början då. Och, vad ska man säga här. Jag har
kommit in här på Folksam och kommer jobba litegrann inom riskområdet, och även arkitekturstödjande då. Och där har vi börjat titta på det här med förmågor. Man har ju jobbat
ganska länge med förmågor, och jag diskuterade också med Charlotte tidigt, när vi hade
vår dialog ikring hur vi hade jobbat på SEB och hur de jobbar här. Så det är väl litegrann
bakgrund. Innan jag jobbade på SEB, där jag började 2011, så har jag jobbat ett par år
som konsult inom många olika delar, i början som utvecklare, har jobbat som projektledare,
har jobbat mycket inom management strategi-konsulting och så. En bit bakgrund.
Så, kortfattat: vad vet du om förmågor och verksamhetsförmågor, och hur använder ni
det?
Jag jobbar med det ungefär sen 2011, som egentligen ett verktyg i Enterprise Architecturearbetet. Jag har ganska tidigt börjat jobba med Enterprise Architecture, typ 2001 nån gång
började jag med de tankarna, sen har jag kontinuerligt byggt på olika verktygssätt att arbeta
med där då, och förmågor ser jag som ett sätt att skapa en högre nivå av diskussion med
intressenter, så man inte behöver gå ner och fastna i detaljer för att scopa in saker och ting,
för att identifiera problemområden och så vidare. Det blir så lätt annars att man utifrån
kanske ett affärsområde eller en specifik kunskap fastnar i en detalj som är ganska oviktig på
totalen, men det för inte dialogen framåt. Jag kan säga att när vi tittade på förmågor, när
jag började titta på det då, kring 2011, då använde vi oss mer ur ett affärsfunktionskoncept,
alltså egentligen en behållare du kan lägga affären i då, olika delar. Och det var mycket ur
analyshänseende då, så at man kunde på ett enkelt sätt mappa ner det, men ”vad är det
för nånting ett speciellt initiativ eller en satsning kommer beröra?” ”Vad är det vi behöver
tänka på så att vi får med allting?” Så det var mer ur det perspektivet än att vara specifik på
att ”det är precis det här” eller ”det är bara 20% av den här delen”, utan vi bara markerade i
form av en heat map att det här och det här och det här området, det berörs. Sen började ju
vi väva ihop egentligen, sätt att se, men ”hur förhåller sig förmågor till affärsmodeller”, ”hur
förhåller de sig till värdekedjor” osv. Och det jobbade vi ganksa mycket med att få ihop det
tänket, så vi kunde ha olika typer av verktyg, och prata med olika personer i verksamheten,
beroende på var de var och vad de hade för , egentligen bakgrund och kunde förstå. Vissa
kunde vi prata förmågor med, andra pratade vi affärsmodeller, och så mappade vi ner själva
till förmågor. Och det är väl det sättet som jag har sett att det funkat bäst. Man kan ju ta
då som exempel att om vi får ett lagkrav på oss, ja men då kanske man tittar på en specifik
affärsmodell, ja men ”vad var det nånstans det här kommer röra?” ”Jo men det kommer
röra rapportering”, ”det kommer röra kunderbjudande” och så vidare. Har man tagit den
nivån, ja men då kan man ploppa ner det sen på förmågor, och se ”Vilka förmågor är det
50
som det berör?” Och då beror det ju på vad vi lägger i den här förmågecontainern då. Och
mitt synsätt på det har ganska pragmatiskt varit fyra komponenter: det har varit organisatoriska, det har varit process, det har varit information, och det har varit system. För att
kunna, liksom, har du landat i en förmåga ”Berör det organisation?”, ”nej, det berör inte
organisation”, ”berör det processer?”, ”ja, det berör det”, och sen ” okej, automatiserade
processer” och i så fall vilka. Så att man liksom har kommit ner till någon typ av att man kan
göra analyser. Så det är så liksom, de sättet man hänger ihop det på. Det mindset’et har jag.
När dök det här upp, konceptet med förmågor, och på vilket sätt, i vilket sammanhang?
Sammanhanget var egentligen att, och det var tillbaka när jag jobbade på SEB, att vi
hade en funktionskarta. När vi började titta på den och hur den funkade, och även hade
omvärldsbevakning och man började diskutera mer och mer förmågor, det dök upp nån
stans där 2010-2011, det var då jag började få upp det på kartan. Då började vi titta på det
”Ja, men det här är ju i stort sett förmågor”, så. Sen hade vi ett ganska pragmatiskt sätt
att se att vi hade den här affärsfunktionaliteten, den här komponenten eller förmågan, det
var en nivå 1:a för oss, och sen det vi hade under den direkt, vi bröt inte ner den i separata
förmågor utan vi sa att ”nej men vi tar våra processer, så lägger vi huvudprocesserna i den
förmågan, så vet vi att de håller någon typ av funktionalitet på det sättet”. Sen kan man
ju titta på den och se att det fanns ju för- och nackdelar med att göra det. Processerna är
ju bara en del av en förmåga egentligen, men det fyller den funktionen som vi ville ha då.
Så säg 2011 därikring. 2010-2011.
Hur har du använt dig av förmågor?
Det är just egentligen, jag har jobbat mycket med Quality Assurance, på projekt och så
vidare, och en del i det var att vi i dokumentationen hade att projekten skulle fylla i med
vilka komponenter det är de spänner över. Och det var ju förmåge-delen, så att säga. Då
fick de egentligen beskriva, till den nivå som de visste vid tillfället. Det är ju olika delar
i olika faser för olika projekt hur mycket de vet men, först börja övergripande ”Ja, men
det kanske bara rörde en förmåga på toppnivå”, och sen kunde de gå ner och markera ”ah,
men just det, den och den processen rör det då, och sen den här organisationen”. Så att
det var egentligen ur att säkerställa då att jag som stakeholder från verksamhets/IT-sidan
säkrade upp att projekten hade rätt scope. Och likadant att var de i ett visst område man
kunde se på den här kartan om det var andra saker ”Ja, men det här rör sig där” man kunde
få nån typ av korsreferens hur projekten rörde sig. Så mycket ur liksom analys och planering.
Förutom då Quality Assurance, vilka andra användningsområden kan du se för förmågor?
För dig/avd...
Nej men det är just.. En del det är ju att kunna få grepp om helheten, för det är ju
det som liksom är huvudsyftet tycker jag, att kunna se ”Ja man hur slår det här” och ”hur
slår det i jämförelse med andra satsningar” och så vidare. Jag är väldigt försiktig med att
liksom hitta, ja men ”nu ska vi mäta på förmågor” för en förmåga den är egentligen konceptuell, den är inte specifik. Den kan bestå eller stödjas av många olika saker, en process
till exempel. Och en process, den kan du mäta. Du kan tidsmäta, och vad har den för
genomströmning och vad har du för resultat och så vidare. Men det är bara en liten del.
Om man skulle liksom, rita en cirkel här som är förmågan, så den här delen, 60% eller vad
det nu är (ritat 30-40), består av mätbara delar, som process, organisation osv. Den här
andra delen här, det är annat. Det kan vara liksom, du råkar sätta tre personer som har en
viss bakgrund i samma rum och använder olika saker och då får du en en effekt, men den
är liksom inte så här påtaglig. Och därför så tror jag att det kan vara svårt att mäta på
förmågor. Du kan mäta på stödjande 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
utanför Folksam, så är det inte säkert att du får samma resultat i förmågan i vilket fall. Så
därför är jag lite försiktig när man säger att man ska mäta på förmågor. Jag tror att man
kan mäta på process och information osv. Sen kan det ge en indikation på hur förmågan
mår, så det är lite så. Men mätbarhet, ja, till viss del, subjektiv då. Och det kan också vara
då att har du identifierat områden som du känner att du måste förbättra, ja men då kanske
du går ner ännu mer och kollar på, ja, men ”Kan vi utöka den delen som vi vet, och minska
det här frågetecknet?”
Vad ser du skulle vara relevant att mappa till en förmåga, utom just process, information,
organisation (och system)?
Jag skulle säga att du skulle egentligen kunna koppla vad som helst till en förmåga, det
beror bara på vad du sätter för relation, och på den kopplingen. Litegrann den här cirkeln
som jag ritade där, det kan vara system som stöder saker och ting, det kan vara kompetenser, organisatoriska uppsättningar, ja men hur du sätter upp din organisation, det kan
vara de ingående kompetenserna också. Det kan vara, du skulle kunna ta till exempel att
våran VD har ett kontaktnät ute i organisationen, eller ute på marknaden, som gör att vi
får bra kontaktytor och kan göra bra avtal, så. Det är ju något som förbättrar vår förmåga
att göra försäljning, men den är ju inte så jättepåtaglig, men den skulle kunna finnas där.
Så att jag tror att det är mycket som bygger upp förmågorna. Sen är det vissa delar som
vi kan pinpointa och analysera och förbättra, och andra saker sitter i väggarna. Så att jag
skulle kunna säga att de här sakerna som du har räknat upp här: Krav, ja, du kanske kan
sätta nån typ av krav på den, men jag tror inte du ska koppla krav till en förmåga. Du
kan förbättra en förmåga, men kraven kommer du att sätta på en organisation, process eller
nåt sånt. Resurser, ja, du måste ha resurser som stödjer en förmåga, men att troligtvis så
stödjer de ingående delar i den istället, och inte förmågan som sådan. Resultatet av det
blir att förmågan förbättras eller försämras. Så att jag tror att, direkt och indirekt, och jag
vet inte om vi har nån nytta av att liksom, sätta hela fulla metamodellen för den, utan jag
tror att det är viktigare att vi riktar in oss på saker och ting som vi ser är relevanta för
oss som vi kan förändra. Och jag skulle säga att huvudingredienserna är egentligen de här
fyra. Lägg till/ta bort personal, utveckla personal, förbättra din process, eller så. Det är
det som i en förändringsprocess är såpass påtagligt. Sen kan man ju, man måste se det som
en helhet. Man kan inte bara modernisera det ena eller det andra, så. Så att jag skulle inte
vilja begränsa mig till att du inte kan koppla saker och ting till en förmåga, men frågan är:
Ger det dig någon reell nytta i ett förändringshänseende? Och det tycker jag är viktigt.
De som du tycker är vettiga att koppla till förmågan är alltså de fyra du har nämnt?
Ja, men det är de här fyra som jag sa: organisation, information, system, och process.
Och det kan man ju, liksom, det är litegrann därför jag skickade det här till dig också,
det här med verksamhetsförmåga, vad är en verksamhetsförmåga eller en förmåga eller en
IT-förmåga? Det är ingen ide att kalla den, säger du verksamhetsförmåga då finns det nån
annan typ av förmåga också, implicit. Och pratar du om IT-förmågor, ja men det är ju
egentligen en förmåga som är automatiserad, så. Så att vi vinner ingenting på att lägga upp
flera olika begrepp. Vi har haft diskussioner om affärsförmågor och verksamhetsförmågor.
Affärsmodell, ja, men en affärsförmåga..? Nja. Jag tycker det är att skapa onödiga konflikter.
Men sen har vi ju samtidigt haft, apropå att man avänder förmågor, förmåga inom HR då,
och då är det också, ja, förvisso. Vi använder ju tjänst och andra begrepp också beroende på
hur verksamheten ser ut. Så jag tror inte man ska ta nåt patent på det, men det är ju viktigt
att förstå vad vi användet det till, och varför kallar vi det förmåga. På engelska, capability, ja, det är väldigt nära ability och så vidare, men vi har inte så bra svenska ord för allting.
52
Så de här fyra som du tycker är relevanta..
Och de tror jag också att vi bör modellera i FAR6 , så vi får liksom ett meta-stöd för dem.
De är ganska uppenbara, de finns på alla förmågor.
Så varför och vilka element det skulle vara har vi ju då avhandlat lite redan..
Sen tror jag som man har satt som inriktning här på Folksam är ju att man vill ha möjlighet
att mäta på förändring. Som 2018 då vi ska ha genomfört ett visst antal saker, det är ju
bra att kunna se, så att säga, hur gör vi då den förflyttningen? Där tror jag att förmågorna
har en roll, men det är en pusselbit bland andra, så att säga. Sen finns det ju det här begreppet ”Tala med bönder på bönders vis” och så vidare, men det är ju litegrann det. Vissa
kommer du behöva prata förmågor med, andra får du prata, liksom, systemkartor med, och
en tredje kommer det vara informationsmodeller. Men det gäller att de hänger ihop och att..
Att man kan mappa allt till sammma?
Ja, men liksom, pratar du om en sak med en, då får ju inte det divergera mot andra
typer av modeller för att då kommer du inte nå ett gemensamt resultat. Men sen att det
finns olika typer av verktyg. Jag kan se att till viss del skulle man kunna ha verktygslådan i
form av förmågor, ja, men den skulle kunna vara en intern angelägenhet för arkitektur, så.
Man behöver inte sälja på den, men däremot så pratar man kanske utifrån den för att ha ett
gemensamt ramverk, men för den delen så behöver man inte trycka upp en modell i ansiktet
på verksamheten och säga ”Det här ska vi använda nu!”. För att det är min erfarenhet
också, att, liksom, powerpoint i all ära, men du måste ha en acceptans från den mottagare
du har, på det sättet som du vill jobba. Och visst, vill de jobba med förmågor och förstår
det och så vidare, ja, men då ska du göra det. Men jag tror inte du kan tvinga på någon
det, då får man hitta på andra sätt. Och sen mappa hemma istället. Så det är lite arbetssätt.
De här fyra elementen, tror du de påverkar förmågan, eller blir påverkade av den, om det
sker förändringar?
Min syn på det är att alltså ingående delarna stödjer förmågan. Så att svaret på det du sa
det är väl både och. För eftersom på nåt sätt förändrar du ingredienserna, ja men då kommer resultatet bli något annat. Men.. Det blir så här meta-meta.. Jag menar, förmågan att
genomföra en process, ja men det är ju en sak, men hur den processen stödjer en förmåga,
det behöver ju inte vara samma förmåga den stödjer liksom. Abstrakta saker.
Vilka delar av en förmåga eller elementen påverkas av varandra? Hur ser mappningen
mellan dem ut?
Du kan ju ha beroenden mellan förmågor, det kan du ju ha, i och för sig, om du ska
ha ett resultat. Det vi.. Jag kan visa bara hur vi försökte få ihop den här röda tråden på
SEB. Då hade vi affärsmodeller, och då använde vi Business Model Canvas för den. Då är
det egentligen en flerfärltare som består av att du har ett värdeerbjudande, Value Proposition, i mitten. Du har hur du vill ha relation till dina kunder, du har dina kunder, du
har kanaler. Sen på den här sidan så har du Key Activities, Key Resources och Partners.
Så kan man lägga en aspekt på det att man har Cost och Income. Vad vi gjorde med den
här, det var att vi hade affärsmodeller, fyra-fem stycken, inom den affär jag jobbade då.
Då sa vi det att det som ligger här, Key Resources och Key Activities, det motsvarar de
förmågor som vi har. På en hög eller en låg nivå, vi satte ingen aspekt på det, men här
skulle det till exempel kunna innefatta en Key Activity här är rapportering för att du ska
6 Folksam’s
Architecture Repository
53
få ut någon typ av värdeerbjudande till kunden här då. Det skulle kunna vara att du har
IT-resurser här eller nånting annat som stödjer förmågan. Så då sa vi att den kopplingen
finns då. Sen sa vi också det att de här delarna, Key Activities och Key Resources, de kan
även bygga värdekedjor, liksom, från början till slut i nån typ av leverans. Och då skulle de
här förmågorna, så att säga, vara staplade på led då. Den använde vi inte så mycket, men
den fanns i varje fall. Och sen hängde vi på de här andra sakerna då, organisation och så
vidare. Så det var liksom våran röda tråd vi jobbade efter där. Men det man kan säga här,
om man skulle bortse från den där (BMC), och bara titta på förmågedelen, så skulle ju en
förmåga kunna bestå och stödjas av en process på det här sättet. Den processen skulle ju
kunna stödja en annan förmåga också. Så att här har du ju ett beroende mellan förmågor på
något sätt, och likadant en organisation skulle ju kunna stödja olika typer av förmågor. Man
skulle ju kunna ha en förmåga, en dålig förmåga som heter bara rapportering, det är inte
så mycket av en förmåga, men möjligheten att göra myndighetsrapportering. Vi kommer
ju göra det i en mängd olika processer, för en mängd olika rapporter. Vi kommer göra det
i olika organisationer också. Det behöver inte vara myndighetsrapportering, det kan vara
bolagsstyrningsrapporter, eller det kan vara Solvens, det kan vara vad som helst, men det är
många saker som stödjer den. Men däremot att förmågor skulle vara beroende av förmågor
på det här sättet (direkt kopplade), den blir lite knasigare ur ett analyshänseende. För att
då får du liksom att en förmåga, då kan du aldrig liksom lyfta ut det eller så, och då tror
jag att då har man hamnat lite knasigt i vad en förmåga är, om man börjar få beroenden
mellan förmågor på toppnivåer. Sen längre ner så kan det ju, klart, om du ska bygga ihop en
värdekedja, ja men det måste ju finnas, så att säga, bitar ur olika typer av förmågor, så, för
att det ska funka. Men på toppnivå så tror jag att det inte ska vara kopplingar mellan. Se
det mera som byggklossar som du använder för att bygga ihop det stöd du behöver ha då.
Och litegrann den också, relaterat till det här med affärsmodeller. Har du då en legolåda
här (förmågorna), så skulle du kunna bygga helt nya affärsmodeller om du använder de
förmågorna som du har, bara det att du konfigurerar dem på ett annat sätt. Så, lite så är
mina tankar.
Respondent 2
Vilken position har du, hur länge har du haft den, och hur länge har du jobbat på Folksam?
Jobbar som verksamhetsarkitekt, och nu jobbar jag med nånting som heter Koncerngemensamt. Och det har vi väl inte gjort så där jättelänge, det är väldigt nytt, så det är bara
några månader gammalt. Innan dess jobbade jag som verksamhetsarkitekt inom produkt
och ekonomi, och det gjorde jag i ungefär två år, knappt. Och innan dess jobbade jag ganska
länge inom skadeorganisationen, också som verksamhetsarkitekt. Det kanske räcker så, men
totalt sett så har jag väl varit på Folksam i ungefär 13 och ett halt år, och varit i princip
nästan överallt utom i köket.
Kortfattat, vad vet du om förmågor?
Ja, att det finns ju lika många uppfattningar om vad en förmåga är och vad det borde
vara som det finns nästan personer. Sen finns det många som vill använda olika typer
av standardmodeller att utgå ifrån. Och jag har väl kommit till det läget att det är väl
klart att de är bra, men jag tror att vi kommer aldrig bli färdiga liksom ”Det här är exakt
våra förmågor”. Men det är viktigt att vi har någnting att diskutera med verksamheten
som de förstår och känner igen sig i, i alla fall på ett någorlunda bra sätt. Sen kommer
den ju alltid att behöva justeras. Men de beskriver ju som sagt vad man ska hantera i en
affärsverksamhet, inte hur då, vilket då är en process.
Hur länge har du jobbat med förmågor?
54
När det dök upp? Som första gången här på Folksam så har det nog varit, ja, jag skulle gissa
att vi har hållit på och provfuskat i ungefär 2 års tid, mer eller mindre, i olika omgångar.
Men det är väl egentligen inte förrän nu på sistone som det har tagit lite mera skruv, om
man säger så.
Hur kom du i kontakt med förmågor? Hur introducerades det? Var kom det ifrån?
Var det kom ifrån? Ja, det kom i yrket, därför att vi har ju valt att beskriva verksamheten..
Man kan ju beskriva en verksamhet på massa olika sätt, och vi har ju länge försökt att
dokumentera saker och beskriva saker i processer. Och vi fann då att det fanns, att det har
blivit lite, så att säga, förbrukat, om man uttrycker sig så. Det vi vill hitta är en mera, så
att säga, neutral beskrivning av verksamheten, och det var då som vi hittade de här, liksom,
förmågorna. Och fördelen med förmågorna är ju att de är inte knutna till en organisation
på samma sätt som kanske processer är, på det sättet.
Har du använt dig av förmågor?
Oh ja. Bland annat så har vi använt det för att försöka beskriva vad är det nånting som
man har för ansvar, och vad är det som man jobbar med inom området Ekonomi. Och då
menar jag inte organisationen Ekonomi utan hela området ekonomi. Att försöka beskriva
vad är det för verksamhet, eftersom man måste försöka hålla rätt på, och styra och kontrollera. Och vi kommer också använda det i strategiarbetet som vi håller på med nu, inom
koncerngemensamt, där vi försöker att bedöma ”Hur bra mår en förmåga?”. Och då har vi
liksom en skala, från Rött - fungerar inte alls, Orange, Gult, och Grönt - fungerar kanonbra.
Men sen har vi gått vidare och tittat litegrann på varför mår en förmåga inte Grönt, vad
beror det på? Och då gör vi samma beräkning där, eller bedömning där, så här ”Beror det
på processerna?”, dvs hur bra mår processerna? Och ”Hur jobbar vi gentemot andra?”. Det
är också huruvida vi har god kvalitet på den information vi hanterar, och allt vi tar med,
det påverkar också. En tredje viktig aspekt är ju då vilken kompetens är det egentligen vi
besitter och har för att hantera den här förmågan. Den ytterligare biten är då ”Hur mår
systemstöden som ska stötta de här förmågorna?”, och slutligen har vi också en ytterligare
extra variabel, det handlar ju också om integration, för information spänns ju inte mellan
bara två applikationer, utan det kan vara en hel skog med saker. Och det där försöker vi
då använda för att bedömma, om inte en förmåga mår speciellt bra, vad beror den på? För
annars är det ju ofta att man vill använda argument att ”Vi behöver ett nytt IT-stöd”, eller
”Vi behöver ett förändrat arbetsstöd”, men ett IT-stöd hjälper inte en dålig process. Om
man automatiserar en dålig process så blir den inte bättre. Om man har dålig information,
så blir den inte bättre för att de får ett IT-stöd. Har man inte kompetens så hjälper det
heller inte, liksom, så det är flera aspekter. Så så håller vi, just nu i alla fall, i dagsläget på
att försöka beskriva ”Hur mår förmågor?”, ”Hur mår verksamheten?”, och ”vad beror de
här olika sakerna på?”
Vad kan du se för andra användningsområden för förmågor?
Oh, det finns en hel skog med olika typer av användningsområden. Nej, men det är ju
en lite mer neutral, så att säga, klädhängare då, som man kan realisera förmågorna till. Nu
är det ju inte så att om man nu skulle välja att, till exempel, bryta ner en förmåga, så har vi
ju sagt litegrann nu då att en förmåga kan inte bli nånting annat än en förmåga. Däremot så
kan den ha relationer med massa olika typer av saker, löst hängande. Till exempel processer,
organisation, information, kompetens, och så vidare. Men när du bryter ner en förmåga så
blir det ingenting annat än en förmåga, litegrann så.
Finns det några andra element än de du nämnde, process, organisation, som du skulle vilja
55
kunna koppla ihop med en förmåga?
Ja, det beror sig ju alldeles på vad man ska ha det till. För nu har ju vi mest använt det
för att vi, så att säga, vill göra olika typer av förflyttningar inom de här primära områdena.
Det finns säkert anledningar att titta på andra saker, till exempel Risk, vilka risker har vi?
Men det håller ju liksom litegrann Risk och Compliance på att jobba litegrann med, så där
försöker vi också använda det litegrann. Så det finns säkret flera såna tillämningar där man
kan, så att säga, utöka det här för att få det lite mera neutralt.
De element som är listade här, är det några du ser skulle vara relevanta att koppla till
en förmåga? Krav, till exempel?
Ja, när jag sen visar dig den här bilden kan du se, vi håller på att titta lite på det, vilken
information är det som är intressant utifrån, så att säga, förändringsarbete? Och då är det
ju, vilka som är direkt kopplade till en förmåga, eller vilka kommer i ett senare led. Så
att självklart kan vi koppla alla dem egentligen, mer eller mindre, direkt eller indirekt, till
förmåga. Så jag svarar ja på alla. Om man nu vill det. Men det finns inget självändamål,
utan det är ju, liksom, man vill ju liksom beskriva en verksamhet, man behöver ha nån
nytta, det är då man vill ha en koppling även till förmågorna. Så att egentligen ser jag inga
direkta begränsningar, till skillnad från till exempel processer eller andra grejer, där det kan
finnas, vara lite mer olämpligt att koppla ihop olika saker.
De här elementen, varför är just de relevanta, och hur använder ni dem?
Ja, det handlar ju först om att försöka beskriva ”Vad har vi för verksamhet?”, vi har också
vem som ansvarar litegrann. Det är vi inte riktigt överens om, om det ska finnas någon
som ansvarar för en förmåga, det håller vi på och träter litegrann om. Men jag ser att det i
alla fall finns ett ansvar att förändra, eller förbättra, eller att ha ett ansvar att, så att säga,
förmågan fungerar. Men nu har vi ju inte processägare heller, så när vi kommer till, ja,
förmågeägare, så kanske det ligger en bit framåt i tiden.
Dessa element, påverkar de eller blir de påverkade?
Ja, alla de här elementen kan ju bidra till den här förmågan, på mer eller bättre sätt.
Så tror jag det snarare är. Att du kan, så att säga, bra processer kan bidra till att vi har
en bra förmåga, har vi bra systemstöd kan vi ha en bra förmåga, att vi har bra risk och
kontroll kan bidra till den här förmågan, men kanske inte tvärt om. Så det är kanske åt det
hållet. Men det är så som jag spontant svarar på frågan just nu.
Respondent 3
Bakgrund:
Jag är verksamhetsarkitekt på Folksam, och det har jag varit i snart två år. Så jag sitter i.. under Fredrik Wahlström som Chef och Charlotte som teamledare, Charlotte Frank.
Och bakgrunden är ju att jag har jobbat inom IT-management och verksamhetsutveckling i 19 år ungefär, på olika sätt, som konsult eller som chef, för de här olika delarna då:
affärsutveckling, verksamhetsutveckling och IT-management, kan man säga.
Och du har jobbat på Folksam sen..?
Snart två år.
Kortfattat, vad vet du om förmågor?
56
Ja, jag vet egentligen det som jag har.. på det sätter som jag har jobbat med förmågor
här på Folksam då i snart två år, som vi i våran grupp har byggt upp en förmågekarta. Och
det är ju för att kunna beskriva vad vi utför, vad vi gör inom Folksam. Ja, så kan man ju..
Vi har tagit fram en karta, vi har tagit fram ett index som ska ringa in hela Folksams verksamhet, allt vi gör, inom alla olika delar. Och att sen kring varje förmåga så finns det ju en
rad information, det finns processer, och ett antal olika information som hör till förmågan.
Och vi brukar jobba med dem på det sättet att vi brukar titta vilka förmågor som påverkas
i olika förändringsprojekt, för att se skillnaden mellan olika projekt. Och kunna förstå vilka
som, ja, vilka som berör olika förmågor då, olika projekt, och kunna jämföra dem. Och
prioritera mellan dem också.
Hur länge har du jobbat med förmågor?
Ja det började jag med på Folksam, det var första gången. Så det är ett och ett halvt
år kan man säga.
Hur kom du i kontakt med förmågor? Hur introducerades det?
Ja, det var Charlotte Frank som började introducera det, och hon hade även hjälp av
andra medarbetare och konsulter då, som beskrev ett upplägg med en förmågekarta som
central i det man jobbade fram. Som hade lite mallar att visa för vilken information man
kan kartlägga i varje förmåga också.
Har du använt dig av förmågor, och i så fall hur?
Ja det är i de analyserna vi gör, kring våra nya projekt eller nya initiativ. Då är det i omfattningsanalyserna oftast då, som vi jobbar med att titta på vilka förmågor som påverkas. Och
det kan också vara då, när vi ska jämföra olika projekt med varandra, omfattningsanalys
eller inte, men just att se påverkan på organisationen, så kan vi använda oss av förmågor
och titta hur affärskraven träffar förmågorna, det är det vanligaste sättet som jag har gjort
i alla fall.
Kan du se några andra användningsområden för förmågor?
Ja, det är ju egentligen i alla fall där man behöver ha en översikt av var man är och
driver sitt arbete. Man kan jämföra olika avdelningar, om det finns andra som har samma
förmågor, eller liknande förmågor. Då kan man se om man skulle kunna hjälpa varandra
att utföra förmågan på ett bättre sätt. Eller om man kanske kan skrota förmågan på det
ena stället och få till en effektivisering på det sättet då, och tjäna tid och resurser. Det kan
ju vara i allt förändringsarbete egentligen, eller förbättringsarbete, att man börjar att titta
på vilka förmågor man har, vilka man kanske skulle behöva. Det kan vara ett annat sätta
att tänka. Och vad som saknas då, eller vad som är gap inom den nya förmåga som man
önskar. Eller även om det är en befintlig förmåga som man har, kan det vara ett gap mellan
nuläge och börläge, då kan det vara ett sätt att börja.
Vilka element vill du koppla till en förmåga?
Det känns som att det kan variera beroende på olika situationer, i och för sig. Men hur
vi jobbar inom förmågan och vilka processer som finns där, är ju en del i alla fall. Och om
det är inputs/outputs eventuellt också, till förmågan. Vilka informationsobjekt som finns
inom förmågan, kan hjälpa till. Kanske även vilka IT-system som finns där. Det här är väl
det som ligger närmast mitt jobb då, såna här delar som jag rapar upp nu då.
57
Fem attribut från litteraturen, vilka är relevanta?
Ja, men krav är ju ett sätt som vi jobbar idag faktiskt, att lägga in, eller koppla till förmågor,
affärskrav oftast, är det som är just i våran roll då. Nu får vi nästan ta en i taget där.
Absolut. Resurs?
Resurser. Ja precis, det kan ju vara om man jämför hur förmågan utförs då inom organisationen, om den finns på flera ställen exempelvis, och titta på hur många resurser som
jobbar med den. Att kunna jämföra då i nästa steg, hur jobbar de med den, och varför
behövs det fler resurser på ett ställe än ett annat ställe. Finns det delar i vad den här
resursen utför som man kan samordna eller inte.
Roller?
Roller, ja. Det kanske var lite det jag touchade här precis nyss då, det kan vara flera
olika roller som jobbar inom förmågan, och de kan ligga nära varandra eller långt ifrån
varandra, de kan utföra samma saker eller lite olika saker. Och det kan ju vara ett sätt
att strukturera upp också, så att det blir ännu tydligare hur förmågan skiljer sig på olika
organisatoriska delar i företaget.
Service?
Tjänst. Är det tjänst på nåt speciellt sätt du tänker, tjänst på vår websida, på det sättet,
eller mer en tjänst som en process.
Mer åt, inte så mycket websidan, utan snarare process..
Nånting vi utför för kunden, en sån tjänst?
Precis.
Ja, hur gör vi där då. Nu ska vi se. Ja, i ett projekt så har vi ju relaterat våra nya
tjänster till förmågor faktiskt. Det är i Digitala Affärer, har vi gjort. Sen har vi kanske inte
sett effekterna av att jobba med det än, om man säger så, att vi har fått ut så mycket av
det. Men vi har gjort den kartläggningen i alla fall.
Händelser?
Händelser, ja, då går ju mina tankar till våra CRM-projekt då, och CRM-verksamhet.
Där har vi ju, det bygger vi helt enkelt mycket på dialoger med kunden när det händer en
viss, när en viss händelse inträffar för respektive kund så söker vi ju kontakt för att se om
de har behov då, efter att den här händelsen har inträffat. Om de har fått barn, eller om de
är på väg att få barn, om de vill ha en gravidförsäkring exempelvis. Då är det en händelse.
Och, ja, den skulle man behöva fundera lite mer på.
Varför tycker du dessa element är relevanta att koppla ihop med förmågor, och i vilka situationer vill du använda det?
Alltså, det är svårt att säga att det är klockrent i samtliga fall här och nu, men man
kan se att det finns möjligheter, och att vissa delar utav dem jobbar vi med, och vissa inte
lika mycket. Men om man ska, så att säga, sortera upp våran verksamhet och allt vi gör, så
58
är det väl ändå förmågor där vi har kommit ganska långt nu, det är därför jag ser att man
kan bygga vidare på det. Och även då sortera upp olika tjänster exempelvis. Det känns
som en vettig approach för att komma vidare med kartläggningar som vi, som man har en
chans att komma i mål med också för hela företaget. För det blir ganska stora arbeten och
börja med en ny approach då tar troligtvis längre tid än att jobba med förmågor som vi har
kommit en bit med. Och det känns lite enklare än att jobba med processer, i många nivåer.
Förmågor säger ganska mycket på typ, nivå 3, då har man kommit ganska långt.
Tror du att elementen till störtsta del blir påverkade av förmågan, eller påverkar förmågan?
Hur menar du nu?
Om det sker förändringar, är det elementen som påverkar förmågan, eller tvärtom?
Aha. Hmm. Ja, det var en bra fråga faktiskt. Jag funderar på vad man skulle kunna
ta för exempel där. Om kraven förändras inom en förmåga, i en förändring, då kommer de
att driva förändringen på förmågan, i det fallet i alla fall.
Finns det något du kan tänka som skulle kunna gå åt andra hållet?
Hmm. Det som händer utifrån det är ju hur vi, vilka regelkrav vi har på oss, eller vilka
lagar vi har. Det betyder att vi måste utveckla våran förmåga för att kunna ta hand om
nya lagar, om det är så man tänker här, jag vet inte. Och likaså nya omvärldstrender då,
det driver ju krav på nya erbjudanden då exempelvis, och förbättrade erbjudanden. De
förmågorna som har att göra med att hantera erbjudanden och utveckla erbjudanden. Jag
vet inte om det var ett exakt svar.
Respondent 4
Bakgrund:
Bakgrund på Folksam, jag har varit här i två år, jobbar som Risk Manager, främst med operativa risker, eller verksamhetsrisker, begreppet har lite olika benämningar. På det sättet
som jag kom i kontakt med förmågor, eller arkitektur, det var egentligen på grund utav
att i min roll så behöver vi kartlägga, vi har ett behov av att beskriva en verksamhet och
kartlägga den på nåt sätt. För att kunna titta på var nån stans i verksamheten finns det
risker, och var finns det kontroller. Så det var utgångspunkten till förmågan.
Kortfattat: vad vet du om förmågor?
I början, inte så mycket. Jag var mer bekant med processer. Men jag kan inte säga att
jag har liksom läst processteori. Och jag har jobbat med processkartläggning liksom, på en
väldigt oteoretisk nivå. När vi började med förmågorna så blev det ju liksom mer teoretiserat, vilket var bra. Och även den här bakgrunden till processer, att den kommer från
processindustrin, så förmågor är liksom nästa steg, kan man säga, i mer i , hur det fungerar
i tjänsteföretag. Det är lättare att jobba med förmågor på det sättet. När vi började jobba
med det här så, grundförklaringen var att förmågor är, ja, men ”Vad gör man”, medans
processer är ”Hur gör man det”, vilket var ganska lättsmält förklaring. Vi har försökt, sen
har man liksom lärt sig mer, och förstått mer om förmågorna, vilket var väldigt kul. Att
förstå hur man ska se på dem, hur de avgränsar sig och förhåller sig till processer och var
processer kan jacka in nånstans.
Hur länge har ni jobbat med förmågor?
59
Sen två år tillbaks, precis när jag började egentligen. För jag hade, som en huvuduppgift
var att börja processkartlägga verksamheten. Och i Folksam är ju det, det har ju gjorts 100
gånger, kan man säga, på lika många nivåer, med lika många syften, ungefär. Och då, så
att börja, att ha utgångspunkten nu, i alla fall hos oss, så var, förmågorna kom in som ett
arkitekturstöd, för att kunna bygga upp ett repository kring det här. Och då vill ju vi vara
med, för att vi ställer krav på att vi ska ha, vi vill gärna få in någon form utav notation
för kontroll och risk. Så att man snabbt kunde få med det i repositoryt. Sen har inte det
riktigt blivit så vad jag vet, sen har det liksom spritts där. Eller det har blivit lite olika, jag
vet inte om det finns nån notation för det nu, jag vet att man i vissa projekt har byggt in
kontroller, men då har man kallat det nåt annat istället för kontroll. Det sprids ju direkt,
beroende på orsakerna. Nämen, och det som var intressant med förmågorna var just det
att, att få den här bilden och beskrivning utav värksamheten för att kunna förändra på ett
mer effektivt sätt. Det är det, det har vi också ett intresse utav.
Hur kom du i kontakt med förmågor?
Kontakten kom liksom tack vare att jag träffade Charlotte, eller koncernarkitektur. Och
de, då var de i ett ganska tidigt stadie av att anamma förmågor, och börja jobba med dem.
Så det tog en ganska lång stund innan jag förstod vad det var som avsågs och hur det
skulle funka. Och mycket var för att, hur man, att det här med att förmågorna inte var
tydligt beskrivna. Sen hade Charlotte med sig två konsulter som liksom, argumenterade
för förmågor, och det var ju liksom inte rätt läge. Jag behövde inte höra argument för, jag
behövde förstå vad det var, liksom, och varför, istället. Sen pratade de väldigt mycket om
kravställning på förmågorna, och det liksom, nu kanske det blir dumt när du spelar in om
jag ritar här, men det som var det luriga med förmågorna i början, som de liksom direkt
försökte gå in och förklara var att det här är förmågan (cirkel). Det där vet vi (fyller i
20-30%). Sen det här (resten) vet vi inte. Och det liksom, förmågan sätts ju utifrån vad den
har för krav, och vad vi kravställde på. Och det var inte helt lätt att, liksom, förstå. Att
det var nåt som var på nåt sätt odefinierat, och att man skulle definiera upp det. Medans
en process är ju på nåt sätt mer definierad. Så, ja. Det var lite, där i början var det rörigt,
helt enkelt.
Har du använt dig av förmågor, och hur?
Jättemycket. Vi har ju.. I Folksam så, på grund utav hur organisationen ser ut, och en
massa olika orsaker som du får ställa följdfrågor på i så fall, så är det så att, som jag
var inne på, att det finns jättemånga processer, och i en verksamhet så, om man skulle
använda processer för att beskriva verksamheten, så behöver man ha ett processansvar eller
ett ägarskap för processen, ja, processansvar. Och det är svårt eftersom organisationen är
väldigt stuprörslik. Då såg vi fördelen med förmågorna, eftersom förmågorna är liksom inte
kopplade till en, det är ingen som äger förmågan, vilket var väldigt bra. Utan förmågan
finns där den uppstår och där det finns, vad ska man säga, behov utav den. Så det var en
stor fördel som vi såg, för att det gjorde oss, plus att koncernarkitektur jobbade med det,
och om vi hakade på och började prata om det här och jobba med det, så hjälpte vi dem,
och de hjälpte oss å andra sidan. Vi kunde säga att det här finns, det har ett syfte för att
vi ska kunna göra den här förändringsresan enklare. Och vi behövde också ha någonting
som funkade på en ganska hög nivå. Och som var beständigt över tid. Det var viktigt, för
att vi behöver kunna rapportera på det här, framöver. Så ansvarsdelen, beständigt över tid,
lagom hög nivå men ändå begripligt. Man liksom förstår, den säger dem vad man gör, vad
man har för förmåga, sin kapabilitet. Det går att jämföra också med andra om man skulle
vilja det eller får tag i det. Så.. Nu har jag tappat bort frågan..
Vad har du använd förmågorna till?
60
Juste, jaja. Ja, men det var, vi tyckte det var väldigt användbart. Sen så tog koncernarkitektur fram en karta som i det skedet blev någon form utav, man började bygga den utifrån en
processkarta som fanns. Det hade gjorts en stor processkartläggning på ett affärsområde,
och sen, det här måste du kolla med Charlotte, det här är min kvalificerade, subjektiva
uppfattning om hur det är. Att man utgick ifrån det. Man tar nåt som man har, så utgick
man ifrån det, och sen så förmågefisierade man det något. Och så försökte man liksom
bygga upp nånting. Det gjorde att vi landade i en hybrid mellan förmåga och processkarta,
vilket för mitt ändamål var utmärkt. Det passade jättebra. Och det var också, anledningen
till att det passade så bra var att vi tyckte att, ja men nu får vi det här high-fly, på en
övergripande nivå, men vi får samtidigt direkt det som jackar in, det vill säga.. På en viss
nivå, som jag förstått det, i förmågorna, så kommer processer in, man brukar rita det så
här... (se foto) En förmåga kan definieras av en förmåga, och sen kan processer komma in
här, så. Och vad skulle jag säga med det då? Jo men hybridkartan var ju redan, då hade
vi förmågor, och sen var processerna liksom, låg de undertill. Och vi har olika nivåer, i
hybridkartan hade vi nivå 1, 2, och 3. Och egentligen nivå 3 var processer. Och det passade
alldeles utmärkt för våra ändamål. Däremot så var det väldigt många, hybridkartan blev
ganska stor. Det som har hänt nu, som vi har gjort, det är att vi har delat upp den i en,
vi har slagit isär hybridkartan, vi har renodlat den till en mer förmågebaserad karta och en
mer processorienterad karta. Men vi har inte landat i översättningen, för det är det man
skulle vilja ha. Att se vart processerna på nivå 3, vart de jackar in i förmågorna på nivå 2,
blir det väl.
Förutom dessa, kan du se några andra användningsområden för förmågor? För dig, företaget,
projekt?
Ja,alltså, för att det du räknade upp i stort sätt. Jag skulle vilja säga att, vi strukturerade ju våran riskrapport. På riskfunktionen så skriver vi en rapport två gånger per år.
Det är av olika anlendingar så finns det såna krav ställda på oss. Men det är också en del
i stödet till ledningen, i att styra verksamheten. Så vi genererar de här rapporterna, och
rapporterna strukturerade vi utifrån förmågorna, på nivå 1 då, som fanns. För vi tyckte
att, men det är ju så bra att kunna lägga det på den nivån, för då ser man, det här är våra
kapabiliteter, det här är våra förmågor. Vad är det som det finns nånstans att vi riskerar att
inte kunna genomföra det här på ett bra sätt, eller vart brister vi i våra förmågor. För där
bör man ju rätta till det, om det är en viktig förmåga. Och då skulle man också, nackdelen
med det då, det är att, eller fördelen beroende på hur man ser det, man har ju ingen som
är superansvarig, å andra sida så är alla lite ansvariga för det här. Så man skulle kunna
peka på flera, och oftast är det så, att det är inte bara en som kan rätta till nånting, utan
man behöver samarbeta för att få det att funka. Det är oftast det som är grundorsaken till
att nåt går snett, det är att man samarbetar inte inom förmågan. Så det var det ena. Sen
det andra är ju också att se vart behöver, vart driver vi förändring, och vart finns det risker
inom det förändringsarbetet. Ja. Jag tror jag stannar där.
Vilka element skulle du tycka var intressant att koppla ihop med en förmåga?
För mig då, om jag får helt.. Risker, kontroller, information, system. Sen kan man ju
mäta det här på olika sätt, det vore också spännande. Men då är vi inne på KPI, som är
Key Performance Indicator. Kostnader, men det kanske landar inom KPIer. Naturligtvis,
den är ju självklar, processer. Processer, system. Ja, det skulle väl vara också människor,
eller resurser. Resurser som människor, eller personer. Men jag vet inte riktigt hur, för de
kan ju liksom, nej. Ja, nånting sånt där.
Vilka av dessa fem element tycker du är relevanta eller inte? Krav, resurs, roll, service,
61
händelse.
Kraven var jag ju inne på tidigare, resurser också. Service, vad kan det vara? Alltså
vilken service förmågan, framgår inte det av själva förmågan? Nej, kanske inte. Det beror
på, naturligtvis, hur man har beskrivit förmågan. Men som förmågan att hantera betalning
eller, vi har ju en, det kan ju vara.. Då är det ju på nåt sätt, servicen är att vi betalar ut
pengar, ja.. Okej, jag ska försöka svara på din fråga. Krav, resurser, ja, de skulle jag hålla
med om.
Roll, service, och händelse?
Roll. Vad menar man med roll?
Att man kopplar ihop det med en position kanske snarare än en specifik person.
Aha. Det har vi varit inne på också. Men vad skulle det säga? Vad ger det oss i, jo
vi ser vilka personer som har, om nån slutar. Ja, precis, det skulle kunna vara en.. Roll,
krav, resurs.
Roller och resurser blir ju lite lika, men resurser kan ju vara annat än personer.
Ja, men precis, det var ju det som var, det är den där definitionen. För jag menar resurser
kan ju vara system eller information..
Ja, precis. så resurser kanske fås med automatiskt om man tar med det andra du skrivit upp.
Ja, det beror på hur man definierar det. Men service funderar jag på, hur det kommer
in. Är det som output av förmågan, eller input till förmågan, eller?
Snarare en output.
Av förmågan? Vilken service förmågan levererar. Typ så?
Ja.
Ja. Nej, jag såg nog det som, vänta. Vad är skillnaden då? Vi har en förmåga, vad är
kapabilitet och service? Vi har en förmåga att kunna levererar nånting, eller göra nånting.
Jag tyckte de var, begreppen blir liksom ganska..
Begreppen hänger ihop ändå?
Typ. Det beror lite på. Ja men som förmågan att göra rapporter, jag tror vi har en
sån förmåga, förmågan att rapportera. Vad är servicen, jo det är en rapport, eller..
Så det blir svårt att särskilja?
Ja, precis. Det ligger ju på nåt sätt i, kan man tänka nåt som är vår förmåga att göra
nånting annat, som inte leder till nån service? Alltså, förmåga.. Kan man komma på nåt?
Förmåga att drifta system? Det är en service att... Nja, jag tycker de är närliggande.
Sen har vi händelser också.
Händelse. Det skulle ju vara risk, för så brukar vi benämna det. Och händelser, då kan det
62
vara en positiv händelse, men det kan också vara, oftast, en negativ händelse som man vill..
Varför vill du koppla ihop just de här elementen med förmågor, och i vilka situationer skulle
det vara användbart?
Egentligen i.. Okej, om jag börjar med varje attribut då. Ettan, risk. Som jag sa, i
förändringsarbete, eller i, framför allt en kartläggning utav organisationen. För att se vart
nånstans har vi risker. Och för att ha en risk, måste man ha ett mål, det är liksom det första,
om man går in på riskteori. Har vi inget mål med nånting, ja, men då har vi ju inga risker.
Och det kan ju ge sig lite utav förmågan. Om vi har en förmåga som säger, vi ska leverera,
vi ska göra utbetalningar. Då kan man ju tänka sig att målet är att utbetalningarna ska
komma till rätt person, vid rätt tid, och rätt belopp. För annars så känns det som att vi
inte levererar. Då har vi förmågan att göra felutbetalningar i såna fall. Men det ligger i
korten på nåt sätt, att målet är att det ska bli rätt, det är ett kvalitetskrav då, eller ett
kvalitetsmål. Men där kan vi ju se om vi har, där är det ju relevant med risk, för då skulle
vi kunna titta på, okej, har vi några risker kopplade till den här förmågan? Ja, till exempel
att vi inte betalar ut i rätt tid, till rätt kund, med rätt belopp. Okej, hur bra är vi på att
hantera det här, eller finns der några kontroller, vilket kommer in till nästa. Och då kan
man kartlägga, ja men vi säkerställer den här förmågan, genom de här kontrollerna, och de
finns här och här i verksamheten. Eller inom den här förmågan då, förmågan hanteras utav,
då kommer vi in på, i de här processerna, med de här rollerna eller resurserna, med de här
systemen, nu namnger jag de här olika attributen, och med den här informationen. Och det
kan ju finnas risker i alla de här olika attributen också, det kan ju vara systemen som är en
orsak till att vi inte klarar av det. Det kan ju vara processen som sådan som haltar, eller att
vi inte har rätt roller eller att kraven inte finns tydliggjorda på vad som faktiskt ska levereras. Så att i själva riskdelen så kommer väldigt många av de här attributen in. Följdfrågor?
Nej, det känns ganska heltäckande.
Är det nån som jag missade? KPIer? Det beror ju på, det är ju mer om man styr, om
du har ett, om du väljer att koppla ihop.. KPIer är också kopplade till kanske mål, i alla fall
teoretiskt, så sätter man mål för verksamheten som man bryter ner, och gör om till mätbara
mål. Vi ska ha de nöjdaste kunderna. Okej, men vad är en nöjd kund? Hur mäter vi det?
Hur vet vi att vi når målet? Ja, då säger vi att nöjd kund är när 95% av våra kunder i en
kundundersökning säger att de är väldigt nöjda på en skala 1-5, och då vill vi ha 90% över
4, och sen ett visst antal 5or. Då har vi en KPI, då mäter vi det, och då kan vi säga att
vi har en god förmåga att, den kanske slår på flera förmågor, men det kanske finns saker
som man kan bryta ner utifrån målsättningar kopplade till förmågor, som landar nånstans,
till exempel. Det skulle kunna vara betalning, det skulle kunna vara svarstid i telefon, det
skulle kunna vara antal annullationer eller så. Det finns en massa KPIer att bryta ner.
De olika elementen, påverkar de förmågan eller blir de påverkade?
Ställ frågan en gång till.
De här elementen, påverkar de förmågan, eller är det snarare så att de blir påverkade av
förmågan?
Förmågan är ju ingenting i sig. Förmågan består ju av de olika attributen, hur de samverkar.
Så jag skulle vilja säga, förmågan påverkar, nu ska vi se här. Jag tänker högt nu. Om vi tar
förmågan betalningar, att göra betalningar. Om vi säger att vi ska ha det som en förmåga,
då får vi ju indirekt ett mål, att vi ska göra det med nån form utav kvalitet, eller enligt
nån form utav krav. Har vi inga krav på betalningar, då har vi inga, då kan vi göra vad vi
63
vill. Har vi inga krav på förmågan, är det ens en förmåga då, om vi inte har några krav på
den? Då kommer vi in på den här definitionen, vad är en förmåga? Då måste vi på nåt sätt
definiera upp. Jag skulle vilja säga att det är de här komponenterna, elementen, som bygger
upp förmågan. Och vissa har vi ju definierat, ställt krav på, som vi känner till. Ja, jag skulle
nog vilja se det så här, att det är snarare tårtbiten här ( 20-30% kända) som påverkar resten
(okända), så här, som kommer in som en pil och påverkar den här förmågan, än att den där
(okända) påverkar pilen. Det här uppstår ju, enligt min, nu har ju jag inte läst nån teori om
det här, men enligt min uppfattning, så, saker här ute kan ju uppstå i olika interaktioner
med de här olika elementen som vi har sagt. Det är vissa roller som, tillsammans med andra
resurser, och en specifik information, som gör att vi kan leverera en delmängd av den här
förmågan till en specifik intressent, eller nånting sånt. Ja, men nu när jag liksom pratar om
det och försöker beskriva det så tror jag nog mer att det är så, än att det är förmågan som
påverkar de olika elementen. Jag väljer nog att se det så. Och det hänger nog ihop med
också, med den här definitionen. Att vi har processer som jackar in i förmågan, det kan
ju hända grejer i processen som påverkar den här. Förmågan i sig sätter ju bara ramarna
för vad vi ska göra, på något sätt. Den påverkar.. Ja den sätter nog mer ramarna. Skulle
vi ha en förmåga som är, vi ska ha en förmåga att göra dåliga utbetalningar, vi ska ha en
oförmåga, ja, en bristande förmåga att göra betalningar, då hade det kanske påverkat. Då
behöver vi inte ha så mycket system, vi behöver ändå inte göra nån utbetalning i rätt tid,
alltså vi kan göra den när nån kommer hit och skriker liksom. Ja, så kanske ramarna. Jo,
men det blir väl bra! Titta, det här (ramarna) påverkar den där (kända?) delen utav tårtan,
på nåt sätt. Ja.
Respondent 5
Bakgrund:
Jag har väl titeln Risk Manager, och jobbar inom Risk- och Compliance-avdelningen på
Folksam Sak. Jag har jobbat på Folksam i ganska precis två år.
Kortfattat: vad vet du om förmågor?
Ja, innan jag började här så hade jag ju aldrig, inte medvetet i alla fall, kommit i kontakt med begreppet förmågor, utan mer med processer. Och att, intresset här var ju för att
det finns ju ingen överenskommen processkarta på Folksam, och när vi då på Risk skriver
riskrapporter så behövde vi hitta nåt slags struktur. Man kan strukturera risker på många
olika sätt. Och man kan ju, till exempel, jobba på tvärsen och klumpa ihop dem över hela
verksamheten, men då blir det ju inte så intressant att veta var riskerna finns. Utan då
behövde vi hitta nånting som gjorde att man kunde, liksom, mappa ihop olika risker i verksamheten mot övergripande risker. Och då fanns den här förmågekartan som vi, jag vet inte
hur vi stötte på den egentligen. Jo, vi var intresserade av att rita processer, så därför tog vi
kontakt med Koncernarkitektur, och lärde oss EA, jag och min kollega Marcus som du har
intervjuat då. Och sen kom vi väl på att, jo men vi kanske skulle, bara så där, häpp, liksom,
att vi kanske kan strukturera riskrapporten utifrån förmågorna. Och då gjorde vi det! För,
vad kan det vara, förra hösten måste det vara, nästan. Så vi har skrivit två rapporter enligt
den strukturen, vi skriver två gånger om året. Precis, vi skriver en ny nu i höst ja. Och,
ja, men sen visade det sig ju då att den här förmågekartan som man hade tagit fram på
Folksam, den var ju inte helt korrekt, utan den var ju lite en mix då mellan processer och
förmågor. Men jag ser ju forfarande att förmågorna är intressanta ur ett riskperspektiv,
därför att man kan ju skära risker på olika sätt. Jag vet inte hur väl du vet hur man jobbar
med risk, men det blir ju som en matris, alltså förmågorna kontra processerna. Om vi till
exempel säger att vi har stora risker i en utbetalningsprocess inom en specifik del av verksamheten. Då är det ju mest intressant för verksamheten att veta att det finns stora risker
i den här hanteringen, alltså i den här processen. Att administrera pensioner, till exempel.
64
De är ju inte så intresserade av att veta att det är förmågan Utbetala som har brister,
eftersom processerna oftare följer det organisatoriska ansvaret så är det lättare att använda
processerna i relationen med ledningen. Men samtidigt då om man tittar på risker på en
annan ledd, om man tänker då IT-utveckling, på samma sätt som Koncernarkitektur jobbar,
så är det ju intressant att kunna lägga ihop och titta just ”Oj, men vi har jättemycket risker
just kopplade till utbetalningar”. Och det är ju viktigt för där hanterar man ju, alltå, går
det fel i utbetalningarna så är det ju värre än om det kanske går fel i den här processen. Så
båda dimensionerna är intressanta för oss. Men vi som jobbar på Risk kommer nog alltid
att vara mer intresserade av processer, egentligen. Så är det.
Hur länge har ni jobbat med förmågor?
Ja, det var ju då sen, ja men nästan sen jag började så började vi nog nosa lite på det.
Men att vi började ju att beskriva riskerna, fast då blir det ju lite fel att säga att vi gjorde
det enligt förmågor, för egentligen har vi ju gjort det enligt processer, eftersom kartan är
mixad. Ja, hybridkartan, så.
Men ungefär två år?
Eller, ja, ett och ett halvt då kanske.
Hur kom du i kontakt med konceptet förmågor? Det har vi ju redan diskuterat lite.
Via Koncernarkitektur, ja. Vi ville rita processer, och så fick vi reda på att de fanns.
För här hade man ju diskuterat hur Folksams processkarta såg ut framåt och bakåt och
aldrig kom till nånting, och här fanns det ju liksom en färdig karta som man bara kunde
säga att ”Ja, men nu använder vi den här!”. Så det var ju bra.
Har du använt dig av förmågor vid något annat tillfälle än riskrapporterna?
Nej, vi har inte använt det på nåt annat sätt. Jag vet inte, om det här hade varit helt
rätt från början, så vet jag inte hur vi hade använt det då, men nu var det ju inte riktigt
rätt uppställt. Men det är nyttigt att skära verksamheten på olika ledder, så på så sätt
tillför det nåt.
Kan du se några andra användningsområden för förmågorna?
Ja, men i förändringsarbete ser jag det framför allt. Och samtidigt måste man ju kunna
beskriva verksamheten både i ett nuläge och i ett.. ett nuläge, ett målläge, och ett förändringsläge
utifrån nån viss typ av struktur. Och där fyller det ju ett syfte. På samma sätt som man
kan beskriva processerna, men det har ju lite olika syften. Så jag ser nog att, om man tänker
ur ett organisatoriskt perspektiv, alltså som chef, så tror jag att man lättare förstår processer. Men när man tittar på verksamheten som en helhet, så kan det ju vara mer effektivt
att använda förmågorna, tror jag. Och särskilt när det gäller IT-utveckling eller förändring
över huvud taget. För det blir ju lättare suboptimering om man bara tittar i processerna, så.
Finns det några särskilda element eller särskild information du skulle vilja kunna koppla
ihop med förmågor? Till exempel just processer?
Ja, för oss så känns det relevant.
Finns det något annat än processer?
65
Jag har nog inte tänkt så långt. Det har varit tillräckligt besvärligt att koppla ihop det
med processerna. Ja, men IT-stöd givetvis, alltså, ja. Om man tänker personalförlyttning,
alltså allting som har att göra med att man förändrar nånting som är en typ av gemensam
massa, så kan man ju applicera.. Ja, men du ska förflytta din personal, då kan det ju vara
intressant att tänka ur ett förmågeperspektiv också.
Här är fem element, från min litteraturstudie, som du får ta ställning till om de är relevanta eller inte. Krav, resurser, roller, service, händelse.
Om man kan koppla det till förmågor?
Ja, om du tycker att något spontant känns relevent eller inte.
Krav känns väl viktigt. Alltså om man ska kravställa, nu är vi inne på förändring igen.
Och resurser är ju lite samma sak. Du använder ju olika typer av resurser i olika förmågor.
Man kan ju effektivisera genom att tänka förmåga, tror jag. Det ska man ju inte säga till de
som är processnördar, att man kan effektivisera genom att skära det på andra ledden, det
beror lite på hur man vill effektivisera. Kund-effektivitet uppnår man väl kanske inte med
förmågor, men man kan internt effektivisera. Vad sa du mer?
Roller, service, händelse?
Roller? Krav och personal, eller resurser, kändes ju mest rätt. Klart man kan koppla roller,
alltså, man kan koppla allt till en förmåga. Men roller, händelser, och vad sa du nu den sista?
Service.
Service. Ja, men servicen känns ju lite mer som det här med krav och så, alltså om man nu
vill tänka utifrån ett kundperspektiv, kanske att service händer med. Men de andra två är
väl, tror jag hellre jag skulle koppla till en.. Nej, ja.. Men det är klart, om man tittar på
Utbetalning, ja men då har du ju olika roller. Och då kanske det är viktigt, då kan man ju
liksom koppla, inom Utbetalning har man de här rollerna och de bör liksom vara likadant
i alla, i all Utbetalning. Och tittar man på processen så kanske man tänker roller på ett
annat sätt. Det var ingenting som jag kände så här ”Nej, det går inte”.
De olika elementen, i vilka situationer skulle det vara användbart, och varför just dessa
attribut? Men det har vi nog redan tagit.
Ja, precis, det tror jag nog.
Kommer elementen att påverka förmågan, eller tvärtom?
Förmågan är väl en beskrivning, så den borde väl inte.. Ja, men krav borde ju påverka
förmågan. Ja, det var nog lite för abstrakt för mig känner jag. Det beror nog på hur man..
Är inte en förmåga en beskrivning av nånting? Och då menar du att då skulle beskrivningen
påverka? Ja, det kanske den kan, jag vet inte.
Så det känns naturligare att resten påverkar förmågan, som krav till exempel?
Ja, det gör det nog.
66
Respondent 6
Bakgrund:
På Folksam har jag jobbat i, det bli 14 år nu. Time flies when you have fun. Och jobbat med just affärsarkitektur har jag gjort sedan 2010. Och det blir väl senaste 2 och ett
halvt åren har jag suttit på affärssidan, innan dess satt jag på ITstabs-nivå, med Charlotte
och gänget.
Så Affärsarkitekt?
Ja. Eller, min titel på Affären är Affärsutvecklare, men jag är certifierad affärsarkitekt.
Kortfattat: vad vet du om förmågor?
Ja, det är ju så man ringar in vad ett företag gör, vad man har för göromål, för att leverera
det man ska. Vi har ju jobbat mycket med processer just inom Partneraffären som jag sitter
på då. Vi började där, till att sen utveckla det till ett förmågetänk, under ett program vi
körde, under resans gång. Och kom en bit med det, för att processer säger inte allt, utan
man fångar mer saker som påverkar utifrån ett förmågeperspektiv. Men processerna finns
ju där i förstås.
Hur länge har du jobbat med förmågor?
Ja, det var, jag och Charlotte satt ju och jobbade med det här. Det var 2012-2013, satt vi
och började.
Hur kom ni i kontakt med konceptet förmågor?
Det var Charlotte som introducerade det tänket lite mer. Jag hade väl hört det, lite så
där, men inte tagit reda på riktigt mer om det så. Just då var väl det i ropet lite det här
med industrimodeller, som i och för sig är en typ av förmågor, och IBMs industrimodell som
sen visade sig inte funka i verkligheten. Det var lite roligt, jag träffade en enterprisearkitekt
hos en av våra konkurrenter, som var eld och lågor över IBMs modell. Och sen så stötte
jag på honom vid nåt seminarie om det var två år senare och frågade 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, så. Det var lite spännande att höra.
Har du använt dig av förmågor, och på vilket sätt?
Ja, vi använder det när vi ska göra stora satsningar. Främst stora satsningar, man kan
göra det även på mindre men det är mest användbart när man ska göra stora satsningar,
för att ringa in vad är det som påverkas av det här initiativet ni nu ska genomföra. Vi vill
ta oss från plats A till plats B, hur påverkar det vad vi gör idag? Så det är ju ett väldigt
bra sätt att ringa in vad som påverkas. Vi har en stor och komplex verksamhet. Gammal,
över 100 år. Så att, många saker gör vi, och vi försöker att få en karta över, men vad är det
vi egentligen gör i vår komplexa verksamhet. På bästa sätt ringa in, man hittar ju aldrig
allt, så är det ju, men man har större chans att hitta rätt om man åtminstone har ringat in
på förmågenivå vad det är som berörs.
Förutom detta, kan du se några andra användningsområden för förmågor?
Ja, för dels är det ju att ringa in vad är det som berörs. Sen behöver man ju också göra
en bedömning ”Hur svårt är det här?”, vad är det för komplexitet inbyggd i det här. För
67
sen använder man ju det för att göra en roadmap över vilka steg bör vi ta, hur svårt är de
olika stegen. Och sen kan ju det också vara en grund till prioritering, jämfört då med vilka
effekter man tror att man uppnår. Är det nånting som är extremt svårt att göra, men som
bara bidrar till en pyttedel av effekten, ja men då får man kanske tänka om. Så det är ju
en bra utgångspunkt för prioritering i vart man ska lägga sitt krut i förändringen.
Vilka element skulle du vilja kunna koppla ihop med en förmåga?
Eftersom jag är affärsarkitekt så tittar jag ju på hela affärsarkitekturen. Det vill säga
då, vi har ju liksom en övergripande strategi och inriktning. Affärsmodeller, som du då vill
förändra också. Och sen utifrån det då så ser man ju då på processer och förmågor, förmåga
är väl då liksom en inringning av många saker, men dels processer. Hur påverkar det vad
vi gör i en verksamhet? Och sen så spiller ju det också över på hur styr du arbetet som
utförs, vilka kompetenser behövs, vilket typ av IT-stöd behövs? Och då kommer du ner på
information och tekninska plattformar och allt sånt.
Fem element från litteraturen, känns de relevanta eller inte? Krav, resurs, roll service,
händelse.
Ja, det beror på vilken fas man är i, i förändrningen. Vi skär det nog inte riktigt på
den ledden, i det tänk vi har, är liksom min spontana känsla. Men nu har ju jag inte liksom
pluggat in hur vi har skivat upp våra förmågor just nu. Jag var bara med i början, då hade
vi behöv av att ringa in ”Vad är det som berörs?”. Och då tittade vi på vad är det för typ
av information, och kopplat till vilka processer görs det här med hälp av. Och vilken typ av
roller. Jag kommer inte ihåg om vi kom så långt att vi kopplade på organisation eller inte.
Så att, liksom, ja, det går väl att översätta, kan jag tänka.
Men det är ingen av dem som spontant känns relevant?
Ja men det gör de nog, fast vi har kallat det för annat, om man säger så.
Är det några då som verkade relevantare än andra, eller tvärtom?
Jag tror nog att vi ser det, det där är väldigt, om vi nu uttrycker oss i IT-språk, så är
det där IT-språk. Vi uttrycker kanske motsvarande fast på ett annat språk, om vi så
säger. För det där blir lite, om man tänker sig att man ska ha en dialog med en affärssida,
eller en verksamhetssida, då stänger man av ”Aja, men det där är sånt där tekninskt som
hör till IT”, det är en rätt viktig aspekt, om man ska få det här att funka hela vägen.
Eller om man vill ha det IT-internt, eller arkitektur-internt, alltså, ursäkta uttrycket, men
på ”nördarkitekturnivå”, så funkar det där bra. Men behöver man ha en dialog med en
affärssida och affärschefer och alla möjliga typer av roller så kanske man ska fundera på,
men, de där begreppen stämmer, om man tänker sig rent generelt, men man kan nog få
svårt att få med sig alla roller i en verksamhet, genom att använda just de begreppen. Det
är min personliga erfarenhet. Men alla är ju relevanta, förstås.
De här elementen, i vilka situationer skulle det vara användbart att koppla ihop dem med
förmågan, och varför just de elementen?
Det är egentligen om man tittar på affärsutvecklingsprocessen. När man har ideer, eller
man ser att man behöver göra en förflyttning. Det är det här, om du tänker dig en projektmetodik, för att komma fram till en BP1a, faktiskt, och ringa in vad är det vi vill, och
varför, och vad innebär det här då. Innan man kör liksom, go, nu kör vi ett eller flera projekt. Så det är ju egentligen affärsarkitekturprocessen där man då går igenom de här stegen
68
och fyller på med den här informationen, på en lagom övergripande nivå förstås. Annars
kommer man ju in i verksamhetsanalysen och det är ju inte meningen. Utan liksom, för att
ha ringat in, men ”Det är det här vi ska göra framöver, för att..”, och gärna kopplat då till
relevanta afffärshändelser som man då kan checka av mot. Det är affärshändelser som styr.
Elementen, påverkar de förmågan, eller tvärtom?
Jamen, förmågan beskriver ju den verklighet man lever i. I och för sig, där kan man säkert
också göra as-is och to-be. Men om du har koll på as-is, så kan du ju när du vill göra en
förflyttning från punkt A till punkt B, så tittar du ner, i sin låda av förmågor, ja, men ”Så
här ser den ut”. Då kan det ju vara mer eller mindre svårt. Det är ju det man får fram då.
Och sen så är det ju så, antingen är det så att den här förmågan, ja, den kan vara så att,
otur, det är jättesvårt att ändra på den av nån anledning, nu vet ju inte jag vad det kan
vara, men, det kan ju finnas sånt. Eller att den, det är så många andra saker som strålar
ner i samma förmåga så man kan inte ändra på den ur ett perspektiv, för då liksom rasslar
det till och förstör i massa andra hörn, nån annan stans, som gör att man inte kan förändra
för mycket. Ja, då blir ju det en aspekt att ta hänsyn till. Eller så är det så att man tittar
ner då och ser att den här förmågan är för dålig, vi måste förändra den. För det gagnar inte
bara den här initiativet eller den här affärshändelsen, som vi är ute på marknaden med, då
kan man ju förändra förmågan i sig. Så det beror ju alldeles på. Så det finns inget rakt svar
på den, nej.
Något annat du känner är relevant att lyfta fram?
Nej men det är just det här att i affärsutvecklingsprocessen, inför att man behöver sätta
igång ett initiativ, ett eller flera projekt som det kan vara då, så använder vi oss av det för
att göra komplexitetsbedömningar och omfattningsanalyser och så. Som är liksom, för att
kunna ta fram en roadmap, som projektet ska kunna basera sitt arbete på.
Respondent 7
Bakgrund:
Jag är verksamhetsarkitekt. Jag började på Folksam september 2013, tror jag. Jag har
jobbat här ett och ett halvt år, kanske det blir. Så att, och innan dess hade jag samma
position i typ 6 år också, så att jag har jobbat ganska länge som verksamhetsarkitekt.
Kortfattat: vad vet du om förmågor?
Ja, vad ska jag säga. Det är ett omdebatterat ämne inom arkitektur. Jag har jobbat
mycket med olika typer av förmågor, även innan jag jobbade som verksamhetsarkitekt har
jag jobbat med krav och kartläggningar av olika slag, jag har jobbat med upphandlingar och
använt mig av förmågor ganska många gånger. Så det är egentligen samla in kravställning,
identifiera olika hanteringar i ett företag. Jag vet inte riktigt hur mycket, jag kan berätta
en hel dag om de där olika kapabiliteter hit och dit, finns olika former.
Hur länge har du jobbat med förmågor?
Oj. Ja, måste tänka, det var kanske 2000, när jag blev konsult, som det dök upp. Jag
har jobbat ganska mycket med upphandlingar och då är det väldigt praktiskt att jobba
med förmågor. För då, innan man vet hur man vill jobba, och kanske kravställer på vad
man behöver, tjänster och funktionalitet, av externa företag och service providers. Jag tror
faktiskt att det är så länge, det låter väldigt..
69
2000?
Ja, då blev jag konsult, så det var väl då man började tänka på såna saker.
Hur kom du i kontakt med konceptet förmågor?
Det är inom, alltså, inom kartläggningar. Ofta så börjar man med nuläget, hur ser det
ut idag, och vad är det vi hanterar idag. Vad behöver vi hantera i morgon för att stötta
affären. Vi har väl, som anställd inom arkitektur som jag har varit då i sju år, ja, det är sju
och ett halvt, åtta år, då blir det ju mer att man förvaltar förmågor och kartläggningar, och
försöker få till någon slags återanvändbarhet i det hela. Så det blir lite mer strukturerad
form som linjeanställd.
Har du använt dig av förmågor, och hur?
Jag har ju redan nämnt några stycken. Ja det är ju massor av sätt, i många olika sammanhang. Men framför allt kartläggningar av verksamheter, kartläggningar av övergripande
affärsarkitektur. Kartläggningar av organisationer, man kan titta på, till exempel, dels hur
organisationsstrukturen ser ut, vad man hanterar inom dem, eller hur ska vi organisera oss
för att vara effektiva. Hur ska vi jobba och hur ser våra processer ut för att vara effektiva.
Och sen kapsla in nån slags övergripande, strategisk, alltså man kartlägger strategiskt ”Hur
påverkar en ny strategi vårt företag?”, och så istället för att gå för djupt ner i processer och
system, ha nån slags övergripande inringning.
Förutom detta, ser du några andra användningsområden?
Alltså på Folksam tycker jag att man använder förmågor ganska brett. Både strategiskt,
och sen verksamhetsanalysmässigt, och så även kravställningsmässigt. Jag tycker att man
kan dra nytta av det i en agil metod bättre. Jag jobbade agilt i sex år och försökte få till
det lite grann, för där möter ju arkitektur agila, de här användarcentrerade metoderna. Och
det är ju, det kan vara lite spännande att se hur det fungerar ihop.
Finns det några element du vill kunna koppla ihop med en förmåga?
Ja, det finns egentligen.. Processer tycker jag är jätterelevant att koppla in, och det har
jag också gjort i verktyg själv. Så vi har sett att det fungerar verkligen. Affärsobjekt,
jättecentralt. Vad kommer in i en förmåga, och saker händer inom förmågan med processer, organisation, och kompetenser, och sen kommer nånting av värde ut i förmågan, det
affärsobjektstänket gillar jag. Sen tycker jag också att det är intressant att koppla ihop
med, vilket man inte alltid gör, den logiska arkitekturen, lösningsarkitekturen. Den, alltså
gå ner mer mot applikation och lyfta applikationsparken på ett logiskt lösningstänk. Och
system, att inte förglömma. Alltså vilka system, x, y, oxh z, alla systemen. Och sen också
organisation. Vilka kompetenser och roller har vi i en förmåga, och var sitter de placerade
i vår organisation.
Fem element från litteraturstudie, relevanta eller inte? Krav, resurs, roll, service, händelse.
Händelse? Hur tänker du då, ett event?
Ja, precis.
Ja. Men jag tror nog att alla är relevanta. Jag har inte kopplat ihop det med service,
vilken service tänker man här? Det finns många olika där också.
70
Vilken service bidrar förmågan till?
Okej, det som ligger inom förmågan, vad är det för service som man kan förvänta sig..
Om vi säger att vi köper det externt, outsource’ar. För tjänster, på Folksam här finns ju
inte tjänster i arkitekturen i den utsträckning som det finns på andra bolag. där jag var tidigare i sex år, där byggde vi ju upp tjänstearkitekturen, och det tycker jag, ja, det var ganska
bra, för då behövde man inte alltid få in det här med process, det kan ju ligga utanför, om
man tänker mer tjänst.
Så alla känns relevanta?
Ja, men jag tycker tjänsterna är inte så, det är också lite infekterat över åren. Men det
är inte så mycket sånt tänk här.
Varför känns dessa element relevanta och i vilka situationer skulle det vara användbart att
koppla dem till förmågor?
Alla?
Eller ta en i taget, om du vill.
Av de du nämnde?
Ja, eller av de du tänkte på också.
Okej. Nej, men det är ju verkligen olika sammanhang. Det vi använder mest här, de
här affärsobjekten, det är ju för att säkerställa själva förmågans hållbarhet, och att det är
rätt abstraktion på den. Så det är ju, när man ringar in förmågor och säger att vi ska ha
förmåga x, y, och z, hur vet vi det? Hur vet vi att det är rätt x, y, och z, och inte t, till
exempel. Så att, för att klä en förmåga med affärsobjekt och sen organisation, alltså hitta
centrala delar som man vill klä sin förmåga med, så man vet vad man pratar om, för annars
är det bara rubriker. Och då når man sällan fram till människor med förmågor, då tycker de
att det är för abstrakt, de kan inte relatera till förmågan. Så jag tror att, för att få folk att
relatera till förmågor så är det väldigt viktigt med just affärsobjekt. Sen också organisation,
tycker jag är viktigt. Men jag vet inte, det är så många olika sammanhang där man kan..
Strategiskt sätt så tror jag att kanaler är också ganska intressant, distributionskanaler. Är
det digitalt, eller är det via kundtjänst, eller vilken, den har vi inte nämnt men den tycker
jag är, också, bra. Räcker det som svar?
Jajaja, absolut. Jag ska skapa en metamodell utifrån intervjuerna och det ni tycker är intressant att koppla till förmågor, som ni sen kommer få ta ställning till, och förhoppningsvis
kunna inkorporera den i EA Sparx också.
Jaja, men då tror jag nog process är ganska viktigt, på en väldigt hög nivå, typ nivå 2
eller nånting sånt. Det skulle vara bra att få en koppling till. Organisation är ju mera,
alltså, föränderligt, eller vad man ska säga, men det kan också vara relevant att titta på
vilken enhet eller affärsområde som florerar i vilken.
Påverkar elementen förmågan, eller tvärt om?
Att de påverkar förmågan.. Förmågan, om man säger, byggs ju upp av alla elementen.
Det är så jag bektraktar förmågan, att det är en container för allt det andra, för att man
71
ska slippa prata om det andra för att det blir så detaljerat. Jag känner så, att den, man
kan ju ha en förmåga och inte använda den alls, men frågan är ju då hur länge man har
den förmågan, i verkligheten. Alltså, det finns ju en verklighet och så finns det en teori
bakom förmågekartläggningar, och ibland blir det ju liksom mer en teoretisk diskussion, vad
som påverkar det ena och det andra. Men för att säkerställa en bättre bild, av att man har
identifierat sin förmåga, liksom, i balans med de andra arkitekturnivåerna, då måste man
nog klä in den lite för att se, den här omfattningen, den är relevant att ringa in en förmåga
på. Så drar man bort nånting och jackar in den andra, ja, då påverkas ju inringningen av
förmågorna, men den är ju bara en abstraktion av den andra. Så egentligen är inte förmågan
nånting utan allt det andra. Är du med vad jag menar?
Jadå, inga problem. Något mer du vill få fram?
Jag tror så här, man kan ha en teoretisk bild, och det är jättebra att beskriva det, för
då kan alla få samma grund. Men sen så när man är i samtal med människor så gäller
det att ändå få grepp om behovet och grunden för samtalet, och huruvida man betraktar
förmågan på samma sätt. Om den samtalspartner man har i ett möte inte har samma grund,
då måste man anpassa sig i sin arkitektroll. Jag tror det är A och O att man är flexibel.
Respondent 8
Bakgrund:
Du, jag har varit, om vi börjar med Folksam, länge. Jag har varit här i 14 år. 15 år
snart. Jag jobbar som Affärsarkitekt, inom ett område som heter AO Privat. Det är ett
utav de tre affärsområdena som finns, jag vet inte hur väl du är bekant med organisationen?
Jo, men det har jag sett.
Bra. Så där sitter jag. Mitt ansvar gäller både AO Privat, och det handlar framför allt
om distribution och vårt erbjudande, eget varumärke, och det handlar även om ansvar för
försäljningsdistributionskanalerna. Det ligger också under där. Så att, så, då har vi ramat
in det. Jag har haft affärsarkitektrollen sen i somras, så snart ett år. Jag har jobbat med
affärsutveckling tidigare, det är bara det att vi har gjort en liten omorganisation, frågorna
är de samma, den är en lite annan roll bara.
Kortfattat: vad vet du om förmågor?
Ja, ja vad vet jag om dem? Hyfsat mycket. Sen finns det väl alltid mer att lära sig,
absolut. Jag har varit med sen vi började arbeta med förmågor i Folksam. Och det vi
gjorde de första trevande försöken, eller trevande, vi tog dem i ett praktiskt fall och använde
dem, vad har vi kört det i, en fyra-fem år, ungefär. Så där satt jag och Charlotte Frank,
som du säkert känner sedan tidigare, tillsammans med en kille som heter Roland Karlström.
Och då använde vi förmågorna när vi jobbade med strategiarbete inom företagsaffär. Så det
är sen dess. Sen, jag har ju.. Det är ju förmågor som vi behöver besitta, eller besitter. Eller
som vi besitter, det är inte alltid man behöver dem, men förmågor vi besitter. Och speglar
väl på nåt sätt vilka kompetenser vi behöver. Stöd i arbetet, det är allt ifrån IT-system till
andra kompetenser också i form av stöd. Processer, också. Nej men det har varit ett bra sätt
att åskådliggöra vad vi faktiskt gör, och det är ett bra sätt att också scopa in frågeställningar.
Hur länge har ni jobbat med förmågor?
Jag tror vi har jobbat i drygt 4 år. Tror jag. Vi gjorde ett jobb, och det gjorde vi runt
årsskiftet, det måste ha varit fyra år sen. Den kan vara tre, men jag tror det är fyra.
72
Hur kom du i kontakt med förmågor?
Det var faktiskt Charlotte som introducerade det. Vi hade gjort, vi gjorde faktiskt ett
visst försök, till och med ett år innan dess. Det stämmer, det var nästan fem år sen. Och
jag tror att vi fick lite input ifrån Sandvik, om inte jag missminner mig helt fel. Annars,
den som driver själva arbetet, så som jag ser det, det är ju Charlotte, absolut.
Har du använt dig av förmågor, och hur?
Absolut. Vi kan väl ta ett praktexempel. Projekt, där vi talar om vilka förmågor som
är inom scope för projektet. Man kan också tydligt tala om vilka som är utanför. Det
är ett sätt. Ett annat sätt som vi använder idag, det är, givet, om vi tittar på de olika
affärernas olika intressen, att dra åt ett eller ett annat håll, åt det vi vill, så kan vi tala om,
på förmågenivå, vilken typ av förflyttning som behövs för att stötta det. Till exempel en
strategi eller en affärsplan. Så att, det är ett bra sätt att på nåt sätt förstå, vilken förmåga
har vi idag, givet vad vi säger, och vad behöver vi förändra. Så är det, det är en bra yta
att dela på, och folk verkar gilla det, det är så. Annars brukar det vara väldigt svårt att få
olika roller att prata med varandra. Så det har varit en bra spelplan. Och, som sagt, bara
man har en spelplan så har vi, liksom, en gemensam syn, och bara det är bra.
Kan du se några andra användningsområden för förmågor?
Absolut. Återigen, precis som ett projekt kan scopa in vad vi ska och inte ska göra så
kan man också tydligt tala om vad en organisation gör. Vi har använt den, och det är
väl inte bara vad jag kan se, men vi har också använt den när vi pratar om ansvar mellan organisationer, vem har egentligen ett ansvar. Då kan man börja på förmågenivå och
mappa in vilka organisatoriska delar som har ett ansvar. Och där kanske fler träffar på
samma förmåga, då börjar man ju undra ”Har vi ett samlat ansvar? Eller är det så att
den där förmågan består av egentligen två delar?” Så att, det har varit en bra yta att även
diskutera ansvar, befogenheter, mandat. Det kan väl användas till allting. Jag vet att man
använder det idag för att mappa ut risker, till exempel. Återigen, har vi valt en spelplan att
beskriva, på en övergripande nivå, den verksamhet vi bedriver, så kan den ju, utifrån den här
verksamhetens alla behov, ganska tydligt användas till allt ifrån liksom, resursplaneringar,
kompetensplanering, du kan göra i stort sätt vad som helst.
Vilka element vill du koppla ihop med förmågorna för att det ska funka som bäst för dessa
användningsområden?
Jag tyckte det var bra när vi på nåt sätt också mappade, mot förmågor, vilken organisatorisk del har ett ansvar. Den blir väldigt organisatoriskt bunden, så det finns ju en
ganska stor fara med det, i och för sig då. Men man kan i varje fall på en övergripande
nivå prata om produkt till exempel, vi kommer ha en produktorganisation på ett eller annat
sätt. Det har den varit bra för, som ett exempel. Andra bitar, ja. Det jag skulle vilja se i
den annars, det är just ”Vilka är det som jobbar här?”, altså, vi pratar roller. Vad besitter
de här rollerna, eller behöver de besitta, för typ av kompetenser. Det är kanske att ta det
lite för långt just nu då, men att förstå rollerna, förstå processen eller processerna som bor i
den förmågan. Och det är väl ungefär det vi jobbar med just nu. Sen kommer det ju ta ett
tag innan det är klart. Sen kan man önska väldigt mycket, men man behöver få ett grepp
om det som behövs idag då. För att återigen, en förmåga givet behovet av förflyttning, så
är det ändå när du kommer ner på processnivå som saker händer.
Fem element från litteraturen, känns de relevanta eller inte? Krav, resurs, roll, service,
73
händelse.
Ja, vi tar dem uppifrån och ner då!
Okej, krav?
Krav, vi har arbetat med krav. Beroende på hur man nu, vad du menar när du säger
krav, men om det är någons krav inom ramen för den här förmågan, så har vi jobbat på det
sättet att definiera krav. Med hjälp av förmågor tala om hur stor, hur många krav har vi
inom en förmåga. Och det handlar också att om man nu gör en utveckling, så kan det vara
svårt att göra någonting som är väldigt spretigt, det tar fokus ifrån frågeställningar, och
det blir väldigt omfattande. Därför är det oftast viktigt att man isolerar en aktivitet eller
händelse till ett givet område. Och då är det bra att använda förmågor som ett sätt att
prioritera krav. Så att, ”Vi tar den här förmågan först, och gör den bra. Sen börjar vi med
nummer två och nummer tre.” Och det har vi också använt praktiskt. Sen har vi väl hittat
lite andra skärningar, för förmågor är inte lösningen på all huvudvärk, men det var en bra,
det var ett bra, en bra första grej. Och prioriterar man till exempel bort då en förmåga, då
försvinner ju alla krav därunder, och då kan man liksom släppa den diskussionen. Det var
krav. Och sen hade du?
Resurs.
Resurser. Ja, allt ifrån IT-stöd till, det kan vara fysiska resurser, och andra saker, ja,
absolut. Absolut.
Roller.
Ja det är ju en sorts resurs. Eller, ja det beror ju på hur man ser det.
Service, tjänst?
Är det vilka typer av tjänster som behövs.. Vilka stöttande tjänster som behövs för att
den förmågan ska uppfylla..?
Ja, ungefär.
Då blir den väldigt teknisk. Ja, nej men absolut. Återigen, lösningen på den här förmågan
är ju inte bara vilka som jobbar och hur ser processerna ut, utan hur ser faktiskt stödet ut.
Om de här stöden i sin tur behöver, liksom, olika tjänster ifrån A till Ö, så, så är det väl
bra att man har koll på dem också. Men, ja, jag flummar ut lite i svaret där för jag vet inte
exakt vad som avses med service, där, så att.
Händelse.
Aktivitet då, process, aktiviteter, händelser. Som skulle bo i en förmåga då?
Ja, eller på något sätt påverka förmågan.
Ja, jo, men så är det väl, det är väl alltid en händelse som på ett eller annat sätt triggar den här förmågan att, liksom, aktiveras. Och den kan väl komma från olika ställen
och i sin tur så lämnar den ju faktiskt över nånting. Vi är inne lite i processperspektivet
på förmågan då, men absolut. Men det är ju händelser, de är ju högst relevanta, och de
blir ju väldigt relevanta också när man börjar prata om förflyttningar av, speciellt större
74
organisationer. Återigen, du kan inte göra allt på en och samma gång. Och då måste man
förstå frekvenser av händelser. Men också när händelserna kan tänkas inträffa. För då kan
man också effektivt styra utveckling. Om nånting inte händer förrän om tio år då kanske
det inte är värt att vi gör det idag, då kan vi vänta nio år till, så, till exempel.
Varför känns dessa element känns relevanta att koppla till förmåga, och skulle det vara
användbart i några specifika situationer?
Nej men det var väl, de som du nämnde och sen nämnde jag några innan dess, det var
väl ungefär same same. Ja, alltså, givet då att om det är verksamhetens spelplan, och där
vi har förmågor som slår både över affär, och verksamhet, och IT. Vi delar, i min värld,
på samma förmågekarta, de finns inte i olika lager eller på andra sätt. Då kan vi använda
den till precis vad som helst. Planera outsourcing, till exempel. Du kan, återigen, hur du
hanterar kompetenser i de här, ju mer stöd vi får i vårt vardagliga arbete, desto mindre,
minskar också kompetensbehovet på ett ställe men det kanske ökar på något annat då. Det
handlar om resurs- och kompetensplanering, absolut. Du kan koppla mål till förmågor.
Givet hur den här förmågan på något sätt uttrycks, hur den mår idag, hur bra bör den må?
Sen, vi använder också, jag kanske nämnde det tidigare, vi använder det till strategiska
krav, kärt barn har många namn, strategiska affärskrav, affärskrav, taktiska affärskrav, det
finns måna olika begrepp. Men strategiska krav, på ett eller annat sätt, som har sin källa
i nåt strategidokument, oftast, kan också, då, mappas mot förmågor, vilka strategiska krav
bor i den här förmågan. Fast de ligger lite ovanför, ser jag ändå, så de bor inte riktigt där,
men de påverkar.
Elementen, påverkar de förmågan, eller tvärt om?
Oj, det där var ingen lätt fråga. Jag tror inte att det finns nån, det är inte svart på vitt. Jag
kan ge två exempel. På ett ställe där vi till exempel påverkas av, där förmågan påverkas
av det som bor därinne, och tar vi mycket av den förflyttning vi till exempel gör nu inom
Folksam, så handlar mycket om att standardisera, framför allt till stor del processer, och
processerna bor, till nästan 100%, i någt IT-stöd. När vi köper de IT-system ifrå standardleverantörer, så påverkas ju vi av hur det här standardsystemet är utformat. Alltså påverkas
förmågan och vad som görs där av vilket stöd vi faktiskt har valt att använda. Och gör den
det så kommer den att påverka andra saker. Så det är ett sätt som förmågan påverkas av det
som bor därinne. Men sen finns det ju andra förmågor som är av kritisk karaktär, mer, som
har sin ram, så. Och då påverkar den snarare det som bor där i. Exempel på dem är såna
här bolagsspecifika frågor. Vi har en viss typ av bolagsstruktur, och den går inte att göra
våld på, inte på dag ett i varje fall. Vi har vissa juridiska perspektiv, compliance, aktuariella
perspektiv som är väldigt viktiga för oss. Och de här kraven då, inom ramen för den här
förmågan, kommer att påverka allt som hamnar där. Även om vi köper in standardsystem.
Respondent 9
Bakgrund:
Jag har jobbat på Folksam i sex år. Jag är sedan augusti chef för en avdelning som heter
Kundanalys, som ligger under Kundstrategi, affärsområde Privat. Och jag har inte jobbat
med förmågor, jag har jobbat lite med affärsutveckling tidigare här.
Så, kortfattat: vad vet du om förmågor?
Ja, jo, men jag har ju varit med i några såna affärsutvecklingsprojekt, så jag har kommit i kontakt med det så. Det fördes väl in här för runt ett och ett halvt år sen, helt
plötsligt så började alla prata capabilities, så det var så här ”Vad är det här för nånting?”,
75
och då kände jag att om jag ska kunna förstå vad man pratar om och, liksom, hamna på
samma nivå så man inte får ett språkligt övertag så vill jag lära mig det här. Och också vill
jag, började jag tillsammans med Charlotte och Carina titta på vilka förmågor som finns
inom mitt ansvarsområde, för att vi ska kunna se ”Vilka förmågor mår inte bra?”, ”Vilka
förmågor mår bra?”, och hur ska vi kunna utveckla dem. Bara liksom, för mig, att få upp
alla korten på bordet, för det är så lätt att det hamnar i projekt, så det är där man jobbar
med dem. Men jag har ju min vardag och det var där jag ville.. Så jag påbörjade det arbetet
i julas, och sen har jag haft en alldeles för hög arbetsbelastning så jag har inte haft nån
möjlighet att fortsätta. Men jag har, kunde inte riktigt, se fullt ut hur man skulle använda
det, men sen när vi började titta på det så kände jag att ”Ja, men okej, om vi börjar beskriva
verksamheten utifrån förmågor så kanske”, men jag var inte helt hemma än.
Du sa att det dök upp för ett och ett halvt år sen, ungefär?
Ja, jag tror det. I alla fall för mig. Cordial var ett bolag som kom hit. Och så helt
plötsligt kändes det som när de kom, och man gjorde den här nya arkitekturfunktionen,
man omstrukturerade massor som var, och då kändes det som att helt plötsligt började man
prata förmågor. Från att, jag vet inte vad man pratade innan i och för sig, men det kändes
som att helt plötsligt så började många prata om det.
Hur kom du i kontakt med förmågor?
Ja, det var ju just genom ett sånt affärsutvecklingsprojekt, som hette ITJP, som jag var
med i litegrann ett tag. Och det var där jag hörde ordet, och sen, då var det också, tillsammans med Carina Eriksson som du kanske har träffat, affärsarkitekt. Så hon hade gått nån
sån där affärsarkitekturutbildning, och det var där som, för det är många som har gjort den
på Folksam, och då känns det plötsligt som om man kommer med ett gemensamt språk,
som inte riktigt alla förstår.
Har du använt dig av förmågor?
Det var ju just för att få en bild av min egen verksamhet som jag försökte använda, jag har
inte nått fullt hela vägen fram, men jag kan tycka att det är ett bra sätt att tänka. Men
jag får ändå inte ihop det riktigt med kanske processer och sådär. Jag kan se hur liksom,
”Okej, det är det här vi ska göra”, men det, jag är inte riktigt klar. Men det kanske är för
att jag inte kan det heller, och jag kanske inte ska kunna det heller.
Finns det någonstans där du tror att det skulle vara användbart att använda förmågor?
Ja, men jag tror, eller jag ser det ju framför allt i projekten då, vad är det vi ska göra,
vad är det vi behöver kunna. Men också just för den egna verksamheten, alltså, så såg jag
det, utifrån mitt perspektiv, att jag tänker att ”Vad är det vi ska göra? Vad har vi för
förmågor inom mitt verksamhetsområde?”, och ”Vad är det vi gör? Hur mappar de, och
vad är det som inte mår bra?”, ”Okej, den här förmågan kan vi inte leverera, för att..” och
så kan man då hitta orsaker och kanske kan börja jobba med det, så man får upp någon
slags karta. Men sen är det ett konstigt sätt att uttrycka sig, så jag har svårt att, liksom,
dra det vidare till min grupp och säga ”Nu ska vi titta på vilka förmågor vi har”, de bara
tittar på mig, så att jag har inte riktigt hittat hur man ska, hur ska man kunna använda
det i verksamheten utan att alla ska behöva lära sig det? Det tycker jag är svårt.
Finns det något du skulle vilja koppla ihop med en förmåga?
Men jag tänker lite så här på processer, och hur det liksom hänger ihop helheten. För
76
det är ju en sak i en förmåga. Men jag vet inte, jag kan för lite om det.
Är det något förutom processer som du känner vore intressant att kunna relatera till en
förmåga?
Det har jag inte reflekterat över, men det finns det säkert. Ja, men det är klart att det
måste finnas det. Ja, men, jag vet inte om det är så du menar, men jag tänker att inom
mitt område, om man gör rätt saker på rätt ställe i organisationen. Så att vi inte sitter med
samma förmågekort på flera ställen. Jag vet inte.
Lista på fem element från literaturen, känns de relevanta att koppla till förmåga eller inte?
Krav, resurs, roll, tjänst, händelse.
Ja, men det låter ju relevant alltihopa. Såklart. Det är lättare då, om man tänker utifrån
ett projekt, så blir det ganska tydligt. Men jag tänkte utifrån min egen verksamhet.
Finns det nån särskild situation där någon av dessa är användbar att koppla ihop med
förmåga?
Ja, men i kravsituationer känns det ju också.. Vad hade du mer, roller och..
Resurs, tjänst..
Ja, men alltså, det är ju alla de här, som det är superrelevant, så klart. Men det känns
som att, i all fall utifrån mitt perspektiv, så tillämpar man det här sättet väldigt mycket
i projekt, och det är ju jättebra. Men det blir svårt eftersom man har en verksamhet som
man ska driva också, som inte riktigt är uppbyggd på samma sätt, överallt, och då är det
svårt, tycker jag.
De här elementen, påverkar de förmågan, eller tvärtom?
Nu måste jag tänka lite. Det borde ju vara så att det är fömrågan som ska få, eller vänta.
Att det ska vara, om man tänker sig att det är en affärshändelse som vi måste agera på, så
måste vi ju se till att vi har förmågan att kunna hantera den, med kompetens och massor,
krav och allt där i. Så det är klart det måste finnas nån hierarki i det där. Vi måste ju
anpassa våran förmåga till vad vi vill göra. Så tänker jag.
Respondent 10
Bakgrund:
Jag har jobbat länge på Folksam. I hela min yrkeskarriär i princip, i väldigt många olika
roller. Kommer från affärssidan, verksamhet, jag har sålt försäkringar. Jobbade länge med
produktutveckling, haft ledande befattningar i 20-25 år. Nu är jag specialist, men jag jobbar med styrningsfrågor, governance-frågor. Och just precis nu så sitter jag och utvecklar
ledningssystem för informationssäkerhet och kvalitet, bland annat tagit fram en certifiering.
Och det som gör att jag är intresserad av förmågor, det egentligen grundar sig litegrann
på mitt intresse, min erfarenhet, min insikt om hur vi jobbar i såna här stora, komplexa
organisationer. Det är väldigt lätt, vet du, att det blir dubbelkommandon, spagettisystem,
dubbellagring. I verksamheten speglas det av att man har parallella processer för att göra
samma saker. Så att jag har försökt, i det jag gjort, liksom genomsyrar mitt arbete, att
hitta lösningar för integrera olika typer av processer och system och såna saker då. Och
ur det perspektivet, när jag blev bekant med förmågor, var det litegrann ”Aha, här har vi
nåt”. Så dök det upp.
77
Kortfattat: vad vet du om förmågor?
Ingen teoretisk grund. Men jag har stött på det, jag har jobbat och är väldigt bekant med
arkitekturfrågorna, jobbat nära dem, så att säga, så jag har fått information. Litegrann har
jag läst, så jag förstår ju ungefär principerna för det. Men det är inte min specialitet, så att
säga.
När dök konceptet med förmågor upp? Hur länge har du jobbat med det?
Jag har varit bekant med det, tror jag relativt tidigt, sedan 4-5 år tillbaks. Jag har fått,
liksom, underhandsinformation genom att jag har goda relationer till koncernarkitektur.
Hur kom du i kontakt med förmågor?
Ja, dels har jag fått information som jag sa, men konkret tillämpning var för ett par
år sen, när jag försökte se hur jag kunde applicera det på det jag gjorde just då, nämligen
informationssäkerhet. Där man såg sambanden mellan informationshantering, allt vi gör på
Folksam handlar om information egentligen, det är immateriella tillgångar, det är processer
och det är system, och så är det mycket information då. När man jobbar med arkitektur
så är liksom informationshanteringen central, vilket speglas i förmågor, så att säga då. Och
det jag jobbar med är egentligen samma sak då, när jag jobbar med ledningssystemet. Det
var säker informationshantering. ”Aha.” När vi då ska, som det heter, nu är vi inne på
informationssäkerhetsteori. När vi då, som jag skulle göra då, hitta en modell för att identifiera informationstillgångar, då står ju liksom två teorier mot varandra. Då är hela det här
med informationssäkerhet baserat på standard då, ”Vad är en informationstillgång?”, ”Hur
definierar man den?”, kontra ”Hmm, vad är förmågor? Hur definierar man dem?”. Och
då såg vi sambanden då mellan säker informationshantering, informationshantering, det vill
säga informationstillgångar, och förmågor. Och den, i det, det var liksom en aha-upplevelse.
”Det här kanske vi kan göra något riktigt bra av, istället för att köra parallella spår när
vi ska bygga upp två olika ledningssystem.” Det var det, nån slags idé då, som både koncernarkitektur, som jag fick lite stöd av just vid det tillfället, och jag då som representerade
infomationssäkerheten när vi skulle bygga upp ledningssystemet såg att här är nånting vi
kan samarbeta kring då. Det var det ena. Det andra som egentligen är samma sak, nu är det
ännu mer teori då, men operativ risk, Solvens-regelverk, alla pratar om risker idag, det är så
mycket risker förknippat med framför allt användandet av IT, så att säga va. Sociala medier, allt är information, alla är beroende av information. Och för att, om vi ska bedriva den
här typen av verksamhet som vi gör på Folksam, så måste kunder och intressenter försäkra
sig om att vi har just en säker informationshantering, för annars tar vi risker, och finansinspektionen, den övervakande myndigheten, de ställer väldigt mycket krav, och det gör även
det här kommande Solvens-regelverket, på operativ riskhantering. Operativ riskhantering
och informationssäkerhet är ungefär samma sak kan man säga då. Det var en lång, för att
komma dit, men i alla fall. I arbetet med att identifiera, hantera, och rapportera operativa
risker till ledningen så såg vi också en möjlighet att rapportera de operativa riskerna på
verksamhetsförmågor till ledningen, för att hitta något sätt att bygga upp strukturen på.
Som ett alternativ till, som det hade varit dittills, att man hade gjort riskbedömningarna på
funktionsnivå. Det finns många funktioner på Folksam, typ hundratals. Och sen så bakar
man ihop det och så ger man nånting, men funktionerna speglar ju inte vad man gör eller
hur man vill att det ska vara, utan bara var människor sitter någonstans. Så det ger inte
ledningen en bra bild av risksituationen i företaget. Genom att relatera till förmågor och
en idé om, kanske man kan koppla ihop i framtiden, att formulera mål på förmågor, och
hantera risker, alltså riskerna att man inte kan uppfylla målen. För det är egentligen det
som risker handlar om. Det var liksom bara, så här, lösa tankar om det då. Nu kanske jag
78
svarar på andra frågor också. Men sen så var man ganska progressiva då på risksidan, och du
kommer säkert prata med dem också då, som vågade ta klivet, att börja rapportera, utan att
man hade en underliggande struktur på verksamhetsförmågor, så började man rapportera
riskerna till koncernledningen på verksamhetsförmågor. Ja, och i det arbetet har jag liksom
stött och uppmuntrat, kan man säga. Eftersom risk och informationssäkerhet hänger ihop.
Du har kommit in lite på nästa fråga: har du använt dig av förmågor, och hur? Har
du några fler exempel?
Nej, det som jag konkret har försökt använda det till, det var de två, konkreta användningsområden
som jag försökt, liksom, bidra till eller har tillämpat då, så att säga. Naturligtvis andra,
men det är inte mitt bord då, så att säga.
Kan du se några andra användningsområden för förmågor?
Man kan vända på det, vad kan det inte användas till? Nej, ja men fokus då i allt som
har, vi är styrda av, nu försöker jag tänka här, vi måste rapportera ekonomier på produkter och bolag. Och kostnadsställen där pengarna finns ligger ju på funktioner, det kan vi
inte göra så mycket åt. Det driver så att säga ett funktionellt arbetssätt, för vi måste ha
ekonomierna kring de här parametrarna. Men det är ju inte det vi vill uppnå, vi vill inte
vara funktionsorienterade eller produktorienterade, utan vi vill ju nå våra mål framöver.
Och för att nå dit, allt då, utöver ekonomierna, så vi kan styra mot och följa upp mot,
där skulle jag vilja peta in förmågorna. Alltså oavsett om det är verksamhet eller den här
typen av flummiga frågorna som jag jobbar med, det är risk och GRC compliance och såna
saker, som underlättar för ledningen att få en vy över företaget i förhållande till var vill vi
vara i framtiden, hur ser de långsiktiga målen ut, hur tar vi oss dit då, all styrning. Och
kanske då framöver, även mått och mätetal, och de delarna. Så måste det sen möta den
ekonomiska uppföljningen, så klart. Det är min lilla våta dröm, om hur man ska kunna
använda förmågorna framöver. Utan att ha den där teoretiska, liksom, grunden för vad
man kan göra med förmågor och så. Men jag ser, man blir lätt euforisk när man ser de
möjligheterna, den här silverkulan i verksamheten som skär igenom allting, som inte funnits
tidigare. Jag höll på att tröska rätt mycket med processer på 90-talet, och tyckte väl inte
att man uppnådde riktigt de effekterna med processorientering.
Vilka element vill du koppla till förmågan för att det ska vara användbart i dessa situationer?
Ja, jag tror att jag delvis lämnade svar på det när jag sa ”Inte de ekonomiska rapporterna”,
och det betyder ju allting annat, ur perspektivet styra och följa upp verksamheten. Då är
det alltså all information ur ett styrnings- och uppföljningsperspektiv då. Och det betyder
ju också att man måste sammankoppla en hel del saker. Informationsmängder, processer.
Man måste bryta ner förmågor, koppla dem till processer, koppla det till system, och göra
den här kopplingen, alltså det är ju en så otroligt komplex organisation. Och det är ju den
analysen som återstår, därför kan jag inte svara på den mer konkret än vad jag gör just nu.
Förutom processer och system, finns det några andra element du känner vore intressanta?
Nej, det är ju alltså process, och med process menar jag ju då liksom arbetsrutiner på
operativ nivå, sen är ju det i de olika verksamheterna oavsett om det är HR eller IT, eller
om det är nånting annat som görs i verksamheten. Det är ju liksom ingenting som är
uteslutet då, utan det är det som görs, då kan man hitta det på operativ nivå, som är mer
generiskt, där de sen har en drivkraft där man sätter mål på förmågor och sen utformar man
processer, och processerna gör olika saker, varför man suboptimerar och springer åt olika
håll då. Så det måste ju ner på operativ nivå för att man ska kunna styra verksamheten i
79
önskad riktning då. Det är så långt ner man måste komma, då tror jag inte man kan, då
ska man nog ha utgångspunkten att man inte exkluderar någon verksamhet. Men sen är ju
det, jag menar, det är ju ett sånt där arbete som aldrig blir klart, det är ett förhållningssätt
eller ett synsätt då.
Fem element från litteraturen, känns de relevanta att koppla till förmågor? Krav, resurs,
roll, tjänst, händelse.
Krav, ja, det är styrning. Resurs, det beror på vad man menar med resurs. Om man
menar med resurser mer typ av personal och kostnader, så är det en ekonomisk fråga och
då har vi ett styrsystem som säger att det ska hanteras på ett visst sätt. Men sen kan ju
resurser vara andra typer av tillgångar, det kan ju vara fastigheter, lokaler, och såna saker
va, så att, man ska vara noga med definitionerna va, jag måste veta vilka resurser det avses,
för vi måste hantera..
Du får gärna ha en åsikt om båda.
Men resurser i form utan tillgångar, då kan jag vrida det på mitt sätt och säga att en
resurs är en tillgång, information är vår viktigaste tillgång, så alla typer utav informationtillgångar i den meningen att de utgör resurser, det måste relateras till förmågor om man
vill uppnå någonting. Och krav ställer man ju på informationen. Så styrning av, egentligen
löpande verksamheten, de resurser i form utav informationstillgångar och krav på informationstillgångar ur ett förmågeperspektiv blir ju en viktig styrningsfråga om man ska uppnå
någonting. Dels det löpande arbetet i sig, och sen förändringsarbetet. Vad sa du mer?
Roll, tjänst, och händelse.
Roll. Ja, det blir nog kanske när man har mognat i det här om man tänker roller, ansvar
för att utföra arbetsuppgifter, ägarskap och de frågorna, så kan man ju tänka sig att om
man har kommit en bit på väg, man måste ju mogna i det här också. Man kan inte börja
utse ägare och ansvar och roller mer än kanske på arkitektursidan, för att driva arbete, men
när man har mognat i det här så tror jag att frågorna addreseras, hur man ska jobba rent
praktiskt, vilka roller som ska finnas. Men där är man nog inte än, det tror jag man ska ta
det lite försiktigt med. Så man inte tror att det är lösningar på den här frågan hur man ska
åstadkomma resultat med förmågor som drivare i arbetet.
Sen tjänst och händelse.
Ja, tjänst. Det definieras också på olika sätt va, beroende på vad man menar med det,
men utföra en tjänst eller leverera en produkt, menar jag, det är ju samma sak. Egentligen
att vi utför de tjänster i arbetet, levererar den produkt som kunden kräver, det menar jag,
i och med att vi jobbar med immateriella tillgångar, det vill säga utför tjänster, vi är inte
en snickerifabrik eller tillverkar bilar, så är det det löpande arbetet, så självklart, ja, tjänst.
Men du kommer få, när du frågar runt i Folksam om tjänst, så kommer du få olika svar på
det. Jag svarar utifrån ett ISO 9001-perspektiv som är den allmänt vedertagna definitionen
på vad tjänst är, utanför det här företaget. Sen finns det mycket annat som är tjänster också.
Händelse.
Nej, det har jag ingen uppfattning om.
De relevanta elementen, i vilka situationer skulle det vara användbart att koppla dem tillförmåga,
och varför vill du koppla just dessa?
80
Svår fråga. Också definitionsfråga, men jag tror att det har ju att göra med vårt dagliga
arbete, det är ju objekt som du tar upp som, det finns ju naturligtvis flera, och sen är det ju
som sagt definitionsfrågor, men det är ju sådant som om man säger, min uppfattning om det,
att man ska styra verksamheten så att vi åstadkommer ett resultat i önskad riktning, och
följer upp verksamheten. Då blir ju de här parametrarna, då måste man ju uppmärksamma
dem. Då hänger ju väldigt mycket på det. För sen liksom att konkretisera det, då måste
man ner i geggan och hitta de här entiteterna där man kopplar ihop det, och det kan jag
inte ha nån uppfattning om. Jag svävar ganska högt där. Då är det nästan lättare att
kanske ta någon slags konkret exempel, och det liksom känns lite svårt att komma på, då
måste jag fundera litegrann. Men jag tog ju ett exempel genom det som vi hade gjort i
vårt arbete, det går ju att omsätta i produktutveckling till exempel, man kan hitta gemensamma komponenter kopplade till förmågan, hur man vill att produkterna ska utformas, till
processutvecklingen, gemensamma komponenter som om man definierar det som tjänst eller
händelse eller krav för att man ska förändra processerna, det är ju lite situationsanpassat
också. Men det var ju det där, man hittar det i alla verksamheter som utförs oavsett om
det är IT eller mer på verksamhetssidan, i de olika ledningssystemen så hittar man ju det
som måste styras för att vi ska kunna nå dit.
Elementen, påverkar de förmågan, eller tvärt om?
Ja, det är klart att förmågan, om man säger, jag ska styra, om man bryter ner styrningen i mått och följer upp att elementen rör på sig bara för att man vill styra, så påverkar ju
förmågestyrningen alla elementen. Annars är det meningslöst att hålla på. Om man följer
upp så påverkar ju avvikelserna i styrningen, alltså att man inte har nått avsett resultat,
då påverkar de ju förmågan att uppfylla, så att säga. Det är så jag vill att man ska se
det. Då blir det ett ledningsverktyg om man använder det på det sättet, och jag tror att
koncernarkitektur uttalat eller outtalat har de ambitionerna, att det är ett viktigt verktyg för att kunna förflytta Folksam, och då måste man tänka Styrning, hmm, Uppföljning,
Avvikelser, Mål, Mått, bryta ner det.
Respondent 11
Bakgrund:
Jag är nyanställd på Folksam. Jag började vid årsskiftet, och har en roll som heter ITstrateg. Så jag jobbar på Strategisk IT, där koncernarkitekterna sitter, men jag är då en,
vad ska man säga, som en egen liten roll. Jag rapporterar till Daniel Leideberg som är chef
för Strategisk IT, och sitter i den ledningsgruppen, men har inte en egen organisation. Jag
är liksom nån form av specialist då. Och tanken med min roll är väl att jobba och stötta
hela IT-organisationen i strategiska frågor, och driva liksom lite olika initiativ. Jag jobbar i
princip bara uppdragsbaserat och har inga linjeansvar, förutom kring fusioner och uppköp
så är jag inblandad ur IT-perspektivet då. Och framför allt nu så håller jag på och jobbar
med en systemstrategi för utvecklingsområdet inom koncerngemensamt stöd, som ekonomi
och HR och sådär.
Kortfattat: vad vet du om förmågor?
Ja, begreppet som sådant är väl lite nytt för mig. Jag har ofta, jag tror nog att jag har,
så att säga, arbetat med det innan, även om jag ofta själv har tänkt i termer av, liksom,
funktioner, alltså det är nånting vi gör, och det är väl, tror jag, i mitt huvud, bara en anna
label på vad det handlar om då. Och nu innan jag började på Folksam så har jag jobbat som
konsult på Accenture sen 2007, och där har jag ju ofta liksom hanterat de frågeställningarna,
”Vad är det vi vill åstadkomma?”, “Vad är det för nåt vi ska kunna göra?”, och liksom, hur
81
gör vi de förändringarna då. Så, som tanke är det väl i mitt huvud, men just att kalla det
för förmågor har jag väl börjat göra här på Folksam då, tror jag.
Så när du började jobba med just förmågor var när du började på Folksam?
Ja, som begrepp så. Men som definition har det väl ofta funnits med mig.
Hur kom du i kontakt med förmågor?
Ja, här är det ju för att i det team som jag leder kring den här systemstrategin så är
det tre stycken arkitekter som jag jobbar med, och då, och även i min introduktion till
företaget så satt jag ner med Charlotte, till exempel, ja, och med Robert och Stefan Reifalk
och så, så det kom väl in ganska snabbt där, hur man jobbar med den kartläggningen.
Och vi satt och tittade på en del arbete som har gjorts kring förmågekartläggning inom
ekonomiorganisationen och sådär.
Har du använt dig av förmågor, och i så fall hur?
Ja, vi, i systemstrategiarbetet så har vi ju, en del i det är ju att, vi försöker ju måla
upp en målbild för vårt applikationslandskap. Och det ska ju stödja funktionalitet, eller
förmågor. Och än så länge så pratar vi väldigt mycket om de målbilderna och den här
målfunktionaliteten, eller logiska IT-stödet, eller förmågor. Så i de termerna har vi väl både
varit i det gränslandet, och sen nu de nästa steg som kommer, så handlar det mycket om
att se ”Var är vi i nuläget?” och ”Vad är det för nåt vi klarar av att göra idag?” och ”Vad
är det för gap mot det vi vill?”. Och i det så handlar det ju både om att titta på systemen
men också då ta förmågekartläggningen ett steg längre och känna att vi har träffat rätt där.
Kan du se några andra användningsområden för förmågor?
Ja, alltså, jag tycker väl, generellt, så när man kommer som ny på Folksam, om vi nu antar
att det här blir Folksam-specifikt, så är det ganska svårt att få en överblick och förståelse
för vad är det man gör var, och gör man samma typ av sak på flera ställen, och varför gör
man det, och sådär. Och i det där arbetet vi håller på med nu, så jobbar vi ju även med
FAR, framför allt för att börja försöka få till en annan dokumentation kring de system som
vi har. Men där ser, måste ju förmågorna komma in så att man kan få en koppling både till
organisation, som, vad säger man, stöder eller genomför de här förmågorna. Systemen som
ska stötta och liksom hur de hänger ihop, så det är ju, liksom, att få överblicken, och kunna
förstå om vi nu ska göra förändringar här, och liksom, flytta på nånting, eller ja, fusioner
och uppköp, om vi köper ett bolag. Hur passar det in i vårat pussel, och vad är det för
typ av synergier vi kan få, eller vad är det för problem det här kommer att ställa till, eller
kommer vi. Där tror jag att man har väldigt stor nytta av att förstå sin egen förmåga, vilka
de är och var de finns och hur vi arbetar med det. Men jag tror att det är väldigt viktigt
att, ja men, FAR eller nåt typ av verktyg som, så att man kan ha all den här informationen.
För bara en förmågekartläggning i nån form av bild som inte rör på sig, eller bild som inte
har kopplingar till annat, den blir ju inaktuell och till slut ganska värdelös, när man inte
ser hur det hänger ihop med människorna som utför det eller systemen som stöder det eller
vad det nu är. Så, ja, var det ett svar?
Jadå. Vilka element vore intressanta att relatera till förmågor? Du nämnde organisationer
och system, finns det några andra?
Ja, det tycker jag. Man har ju tagit fram ett värdedrivarträd, eller en värdedrivarlogik,
som vi så att säga ska mappa in de olika initiativ och projekt som vi har. Det är liksom,
82
vad är det för, ”Vad bidrar det här med?”, och så finns det ett antal huvudgrupper på
värden och sen så nedbrutet. Där tycker jag ju man bör kunna hitta en koppling, att en
förmåga kan säkert bidra till, eller bör ju bidra till en eller flera av våra toppvärdedrivande
koncept då. För gör de inte det kan man ju fråga sig ”Varför har vi den här?”. Och då
bör man också kunna förstå vilka förmågor är det som är viktiga, och vi kanske ser, fattas
det förmågor, eller? Och sen så skulle man ju även vilja få någon form av, ja, vad ska man
kalla det? Hälsomätning? Alltså, hur är förmågan, hur mår den? Och vad består den av?
Vad är det som krävs för att förmågan ska upprätthållas? Är det bara kunskap, eller är
det systemstöd, eller vad är det för nåt vi behöver för att kunna exekvera på den här, och
hur mår vi. För då kan man ju också börja förstå vad är det vi behöver, liksom, var kan
vi bli mer effektiva eller mer duktiga. Och på samma sätt som att förmågor då knyter an
till våra värdedrivare, så bör man ju även, tycker jag, för att förstå, om man tänker liksom
förflyttningsperspektivet, vart är vi på väg, så bör man ju på samma sätt som man kopplar
initiativ och projekt till liksom värden och effekter så bör man ju förhoppningsvis kunna se
vilka såna arbetsinsater som bidrar till en stärkt förmågehälsa, så. Så det hänger ju ihop,
men, ja.
Fem element från litteraturen, känns de relevanta? Krav, resurs, roll, tjänst, händelse.
Ja. Krav känns ju absolut relevant. Vad sa du sen, resurs?
Ja.
Kan du förklara vad du menar med resurs?
Det kan vara dels till exempel pengar, dels material och sådant som byggnader, beroende
på hur man vill modellera det.
Men, har det också, för resurs kan ju också vara, alltså, arbetskraft eller datorstöd, och
i så fall tycker jag ju att det är relevant, det sa jag ju. Ja, men det känns ju relevant, att
man kopplar vad är det för nåt som får det här att hända.
Sen roll.
Ja, de är ju lite lika resurser, just det.
Och tjänst och händelse.
Och tjänst i perspektivet arkitektur?
Tjänst som på nåt sätt bidrar till förmågan, tjänst som förmågan bidrar till att det går
att erbjuda.
Är det förmågan som bidrar till tjänsten, eller är det tjänsten som är, ja, en del av förmågan?
För man kan ju tänka, men tjänsten är i någon form av, ja, det erbjuds en tjänst på ett
eller annat sätt, som gör någonting, och ja, det bör ju vara en del av en förmåga. Sen om
det, vem det är som utför den här tjänsten, det kan ju antingen vara vi här, eller vi köper
en tjänst nån annan stans. Men för att en tjänst ska vara relevant för oss, antingen att
erbjuda, alltså att IT erbjuder en tjänst för verksamheten, eller att vi erbjuder en tjänst för
våra kunder, eller att vi köper en tjänst för nåt sånt där, då bör ju den koppla till nån typ
av förmåga, det känns ju rimligt, så. Givet att man arbetar med den typen av paketering.
Och där är jag lite osäker vad, hur Folksam gör just nu. Om det liksom finns nån form av
tjänstekatalog eller liksom att man arbetar på det sättet, eller om man vill röra sig lite åt
83
det, det vet jag inte.
Och händelse.
Vad tänker du på för händelse då?
Någon slags händelse eller event som kan påverka förmågan eller företaget.
Tänker man då, vad vet jag, skulle det kunna vara att jag vill köpa en försäkring, som kund,
och att ja, vi ska ha en förmåga som heter, som handlar om att vi upprättar försäkringsavtal,
eller att vi får en premieinbetalning och vi har en förmåga som heter hantera betalningar, så?
Ja.
Ja, men absolut, det är klart att det är relevant. För troligen så är ju en händelse relaterad
till flera förmågor. Och om vi tar händelsen köpa försäkring, så bör vi både kunna upprätta
nån form av avtal, vi måste ju ha en förmåga att ha koll på hur våra försäkringsprodukter
ser ut, vi måste kunna ta hand om betalningar, vi måste kunna köpa produkter, eller ja,
liksom, skadematerial och annat. Så de relaterar ju, om man förändrar den så kommer man
ju behöva säkert förändra annat. Så det är säkert klokt.
Dessa element, varför känns de relevanta att koppla ihop med förmåga, och finns det någon
särskild situation där det skulle vara användbart?
Alltså, generellt för att jag tror man förstår bättre vad det är som antingen inte fungerar bra
eller vad som, genom att göra nånting bättre så blir liksom helheten bättre. Det är ett, A
och O, det här med att, som försäkringsbolag så bör vi ju ha ett antal övergripande förmågor
som inte förändras, vi ska sälja försäkringar, vi ska försäkra människor, och sen så kan vi ju
hantera det på olika sätt, men jag tror att man får ett sätt att förstå hur helheten hänger
ihop, med en jäkla massa bolag och det är ju liksom lite lokala världar i liksom skador och
i pension och man håller på och, det är inte säkert att man förstår att en förändring här
faktiskt påverkar en massa andra saker, och då är det här ju ett sätt att få koll på det. Det
var väl det generella.
Elementen, tror du att de påverkar förmågan, eller tvärtom?
Det var ju ingen lätt fråga. Vem kom först, hönan eller ägget? Jag tror nog att, jag
skulle vilja säga att det beror nog på. Och jag tror också att det kan ha att göra med, alltså,
på vilket sätt, kulturellt, alltså, hur är de här förmågorna definierade, och har de, om man
får liksom vara lite fräck och säga att, om det är nån form av, liksom, efterkonstruktion, i
att, okej, det här med förmågor är ju praktiskt och bra, vi ser ett värde i det. Då säger vi,
“Vad har vi för förmågor?”. Då är ju de säkert drivna ur antingen om det nu är händelser
eller om det är processer som vi har, så har man ju på nåt sätt kommit fram till de här
förmågorna. Man har säkert tittat på om det finns nån industristandard eller olika sånt där,
visst. Men man är ju påverkad av hur saker och ting har varit. Och då skulle jag väl tro
att, ja men, hur länge vissa saker har funnits, och nån form av mognadsgrad och sånt där,
så finns det säkert olika typer av påverkan. Är det, så att säga, affärshändelsen som styr,
eller är det så att det kanske är nån förmåga som är väldigt central, som har funnits väldigt
länge eller som styr andra saker. Men jag har ju ingen känsla eller kunskap kring vilken som
är styrande i de här sammanhangen, tror jag. Men jag tror att det finns en, ja, låt oss säga
kulturell eller tidsaspekt på det.
84
Respondent 12
Bakgrund:
Jag är verksamhetsarkitekt, på koncernarkitektur, och har varit här sen september, ett
halvår. Har jobbat som verksamhetsarkitekt, ja, tolv år kanske.
Kortfattat: vad vet du om förmågor?
Vad jag vet, ja, jag vet ganska mycket. Vad man har det till, och hur man bygger upp
dem, och strukturen, och varför man behöver dem.
Kortfattat: vad är det?
En förmåga är nånting som behövs i verksamheten för att man ska kunna utföra sin business.
Utan att man säger hur eller när eller vem som gör det. Till skillnad mot processerna som
talar om det. En förmåga finns bara en enda gång i en förmågekarta, om man nu uttrycker
sig så.
Hur länge har du jobbat med förmågor?
Jag har nog hållt på i en tre till fyra år med det.
Hur kom du i kontakt med det?
Ja, det var nog när vi skulle, det var på min förra arbetsplats då, när vi skulle försöka
beskriva vad vi gör, vad vi har för olika systemstöd, vad vi behöver kunna hantera. För vi
hade väldigt mycket olika processer, mycket olika systemlösningar, och vi ville se att om vi
ska göra en ny förändring av nånting, hur, vad har vi då som skulle kunna hjälpa oss, finns
det nåt annat systemstöd idag som gör samma sak. Det var också i, när vi skulle försöka
klassificera vilka olika initiativ vi hade, vad var de inom för områden? Det var då vi började
förstå att vi behöver en sån karta.
Har du använt dig av förmågor, och i så fall hur?
Ja. Dels har jag ju använt det i att, när vi har tittat på processer. Att slippa gå ner
och göra aktivitetsflöden, kan man säga, “Vad är det för nånting du utför i den här processen?”. För att kunna hitta, just om man gör en förändring i en förmåga, ”Var slår det?”,
i vilka processer slår det, för att se att vi fångar alla. Som, till exempel om vi ska ta Kund
då, som är ett ganska vanligt, så då kan man ju Hantera Kund på olika sätt. När man, första
gången man möter den, eller när man ändrar den, eller när man avslutar, och det är ju olika
processer. Om man ändrar nånting i Kund, så måste man kolla alla de här processerna, så
där, det var viktigt. Vad var frågan?
Om du använt dig av förmågor, och i så fall hur? Är det väldigt många behöver du ju
inte räkna upp alla i detalj.
Men det var i så fall identifiera var vi måste gå in och kontrollera när vi ska göra en
förändring.
Kan du se några andra användningsområden för förmågor?
Det är ju ett bra sätt att identifiera ansvar inom organisationen, vem som har ansvar för
vissa delar. Och sen är det ju, ja, just i planering, vi använder det ju på ganska många, det
85
är planeringen av olika initiativ, så är det ju bra.
Vilka element tycker du vore intressanta att koppla ihop med förmåga?
Ja, det är ju processer, det är ju applikationer, eller tekniskt systemstöd. Det kan vara
organisation, men det behöver det inte vara, tycker jag, riktigt. Det är ju information, det
är ju lagar och policy och regler, regelverk, affärsregler då. Det är ju det jag är intresserad
av. Sen finns det ju krav då, men då är det ju mer kravsidan, så det är inte det jag använder.
Fem element från litteraturen, känns de relevanta? Krav, resurs, roll, tjänst, händelse.
Ja, krav, just för mig, jag behöver ju inte krav, för jag, det är mer krav. Men man behöver
kunna koppla krav till, ett krav är ju ofta nånting som bara gäller nu, när jag göra det här.
Sen om ett år så är ju kravet annorlunda. Vad var det, sen hade du resurs?
Resurs, ja?
Och resurs, då är det kanske information vi tänker på eller, och system?
Ja, det kan vara information, det kan vara pengar, det kan vara annat som byggnader.
Du får gärna ha en åsikt om flera.
Jag ser det nog som att det är information och systemstöd då, och det tycker jag absolut, ja.
Sen är det roll.
Ja, om man då tänker på utövar.. Jag tycker inte rollen är jätteviktig, faktiskt. Men
däremot kan det vara om man vill dela upp ett ansvar, vem som har ansvar för det där,
inom en business, men utövarrollen, nej.
Ansvarsrollen möjligtvis, men inte utövarrollen?
Ja, och det är ju ur aspekten att om man vill göra en förändring i den här förmågan,
så måste man gå via den ansvariga för att veta.
Tjänst?
En tjänst, det är ju hur det är implementerat. Det är inte jag heller intresserad av, men det
är ju IT intresserade av.
Och sen händelse.
En händelse. Ja, det är ju också mer det som hör till, jag skulle säga att det är processerna som beskriver händelserna litegrann. Ja, jag är lite tveksam på den.
Dessa element, varför vill du koppla just dem, och skulle det vara användbart i några specifika situationer?
Det är i analyssynpunkt. Dels är det ju för att veta vilka regler som gäller, lagar och
regler och affärsregler. Om man nu vill styra om sin business på något sätt, då vet man var
regeln hör hemma nånstans, och en regel kan ju slå på flera förmågor. Sen är det ju analysen
då, hur en förändring av den här förmågan slår i organisationen, om jag behöver göra om
86
nån process. Eller om jag går från andra hållet, om jag har en process jag vill modifiera,
vad innebär det? Ja, det är de här förmågorna som kommer att störas, och vad har de för
regelverk? Det är, liksom, spårbarheten där. Det är också om jag behöver byta ut mitt
systempark, om jag drar i systemet X, var nånstans, då ser jag ju vilka processer de jobbar
i, och så ser jag ju också vilka förmågor, eller jag kan kanske koppla dem direkt till förmågan.
Elementen, påverkar de förmågan, eller blir det påverkade?
Förmågan är ju, den är ju beständig, kan man säga. Sen hur den förmågan appliceras i
verksamheten, den kan ju förändras. Jag menar, du kan ju ha en manuell hantering av
en förmåga som sen blir automatiserad. Då har du ju ändrat systemstöd eller processen.
Så processen kommer ju, eller, förmågan kommer ju inte ändras, om du inte ändrar din
affärsmodell, där du säger att “Jag ska göra nånting annat”, eller kommer på nånting, utan
de är snarare de andra attributen, processen, applikationerna, som kommer att styras.
A.2
Intervierw set 2
Respondent 1
Hur kan man se om en förmåga fungerar bra eller inte?
Då måste man titta på vad det är som bygger upp förmågan, och då är man tillbaka till
organisation, processer, system och så vidare. Aggregatet av den sammanställningen bygger
förmågan. Så man måste kolla på ingående delar, och hur de samverkar.
Vad tror du påverkar en förmågas välmående mest?
Det tror inte jag man kan säga, för det beror på vilken förmåga och vad den är uppbyggd
av. Du kan ju säga att en förmåga, att vi inte har automatiserat något stöd i den, då har vi
ju organisation och processer, det finns inget systemstöd över huvud taget. Så då kan du ju
inte säga generellt att en förmåga mår alltid sämst i IT-delen eller i process-delen eller så,
utan, nej, det beror på vad det är för förmåga och vad den byggs upp av.
Finns det några egenskaper hos förmågan du tror påverkar hur förmågan mår mer eller
mindre än andra?
Nej, jag vet inte vad det skulle vara för nånting, vad för egenskaper den skulle ha. De,
så att säga, den är en gruppering eller ett aggregat av andra delar, så att förmågan, egenskaper för förmågan, byggs ju upp av andra. Pratar vi egenskaper, ja, men färg, blå, röd,
grön, blablabla. Nej, jag kan inte relatera till det just nu.
Av elementen, är det några du tror påverkar förmågan mer än andra? Finns det några
specifika situationer?
Inte vad jag kan komma på så, nej. Det kanske är enklare om man tar ett specifikt fall
eller nånting sånt, men rent generellt sett, om vi säger att de byggs upp av de här byggklossarna, så är det ju hur de samverkar, det kommer ju vara olika vad du än tittar på. Och
likadant kommer det vara olika om du tittar på det på Folksam, eller om du tittar på det
på If eller nån annan stans, du kommer inte titta på samma saker för det kommer att vara
uppbyggt på olika sätt.
Tror du att det finns några egenskaper hos elementen som påverkar förmågan mer än andra?
Vad pratar vi om för element?
87
De vi har gått igenom, som kan kopplas till förmågan. Så kanske till exempel upp/nertid för en viss applikation, finns det något sånt som kan påverka mer än annat?
Det beror ju på vad du lägger i definitionen av, om man tittar på, om man bara går tillbaka nåt år, när man inte använde sig av förmågebegreppet över huvud taget, då kallade
man såna saker icke-funktionella krav eller egenskaper på system, uppetider till exempel,
och så vidare. Jag relaterar inte dem till förmågor, jag relaterar dem fortfarande till ickefunktionella krav på ett system, ”vi måste vara uppe 24/7/365”, så, ja, då är det ett krav
snarare än att, på systemets egenskaper, eller det som bygger upp systemet, servrar och så
. Sen kan man naturligtvis säga att det kan kopplas till en förmåga. Vinner man nånting
på det? Jag tror inte det.
Respondent 2
Could not be reached for a second interview.
Respondent 3
Hur kan man se om en förmåga mår bra eller inte?
Idag tycker jag inte att vi har kommit dit att vi kollar det, så det är svårt att svara på.
Jag har inte varit med i såna jobb där vi kollar specifikt på en förmåga riktigt. Ja, eller så,
jag vet inte hur jag ska tänka där. Samtidigt så kollar vi ju då på ”vad är nuläget kring
en förmåga idag?” i något avseende, vilken förflyttning sker kring en förmåga, det gör vi
i systemstrategin, nya, för kundmöte. Då har vi ju litegrann ett systemperspektiv i det
vi ska leverera men samtidigt så tittar vi ju jättemycket på affärskraven som ligger på en
viss förmåga, då ser vi massa önskemål eller behov då helt enkelt, genom affärskraven. Och
det innebär ju då att vi vill flytta förmågan framåt, vilket vi kan göra. Så om man ser
det på det sättet, det kanske är det som är tillämpningen då, så absolut, då jobbar vi med
hälsotillstånd idag då, det gör vi ju. Och på samma sätt gör vi olika omfattningsanalyser för
initiativ då. Ska man bygga vidare på det och mer mappa upp exakt var vill man titta på
förmågor, vilken information vill man titta på eller så där, då kan man ju bli ännu tydligare
då i vad som är ett hälsotillstånd eller inte, jämfört med den nivån som vi är på idag då,
som är kanske lite mer övergripande. Men man tittar ju ändå på olika delar i olika initiativ
och olika strategiarbeten då. Ja, vi gör det, men det går absolut att göra ännu mer.
Finns det något som påverkar hur bra en förmåga mår mer än något annat?
Ja, det första svaret blir att det är svårt att peka ut något specifikt, att det varierar alltid,
om det liksom är kompetensen eller organisationen eller informationen, och att det, oftast
är det mer än en sak som gör att det inte fungerar perfekt om det inte gör det, och att det
är ett samspel mellan flera olika. Det kan säkert finnas fall rent specifikt, men då måste
man ju titta på ett exempel i så fall och se vilket är det just nu då. Det är väl, ja.
Har förmågan några inneboende egenskaper som kan påverka hur den mår?
Ta det en gång till.
Senast pratade vi om element kopplade till förmågan, som Process, Organisation osv. Tror
du att, förutom detta, förmågan har några egna, inneboende egenskaper som påverkar hur
den mår?
Jag tror inte jag förstår hur du menar faktiskt.
88
Finns det något du tycker är en egenskap hos förmågan snarare än ett element kopplat
till den, som påverkar hur den mår?
Så en egenskap, alltså, om vi säger, processerna, det är element som är kopplade till den,
det är inte egenskaper på förmågan?
Precis.
Vad är exempel på egenskaper då?
Det är vad jag undrar om du kommer på några.
Ja, kommer jag på nåt just här och nu då? Nej, men vi passar på den då.
Absolut. Finns det några element som påverkar förmågan och dess välmående mer än andra?
Då skulle man nästan behöva se hela listan då.
Du kan absolut få listan. Hela listan, eller de du kryssade för som relevanta?
Ja, då tar vi de jag kryssade för då.
Applikation; händelse; information; input; IT-stöd; kompetens; kostnad; KPI; Krav och
specialfallen Lag, Regel, och Policy; Organisation; Output; Process; Resurs; Risk; Roll; System; Tjänst; Värdeträd.
Och jag skulle svara på om jag tyckte att nån var mer viktig än nån annan?
Ja, precis. Är det några du spontant känner påverkar mer än någon annan?
Vad ska vi ta då, om det är en förmåga inom försäljning som är att Teckna försäkring,
exempelvis. Då måste man ha kompetensen för att kunna stötta informationen, processen,
nyckeltal. Ja, det blir en stor fråga tycker jag, att ta ställning kring då. Det beror ju på
vilken förmåga det handlar om, igen, tror jag, vad som är viktigast då. Men för att kunna
hantera en fråga, det är ju på något sätt grundläggande att det i alla fall finns en organisation med kompetens, om vi, alltså, det är grunden för att kunna göra det på rätt sätt,
med process och hitta information, det tycker jag är grundläggande, annars kommer man
ingenstans. Om man har en tom box, utan ansvariga, utan medarbetare, då blir det väldigt
svårt, man får sätta det, få det på plats först då. Det, även om vi liksom kan hantera
förmågor med hjälp av prylar, eller Internet of Things, så, på det sättet, så tror jag ändå att
nån måste då sätta upp hur det ska funka. Så kan man ju tänka vidare att det eventuellt
finns då anställda inom andra förmågor som ser till att den funkar, helt utan nån personlig
resurs, men det är väl lite längre fram tror jag, jag tror inte vi har så många såna förmågor
idag i alla fall.
Elementen, har något av dem några egenskaper som påverkar förmågan? T.ex. upptid
för ett system eller liknande?
Inom systemsidan?
Eller elementen över huvud taget.
89
Men inom en systemförmåga?
Snarare allmänt, oavsett förmåga. De här elementen, som man kan koppla till förmågan,
finns det några av dem som har egenskaper som påverkar förmågans välmående, som exempelvis om ett system påverkar så är det snarare systemets upptid som är viktig.
Jaha, vilka element har vi då?
Ska jag ta dem en gång till?
Ja, för då måste man ju svara per element, eller hur?
Ja, eller om du kommer på några ändå.
Ta en i taget då.
Applikation.
Mmh, vad är det för applikation, vad skulle det kunna finnas på den som är viktigare
än annat då, det är det som är frågan?
Ja, om det är något hos det elementet du tror specifikt påverkar förmågan.
Det är lite svårt att svara på så här, då får man nästan göra på papper, alltså dokumentera
då, i en matris då. Och det kanske andra får ta, som har valt att svara på det sättet då, för
det känns som att det blir lite svårt att få ut.
Respondent 4
Could not be reached for a second interview.
Respondent 5
Hur ser man om en förmåga mår bra eller inte?
Mitt problem är att jag känner att jag kanske inte riktigt kan det här med förmågebegreppen
då, eftersom jag då har fått fel ingång från början. Så att, ja. Så, för mig är det just det
här med matris-tanken. Det är ju lättare om man bara har en förmåga som finns på ett
ställe i verksamheten. Det är svårare om du har en förmåga som till exempel Utbetalning,
eller Betala ut, eller vad det nu heter, för det är ju en förmåga som finns på massor med
olika ställen, och då är det ju ganska svårt att bedöma om just, du måste du ju titta på så
många saker. Annars kan du ju målsätta förmågan, på samma sätt som man kan målsätta
en delprocess. Alltså, så tänker jag, fast jag vet inte om det är rätt. Om vi nu tar, kan du
ge mig nåt exempel på en förmåga som är singulär, finns på ett ställe?
Anställa personal, kanske?
Ja, och för mig är det då, då hamnar jag i den här svårigheten: ”är det en process eller är
det en förmåga?”. Det är det jag har lite, för när jag tänker process så tänker jag ofta in
mycket mer än bara själva flödet, jag tänker ju resurser och IT-stöd och allting. Men om
jag, i och för sig, så då kan man ju säga att, då kan man ju fundera på hur bra vi är på att
anställa personal, och då kan man ju i och för sig utvärdera processen på ett sätt, man kan
utvärdera de som gör det. Ja, nånstans måste man ju sätta mål, för att bedöma en förmåga.
Det är väldigt svårt att bara ”out of the blue” säga nåt. Eller också så kan man ju i och för
90
sig känna på sig ”men det här är ju vi nog jättebra på”, så då kanske man kan bedöma det.
Men det är lättare med förmågor som finns i en implementation, det är ju lättare än såna
som finns i flera, för då måste du ju faktiskt göra en ordentlig analys och tänka igenom.
Finns de något som du tror påverkar en förmågas välmående mer än annat, till exempel
av de här olika elementen?
Ja, det är ju ganska många. Det är ju de här standard, processer, resurser, alltså de som
utför processen, och hur de styrs, alltså om de förstår vad det är som är viktigt med den här
processen, och sen de eventuella stöd vi har, men jag menar, den kan ju fungera bra även om
vi sitter och gör allting för hand också. Så att det beror ju mer på hur man målsätter den,
men sättet vi gör det på och de som gör det, och de förutsättningar de har för att faktiskt
göra ett bra jobb, tror jag påverkar.
Finns det några egenskaper hos förmågan som påverkar hur den mår?
Ja, det är där jag har lite svårt att veta vad det skulle vara, är inte elementen delar av
förmågan, eller? Är inte processerna och resurserna och IT-stöden en del av själva förmågan?
Jo, du kan nog se det på det sättet. Annars kan man se det mer som att elementen är
länkade till och ihopkopplade med förmågan, men inte en del av den. Men det är okej att
inte kunna svara också.
Ja, jag tycker det är svårt, och jag känner att jag kan inte uttala mig om nåt jag inte förstår.
Elementen som kan påverka förmågan, har de några specifika egenskaper som påverkar den?
Finns det några specifika, som till exempel upptid för system?
Ja, jag vet inte om styrning är ett element, men jag tror ju att det är väldigt viktigt att, ja,
men, design och styrning av elementen måste ju vara viktig. Du kan ju stoppa in världens
bästa IT-stöd och jättekompetenta människor men inte få ut nånting ändå därför att du
inte har definierat, så nånstans kräver man ju, behöver man ju styrning, och uppföljning, av
förmågor också, tror jag. Även om jag tänker process så tror jag att det går att applicera
på förmågor också. Men det är ju det här att du måste veta vad du vill ha ut, återigen, du
måste ju ha nån typ av mål eller önskvärt 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 förmåga mår/fungerar bra eller inte?
Fanns initialt ”id-kort” framtagna per förmåga där det framgick. Nu pågår arbete med
att strukturera om förmågekartan och jag vet inte om de hunnit till den delen ännu.
Vad tror du påverkar en förmågas välmående mest?
Upptid för systemen hänger ihop med ”IT-förmåga” på en mer detaljerad nivå så där är det
väl viktigt. . . Om man ser på en förmåga ur ett affärs- och verksamhetsperspektiv (utifrån
målen kring nöjd kund och lönsamhet) så är det ett sammanlagt värde utifrån hur viktig
förmågan är för affären/verksamheten samt hur prestandan på den är. Där kan värdet ibland dras ner pga för långa ledtider, felaktiga resultat, otilräckliga resurser mm. Baserat på
hur viktig förmågan är viktas de olika bristerna då olika högt.
Finns det några inneboende egenskaper hos förmågan som påverkar dess välmående?
91
Tror jag berört detta i svaret ovan. . .
Av de elementen som är kopplade till förmågan, vilka tycker du påverkar förmågan mest?
Tror jag berört detta i svaret ovan. . .
Vilka egenskaper hos dessa element tycker du påverkar vilka egenskaper hos förmågan?
Har inte tillräcklig detaljkunskap på den tekniska nivån. . .
Respondent 7
Hur kan man se om en förmåga mår bra eller inte? Vad avgör hur den mår?
Ja, men man kan ju hitta mätetal, och mäta förmågan. Ibland, det värsta scenariot är
väl att man i verksamheten inte mäter, och då vet man ju inte om förmågan. Och då tittar
man snarare på vad det kostar i organisationen att driva en verksamhet. Det kanske inte är
så bra mätetal, utan kanske snarare hitta effektiva KPIer som visar på, liksom, vilka mål
man har, så man sätter målen på rätt nivå, och hela tiden har en förbättringsambition.
Finns det någor, tex några KPIer, som påverkar en förmåga mer än andra?
Hur menar du?
Kan du komma på några KPIer eller liknande som du tror påverkar förmågan och som
skulle vara bra att mäta för att se om den mår bra eller inte?
Jag kan, om du är ute efter exempel, liksom, i konkreta verkligheten..
Om du har några exempel, så absolut.
Ja, till exempel merförsäljning i försäljningskanalerna. En förmåga kring, säg att vi har
en förmåga i försäljning, och sen en underförmåga som heter merförsäljning, där kan det
vara bristfälligt, så att i vissa kanaler har man inte någon målsättningar kring merförsäljning,
men i en annan kanal kanske man har det. Och då kan ju det bero på att, dels kan det vara
naturligt så att man i den här kanalen inte är effektiv när man försöker sälja, kunden vill
inte. Men det kan också vara så som det vi upptäcker här, vi har ett projekt i Folksam,
där vi inte har några verktyg för att sälja, för vi ser inte kundens helhetsengagemang. Och
då vet vi ju inte vad vi ska erbjuda heller. Och då har man inte satt upp mål där, i den,
i det här exemplet, att just i den här kanalen så har vi inte säljmål på de här delarna då,
det gäller vissa produkter då. Och det är brister i systemstöden helt enkelt. Det är bara
sånt som jag stött på här, men det är ju många andra, jag är ju mycket säljinriktad som
arkitekt, och jobbar mycket med försäljning och marknadsföring, mycket digital försäljning,
där mäter man ju, det finns specifika mätvärden som man mäter på. Och då vet jag inte
hur det är just här på Folksam, så jag ska inte ta de exemplena, för jag har inte jobbat inom
digital utveckling här.
Tror du att det finns några egenskaper hos förmågan som påverkar dess välmående?
Jag tror det är snarare så att det är de som är kopplade till förmågan, därför att förmågan
i sig är mer en abstraktionsrubrik. För mig är det så i alla fall, att det är snarare man får
titta på ”Vad är det i förmågan som..”, utan jag vill snarare härröra mig väldigt strategiskt
eller högt uppe när jag pratar förmågor. Och sen när man går in i praktiken och analyserar
92
som arkitekt, då tittar man ju verkligen på ”är det organisation, eller roll, eller process,
logisk arkitektur, eller, vad är det för nånting?”.
Av elementen kopplade till förmågan, tror du att några påverkar förmågans välmående mer
än andra?
Ja, styrmodellen, tror jag. Därför att styrmodellen spiller över på de andra delarna, hur du
sätter upp din organisation, hur du mäter förmågan, hur du kravställer mot IT för nya stöd,
det tycker jag nog är, det är nog liksom det som går, i mitt huvud direkt så här, det är nog
det som går först.
Finns det några egenskaper hos dessa element du tror påverkar förmågan mer än andra?
Till exempel upptid för ett IT-system.
Ja, jag tror att det är mycket kring, lite egenskaper för processen då, eller fördjupningar av
processer, där man gör dubbla, man gör upprepade, dubbla aktiviteter. Du har ett manuellt
arbetssätt att koordinera, till exempel, mellan olika system, eller olika silos, och det blir
merarbete, och det är väldigt ineffektivt. Så att du har inte automatiserade flöden, så att
när du gör en sak, då har du transparens ut i applikationer och system, du behöver bara
göra en gång eller så går det med automatik. Här i vår moderniseringsresa så innebär det ju
att du gör massa saker flera gånger, du har dubblerade informationsmodeller i olika system,
så att tolkningar, koordineringar, det tror jag. Välmående, sen i övrigt, ja, men tolkningar,
att man har olika informationsmodeller i förmågan beroende på att man har historik när
man har utvecklat parallella IT-landskap för olika produktområden till exempel, det, ja.
Något att tillägga?
Nej, jag tror att det var det. Ha greppet om förmågan, om du vet innehållet i den. För jag
tror att du, ibland beskriver man förmågan men man missar halva innehållet för att man är
inriktad på ”ja, men nu jobbar jag med det här initiativet” att det blir lite för långt ner i
organisationen, man jobbar på projektnivå med en förmåga, då vill man bara scopa in det
här, ja, men hela förmågan då? Om du konsoliderar allting som är i det området, så kanske
det blir ett annat perspektiv på hur bra den mår. Just det här att man jobbar silos, det
tänker man inte alltid på, det är viktigt som arkitekt att just förmågan 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 förmåga mår bra eller inte?
Kan man se om en process mår bra, eller nånting annat? Det vet inte jag. Men jag kan
inbilla mig att, som med mycket annat, för att veta nånting om det så måste man mäta, nån
form utav framsteg eller progress, utifrån KPIer, beroende på vad det är man vill uppnå.
Det är det enda sättet tror jag. Det andra är den här typen av intervjuer, men de tycker
jag inte du ska lita på. Men mäta, alltså, införandet av förmågor, när man har infört dem,
hur de mår, det borde ju gå, tycker jag, teoretiskt i alla fall.
93
Finns det något du tror påverkar hur bra en förmåga mår eller fungerar mer än något annat?
Alltså, det här med förmågor, det har vi ju framför oss, det vill säga vi pratar om ett
förändringsarbete. Jag tänker så här, när man ska driva in nånting, det är liksom i en
utvecklingsfas då, då måste man utgå från det här med vilken mognadsgrad vi har då, och
vi är ju bara i början där. Så en grej som påverkar väldigt mycket är vilken acceptans vi
har för förmågesynsättet. För har vi inte det så kan vi inte arbeta med förmågor. Och det
är ungefär där vi är just nu. Sen när man har infört det så är det en annan sak då. Jag vet
inte om det var ett svar på frågan, men det är liksom en förutsättning för att en förmåga
ska kunna existera och må bra. Så ser jag på det.
Kan en förmåga ha några inneboende egenskaper som påverkar hur den mår?
Säkert, men det är ingenting jag kommer att tänka på.
Är det några av elementen som du tror påverkar hur förmågan mår eller fungerar mer
än några andra?
Kan du repetera snabbt vilka det var?
Absolut. Applikation, som är stödjande. Information. Input, IT-stöd. Kompetens. Kostnad. KPI. Krav, lag policy. Organisation. Output. Process. Resurs. Risk. System. Tjänst.
Värdeträd.
Det var svårt. Men som påverkar mer?
Precis. Är det några du känner sticker ut och påverkar mer hur förmågan mår eller
fungerar?
Ja, Organisation, och med det menar jag tydlighet i ansvar i organisationen, till exempel
mellan funktion, process, och förmåga. Och jag tror att det är väldigt svårt att åstadkomma
det, så jag tror också att just det här med mål och mätetal, om man kan börja mäta på
förmågan. Så Organisation och Mätetal, att få det att lira ihop för att utveckla och följa
upp förmågan, hur den mår eller progressen i den, det tror jag är viktigt.
Finns det några egenskaper hos elementen du tror påverkar mer? Exempelvis kanske upptid för ett system.
Det är ju en komplex organisation, och förmågan vill jag ju se som att den skär igenom
organisationen och det vi gör, för att uppnå det som är viktigt, det vill säga vad. Och då
tror jag att det är en utmaning. Och nu sa jag mätetal, KPIer, då tror jag att man får tänka
till, så att de KPIer som man sätter, dels att man sätter dem rätt, och sen att vi utvecklar förmågan att följa upp det. Det är lätt att man utvecklar någonting, i det här fallet
förmågor, och sen lägger man mycket energi på det, och sen utvecklar man ett mätsystem,
och sen rasar det mellan fingrarna för att man orkar inte hålla i, orkar inte följa upp. Man
måste ha ett, för det här är svårt, om man ska skära ut förmågan, få acceptans för det,
och sen mäta och följa upp så vi når de resultat vi vill. Då tror jag vi måste verkligen ha
tryck i den frågan och acceptans från högsta ledningen, och lyckas koppla till organisation
som ska utföra då någonting, så vi når det vi ska mäta. Det tror jag är väldigt viktigt, att
man tänker till där. Det får inte vara heller ett teoretiskt ramverk, för det är lätt, som du
intervjuar mig nu, så blir det ju väldigt mycket mer teori, utan det måste vara någonting
som organisationen kan hantera, utifrån den mognadstrappa där vi står just nu, där vi är
94
ganska långt ner. Så man får inte bygga ett teoretiskt ramverk som vi inte kan rå på helt
enkelt, vare sig ledningen eller organisationen då. Jag tror på att mäta, jag tror att vi måste
tydliggöra relationen mot organisationen som ska gör nånting kring det här, det tror jag är
viktigt.
Respondent 11
Hur tycker du att man kan se om en förmåga mår bra eller inte?
Oj. Det var ju en svår fråga.
Känner du att du inte kan svara får du säga det också.
Jo, nej, men nåt svar måste jag ju kunna ha, eller en fundering. Det finns väl olika sätt,
känns det som. Och att det kanske är någon form av sammanvävd bild som ger svaret.
För, alltså, dels så kan man ju nånstans säkert mäta, beroende på vad det är för förmåga vi
pratar om, men liksom, ”Hur många, vad det nu är man hanterar, klarar vi av att hantera
per tidsenhet?”. Och är det nånstans i paritet med vad man har som mål eller som branschen gör eller så där, så kan man ju tycka att, ja, då mår den ju bra på ett visst sätt. Men
sen måste man ju få in, de som jobbar, med den här förmågan, kanske är frustrerade över
nånting. Och det kan vara olika saker, systemstöd eller att det är nåt knasigt i processen,
eller så där. Så, jag tror att det är svårt att se, liksom, på en gång, ”Den här förmågan
mår inte bra”, jag tror man måste dela upp det i liksom, nån form av, process, organisation,
system, kanske nåt mer, och liksom försöka förstå, är allt grönt, så kanske förmågan mår
väldigt bra. Sen kan det säker vara nåt som är rött, men det mår ändå nästan bra för
vi klarar av det genom en heroisk insats, liksom. Då kan man ju fundera på vad som är
viktigast, liksom. För levererar man efter det man borde kunna göra så kan man ändå säga
att den mår ganska bra. Det är ett svävande svar, men ja.
Finns det något som påverkar en förmågas välmående mer än annat?
Ja, jag tror att.. Vilken svår fråga. Jag tror nog mycket, alltså, hur, det är inte den
enda sanningen, men, de som, så att säga, utför arbetet, hur de mår och tycker att det
fungerar tror jag är ganska centralt. Sen så kan ju de vara inkörda på, liksom, sneda spår,
och liksom, det går att göra, när man liksom börjar skrapa på ytan så inser man att ”Den
här förmågan mår inte så bra”, även fast de är jättenöjda för ‘’det flyter ju jättefint och bra”.
Me å andra sidan, är det nåt som inte funkar så kommer ju de vara, liksom, då kommer det
ju märkas. Men sen så tror jag väl, det tror jag är en sak, och sen så tror jag väl att, alltså,
stöd, om det är, liksom, IT i form av hårdvara eller mjukvara, eller om det är nåt annat, ja,
men, liksom, ja, stöd i det arbetet, det tror jag också är väldigt viktigt.
Tror du att det finns några egenskaper hos förmågan som påverkar hur den mår?
Kan du ge nåt exempel på..?
Nja, vi kollade ju på det här med element som kan påverka, element som är kopplade utifrån,
så det här är mer om hur ni tycker att förmågan har några egenskaper som är dess egna
snarare än kopplade till den, som påverkar hur den mår.
Jag försöker också fundera på vad.. Spontant så skulle jag ju säga, eller tycka, jag kommer
inte på nåt bra.
Det är också ett svar.
95
För det är väl lite min åskådning, att det är olika typer av komponenter som gör att man
gör någonting, och det är de tillsammans som bildar den här förmågan.
Är det några av elementen vi pratat om tidigare som du tror påverkar förmågan och dess
välmående mer än andra?
Vad blir skillnaden där mot förrförra frågan?
Den var mer en chans för er att prata allmänt, nu är det mer specifikt vilka av elementen
det kan röra sig om.
Har du listan över vilka jag klickade som relevanta?
Absolut. Applikation, dels stödjande och som stöds.
Ja, det tror jag ju. Frågan var om det var någon som var extra viktig?
Ja, precis, om det är någon som påverkar mer än andra. Alla kanske påverkar på något sätt
eftersom de är kopplade till förmågan, men vissa kanske är mer avgörande för förmågans
välmående.
Det känns ju som att det beror på vad det är för förmåga man pratar om. Men Applikation tror jag är centralt, i de flesta. Det är få förmågor, finns säkert en del, men de flesta
har ju någon form av systemstöd.
Information?
Ja, det tror jag går åt skogen om man inte har bra information.
IT-stöd?
Hänger ihop med Applikation.
Kostnad och KPIer?
Och är det alltså kostnad för att utföra förmågan?
De kostnader som är associerade med förmågan, ja.
Den tycker jag ju då kanske inte är lika viktig ur ett välmåendeperspektiv, för jag tror
att förmågan kan må jättebra, även fast det kostar för mycket pengar.
KPIer?
Ja, alltså, där handlar det ju mer om att förstå om den mår bra, men jag tror, det är
ju inte nödvändigtvis så att den mår dåligt, även om vi inte kan påvisa att den mår bra. Så
nej. Däremot så tror jag den är viktig för att kunna fintrimma förmågor, men det är inte
centralt för att den ska kunna må bra.
Krav, och specialfallen Lag, Regel, Policy?
Nej, den tror jag också är lite så där, det är centralt om det visar sig att förmågan inte
mår bra, för då måste man göra nånting. Men det kan ju vara så att den funkar jättebra
96
även fast vi har jättedålig koll på kraven, därför att de människor som håller på med det
här faktiskt vet vad de gör.
Organisation?
Ja, det är ju viktigt, av samma anledningar som jag sa där i början, jag tror att de som gör
det behöver tycka att det känns bra.
Process?
Ja, den tror jag är viktig.
Risk?
Ja, vad menar vi där, egentligen. Nej, den tror jag, alltså, det känns också som en sån
här, mer kontroll. Det har egentligen ingenting med hur bra den mår, utan det handlar ju
om hur vi sköter den.
System?
Hänger ihop med Applikation och IT-stöd.
Tjänst?
Nej, den känns inte som att den riktigt passar in.
Värdeträdet?
Ja, alltså, om det är så att man inte kan mappa en del av väredträdet till förmågan, då
borde man ju ifrågasätta varför vi har den förmågan, givet att värdeträdet är komplett. Sen
kan ju förmågan må väldigt bra, även om det är en redundant förmåga. Så ur det perspektivet tycker jag inte den är viktig. Det ärju lite som KPIerna, alltså den behövs inte för att
förmågan mår bra, däremot är det viktigt att förstå hur den passar in i vårt värdeskapande.
Har några av elementen egenskaper som påverkar förmågans välmående? Exempelvis kanske
upptiden hos ett system.
Ja, alltså, det tror jag. Mycket just kring, om man knyter tillbaka till den utförande organisationens väl och ve, är ju ofta tätt sammankopplat med, alltså, att sytemstöd eller stöd
fungerar friktionsfritt. Att det är uppe, att det är snabba svarstider, att man inte får felmeddelanden man inte borde få och liksom skapar irritation i det där, utan att man förväntar
sig att få ett stöd, och det får jag. Så, alltså, den typen av tekniska förutsättningar, som
inte har med, liksom, det mer specifika förmågestödet att göra utan snarare vad alla tycker
är hygienfaktorer, det tror jag har väldigt stor påverkan.
Respondent 12
Hur kan man se om en förmåga mår bra eller inte?
Då måste man ju veta var den finns implementerad, alltså vilka processer. Och processerna
kan man ju alltid mäta och förstå hur effektiva de är då. Så på så sätt så ser du ju om
förmågan mår bra eller dåligt.
Vad tror du påverkar en förmågas välmående mest?
97
Jag tror att det är en definition ”Vad är en välmående förmåga?” som man måste fundera på. Betyder det att vi kan utföra den? Betyder det att den är effektiv? Beroende på
vad du lägger för dimension i, alltså, och det är ju fortfarande, om vi gör en förmåga som
vi inte har ett enda systemstöd för, mår den dåligt då? Det behöver den ju inte göra.
Har förmågan några egenskaper som kan påverka hur den mår? Som inte är element kopplade till den utan egenskaper hos den.
Ja, alltså, en förmåga. Ja, det beror ju på vad man menar med element kopplade. Tänker
du på regelverk, är det ett element som kopplas till?
Ja, det skulle jag säga.
Ja, för beroende på hur, ja, yttre krav och inre krav på en förmåga, så är ju det hur
lätt den är att applicera, skulle jag vilja säga. Och då är det väl kanske, det kan ju vara
lagkrav det kan vara interna mätgrejer som gör att den är helt hopplös.
Elementen kopplade till förmågan, är det några som påverkar förmågans välmående mer
än andra? Jag kan läsa upp dem om du vill.
Ja tack. Har du gjort nån definition på vad det betyder ”att må bra”?
Nej, det är det jag frågar er nu i de här intervjuerna.
Ja, för dels så kan man ju säga, det är ju liksom, hur väl förstår vi hur den ska funka,
hur väl har vi förberedda processer för den, både digitala och manuella. Det är, om man
säger, att den mår bra. Ja, vem är det som bedömer att den mår bra? Känner vi att vi
förstår den eller att vi kan utföra den, mår den bra då? Alltså, man skulle nog behöva ha
en liten definition på ”att må bra” tror jag. För det kan vara så här ”vet jag vad jag ska
göra, ja då mår den bra”, ”vet jag hur jag ska göra det, ja då mår den ännu bättre”. ”Har
jag inget systemstöd utan gör allt manuellt, då mår den ganska dåligt”, eller? Det är tycke
och smak, så jag tror att man måste tala om litegrann vad man menar med ”att må bra”,
eller att det kan vara olika grader av bra då.
Okej. Nu, vill du ha alla element eller de du kryssade för som relevanta?
Läs upp alla. För nu var frågan vilka som påverkade?
Ja, om det är några som du tycker påverkar förmågans välmående mer än andra. Applikation, stödjande och som stöds. Händelse. Information. Input. IT-stöd. Kompetens.
Kostnad och KPI. Krav, och specialfallen Lag, Regel, och Policy. Organisation. Output.
Process. Resurs: Risk. Roll, System. Tjänst. Värdeträd.
Vilka som får den att må bra?
Ja, om det är några du tycker sticker ut och påverkar mer än andra.
Ja, det är regler, då, det är ju en , och processer är en. De två skulle jag ju highlighta.
Har elementen några egenskaper som påverkar förmågan välmående? Tex kanske upptid
hos ett system.
98
Altså, det är ju, kompetens och kunskap om förmågan, det är ju det som är A och O.
Om vi inte har kompetens runt vad det här innebär eller hur man ska göra det här, vad det
nu kan vara för någonting, då mår man ju riktigt illa.
Något att tillägga?
Det som man bör tänka på är att förmågan i sig, den bor ju i ett kontext. Så det är
svårt att säga, ja, ”hallå”. Utan det är ju allting, jag menar, har du ingen, för att utföra
det här, din förmåga, vad du behöver göra, då måste du ju ha både resurser och processer
och eventuellt systemstöd då, och sen beror det ju på hur komplex den där är, på vilket sätt
du måste ha stöd. Så om man skulle gå och fråga en verksamhet så här ”Var gör det ont
hos er?”, ja då kommer de säga ”Det gör ont här, för vi vet inte hur vi ska göra”, eller ”Det
gör ont här, för det tar så jädra lång tid’, så det är ju det, därför tror jag att det är bra om
man försöker definiera ”Hur mår en förmåga?”, ja, ur vilket perspektiv?
99