Using Documentum Helps BMC Cut Production Time

Home/Publications/Best Practices Newsletter/1999 – Best Practices Newsletter/Using Documentum Helps BMC Cut Production Time

CIDM

December 1999


Using Documentum Helps BMC Cut Production Time


CIDMIconNewsletter David Shaw and Robin Reddick

The Technical Publications and Usability Organization at BMC faced increased demands in development, business, and customer requirements. On the development front, rapid growth brought the company from 150 to more than 300 products, from 2000 to 6000 employees, and from two major labs in Texas to eight major labs in two countries. On the business front, BMC began delivering solutions rather than products; as a result, engineers produced components rather than products. Products were heavily integrated in scalable and multi-platform configurations. At the same time, customers needed greater access to more consistent and usable information.

Together, these demands created pressures that would be best met through a single-sourcing strategy. However, with such rapid growth, such a large organization, and so much documentation already in release, the group broke the move to single sourcing into two phases: the development and adoption of a Document Management System (DMS) and the optimization of it to enable a Component Management System (CMS). Phase 1, DMS, is now fully functional and the early stages of Phase 2 are underway. We recently talked to Robin Reddick, Director of BMC’s Technical Publications and Usability Organization, and some of her team members to find out how they got the project off the ground, how they’re using it, the rewards they’ve seen so far, and how they’re embarking on the CMS frontier.

Getting Started

The group at BMC identified the need for DMS about five years ago. The growth described above was exponential, almost unstoppable. Product integration was well underway, and it became clear that soon information would begin to overlap. The group managed multiple versions of the same basic information.

Their first tool search convinced them that the manufacturers of DMS applications weren’t quite ready for the needs of a large software and technical writing organization. They put the project on the back burner and came back to it about two years ago. The second time around, the tools appeared much more advanced, and after an evaluation of the field, they selected Documentum.

BMC chose Documentum for two primary reasons: it has a strong document management engine, and the baseline functionality was exactly what they needed, yet it was open enough to allow them to customize it for their specific needs. Documentum consultants came onsite for about a year to customize the tool.

The first trial was completed seven months later when a small group of information developers successfully imported completed documents into the documentation database and began using the DMS for storage, electronic delivery, and printing.

Documentum Version 3 allows the group to store documents as Works-in-progress, Renditions, and Releases. Meta-data attributes attached to each file identify the document in the following ways: its product, the specific release, the owner, status, and type of document.

How It’s Used Today

Documentum integrated smoothly into BMC’s information-development processes. FrameMaker remains the primary authoring tool. FrameMaker is not integrated into Documentum; instead, information developers create documents in FrameMaker, exit the program, launch Documentum, and import the FrameMaker document into the Documentum workspace.

Once inside Documentum’s workspace and after being assigned meta-data attributes, the original document is stored in the Oracle database underlying the Documentum DMS. When the document is ready for publishing, it is assigned a new meta-data tag indicating it is ready for Web delivery.

Currently, documents are delivered in three renditions: PostScript, PDF, and HTML. The primary mode of Web delivery is PDF, though both internal desire and external demand are driving a move toward increasing the volume of information available in HTML.

Documents can be checked in and out of the database for continual development and revision. When a document is imported from the database, a locked copy of it is stored in its place. This lock tells others that the document is currently being worked on and also leaves the most current version in the database and available for on-demand publishing. The group also implemented a new business rule requiring them to run database replications every 24 hours to ensure that everything that gets checked in is updated everywhere.

The Documentum DMS fosters workflow through a series of workflow templates you can drop into the workspace. Ad-hoc routers circulate an Acrobat PDF of a document for review. Acrobat’s annotation capabilities allow reviewers to include review comments as the PDF circulates.

The Technical Publications group can also connect to Information Exchange, BMC’s corporate data warehouse which is also an Oracle database. The connectivity allows the group to draw on information created by other groups such as marketing. But while they can search other databases, they can’t draw from them live. To allow writers to work with material in Information Exchange, queried documents are “dumped” into a temporary database that Documentum accesses every two hours.

Increased Efficiency Through Documentum

We already noted that updated documents are delivered to the Web every 24 hours. Prior to implementing Documentum, Web postings took two to three weeks.

