The IT Challenge

New, emerging and exciting electronic publisher products are well documented elsewhere, almost everywhere, so no need to list them here. Successful publishers are moving away from providing only a single product, which might be printed. They are now in the business of hosting the membership of a club that offers many different products and services, across many delivery channels, in order to provide and monetise a valuable experience for their customers and advertisers. The task of IT is to support this ongoing evolution.

In this article, I will share my humble view on how I think publishers should organise their IT resources moving forward. I have broken this down into three sections:

1. IT Strategy
A publisher’s IT strategy should encompass the support of the marketing, production and delivery of the organisation’s products and services, together with the exploitation of available technological advances were appropriate.

Whilst there are some publisher products and services on offer where the supporting IT appears as a graceful swan from the surface, yet are discretely supported by frantic activity beneath that surface – these are few and, thankfully, reducing. Some publisher IT groups have responded brilliantly in recent years. There have been some remarkably innovative technical advances. Publishing IT has almost been a cool place for an IT person to work! And long may that continue. However, the time is overdue (for some) to look beyond satisfying the latest exciting, individual initiatives, to step aside for a moment from the very long list of ‘to do today’ items and look at how they might support long term business growth and cost savings.

Quoting the World Association of Newspapers: Circulation Science Report 2005, "Another element that separated successful newspapers from many others is that they enjoy a culture of shared responsibility. Journalists, circulation and advertising staff all work closely together with common beliefs and a commitment to help each other improve the business." I would argue that a sharing, if not a centralisation, of customer data is key to providing common beliefs and knowledge to enable effective cross-product marketing.

"Know your customer" is an old and valid adage. Just because it is difficult for a publisher to achieve does not reduce its relevance. There should be one and only one logical customer record within a publisher’s enterprise, with only one bad debt flag, one ‘do not contact’ flag by channel / product, one set of profiling data and a single merged record of total product consumption. In order to be more effective, trained marketers should have access to data pools and analytic systems utilising data collected via such diverse inputs as ‘job seekers’ and ‘house seekers’ web clubs, SMS alert services, website surfing activities and classified advertising history etc.

The concept of CRM has been established almost universally, but not yet in publishing. Why is it that a publisher cannot have a single view of one of its customer’s interactions across the whole of their product offerings? As publishers have extended the products and services that they offer, and as these products have frequently been dependent upon cutting edge technologies, this has often lead to an increase in the disparate systems and databases put in place quickly to support their individual marketing and delivery. Technology has itself erected barriers - barriers of platform, individual system replacement cycles and perhaps the biggest barrier of all, the barrier of the sheer size / cost and danger of failure of any system upgrade, let alone systems convergence project, as the dependence upon technology has become absolute.

But maybe advances in technology are now starting to help us so that it is no longer as difficult and dangerous as some might have us believe, especially if we start now to consider how ultimate system convergence may be achieved in manageable phases over time. Starting slowly, starting now.

Service Orientated Architecture

So what is the silver bullet? It is SOA, or Service Orientated Architecture, along with web services. With everyone from IBM, SAP and Oracle touting the merits of this technology and philosophy to all industries, with success, then maybe we should consider it within publishing too! Put simply, SOA is the means with which the functionality and data of both new and older systems can be made accessible to one another. The real beauty is that if the decision is made to adopt SOA, then it can be achieved over time without the need for so called ‘big bang’ or ‘rip and replace’ system upgrades which are as dangerous as they are costly. It is possible to begin the move toward a single, logical customer record without the introduction of a new, single, ‘do everything’ vendor system – which does not, and probably never will, exist anyway.

IT should understand and map all of the functionality within the current enterprise systems. They should identify all of the common and duplicated functions as well as working with the rest of the organisation to understand what data each function would benefit from sharing. Some small advances could be quickly achieved – a single enterprise wide credit card payment process might be established and this service could be ‘plugged into’ all systems requiring this functionality (saving more money than some people might think). Perhaps a service could be easily developed within existing technologies to be called by, say, an advertising system and a circulation system to identify a common customer. It may not be as difficult as some think to reach this fundamental stage. The advertising and circulation systems could then be extended to provide a service which delivered information on request on persons within their respective databases. This in turn could allow a marketing database to house both the advertising and circulation profiles of the people to whom it is marketing; it could house the web surfing profile of the publisher’s site of those same people and perhaps instruct the content generation engine to deliver an appropriately constructed product including relevant ads. This is exactly what some publishers are on the verge of achieving, eager to exploit the information that analytics on this data will yield.

