Feature

posted 23 Dec 2004 in Volume 1 Issue 6

Intranet consolidation

Winner of the ‘Best intranet/extranet project 2004’ category at the recent International Information Industry Awards in the UK, Boots has successfully consolidated seven intranets into one. Read on and learn how.

This case study will provide an overview of intranet and portal developments at Boots The Chemists, a large chain of health and beauty stores in the UK.

The story starts three years ago when we had seven very different intranets within the business. An intranet rationalisation project was initiated across the Boots Group to tackle this situation, which included the introduction of a content-management system (CMS). With the benefit of hindsight, I’ll review the benefits and challenges of introducing the CMS and how the intranet development team created different views of content for different audiences across the business.

About the company

Anyone reading this article that lives in the UK will no doubt know what Boots does, but those from most other countries may not have heard of the retail chain whose head office is based in Nottingham in the UK.

The group has three distinct areas of the business. The first and most visible in the UK is our chain of over 1,400 health and beauty stores (similar to drugstores). The group has expanded overseas in recent years, with Boots stores opening in Ireland and Thailand, and implants opening in Taiwan and Hong Kong with AS Watson stores. A similar implant model is underway in the US with Target and CVS. In addition, we sell some of our key brands via other retail outlets worldwide – examples of this are ‘No7’ and ‘17’ – two of the leading cosmetics brands in the UK.

The second side of our business is our international healthcare over-the-counter medicine business. This includes brands such as Nurofen, Optrex, Strepsils and Clearasil. These are sold via many different outlets in over 80 countries worldwide.

Finally, our internet business, which is ever expanding, sells all these products as well as providing an online pharmacy and an outlet for other product ranges such as telephones, computers and kitchen appliances.

Too many intranets

As mentioned earlier, three years ago the group had seven different intranets. Each intranet had a very different look and feel, as you’ll see from the example screen shots (figure one, opposite). Different sites also had very different designs and navigation.

In terms of the overall project, we had three areas to consider: business issues; technical issues; and the future business requirements of web technology.

Our business issue was really that we had seven different intranets, all with disparate designs and navigation. Because of this the end-user experience was far from ideal, with users having to relearn their way around every site they visited. Content was also organised in the same way as our organisational structure – a site for every department and so on. This meant that to find anything, users needed to understand the structure of the business before they started. This in turn encouraged silo thinking – far from an ideal situation, especially for anyone new joining the business.

Technically, the intranets were hosted on different servers, all with different publishing models, using different software (mainly Dreamweaver and FrontPage) and therefore requiring different technical support. This was incredibly inefficient to support, especially at a time when we were outsourcing our IT department and were looking for increased efficiencies in our support to help reduce costs.

We also needed to consider our changing business. As a group we had reorganised from seven independent businesses into one with only two divisions – UK retail and international over-the-counter brands. The business was working hard to integrate and work as one, and we needed an intranet to support this. We also knew SAP systems were due to be implemented, with major changes to our core purchasing and HR processes – and this would all be delivered via a web-based SAP interface on our desktops. Finally, we needed to make sure we would be able to comply with new Disability Discrimination Act regulations, which require strict adherence to web-accessibility guidelines.

To tackle these issues and future requirements, an intranet rationalisation initiative was started three years ago. It had clear business and infrastructure objectives. The business objectives were to:

Design a new, consistent user interface and information architecture – improving findability, especially for new/recent hires who didn’t already understand the organisational structure of Boots;
Transfer all content to the new information architecture and some initial content to the new look and feel;
Create, publish, maintain and enforce standards for policies and processes;
Establish a centralised intranet management team to identify and manage the extensive change required to bring about the above objectives.

Our infrastructure objectives were to:

Implement a single CMS to consolidate multiple intranet platforms to a centralised model, supported centrally, but allowing distributed publishing;
Provide the means to target different areas of the business (eg, stores/non-stores);
Build an infrastructure that enables effective integration of new web applications (eg, SAP and portal technology).

The project started in 2001 and was completed in January 2003, coinciding with the introduction of the intranet management team. This team took over the ongoing management of the intranet publishing process and took ownership of the CMS.

