There is no doubt that fuelled by a compelling business need, a portal solution can provide real business advantage. However provisioning a portal when it is a content-managed site that is required, will result in the most expensive website or intranet that an organisation can build.

What then should those organisations keen on entering the portal space consider? Using two case studies this article explores portals and seeks to answer this question by taking a look at:

• the difference between ‘portal as a concept’ and ‘portal as a technology’
• the types of business initiatives that are well-suited to a portal
• the importance of aligning business users’ thinking with that of those working in the information technology (IT) or information systems (IS) departments
• working out whether the business requirement is for a portal or a content-managed site

Enterprise information portals defined

Gaining an understanding of what exactly an enterprise information portal is can be difficult; in part because portals are completely invisible to the end user and in part because there is little agreement as to what exactly constitutes a portal. The earlier article Taking a business-centric approach to portals differentiated between ‘portal as a concept’, and ‘portal as a technology.’

Portals as a concept are very different from portals as a technology

Portals as a concept

Understandably, ‘portal as a concept’ is driven by end-user needs and end-user experience. On the whole, user goals relate to the user experience of staff, and are about making it easier for staff to access information and to complete tasks. Here emphasis is placed on:

• providing staff with a single point of access to business systems
• tailoring (customising or personalising) information to the needs of individual staff (or groups of staff)
• reducing (or eliminating) the need for multiple logins
• providing staff with a single user experience that crosses information systems and technologies

This concept has been around for a long time, and quite a few technologies have had a positive impact. For example, web content management systems have done much to improve both the delivery and management of information.

Portals as a technology

‘Portal as a technology’ on the other hand is driven by technology vendors, who have focused on delivering products that do the following:

• simplify integration issues
• provide single sign-on to targeted applications
• provide personalisation and customisation
• offer a development environment and integration standards
• allow more dynamic delivery

Striking an understanding between IS and the business

It is clear that a well-considered portal can serve the needs of both business users and IS. The danger comes when there is a disconnect between IS as the usual purchasers of technology and, business users who are looking for a more seamless working experience.

For end-users portals promise to remove the frustration experienced in working across many disparate applications. Portals deliver an equally compelling, if different promise to IS departments.

To IS departments, portals provide the assurance that it is possible to retain and leverage the many disparate legacy applications in any given organisation.

The initial goal should be to clearly understand whether the requirement is for ‘portal as a concept’ or for ‘portal as a technology.’

If both IS and the general business are requesting a portal solution, alignment seems assured. This is of course the danger – achieving clarity can be especially difficult as neither party is likely to be aware that there is a difference in requirement or understanding.

At least superficially, the goal of the business stakeholders and the goal of the IS department will appear aligned. In fact one group may be focused on ‘portal as a concept’ and the other on ‘portal as a technology.’ Each of which presents as a very different solution.

It is clear that a well-considered portal can serve the needs of both business users and IS

Ensuring alignment

Reaching a common understanding as to whether the requirement is for ‘portal as a concept’ or ‘portal as a technology’ will require cross examination of the business and IS stakeholders. This investigation will necessarily take in the following areas:

• desired business outcomes
• final product (portal or content-managed site)
• required information resources that will drive the site
• overall business process
• the end-user experience of the site

In looking at the end-user experience of the site, particular focus should be placed on those things that the end-user will consume and the way in which they will do so.

Reaching a common understanding of a ‘portal’ can be difficult

Exploring this in practice

So far we have explored some of the high-level questions that need to be answered when considering the need for a portal.

Building on this, the following sections provide two case studies, drawn from real-life situations. These are designed to give concrete examples of how to consider the requirements for a portal.

These two case studies are:

• A software company looking to introduce a customer portal by pulling information from different systems into a customer-specific view
• An insurance company that has grown by acquisition and is now managing customer and other information across multiple information systems

These case studies provide an interesting comparison. Both case studies focus on the same key performance indicator (KPI) around providing excellent customer service to external customers. They also have issues with their legacy systems. Most business processes are carried out across multiple information systems, with users forced to sign-in multiple times.

Carrying out even some of the most simplistic processes such as updating the details for a single customer will mean making the update in four or more systems.

In each case the initial requirement was for ‘portal as a technology.’ However with further investigation, the business solution was quite different.

Case study: customer portal

Recently a software company conceived an initiative to launch a customer portal. The business driver behind this was the company’s continued focus on providing excellent customer service.

The portal was charged with providing customers with a level of convenience that could not be offered through other channels. It would achieve this by bringing all the information together in one place and enabling customers to access information and install new software around the clock regardless of their geographic location or time zone.

The company was particularly interested in delivering the following key information and artifacts to customers:

• information relating to software updates
• software patches and other fixes that could be downloaded and installed by customers
• new product information
• general company information including contact and support information

So is it ‘portal the concept’ or ‘portal the technology’ that is required?

The business requirement for a customer portal can sometimes be met with a web content management system

Is it a portal or not?

Everyone in the business (IS and business stakeholders alike) were equally emphatic that a portal solution was needed. Even when looking at a few initial areas this seemed obvious to everyone involved.

