Vad gör en verksamhetsarkitekt?

Vad är verksamhetsarkitektur?

För att kunna förklara vad en verksamhetsarkitekt gör behöver vi först klargöra vad verksamhetsarkitektur är.
Med verksamhetsarkitektur avses verksamhetens struktur, alla delar och hur de interagerar, samt gränsytorna mot omgivningen; kunder, leverantörer, partner mm. Verksamhetsarkitekturen beskriver vilka förutsättningar som finns i verksamheten, vilka förmågor verksamheten har, hur verksamhetens processer ser ut samt vilka informationsresurser och IT-stöd som hanteras i verksamheten. Med en väl dokumenterad arkitektur har vi en gemensam bild av verksamheten och en bra grund för beslutsfattande och effektivisering av verksamheten.

Varför verksamhetsarkitektur?

Syftet med verksamhetsarkitektur är att möjliggöra en snabb och enkel verksamhetsutveckling, åstadkomma hög informationskvalitet samt att se till att rätt system stödjer verksamheten.

Verksamhetsarkitektens uppgift

Verksamhetsarkitektens uppgift är att (skapa?) och synliggöra/beskriva strukturen så som den ser ut, de värdeströmmar som finns, att visualisera målbilder och alternativa scenarios samt att ta fram en plan för hur vi ska kunna nå det önskade läget. I den nödvändiga, ständigt pågående, verksamhetsutvecklingen är verksamhetsarkitektens roll central för en innovativ och lättrörlig organisation. Verksamhetsarkitekten knyter ihop olika initiativ till verksamhetsutveckling och IT-satsningar i den riktning som verksamheten strävar.

Verksamhetsarkitektens verktyg

Verktygen verksamhetsarkitekten använder för att skapa bilden av verksamhetens delar och inbördes samband, är ofta olika typer av modeller. Det kan exempelvis vara processmodeller, informationsmodeller, förmågekartor, organisationsscheman eller systemkartor. Modellerna visar verksamheten utifrån olika perspektiv.

Vintergatan

IRM har arbetat fram en modell som vi kallar Vintergatan. Vintergatan är ett exempel på en förmågekarta som rymmer alla olika verksamhetsperspektiv i en och samma karta. Med kartan som underlag gör verksamhetsarkitekten en mängd olika analyser för att kunna se effekterna av olika typer av scenarios.

Utbildning

IRM har utbildat verksamhetsarkitekter sedan 1989. Tillsammans med DF Kompetens levererar vi utbildningen Certifierad Verksamhetsarkitekt. Sveriges största utbildning inom området.

Boktips

Vintergatan – din verksamhetskarta av Cecilia Nordén Visualising

Enterprise Design Patterns av Wolfgang Goebl, Milan Guenther, Annka Klyver och Bard Papegaaij

How to develop a Sustainable Digital Platform

By Eskil Swende and Svein Oliver Vedaa, IRM,

“The digital world is here but our old companies are simply not yet designed for digital.”
  – stated by Jeanne Ross in her new book “Designed for Digital”

The article below is based on our assistance since 2016 to the Data Architect at Cambridge University and their global assessment business. It is also based on our experience of more than 50 Business Architecture Plans developed for both Private and Public businesses in Scandinavia starting at Scandinavian Airlines (SAS) in 1980.

The development of our approach was inspired by the Swedish Professor Bo Sundgren and his close relationship with Ted Codd; the British mathematician that developed the Normalization Theory, that still is very important to achieve the sustainability in your IT Portfolio.

The authors Eskil Swende can be reached at eskil.swende@irm.se and Svein Oliver Vedaa at svein.oliver@irmconsult.no both looking forward to your comments!

1 Introduction

Your business may need to develop a new digital platform to replace your existing application-centric IT solution. Your current application portfolio may have reached a size and level of complexity that is expensive and difficult to develop further. You are then on a non-sustainable track. If you want your new digital platform to be sustainable, you have to be very careful and understand the capabilities needed to achieve such a sustainability.

This article does not cover the Information Technology needed to establish a Sustainable Digital Platform.

2 Why sustainability

In our rapidly changing environment the business, need to be agile. Our new digital platform must allow for changes in the Organization, the Business Processes and the Capabilities when new products or services are developed, and even when new strategies are decided.

A Digital Platform based on a high-quality Information Architecture is sustainable and flexible, allowing these changes to be made without adding complexity. Your Digital Platform will consist of a number of modules, where the same data is only captured and updated in one and only one module.

Allowing the same data to be captured in more than one module, may after a few years result in the same “unsustainable level of complexity” as your current IT systems have reached after 20+ years of application-centric development. (Further reading see 8.1)

3 Achieving sustainability

In your business, you may have 10.000+ different data elements like customer address or product price. To group these data elements into the correct module must not be done randomly. Together with your business experts, you, as an architect, must establish a number of Information Groups – say 30-50 groups, divided into Master Data like Customer, Personnel or Product and Event Data like Customer Order, Delivery or Supplier Invoice. (Further reading see 8.2)

Your information architecture must be based on your business, and not derived from your IT solutions. Your current IT solution came with an architecture often deviating from the one in your business.

The Business Model Canvas developed by Alexander Osterwalder is based on Building Blocks that easily can be related to your Information Groups. A new Value Proposition may reuse existing Building Blocks and existing Modules in your Digital Platform. This will add speed and keep complexity and Integration at a low level. (Further reading see 8.3)

Designed for Digital is a new book by Jeanne Ross, written for management to understand the importance of the digital transformation and to leave the application-centric legacy systems behind us. She was also co-author of EA as Strategy; the first management book to describe Business Modularity based on shared data. (Further reading see 8.4)

4 Consequences

A new sustainable digital platform has to be built from scratch. The existing legacy systems have to be eliminated step-by-step, and replaced by modules in a new digital platform. The current legacy system cannot be transformed into a digital platform in a step-by-step approach.

5 The Architecture and Development Cooperation

You will need a loose coupling between application and data. No application will be allowed to own its own data. Data is a common resource and will be available for all applications. Data bases will be designed and implemented based on the Information Groups.

You should establish a number of autonomous Development Teams. Spotify has several hundred teams working in three continents. You will need a number of teams to take care of applications and Information Groups. One team can have responsibility for one or more applications and one or more database (based in Information Groups). However, responsibility for one application or one database (Information Groups) must not be divided between teams. 

The development teams will have to work in close cooperation with the Business Architecture Team including Data and Process Architecture.

The autonomous development teams (Scrum) delivers speed and quality, the Business Architecture Teams secures direction, and a sustainable solution prepared for future changes. The Business Architect will support Development Teams, but also further develop the overall architecture. (Further reading see 8.5)

The Business Information Models are the key artefact to combine the Development with the Business Architecture. The Overall Business Information Model shows the total Digital Platform and the Detailed Business Information Models show the structure of each module.

One development team may be responsible for one Master Data Module like “Customer” or an Event Data Module like “Delivery”. An Event Data Module will be related to your Business Processes like the “Delivery Process”.

6 Ten Critical Success Factors

Many IT-managers, CIOs and CEOs agree that the old application-centric approach does not support a digital world. However, the transformation is very difficult and there is no guarantee for success. There are a number of very critical success factors (CSF) to handle when developing your future Sustainable Digital Platform.

Below we have listed and described some of these very critical success factors. You may try to evaluate them, discuss them, and start the transformation process being fully aware of which CSFs are most critical in your own busines

1. Executive level support

Develop a new sustainable digital platform; in order to achieve speed and high quality when delivering new customer values, will require full support and understanding from your executive management, all the way from the IT Manager and CIO to the CEO and the Board. Do not hesitate to keep them informed, and at the same time develop their capabilities in an area where they so far are not the experts.

2. Internal and external forces working against the digital transformation

In your business, you have many highly qualified people that daily depend on a set of application-centric solutions. A transformation from this old approach to something new, may cause a lot of internal fear and resistance. Try to engage them in the transformation and make them understand that the digital transformation is necessary for the survival of your business. Keep them informed and try to develop their capabilities. The Milky Way, described below, is a good way to engage everyone.

3. Financing the digital transformation

Long-term and stable financing of the Digital transformation is important. At the same time, you should reduce financing of the current legacy systems to a minimum – only covering very critical adjustments. When you finance your digital transformation, it is important to avoid sub optimisation that will lead to new application silos. Building on a common Business Architecture with a quality Information Architecture does not imply any common expensive infrastructure – it just stops you from financing redundancy and unnecessary complexity. 

4. Culture change

The hierarchical organization can be transformed into more self-organizing teams. Today the main knowledge exists down in the organization and less at the top and middle level. This transformation of decision-making must be aligned with a change of mind-set in the organization. IKEA is a global successful business based on a number of common culture principles established already 1976 by Ingvar Kamprad. Microsoft and the new CEO Satya Nadella is a current example of such a transformation of culture and new business model that goes hand in hand. (Further reading see 8.6)

5. Autonomous development team

Autonomous development teams with responsibility of both development and operation, makes it possible to deliver new customer values continuously, whenever they are ready to be released. In the classic application-centric approach a new release is risky and may take hours or days to accomplish, and will only happen a few times a year.

The autonomous team approach was first developed by Henrik Kniberg at Spotify and later also introduced at LEGO. Now it is widely introduced, at least in Scandinavia.

