Almost every week, a new technological innovation comes to market, promising to save publishers money, streamline workflow, reduce administrative burdens or reach more readers.
These innovations are diverse, but they share one thing in common: each promises to make our lives easier.
The unique selling propositions vary. Some offer easy enhancement of ebooks (CircularFlo, Beneath the Ink). Others let you conveniently mark up your manuscripts online (FutureProofs). Some offer to improve marketing (NetGalley).
Still others promise to reduce back-office administrative labor (my own Consonance). There are, additionally, tens and possibly hundreds of offerings promising to take the pain out of social media campaigns, mailing list management, editorial workflow, production and schedule management, online galley review, e-commerce, print-on-demand (POD), rights sales—you name it.
But here’s the rub: These solutions usually get developed in isolation, with little consideration for where they’ll each fit into their new customers’ existing technological ecosystems. And that’s hardly any surprise. With the myriad systems publishers use, how can a developer accommodate them all?
A prospective publishing client might have a distributor whose stock management system is an old AS400, alongside a Drupal customer-facing website, with Microsoft Navision for finance and Klopotek for metadata management.
Another publisher might have a distributor that uses an online data warehouse and a Magento website, with SAP for finance and spreadsheets for their metadata and scheduling processes.
How can a developer working on a new product or solution for either of those clients know precisely which integrations to plan for? And anyway, the developer is focused on building her new product to be amazing on its own merits. Legacy system integrations come later, right?
Wrong. Almost any new service is great, in isolation. But the real value—and the real pain—comes when it’s integrated into publishers’ own unique IT ecosystems.
Say the exciting new service that you want to incorporate into your business is for making enhanced ebooks. (There’s more than enough debate about the wisdom of that decision, but let’s take it just for the sake of argument.) It will require more content, more files, more workflow to create the new assets. And that opens up a slate of important questions: Which systems will be impacted by this new aspect of your business? Your metadata management system, your ONIX output, your editorial-production workflow, your scheduling software, your rights and permissions system and your finance system: Will they play nicely with your new toy?
What about something publishers might consider more sensible, like POD, a service that promises to radically simplify your stockholding requirements—how will that integrate with your distributor’s existing systems? How will you represent the applicable rights in your ONIX feed? What about sending the stock status to retailers? What about the additional printer scales?
If you’re not very careful, your supermarket sweep of shiny new services will turn into a major administrative overload as you try to stitch together a growing array of disparate systems. Doing so is almost always costly, and as I’ve written before, publishers must carefully weigh those investments against the returns that the new strategy they’re meant to support is likely to generate. Otherwise publishers end up becoming middle-men between two or more system providers and experiencing the worst of all worlds as a result—feeling the most pain and being the least equipped to ameliorate it.
So, in addition to listening critically to pitches for how any new service might make one isolated dimension of your publishing business easier, here’s what you need to ask of developers:
What is your track record for adapting to changes in the supply chain? Which systems do you integrate with? What was your process for determining the data formats accepted by the other systems yours is built to work with? Do you accommodate two-way data transfers? Could I see your API documentation please? In previous projects, who changed their code to accommodate the integration—you or them?
Developers and their fancy boxes of tricks often promise to make publishers’ lives easier, and of course their solutions can indeed turn out to do just that. But before things get easy, publishers have to confront the hard part first, and determine how well any new addition will integrate with all their other labor-saving systems.
Are your current systems sabotaging your growth ambitions? Are you hungry to implement new business models, but concerned you lack the strong administrative foundations needed for innovation?
We're always amazed at how resigned publishers have had to become to the low bar in publishing management systems. Demand more.
Contact us via our contact form, or email us.