Long term, once a certain point has been reached within an SOA environment, when sufficient existing functions and data pools are exposed, they can be replaced with improved versions. Best of breed functionality can be delivered to all areas of the enterprise simultaneously. At some stage in the future a publisher need no longer distinguish between, nor pay a premium for having, more than one ‘system’ supporting all its activities. A publisher can become an on demand supplier by allowing its previously ring fenced data and functionality to better interoperate across company functions, as well as with third parties. This allows it to more quickly react to changing market conditions and to seize new opportunities as they arise.

To realise the long term benefits of SOA, IT must help all areas of a publisher’s enterprise understand what is possible. They must help produce a viable software evolution and convergence plan that takes into account disparate purchase cycles and budgets, without compromise to the competitive need to continue to be locally innovative. Ultimately, a publisher’s customer should be able to have a single sign-on to all of the services offered by the publisher and their partners. Equally, a publisher should have a single view of their customers’ activities and thus any opportunities that they represent. Now that would be cool.

2. Purchasing, Implementation and Integration
System users, including their management, are not generally experienced in purchasing, implementing and integrating systems. They need help. These days, there can be very little to differentiate vendor systems in terms of visible functionality and this can make the decision process very difficult indeed. One thing which is clear is that once presented with a selection of systems, the one chosen by the users is the best one to purchase and implement with the worst system being any of the alternatives. It is therefore critical that IT help in the short list process.

Only those systems which support the agreed corporate IT strategy (this having been formalised along with user representation) should be considered. If the long term goal is SOA and integration with other systems, then perhaps it might be appropriate to purchase a system not yet fully constructed. If the objective is to quickly and safely implement a system due to, for example, current capacity or hardware support imperatives, then it might equally be appropriate to implement a proven system even though the technology is dated. Clearly a mismatch can spell disaster.

A system should only be purchased if it can provide the functionality that is required. This can only be determined if the requirements are defined. IT has a significant role to play in this definition process. It is not so much the technical language that might be used but more the completeness of the definition. A requirements specification of 50 pages is useless if it contains requirements such as ‘Should produce invoices’ without further definition or if any data to be integrated to other systems is not detailed.

Once the purchase has been made, IT should recognise that users will almost certainly underestimate how much effort the implementation will require of them whilst they continue with their day job. Until people experience it for themselves, they will never appreciate just how much time it takes to discuss, agree and authorise the wording of the specification of a change to a system, just why it takes forever to convert data from one system to another and why the parallel running of two systems is so important. IT, with their experience, should deploy resources to help in the specification of changes. Whilst users are the only people qualified to judge the accuracy of converted data, IT can go a long way to providing the means to efficiently make that judgement. By learning and understanding the specific business processes during the implementation process, IT can help agree sensible, staged sub sets of the parallel run and final sign off process. Appropriate IT involvement in these stages can significantly speed up an implementation.

3. The Boring Stuff
Why is it that almost every organisation fails to ensure that systems, new or old, are used efficiently? This is perhaps a HR issue as much as it is one for IT, but ongoing training and process checking are very often forgotten.

In some departments, staff turnover is such that it is not uncommon to find that none of the current users have ever received training on the systems that they use. Many of today’s systems have alternative screens and flows to do apparently the same thing, but there are subtle differences which can provide efficiencies dependant upon transaction volumes or the manner in which input data is presented. Often workflows change within a department that would benefit from the utilisation of areas of a system (maybe existing, available menu options) not previously used and therefore not known to the current users.

Individual users and their departments can often win back significant amounts of time just by being shown a more efficient way of doing certain aspects of their job. I had an instance myself where a colleague recently introduced me to the VLOOKUP facility within Microsoft XL; it did in seconds what I was about to spend a day on. I would urge IT to devote time to developing a cycle of such sessions with their user departments and, if necessary, ask the system vendor to give you the odd free day as part of your maintenance contract.