SBAB, a Swedish Bank, has established a number of development teams also responsible for the operations, called ”Dev-Ops” teams. It took them only one month to have a new product on the market and their market share grew in one year from 9 to 17%. So far, they have got rid of 50% of their old integration making the business very agile. The teams are very close to the market and deliver new customer values every day.

6. The Milky Way – map, navigate and accelerate change

The Milky Way is a method and navigational tool showing the work of the entire enterprise and how to move from strategic considerations to results. The tool demonstrates how processes, information and IT support work together to support the company’s value stream, and how the company interacts with its suppliers, partners and customers. It uses geographic maps as a metaphor to illustrate why and how an enterprise work. Building Milky Way models is largely done in workshops, where it becomes clear how different parts affect each other and how change initiatives can be coordinated. (Further reading see 8.7)

7. Common Information Model

Today many applications have their own data structures based on local data definitions, some of them are expressed explicitly, but most are only implicit. To make the transformation to a sustainable digital platform we need a common Overall Business Information Model (OBIM) divided into a number of Information Groups; some are Master Data, like customer or product, and some are Event Data like customer order, invoice or delivery. We call it an Information Model when it describes the business itself and a Data Model when it describes a specific IT Solution (existing or planned). These Information Groups are an important part of the information architecture. They are keys in design and planning to avoid data to be captured and managed by more than one development team. This avoids unnecessary duplication of work and solutions, and it saves complexity and money. Members of DAMA Chapter Scandinavia developed the OBIM approach in 2010.

8. Integration

The integration between the various Service Modules must be based on the Service Choreography approach with an Event Stream. Read more at https://specify.io/concepts/microservices#choreography.

An Orchestration approach may after a few years result in the same complexity as you have today, and it will not result in a sustainable digital platform.

9. Process Components and Processes/Capabilities

Today we have to provide a Process & Capability Architecture that works in large companies that may have development, production and deliveries of IT solutions in several countries.

Avoiding redundancy is necessary in order to achieve effectivity. We need to combine both reuse of solution at the same time as we offer easy adoption to local conditions. A set of Common process components will handle a well-defined part of the total business flow. They should be easily combined in many different ways where changes can be handled fast. This will create flexibility and a more agile business.

10. Application Lifecycle

To be able to replace existing applications, we need a good description of our application portfolio (both legacy and new). Stages in their lifecycle may be; 1. Under development, 2. Installed to be finished, 3. Installed and finished 4. To be replaced and 5. Planned to be replaced. To keep track of which Information Groups are handled in each specific application is a key factor to facilitate the transformation.

7 Summary – The Inca Foundation and your Platform Foundation

When building a sustainable house, the foundation is the most critical part. The Inca people learned that the hard way. Their foundation stones were cut so precisely, and wedged so closely together, that a credit card cannot be inserted between them. When an earthquake occurred, the stones in an Inca building are said to “dance;” that is, they bounce through the tremors and then fall back into place. Without this building method, many of the best-known buildings at Machu Picchu would have collapsed long ago.

When creating a sustainable Digital Platform, the foundation consists of a number of Information Groups; they will not dance when the “earthquake” happen. Instead, you may just add or take away a data element or an entity. You may even have to add or take away an Information Group. Then you may change the Platform to achieve new requirements needed to continuously deliver your new customer value.

To establish a Platform Foundation Capability may take some time. If you need any assistance, we may offer mentoring, education, second opinion or direct support; just send a mail to Svein Oliver Vedaa (svein.oliver.vedaa@irmconsult.no).

8 Further reading

Below we recommend some further reading.

If you do not know the reasons why we have a lot of problem with our current legacy systems, Dave McComb has made an excellent analysis in his book. You may also find an interview with him in TDAN.

Knowing these reasons will motivate you not to repeat these mistakes again!

  1. Software Wasteland – How the Application-Centric Mind-set is hobbling our Enterprises”, 2018, by Dave McComb. Know what´s causing application development waste so you can turn the tide.
  2. Overall and Detailed Business Information Models – Developed by the DAMA Chapter Scandinavia in 2010. http://tdan.com/defining-and-naming-data-models-related-to-the-zachman-framework/12655
  3. Business Model Generation – By Alexander Osterwalder in 2010. His Business Model Canvas (BMC) is very important when designing a new Sustainable Digital Platform
  4. Designed for Digital – How to Architect your Business for Sustained Success, by Jeanne Ross, 2019, also co-author of “EA as Strategy”. The Digital World is here but our old companies are simply not designed for digital.
  5. Agile EA in Practise – At Swedish Board of Agriculture (SBA) published in JEA, 2015, https://www.irm.se/2018/09/27/agile-in-practice/. This ambitious program at SBA may be regarded as a global breakthrough to achieve an Agile EA in Practice with the Chief Architect acting as the Program Manager.
  6. Hit Refresh – The Quest to Rediscover Microsoft´s soul” by Satya Nadella, CEO, 2017. He asked everyone to identify their innermost passions and connect them to the new mission and culture.
  7. The Milky Way – map, navigate and accelerate change – By Cecilia Nordén, 2019. It uses geographic maps as a metaphor. The work is largely done in workshop form, where it becomes clear how change initiatives can be coordinated and how to move from strategic considerations to results.

9 Your feedback!

So far, we have a lot of very useful comments, questions and feedback from our global network of experts.

Please, do not hesitate to mail us your comments, questions or other feedback on this article.

Our next article on “How to develop a Sustainable Digital Platform” will focus on the Information Modelling and Information Architecture including a number of example of Information Groups from various types of Business. Please send us your email address and we will mail you our draft before publishing.

Svein Oliver Vedaa: svein.oliver.vedaa@irmconsult.no

Eskil Swende: eskil.swende@irm.se

10 Bios

Eskil Swende, IRM Sweden

Eskil is a co-founder of IRM Sweden in 1982, a Scandinavian consulting company focusing on Business Architecture. He initiated the education of Certified Business Architects already 1991 and so far 1500+ Architects has been educated. He is now focusing on the business use of new technologies like digital development. Eskil has been mentor to the Data Architect at Cambridge University and their assessment business since 2017. It has resulted in an approach “How to Develop a Sustainable Digital Platform”. Our article is based on this approach. Eskil started DAMA Chapter Scandinavia in 1995 and was their President until 2016. He is also a co-founder of IRM UK and  has developed a global network of leading expert of EA. Eskil has written a number of articles for TDAN since 2008.

Svein Oliver Vedaa, IRM Norway

Svein Oliver founded IRM Norway in 2000. Already as a University student in the 80s, Svein Oliver was interested in data and information as the core of value creation within IT. Despite all the brilliant technology that has emerged since then, data and information must still be managed as a resource to fully exploit its value. He believes fully that we must start with architecture to accomplish this. Today he focus on architectural debt (inspired by the theory of technical debt) with the goal of designing sustainable digital platforms. Svein Oliver has participated in many business architecture projects, many of them in the Oil & Gas industry. The ground for a sustainable digital platform will be described in more detail in our next article for TDAN.

Download the article

Processutveckling- inte bara processer

Processutveckling handlar inte bara om processer. Syftet med processutvecklingen är ju att utveckla vår verksamhet, och tittar man närmare på en process så innefattar den så mycket mer; processen är en del av en verksamhets förmåga, den styrs av regler och är beroende av information i olika former och allt som oftast är det människor inblandade.

Så låt oss lyfta blicken och se det som den verksamhetsutveckling det är när vi snackar processutveckling.

Många av våra kunder vänder sig till oss när de behöver komma loss från gamla stela arbetssätt och system. Det kan upplevas som svårt att rulla ut på rätt bana för att nå sina mål och att realisera nya idéer.

9 checkpoints

