Change before you have to. -- Jack Welch
A few years ago, some Forward Looking people proposed conforming our existing (formerly Sybase) SAP documentation to the DITA methodology, including packing our docs into a central CMS where it would be accessible to other business units for reuse in their products.
We didn't have much reuse at the time (a couple dozen topics), though. And the switch would mean abandoning two decades of perfected customized tools, fracturing a few hundred XML files into a staggering 12k files, adopting an admittedly complicated set of doc processes, and seemingly losing control over our baby. Oops, did I say baby? I meant our documentation collection. Anyway, we were a Docbook shop, pioneering and advocating change in the Docbook standard in the industry, mavericks in the face of processes-for-the-sake-of-process, and generally adverse to abandoning all in the absence of a problem that justified it. There seemed really no compelling reason to make the switch for the small reuse needs we had. After all, our information products were receiving acclaim, and Our Customers Were Happy :oops: with them. So.. why change?
Then, a funny thing happened On The Way To Market.
Suddenly, in 2012, our reuse requirements shot up dramatically when a sort of product recombination approach to solution delivery hit us -- the on-the-fly integration of smaller products into end-to-end solutions with rapid go-to-market goals. Slower waterfall development and release strategy gave way to nimble, agile solution-creating, and this required the supporting information products to keep pace.
Suddenly, the definition of customer grew to include other authoring teams in other business units, as well as new customers of other products in the solution.
Suddenly, information architecture went from 'how to organize your books' to:
- how to architect cross-project information products
- how to blend terminology and styles across product documentation
- how to write so that topics could be reused in multiple product contexts
- how to version documentation and time its release to be concise and accurate for the software going out the door
- how to do all this in a way that controlled localization and translation costs too?
Suddenly, the maverick authoring team style was no longer an option. For the organization to share and recombine content from the various product authoring teams, we had to Be On The Same Page - literally and metaphorically. Standardization of styles, processes, tools, the centralization of content, and the integration of authoring teams around the globe were a must.
Cut to today and we are within months of our final push to standardize, centralize, and integrate our SAP doc content in with the rest of SAP product documentation. Our content is now DITA-compliant, we author in one of the best XML authoring tools (oXygen), and we will be cohabitating a corporate content repository (Ixiasoft CMS). Our team now works closely with other SAP authoring teams around the globe on almost a daily basis. The timing of this change is perfect, as we now have close to 2500 topics being reused by other products in SAP, and that number is expected to double once our final migration is complete.
It's a whole new world, and we're pretty excited to be done with the (years) of projects to get our content switched over. We've had some hurdles to overcome to get to this point, but all in all, this has definitely been Change That Couldn't Be Spared.
(About the author: Laura Nevin is an SAP Knowledge Architect working on the SAP product.)
