When you hear a tag line from a business, do you believe it?  Some companies have nailed the tag line such as American Express (Don’t leave home without it!) while others are questionable given their press over the years (Bank of America:  Higher Standards).  Tag lines are without a doubt the first reflection of a company’s culture and their ability to deliver on their promises.

1. RSuite is being licensed and used by more and more organizations that publish but would not be considered a traditional publisher.
2. RSuite continually was touted by our clients as their publishing automation tool that significantly decreased their production timelines.

Over the years we have worked with hundreds of publishers spanning many industry verticals.  Some publishers do everything in-house, some outsource pretty much everything. The question for me is what is the definition of a publisher these days?  Is it an organization that does everything from soup to nuts in the entire publishing process or is it a publisher that outsources as much as possible and only worries about brand management?  

According to Oxford English Dictionary (OED) published by our RSuite CMS client Oxford University Press, the definition of a publisher and brand manager are:

Publisher - A person or company whose business is the preparation and issuing of printed or documentary material for distribution or sale, acting as the agent of an author or owner; a person or company that arranges the printing or manufacture of such items and their distribution to booksellers or the public

Brand Manager - the supervision of the promotion of a particular brand of goods

So, do these definitions define today’s environment?  Let’s look at two examples:

We do everything publisher

We have worked with some publishers who like to control everything about the publishing process right down to printing and binding their publications onsite.  These types of publishers are few and far between these days, but they do still exist.  I can certainly understand the desire to own the entire publishing process since I am sure the company is a traditional publisher, have employed many of the people for 20 plus years, and have honed the process to be very efficient.  The questions are, can outsourcing a specific piece of the publishing process drive better profits or maybe adding some key automation tools (i.e., RSuite CMS) help deliver more and higher quality content?  The “we do everything publisher” is generally a niche publisher (e.g., safety information) and has not had too many competitors in their space to drive change.  However, as with everything in publishing, the digital age requires publishing to deliver in multiple formats and print no longer can support the company growth.  Therefore the call to automate as much of the process to really drive multi-channel publishing will continue to grow and require change along the way.  What these types of publishers need to realize is that change is not a bad thing and frankly, change is inevitable.  Selective automation is better than no automation.

We outsource everything publisher

Several years ago I had a rather heated conversation with an executive at a global publisher.  I asked her what exactly they do in-house anymore since it seemed like all they wanted to do was to outsource the entire publishing process and enjoyed beating up their vendors to hit their quality standards and profit targets.  First, I’m sure the offshore vendor deserved some of the beating up.  Second, I’m sure some of blame was due to poor input from the publishers.  In other words, there was blame on both sides, but the fact was that this global publisher became nothing more than a brand manager in my opinion.  Other than the acquisition team, everything else was outsourced (mainly offshore).  Is this the face of publishing today?  I suppose that companies who are attempting to drive profitability as much as possible feel that outsourcing everything is the best alternative.  Long gone are the days when the art and craft of publishing required a solid team who were dedicated to the higher cause of publishing.  It’s about brand management and its about profits in this scenario.

We selectively outsource publisher

Now I am sure there are publishers that fall in between these two examples where they do a lot in-house and selectively outsource production processes.  If I had to guess, I think that is where most publishers fall today.  The question that still remains is which direction is the industry headed?  Will publishers become so highly outsourced in their production process that they only manage their brands or will they want to continue to control every step along the way?  My guess would be that most publishers are going to continue to move towards the brand manager model and outsource and automate as much as possible to drive profits because of the pressure of replacing print with digital revenue.  Unfortunately that is not a dollar for dollar replacement and publishers will be forced to do something in a very short period of time or begin a slow decline until they go out of business.

When publishers look to automate their publishing process, I hope they take some time to look at the amazing results our RSuite CMS publishing clients have achieved by implementing our software.  When we set out to build a better publishing automation tool, we never envisioned our clients enjoying a 50% reduction is production time, 30% increase in website traffic due to better metadata management, or 100% content processing automation.  These numbers are staggering but real and we are proud of how much we have helped our clients drive revenue and profitability within their organizations.

