Kalthoff University In-Depth Review of EDM Systems Taxonomy and Classification

g3/7/2020 : Page – 1
548 – Kalthoff Fall 97
EDM Systems
In Depth Review
Kalthoff University
301, 501
29 September, 1997

g3/7/2020 : Page – 2
The Big Disclaimer
The classifications presented here are the opinions of the author and do not
represent the opinions of the author’s employer. These opinions are to be
taken as is and are based on information found in the public domain or
information gathered through the personal experience of the author.
The basic problems with comparing vendors:
 Access to working systems is difficult in most cases.
 The users of the working systems have a built–in bias to provide
favorable reviews of the systems they have purchased with the stock
holders money.
 The complexities of the EDM world provide many opportunities for
success or failure based on non–technical aspects of the project.
 The market place is changing rapidly, which creates both opportunity and
problems for the vendor.
 Changing standards
 Changing market demands
A High Level view can be taken of the products and market though

g3/7/2020 : Page – 3
Why are we here?
 To discover the Taxonomy of EDM Systems
 To discover how the taxonomy of a system can effect the outcome of the
EDM project.
 To discover the Risk Factors associated with evaluating EDM System from
the point of view of their taxonomy.
 To avoid the Pit Falls in reviewing the taxonomy of the various systems

g3/7/2020 : Page – 4
What we won’t learn here
 The magic bullets — there aren’t any, period.
 The turn key solution to our problem — unless of course you have a turn
key problem:
 This off the cuff comment should actually not be minimized. If there is a
problem to be solved which fits (or nearly fits) an existing Commercial Off
The Shelf product, don’t focus on the requirements for the System, adapt
the Business Process to fit this System.
 No matter what anyone says, this is hard work.
 Specifying the behavior of both the business process and the computing
system which supports that business process requires discipline and
courage.
 Controlling the scope of the project requires fortitude.
 Displacing the current business process with an automated system
requires physical as well as mental effort.

g3/7/2020 : Page – 5
Pre-existing problems with this presentation
Scope of the Material
 This is a big subject, not amenable to 1 1/2 hours, so we’ll move fast.
 If this were easy, everyone would have flawless EDM projects and we’d
be out golfing instead of having this seminar.
Density of the Material (Physical, Logical, Point Sizes)
 The slides are intended to be read outside of this room, so they violate all
the rules of good presentation style:
 They are dense.
 They contain (I hope) real ideas and content that you can use later to
build your own ideas on.
 They have references that can be followed to the source of the idea.
The Subject Matter Itself
 This stuff is hard, somewhat tedious and always looked back upon when
the project is in trouble as — SOMETHING THAT SHOULD HAVE BEEN
DONE, BUT OF COURSE WASN’T.

g3/7/2020 : Page – 6
Some Clarifications
Electronic Document Management
 There is a difference between:
 Electronic Document Management
and
 Managing Documents Electronically
 Electronic Document Management
 Managing Documents Electronically

g3/7/2020 : Page – 7
Taxonomy of an EDM System

g3/7/2020 : Page – 8
Taxonomy
 The science or technique of classification; the science dealing with the
description, identification, naming, classification or organisms; any
classification especially the systematic classification or organisms in to
hierarchical groups.
 Why deal with EDM Systems in this way?
 The EDM market place is populated with products that provide a variety
of capabilities, nearly all of which have been developed as a result of user
needs.
 In mature products, this creates a plethora of features, which overlap with
the needs of the end user community.
 These feature sets are continually evolving, driven by user needs, market
forces, technological fads, competition.
 One way to sort out this mess is to put the systems into categories which
define their behavior or use rather than their list of features.

g3/7/2020 : Page – 9
Three Generic Application Classes of EDM Systems
 Archival Support
 Performance Support
 Authoring Support

g3/7/2020 : Page – 10
Classes of EDM Systems
Archival Support
 Provides a repository for read only (or nearly read only) information
 Banking, lease, mortgage service, medical, educational, etc. records
 Indexing of these records is usually through the original document
number, transaction number, account number (static linkage)
 The archival aspects of the system are the primary Critical Success
Factor.
 Optical storage for nearly a lifetime (equivalent to microfilm)
 Legal records management requirements. Microfilm replacement
behaviors.
 Connected to the Line of Business support systems, as if the document
