Thomson Reuters is one of the world’s largest information businesses. Forged in 2008 through the acquisition of news and market data agency Reuters by Canadian professional publisher Thomson, the combined company turns over US$13 billion annually by getting the right information in the right people’s hands at the right time.

Like any recently merged organisation, Thomson Reuters is still in the process of developing a single identity and unifying structure. On its inception, the company was divided into three units – Professional, Markets (these two roughly reflecting the focus areas of the constituent companies) and a small corporate division. But in October 2011, Thomson Reuters announced that it would be moving away from this structure in order to foster greater collaboration across divisions.

Part of this organisational convergence is the unification of the company’s IT operation. Until January 2011, the IT department was split into the same three divisions as the group, each with their own CIO. Since then, Jane Moran, formerly IT chief of the Markets division, has been appointed overall CIO, and her remit is to unify the IT organisation across the group.

As Moran explains below, this is a task with many facets. These include unifying a fragmented legacy application suite, bringing together global distribution IT organisations and focusing on “customer excellence”.

Information Age: How has the convergence of Thomson Reuters since the 2008 merger affected IT
Jane Moran: Until January of this year, the structure of the IT department reflected the divisions of the business. We had three CIOs, one for the Professional unit, one for Markets and one for corporate. I was the CIO for the Markets division, having joined the company from Reuters.

Now we’re centralising IT across the whole of the organisation, which we think will leverage the scale of our IT operation for the benefit of the corporation.

What are the strategic objectives of the combined IT department?
Thomson Reuters’ business objectives are to drive revenue, reduce cost and reduce risk. We’re lining up everything we do in IT to support that. The directive I’ve been given is to reduce costs, but not at the expense of driving revenue.

How do you propose to do that?
The things that I’m doing specifically fall into four categories: driving and enabling business outcomes; standardising and rationalising the architecture; strengthening and aligning our capabilities; and improving delivery.

To drive business outcomes we really need to understand what problem we’re solving. I love technology, but you need to work with your business partners to solve a problem.

Demand management is an important part of that, and one that we are working on now. Instead of building 27 different order-to-cash processes, for example, we need to work with our business partners to provide a streamlined order-to-cash function that benefits our customers.

Fortunately, at Thomson Reuters IT is looked at as a strategic partner – our business partners call us to the table early on. Right now, for example, we’ve got a big programme going on in our professional division to streamline the order-to-cash function, and we were involved from the very beginning of that programme.

Rationalisation

How does the company’s IT infrastructure stand today?
My responsibility is for internal applications (our data centres and networks are managed by different groups) and right now I have 900 systems to manage, not counting separate instances of the same system. The majority of these systems are prospect-to-cash or reporting systems, although there’s other stuff like tax and property management.

I’m in the process of finalising a three-year plan to go from those 900 applications to a footprint of about 300 on a standard platform. That platform includes Salesforce.com for CRM, SAP for financials and order-to-cash, BusinessObjects for business intelligence, Oracle for databases and middleware, and Workday for human resources management.

What is the biggest barrier to rationalising your applications?
We have a lot of legacy custom code, much of which was necessary at the time. We do a lot of subscription billing, for example, and none of the ERP vendors had a subscription-billing module until 2002, so we had to build it ourselves.

But we’ve customised our applications way too much, and I don’t want to do that any more. I want to configure the software to get the best process, but the last thing I want to do is start fooling around with the code itself.

How can you remove the need for this customisation?
The key to our strategy is our partnering with the vendors themselves. Right now, for example, we are working with [on-demand CRM provider] Salesforce.com and [hosted human resources management supplier] Workday on integrating their products.

What made you choose SaaS providers Salesforce.com and Workday?
When I look at my application estate, about 40% of my project budget is spent on infrastructure. My first cloud experience was Salesforce.com in 2005, and I’ve become a huge fan of moving our infrastructure to cloud-based applications – where possible.

What stops you moving more applications into the cloud?
Having our order-to-cash applications on-premise is efficient for us. For one thing, there isn’t a cloud provider out there that has a mature enough order-to-cash engine, especially for billing.

Secondly, there’s also a close relationship between our order-to-cash process and what we call ‘entitling’, which means giving customers access to our products. There’s a connection between placing an order, paying an invoice and then accessing the product. That requires a lot of collaboration with our business partners, and it’s easier for us to have an on-premise application to support that.

Hiring internally

How do you source software development skills at Thomson Reuters?
I’m one of those people that truly believe in internal staff. I have great relationships with my external partners, but I don’t ever have a need for more than 20% of a flexible workforce at any given time, because there’s always work to be done.

When I started out as CIO for the markets division four years ago, it was the reverse. There was only 20% internal staff and 80% consulting. The turnover in my development staff was about 35%, so every year I was training consultants. Plus they were super-expensive.

Where are your developers located?
Our development organisation is located in 27 different cities, but the majority are in Hyderabad, Bangalore, London and Eagan, Minnesota. Because we were three different organisations, I’m still in the process of bringing those teams together.

How do you make sure that you have the appropriate skills for e.g. working on Salesforce.com?
I’m always upskilling my development staff. For the most part, they look forward to learning new capabilities like [Salesforce.com’s development platform] Force.com and Workday, and they’d like to get out of custom code.

How do you cultivate cooperation with the business?
I believe in Agile development. You need to have a close partnership with your business partners to understand their problems. I’m not an Agile purist, though – you need to do what works. We’ve adapted Agile methodologies to the way things work here at Thomson Reuters.

For example, we don’t just apply Agile on a per-application basis; we look across the whole enterprise. In a sprint, we’ll look at all of the applications as an end-to-end process, and an end-to-end platform of capabilities to support our customers. That’s where a lot of companies go wrong, I think. They look just at the CRM piece or just at the order-to-cash or just at the financials, and when you put it together it doesn’t hang together as a process.

Delivery

How do you plan to improve the IT department’s ability to ‘deliver’?
I think we need to achieve customer excellence. In a lot of IT organisations, the customer never features in the conversation, but I think that’s beginning to change for us. As a business, we use customer focus groups and we are starting to feed the insight we get back into the IT organisation.

I also think we need to improve our time to market, and again Agile helps achieve this. Even as we replace 40 legacy billing systems with a single billing process on SAP, the job can be done in bite-sized chunks. Even these big programmes of work we’re releasing on a quarterly basis.

If you develop milestones that are on a regular drum beat of activity, then you are going to reduce risk for the organisation and you have a lot better chance of being successful with what you are actually trying to achieve.

What is the biggest challenge to achieving all this?
I think that one could be overwhelmed by the size of the organisation. Thomson Reuters has more than 55,000 employees, and all of them are using at least one of these applications. But my philosophy is to treat a large company like a small company, and just get after the problems.