RSI began as a consulting company for publishers. In that role, we were often asked by our customers to document their as-is workflows and recommend new ones that would drive electronic product development and efficiency. We spent a lot of time creating massive diagrams. A lot of time. These projects were sometimes useful, and sometimes not. They were useful when we and our customer stopped analysis and documentation before the point of diminishing returns and turned our focus instead to implementing real change and on breaking down barriers to it. They were not useful when our customer was more focused on the perfection of the workflow documentation than on what they could learn from it. (Like, “Whoa, do we really need three different people to perform the same review cycle?” or “Does the author really need a print-perfect PDF proof?”)

As we transitioned to becoming a software solutions provider, workflow analysis was one of the more interesting and challenging areas because we had to actually make those new workflows work in the real world. The timing of this shift for us was accompanied by a shift in perspective by many publishers. Most of our business sponsors no longer have patience (or budget!) for extended analysis projects. They want change, and they are willing to take on some risk to make it happen. Fortunately, what our customers want and what we’ve found really works align nicely. 

Bottom line: Most teams come to us already knowing what they want to change about their business processes (at a high level), can list their most obvious inefficiencies, and have no way of knowing about the other ones that lurk until they move to an environment where they can measure them. Sometimes this is because another consultancy has helped them plan, but usually it’s because they are smart people and they know their own processes because they live with them every day. (Sometimes teams don’t know these things, but that points to management and staffing problems and that’s a post for another day…)

Because most of the teams we work with already know, roughly speaking, what they need and want to do, our job is to guide them towards a workflow implementation that reflects their big goals for change (usually being digitally-driven rather than print-driven), works for every day users, is flexible, and provides enough reporting to inform ongoing improvement. And to get it in their hands quickly. 

Even though we and our customers are smarter than we were ten years ago, there are still plenty of pitfalls in implementing workflow. This is especially true of a system that enables automation of content transformation, product delivery, and other common publishing tasks. Everyone is looking for the Easy Button.

Here are the best practices we follow when implementing RSuite workflow.

1. Keep it simple, keep it loose. Our customers today are mostly willing to forego months of analysis, but they often still want to reflect hundreds of discrete steps in their CMS workflow. Unless you have a legal compliancy concern, this is a waste of effort and will make your team nuts. System workflows with a small number of milestone steps give human beings flexibility in working out the daily details of their jobs and avoid the feeling of a police state. Few publishing processes really follow the documented 500 steps, and often that is for good reason. Don’t hem in your staff with a rigid implementation.
2. Automate, but avoid automation dependencies for your workflows. A business process often has several predictable points at which automation is needed (e.g., conversion of a manuscript from Word to XML, generation of author proofs, delivery). It’s tempting to want to plug those steps tightly into your workflow. In the past few years we’ve taken a different approach. We give users tools to run or rerun automations whenever they need to, but don’t have the workflow engine itself initiate the conversion, delivery, and so on. This simplifies (read, cheaper, shorter) workflow implementation and also gives the publisher the opportunity to change a workflow on a one-off basis or permanently with minimal or no configuration changes. 
3. Don’t forget reporting! During a project it’s easy to get caught up in workflow process implementation and not spend enough time creating truly useful reports. Which leads to…
4. Remember that change isn’t a switch you flip. Rolling out your new CMS and workflows is the beginning of change, not the end. Expect that over time you will want to adjust not only the offline details of how you’re working, but also the workflow itself. Create a habit of reviewing reports and looking for bottlenecks and points of frustrations. Make sure you have a staffing plan that enables you to make small changes quickly. This best practice also means you have permission NOT to rationalize all your business processes on day one of CMS launch. Management often has the goal of getting rid of all the unnecessary inconsistencies among teams, and this is a worthy goal. But sometimes it makes sense to step into that level of change incrementally.

We’ve found that following these guidelines results in a system that enables immediate change but with the option for more change when you need it. Not following them can lead to user revolt and management disappointment. 

What do you think? What has and hasn’t worked for you when implementing business process changes?