För att veta att vi är på banan har vi identifierat 9 avgörande checkpoints längs utvecklingsresan:

  1. Vi vet varför vi beskriver våra verksamhetsförmågor eller processer och vad vi vill uppnå med det.
    Ett par frågor som ofta kommer upp inför ett utvecklingsarbete är: Varför gör vi det här? Kommer de metoder och arbetssätt vi har valt verkligen att ta oss dit vi vill?De är bra frågor, som tyvärr oftast tappas bort när man väl är igång med utvecklingsarbetet. Glöm inte; vi måste kontinuerligt ifrågasätta varför vi gör vi det vi gör – under hela utvecklingscykeln.
  2. Vi beskriver så mycket av vår verksamhet, omfattning såväl som djup, som syftet ställer krav på. Inte mer, inte mindre
    Är det en övergripande bild vi behöver? Eller är det detaljerade djupdykningar i specifika processer? Vad vi ska uppnå styr detaljgraden. Ett tips är att börja med att snabbt få upp en helhetsbild över verksamheten, t.ex. i form av en förmågekarta/Vintergatan och att därefter beskriva processflöden och informationsbehov för de mest prioriterade områdena.
  3. Vi har syftet i tankarna när vi kommunicerar vårt utvecklingsarbete; vem ska förstå och varför ska personen förstå våra verksamhetsbeskrivningar? 
    Gör arbetet visuellt och lätt att förstå. Använd verksamhetens eget språk och synliggör gärna synonymer så du når ut brett.
  4. Vi ser till att individerna känner igen sig i verksamhetsbeskrivningarna. Detta gör vi genom att involvera människor.
    När det gäller processer är det också viktigt att vi fokuserar på processernas resultat och vad detta resultat i nästa steg ska användas till. Det leder till en starkare känsla av delaktighet. Att som individ få vara med och skapa ett resultat föder så mycket mer engagemang jämfört med att bara utföra ett antal steg i en process.
  5. Vi förstår vår egen verksamhets ambition. 
    Hur processorienterade vill vi bli? Ska vi använda processer för att lösa ett specifikt problem eller utveckla ett visst verksamhetsområde? Eller vill vi gå mot en mer processorienterad organisation? Vill vi utse processägare etc.Om vi vill gå mot en mer processorienterad organisation måste vi se över vår incitamentsmodell. Vad belönar vi våra medarbetare för? För att de bidrar till att våra värdeflöden utvecklas och förbättras, eller att de håller sig inom sina organisatoriska ramar?
  6. Vi förstår att införandet av nya idéer i de flesta fall handlar om att människor behöver ändra sitt arbetssätt eller beteende och vi ser till att vi har rätt kompetens för att hantera detta. 
    I ett verksamhetsutvecklingsarbete har vi mycket fokus på människan och företagskulturen. Det gäller att säkra att rätt förutsättningar finns för förändringen. Vi använder gärna Kotters 8-stegsplan som stöd vid förändringsarbete. Det första steget är enormt viktigt: Förändringsarbetet ska kännas angeläget!
  7. Vi arbetar agilt med utveckling av vår verksamhet och vi levererar nytta i tydliga mindre leveransomgångar. 
    Detta är avgörande för att ha med sig alla på tåget och för att komma framåt utan obehagligt kostsamma överraskningar.
  8. Vi lär känna kunden, på riktigt!
    Kunskap om kunden är ovärderlig när vi utvecklar vår verksamhet. När vi väl förstår hur kunderna upplever sina resor i användandet av våra tjänster och produkter, så kan vi också lättare prioritera var vi ska sätta in vår egen utvecklingsinsats. Sluta anta kundernas upplevelse, ta reda på fakta istället!
  9. Information is da shit!
    Ja, ni har väl hört talas om datadriven verksamhetsutveckling? När vi utvecklar våra förmågor eller processer så måste vi förstå vilken information som är viktig; vilken information vi behöver, vilken information vi har, vilken information vi kan införskaffa och hur det ska gå till. Vi behöver också säkerställa att kvaliteten och tillgängligheten på vår information är tillräcklig för syftet. Alla i verksamheten använder information i det dagliga arbetet och omvandlar den för att dra nya slutsatser och starta nya aktioner. Att jobba informationsdrivet innebär att vi tar hand om informationen som genereras i verksamheten och medvetet använder den för att optimera våra värdeflöden och skapa nya värden. Så, att jobba med verksamhetsutveckling är lika mycket att jobba med informationsutveckling, glöm inte det alla verksamhetsutvecklare! 🙂

Kompetensutveckling

Om du vill få metoder och verktyg för att hålla utvecklingsinitiativen på banan – kolla in våra utbildningar inom process- och verksamhetsutveckling:

Certifierad verksamhetsutvecklare – en utbildning på tolv dagar uppdelade på sex tillfällen

Spela en avgörande roll och ta ett starkt grepp om verksamhetsutvecklingen. Denna utbildning är en skola med praktisk kundorientering.  För att hänga med i dagens snabba utvecklingstakt och för att kunna öka kundnöjdheten och den interna effektiviteten ställs nu mer än tidigare krav på en kontinuerlig och lättrörlig verksamhetsutveckling. Certifierad verksamhetsutvecklare ger dig kompetensen att utveckla processer, tjänster och förmågor samt att leda förändringen. Certifierad verksamhetsutvecklare – ubildningsbeskrivning

Processutveckling – en kurs på två dagar

Lär dig kartlägga och beskriva processer. Genom att kartlägga hur vi jobbar för att uppnå kundvärde, identifiera målen för varje process och sedan införa mätetal får vi en nödvändig grund för att styra verksamheten emot övergripande mål. Kursen bygger på en väl utprövad teoretisk grund i kombination med praktisk processutveckling. Du får mycket övning samt tillfälle att reflektera över konkreta exempel och ta lärdom av praktisk erfarenhet från verkliga case. Kursen ger dig förmågan att praktisera dina nya kunskaper på ett professionellt sätt, direkt i din egen verksamhet. Processutveckling – kursbeskrivning

Informationsmodellering – en kurs på två dagar

Lär dig att identifiera, definiera och strukturera information i modellform genom övningar. Du får lära dig teorin bakom objekt, relationer och nycklar, och vi ger även en genomgång av informationsmodellens användning och visar på samband med förmågemodellering och processutveckling. Informationsmodellering – kursbeskrivning

Vintergatan – en kurs på 2 +1 dag

Lär dig ta fram en översiktlig bild över hela eller delar av din egen verksamhet i en förmågekarta. Modellen har en unik syn på verksamhetsutveckling och låter dig kombinera och visualisera flera perspektiv i samma karta som processer, business capabilities, applikationssystem, kundresor, etc. Vintergatan – skapa din verksamhetskarta – kursbeskrivning

Vi levererar våra utbildningar i samarbete med Dataföreningen Kompetens AB

En gemensam bild av verksamheten gör oss mer framgångsrika

Att inom organisationen ha en gemensam bild över var vi är och vad vi gör är en förutsättning för att lyckas skapa en framgångsrik verksamhet. På samma sätt som en grupp människor i skogen snabbare når sitt mål om alla utgår från samma karta så blir organisationen mer effektiv om vi har en samstämmig bild av verksamheten, dess utgångsläge och vart vi är på väg.

Det är lätt att tro att bilden jag har av min verksamhet och hur vi tar oss framåt, är densamma som min kollega har. Men faktum är att den bilden många gånger ser väldigt olika ut beroende på vem i organisationen man pratar med.

Om vi har olika utgångspunkter med olika mentala bilder av var vi är tar vi olika vägar mot målet. Vi ser olika hinder på vägen och navigerar olika. Det medför även stora problem med att försöka koordinera alla med olika bilder att ta sig till samma mål.

En förutsättning för att lyckas

Att ha en gemensam bild över var vi är och vad vi gör är en förutsättning för att lyckas med en verksamhet.

På samma sätt som en grupp människor i skogen snabbare når sitt mål om alla utgår från samma karta och går åt samma håll, så blir en organisation mer effektiv om vi har en samstämmig bild av verksamheten och dess utgångsläge.

Samsyn är grunden. När vi skapat samsyn är alla  på samma bana ,och vi kan navigera, prioritera och styra mer effektivt. Vi är därmed rustade för att lyckas genomföra snabbare förändringar och snabbare kursändringar.

Förenkla och förtydliga en komplex verklighet

För att uppnå samsyn använder vi oss av modeller av olika slag. Att ta fram en modell eller karta är att skapa ett verktyg för att förstå en komplex verklighet. För att förstå behöver vi kunna se samband. För att göra det tydligt behöver vi förenkla, lyfta fram vissa delar och tona ned andra.

Därför är det inte så konstigt att vi använder en mängd olika modeller för att beskriva en verksamhet; hur vi arbetar, vilken information vi behöver, hur IT-lösningarna ser ut eller hur vi organiserar oss. Dessa modeller används i sitt sammanhang för att klargöra ett visst område och fyller sin uppgift inom den delen. Men hur hänger dessa modeller samman? Hur navigerar jag mellan dem? Exempelvis – Hur avgör jag vilka delar av verksamheten som påverkas av företagets nya vision?

Vintergatan – en karta, en modell och en metod

IRM har arbetat fram en metod och en modell, en sorts karta som innehåller just alla dessa perspektiv och som tillåter oss att navigera mellan dem. Vi kallar den Vintergatan.

Den visualiserar en organisations olika funktioner som förmågor i ett cirkulärt, kretsloppsliknade system. Vintergatan ger en tydligare, kraftfullare överblick och bättre kapacitet att navigera och arbeta strategiskt med verksamhetsutveckling inom organisationen. Vintergatan är också en metod som förenklar den del av verksamhetsarkitekturarbetet som visas upp mot verksamheten och bidrar till förståelse för de konsekvenser ett förändringsarbete kan få för andra delar organisationen.

Pension & Försäkring i SEB började kartlägga sin verksamhet och navigera utifrån Vintergatan i samband med en stor översyn av föråldrade IT-stöd.

” När jag först kom i kontakt med Vintergatan kände jag, wow, det här kan verkligen hjälpa oss att överbrygga gapen i vår verksamhet och ge oss bättre verktyg för att ta mer medvetna designbeslut. Vi började först använda den för att skapa övergripande analyser.”  – Cecilia Klöfverskjöld Nyberg, Pension & Försäkring i SEB.

Läs mer om SEBs erfarenheter av Vintergatan

IRMs kunder delar med sig av sina erfarenheter av Vintergatan:

För de som snabbt vill få upp en första version av en Vintergata över hela eller delar av sin verksamhet så rekommenderar vi vår öppna kurs som vi levererar i samarbete med Dataföreningen kompetens. 

Läs kursbeskrivningen och se kommande kursdatum för Vintergatan – skapa din verksamhetskarta.

Därför behöver din organisation en affärsarkitekt

Att affärsarkitekten är en nyckelroll för en framgångsrik organisation råder det ingen tvekan om. För att kunna bygga en fungerande affärsarkitektur och säkerställa att verksamheten kan hantera de allt tuffare omvärldskraven är det essentiellt att den här typen av kompetens finns på plats. Här listar vi fyra anledningar till varför du ska ha en affärsarkitekt i din organisation!

