We just finished a two day strategy session for a client in the heavy equipment industry. Having completed a number of efforts with document scanning and report capture, the client was looking to outline a strategy for Documentum going forward. This post will discuss our experience and thoughts on how to introduce the concept of case management as well as steps we outlined to begin the project.
Documentum Strategy Goals – Identify the Vision
The first activity we did with the client was to outline the goals of the Documentum strategy. Working with the client, we came up with the following goals:
- Capture as much electronically as we can
- Eliminate use of physical storage (cabinets – trailers in some cases)
- Quick wins to add up to big efforts
- Gradually reduce production of paper
- Focus on a Business Process – not just capture of documents
We also identified some particular technical goals based on thoughts regarding how documents might be leveraged in the future. Some specific points included:
- Extranet – Remote Access
- Wireless/Mobile
- Electronic Forms/Workflow
- Case Management
While our client is a current TaskSpace user, they were only using TaskSpace for simple routing and basic search and retrieval. Moving beyond the typical “let’s capture all of these document types” approach, we explored how a case management view of documents focuses on collections of documents. A real “a ha” moment was when we discussed relationships between documents within the normal search terminology. For example, if I am looking at an invoice for warranty work, I might want to see other documents related to that particular invoice without having to perform another search. These documents could include:
- Work Orders
- Email exchange with the client requesting the work
- Pictures of the work before and after completion
A big part of the vision was to understand not only the case, or activity that would lead to the invoice and surrounding documents, but also how those cases were related.
Step 1 – Identify the Unifying Entity(ies) between Documents
The unifying entity between related documents for our heavy equipment vendor was, as expected, equipment, or more detailed, the unique equipment serial number. When we discussed how documents are related rather than just document types, a clearer taxonomy for relationships was uncovered. For this client, some of the types of documents that all relate to equipment included:
- Invoices
- Equipment Pictures
- Purchase Orders
- Work Orders and Service Documents
- Sale and Lease Documents
The client started to get a vision of how the taxonomy would emerge based on several user scenarios. For Example, in addition to our previous example on invoices and work orders, if renting a piece of equipment, the user might want to view related documents in regards to the service previously performed on that piece of equipment.
Step 2 – Identify the Cases and other Case related data
In discussions with the client, we introduced the idea of activities that would result in a logical collection of documents or “case”. For experienced Documentum users, many of us have seen the Whitney insurance demo where the Unifying Entity was a policy holder (or insured). The case is a specific claim (usually a car accident – since it would result in cool mobile phone pictures). Other cases for insurance could be policy issuance or policy renewal.
Cases for our clients in regards to equipment included:
- Order
- Lease
- Sale
- Warranty
- Service
For each case, we thought the addition of customer-id as well as date was important overall. Keep in mind that a piece of equipment might be leased by more than one customer over its life time so customer-id could also be used as a unifying entity. Cases might have specific things added (for example Sale might need a create date as well as sale date).
By focusing on case, document indexing can be automated so that documents added to the case inherit all of the case’s attributes.
Step 3 – Identify how a Case would be created
The client didn’t want a user to be able to create a case in Documentum at will. Instead a controlling system will initiate a case including customer purchase, warranty work or rental/sale. For example, in insurance, there is usually an overall policy issuance system or claim management system. Our team (client and TSG) really wanted to make sure that defining those critical items (like serial number, customer-id) were always accurate and generated from the controlling system.
Step 4 – Next Steps
Armed with our understanding of the case management approach we identified the next steps for the project to clarify the vision. These steps follow the normal TSG methodology for starting any project and include:
- Interviews
- Prototype
- Focus Groups
- Implementation Plan
The methodology gives the client and TSG a fast-track approach to establishing and gaining buy in to the long term document management strategy.
What about xCP?
Typically, many clients would start with a product like xCP and look for opportunities where the business process fits the product capabilities. That was how TaskSpace was introduced in the past. While we showed some different examples of case management, we didn’t want to focus on a product demo and risk that the vision would be clouded by what the product did or didn’t do. For our client, workflow/BPM isn’t as much of a driver as understanding how documents drive a process. Our next steps are to conduct more detailed analysis into the Documentum vision and then introduce other concepts like:
- Email to and from the case folder
- Case Notes
- Workflow and BPM
All of these fit into the xCP as well as our Open Source product, HPI. Once the vision is finalized, we will work on a review of the products to determine the correct product or potential hybrid approach.
If you have additional thoughts or techniques that you have found useful, please comment below.
Paras Jethwani says
This is an excellent article that focuses on a different approach to content management – which is (in my opinion) more ‘vertical’ when compared to traditional ECM where the approach is to understand the document types, controlling changes to those documents, flagging organisation’s records, accountability and security etc. – generally across the board.
Case based solutions are in a way point solutions that focus on a critical business process and all documents that form part of that process; however, the methodology highlighted here takes a step back and uncovers the central entity/s around which most of the case-based processes would be based. Even though the implementation may still be one process/case at a time but by having some understanding of the overall vision the meta-data and security structure can be designed for extensibility.
In one of our recent solutions this central entity was a ‘candidate’ in a recruitment agency that maintained a resource pool of suitable candidates from which job orders would be filled.
Their candidate management system was the central system from which cases originated.
However, one of the most interesting ‘change management’ challenges we are facing (during solution design) is – how do we complement their paper-based process with Documentum without requiring their recruitment consultants to learn/manage information in a new system aka TaskSpace. They already use Email and their candidate management system; having to learn and manage TaskSpace would be a hinderance in adoption. We are thining of using Email as much as possible but obviouly cannot remove all interactions with TaskSpace.
This would be a common challenge in most case-based solutions as all organisations usually have a central transactional system in place that their users use on a day to day basis.
TSG Dave says
Paras,
Great comment. As consultants we all have to balance the “client needs this” with the “software does this”. Getting creative in how to resolve client/user needs with support and training is difficult. IT typically wants “out of the box” for support reasons but it can lead to training and risk of completicated interfaces.
I like your email approach as we have used that successfully for a number of clients to easily import into Documentum from a variety of sources without having to roll out a complex interface. OpenInterChange is our open source offering around email ingestion. Couple of Blog posts out there about how we used it if it helps with your process.
Dave