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.