were in its original form — paper or film.
 The database record is the primary document of record, while the
scanned image is the supporting information.
 Signatures, hand filed fields and other human generated information is
usually contained in the document.

g3/7/2020 : Page – 11
Performance Support
 Assisting employees to better execute their tasks.
 Attributes of a Performance Support EDM System
 Focused on User Needs
 Provides a Representation of the user’s work process
 Work processes and business rules guide the user through the daily work
activities
 Provides access to information required to support the decision making
process.
 Delivers the correct information to the right person at the right place and
the right time [†]
[†] Electronic Document Management Systems, L. Bielawski and J. Boyle, Prentice
Hall, 1997.

g3/7/2020 : Page – 12
Performance Support — System Attributes [†]
 Absence of any need for training.
 Integration of the software in the user’s performance.
 Understanding that performing, not knowing is the critical success factors.
[†] “Just in Time Knowledge Delivery,” K. Cole, O. Fischer and P. Saltzman,
Communications of the ACM, Volume 40, Number 7, July 1997.
Electronic Performance Support Systems: How and Why to Remake the Workplace
through the Strategic Application of Technology, G. J. Gery, Gery Performance
Press, Tolland, MA, 1991.

g3/7/2020 : Page – 13
Authoring Support
 The EDM system is embedded in an author / review / publish cycle.
 Publishing formats vary, but are usually in a different form than the
original authored text.
 PDF
 HTML
 Management of Change is an important attribute to this type of system.
 Review and update of the various versions of a document are managed
by the system.
 Multiple renditions of the document are managed directly by the system.
 The Web has focused the EDM systems on these issues
 How can reliable documents be delivered to HTTP servers?
 Can HTTP servers be replaced (augmented) by EDM Systems?
 This is the million dollar question asked here

g3/7/2020 : Page – 14
What about Engineering Document Management Systems?
 The attributes of all three of these system types are found in the
engineering document management environment.
 Authoring of design documents using CAD systems and specifications
and standards using word processors.
 Management of Change for the various versions of the CAD drawings
and textual documents.
 Performance support by delivering documents directly to the end user on
the shop floor, control room, construction trailer or maintenance office.
 Archival control of documents imposed by regulatory requirements
(OSHA 1910.119, ISO 9000, FDA GMP).
 Low training footprint, due to high value, low use of the document
management interface (the EDM system is a secondary function when
compared to producing products).

g3/7/2020 : Page – 15
Three Generic Architectural Classes Systems
 Standalone
 Integrated
 Integrate–able
 How to interpret the following slides
 Each attribute is cumulative
 Each attribute is general in nature is should be used to classify a system
rather than select a system.

g3/7/2020 : Page – 16
Standalone
 Favorable attributes
 Provides a turn key data model based on Vendor’s indexing model
 This model may provide user defined attributes
 But it is closed in the sense that the underlying model is Fixed.
 Provides a built in facility to capture, store, view and print documents
 Usually priced in a per seat configuration
 May or may not require a server
 In a minimum configuration, a local file system may be used to hold
documents.
 Indexing may be implemented with a embedded database engine
 Unfavorable attributes
 System may not scale beyond a few seats
 Performance
 Reliability
 Usually problem specific solution, so the system is unlikely to be
syndicated across other business applications.

g3/7/2020 : Page – 17
Integrated Systems
 Favorable Attributes
 Provides hooks for connecting a Line of Business (LOB) database
 Usually only single path table entries
 Usually done through an API
 Provides a scalable architecture usually by separating the server
functions into multiple processors
 Provides a layered approach to the user interface, peripheral integration
and database connections.
 Un–favorable Attributes
 Assumes a market specific document model
 Folders, attributes, etc.
 Embeds this data model in the underlying system
 Provides integrated system components as standards offering
 Third party components can usually be added, but requires integration
and lacks standard warranty

g3/7/2020 : Page – 18
Integrate–able Systems
 Favorable Attributes
 Production oriented installations which have worked through all the
performance and reliability problems.
 Provides a scalable architecture.
 Provides an open database model (see un–favorable attributes)
 Allows LOB database to be the primary indexing tool
 Allows tight integration with multiple database models
 Un–favorable Attributes
 Usually requires a big picture type project, which can support the initial
investment in the infrastructure.
 The primary indexing attributes of the Standalone and Integrated systems