As with everything in life, it's all a matter of the lens you view things through.  Something can look rosey to one person while looking like a train wreck to another.  Often times the view of a legacy content management system is dependent on where you sit within your organization, and rightly so.  But many times the decision to not replace a legacy CMS is based completely on the false premise that everything is OK and IT has everything under control.  In our experience, many times the IT organization is overwhelmed with projects and maintaining a legacy system becomes more difficult with each passing year.  

In many publishing organizations that we speak with on a daily basis, legacy CMS' are patched together by one or two very key individuals within an organization because they happen to be the longest tenured staff and were around when the system was installed.  There is generally a knowledgebase of small system idiosyncracies that these individuals know to stay away from because of either a design flaw or through implementing the system incorrectly.  Having an IT person be a single point of failure is not a good business practice to begin with, but having little or no understanding of what the black box legacy CMS is doing is much, much worse.  Unfortunately these situation exist at major publishing organizations around the globe.  This is an outgrowth of publishers who don't want to face the reality that their system is in serious jeapordy of crashing and there is no recovery mechanism in place.  

So how does each management level within a publisher view a legacy CMS?  Here's an outsiders perspective:

C-Suite View - We have technology that is proven

From the top, everything looks calm, cool, and collected.  Think about the duck gliding across the pond.  Products are being produced, money is being collected, why do we need to change anything? Remember the duck is paddling like crazy under the water.

VP View - We can make this work with little investment

While there are issues we need to address, the technology is solid and has been proven for some time.  Our team does not have turnover issues and therefore they are well versed in the CMS.  Some investment might be required to patch things here or there, but we have no need to upgrade to a new CMS.  Throwing more staff or budget at the legacy CMS will take care of everytihng.  We should be fine to meet our strategy.

Director View - We are unable to keep up with daily issues let alone scale the system

The system has been working, but barely.  The fragile nature causes daily concern that one hiccup could bring the entire production process down.  Editorial is comfortable with the workflow, knows the editorial tools, but under the covers the CMS cannot be extended and is patched because the technology has not been upgraded in years.  Adding more content, integrating with other systems, or adding third party tools will be extremely difficult without a large budget and a sufficient timeline to complete.

Developer View - We are so screwed 

The application has been maintained by different people over time.  Nothing has been documented, we have not paid support and have not received CMS software upgrades, and the underlying database has not been upgraded in years.  If the system goes down, I may need to look for a job.

The Bottom Line

Every position and management level at a publisher has a different view of their CMS.  It's natural.  What consistenly surprises people is that a legacy CMS can only address the requirements from yesterday and potentially not address the strategy of multi-channel publishing or automated eBook creation or whatever objective because changes are difficult and the system cannot scale.  Legacy systems are generally proven, but they do not generally have the stability to support the long-term business objectives and must be replaced.

If your CMS is over seven years old, has been patched to keep it running, and doesn't support your strategy, let us show you why publishers from around the globe and over 10,000 publishing professionals use RSuite every day.

Every so often we get inquiries from our RSuite enterprise clients or prospects about why there are services required to implement our RSuite software if the pre-configured environment is pretty much useful out-of-the-box?  If one digs a little deeper and analyzes exactly what types of services are required, I think a publisher will be surprised that services related to customizing or extending the content management software are actually pretty small.  Sure there will be custom forms for metadata capture or custom search forms, but these are generally a few days worth of work at the most.  On the other hand, services related to content structure and workflow re-engineering have a huge impact on the services required for a content management product implementation independent of the software package chosen.

Content Engineering

Content engineering can be simply defined as understanding the structure of your content and putting a migration plan to make it adhere to some type of standard.  In some cases very large publishers have crafted a proprietary content standard, but many adhere to industry standards such as NLM, D4P, DocBook, etc.  The amount of services required to transform the content from one format to another can vary widely depending on the amount of file formats and complexity of content.  While this effort can be categorized as part of the content management project, it is not part of the content management software.  

