With stability taking hold of the hybrid print-digital market after years of rapid ebook growth, many publishers are turning to evaluate how workflow automation and other IT solutions can streamline their businesses and make them more efficient.

That’s undeniably a good thing, but as I’ve written before, the allure of a new digital system or solution can sometimes introduce new problems in an earnest bid to solve old ones.

I talk to a wide range of publishers interested in implementing our Bibliocloud publishing management software. But before we ever get to talking about databases, metadata management, interfaces or legacy data migration, we close the laptops, get out a Sharpie and some Post-It notes and talk about business process.

The point at which a publishing business starts to think about putting in place a new management system is a great time for a spring-cleaning of its processes. In fact, whether a publisher realizes it or not, the reason they think they need a system is usually because of problems with process, not data.

Yet that bigger picture rarely gets the level of scrutiny it deserves amid the daily hurly-burly of trying to keep a thousand tasks, deliverables and projects on track.

When publishers take the time to reflect on how they work and how well it’s working, though, they tend to arrive at more intentional and efficient ideas about their workflows and processes. That’s why we encourage all our clients to let us facilitate a day’s workshop for them. At those workshops, in the morning, we document how things work in the business, right now, using Post-It notes and a big wall.

We talk about how a publication gets from soup to nuts. We talk about how commissioning and acquisition works, about how the business considers and approves a manuscript put forward for consideration. We document how long the business allows for a book to go through its various stages of development. We write down all the discussions that have to occur and layers of approval that have to be passed—who’s involved and what each step is for. We write down all the names of the various documents that hold data. We articulate exactly how things normally happen to get a book to market in all its formats.

Do you know who, for instance, is in charge of writing back-cover copy in your organization? And who then signs off on it? Do you pass it by the author for approval? Or to senior editors to make sure that an imprint-level view is taken? What about series editors—do they have a say?

What about cost sign-offs—is there a stack of invoices waiting to be approved by senior managers? Can they see the context in which they’re signing them—whether they signify an overspend or are within budget—or is it just a pile of invoices needing signatures?

How do you handle a project’s transmittal from editorial to production? How long do you allow for proofreading? Is your in-house design team actually capable of meeting the deadlines for first and final cover drafts that editorial assumes to be reasonable?

What’s your canonical source of metadata? How many spreadsheets get maintained by different departments and individuals that contain roughly the same data?

And what we always discover—without exaggeration — is that there’s a lot of duplication, and a lot of assumptions about who does what, and when.

Lunch can be a sobering affair, during which the team may reflect, with some dismay, on their working practices. Don’t confuse that with snark; I would challenge any publisher to go through this exercise and feel that their workflow resembles a finely tuned machine.

Things pick up throughout the afternoon of our workshop, though, as it’s our chance to redesign the process for the future. The bottlenecks and duplication of data and effort that seem so obvious after our morning’s work get eliminated from the plan. We have some great, spirited discussions about who, precisely, should do what. I often see real relief from people who’ve been living with the effects of a poorly articulated process, who see simplification and clarity on the horizon for the first time in years.

It’s an exhausting day, as you can imagine, and sometimes it’s the first of many. But in time I email the team the first draft of their own “Publishing Manual.” It’s a document that, after many edits, refinements and discussions, will eventually be given to every new hire—“this is how we do things here,” with every part of the publishing process clearly written down. Responsibilities articulated, authority made clear. The roles of departments and individuals defined in writing. Timescales (both normal and crash schedules) laid out.

The document names meetings, and their frequency, attendees and expected outcomes. It states how the team will manage the canonical version of every sort of data, from contacts and schedules to metadata and printer estimates.

And almost as an afterthought, the Publishing Manual contains information about how the IT system will help—where the data will be entered and maintained, where meeting minutes will be captured and actioned, how sign-offs get stored and so on.

Because configuring a system to support a particular process is the easy part. Figuring out what the process should look like, on the other hand, is the larger problem. It’s emotionally charged, challenging, difficult and often frustrating. But it’s necessary and, ultimately, hugely beneficial for the business.

And it’s a prerequisite for the success of any significant systems implementation.


    Most popular

  1. Ruby code and why you should care
  2. A quick look at data visualisation and analysis
  3. Learning how to code, the long way around
  4. A manifesto for skills
  5. It's us in the industry who need to be able to code
  6. Menial publishing jobs are destroying our future
  7. Company news

  8. New website
  9. 2018 Customer survey report
  10. 2017 in review
  11. And now we are five
  12. Prizes galore
  13. Sara O'Connor to join the team!
  14. Product news

  15. 'Continuing to solve real problems': Futurebook 40, London Book Fair 2018 and the Works page
  16. How many authors is too many?
  17. Better ONIX fragments
  18. Advanced advance information!
  19. Schedules page
  20. Publishers hack their own bibliographic data
  21. Case studies

  22. Burleigh Dodds Science Publishing
  23. Zed Books
  24. IOP Publishing
  25. Code

  26. What publishers need to know about Ruby on Rails
  27. How APIs can make publishing more efficient
  28. A day in the life of a programmer
  29. A publisher’s guide to APIs
  30. eCommerce

  31. Don’t outsource your publishing business away
  32. Inbound marketing
  33. Who has the balance of power over data?
  34. To go direct, publishers must mean business
  35. Why publishers must use direct sales
  36. The business case for going direct
  37. ONIX

  38. A hidden benefit
  39. Thema Subject Codes Update November 2017
  40. ONIX. Not very standard
  41. BIC, Thema and artificial intelligence...
  42. Three ways to do more with ONIX
  43. How to create a catalogue automatically using ONIX and InDesign
  44. A non-technical, beginners’ guide to ONIX for Books
  45. ONIX Changes
  46. Skills

  47. A taste of code
  48. Mechanical sympathy
  49. Publishers can learn a few things from programmers
  50. Embrace the code
  51. Strategy

  52. A company of one's own.
  53. Responsibility, Authority, Capability
  54. Five things I've learned since moving into enterprise product management
  55. The search for publishing's holy grails
  56. Sometimes, size matters
  57. Managing expectations
  58. Rejuvenation
  59. Decisions, decisions
  60. The real price of a strategy shift
  61. Why ‘easy’ publishing solutions hardly ever are
  62. Technical debt
  63. Start with Why – How to refine your publishing mission
  64. The right tool for the job
  65. No computer system can fix a broken publisher
  66. Creative industries and the division of labour