Expressing the business value of architectural decisions
A balanced scorecard approach to architectural decision- making at Unilever
Geert Waardenburg
Author:
Geert Waardenburg StudentNO:
1230751
By order of:
Unilever N.V.
Department:
Design Authority, Unilever Europe IT Supervisor company:
Aaron Rajan Ronald Stoppelenburg
Supervisors university:
Ir. F.B.E. van Blommestein Dr. H. Balsters University of Groningen, The Netherlands
Faculty of management and organization Master thesis Technology management Specialization information technology
Expressing the business value of architectural decisions
A balanced scorecard approach to architectural decision- making at Unilever
Preface
The end of a matter is better than its beginning; likewise, patience is better than pride.
(Ecclesiastes 7:8, the bible)
Reaching the end of studying life, the point of no return is there. Finishing the project there have been points of disappointment, but also points of joy. After seven months I can say the bible is right. Finishing things is better than its starting.
The subject of this thesis, business value of architectural decisions, is on a highly unexplored area. Although I never thought to be an expert on this area, it is a very interesting subject. I hope this thesis will provide some useful insights on this subject.
With this thesis I am finishing my graduate project at Unilever. I would like to thank Aaron Rajan and Ronald Stoppelenburg for their support, useful remarks, and the opportunities they gave me to make the internship this successful. Further I would like to thank Fred van Blommestein and Herman Balsters for their input and criticism. Their effort has been of enormous value. I also want to thank my family for their support, during the internship, but also during my study. Their support has been of priceless value. Furthermore I would like to thank my friends, colleagues, and other people for supporting me, conscious and unconscious.
Last, but definitely not least, I would like to thank my God. He provides me with the power I need and without His power I was not able to finish this thesis. The Lord is the one I am living for.
Geert Waardenburg
Summary
The design authority is a relatively new department inside Unilever Europe IT. This department is responsible for the planning, monitoring, and communication of the IT architecture. The architectural decisions concerning the longer-term use of applications, technology, integrations, and other systems have to be taken by the design authority.
Ultimately, these architectural decisions, although they possibly contribute to the IT goals, have to be aligned with the Unilever business goals.
Diagnosis
Currently three problems in this architectural process are apparent:
1. Departmental stakes drive architectural decisions
The decision-making process is being performed in the extended design authority group. This group consists of representatives from departments around the design authority, including an architect representing the design authority department. Decisions taken in this group are more of a compromise than generating the highest value for Unilever. The decision-making process is characterized by coalition building. This process is also highly influenced by Departmental stakes.
2. The design authority department is unable to show the value of architectural decisions
The costs involved with the management of the IT-architecture need to be justified.
Justification can be achieved by expressing the value generated by architectural decisions.
3. Lack of good communication to local IT departments.
It is important to justify a decision by showing the value for Unilever rather than focusing on local interest versus central interest. Therefore good communication is necessary because the architectural decisions take away local power shifting it to central IT.
Problem statement
The main underlying problem of these three problems is the fact that departmental stakes weigh too heavy in the decision-making process.
In order to solve this problem the following objective can be identified:
Shaping the decision-making process, in order to generate the highest business value for Unilever, and to develop a tool to support the decision-making process, in order to provide insight in the business value of architectural decisions.
To solve this problem two adjustable parameters are identified, being a different design of the decision-making process, and a new to be developed tool providing an independent insight in the business value for Unilever.
The scope is provisionally limited to business applications. The business value of architectural decisions is most clear in this area.
Description of decision-making process
The decision-making process is characterized using the theory of Daft for organizational decision-making. The current decision-making process can be described using the incremental decision-process model. Three phases are identified, the problem identification, the diagnosis, and the evaluation and choice. The last phase of evaluation and choice can be described using the Carnegie model. This model is based on the principle of coalition-building.
Design
First the decision-making process will be adjusted in order to solve the problem. Thereafter an instrument will be developed to support the decision-making process and to contribute to the solution of the problem.
Design of decision-making process
The problem of the weigh of departmental stakes being too important in the decision-making process can be solved by changing the phase of evaluation and choice of solutions from a coalition building to a more independent decision-making manner. The move to a more analytical and objective form of decision-making can be supported by the development of an independent supporting instrument.
Supporting instrument
In order to improve the decision-making process a supporting instrument will be developed.
The model used to support the development of the instrument, that has to support the evaluation, is the balanced scorecard. The balanced scorecard provides a good insight in the different aspects of the organization and also has qualitative and quantitative measures.
The architectural decisions have to contribute to the business goals. Unilever has made these business goals operational by providing architectural benefits. These architectural benefits are increased speed and responsiveness, increased business flexibility, reduced time to market, lower IT risk, and reduced costs. Architectural decisions have to contribute to these architectural benefits.
The impact of a decision on the organization is also important when stating the value of an architectural decision for the organization. This is important because the impact of a decision on Unilever has to be represented.
Therefore the instrument needs to take both the view on the organization and the architectural benefits into account in order to generate the insight in value for the Unilever business.
The resulting instrument is a scorecard with the four original perspectives of the balanced scorecard: financial, learning and growth, customer, and internal business process. These four perspectives generate a good view on the organization.
Several drivers are identified for each of these perspectives. These drivers ultimately contribute to one or more architectural benefits. Each of these drivers is weighted for their contribution to the architectural benefits. Further, for the financial perspective, a cost-benefit analysis has to be performed in order to state the financial implications for Unilever Europe IT. The resulting scorecard can be found in paragraph 7.5. The different drivers have to be rated from -5 to 5, where minus infinite and infinite are added as showstoppers. These showstoppers can be used when a driver forces a decision.
Change
To illustrate its use the resulting model has been applied to two decisions, a decision concerning reporting systems and a decision about the technical components of these reporting systems.
1. Reporting systems
The first decision-type is a decision about business applications. This architectural decision considers the choice for one reporting system, instead of several in the current situation. It is about whether or not to use Business Objects as the reporting system standard. Before the choice for Business Objects several reporting systems were used by Unilever Europe. Examples are Cognos, Oracle Sales Analyzer, SAP, Microsoft Excel and also Business Objects.
The architectural decision about Business Objects rates very high on the financial perspective. Secure savings are €1.2 million and possible additional savings are €3 million. A positive score is also generated in the other perspectives of the architectural scorecard. The user and learning and growth perspective generate respectively a score of 1.44 and 1.75. These are both low positive impacts on these perspectives. On the internal business process perspective a huge benefit is generated, namely 3.44, which implies a moderate to high positive impact on the internal business process. As can be analyzed, the decision to consolidate the current reporting systems results in a positive impact on the organization, mainly for financial reasons. The other perspectives will have positive impact as well.
Conclusion
The architectural scorecard can support decisions by showing the impact of a decision on the different perspectives of an organization. This impact is positive in all perspectives for the decision about consolidating the reporting systems. It is imaginable that an architectural decision generates a negative impact on one or more organizational perspectives. This emphasizes the fact that human decision-making is still necessary and that this architectural scorecard is only supporting the decision- making process. But using this scorecard for the process of decision-making is more objective and shows well the value of a decision for Unilever.
The architectural scorecard improves the communication showing the reasons of a decision to local IT. Such a decision is justified when it generates value for Unilever.
So this scorecard makes the communication of architectural decisions easier. As an example a decision about the consolidation of reporting systems is analyzed. This analysis shows a definite positive impact of this decision on the Unilever organization.
Being able to show this removes possible barriers of resistance.
Finally the architectural scorecard also supports the justification of the costs involved with the maintenance of an IT-architecture. Looking at the financial perspective it can be seen that the consolidation of reporting systems generates secure savings of 1.2 million Euros with possible additional savings up to 3 million Euros. Further it is these decisions improving the Unilever Organization as a whole that can be analyzed in the other three perspectives: Learning and Growth, User, and Internal Business Process.
Concluding it can be said that the architectural scorecard can support the decision concerning business applications. Furthermore the scorecard is useful in the communication of these architectural decisions towards local IT and it is the architectural scorecard able to show the value of architectural decisions for Unilever.
2. Technical components
The second decision is about the standardization of databases. This is partly an architectural decision, where the question is whether to replace the current standard IBM P5/Oracle by the HP IA64/SQL 2005. This decision is an architectural decision because of the fact that the decision is made which database will be the standard.
Although the architectural scorecard is limited to business application, it is useful to
see how usable and applicable the architectural scorecard is for non-business applications.
The main benefit of this back-end system is the financial savings. These savings determine the decision, where the other perspectives have a negligible influence on the choice. This can be explained by stating that these back-end systems do not have a direct impact on the users of an application.
Conclusion
Concluding it can be stated that the architectural scorecard supports the architectural decision-making process. This is being performed by showing the value of this decision in the financial perspective. Although the other perspectives generate a negligible value it can be showed that the decision generates savings for Unilever. So, the scorecard also justifies a decision driven by savings, showing that the decision does not have any negative consequences for the Unilever organization. Being able to show this, the design authority department is able to communicate the architectural decision to local IT and also to justify their own existence.
Evaluation
A management solution has to be relevant and solid. The architectural scorecard is relevant and solid, and therefore applicable to the situation inside Unilever Europe IT.
The scorecard is a powerful tool to support architectural decisions concerning business applications, providing insight in the value of such a decision for Unilever. This value is expressed in the different areas of the organization, being the financial, user, internal business process, and learning and growth area. The decision-making process is improved because of the availability of insight in the consequences of a decision for the organization.
The scorecard also improves the communication of architectural decisions by providing the same insight, the consequences of a decision for the organization, to local IT.
Finally it is possible to justify the existence of the design authority department by providing insight in the savings or costs, and the advantages or disadvantages of an architectural decision for Unilever.
Although non-business applications do not always have a high influence on the non-financial perspectives is it important to apply the balanced scorecard also to these decisions. Doing this makes the communication of architectural decisions easier, and also the decision-making, by showing the fact that besides the positive financial effects, no negative effects are generated by that decision.
Table of Contents
PREFACE _______________________________________________________________________________ 3 SUMMARY______________________________________________________________________________ 4 INTRODUCTION _______________________________________________________________________ 13
DIAGNOSIS____________________________________________________________________________ 13 DESIGN_______________________________________________________________________________ 14 CHANGE______________________________________________________________________________ 14 EVALUATION __________________________________________________________________________ 14
CHAPTER 1 COMPANY DESCRIPTION ___________________________________________________ 15
1.1GENERAL __________________________________________________________________________ 15 1.1.1 History ________________________________________________________________________ 15 1.1.2 Present ________________________________________________________________________ 16
1.2UNILEVER EUROPE-IT ________________________________________________________________ 20 1.2.1 Structure_______________________________________________________________________ 20 1.2.2 Architecture vision _______________________________________________________________ 20
1.3DESIGN AUTHORITY DEPARTMENT_______________________________________________________ 21 1.3.1 Mission ________________________________________________________________________ 21 1.3.2 Role __________________________________________________________________________ 21 1.3.3 Responsibilities _________________________________________________________________ 23 1.3.4 Organizational structure __________________________________________________________ 24 1.3.5 Definition enterprise architecture ___________________________________________________ 24 CHAPTER 2 PRELIMINARY RESEARCH__________________________________________________ 25
2.1OBJECTIVE _________________________________________________________________________ 25 2.2PROBLEM SITUATION _________________________________________________________________ 26 2.2.1 Problem-owners analysis __________________________________________________________ 26 2.2.2 Problem description ______________________________________________________________ 26
2.3PROBLEM CLASSIFICATION_____________________________________________________________ 27 2.4CORE PROCESSES DESIGN AUTHORITY ____________________________________________________ 28 2.4.1 Planning _______________________________________________________________________ 29 2.4.2 Imposing_______________________________________________________________________ 29 2.4.3 Monitoring _____________________________________________________________________ 29
2.5STAKEHOLDER ANALYSIS______________________________________________________________ 29 2.5.1 Definition ______________________________________________________________________ 29 2.5.2 Stakeholders ____________________________________________________________________ 30 2.6SUMMARY__________________________________________________________________________ 32
CHAPTER 3 RESEARCH ISSUE __________________________________________________________ 33 3.1PROBLEM DEFINITION_________________________________________________________________ 33
3.1.1 Main objective __________________________________________________________________ 33 3.1.2 Main question___________________________________________________________________ 33 3.1.3 Preconditions ___________________________________________________________________ 34
3.2SCOPE_____________________________________________________________________________ 34 3.3CONCEPTUAL MODEL_________________________________________________________________ 34 3.3.1 Functional problems _____________________________________________________________ 35 3.3.2 Instrumental problem _____________________________________________________________ 36 3.3.3 Parameters _____________________________________________________________________ 37 3.4SUB-QUESTIONS _____________________________________________________________________ 38
CHAPTER 4 THEORETICAL FRAMEWORK ______________________________________________ 39
4.1ITARCHITECTURE ___________________________________________________________________ 39 4.1.1 Definition ______________________________________________________________________ 39 4.1.2 Architects & architecture process ___________________________________________________ 40 4.1.3 Benefits________________________________________________________________________ 42 4.1.4 Summary_______________________________________________________________________ 43
4.2ORGANIZATIONAL DECISION-MAKING ____________________________________________________ 44 4.2.1 Management science approach _____________________________________________________ 44 4.2.2 Carnegie model _________________________________________________________________ 45 4.2.3 Incremental decision process model _________________________________________________ 46 4.2.4 Garbage can model ______________________________________________________________ 46 4.2.5 Contingency decision-making framework _____________________________________________ 48 4.2.6 Summary_______________________________________________________________________ 49
4.3THE BALANCED SCORECARD____________________________________________________________ 49 4.3.1 Perspectives ____________________________________________________________________ 49 4.3.2 Usability _______________________________________________________________________ 51 4.3.3 Summary_______________________________________________________________________ 51 CHAPTER 5 ORGANIZATIONAL DECISION-MAKING AT UNILEVER _______________________ 52
5.1CURRENT DECISION-MAKING PROCESS____________________________________________________ 52 5.2CONTINGENCY DECISION-MAKING FRAMEWORK_____________________________________________ 53 5.3CHARACTERIZATION__________________________________________________________________ 54 5.3.1 Management science approach _____________________________________________________ 54 5.3.2 Carnegie model _________________________________________________________________ 55 5.3.3 Incremental decision process model _________________________________________________ 55 5.3.4 Garbage can model ______________________________________________________________ 56 5.3.5 Summary_______________________________________________________________________ 56 5.4DECISION-MAKING PROCESS CHANGE_____________________________________________________ 56
CHAPTER 6 MODEL AND DRIVERS ______________________________________________________ 58 6.1DEFINITION DRIVER __________________________________________________________________ 58
6.2 ARCHITECTURAL BENEFITS_____________________________________________________________ 59 6.3DRIVER REQUIREMENTS_______________________________________________________________ 60 6.4MODEL-TYPE _______________________________________________________________________ 61 6.5APPLICABILITY______________________________________________________________________ 62 6.5.1 Changes _______________________________________________________________________ 62 6.5.2 Perspectives ____________________________________________________________________ 63 6.5.3 Scale__________________________________________________________________________ 64 6.5.4 Weight ________________________________________________________________________ 64 6.6SUMMARY__________________________________________________________________________ 65
CHAPTER 7 ARCHITECTURAL SCORECARD _____________________________________________ 67
7.1FINANCIAL_________________________________________________________________________ 67 7.1.1 Definition and purpose____________________________________________________________ 67 7.1.2 Method of use ___________________________________________________________________ 67 7.1.3 Value of an architectural decision ___________________________________________________ 68 7.1.4 Conclusion _____________________________________________________________________ 69
7.2LEARNING AND GROWTH ______________________________________________________________ 69 7.2.1 Definition ______________________________________________________________________ 70 7.2.2 Drivers ________________________________________________________________________ 70 7.2.3 Weight ________________________________________________________________________ 72
7.3USER______________________________________________________________________________ 73 7.3.1 Definition ______________________________________________________________________ 73 7.3.2 Drivers ________________________________________________________________________ 73 7.3.3 Weight ________________________________________________________________________ 76
7.4INTERNAL BUSINESS PROCESS___________________________________________________________ 77 7.4.1 Definition ______________________________________________________________________ 77 7.4.2 Drivers ________________________________________________________________________ 77 7.4.3 Weight ________________________________________________________________________ 80 7.5CONCLUSION _______________________________________________________________________ 81
CHAPTER 8 APPLICATION______________________________________________________________ 83
8.1BUSINESS OBJECTS___________________________________________________________________ 83 8.1.1 Business Objects – the application___________________________________________________ 83 8.1.2 Business Objects – the supplier _____________________________________________________ 84 8.1.3 Change ________________________________________________________________________ 85 8.1.4 Reporting systems________________________________________________________________ 86 8.1.5 Architectural scorecard – applied ___________________________________________________ 86
8.2TECHNICAL COMPONENTS FOR SAPBW SYSTEMS___________________________________________ 87 8.2.1 Background ____________________________________________________________________ 87 8.2.2 Architectural Scorecard - Applied ___________________________________________________ 88 8.2.3 Conclusion _____________________________________________________________________ 88
CHAPTER 9 CONCLUSIONS AND RECOMMENDATIONS __________________________________ 89
9.1CONCLUSIONS_______________________________________________________________________ 89 9.2EVALUATION _______________________________________________________________________ 91 9.2.1 Usability _______________________________________________________________________ 91 9.2.2 Usability for Architectural decisions _________________________________________________ 91 9.3RECOMMENDATIONS__________________________________________________________________ 93
BIBLIOGRAPHY________________________________________________________________________ 94
APPENDIX I ORGANIZATIONAL STRUCTURE UNILEVER EUROPE ITERROR! BOOKMARK NOT DEFINED.
APPENDIX II ARCHITECTURAL SCORECARD BUSINESS OBJECTS __ ERROR! BOOKMARK NOT DEFINED.
APPENDIX III ARCHITECTURAL SCORECARD HP IA64/SQL 2005 ____ ERROR! BOOKMARK NOT DEFINED.
APPENDIX IV POLICY FOR TECHNICAL COMPONENTS FOR SAP BW SYSTEMS______ ERROR!
BOOKMARK NOT DEFINED.
Introduction
One is a lonely number, unless you are Unilever, one of the largest producers of some 400 packaged consumer goods. Unilever operates in nearly all countries in Asia, Africa, North America, the Middle East, Western Europe, and Latin America. The company's brand names for frozen foods, soap, and tea include Birds Eye, Dove, and Lipton. Unilever is part of the Unilever Group owned by the Netherlands-based Unilever N.V. and UK-based Unilever PLC.
Unilever has two global categories, Home & Personal Care and Food1.
Unilever came into existence in 1928 as the result of the merger of a Dutch company and a British company. This was the start of a series of mergers, most of them through acquisitions.
Because of these mergers the company has many different divisions and, as a consequence, many different IT-systems.
Forced by the market, inside Unilever the need arose to take advantage of its scale and to create synergy between these different divisions. To address to this need, Unilever started the one Unilever program. As a result of the merger of the former pillars Foods and Home &
Personal Care the design authority department came into existence.
The main responsibility of the design authority is the so-called IT-architecture. The purpose of maintaining this architecture is result in cost reduction, but there are more goals the architecture has to addresses.
The design authority department is interested in the design of the decision-making process, in order to improve the decision-making and communication.
To perform this research the DOVE-model of De Leeuw is used2. This model consists of four phases: diagnosis, design, change, and evaluation.
Diagnosis
The first phase is the diagnosis. A problem indication is available. This indication is a rough question about what to investigate. This is the presence of a couple of problems. Using this indication, the ultimate goal of this phase is to come to a problem statement. This problem statement is more exact than the problem indication and provides direction for the solution.
The diagnosis phase consists of three aspects:
1 Source: http://www.hoovers.com/
2 Leeuw, de, A.C.J., Bedrijfskundige Methodologie - management van onderzoek (Management Studies Methodology – managing research), Assen, Van Gorcum, 1996
1. The first aspect is to look multiform at the problem. This means developing a good view on the different aspects of the problem. An important part of this aspect is the use of the root definition stated by Checkland3. This root definition is a statement of the core processes of the organization. The root definition is stated in paragraph 2.4, where the core processes of the design authority are explained.
2. The second aspect is the assessment of the problem. The problem is assessed through the use of a problem-owners analysis and through other tools to define the problem.
This assessment is done in paragraphs 2.2 and 2.3.
3. The last aspect of the diagnosis phase is the description. Describing is the problem- oriented mapping of the system using modeling and concepts. The most important part is the delineation of the system. This is performed in chapter 3.
The product of the diagnosis phase is the main problem statement, which can be found in paragraph 3.1.
Design
The design phase consists of two parts: the first part to determine the direction of the solution and the second part is the elaboration of the concrete design. Determining the direction of the solution is the choice of a way to solve the problem as stated in the diagnosis phase. This is done in chapter 4, where the main theories used are explained. Thereafter the concrete design is elaborated. This is performed using the theory described in chapter 4. The first step is to describe the current decision-making process using the theory described in chapter 4; this can be found in chapter 5. Thereafter the framework of the instrument is built in chapter 6. The final step of this phase is to build the solution. This is described in chapter 7.
Change
The third phase is the change-phase in which the solution is implemented. This implementation is performed by the application of the architectural scorecard to two decisions made last year. The scorecard is applied to these decisions in chapter 8.
Evaluation
This is the last phase. The evaluation is achieved in chapter 9, where the conclusion, evaluation, and recommendations are stated.
3 Checkland, Scholes, Syllabus Ontwerp van Bedrijfskundige Systemen (Reader Design of Management Systems), Rijksuniversiteit Groningen, 2003
Chapter 1 Company description
The environment of the research will be described in this chapter. First Unilever as a whole comes up for discussion, thereafter Unilever Europe IT will be described, and finally the department where the problem appears, the design authority department will be described.
1.1 General
Unilever will be introduced in this first paragraph by providing a brief description of the history. The reason for this is because Unilever is a company with a large history and today the company is influenced by the inheritance of the past.
After this description the present will come up for discussion. An overview of the brand- portfolio, the company structure, the mission, the purpose, and the strategy will be given.
1.1.1 History4
Nowadays Unilever is a global multinational. It will be hard to find someone who has never bought one of its products. Everybody definitely knows one of its products. But how did it all start? The following passage gives a short overview of the origins until the present.
In the year 1870 two Dutch competitors have both a successful butter company in Oss, the Netherlands. After a few years they also started to produce margarine. They exported their products and it was going so well that the demand exceeded the supply. In 1927 the two competitors decided to merge their activities in “De margarine unie”. The years after that merger more European companies decided to join this union.
Around the same time, William Hesketh Lever built a large soap company in England in 1885. This soap company, called the Lever Brothers, was so popular that it had to build soap factories all over the world. In 1917 the company extended their product-line with fish, ice, and tins.
De margarine unie and the Lever Brothers decided to merge their activities in 1930. The reasons for the merger were clear. The same target customer group, namely the housewives, and their joint interests in the market for raw materials were the main reasons. This merger created more market power in advertising and the acquisition of materials.
4 Source: http://www.unilever.com
After the merger there were some difficult years due to the recession in the 30’s and World War II. Following World War II, business boomed as new technology and the European Economic Community lead to rising standards of life.
In the 60’s the world economy and Unilever expanded. Unilever set about developing new products, entering new markets, and running a highly ambitious acquisition program.
As Unilever in the 80’s became one of the largest companies of the world, it started to concentrate on its core brands and core products. After that, in the 90’s Unilever expanded further to eastern and central-Europe and continued to concentrate on their core brands. At the moment Unilever are on their way to reduce their brand portfolio to around 400 core products.
1.1.2 Present
The different organizational aspects come up for discussion in this section. Respectively the organizational structure, the portfolio, the mission, and the organizational strategy are described. Finally some general information will be given.
1.1.2.1 Organizational structure5
The organizational structure of Unilever recently changed to a matrix structure. Hitt provides the following definition for a matrix organization6:
A matrix organization is an organizational structure in which there is a dual structure combining both functional specialization and business product or project specialization. Although complicated, effective matrix structures can lead to improved coordination among a firm’s various divisions.
5 Cescau, P.M., Organizational announcement, Unilever, 21-03-2005
6 Hitt, M.A., Ireland, R.D., Hoskisson, R.E., Strategic management: competitiveness and globalization, Cincinatti, South-Western College Publishing, 2001
Figure 1 top organizational structure CEO
Europe
Americas Asia / Af rica Finance
Foods
HPC HR
Categories Regions Functions
The matrix structure of Unilever has three pillars namely regions, categories, and functions. In figure 1 this matrix structure is pictured.
The regions are primarily responsible for the communication with and the acquisition of customers, managing Unilever’s business in the region and deploying brands and innovations effectively. The regions lead resources in customer development, brand building, and regional supply chain and are accountable for the growth, cash flows and the short-term
development of market shares.
The Categories are fully responsible for brand development and innovation as well as brand and category strategy. Categories will lead all brand development and R&D resources, including those in consumer and market insight.
The Categories are accountable for long-term value creation in the business by driving medium to long term market share, brand health, and innovation. They will also lead the strategic elements of the Category Supply Chain.
The Regions will progressively evolve to be organized by geography and will start to deliver the benefits of scale through the creation of one Unilever operating company per country.
The third pillar is the functions. Functions work across category and regional levels and examples of functions are HR, IT and Finance. The functions deliver services and, in the case of Europe IT, they deliver services to the region Europe.
The current organizational structure of Unilever Europe is stated in figure 2. The functions are staff departments. SVP stands for senior vice president, where in the underlying groups GVP stands for group vice president. In the current organizational structure the GVP’s are responsible both for regions and categories. The goal is to move to the organizational structure as stated in figure 3.
Figure 2 Current organizational structure Europe
Functions
Large countries
GVP small countries Western Europe SVP Marketing
Operations for categories
GVP CEE Regional
President
Responsibility for maximal country synergies Responsibility for category performance Euro Exec
Regional President
CCDO / SVP Customer
Development SVP Finance
SVP Supply chain
GVP Foods GVP ICF GVP HPC
All Western European BU heads Foods
Italy Switzerland Austria Nordic
UK Ireland Greece
CEE All Western
European BU heads ICF*
All Western European BU heads HPC
Germany Portugal VP Communications
SVP HR
France NL Belgium Spain
GVP CEE
1.1.2.2 Portfolio
A few years ago Unilever used to have a big brand portfolio containing about 1600 brands.
However since 1999 Unilever concentrates on the 400 key brands. The other brands are sold or just disappeared.
Unilever produces very diverse products, and these products can be divided into two categories: Foods and Home & Personal care. These are also the two divisions Unilever used to base its organization on. Recently this two-division structure changed to the above mentioned matrix structure but these two divisions are in the new structure still split in the categories part.
Some well-known brands are Blue Band, Ola, Knorr, Bertolli, Slimfast, Cif, Omo, Rexona, Lipton, Dove, and Axe.
1.1.2.3 Purpose
Unilever’s corporate purpose states that:
"To succeed requires the highest standards of corporate behavior towards our employees, consumers and the societies and world in which we live."
1.1.2.4 Mission
The mission of Unilever is:
To add vitality to life. We meet everyday needs for nutrition, hygiene, and personal care with brands that help people feel good, look good and get more out of life.
Figure 3 Organizational structure Region Europe 2007
This mission is a very important part of the Unilever strategy. Everything the company does is related to this mission.
1.1.2.5 Organizational strategy
The mission and purpose of Unilever determine the longer-term strategy. This strategy is made operational in the organizational strategy. From 1999 till 2004 Unilever used a strategy called “path to growth”. This was a five-year plan that included the following goals:
reshaping the brand portfolio to concentrate on core brands significant improvements in supply chain and innovation a closer consumer focus
the building of an agile, enterprising business culture gross profit margin of 15-16%
growth of sales of 5-6%
Path to growth officially ended in 2004 and the main objective, growth, was not reached.
After this disappointing result Unilever cancelled its newly developed strategy and decided to concentrate on the mission, where the key word is vitality.
Further Unilever adds three goals, which are the generating of a free cash flow of €25-30 billion from 2005 till 2010, improvement of sales from 2-4%, and to win with customers.
Customers are the retailers for Unilever, for example Ahold, and Tesco. The people using the products are the consumers. The main purpose of gaining more customers is to create a situation of mutual benefit.
1.1.2.6 General
Unilever is based on business units. There are two types of business units: sourcing units, and marketing sales units. The sourcing units produce the products. These sourcing units are located in different countries and are organized by brand. For example the Blue Band sourcing unit based in Rotterdam produces for several countries in Western Europe.
These sourcing units produce for the marketing-sales units in the different countries. The marketing sales units are responsible for the marketing and sales of the Unilever products in one country or, if the business is small, in a group of countries.
In total, Unilever is selling products in about 150 countries all over the world and is producing products in approximately 100 countries with a total of 234,000 employees. Every day a 150 million times someone chooses a Unilever product. The total yearly turnover in 2004 was €40,400 million resulting in a net profit of €1,870 million.
1.2 Unilever Europe-IT
A brief description of Unilever Europe IT will be given in this paragraph. The main aim is to clarify the position of the design authority department inside Europe IT and in the organizational structure of Europe IT. The vision of enterprise IT-architecture will also be stated.
1.2.1 Structure
Using the organizational structure stated in figure 1, three pillars can be identified, namely categories, regions, and functions. Europe IT can be classified in the region Europe and the function IT. IT as a function falls under the responsibility of the function Finance. The organizational structure of Unilever Europe IT is stated in appendix A.
At the top of the Europe IT organization is Neil Cameron. He is the CIO and responsible for the whole IT governance of Unilever Europe. There are three people directly beneath him:
The vice-president Countries, he is responsible for the IT in the business units of the different countries.
The vice-president Services, he is responsible for the technical infrastructure of Unilever Europe.
The vice-president Regional Systems and Processes, he is responsible for the European systems, the maintenance and deployment of these systems. He is also responsible for the design authority.
These vice-presidents form together with the CIO the IT Leadership team. They make sure the architecture is implemented.
1.2.2 Architecture vision
The goal concerning IT-architecture is one IT-architecture for Unilever. There is freedom inside the framework, but not outside. Architectural diversity exists only in response to corporate business goals.
The vision, inside Europe IT, for the architecture is7:
The Unilever IT leadership team seeks to develop, maintain, and facilitate the implementation of the top-level IT architecture for Unilever.
7 The guiding principles of architecture, presentation Unilever, 11-03-2005
This architecture will serve Regions and Operating Units as a reference point to facilitate the efficient and effective co-ordination of common business processes, information flows, systems, and investments.
In time business processes and systems will operate seamlessly in an enterprise architecture that provides models and standards that identify and define the information services used throughout Unilever.
1.3 Design Authority department
The last aspect coming up for discussion is the design authority. The design authority is the department having a problem.
The mission, role, organizational structure, responsibilities, and a definition of enterprise architecture come up for discussion respectively. These are important to provide a general description of the design authority. The core process and the stakeholders are respectively stated in paragraph 2.4 and paragraph 2.5.
1.3.1 Mission
The mission statement of the design authority is:
To harness our knowledge of business and technology, to design sustainable architectures, which meet our evolving business needs.
1.3.2 Role
The direct environment of the design authority department consists of two main entities, which are the design authority department and the extended design authority group. The main roles of these will be pointed in this paragraph.
1.3.2.1 Design Authority
The core team of the design authority consists of four architects, a general director and a manager emerging technologies. Each of the four architects has an own area of expertise, which are respectively integration, technology, information, and planning and transaction.
The core team is responsible for the planning, communication, and monitoring of the IT- architecture of Unilever Europe. In short, this department is responsible for the implementation of the IT- architecture vision as mentioned in section 1.2.2. The design authority communicates the high level design to the extended design authorities.
1.3.2.2 Extended Design Authority group (XDA)
The extended design authority group consists of representatives from departments around the design authority, including an architect representing the design authority department. These
representatives are stakeholders in the architectural process and come up for discussion in paragraph 2.5. The architect, representing the design authority department leads the architectural process inside an XDA.
The main responsibilities of each XDA are on the area of expertise of its architect. As a consequence four extended design authorities exist. All members of an XDA can put issues into discussion.
The XDA has to develop the target architecture in detail and has to solve the issues that have been put into discussion.
Each of the four XDA’s will be discussed shortly in this section and their main responsibilities will be described.
Information architecture
The XDA information architecture is responsible for the information systems inside Unilever Europe. This responsibility can be divided into two major tasks: the first task entails the management of the reporting requirements of end-users and the second task is setting standards for these information systems.
Integration
The main role of the XDA integration is to identify the future vision and strategy of the IT integration environment within Unilever Europe. Integration can be defined as the communication between the different applications. Integration has to do with infrastructure, but also with information. This information is called a business object. The business object is the message that has been sent from one to another application. This message has several characteristics that differ per application. Because of this difference a solution has to be built to streamline the communication.
Technology
The technology XDA is responsible for four key areas:
1. landscape design 2. technical components 3. technologies
4. project portfolio-management
In these areas the XDA group concentrates on the technological side of these areas. This has to do with the hardware, the operating systems, and the technical view on applications.
Planning & Transaction
Inside Unilever a lot of ERP systems are used. The biggest part is the SAP-systems. This group has just been set up in the last few months. They are responsible for these systems.
1.3.3 Responsibilities
Given these roles for the design authority department key-responsibilities can be identified.
The design authority’s main responsibility is to monitor the quality of the system landscape of Unilever Europe. This main responsibility can be divided into four areas. These four areas are accountability, order, co-development, and ownership and communication. These areas imply some activities:
1.3.3.1 Accountability
Accountability is one of the most important responsibilities of the design authority. This contains several things, namely the preparation of solutions for strategic business initiatives, the proving and introduction of new technologies, the managing of the convergence to the Unilever Europe IT landscape, and ensuring those professional standards and policies do exist.
1.3.3.2 Order
The design authority has various activities to perform to bring order in the diverse array of the IT-landscape. The main activity is the responsibility for the Unilever Europe IT integrated architecture. To take this responsibility the design authority has to ensure that proposed changes are fully considered from an architectural perspective. Other activities in this area are managing the complexity – current and to come – and the response to a need for stronger governance and solution sign off.
1.3.3.3 Co-development
The design authority has to recognize that solutions design is a collective process in order to maximize business value for Unilever. Further the design authority has to respond to a need to tap distributed expertise within Unilever Europe.
1.3.3.4 Ownership and Communication
This responsibility is about responding for a requirement to define IT design principles, technical choices, and standards for applications and interfaces.
1.3.3.5 Summary
The design authority department is responsible for the overall planning of the IT-architecture of Unilever Europe. The design authority has to provide solutions for the Business Units and has to communicate these solutions. Further the design authority has to ensure that the proposed changes are implemented.
These responsibilities have to be taken from the perspective of information, data, technology, application, and integration.
The design authority provides a migration roadmap to reach the target IT-architecture, in order to help the users with the communication of the target landscape.
1.3.4 Organizational structure
The organizational structure of the design authority is stated in figure 4. This is a not a hierarchical, but a functional structure. The four architects each have their own architecture team, the already mentioned extended design authority.
1.3.5 Definition enterprise architecture
The definition for the enterprise IT-architecture inside Unilever Europe is the following one:
Enterprise IT-architecture is the collection of strategic and architectural disciplines that encompass the Information, Business System and Technical Architectures.
The definition of enterprise architecture will be broadened and explained in paragraph 4.1.
Enterprise architecture is the process of managing the evolution of complex relationships of interrelated IT-systems to meet underlying business objectives. Although the enterprise architecture may seem like an abstract concept, the process is actually similar to that of real- world architecture. These are the review, design, build, and maintenance phases.
Figure 4 Organizational structure design authority
Aaron Rajan strategy and emerging
technologies
Colin Dittmer support
David Wardley information architecture
Ronald Stoppelenburg technical architecture
Colin Dittmer planning & transaction
Theo Jassies integration Guy Lucq
Director
Chapter 2 Preliminary research
It is necessary to have a clear understanding what to investigate before starting with the research. The preliminary research helps identifying the problem definition. In this chapter the preliminary research is being performed.
The first step is making a statement of the objective for the preliminary research. The objective of the preliminary research is the starting point in the process of the identification of the definitive objective.
Secondly, when the preliminary objective is stated, successively the problem situation, the problem classification, and finally the core processes of the design authority. This is performed in order to create a clear view on the problem and to come to a starting point for the research issue.
2.1 Objective
The preliminary research will be performed in order to identify the main management- problem. The main objective for the preliminary research is:
Mapping the management-problem, resulting in a qualitative high-grade objective and the design of a good approach for the research, in order to solve this problem.
So the goal of the preliminary research is to come to an objective in order to solve the problem of the design authority department.
This preliminary research is being performed in order to identify the correct problem definition. This, because the problem definition set by Unilever is not complete. De Leeuw states8:
The problem definition set by the client is not always complete. A correct problem definition has to contain an objective, a phrasing of the main question, and pre- conditions. Besides this the problem definition has to meet the requirements of relevance, the possibility of investigation, and suitability. As a result there are in fact two objectives. The first objective is the starting point for the preliminary research and it leads to the second, definitive objective for the main research.
8 Leeuw, de, A.C.J. , Bedrijfskundige Methodologie - management van onderzoek (Management Studies Methodology – managing research), Assen, Van Gorcum, 1996
2.2 Problem situation
Two elements are identified in this paragraph. The first element is the problem-owner and the second element is a description of the main problems.
2.2.1 Problem-owners analysis
When identifying the definitive objective it is necessary to perform a problem-owners analysis. This analysis answers the question ‘who is worried about what’.
The persons that are worried are identified in the answer on this question. Although there might be only one person or department that is worried, it is still useful to do this analysis in order to get a clear view on what the problem exactly entails and who exactly owns the problem. To start with, the customer is identified. The customer is the design authority due to the fact it owns the assignment. Besides customer is the design authority also the main problem owner, because this research is performed in order to solve the problems of this department.
There are not more problem-owners in this preliminary stadium. Primarily the design authority has a problem that has to be solved.
2.2.2 Problem description
Now the problem-owner is defined, its main problems are stated. The design authority department is, as already mentioned, responsible for the planning, monitoring, and communication of the IT-architecture. Summarizing, the design authority is responsible for the IT-architecture of Unilever Europe.
Three problems appear in this architectural process:
1. Department stakes as primary driver of architectural decisions
Architectural decisions are unstructured decisions, made in a cross-departmental group. These are decisions about the technology, infrastructure, and applications that are planned to be used for the next five years inside Unilever Europe.
The problem is that departmental stakes are highly influencing the outcome of the architectural process. The outcome of a decision is more of a compromise than a highest value generator for Unilever. Summarizing, the problem is often that the decisions made are not generating maximal value for Unilever.
2. Being unable to show the value of architectural decisions
The second problem is the need to be able to show the value of maintaining an enterprise IT architecture, in order to justify the costs involved with the architectural process. These