1. Affärsarkitekten är en länk mellan strategi och förmågor

En affärsidé är sällan unik men sättet den realiseras på kan vara det. Det är i det specifika sättet en verksamhet realiserar en affärsmodell som dess förmåga att leverera kundupplevelse och konkurrenskraft avgörs.

2. En drivande kraft för modern strategisk affärsutveckling

Affärsdesign är ett kraftfullt verktyg för att skapa en effektiv dialog kring komplexa frågor. Genom visualisering och storytelling (genom Value Proposition Design och Innovationskartan) kan din organisation driva modern strategisk affärsutveckling.

3. Organisationens alla nivåer följer med i transformationen

I en väldesignad affärsarkitektur byggs en helhet genom att föra samman affärsstrategi, affärsmodeller, förmågor, IT och organisation. Tillsammans skapar dessa förutsättningar för modern och innovativ affärsutveckling.

4. Organisationen kan ta emot framtiden med öppna armar

En affärsarkitekt hjälper din organisation att anpassa affärsmodellen och verksamhetens förmågor att möta nya utmaningar. Se till att din organisation har en strategi och en snabbfotad affärsarkitektur som möter marknadens krav på hållbara och kundcentrerade organisationer.

Säkerställ att erbjudanden anpassas i takt med att omvärlden förändras och kundernas behov med den.

I samarbete med Dataföreningen kompetens erbjuder vi utbildningen Certifierad affärsarkitekt Master som säkerställer att du som affärsarkitekt får förmågan att utveckla affärer som talar till dina kunder. Utbildningen ger dig kunskapen att forma ett team som kan analysera, innovera, designa, testa och realisera förbättrade eller helt nya affärsmodeller!



7 steg för att lyckas med processutveckling

Funderar du på hur din verksamhet fungerar och levererar ur ett kundperspektiv? Är du frustrerad över onödigt omständliga och rigida arbetssätt? Känns det som gamla strukturer förlamar och gör det svårt att anpassa sig till nya omvärldskrav? Då kan det vara dags att se över era processer.

Vi har identifierat 7 avgörande steg för att lyckas med processutveckling:

  1. Vi vet varför vi beskriver våra processer och vad vi vill uppnå med det.
  2. Vi beskriver så mycket av processerna som syftet ställer krav på, inte mer, inte mindre.
  3. Vi har syftet i tankarna när vi kommunicerar våra processer; vem ska förstå och varför ska personen förstå processerna.
  4. Vi ser till att individerna känner igen sig i processerna. Detta gör vi genom att fokuserar på processernas resultat och vad detta resultat i nästa steg ska användas till. Det skapas lättare ett större engagemang kring att jag som individ är med och skapar ett resultat än att jag som individ är med och gör ett antal steg i en process.
  5. Vi förstår vår egen verksamhets ambition när det gäller vilket sätt vi vill leva med process-perspektivet. Ska vi använda processer för att lösa ett specifikt problem eller utveckla ett visst verksamhetsområde? Eller vill vi gå mot en mer processorienterad organisation? Vill vi utse processägare etc. Om vi vill gå mot en mer processorienterad organisation måste vi se över vår incitamentsmodell. Hur kan vi få människor i organisationen att jobba processfokuserat och inte organisationsfokuserat?
  6. Vi förstår att införandet av förändrade eller nya processer i många fall handlar om att människor behöver ändra sitt arbetssätt eller beteende och vi ser till att vi har rätt kompetens för att hantera detta.
  7. Vi arbetar agilt med processutvecklingen och vi levererar nytta i tydliga mindre leveransomgångar.

Ser du ett behov av att se över era processer? IRM:s verksamhetskonsulter har många års erfarenheter av att lotsa företag och organisationer inom olika branscher i deras process- och verksamhetsutvecklingsutmaningar.  Vi kan stöttar er längs hela resan, från processanalys till förändringsledning, eller avgränsat till de delar där behov finns, exempelvis som workhopledare eller mentor.

Vi erbjuder även kompetensutveckling inom processområdet, både i öppen regi och som företagsanpassade utbildningar:

Processutveckling – en kurs på två dagar

Lär dig kartlägga och beskriva processer.

Genom att kartlägga hur vi jobbar för att uppnå kundvärde, identifiera målen för varje process och sedan införa mätetal får vi en nödvändig grund för att styra verksamheten emot övergripande mål. Kursen bygger på en väl utprövad teoretisk grund i kombination med praktisk processutveckling. Du får mycket övning samt tillfälle att reflektera över konkreta exempel och ta lärdom av praktisk erfarenhet från verkliga case. Kursen ger dig förmågan att praktisera dina nya kunskaper på ett professionellt sätt, direkt i din egen verksamhet. Nästa kurstillfälle startar 26 november. LÄS MER HÄR

Certifierad verksamhetsutvecklare – en utbildning på tolv dagar uppdelade på sex tillfällen

Spela en avgörande roll och ta ett starkt grepp om verksamhetsutvecklingen.

Denna utbildning är en skola med praktisk kundorientering. För att hänga med i dagens snabba utvecklingstakt och för att kunna öka kundnöjdheten och den interna effektiviteten ställs nu mer än tidigare krav på en kontinuerlig och lättrörlig verksamhetsutveckling.

En verksamhetsutvecklare driver verksamhetsutveckling utifrån ett processperspektiv, ser till att roller, ansvar och befogenheter är tydligt definierade och kända samt att överlämningskrav är tydliga Vår utbildning Certifierad verksamhetsutvecklare ger dig kompetensen att processutveckla, styra processer och förändringsleda. Nästa utbildningstillfälle startar 19 februari 2019. LÄS MER HÄR

Agile in Practice

Agile in Practice

Abstract

Architects are often criticized to be too slow when developing the overall architecture in their enterprise. When their overall architecture is finished they are often criticized, because it is difficult to understand, difficult to use and the quality of the architecture is not acceptable.

How these problems may be solved at the Swedish Board of Agriculture (SBA) is described in this article. During an architectural journey we gradually learned how to work with Enterprise Architecture (EA) in a new way. The reason was a large program (ProCAP) with a lot of uncertainty, rapid changes and strong deadlines. The solution was Agile EA.

By combining agile methods with more traditional EA work, we have found a way to succeed developing the EA step by step based on current needs – while we support and participate in the program’s projects.

A number of Critical Success Factors are in place at SBA; some due to hard work and some by lucky circumstances in our environment. The agile development method Scrum was the standard development method in use. In the very ambitious program ProCAP, Scrum has been successfully related to the EA.

Agile EA is used in Practice managing both iterative development of the EA and guiding and supporting the development of new IT solutions.

This ambitious program at SBA may be regarded as a global breakthrough to achieve an Agile EA in Practice.

Table of contents

  1. Introduction
    1.1 The EA approach
    1.2 The Swedish Board of Agriculture
    1.3 The ambitious program ProCAP
  2. In theory
    2.1 Business Architecture
    2.2 The Agile approach – Scrum
  3. In practice
    3.1 The EA approach at the Swedish Board of Agriculture
    3.2 The Agile EA approach
  4. Summary of further challenges
    4.1 Advantages achieved with Agile EA
    4.2 Critical Success Factors
    4.3 Challenges
  5. About the authors
  6. References

Introduction

The EA approach

To handle today’s changes we build an overall enterprise structure based on a stable foundation. The information resource is such a stable foundation. It does not change very much even if the organization, the business innovation canvas, or the business processes change. Information Management – the way an organization deals with information – makes information available as a resource to be used in business processes and the business innovation canvas. Formulate a business strategy that allows an open exchange of relevant, meaningful and useful information.

Most approaches to thinking about an enterprise in a holistic way involve abstractions and the use of metaphors. The metaphor we use is the business as a city to be planned. A City Plan draws up an organized arrangement of sustainable zones or areas as when Baron Haussmann remodeled Paris in the middle of the nineteenth century. Our areas in the enterprise are based on stable and sustainable information groups.

The goal of this EA approach is to restructure the business and their IT solutions to become more efficient, robust, and integrated. When integrating with Scrum, an agile development method, an Agile EA approach in practice is achieved.

The Swedish Board of Agriculture

The Swedish Board of Agriculture is the Swedish Government’s expert authority in the agro-food sector. This means that the board of Agriculture monitors and analyses the development within the sector and implement related political decisions.

The Swedish Board of Agriculture promotes food production that is competitive, adapted to environmental and animal welfare concerns, and that benefits consumers. The political decisions may change sometimes dramatically and with short notice. To handle these changes is a big challenge.

The ambitious program – ProCAP

To understand the background of our architectural journey at SBA, we start with a travel to Brussels and the European Union. Every seventh years, a new long-term budget is added. The current budget period is 2014 to 2020. The Common Agricultural Policy (CAP) accounts for about half of the budget and therefore it can be assumed that the agricultural policy will be reformed before a new budget period.

At SBA we thus know years in advance that a reform is on the way; even if we don’t know any details. The conditions are thus: we don’t know what to do; we don’t know when to be finished. Late decisions and rapid changes are a daily challenge. We had to start preparing for the reform changes and an agile approach became one of the prerequisites for being able to manage the assignment.

The CAP reform includes three new policy programs. In 2012 SBA starts the program ProCAP to prepare for and implement CAP in Sweden. ProCAP is divided into three major projects; Business Rules and Processes, IT Development and Business Change. These major projects are supported by expertise in Enterprise Architecture, Methods and Information Security.