are present, but these features are not used often.
 Weak out of the box user interface facilities when compared with
smaller capable systems.

g3/7/2020 : Page – 19
What is Happening in the Market Place?
 The distinction between these three classifications are becoming vague
 All vendors are moving away from their initial product offerings into other
market areas.
 Al vendors are maturing their product offerings and introducing new
products
 What drives these changes?
 The Web
 Microsoft pricing
 Microsoft itself
 The maturing of the industry
 The generalization of the EDM problem space.

g3/7/2020 : Page – 20
Components of an EDM System
Layered Components
 System Architecture
 Industry Standards
 Workstation Applications
 Middleware Applications
 Electronic Vault
 Infrastructure
 Humanware
 Other Attributes of the EDM System
 Component Lifecycle
 System Scalability
 Other abilities

g3/7/2020 : Page – 21
The Document Management Processes
Review / Promote
Authoring
Process
Retrieve
Read
PrintPublish
Electronic
Vault
Document
Model
Record
Information
Unpublished

g3/7/2020 : Page – 22
Life Cycle of Various EDMS Components
Desktop Applications
Document Archive and
Storage Applications
Middleware Applications
These applications provide viewing, printing and markup
capabilities for documents. They are usually based on MS
Windows and will turn over every 18 to 24 months. Since
the underlying operations system is driven by market
pressures, SRP's ability to control the migration is limited.
These applications provide access to the physically stored
documents and their rudimentary indexing information. If
the document image format is an industry standard, and it
is placed on an industry standard media, the mechanical
devices used to access these images changes every 5 to 7
years.
These applications maintain the data and process models
used to describe the documents and their relationships.
The underlying technology (RDBMS) is considered stable.
Any changes in this infrastructure will take place over 3 to
8 year cycles. The majority of the value of the EDM System
is maintained in these applications.

g3/7/2020 : Page – 23
Why Look at the Systems from this Point of View?
 The Three (3) Phases of the Software Industry [†]
 Business Software of the 70’s and 80’s
 Off the Shelf Software Solutions
 Open Standards
 What does this mean to the Taxonomy Process?
 The interconnections between the software components is becoming less
clear.
 The dependence on of single vendor is becoming the norm.
 The direction of the software industry is being driven by end user
requirements rather than by vendor marketing departments.
 At one point in the software business cycle, the marketing folks would
ask: What features will sell?
 Now they ask: What components can we produce that will allow of
user to “assemble” a working system?

g3/7/2020 : Page – 24
Let’s Get Started
The Taxonomy of an EDM System
 Standards – provide an agreed upon set of protocols for integrating,
defining and using EDM Systems.
 Workstation Applications – provide the Visual interface to the EDM
System, the documents it manages and the work processes that are
embedded in the business.
 Middleware Applications – provides a business specific instance of the
document relationships.
 Electronic Vault – provides a secure and reliable storage facility
 Infrastructure – connects the various components of the EDM System
 Humanware – provides operational, legal and administrative components
of the EDM System.

g3/7/2020 : Page – 25
Let’s Get Started
The Hand Out Picture
 The next slide contains a taxonomy of the EDM System.
 This picture is not readable in the book or the slide show, so you should
have a hand out printed full size.
 What does this picture show?
 The decomposition of the various components of the Taxonomy.

g3/7/2020 : Page – 26
Standards
How can standards help in understanding the EDM System?
 Standards define the playing field for the software and hardware
components that make up the EDM System.
 Standards sometimes define the exact behavior of a component
 Scanner interface formats
 Document image formats
 Network protocol standards
 SQL database standards
 Other times standards define vague behaviors
 OLE, CORBA, DMA, ODMA, and Object Technology in general
 Work flow standards
 Sometimes standards are actually private specifications
 AutoCAD, MicroStation file formats

g3/7/2020 : Page – 27
Standards
Known Standards
 EDM standards
 AIMM standards at http://www.aim.org/industry/standards/statrp.htm
 Many of the document imaging and document handling standards are
available from this organization.
 TIIF standards in Aldus TIFF Version 6.0 document
 The actual TIFF header used for scanned images is defined in this
document.
 Additional MIL STDS define the compressed raster formats used by
TIFF
 DMA / AIIM standards
 Workflow Management Coalition at http://www.aiai.ed.ac.uk/WfMC/