A customised publishing model

Implementing a CMS has enabled us to develop a customised publishing model for the organisation. Like many other implementations in other companies and industries it fundamentally separates centrally managed design from devolved authoring of content. The centrally managed design meant we could deliver a consistent design across the business, whatever the business area or audience.

It allowed us to deliver a single look and feel, even if the content was tailored to different business areas, which supported the wider business objectives of creating a more integrated working environment. It also meant authors within the business no longer needed to spend time and resource worrying about the ‘design’ of their web content.

This in turn supported the authoring of content by subject experts (not just the person in that team who was a bit ‘techy’ and seen as the web expert), which meant content was more clearly owned by the correct people. Approval rights also sit out with the business so the subject experts, or those responsible for them, can approve content without having to go through a central editorial function that has limited knowledge of the subject matter.

Basically, the authors now fill in forms, or templates. We only have six templates, trying to keep the complexity down while making them as flexible as possible to support the different needs of different authors. Authors fill in the relevant boxes for content, and browse to other pages to create links or to image files to incorporate pictures. For example, the template in figure two (p24), when saved and generated, produces the web page shown in figure three (p24).

The resulting page adopts the design, colours, layout, fonts, bullets and navigation of the central design. The author, by just entering text and thinking about how to split their content into pages, produces a professional looking website. Also, because the layout is similar to other websites, new users of the site will quickly be able to navigate themselves around the content with ease. This is helped by having consistent components such as left hand navigation – a local menu, specific to the site or ‘content area’ – which is defined in one place and automatically included on every page. This local navigation, combined with the global navigation across the top means the user should never feel lost.

Implementing business change

So, the project delivered the new infrastructure, a new CMS, and transferred some content into the new look and feel. So what next?

The final stage of the project was to set up an intranet management team (IMT) to implement this change across more than 350 sites still sitting on old servers. This is where I joined the picture full time as the new group intranet manager.

Our team objectives for the first 18 months were to set up the required guidelines, policies and business processes for creating and managing intranet content; facilitate the transfer of all the ‘old’ content into the new system; manage the business relationship with our newly outsourced IS providers in supporting the new set up; plus worry about all other aspects of managing the intranet.

The IMT reported into the internal communications manager for Boots and was an integral part of the communications team. This helped progress all the communication content, but what about the other 330 plus sites? We had to first work out what all the sites were, what they were about, who owned them, what the individual target audiences were. There were many sites that were old, out of date and had no clear ownership – so just starting this took lots of legwork. Also, the process of consolidating seven intranets highlighted lots of duplicate sites – a good example of this is the fact that we had six different sites about claiming expenses.

Once we understood the full size of the project, to migrate content to the new system we immediately set about working with the content owners. Through one-to-one meetings, workshops, training sessions and ongoing communication we explained why we were moving to the content-management system, what deadlines we were working to and how we could help them. Ultimately, however, they were responsible for moving the content or it would be switched off completely.

The communications team owned language and brand and developed published guidelines. It was stressed that content needed to be user-centric, which might require different content owners to work together to re-author content.

For a higher-level view of a business area, for example to review all finance content, we sought senior-level sponsors who could give a clear steer on what content should be re-authored as a priority and how that content should be presented.

We worked with the training team to develop training courses to support new users of the CMS. The IMT also provided consultancy-type support for people who needed to understand how to structure their site, or how to breakdown the content into sensibly sized pages, for example. We managed the administration system, which set up new users and linked new sites into the relevant drop-down menus for different audiences (as discussed later) once they were on the live server.

Finally, the IMT managed and owned all developments around the intranet – for example, the development of new templates (to ensure they were as generic as possible), the enhancement of templates, ensuring content complied with the new DDA regulations, how content should be presented through the new portal, and so on.

Realising the benefits of a CMS

Authoring is independent of the end-user technology – this means that the author no longer needs to worry about which browser, or which device the end user will be using. Authors just complete the templates and local navigation once and this is stored in the content-management repository. Different presentation templates are then combined with this content to deliver the content in a format suitable for the end-user device or interface.