Content structure and organization reflects how an organization has worked over time.  If the publisher was disciplined and remained in compliance with industry standards, the amount of services to get the content into the content management system is minimal at best.  Basically, if the publisher has well structured content that adheres to a DTD, then it should just work in RSuite or other systems.  The challenge surfaces when multiple products adhere to different DTD's and then the publisher wants to consolidate under one standard.  Again, a very good idea, but this is an issue beyond the content management software. Or the publisher has no DTD and wants to migrate all of their content to a standard.  Again, an excellent idea, but the effort to complete this should not reflect on the content management software.  As one of our engineers has said, "there is no magic button to transform the content, you either have the discipline to adhere to a standard or it will take some work to transform the content so that it does comply".  There is no simple solution.

Workflow Analysis and Automation

Services related to workflow are generally consultative in nature whereby a business analyst sits with all parties to understand current "as-is" and "to-be" workflows.  In some cases publishers have done a very nice job documenting their current as-is workflows but have a difficult time envisioning the to-be workflows.  This is normal and can generally be addressed by creating some pilot workflows and showing the client how the software will help them.  In some cases though a publisher which has been doing business one way for the past 20-years can have cultural challenges to change to the to-be workflows.  This has been becoming less and less over the past 5-years as the need to embrace multi-channel publishing is critical to the sustainability of the publishing business.  In other words, optimizing workflows, creating efficiencies, and actually automating multi-channel publishing are no longer options.  It does mean in some cases that people within the publishing organization will have to be re-skilled or let go.  That is unfortunately the nature of the game right now for publishers.  Workflow equals efficiency which equals cost reductions which equals a reduction or reallocation of staff or an increase in production throughput.

A publisher that requires significant manual steps (e.g., a person needs to review and approve content) in their workflow will not realize the true benefits of implementing the workflow software.  Manual steps are still required in the editorial process, but minimizing them is key.  An automated step (e.g., content transformation) is the key to gaining the efficiencies that are sought by management.  Depending on the complexity of the automated steps, the amount of services required can vary widely.  The key is automating the highest value steps in the workflow and minimizing the manual steps.  Again, the more a publisher understands how they need to change their process, the less services will be required to implement the content management software.  The software will do whatever you configure it to do, but time spent understanding exactly what a publisher should be doing takes time and requires a visionary within your organization to think outside the box.

The Bottom Line

For both content engineering and workflow related services, the more a publisher is organized in these areas, the less services are required for a content management project independent of whether it is RSuite or not.  The painfulness of addressing years of neglect in a structured or disciplined production of content can require significant services to unwind the structure, business rules, or lack of adherence to standards.  Unfortunately this can be seen as a barrier to implementing a content management system.  

While a new content management system could offer tremendous value in content reuse, version control, and production efficiency, the new software cannot magically address the messiness of the content or undocumented workflow. If your team has been organized and have very structured content with a well documented and agreed upon workflow (even if you are using legacy technology), then services to implement a CMS should be relatively small.  

If you are embarking on a content management initiative, I would highly recommend that you have an honest assessment of your content structure and your workflow.  If these pieces are in order, then you have just increased your odds of a successful content management system implementation and reduced the required services to implement the software.

I had the opportunity to attend the Outsell Signature Event last week that brings together top executives from the information industry.  As always, everything that Outsell does is top notch and so in an inviting setting and surrounded by movers and shakers in the industry a number of key topics were discussed, debated, and argued.  The event traditionally focuses on all aspects of the information industry and provides an executive level view of the economy, business models, technology adoption, current stress points, and business and technology transformation.

Some random points from the sessions:

• The economy is going to continue to grow at a relatively slow pace for the next few years and it will be worse if the US government does not address the debt ceiling quickly.
• Many information providers are being disrupted by the shift to electronic products.  Those who have adopted a more progressive business model are able to weather the storm a bit easier.  Those who are stuck in their old ways are beginning to feel the significant decline of print revenue.
• Design of electronic products have evolved tremendously with users expecting a clean, functional design.  No longer is it acceptable to have great content and a poor interface.
• Software vendors are also feeling the disruptions with changing software licensing models.  The need to have an a la carte license model is a requirement, not an option.
• Transformation is not an option anymore.  Too many variables are changing at breakneck speed and an organization needs to be ready to change or face the inevitable decline.
• Wearable technology is really cool and will take some time to be adapted but don't be surprised if you are wearing a small device (e.g., watch, pin, earring) within the next decade that is attached to the internet in some way.