Because of three new policy programs in CAP to be implemented, the need for a new modern IT platform (the legacy systems are from the 90-ties and have difficulties to meet new business demands) and an ambition to take a holistic approach on business change, business processes, business rules and IT solutions, the ProCAP is a big undertaking including over 400 persons with a budget of 530 000 hours with a calculated cost of 30 billion Euros. The program was initiated in March 2012 and is planned to be finished Q1 2016. During this time around 10 new IT-systems will be developed.

This very big Program is managed by the Chief Architect, during the program replaced by another person in his architecture role. This gives a very good understanding and support from the Program management to the architecture team.

In theory

Business Architecture

To handle today’s changes we want to establish an overall business structure based on a stable foundation. The information resource is such a stable foundation. It does not change very much even if your organization or your business processes change.

The metaphor we use is the enterprise as a city to be planned. A City Plan draws up an organized arrangement of sustainable zones or areas as when Baron Haussmann remodeled Paris in the middle of the nineteenth century. Our areas in the enterprise are based on stable and sustainable information groups.

The goal of this EA approach is to restructure the enterprise to become more efficient, robust, and integrated. Traceability will secure that the solutions relate to the business architecture as intended. It is also a way to continuously maintain and develop the architecture based on more detailed knowledge in new solutions.

The first Business Architecture was developed by IRM in 1984 for SKF, the Swedish Global Ball Bearing company. Developing over 100 Business Architectures since 1983 at SKF, IKEA, Statoil, Scania, TeliaSonera and other private and public business. Since 1994 around 1000 Business Architects have been certified at an academic level in Sweden.

Today it is fully accepted (at least in theory!) that EA should be based on business knowledge and not driven by IT.  In consequence we focus on the Business Architecture. The IT Architecture and the Solution Architecture have consequently to be aligned with the Business Architecture.

Defining Business architecture

The Business Architecture definition by Len Fehskens at The Open Group says

“The Business Architecture ensures that the enterprise as a whole is always fit for purpose of achieving its vision, mission and strategies”

If your ambition is to always be fit for purpose you should choose an artifact that is stable and doesn´t change when you change your organization, make a new innovation, or you choose to outsource part of your business. The most stable resource or artifact we know of is the Information Resource itself. Another very useful and rare characteristic of this resource is that data and Information is not used up or consumed when you use it.

The definition implies that the lifecycle of the business architecture starts when the enterprise is established and ends when the enterprise is closed. The lifecycle of a vision, mission, strategy, IT solutions, and business innovation may have a much shorter lifecycles. That implies that the Business Architecture should not be made dependent on these shorter lifecycles, but instead be based on the business itself.

The Information Resource

The artifact of the Information Resource is the most stable one and an architecture based on the information structure may reach a stability needed to achieve a fit enterprise as stated in the definition above. Shorter for this is “keep your artifacts in good order”. Maintain your Information Resource and your Business Rules in good order and you are well prepared for future known or unknown changes – internal and external.

Business Architecture – the Big Picture

Figure 1 The main Artifacts of Business Architecture

In a Business Architecture we usually have 25 to 50 normalized Overall Business Information Groups (OBIM). A single data element belongs to one and only one Information Group. We also usually have 25 to 50 Business Processes where one specific activity belongs to one Business Process. The Business Process Matrix tells in which process a specific Information Group is created or used.

The Business Architecture is created in an agile way over a two month period by 12-15 business experts all participating in three two day workshops facilitated by two experienced Business Architects. The Result consists of an Overall Business Information Model, an overall Process Architecture and a number of high level Innovation Canvases. Please, stay at the overview level and avoid details at this stage if you want to fulfill it in two months.

Our world is growing more and more complex. We have many driving forces adding to this complexity and very few creating simplicity. Companies like IKEA, where “simplicity is a virtue,” are very rare.

”It seems that perfection is reached,
not when there is nothing left to add,
but when there is nothing left to take away”

Antoine de Saint Exupéry, French author and pilot, 1900 – 1944.

The Agile approach – Scrum

Scrum is an iterative and incremental agile software development framework for managing product development. It defines a flexible, holistic product development strategy where a development team works as a unit to reach a common goal and enables teams to self-organize communication among all team members and disciplines in the project.

A key principle of Scrum is its recognition that during a project the customers can change their minds about what they want and need often called ”requirements churn”. As such, Scrum adopts an empirical approach—accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the team’s ability to deliver quickly and respond to emerging requirements

Product Owner

The Product Owner represents the stakeholders and is the voice of the customer. He or she is accountable for ensuring that the team delivers value to the business. The Product Owner writes customer-centric items (typically user stories), ranks and prioritizes them, and adds them to the product backlog. Scrum teams should have one Product Owner, and they may also be a member of the development team.

Sprint

A sprint or iteration is the basic unit of development in Scrum. The sprint is a ”time boxed” restricted to a specific duration. The duration is fixed in advance for each sprint and is normally between one week and one month.

Each sprint is started by a planning meeting, where the tasks for the sprint are identified and an estimated commitment for the sprint goal is made, and ended by a sprint review-and-retrospective meeting, where the progress is reviewed and lessons for the next sprint are identified.

Scrum emphasizes working product at the end of the Sprint that is really ”done”; in the case of software, this means a system that is integrated, fully tested, end-user documented, and potentially shippable.

The figure below illustrates how important it is not only to have a working product at the end of the Sprint, but also deliver it to users to learn from their feedback.
 

Illustration by Henrik Kniberg at Spotify and Crisp

In practice

The EA approach at the Swedish Board of Agriculture

A few months before the ProCAP program started at SBA, some architects received the assignment to lay the foundation for the ProCAP program – a foundation that included objectives and guidelines for the architecture which would form the basis for the new generation IT systems to be implemented during the program. The assignment was given by the chief architect (who then became program manager of ProCAP) and the ProCAP steering Committee chair. This gave a very good understanding and support from the Program management to the architecture team.

To handle changes in our environment – sometimes dramatically and with short notice – it was important to establish an overall EA based on a stable foundation. Our two architecture principles became ‘a holistic perspective’ and ‘an information-driven architecture’.

We started to map overall information and processes. By matrix analyses we captured the most important business capabilities and our city plan was born. The city plan became our way to communicate and visualize our overall target architecture.

The city plan was divided into different views – for business architecture, information architecture, applications architecture and infrastructure architecture. In this way we could start aligning Business architecture and IT architecture.

The Agile EA approach

The ProCAP program had to start although the conditions were ‘we don’t know what to do, we don’t know when to be finished, late political decisions and rapid changes’. The agile development method Scrum had been used at SBA for some years and would be used in ProCAP. This led us to the idea of testing Agile EA.

We formed an architecture team of business architects and IT architects (at the moment five business architects and three IT-architects) working together. Our assignment given by the program manager and the steering committee chair was:

  • Create conditions for good planning and effective implementation of IT development within ProCAP
  • Contribute to effective business and IT development within the entire SBA

Based on the IT project needs we made a rough plan for six months at a time – a plan that was adjusted before each sprint. The tasks in this plan (our back log) included both tasks to continuously develop the architecture step by step and tasks to guide and support the IT projects when understanding and using the architecture.

With the city plan, we had a rough, adaptive architecture. With Agile EA we added a rough, adaptive plan. This became our approach to meet the everyday challenges in ProCAP.

The Agile approach illustrated by Henrik Kniberg at Spotify and Crisp

 The Architecture Team and the Product Owner

The role Product Owner is staffed by three persons – the program manager, the chief architect and the head IT project leader. The Product Owner helps and supports the architecture team to focus on their most important tasks in each sprint based on the needs within the different parts of ProCAP. In one period it could be to focus on the architecture itself and in another period to assist and guide development team using and understanding the architecture.

In practice this means that the Product Owner and the Business Architects work in very close cooperation to secure that the result of the sprint delivers value both to ProCAP and the EA – avoiding specific “quick and dirty” solutions that represents an ‘architecture debt’. The architecture team and the Product Owner work together to identify, add and prioritize tasks to the backlog.

The chief architect is both Product Owner and part of the architecture team.

Three week Sprint

The architecture team works in three week sprints. Each sprint is started by a planning meeting where we review the back log and decides what are the most value giving tasks to do right now. Sometimes tasks are deleted from the back log because they are now longer necessary. The highest priority tasks from the back log represent the sprint goal and they are estimated and planned in detail.

At the end of the sprint there is a retrospective. At the retrospective both methods and deliverables are evaluated and adjusted accordingly. During our architectural journey in ProCAP a lot of changes have already been made, both big and small. Some changes have been about the methods, some in what has being delivered and focused on and some about the forms of the deliverables.

Examples of deliverables from a sprint are:

  • generic principles and guidelines within a business capability
  • a new part of a business process
  • a more detailed information model
  • a solution pattern for how to implement an IT function.

The result of each sprint is delivered to relevant parts of ProCAP, for example through briefing, education or by being used by the architects when supporting and guiding IT development projects. Feedback from the ‘architecture users’ is important input to next sprint to continuously further develop the architecture while adding business value.

How to reach all project members and getting them to understand and use the architecture deliverables is a difficult challenge. The best way is to have the architects involved in various projects and use the deliverables in this work. The consequence is that then there is no architect left in the architecture team to keep developing the shared architecture. And when the architects instead focus on developing the shared architecture – the result doesn’t reach every project member.