g3/7/2020 : Page – 28
Standards
AIIM Document Management Alliance (DMA)
 AIIM sponsored initiative
 Defines the Functional and Interoperability requirements for:
 Document input and processing
 Document retrieval and display
 Document review and approval
 Document storage and administration
 Document services
 Defines six (6) categories of document library services:
 Check In / Check Out and Version Control
 Query Services
 Users, Groups and Security
 Catalog and Container Association
 Document Conversion
 Object Exchange

g3/7/2020 : Page – 29
Standards
Workflow Management Coalition (WFMC)
 WFM Coalition is a group of commercial companies that have agreed to
comply with a specification for the following interfaces:
 Session establishment
 Operations on workflow definition and their objects
 Process control functions
 Process control supervisory functions
 Process status functions
 Activity management functions
 Data handling operations
 Worklist / Workitem handling functions
 Role Management operations
 Audit management operations
 Resource control operations
 The WFMC approach is through interoperable application programming
interface (API) specifications.

g3/7/2020 : Page – 30
Standards
TWAIN
 An acronym for Technology (or Toolkit) Without an Interesting Name.
 Defacto standard for connecting scanners to workstations
 TWAIN is a software protocol for managing the PC to Scanner interface.
 Composed of four suppliers:
 Hewlett–Packard, Logitech, Cannon, KOFAX, Genoa Technology, Fujitsu,
Documagix and Papermaster and Bell & Howell

g3/7/2020 : Page – 31
Workstations
Separating Hardware from Software
 At one point in the EDM product cycle, the specification of an image
quality workstation was important.
 Windows 95, 96 and 97 took care of that.
 Typical WIN 95 machine running Office 97 and one other application
 32 to 48 MB memory
 2GB to 4 GB disk
 Pentium 120 to Pentium Pro processor
 Several hundred's of dollars of application software on every machine
 The specification of the EDM workstation application’s behavior is now
much simpler:
 A well behaved 32–bit widows application that is capable of operating in a
TCP/IP or Novell network environment without producing any adverse
effects on the existing applications.
 What is left is specifying the exact behavior that will meet the business
goals of the EDM project.

g3/7/2020 : Page – 32
Workstations
Applications
 Thick Applications
 Client heavy applications that make use of the services of database
engines.
 The document management logic is embedded in the workstation
application.
 The database engine maintains the logical states, but the state transitions
are initiated by the workstation.
 Thin Applications
 Client light applications that make use of the services of the database
engine and a server based application environment.
 This environment could be embedded SQL scripts
 Or a middleware component running on a separate processor.
 Web Based applications
 The ultimate thin application, is now getting fatter with the introduction of
Java and ActiveX

g3/7/2020 : Page – 33
Workstations
Programming
 What tools are available to alter the behavior of the work station?
 Visual basic
 Java
 ActiveX
 C++
 Can the system be altered?
 Was the client application designed to be altered?
 If so, what tools, training and support are available to perform this
function?
 Is this the standard way of installing the system?

g3/7/2020 : Page – 34
Middleware
This is where the action is
 This component maintains the logic of the EDM System
 Database tables
 Embedded scripts
 Programming to perform state processing
 The question is where is the middleware component in the system?
 Wholly inside the database tables
 Wholly in a server application
 A combination of both
 The architecture of this component separates the systems into their
categories
 Turnkey (closed) middleware
 Semi–open
 Open

g3/7/2020 : Page – 35
Middleware
The Killer Apps in the Middleware component
 Management of Change
 Line of Business database integration
 Workflow

g3/7/2020 : Page – 36
Middleware
What’s Being Managed Here?
 Documents and Their Relationships
 Engineering Design Documents
 Maintenance Documents
 Regulatory Compliance Documents
 Design Basis Information
 As Built Documents
 Design Calculations
 Record Information
 Equipment Numbers
 Change Orders
 Maintenance Records

g3/7/2020 : Page – 37
Middleware
Managing the Change to Documents
 This is the most understated activity in any EDMS.
 Paper based MOC schemes rarely work properly when transferred to an
EDMS.
 The changes to the organization in this area should not be ignored.
 The changes to the document database include:
 Revision to the content of the document.
 Revision to the document relationships.
 Temporary changes with reversion to previous state.
 Regulatory Requirements
 OSHA 1910.119
 ISO 9000