While RSuite CMS was not front and center at this conference as an exhibitor, it was interesting to speak with publishers who continue to be challenged by managing a large (dare I say big data) set of disparate content.  

Publishers realize that content management software is an absolute necessity to transforming their organization, and I believe executive management understands the larger problem is with their processes and culture.  The culture (i.e., people) side of transformation is probably the most challenging and will continue to require a significant investment of time and money to address. The process side of transformation is a bit easier because everyone wants to make their jobs easier and more efficient.  It is great to finally hear executives say that XML content management is no longer a "nice to have" but a necessity in business transformation to meet multi-channel publishing goals. Fortunately, RSuite CMS is positioned very well to help out publishers in their transformation.

I look forward to the meeting next year.

I find it almost comical that our mainstream media is latching onto (and blowing out of proportion) the report about the NSA pouring over phone records and other data.  First, metadata is not new.  It may have been disguised as health records, or school records, or whatever, but it is not new.  People didn't care about the information in years past because it was secured and locked away on a printed piece of paper in a file cabinet at your doctor's office or at your child's school.  Fast forward to today where many of our personal records, bills, and pretty much everything else is electronic and you have a massive amount of metadata.  Yes, there is a massive amount of this metadata that lives in our world, and yes the NSA is not the only organization looking at it.

Twenty years ago when I worked at GE, we were hired by a well known large bank to develop a data mining system that would be able to forecast the likelihood of a person defaulting on a loan or missing a credit card payment.  This system aggregated a ton of metadata including financial credit scores, loan payment history, economic status, etc.  This was a commercial business, not the government, but why is this any different than the NSA using phone records to secure our country?  Aren't both organizations (banks and NSA) invading our privacy?  I am perplexed by our citizens who feel that our government is required to keep us safe, but don't want any inconveniences or intrusion in our lives.  Meanwhile, public companies, advertisers, banks and pretty much every other large business is looking at your metadata to figure out your buying behavior. This is nothing new.

Up until a few weeks ago most people in the United States had no idea what metadata was and frankly, probably could care less because it was a techie thing.  For most publishers, metadata is the backbone of their content.  Publishers have invested heavily in metadata as their printed product revenue has evolved over time into electronic product revenue.  We have touched on this subject several times over the past few years on this blog:

The Second Rule of Content Management:  Enrich with Metadata - http://blog.reallysi.com/bid/92056/The-Second-Rule-of-Content-Management-Enrich-with-Metadata

Centralized Metadata, Content, and Assets:  Paradise Lost - http://blog.reallysi.com/bid/41180/Centralizing-metadata-content-and-assets-Paradise-Lost-and-Regained

Metadata Lessons from Google Books - http://blog.reallysi.com/bid/40326/Metadata-lessons-from-Google-Books

Metadata management will continue to be a key part of their publishing and product development processes.  This is one of the main reasons we developed RSuite CMS.  There was a significant void in the CMS market when it came to both content and metadata management.  We believe we have solved this issue with RSuite and welcome the opportunity to discuss our product with publishers who feel the need to more efficiently apply and manage metadata.

The recent elevation of the word "metadata" in the mainstream media probably has most publishers chuckling a bit, but the investment in metadata by publishers is very real and will continue as the ability to find content becomes ever more complex.

As a content management company, we sing the praises of our clients who have created tremendous efficiencies in publishing operations by implementing appropriate tools and technologies to reduce time to market and satisfy a multichannel publishing strategy.  The information industry is under tremendous pressure to deliver digital content in many forms to many channels.  However, some publishers are moving away from automated workflows and content transformations.  Why would an organization forgo automation in today’s complex publishing world?  Perhaps it is due to the following:

