Cambridge University Press (CUP), the oldest publisher in the world, is overhauling its enterprise applications in a bid to keep up with how people consume content in the digital world.
Established in 1534 by Henry VIII, CUP has more than 50,000 titles in its back catalogue and produces more than 2,500 titles a year. However, like many other publishers, it is having to reassess its business model to accommodate a shift from pure print to a combined print and digital future.
Part of this requires a consolidation of its back-end systems to adapt to new revenue models. Computerworld UK spoke to John Rimell, chief architect at CUP, about the global transformation project.
He explained that CUP is moving from having 10 disparate financial, procure-to-pay systems around the world – based in locations including New York, Japan, Brazil, South Africa Australia, Singapore and Spain – to one single, consolidated SAP platform.
“From a back-end financial systems perspective, we can already handle having books on pallets in warehouses and shipping them around the world, but we now need to be able to handle digital assets, sales, and all the new sales and costs models that come with digitisation,” he said.
“Leaving aside the cost benefits of having one system instead of 10, along with the simplification we get with support, we will really be in a position to adapt to these new models that are coming through in digital publishing.”
He added: “For example, we have a print book that is stocked on a shelf, but then we have a website that we sell 12 month subscriptions on, which you then need 12 months' revenue recognition on.
"Being able to do a single order for all the different types of products and have a back-end that can handle the taxation, revenue recognition, fulfilment across digital platforms, be completely automated, will really open the gates to sales and product and development teams.”
New strategic direction
Rimell explained that the 'strategic business transformation' happening at CUP led to IT selecting SAP to replace the 10 different finance systems, which had consisted of a variety of products and vendors.
CUP's approach was to go live with SAP's Finance and Controlling (FICO), Materials Management (MM), and Accounts Payable (AP) modules in the UK and US first – which went successfully went live on 7 January this year – and then roll out Sales and Distribution (SD).
Once FICO, MM, AP and SD are live in the UK and US, which represent most of the publisher's cost base, it will then take this complete procure-to-pay and order-to-cash platform to other countries across the world.
However, Rimell explained that he had three options when deciding how to best migrate CUP's data across to the new SAP platform from its previous finance systems. He said that he was presented with the following options:
- Move as much of the functionality as possible into SAP and make SAP manage all the data for CUP.
- Create a set of APIs between CUP's existing systems and build a business logic layer that would do all the transformations from how SAP handles data to how the legacy systems do things.
- Undertake a radical overhaul of all of CUP's internal systems so that they all use SAP's data model – SAP's view of the world.
“We chose option three. We have quite a good development capability in house and we took the line that we wanted to enhance and rewire a good chunk of our key internal systems to use the SAP data model. That in itself was a 12-month project – to redesign each application schema, to change the applications to use the new schema, to change how the data flows worked from system to system,” said Rimell.
“That all went live a few months ahead of the SAP go live, to allow it to bed in. But as a result of having taken that early hit, we now have a single product data model for all our product data across all of our systems. Everything is now a straightforward data flow from one system to another.”
Rimell said that putting all of the data into SAP to manage wasn't an option for CUP, as it wanted to retain its systems' publishing customisations that have been built up over the years.
“Had we done option one, the challenge there is that SAP is still not an editorial, publishing system. We have years of built-up knowledge of how to do this and we have coded up systems with that knowledge – to have thrown away those lessons learnt and systems expertise, was not a route we wanted to go down,” he said.
Although Rimell said that he was pleased that up until this point he and his team had delivered the project on budget, on spec and on time, he did warn others undertaking such a large data migration that you need to factor in time for business users to assess the quality of the data.
“What does good data look like? What does bad data look like? You need someone in the business who knows. So the load that puts on the business is quite high,” he said.
“For these people that are being called upon to test business processes, it puts quite a bit of burden on them. So you must remember to factor in the time it takes business users – because we did that, we hit all of our data migration deadlines.”
Rimell will be speaking on behalf of Cambridge University Press at the SAP UK & Ireland User Group Conference in Birmingham this month. For more details of the event, click here.