g3/7/2020 : Page – 38
Middleware
Multiple Layered Data model
 Plant Model – describes the relationships between the various pieces of
equipment, their locations and other attributes of the plant or business
entity. These entities are primarily record based. This is a logical instance
of a document and may represent the latest release or a specific release,
depending on the business rules.
 Document Model – describes the relationships between the various
versions of a document. Since it is not always the case that the latest
version is the proper version
 Object Model – describes the physical and logical storage of a specific
instance of a document.

g3/7/2020 : Page – 39
Middleware
Multiple Layered Data model – Plant Level
Document
Equipment Project
Sheets
Relationship(s)
Plant Data Model

g3/7/2020 : Page – 40
Middleware
Multiple Layered Data model – Document Level
Revisions
External
References
VersionsApprovals
Document
States of a
Version
Document Data Model

g3/7/2020 : Page – 41
Middleware
Multiple Layered Data model – Object Level
Native File(s) Renditions Markup(s)
Electronic Vault
Data Index
Reference Files
Object Data Model

g3/7/2020 : Page – 42
Middleware
A Reality Check is needed here
 The number of business applications (from my experience) that implement
the previous data model (or anything like it) is rare.
 Top 10% in terms of size and complexity.
 The level of effort necessary to define this data model for the specific
application environment is very large
 Multiple version already exist inside the business
 Resolution of the data model conflicts is painful
 The payback for this effort can be found in only a few companies
 Very large aerospace firms where configuration control is a must
 Very large paper processing applications (banks, insurance, etc.)
 The lifecycle of a data model of this complexity needs to be long in order
to accrue the payback benefits.
 The converse is also true. The number of systems business applications
that can take a standalone system, with the vendor’s indexing scheme
and put the system to work out of the box is also rare.

g3/7/2020 : Page – 43
Management of Change (MOC)
The BPR Perspective [14]
 Changes are made to the organization as well as to documents and
processes.
 Managing the changes to the organization are just as important.
 Numerous surveys describe the pitfalls of not addressing both the
technical and organizational aspects of change.
 Without addressing these collateral issues, the installation of an EDMS
will face a high barrier to success.

g3/7/2020 : Page – 44
Management of Change
Reserved Registered Approved
Reject
Reject
Start
Drawing
Process
Managment of Change
Check–In
Renumber
Obsolete
Check–In
Replaced
Check–In
Markup(s)
Check–Out
RenumberedObsolete Superseded
Electronic Vault
Pending
Approval
Approved
for Check–In
Hold
Drawing
Cancel
Drawing
Ready for
Release Ready for
Release
Reject
DrawingCreate
Drawing
Reject
Release
Reject
Release
Work In
Progress
Released
Document
Return Item
to Vault
A Simple MOC State Diagram

g3/7/2020 : Page – 45
MOC Concepts
Data
 Version numbering systems
 Related Documents
 Effectively rules
 Retention schedules
 Replacement in kind criteria
 Equipment maintenance histories
 PFD, Instrument Diagrams, P&ID relationships

g3/7/2020 : Page – 46
MOC Concepts
Process
 Requesting a Change
 Approving a Change
 Making the actual change to the equipment or process parameters.
 Marking up the documents to indicate the changes that were made
 Updating the original documents
 Announcing the change to others
 Placing the equipment in service

g3/7/2020 : Page – 47
MOC Concepts
CAD Based MOC
 Original documents authored in the CAD environment.
 Change control based on drawing revision, authoring process and
relationship to other CAD components.
 Concept of published drawings and their relationship with other
documents assumes drawing office paradigm, not an end user
environment.
 Change control does not follow the plant’s process flow.

g3/7/2020 : Page – 48
MOC Concepts
Pre–Packaged Systems
 Each system assumes a prepackaged data model and document
processing paradigm.
 How documents are routed for review and approval may be fixed.

g3/7/2020 : Page – 49
MOC Implementation Levels
Email based systems
 Ad hoc routing using Email lists
 Audit trails are weak
 Cancellation of distribution usually not provided.
 Timing, Must be done by certain date, is difficult.
 Uses current infrastructure
 CHEAP!

g3/7/2020 : Page – 50
Proprietary systems
 Several EDM vendors provide built in MOC facilities
 The user must adhere to the vendor’s paradigm.
 Usually Expensive for the facilities provided, although market driven