The content is authored once and can be delivered to many different devices without any further input from author. The design can be changed centrally – for example, if a Disability Discrimination Act review means we want to change the colour of our page titles, or the font size of the section headings – this can all be changed once centrally and immediately reflected across all sites and content.

A single authoring tool – having just one authoring tool across the business means support is more streamlined and authors develop their own communities of mutual support. Gone are the mystique and the domain of technical experts.

Editorial control – there is no longer a central editorial team that has to review all content, even content they don’t understand. However, there is still a structured editorial process. Approval sits with the content experts, so updates are quicker and more efficient. Authors submit their finished pages; they are reviewed by the nominated approver for their content area via e-mail and, if approved, are instantly published.

Most sites are authored and approved within the area of expertise in the business (eg, the catering team publish the menus), however changes in the way we manage our pharmacies may be authored within one team, approved by the pharmacy superintendent’s office and approved again by the legal team.

Version control – all content is versioned within the CMS, allowing content to be rolled back at a document or site level if required. Although this facility is available it has not yet been used in anger.

User-centric navigation model – As we needed to recreate our entire intranet content anyway, moving it from the old systems into the CMS gave us an ideal opportunity to look at the way content was structured. In the old model, many sites were structured around the authoring department rather than the user. We ensured that new content was centred on the user.

A simple example here is looking for information about volunteering at local schools (a scheme Boots runs with schools across Nottingham in the UK). As a user on the old intranet you had to know to navigate from your own intranet to the ‘Boots Group’ intranet, then to ‘investor relations’ and then to ‘community investment’. So this assumed from the start that you knew the community investment team managed volunteering in schools, that you knew they were organisationally part of investor relations and that that team sat within the Boots Group. This made things pretty hard to find unless you already knew where they were or knew the structure of the company well – this was no good for long-term members of staff, let alone new starters. So the navigation was reviewed as part of the project, from a whole company and end-user point of view. This content is now found under ‘Boots & me’, ‘My development’, ‘Volunteering and charities’ – this removes the need to know which department manages what before you can find information.

Central resource management – the new system also allows us to centrally manage resources.

Other benefits include:

Reduced training costs, as we are only using one system;
Content lifecycle management – pages are automatically tagged for review after a fixed time. An e-mail is sent to the relevant administrator, giving them between one week and fours weeks’ notice of content that is due to expire. If the content is not reviewed and approved then the pages are removed;
The workflow for content approval and publishing is mandatory and cannot be avoided – if the workflow isn’t followed then the content isn’t published – so compliance isn’t a problem;
There are many automatically generated index pages, so when new pages are added they are automatically listed in the relevant index pages;
We have a global search mechanism that searches across all content, which we didn’t have before;
Content deployment can be deferred to a particular date or time – especially helpful in avoiding the 5.30am start on annual results day for our communications team.

The challenges

Along with the benefits come the challenges – it wasn’t an easy ride all the way.

Perceived cost – The original justification for the intranet rationalisation project came from the communications and HR side of the business – however, the content management side of the project was driven by IT and many people in the business didn’t understand this area of the project. Once it was installed and people had to re-author their content in this new system, there was sometimes resistance. This resistance centred on time – some people did not see the point in re-authoring something that was already there and working. And money – rumours spread about how much the project and system had cost and many people couldn’t see the benefits. As a result, much of our time before the migration of the content to the new system was actually spent selling the much wider picture, explaining about future opportunities such as portals and personalisation.

Departmental politics – people quite liked the old system of having a departmental site with ‘this is who we are and what we do’ type content. Once we explained the benefits for them of content being user-centric (ie, their content is more likely to be found and used) it became easier – but this was an uphill battle with over 350 sites and site owners to consider. Also, this user-centric design meant departments often had to work together to present a single, integrated area of content for the user. Although everyone often agreed it was the right thing to do, finding the time to work together, agreeing who had overall responsibility and project managing the migration proved tricky in some areas.

