Document Management Magazine

Successful EDM Implementation:

The Information Technology Strategy

by Rainer Hoff, Ph.D., P.Eng.

 

July 1998

© 1998, Gateway Consulting Group, Inc.

 

Introduction

    This is part 4 in a series about successful EDM implementation. Part 1 and the methodology diagram are given in the Jan/Feb 1998 edition of Document Management. An information systems project ("the Project’), either in the realm of electronic document management ("EDM") or product data management ("PDM"), is going to use a great deal of a wide variety of information technology ("I.T.") components. It is only prudent to ensure that this investment fits with the other I.T. investments in the organization.

     

Does Our Company Need An I.T. Strategy?

Yes.

Current systems are often large, monolithic, centralized software tied to islands of information creation and use. In response to changing business conditions, the problems associated with this include:

  • limited flexibility,
  • high integration costs with other systems,
  • high development, enhancement and maintenance costs.

These problems are well recognized, and the desire to improve competitiveness highlights these as key issues.

"Strategy is creating fit among a company’s activities. The success of a strategy depends on doing many things well – not just a few. The things that are done well must operate within a closely-knit system. If there is no fit among the activities, there is no distinctive strategy and little to sustain the strategic deployment process. Management then reverts to the simpler task of overseeing independent functions. When this occurs operational effectiveness determines the relative performance of the organization." []

Does Our Team Need an I.T. Strategy?

      The project team would normally use a written I.T. strategy as a starting point or to provide guidelines. Most teams are enthusiastic about and want to contribute to the organization’s strategic plans.

      In the absence of such a document, the team runs the risk of having the project evaluated by a committee for "compliance with standards". The risk occurs because the evaluation becomes subjective, and this has caused numerous projects to be needlessly delayed.

What If There Is No I.T. Strategy?

A key strategic issue for an EDM/PDM project is how the project impacts the "rest" of the organization. The project team could write its own I.T. Strategy document, or release a document that assesses the project’s impact on the organization.

 

Elements of an I.T. Strategy

An I.T. strategy contains 3 major themes:

  • Business improvements are enabled by Information Technology
  • Information Technology requirements are always growing, changing and being extended
  • Information Technology is about abstractions: it would be easy if it were just hardware and software "boxes"

The operational effectiveness agenda is the proper place for constant change, flexibility and relentless efforts to achieve best practices. The strategic agenda is the place for making clear tradeoffs. The challenge now is to create fit among the IT components and their matching business components, and this is often termed the systems architecture.

 

The Importance of System Architecture

A systems architecture is analogous to building architecture in many ways: form, function, best use of resources and materials, human interaction, reuse of design, longevity of the design decisions, robustness of the resulting entities are all attributes of well designed buildings and well designed computer systems. Architecture is a set of rules which defines a unified and coherent structure, although it does not specify the details of any one system. The benefits of having an architecture include:

  • Business processes will be streamlined
  • Systems complexity is reduced
  • Enterprise wide integration is enabled through data sharing and consolidation
  • Rapid evolution to new technologies is enabled.

I.T. Frameworks

One approach to developing a systems architecture was proposed by Zachman[]

The Zachman framework answers the questions:

  • What—is the system made of?
  • How—does the system work?
  • Where—are the components of the system located relative to one another?
  • Who—does what, relative to these system components?
  • When—do things happen in the system?
  • Why—are the various system choices being made?

Although some debate exists about the merits of the Zachman approach, I suggest that it’s a good starting point for developing your overall strategy.

Information Management Issues

Organizations have a great deal of information, whether contained in databases, documents, etc. Issues that ought to be considered in an I.T. strategy include:

  • how is information used in the organization?
  • data ownership
  • data stewardship
  • standard naming
  • tools used to model the data
  • storage, archiving, backup
  • data relationships
  • security
  • quality control of information

Although these issues could be defined in the context of a project, they are global issues that really ought to be dealt with on an organizational basis.

Standard Software Components

Often an I.T. strategy identifies key software components. These are existing or desired applications which are deemed to be central to the organizations mission. In the technical world we frequently see (although not all of these at one organization) applications which are targeted towards information management:

  • Electronic Document Management
  • Product Data Management
  • Enterprise Resource Planning
  • GIS
  • CAD

If each business unit chooses a different application for each of these functions, you clearly have the antithesis of a strategy. In other words, standardization contributes to supporting the I.T. strategy. But what is the optimum scale over which application standardization should take place within an organization? This is a very key question.

Strategic Approaches to COTS

EDM/PDM systems are usually installed by using commercial off-the-shelf software, "COTS". However, there are several kinds of COTS software, all of which might be applicable in your project:

  • Standalone packages: these are standalone applications that are available for sale. For example, word processors would be considered COTS. COTS applications are clearly tempting because they provide turnkey functionality. However, specific needs may not be perfectly addressed by these general applications. On a larger scale, EDM and PDM applications could be considered stand-alone packages. Except in the smallest applications, they are never used "out-of-the-box".
  • Libraries: requiring linkage into the applications code
  • Application-specific languages: e.g. workflow
  • Development environments with runtime modules: e.g. Visual Basic™, Oracle™
  • Vendor–Supplied device drivers: printer, display and multimedia applications

Clearly, not all of these are turnkey, off-the-shelf tools. Due to the perceived difficulties of custom-developed software, the desire exists to have "no custom code" in an application. However, the author is not aware of any large EDM/PDM system which doesn’t have some element of "development".

 

COTS Approaches to EDM/PDM

We have identified 4 approaches to EDM/PDM which use COTS software. However, the direct and implied costs are different in each case.

Let’s use a PDM example: The 4 most commonly used components of a PDM system are:

  • Configuration management ("CM")
  • Component and supplier management ("CSM")
  • Document management ("DM")
  • Workflow ("Wf")

The Best of Breed Approach

        For each of these components, CM, CSM, DM, Wf, there is a vendor who would be worthy of the title "best of breed". You could buy the best of breed CM application, the best of breed, CSM application, and so on. You would then have to integrate these into a working system. Since the effort usually varies quadratically with the number of components, the integration effort would be very large! The integration code would clearly be nonCOTS.

The Integrated Application Approach

        Commercial PDM vendors provide an integrated application which has features of all 4 of these applications. While none of the functions is "best of breed", the logic is that they are "good enough" for most applications. Nothing wrong with the logic; you need to validate the assumption against your needs.

The Enterprise Resource Planning Approach

        Due to the large investment that many companies have in their ERP applications, the statement is sometimes made that, "We’re doing everything in our ERP application!" That’s fine as long as the ERP application has the necessary capabilities. In the area of PDM, the ERP vendors’ capabilities are evolving; in the area of EDM, their capabilities are currently not very impressive.

Augmented ERP Approach

One approach is to augment an ERP application with capabilities from another COTS product. For instance, a popular approach is to augment an ERP application with a COTS document management application. That way the benefits of leading edge document management can be achieved while enjoying the benefits of the fully integrated ERP application.

 

Technical Infrastructure Strategies

In addition to the high level elements of the I.T. strategy, it’s necessary to have specific recommendations on the hardware and software components of the infrastructure. These recommendations are usually an elaboration of the following:

  • Networking standards
  • Network topology considerations
  • Network management system considerations
  • Workstation standards
  • Workstation operating systems
  • Graphics capabilities
  • Memory
  • Free disk space
  • The distribution of workstations among different classes of users
  • Server Hardware Standards
  • Hardware vendor(s)?
  • What model?
  • Migration path when vendor changes models
  • Server Software Standards
  • Acceptable operating systems
  • Databases
  • Version control issues
  • Is there a Common Operating Environment?
  • If so, what are the standard desktop applications?

 

Recurring Misconceptions

    I continue to hear broadly worded, general statements that seem to indicate a strategy. While these statements are not wrong, per se, they tend to be elements of a vision rather than operational definitions. Here are my favorites…

A Document Is Just A "Bucket Of Bits"

      Although the "bucket of bits" perspective of a document allows you to make some file storage decisions, it ignores the true complexities of documents. Documents are integral parts of business processes—the revision, version, format, state, rendition and metadata all matter—not just buckets of bits.

We’re Using SAP™ For Everything Now

      ERP applications, of which SAP™ is the best selling, do NOT do everything. Specifically in the area of document management, the ERP capabilities are very limited. There are a number of clever ways in which a third-party EDM can be used to augment an ERP application.

We’re Using COTS For Everything

      As stated in section 3, even with a COTS solution, there will still be a need for some company-specific development, for any major application.

We’ve Got a DEC™ Strategy

      I mentioned DEC, although it could have been any other vendor. I can understand the value of good relationships with a preferred supplier. Face it, it’s a preferred supplier, it’s not a strategy.

We’re Moving Everything To The Web

True, there is an inexorable trend towards using the Web as a distribution vehicle for information of all types, including documents and part data. However, it’s still necessary to store, index and manage this information, AND IT’S STATE. That’s the role for EDM/PDM.

 

Acknowledgements

I would like to acknowledge the substantial contribution of my colleague Glen Alleman, for providing the material for this paper. This has been a brief treatment of a very vital subject. Feel free to e-mail me at rhoff@gatewaygrp.com if you’d like more information or elaboration.