Documentum vs. OnBase Part 4: Access Control and Privileges

This is an odd one, it could be a comparison where patents play a role in the underlying design because in OnBase there is no explicit mention of “access control”. Let’s try to build a simple use case to illustrate the differences between the two approaches to control who can do what when to a document.

Use Case: Excluding a reader group from viewing documents in their draft state, then allowing the reader group to view documents in their approved state.

DCTM:

1. Create a dm_document object type with attributes
2. Create a permissions list for draft and approved
3. Create a lifecycle for the document type
4.  Add two states for draft and approved
5. Add an action to each state to apply the permission set (or ACL)
6. Apply the lifecycle to the document upon import (manually or automatically)

Or

1. Use ACLs inherited from Folder Security and the folder’s permissions
2. Do steps 1 and 2 and set permissions on folders and use folder security, moving documents from a draft folder to an approved folder

Or

1. Use ACLs inherited from the Owner’s permissions
2. Do steps 1 and 2 and set permission manually on the document after

Or

1. User ACLs inherited from the document type’s permissions
2. Do step 2 and set permission manually on the document after

OnBase:

1. Create two document types: draft and approved
2. Create two User Groups (at a minimum); one with privileges to create, modify, and delete the draft docs, and one with privileges to view the approved document type
3. Assign the ability to change doc types to the author’s group

Use Case: Make a document revisable

DCTM:

1. Create an ACL with Read/Write/Version permissions
2. Apply it to the document

OnBase:

Change to privileges on a group that is linked to the doc type

Thus, in OnBase it is routine to change doc types as keywords are shared across the types, which is taboo in DCTM. However, in DCTM you have three distinct ways to inherit permissions. This is more flexible. The overall difference in permissions is that OnBase is group privileged based and DCTM is primarily object permission based. Groups are a lot more configurable in OnBase which lends itself to easier setup from a User’s perspective. In DCTM, the document object has its own attributes and is linked to ACLs and Lifecycles. In OnBase, the document is more of an equal player in the system.

Documentum vs. OnBase Part 3: Scan/Index workflow

In Parts 1 and 2, we looked at configuration and relations. Now let's look at scanning and indexing using Documentum's tools vs. OnBase's.

Documentum offers a wealth of tools and functionality for scanning, indexing, and validating paper. The huge difference between Documentum and OnBase is that the OnBase user interfaces are integrated into the scan/index modules. You don't have to index in one UI, then switch to another for further processing like you do with Captiva products. EMC bought Captiva but did not fully integrate it.

The concept of a interoperable modules was probably not considered as the most important aspect of the acquisition. However, as these software acquisitions play out over time, you can see the long term negative effects of not integrating the products. I believe the days of buying software to gain market share only are gone. It may be profitable in the short run, but these purchases need to be well integrated in the long run to be viable.

Invoices: Documentum
Let's say you use Input Accel to scan and index invoices for example. You will have to have an approval workflow and an auditing workflow. Which UI is used for the approval workflow, Input Accel or Webtop or xCP, or D2? Which systems tries to match the POs by invoice number, receipts, and total amount, or is this custom? I have seen some of the xCP solutions for this activity and they are complex and expensive and custom to the general ledger integrations.

Invoices: OnBase
Scanning and Indexes are configured and executed through OnBase's Clients. There's no patch work of double checking and exporting, there's just one interface called "Import > Scan/Index", that's it. You set up the scanner, give the workstation rights to scan, configure the document type and scanning queues, and you're good to go. Oh, and the workflow can be configured to execute after you commit the batch. It's all in one and takes about a 5th of the time to configure. It scales as well.

Let's face it, EMC treats Documentum as a repository for dumping content. It cares about amassing storage first, then figuring out what to do with it, eventually...

Documentum vs. OnBase part 2: Relations

In Part 1, I looked at configuration between Documentum and OnBase. Part 2 focuses on a few relations which exist in each software suite. I define relations as any object which is associated with another object.

Folders

DCTM’s at the core has cabinets and folders for System, Resource, and Temp folders among others. OnBase does not show any folders. The first thing you realize when you use the client is that it shows doc retrieval functionality for doc group types, doc types, dates and keywords. I found myself clicking around for folders and felt disoriented. This boils down to the fundamental navigation difference between the two: DCTM shows folders as a base, whereas OnBase shows search initially. To dig a little deeper, we can see File Cabinets, Folders in OnBase, however the configuration is a lot different. In DCTM, the model is fixed base on creating a new folder type which has a supertype (dm_folder). In Onbase, the folder type is part of a hierarchy which inherits properties, but these are not exposed. You just create a parent folder type and a child folder type.

Scan Queues

DCTM bought Captiva and integrated it into Documentum. This integration is poor at best. You use Input Accel to scan and index then export into DCTM. The whole idea of exporting into DCTM tells you how little they are integrated. In contrast, OnBase, at its core, was built with image scanning integration. This means you configure scan queues with doc types and keywords and start scanning. No jumping between licensed product hassles with Input Accel and indexing and QAing in one interface and validating again in DCTM.  OnBase scan queues are configured with indexing and processing in mind, meaning that it is very straight forward to create a queue, associate a workflow, and assign doc types, plus access control. One huge advantage in OnBase is that a document like an invoice can be invisible to ordinary users, but in scan queue for indexing and QA it is visible. Tell me you don’t have to jump through hurdles to achieve this in DCTM…

Lifecycles

In 1999, DCTM was the only content management tool which touted the concept of document lifecycles. Now most do, including OnBase. The evolution of lifecyles in DCTM, however is interesting in that it had LCs before workflow. DCTM LCs were designed with a lot of doc processing power (actions) in them and workflows pushed docs through them: a doc in DCTM can have one LC and it’s a pain to reassign it. In OnBase, Lifecycles consist of workflow queues which have tasks and actions associated to them. You can have multiple LCs associated with a document as part of a continuum of potential tasks and actions which could be performed on it.

Workflow Folders

In Process Builder in DCTM, you can configure folders as attachments to workflows. You can link attachments to those folders as they enter into the workflow. TaskSpace allows you to view the folder contents, and the form associated with the task, and even has workflow queues. It’s just that the time it takes to build the TaskSpace application with action buttons, document settings, folder contents settings, the Process Builder workflow with forms and tasks and integrations with TaskSpace, is about 10 times as much time as it takes in OnBase. OnBase was built with lifecyles and workflow in its core configuration.