The IS department had been struggling with the company’s central information technology applications. The company’s core business of software product development and sales was being carried out in different programming languages over a number of different systems. These systems would need to come together in some way if customers were to be provided with relevant product information.

Delivering a view to customers that was highly relevant necessitated a sign-in to the site. More than just viewing content on the site customers visiting the site would download artifacts and process or install them into their own local environments. In order for the correct set of information to be presented to customers, the system would need to know what products each customer had purchased. This information came from yet another system.

The case for a portal continues to build. It seems clear to everyone that only a portal would be able to bring all this together in the desired manner.

What do customers want from the portal?

The most value can be delivered to the customer by providing information and updates about the products they have purchased. Customers visiting the site were looking to locate and install these as quickly and efficiently as possible.

For a portal solution to be considered the compelling business need should be obvious

Getting the information to the customer

If customer expectations around quick download speeds were to be met, the information sitting in the various systems would require modification. Software updates, for example would be packaged manually using a file compression application to reduce access time for the customer.

The best information to drive the personalisation of the site was the customer report made available to the sales and marketing department. This report would be updated each time a sale is made.

As more detail around how the information would be made available was uncovered, the case for portal technology became less compelling. The business requirement for a customer portal could be met, for example, with a web content management system.

The requirement: a content managed website

There was no requirement to improve or carry out a business process utilising a number of organisational information systems. As each software upgrade is completed, a copy is made, the file compressed and saved into a central location. From here it is uploaded to the site. There is no need to pull information from, or go into any of the organisation’s information systems.

Customer information is accessed from the customer report. Any other information is tailored for the site by the sales and marketing team.

In the end, the case was for a ‘portal as a concept’ rather than ‘portal as a technology.’ Clarity was brought to the situation by looking at the detail and challenging assumptions about how things would work.

Of course sometimes the requirement is for portal technology and the next case study is a perfect example of this..

Portals can facilitate single sign-on to multiple systems

Case study: Blue Insurance

Over the years, Blue Insurance has grown by acquisition. An insurance company that started by offering life insurance only, Blue Insurance has grown to include motor vehicle, income and home and contents insurance. Each time Blue Insurance acquired another company, it also brought in the legacy systems of each.

One process: many systems

Blue was spending a great deal of money and frustrating customers. Each time a customer called to update their details the customer service officer had to flick between four different screens to change details. With each separate screen laid out differently, this resulted in even more time spent across screens. Taking a portal approach would mean that the customer service officer can update the customer’s details once only. Updates could take place in the original application as they were entered in the portal.

A portal approach would mean that the customer service officer will update the customer’s details once only

Responding to customer need

Whilst this was undoubtedly valuable and would reduce unnecessary time spent on the transaction, there was other useful information that could be displayed on the screen.

Often-times a customer that had called up to provide a change of address would take the opportunity to check their policies. Perhaps they would want to change other details such as the amount for which they were insured. In this example, the actual policy was held on the “update customer details” screen and was available to the customer service officer at any time.

The underlying system was also accessible from this page. Clicking the link would take the customer service officer through to the system. The portal facilitated single sign-on to that system.

In-context help and training for staff

There is obviously a lot of other information that could be presented in this way. One in of particular note is training information or work instructions as a reference point and to train new recruits.

In-context help and clear instruction was provided to customer service officers for their first three months in the role. After this time, the portal reverted to the interface ‘the business-as-usual’ interface.

This illustrates how even those processes that may at first glance be considered transactional in nature such as updating customer details can benefit from providing more than just the information from the company databases. By putting this information alongside other content a good deal more can be accomplished from the same point inside the system.

The focus was on a high volume / high pain area of the organisation

A portal success story

Although a fictitious company, the case of Blue Insurance is a real case study. This portal implementation owes its success to a number of factors as follows:

• existing business processes were improved rather than merely replicated online
• transactional data was brought together with other content that provided instruction to business users
• changing customer details was a high volume/high pain area for the organisation
• the business process selected was tied to the organisational and customer service centre KPIs, as such it is measurable
• the initiative supported the organisational strategy in relation to customer service
• concentration was on one business process only rather than a full-scale portal roll-out

Conclusion

We’ve looked at two examples of portals: one where ‘portal as a technology’ was required and one where it was not.

Under the right circumstances a portal can certainly deliver value to any organisation that has a compelling reason to implement a portal over other technologies.

‘Portal as a concept’ will certainly be better served with the implementation of a content management or other similar system over portal technology.

The first step after defining the need for a portal is to take pause and interrogate portal understanding and thinking across the business.

The understanding of portals is likely to be especially variable between IS departments and general business stakeholders. It is important to give particular attention to these two specific areas of the business.

Organisations that have successfully implemented portals have done so by focusing on one particular business problem at a time. For a portal to be successful it must address a compelling business need. Whole-scale portal implementations, including those that address infrastructure shortfalls invariably fail.

Portals continue to tempt organisations. The skill is in articulating and achieving real-world substance in any portal implementation. Solving a real-world business problem is certainly a good place to start.