Also, before Documentum, the group had a team of six or seven people who managed the Web site content. At their best, they were able to maintain roughly 5,000 pages of static documentation. With Documentum, this process is automated. The accuracy is much higher because the most recent version of a document is always delivered to the Web. Currently, Documentum controls access and delivery for over 20,000 pages.

Robin elaborates on the benefits:

Once something’s in the database, it’s available to the printer and the Web (PostScript, PDF, and HTML). We basically took all of these independent and disparate processes and eliminated them. We have one process now and that works for all of our distribution points and all of our media.

This streamlining of process increases the integrity of information going to the Web or the printer. Before DMS, if information needed to be updated in several places on the Web site, the group was never certain that the same document was displayed in all places-all links had to be checked manually. Moreover, they were never entirely sure that the printer and customer were receiving the same information. Needless rewriting was occurring throughout the publishing organization and, often, information developers were creating conflicting information about the same products.

While changes in head count and delivery cycles are easily calculated and provide indexes of the overall success of the Documentum project, it’s much more difficult to determine a return on investment. Documentum Project Manager Andy Grout explains: “It’s hard to quantify the value of current, fast, and correct information; yet, this is the greatest benefit to both us and our customers.”

Envisioning Component Management

Phase 2, the implementation of CMS, is essentially a continuation of the successes seen in Phase 1. Rather than moving toward CMS products like Chrystal and Hynet, BMC is sticking with Documentum but will begin saving information at a more granular level than the document level described in the DMS process above.

To begin Phase 2, Help authors are writing topics as independent files, viewing them as components, and building a library of them with multiple attributes. Essentially, they are taking what they coined the “CMS characteristics” of Documentum and the authoring capabilities of DreamWeaver and combining them to mimic formal CMS processes.

Once the processes are in place, Robin explains:

We’ll step back, take an overall look at where the organization as a whole is, and say that everything we develop from this point forward will be managed as a component at the topic level.

She estimates that this stage is six to twelve months away. They expect to have it launched by April 2000 and fully operating by December 2000.

Tips for Other Groups Considering DMS and CMS

Robin stresses two primary areas for documentation managers to focus on as they embark on DMS and CMS technologies:

  • Get the support of your writers for successful implementation.
  • Understand the business needs and communicate them effectively to your upper management.

Regarding support from your department members, Robin asserts that “the most important thing to do is talk to your writers and make sure you get their support.”

Robin argues that managers must get their staffs to understand the value of the new technology because its success relies on their willingness to make it work. To get this buy-in, Robin included her writers throughout the project.

Immediately after the kick-off, she got volunteers to work with the Documentum consultants to ensure that they optimized the system for their work environment. She also asked her writers to identify the tasks on which they spent most of their time; it was they who brought up the fact that they spent nearly one-third of their time in production. Consequently, when they heard how the new system would automate this function, they were all ears.

To emphasize this point, Robin advises:

In short, include them from day one. Let them drive the requirements. Get them involved in QA testing of the applications you build. Let representatives from each group educate others in their groups. Keep them heavily involved. Let them lead the project as much as possible.”

On the other side of the coin, implementation also relies heavily on support from above.

Robin didn’t have much difficulty convincing her managers because they too saw the need for database publishing. In BMC’s rapid growth phase, engineers were writing object-oriented code faster than the publications group could document it. Both Robin and her upper management saw the need for a similar development model in her group:

When you’re the critical path for getting your product out the door, you absolutely have to do this, or you can’t stay in business.

Robin warns that often it will take a crisis point for upper management to understand that you need to make a change. She advises other managers to identify the coming crisis before it happens and be ready to explain that you need to find a better way to manage your information, serve your customers, develop information more quickly, and improve the integrity of what you deliver.

As Robin says, “these concepts are all pretty easy to understand. It’s not a particularly difficult sale; you’ve just got to put the right business plan in place.”

We’ll follow the progress of Phase 2 and let you know how it turns out. Good luck to Robin and her group! CIDMIconNewsletter

We use cookies to monitor the traffic on this web site in order to provide the best experience possible. By continuing to use this site you are consenting to this practice. | Close