pressures are pushing prices down.

g3/7/2020 : Page – 51
Work Flow Based systems
 Flexible
 Open ended in most cases
 Routing, approval and audit capabilities are provided.

g3/7/2020 : Page – 52
Purpose Built system
 AVOID AT ALL COSTS!

g3/7/2020 : Page – 53
Electronic Vault
This is where the documents live
 The Electronic Vault (EV) provides a secure, persistent storage location
for both the documents and the indexing information needed to retrieve
the documents form the vault.
 Some attributes
 Magnetic disk caching of documents stored in other media (Optical disk)
 Pre–fetching of documents
 Built in back and recovery applications
 verifiable document integrity
 Expandable storage capacity, without introducing downtime for the vault
 Upgradable physical media
 Local cache capabilities to allow distribution of the documents across the
network

g3/7/2020 : Page – 54
Electronic Vault
Components using the EV
Document
Entry
Document
Folders
Document
Printing
Electronic
Vault
Electronic
Input
Scanned
Input
BFC
CAD File
Manager
Drawing
Registrary
Document
Viewing
Remote
Document Access
Management of
Change
User Index
Database
Folder
Retreival

g3/7/2020 : Page – 55
Infrastructure
The Glue that holds the system together
 The key to success in the EDM document delivery business
 Bandwidth, bandwidth, bandwidth
 Network
 Disk transaction rate
 Page movement rate
 Why these infrastructure issues and not others
 Documents will still be scanned a majority of times.
 A neutral format will still be needed, meaning TIFF
 TIFF images of pages are 20 to 100 times as dense as native files
 At the end of the day nearly all work place environments make use of
hardcopy to get the job done. This means printing the documents.
 The paper generation rate is much lower than non EDM based
systems.
 But it is still there all the same.

g3/7/2020 : Page – 56
Vendor Analysis
Nice Logos Aye?
 The list of vendors continues to grow with each year.
 New names replacing old
 Sometimes new companies replacing old
 The vendors at Kalthoff represent the vast majority of vial EDM systems
suppliers for the engineering document management market place.

g3/7/2020 : Page – 57
Vendor Analysis
Vendor analysis and selection is but a small part of the problem
 Needs identification
 Business case
 Requirements analysis
 Functional decomposition
 Vender analysis and selection
 Systems integration
 System deployment
 Backfile conversion
 Training and support
 First operation
 Procedure updates
 Project management
 Business case verification
 Operation
 Technology updates
 Technology migration
 Technology decommissioning

g3/7/2020 : Page – 58
Vendor Analysis
Priority of Activities
 Define of the problem and the consequences of providing the solution
 Bottom line impacts
 Impact of the system on the business process
 Allocation of the proper resources
 Funding
 Personnel
 Management support throughout the organization.
 Control of the scope
 Definition of the detailed project plan
 Selection of the vendor, system integrator

g3/7/2020 : Page – 59
Vendor Analysis
Let’s get to the point here
 The number of vendor providing product offerings that may meet your
needs is sometimes more then:
 The number of people on the selection team.
 The number of must have requirements.
 The number of days left before the system must be installed and running.
 Each vendor can legitimately claim to have just the right solution to your
problem.
 Each vendor can legitimately claim to have systems installed in your
industry, at your competitors, and can do for you what they have done for
them.
 All of this is not meant to be cynical or rude to the vendors. However:
 The problems of document management are known best by you.
 The business environment is your business environment and may be
unique.
 The complexities of the final installed system can not appreciated within
the confines of the tradeshow.

g3/7/2020 : Page – 60
Vendor Analysis
So what's a person to do?
 Have a plan
 Execute the plan
 Measure the results
How are these rules to be applied to the evaluation of vendor’s in
this seminar?
 Define the Class of system you envision for the first installation.
 Include the rollout plan
 How will this system scale up?
 Isolate a list of vendors (Long List) that:
 Appear to have offering that meet your top 5 requirements.
 Appear to have already done this in the past.
 Have references at accounts you recognize, and can reference your self,
without the sales person.

g3/7/2020 : Page – 61
Vendor Analysis
Partitioning the vendors
Standalone Integrated Integrate–able
PC Docs
Sherpa
FormTek
FileNet IMSFN/Saros Mezz
Nova Soft
Auto–Trol
Matra
Altris
Cimage
MetaPhase
CoCreate
SDRC
Intergraph
Documentum
Right Angle
FN Watermark