Navigation – everyone didn’t like the navigation. Although many appreciated that we had brought together content from many different intranets, and made content easier to find, there were those who still couldn’t find the content they wanted and they were vocal about it. There was also the problem that for 18 months we had the new navigation in place with hundreds of old sites still written in the old way. This meant we had user-centric navigation mixed with new user-centric content and old author-centric content. We always knew this would take up to two years to sort out, but this meant the system did not always make sense to users. We had to convince them it would all be okay in the end.

Time – Finally, one of the biggest challenges was time. We knew this change would take 18 months to two years, and everyone agreed with this timescale and supported the wider business change. But the business was changing rapidly, so we also had to manage and develop the existing business. This was sometimes seen as another change that took lower priority than others – and as people left the group, we would have to start from scratch explaining the whole process again.

A single intranet

The screen shots in figure four (p25) show the new homepage and new versions of the content areas. As you’ll see, they all now have a consistent look and feel, layout and navigation.

Although we had developed a consistent look and feel and a single repository of content areas (sites), different areas of the business still had different information needs, both around the homepage and wanting to only see content areas that are relevant to them. The site administration side of the CMS allowed us to have different homepages for wide audience sectors, managed by the various communication teams with some common and some specific content for each key audience.

We are then able to point the top-level navigation for each audience to the relevant content areas. Differing information needs span from local information, such as our people in Boots Healthcare International France who do not want to know what’s being served in the canteen in Nottingham today, to each area of the business or country seeing different HR policies and advice.

We therefore direct different content areas to different audiences, as demonstrated in figure five. But as all content is from a common repository, any content that is relevant across different business areas will always have a single source, managed in one place by one team. This helps ensure consistency wherever possible.

Portal – beginning true personalisation

One of the key reasons for implementing a CMS was to enable the integration and presentation of content in different ways and through different systems. The first real manifestation of this ability is through our new portal.

One of the first areas of the business to benefit from the use of portal technology is our group of stores. Our store intranet was known as StoreNet, which was re-launched through the CMS in spring 2004. However, it still presented a single version of the store intranet to all stores, so they all viewed the same content. We wanted to provide tools to our store managers that would help them to drive sales, so we looked to portal technology to deliver true personalisation.

The portal for stores – or MyStoreNet – was defined as a change project at the end of 2003 and started in early 2004.

Our key objectives were to:

Display content that was relevant to individual stores;
Enable content to be created in stores for use within stores (eg, simple messages);
Display different content for different roles within a store (for example, pharmacists, store managers, sales assistants);
Display content at the most relevant place for the user, supporting our drive to have as many staff on the shop floor as possible – not stuck behind the scenes. For a sales assistant this might be on a till, for a pharmacist it may on a PC in the pharmacy, for a store manager it may be on a handheld PC on the shop floor.

The screen shot in figure six shows an example of a store manager interface for a particular store. Elements for a store manager include a sales tracker that enables them to set local sales targets and track them against actual sales (via our the back-office servers that are connected to our tills), the ability to display these targets and actual sales on a till for all staff to keep up to date with progress, the ability to create in-store messages for delivery via PCs, tills and handheld PCs, as well as many other new functions.

As you can see, although we are using very different technology, we have maintained the look and feel and just personalised the name – from StoreNet to MyStoreNet. It was intentional not to be seen as launching a whole new tool, with a new name and a new way of doing things. Our staff are comfortable with StoreNet and we wanted this to be seen as just the next version. The term portal sounds good, but means different things to different people and means nothing to many – so we’ve avoided too much technical labelling of the project and describe it as the next version of StoreNet. At the time of writing we are planning the full pilot and roll out to all 1,400 stores over the next six months.

Intranets and portals at Boots

This paper has briefly described our journey from many different intranets to a single CMS. It’s talked about how we migrated over 350 old sites into the new system, while also moving away from author-centric content to a user-centric model. The new model supports a single look and feel, with centralised management of design and devolved ownership and managed content. We now have a single repository of content areas but deliver different views of that content to broad audiences. Finally – going forward, we are using that content to feed new portal developments that will enable true personalisation and application integration.

Helen Day is project consultant, Boots Group, UK