This is a tricky challenge and we use the learning process to constantly find the most right approach for the moment.

The Learning process

The architecture team uses the retrospective as a method to continuously evaluate the work and adjust accordingly. Some changes are made because you learn and get smarter and some because the environment changes. The retrospective and the learning process it creates is one critical success factor because the conditions are constantly changing.

The Product Owner and the architecture team work together in the ongoing learning process to transfer business knowledge to the project teams.

The product owner helps the ongoing learning process. The business knowledge is transferred from the architects and the Process Owner to the project teams. This transference of business knowledge is an ongoing learning process partly because of the need to repeat and add new business knowledge to the project teams whenever needed but also because of high turnover of external consultant in the projects.

Summary and further challenges

Advantages achieved with Agile EA

We have tried to describe a number of advantages achieved by using the Agile EA approach, like:

  • Agile EA provides the ability to switch focus and change approach quickly when needed.
  • The architecture development is driven by the business value where the ongoing projects set the priorities
  • The architecture value is achieved directly. Early versions of architecture deliverables are released to set the direction and enable early alignment. The detailing of the architecture continues when needed.
  • A valuable dialogue occurs around architecture, as an effect of not presenting finalized deliverables.
  • The product owner ensures management commitment within architecture

Critical Success Factors

A number of Critical Success Factors are in place at SBA; some due to hard work and some by lucky circumstances in the environment.

Some ‘lucky’ circumstances are:

  • ProCAP needs gave the opportunity to get resources for the architecture effort.
  • Management understands the benefits of architecture.
  • The chief architect was appointed manager of the ProCAP program.
  • Agile development method Scrum was has been in place for some years within the organization.
  • The Business is rather stable even if the Business Rules may change frequently.
  • The size of the business is manageable for a shared architecture (the personnel is 1200 persons with 650 at the main office).

Some “hard work” factors are:

  • Results from previous projects where the new IT platform was prepared have provided a good foundation for the shared architecture.
  • Tight and very professional architecture team with extensive business knowledge are established.
  • Mix of Business Architects and IT Architects working closely together in the same team.
  • The agile method containing the retrospective makes the ongoing learning process possible.
  • Working closely with the projects in the program and listening on their needs.
  • The courage to try new ways of doing things.

Challenges

There are a number of challenges like:

  • Keep focusing when the ongoing projects have a lot of various challenges to handle. We are all torn between competing tasks and prioritizing is demanding.
  • Architects are ’nice to have’ persons, with a deep understanding of the business – useful for other activities besides architecture development. The role of the architects needs to be evaluated continuously to make conscious decisions possible.
  • How to reach all project members with architectural deliverables and at the same time achieve the balance between developing the architecture versus guiding and supporting the projects.
  • Find a good balance between guiding and supporting the ongoing projects and the work with the shared architecture.

About the authors

Boel Ohlin – Boel is Business Architect at the Swedish Board of Agriculture. She is a certified business architect and has a background working with business intelligence (as BI architect, BI analyst, BI developer and BI strategist) and system- and method development. She can be reached at boel.ohlin@jordbruksverket.se

Jenni Dahlkvist Vartianen – Jenni is Business Architect at the Swedish Board of Agriculture, managing the architecture team in ProCAP. She is a certified business architect and has a background working with business analysis, system development and method development. She can be reached at
Jenni.Vartiainen@jordbruksverket.se

Eskil Swende – Eskil is a main partner at IRM , a Scandinavian consulting company focusing on Enterprise Architecture and the Innovation Process. He is also a partner at IRM UK, a strategic education company in London that provides seminars and arranges yearly conferences on EA, IA, MDM and BPM. Eskil is President of DAMA Chapter Scandinavia and has developed a global wisdom network of leading experts inside and outside DAMA, inviting them to give presentations and tutorials in Scandinavia. He can be reached at Eskil.Swende@irm.se.

References

  • Chisholm, M.D. 2010. Definitions in Information Management – A Guide to the Fundamental Semantic Metadata, Design Media
  • Greefhorst, D and Proper, E. 2011. Architecture Principles – The cornerstone of Enterprise Architecture, Springer
  • Guenther, M. 2013. Intersection – How Enterprise Design Bridges the Gap between Business, Technology and People, Morgan Kaufmann
  • Hammer, M., and Champy, J. 1993. Reenginering the Corporation: A Manifesto for Business, New York, Harper Collins
  • Hammer, M. 2001. The Agenda – What Every Business Must Do to Dominate the Decade, New York, Crown Business
  • Kniberg, K, and Skarin, M. 2001. Kanban and Scrum – making the most of both (Enterprise Software Development).InfoQ
  • Langefors, B. 1966. Theoretical Analysis of Information Systems, Lund, Sweden, Studentlitteratur
  • Nonaka, I., and Takeuchi, H. 1995. The Knowledge-Creating Company – How Japanese Companies Create the Dynamics of Innovation, Oxford, Oxford University Press
  • Potts, C. 2010. RecrEAtion – Realizing the Extraordinary Contribution of your Enterprise Architects, New Jersey, Technics Publications
  • Ross, J. W., Weill, P., and Robertson, D. C. 2006. Enterprise Architecture as Strategy – Creating a Foundation for Business Execution, Boston, Massachusetts, Harvard Business School Press
  • Sykes, M., Malik, A.N., and West, M. D. 2013. Stories That Moves Mountain – Storytelling and Visual Design for Persuasive Presentations, Wiley
  • Swende, E. 2014. Core Knowledge for EA, Journal of Enterprise Architecture
  • Swende, E. 2010. Defining and naming Data Models Related to the Zachman Framework, Pittsburg, TDAN.com
  • Weill, P. and Ross, J. W. 2009. IT Savvy – What Top Executives Must Know to Go from Pain to Gain, Boston, Massachusetts, Harvard Business Press

 

Att bygga det agila företaget – med fokus på mänsklig medverkan

Ta tillvara människan

Allt fler företagsledningar och chefer börjar prata om begreppet WHY?, dvs varför vi gör som vi gör.
I tidigare artiklar skriver Mattias Tronje och Robert Elm om vad ett agilt företag innebär på en organisatorisk nivå. De redogör för utmaningen med att gå från det traditionella stabila arvet till en mer dynamisk och flexibel organisation; där agila företag jobbar med tillit och öppenhet och värdesätter människan istället för kontroll och granskning. Det är detta jag vill knyta an till i denna artikel, genom att beröra nedanstående perspektiv:

  • Det nyfikna utforskandet vs traditionellt ledarskapet
  • Vikten av inkluderande och inre mångfald
  • Vikten av att klargöra personliga värderingar före företagets
  • Arbetsklimatets påverkan
  • Vår historia och vikten av samverkan för överlevnad
  • En naturlig samarbetsinriktad metod, Design studio

Människor som resurs; Vad betyder resurs för dig? Tillgång? Hur inkluderande är er kultur?

Agila företag jobbar med tillit och öppenhet och värdesätter därmed människans egen potential och eget ansvarstagande i samverkan med andra, istället för kontroll och granskning. Det finns en utmaning i att hantera vårt arv av kontroll och styrning; en maktstruktur. Detta arv leder till att en del av dagens chefer och ledare försöker plocka russinen ut kakan, och behålla makten. Några nycklar till förändring av organisation, arbetssätt och mind se är att jobba med kultur, mod, vidga perspektiven samt omfamna möjligheter och mångfald i nya kombinationer jämfört med tidigare. I Mattias artikel ”Att bygga det agila företaget – Var börjar man?” lyfts även vikten av öppenhet, kultur av prövande och lärande och landar i att vi behöver ett arbetssätt som börjar med frågetecken istället för utropstecken. För traditionella företag som vill anamma ett lekfullt, meningsfullt och utvecklande förhållningssätt med fokus på människan innebär detta en omfattande kulturresa.

Det nyfikna utforskandet vs traditionellt ledarskap

Min syn på traditionella chefskapet är att bli utsedd med både skyldigheter och rättigheter och att det nu går över mer och mer i ledarskap där ledarskapet handlar om att förstå hur relationer och samverkan skapar värde. Tidningen Chef skriver att ledarskap handlar mer om relationer och går till stor del ut på att få sina medarbetare motiverade genom att ge dem meningsfulla arbetsuppgifter.

När det gäller motivation tror jag nyckeln är att förstå skillnaden mellan inre och yttre motivationsfaktorer. Att leda med yttre motivationsfaktorer, som morot och piska, tror jag är ett minne blott. Genom att förstå inre motivation och kraften av att möta våra olikheter kan vi bättre förstå vad som krävs i resurser och organisering för att lyckas. Ledarskap för mig handlar om självledarskap, leda team och organisation. Vem och vilka som leder är behovsstyrt och självorganiserande i ett agilt företag.

Kanske chefsrollen blir något som delas på framöver för att säkerställa att de som utför jobbet har de resurser som krävs för att både skapa värde och där medarbetarnas inre drivkrafter möts i en allt högre grad än tidigare.