1. Managing offshore vendors – Holding a vendor responsible for meeting quality standards and publishing timelines requires a different set of skills than incorporating publishing tools into an organization. With automation, some of the vendor responsibilities are moved back to editorial and production departments. While an offshore vendor can apply brute force on a case-by-case basis; adhering to structured formats and implementing templates enable content transformations and delivery in a sustainable and automated manner.
2. Cutting jobs – Publishers who think that automating workflow is wonderful but equates to cutting jobs may benefit from another vantage point. Just as effective manager works with an individual to align skills with solutions, the same can be said for automated workflows. For example, technology is excellent at machine processing---XML validation, business rules validation, schematron validation.  Individuals outperfom on cognitive skills that automated technology is not equipped to tackle---content development, content curation, metadata management, new product sandboxing. Saving time with efficient workflow routines equates to realigning staff to work on value-add tasks.
3. Conserving culture – Some organizations don’t like technology that automates workflow.  Never have, never will.  It takes communication, dedication, and training to change an organization's culture in terms of new technology adoption. Working with older toolsets (eg, Word 2000, InDesign CS3, etc.) provides a comfort level to both in-house staff and external authors. But guarding a culture against change can result in antiquated processes and missed opportunities.  
4. Hiring vs investing – Increasing headcount is an easier sell than investing in technology. Investing in the right technology means changing the way individuals do their daily jobs but also means changing the way an organization approaches a publishing program that has worked consistently for decades.  It is no small task and investing in a new CMS is indeed a financial and organizational committment. Adding up the factors that instigate the pursuit of CMS need to be part of the investment equation---lack of automated content transformation, laborious manual workflow steps, inability to deliver to multichannels, ineffective content organization, dispersed assets, inconsistent metadata, etc.
   
   Rather than calculating ROI on a CMS investment try looking at the payback period when the pain points are resolved.  If you can justify an investment in automating workflow and have a payback period of a year or less this could be an easier sell to internal staff and management. 

There is little doubt that publishers have a multichannel publishing goal.  There is pressure from the consumer and the competition to produce more content, more efficiently, and to more channels than ever before. A balanced approach to making changes to people (ie, structuing teams according to skill sets), processes (ie, automating as much as possible), and technology (ie, implementing appropriate tools and technologies) results in success.  It is not just the technology that requires investment. Changing people, patterns, and culture usually requires a greater investment in time and education.

What approaches to workflow automation resulted in success at your organization? What pain points do you continue to face?

A couple years ago there was an article from wsj.com under the Cubical Culture section that struck a chord with me: “Management to IT: We don’t like you either.” As evidenced by the title, the inherent conflict between IT and management is never ending. And even though the article was published 5 years ago, we still see the conflict arise in many publishing and media organizations.

Management today at many companies expect more out of IT organizations than in previous years. It's no longer acceptable to request an 18- to 24-month project life cycle and not show a return on investment quickly. If IT continues to do these types of things, they will render themselves useless and out of a job. The old days of “we can build it better than any product on the market” is long gone.

For publishers I have seen a shift over the past 5 years related to this build-vs-buy mindset. If your IT organization is still touting that they can do it better, cheaper, faster by building a critical system (e.g., CMS) from scratch… run, run away as fast as you can. Given the wealth of tool sets available and the openness of many products on the market, why would an organization ever take the build-it-from-scratch approach? I'm genuinely interested in this and welcome your dialogue in the comments section.

I’m not biased when I make these statements. I’ve seen a renewed interest by publishers to license a product and show a return on investment quickly. This has been our mantra since day one with RSuite CMS. Our goal was to make a highly configurable CMS that can manage any content and be operational in a short period of time (under 12 weeks) to meet core requirements. Yes, there will be some organizations that require 12-month projects to migrate from one system to the next, but overall the trend has been implementing a new system, even for larger projects, in a much shorter time frame. The only way IT will be able to handle this shortened timeline is to license a software product that meets 70% of their core requirements pretty much out of the box such as RSuite CMS.

I can certainly understand why IT organizations at publishers want to build their own CMS. First, it’s fun to build software. Second, it gives more of a feeling of accomplishment than integrating third-party software. Finally, a programmer can have a job for life just making endless changes to the software (ok, that was a cheap shot).

Management today needs to understand that IT does have value and IT needs to understand that management has the right to ask questions. Reducing the stress between these organizations is critical to publishers making the right technology choices and implementing new systems on time and within budget.

Let us show you how RSuite CMS satifies management's desire to demonstrate ROI on CMS investment and IT's desire to play with cool technology.