g3/7/2020 : Page – 62
Vendor Analysis
Partitioning Your Problem (Classes of System)
Archival Productivity Authoring
FileNet IMS
FN Watermark
Anchor Points in the
Spectrum of Vendors

g3/7/2020 : Page – 63
Vendor Analysis
End Point Systems
 FileNet IMS
 Full LOB database integration provided (in fact required, since the
document model that comes with the system is very simple attributes).
 Scalable performance and reliability architecture
 True client server, where the client locates the services through a
clearing house connection.
 Fault tolerance built into the system (not automatic though)
 Lacks middle ground features
 No management of change
 No compound documents
 Watermark
 An extension of the MS Windows file management paradigm
 Save to Watermark instead of save to disk.
 No user defined tables (attributes are limited)
 Tightly coupled with the FILE menu paradigm
 No management of change

g3/7/2020 : Page – 64
Vendor Analysis
Some Key Attributes to Examine
 Line of Business Data Model
 Can the system be integrated with an existing LOB database?
 Can attributes of the business process be attached to documents?
 Can these attributes be updated independently from the document
database, while still maintaining the referential integrity of the EDM
System?
 Can multiple LOB’s be used against the same EDM database?
 Management of Change
 Does the system provide for versioning and revisioning of the documents
(one or both)?
 Can revision or version numbers be assigned according to the needs of
the business?
 Are previous revisions tracked, maintained, archived etc. in a manner
consistent with the records management needs of the business.
 Can the MOC activities be integrated with the existing group–ware
infrastructure?
 Email
 Workflow

g3/7/2020 : Page – 65
Vendor Analysis
Some Key Attributes to Examine, continued...
 Scalability
 Can the system services be partitioned to increase throughput, capacity
or response time?
 Can the system services be partitioned to increase reliability?
 Do the system services map into the domain of the underlying operating
system, in a manner that supports the native networking and system
management facilities?
 NT
 Unix
 Novell
 Integration
 What integration services are provided directly by the vendor?
 What third party integration services are known to work, be reliable,
known to come in on schedule and on budget and provide continuing
support of the system?
 What services are provided to upgrade the system to the next release,
WITH the integrated software?

g3/7/2020 : Page – 66
Vendor Analysis
How to put this all together at the Kalthoff show
 Have a clear concept of the EDM System’s business justification
 How will the system be used to produce a competitive advantage?
 What 3 to 5 key attributes of the system are necessary to meet this
business goal?
 What Class of problem are you trying to solve
 Archive
 Productivity
 Authoring
 Combination of 2 or more
 First isolate the vendors to a small number (5) to gain an understanding of
their capabilities independent of the requirements.
 In most cases, this can be done on paper.
 Schedule interviews of the vendors WITH YOUR AGENDA to determine
the suitability of each product.
 Focus on your needs as well as the canned demonstrations
 Short list to 3 or at most 4 vendors

g3/7/2020 : Page – 67
Vendor Analysis
Keys to a successful project go beyond vendor selection
 Have a strategy – why are we doing this? When will the system pay for
itself?
 Have a tactical plan – how will I actually get the system to work? What are
ALL the steps in the project (in detail).
 Buy COTS when ever possible – adapt the business process to the
available technology is at all possible. Otherwise ask the question When
will this custom software investment be paid back in process savings?
 Plan for obsolescence – the system will be replaced some day
 Continually narrow the scope – success come from controlling the
outcome.
 Continually measure the paybacks – success comes from keeping the
people with the money happy
 Stay Calm at all times!

g3/7/2020 : Page – 68
Thank for for your Attendance

Kalthoff University In-Depth Review of EDM Systems Taxonomy and Classification

Recommended

Recommended

More Related Content

What's hot

What's hot (15)

Similar to Kalthoff University In-Depth Review of EDM Systems Taxonomy and Classification

Similar to Kalthoff University In-Depth Review of EDM Systems Taxonomy and Classification (20)

More from Glen Alleman

More from Glen Alleman (20)

Recently uploaded

Recently uploaded (20)

Kalthoff University In-Depth Review of EDM Systems Taxonomy and Classification