Det nyfikna utforskandet kanske är motsatsen till att peka och instruera. Att visa mod och ifrågasätta chefer och ledare öppet vare sig kulturen tillåter det eller inte, tror jag sker automatiskt när allt fler blir medvetna om kopplingen mellan drivkrafter, värderingar och beteenden. En författare som inspirerat mig mycket är Lasse Berg. Han har skrivit ”Kalahariböckerna”, vilka handlar om vår evolution. Dessa böcker är en sammanfattning av all forskning på detta område. Lasses tes är att människan i grunden är god/altruistisk, vi mår bra av att göra andra glada och att chefskapet inte är något naturligt för oss människor. Lasse Bergs tes stöder att vi vill bestämma själva tillsammans med andra, vissa kanske mer och vissa mindre. Kanske är ledarrollen något vi alla skall dela och ansvara för och, om den inte är naturlig, hjälpas åt i.

Ibland möter jag en frustration från de som fördjupat sig i vad som driver beteenden, drivkrafter samt grupprocesser och som har en chef som är kvar i våra hierarkiska och Taylorismiska arv. Ibland har jag möts av dessa frågor/kommentarer från chefer: Måste du veta? Vilka jobbiga frågor du ställer.
Är detta ett dåligt ledarskap? Vad driver makt; pengar eller kunskapstörst? Personligen tror jag på ett ledarskap som följer ett syfte, snarare än en namngiven person, där vi inkluderar och bejakar inre mångfald med fokus på människa och utveckling och där vi kombinerar det vi vill ha kvar med det vi behöver ta bort eller lägga till. Denna typ av ledarskap och arbetssätt resulterar i ett arbetsklimat som skapar tillit, vilket resulterar i förändringar som ger värde.

Tillvarata mångfalden genom inkluderande

Jag tycker att mångfald omfattar mer än etnicitet, ålder och kön som traditionellt förknippas, vi glömmer oftast de inre drivkrafter, erfarenheter och kunskaper. Hur tar vi då tillvara på mångfalden och varför är inkluderande så viktigt? Det som händer när vi inte inkluderas är snarlikt som när vi får ett slag i ansiktet. Hjärnforskningen visar att samma närliggande system i hjärnan aktiveras. Vi går in i ett ”fight mode” eller ”flight mode”, dvs sluter oss pratar mindre och mindre med varandra. I en grupp med konflikter skapas ett tillstånd av rädslor som smittar och studsar mellan individerna. Vi slutar samverka. Vad som händer med öppenheten och tilliten är ganska uppenbar.

Vikten av att klargöra personliga värderingar före företagets

När jag möter företag som säger sig vara värderingsstyrda frågar jag; ”Hur mappar medarbetarnas värderingar med företagets?” ”Hur vet ni att det är så?” ”Hur gör ni för att förstå hur det ligger till?”

För några år sedan pratade Patrizia Bricca från Handelsbanken på HR-dagarna om Engagerade medarbetare i organisationer under utveckling. Hon visade ett intressant diagram över medarbetares engagemang kopplat till värderingar, se bild nedan.

Den stora vinsten i engagemang får vi när medarbetarna klargör och tydliggör sina egna värderingar. Maximalt engagemang nås när även företagets värderingar är tydliga. Att bara jobba med endast företagets värderingar är därmed nästintill bortkastad tid.

Arbetsklimatets påverkan

Här vill jag belysa vikten av det vi säger i samtalen och i våra möten i vardagen. Att från kollegor, chefer och ledare få höra hur dåligt något är utan att det specificeras suger energi och bryter ner motivationen. Ett användbart sätt för att öppna upp för dialog, så mer tillit och engagemang skapas, är att använda modellen ”Förändringens Fyra Rum”. Det är en svenskutvecklad psykologisk teori om hur vi ser på oss själva, team, organisationen och samhället i förändring. Det är en dialogmodell där vi tillsammans tar fram analysmaterialet som vi analyserar ihop, istället för som i många webtester där andras ord och innehåll används. Framgångsfaktorn i Fyra-rummaren är igenkänning och att vi utforskar tillsammans.

Claus Janssen, upphovsmannen till Förändringens Fyra Rum, fann att världens befolkning, oavsett land, fördelar sig lika över i en normalfördelningskurva. Där ytterligheterna i båda ändar motsvarar 15%.

Frågar vi den första ytterligheten, de som vill bevara, hur stor del av befolkningen de tror att de tillhör är blir svaret ofta 85-90%.
När vi frågar den andra ytterligheten, de som vill leva sin sanning, hur stor del av befolkningen de tror att de tillhör får vi svaret 2-5 %.

I verkligheten är båda grupperna lika stora. Den grupp som vill bevara tenderar att sopa under mattan när gruppens existens eller tillhörighet hotas medan de i den andra gruppen tenderar att lämna gruppen när deras egen tro hotas.

Båda ytterligheterna har samma behov av att känna sig inkluderade, fast på olika sätt, att tillhöra eller kunna stanna på egna villkor. Hur väl detta fungerar hänger ihop med livstillfredställelse.

Hur ser det optimala klimatet ut för en innovativ, kreativ eller Agil kultur? Jag hade förmånen att träffa Claus Janseen för några veckor sedan och han sa:

”Jens, det finns ingen perfekt buljong eller mix här. Det viktiga är att det jordmånen gör att båda ytterligheterna får den näring dom vill tillsammans med den stora gruppen i mitten så att den inre mångfalden kan blomma och bidra till att värde skapas för individer organisationer och kunderna.”

Jag har personligen tittat på och använt många tester och varit i det så kallade testräsket. Den största nyttan jag ser med olika tester är att vi möts och börjar utforska varandra för att förstå varandra bättre. Jag ser en fara och risk med vissa tester som förenklar för mycket. De saknar evidens och kan ge mer skada än nytta i arbetsklimat och värdet för kunden. Jag tror på enkla och naturliga arbetssätt, att utforska varandras perspektiv så vi känner oss sedda och inkluderade på våra egna villkor.

Vår historia och vikten av samverkan för överlevnad

Vår historia har präglat oss. Lasse Berg beskriver vår utveckling i sina Kalahariböcker hur vi levt mer än 95% av vår tid som samlar- och jägarfolk, tills någon tappade tillräckligt mycket säd på jorden så vi kunde skörda och slå oss ner. Överskotten kom och med den administration, byråkrati och makt. Religion, kyrkan och industrialismen, löpande band, processrevolutionen är annat som skapade behov av mer styrning och kontroll. Vilket liv är vi skapta att leva egentligen? Vad är hållbart för natur och oss själva som människor? Enligt Lasse Bergs egen efterforskning härstammar vi alla från en liten population i Afrika; Tsan-folket, och våra förfäder har vandrat olika vägar över jorden. Det är möjligt att ta ett DNA-test för att få reda på vilken väg din förfader vandrat. Lasse, som levt med ett antal naturstammar/folk, har själv upplevt det ickehierarkiska i grupperna där allas insats betyder lika mycket, det som lyser starkast är samverkan och småchattandet. Han menar att vi är skapta för att jobba tre timmar per dag, gå 6–10 km per dag, äta och skratta tillsammans med andra. Maslows teorier får här en känga, och även Matthew Lieberman m.fl. inom neuroforskningen, som menar att behovet av att tillhöra och få stanna i en grupp eller sammanhang är starkare än mat eller sex, får vi stanna och tillhöra får vi andra behov tillgodosedda. Det är därför vi människor kan göra ganska hemska saker bara för att få tillhöra, ett annat ord är Group thinking. Här har experiment som t.ex. Stanfordexperimentet med studenter som fick agera vakter och fångar visat att det som händer i grupper är mer avhängigt av situationen och kulturen än personligheterna och drivkrafter.

Tänker vi på evolutionen och det som sker runt omkring oss idag, med tanke på allt som går snabbare, ökad komplexitet, behovet av att snabbt utforska problem eller prioritera problemen innan vi hittar rätt lösning, så växer behovet av ett arbetssätt som strukturerat leder vårt cirkulära utforskande framåt. Bruce Tuchmans forskning om grupper och team visar att team som utforskar och förespråkar varandras perspektiv är det som lyckas bäst. Där är de genuint positiva uttalandena sex gånger vanligare än de negativa. I team som inte presterar eller är dysfunktionella går det ett positivt uttalande för varje negativt.

När naturfolken jagar är det några som samlar örter, andra maler, doppar pilarna i giftig smet innan de hamnar i kogret som jägaren bär och alla bidrar till att bytet fälls här. Alla i stammen tillför värde och bygger vidare. Jag har länge tittat efter arbetssätt i vår vardag som stöttar, inkluderar och bidrar till en trygg miljö, ”Psychological safety”, och på samma gång minskar vår kognitiva bias (vår personliga uppfattning/perspektiv). Det är bara att erkänna vi alla är biased, och när vi acceptera det har vi lättare att ta in andras perspektiv.

Det Lasse Berg belyser i sina Kalahariböcker, att det ständiga småchattande om vad som hänt ska göras med mycket skratt framför lägerelden, är det som får samspelet att flyta i gruppen när vi talar med och lyssnar till varandra. Vad hade hänt om vi behållit naturfolkens sätt se på naturen och hur de organiserade sig när vi började skörda för 15 000 år sedan? Jag tror inte på att vi skall flytta tillbaka till naturen och leva lyckliga i alla dagar utan jag tror vi har mycket att lära utifrån vår syn på andra, naturen och värdet som skapas samt att vi har mycket vunnet på självorganisering, inga mellanchefer/hierarkier, nätverk och att organisera sig agilt.

En naturlig samarbetsinriktad metod; Design Studio

Design Studio är ett arbetssätt som hjälper individer, team och organisationer att förstå såväl enkla som komplexa sammanhang och situationer. Samarbetsinriktat Design thinking med Design Studio som metod är ett arbetssätt där vi ger och tar och därmed får till ett öppnare och mer tolerant arbetsklimat.

En användbar metod för samverkan, som enkelt minskar bias (vår personliga uppfattning/perspektiv) och samtidigt ökar tryggheten. Jag har praktiserat denna metod i små och stora grupper för enkla eller komplexa frågor med mycket positivt resultat. Metoden Design Studio, fungerar även utmärkt som pedagogik för kollektivt lärande. Jag har själv använt den i kurser för agil/visuell kravfångst.

Med hjälp av Design studio kan vi strukturerat utforska varandras idéer. Ett sätt att bygga tillsammans det vi vill och tror på. Det är en metod som låter dig själv först reflektera, lyssna på andra, för att bygga vidare på varandras idéer och sedan dela insikter och uppdatera förslag.

Design Studio i ett nötskal

Den specifika arbetsmetoden i en Design Studio kan variera, men följer i regel fyra steg:

  • Rama in (kan var stort, litet, komplext, enkelt…)
  • Reflektera genom att SKISSA och ta fram förslag. SKETCH
  • Presentera och argumentera för sin skiss, PRESENT
  • Lyssna, ställa frågor och utveckla idéer, ”CRITIQUE”
  • Skissa om, presentera igen och norpa idéer tills ett fåtal idéer återstår. På så sätt utforskar vi och bygger tillsammans.

CRITIQUE som ord kan låta hårt, det handlar inte om att kritisera utan om att utforska, kanske EXPLORE / INSIGHT from each other är ord som skulle kunna användas istället då det enligt min uppfattning förklarar vad som egentligen görs på ett utforskande sätt. När vi kritiserar finns risken att vi blir trängda och går i försvar, samma system som går igång när vi utesluts. Design studio lämpar sig bra när vi tar fram vårt och förverkligar vårt WHY, SYFTE stort som smått som många säger är viktigt.

Design studio gör det enkelt att skapa den samsyn, öppenhet, tillit och kraftsamling av engagemang med fokus på det vi vill. Metoden hjälper oss att skapa en miljö där vi vågar ta risker och visa oss sårbara samtidigt som vi minskar vår egna och kollektiva bias på vår resa.

Många gånger blir vi överraskade av den nya väg som öppnar sig. Vi använder Design Studion för det är enkelt att komma igång med. Sedan kan metoden skalas upp eller ner beroende på hur enkel eller komplicerad uppgiften är, dvs Leadership by Design.

Att bygga det agila företaget – Var börjar man?

I min tidigare artikel på temat, att bygga det agila företaget, beskrev jag utmaningen i att skapa en organisation och en kultur som möjliggör snabb omställning mellan förändrade förutsättningar i värdeerbjudande, kundsegment, kundrelation och våra kanaler samt vår interna förmåga att leva upp till och leverera på vår förändrade situation.

I denna artikel kommer jag dyka in i hur vi kan sätta tänderna i utmaningen och börja resan mot en mer dynamisk, flexibel och anpassningsbar organisation, utan att krackelera.

Starta med frågan

En fråga som sällan ställs är;
Var i vårt affärs-, organisations- och verksamhetslandskap (affärs- och verksamhetsarkitektur) behöver vi vara mer dynamiska, flexibla och anpassningsbara?

Min erfarenhet är att vi vet att vi behöver bli det, men vi vet inte var i landskapet det ska ske. Detta leder många gånger till sökandet efter standardlösningar och metodval. T.ex. vi skall bli Lean, vi skall bli Agila eller vi skall införa SAFe. Då börjar vårt sökande med ett utropstecken – ett påstående, snarare än med en fråga – var behöver vi vara mer…?

Att starta med frågan istället för påståendet kommer ge oss fler alternativ och därigenom fler möjligheter för att sedan skapa mer precisa punkter för insats. Min rekommendation är att utgå från önskat resultat, eller önskat tillstånd, utifrån kundens perspektiv. Oavsett om kunden är intern eller extern, eller om det är en medborgare eller brukare. Det är viktigt med ett utifrån-och-in-perspektiv, snarare än ett traditionellt inifrån och ut perspektiv.

Dagens förmåga leder till dagens resultat

Vad är en förmåga? Det är just vad det låter som – den samlade förmågan att nå ett specifikt resultat i en avgränsad del av verksamheten.

En förmåga kan utgöras av dess samlade kunskap, den information den innehar och använder, den process den följer, de verktyg den behöver och de människor som verkar i den tillsammans med de mänskliga aspekterna såsom kultur, beteenden, drivkrafter, etc.

Som nybliven hundägare av en liten valp kan förmågan till inkallning i vårt ekipage (människa och hund) utgöras av min kunskap genom erfarenhet och den teoretiskt införskaffade information jag har tillgodosett mig, den tillgängliga information som omgivningen ger (distraktioner för hunden, terränglandskapet, etc), våra verktyg i form av godis, leksak, eventuell långlina och våra processer som består av ett startmoment, kommandon, belöning, eventuell bestraffning (missnöje) och ett slut. Förmågan innehåller även mig som person med mina drivkrafter, mina värderingar och den kultur som skapar mina beteenden i relation till det vi gör och mitt partnerskap med hunden. Förmågan innehåller även hunden med dess drivkrafter och beteenden. Tillsammans har vi en gemensam kultur som i praktiken visas genom våra beteenden.

Ställ fler frågor

Hur väl vi lyckas uppnå önskat resultat, eller tillstånd, beror på vår förmåga. Så vi kan alltså söka svaret på vad som behöver justeras i vår förmåga genom att titta på resultatet eller det skapade tillståndet. Utifrån detta kan vi ställa frågor; Vad händer om vi ändrar till ett annat verktyg (godis)? Vad händer om jag har en tydligare process (start till slut)? Vad händer om jag ändrar mitt beteende(belöning/bestraffning)?

Utifrån dessa frågor får jag alternativ. Möjligheter. Sedan kan vi i små steg pröva dessa förändringar för att se om det leder närmare mot det önskade resultatet eller tillståndet, enligt modellen:

Nu har vi skapat en ingångsmöjlighet till mer precis och avgränsad förändring genom att ta ett utifrån och in perspektiv. Vi tittar på det önskade resultatet/tillståndet snarare än ett påstående om metodbyte, verktygsbyte, processbyte, etc. Vi kan också rangordna (prioritera) möjligheterna utifrån vad vi tror kommer ge bäst effekt på resultatet/tillståndet. Med andra ord så har vi skapat en nedbruten ”att göra/pröva lista” som kan justeras utifrån nyvunnen kunskap och empiri.

I nästa artikel kommer jag att skriva mer om hur vi närmar oss en ökad grad av delegation och vikten av den i en mer dynamisk, flexibel och anpassningsbar affärsmodell, organisation och verksamhet, samt hur den kan leda till en ökad grad av självorganisation genom att titta på hur olika förmågor samverkar i ett värdeflöde/process.

Informationsmodellerarens tre superkrafter

Informationsmodellerarens tre superkrafter

Syftet med informationsmodellering är att skapa en gemensam förståelse samt utveckla centrala och sammanhängande aspekter av en verksamhet. Dessa aspekter kallar vi för informationsmodellerarens tre superkrafter!

Informationsmodellering är inte en specifik analysmetod utan en hel verktygslåda med metoder. I grunden är det ett sätt att modellera, det vill säga att rita och beskriva strukturer. Nedan har vi listat informationsmodellerarens tre superkrafter så att du kan möta våren och sommaren med ny hjälte-kompetens!

1. Att förstå vad verksamheten hanterar, det vill säga de företeelser och deras egenskaper, samt vilka verksamhetsregler som styr.

Företeelser kan exempelvis vara kunder, produkter, leverantörer, anställda och ordrar. En kund har i sin tur egenskaper som till exempel kundnamn, kundkategori och adress. Dessa egenskaper har regler som måste vara uppfyllda för att exempelvis en kund ska tillhöra en viss kundkategori.

2. Ett gemensamt språk för verksamheten.

För allt detta behövs gemensamma väldefinierade begrepp, bra benämningar och tydliga definitioner. En informationsmodell bär själva begreppsarbetet och kan representera det gemensamma språket för verksamheten.

3. Data som hanteras i en verksamhet.

Data representerar alltid företeelser och deras egenskaper beskrivna ovan. I en verksamhet strömmar ofta stora mängder data från många olika källor. Verksamheten är i mångt och mycket hantering av dataströmmar. Just nu befinner vi oss i en teknisk revolution som gör att vi hanterar alltmer data från allt fler källor. Det handlar inte bara om sakernas internet, artificiell intelligens och Big Data, utan även automatisering, integrering och digitalisering i största allmänhet. En informationsmodell är en gemensam karta över data i ett visst sammanhang och hur det ska tolkas, och därmed ett basverktyg för varje datahanterande verksamhet.

Informationsmodellering är en grundbult i de flesta arbeten som spänner över verksamhets- och it-utveckling, oavsett syfte och sammanhang. Det kan vara it-utveckling, it-arkitektur, verksamhetsutveckling, verksamhetsarkitektur, tjänsteutveckling, informationsarkitektur eller Data Management. Informationsmodellering är helt enkelt en typ av superkraft! Det skapar en gemensam förståelse av vad som hanteras i verksamheten samt språk och data som representerar detta.

Läs mer om informationsmodellering här