xCP - Dell EMC Education Services

xCP - BRIDGE TO AN INTELLIGENT WORLDMouli PonnupandySenior Program ManagerEnterprise Content ManagementNTT DATA

2012 EMC Proven Professional Knowledge Sharing 2

Table of Contents Abstract...................................................................................................................................... 4

Case Management ................................................................................................................. 4

Case Management Process Flow ........................................................................................... 5

Content Enabled Process Automation .................................................................................... 5

What is EMC Documentum xCP? ........................................................................................... 5

xCP Solution Approach .......................................................................................................... 6

xCP Project Execution Methodology ....................................................................................... 6

xCP Project Team .................................................................................................................. 7

Acme Company ......................................................................................................................... 8

Order to Cash Process ........................................................................................................... 8

What should we automate? ...................................................................................................11

Why should we automate? ....................................................................................................12

Where do we automate? .......................................................................................................12

How do we automate? ...........................................................................................................12

Bill of Materials ......................................................................................................................12

Core Components .................................................................................................................13

Platform Extensions ...............................................................................................................13

Optional Components ............................................................................................................13

xCP Sales Order Approval Automation .....................................................................................14

Documentum xCP – SAP – Mobile Integration ......................................................................14

Sales Order Approval ............................................................................................................14

How did we do it? ......................................................................................................................20

xCP Object Model .................................................................................................................20

xCP Process Design ..............................................................................................................21

xCP Forms Design ................................................................................................................22

xCP TaskSpace Configuration ...............................................................................................23

xCP Business Activity Monitor Configuration .........................................................................25

Case Management, Intelligence and Beyond.........................................................................25

Reference .................................................................................................................................26

Disclaimer: The views, processes, or methodologies published in this article are those of the author. They do not necessarily reflect EMC Corporation’s views, processes, or methodologies.


List of Exhibits Exhibit 1: Acme Company – Order to Cash Process ........................................................... 11

Exhibit 2: Acme Company – Incoming Mail Integration ........................................................ 15

Exhibit 3: Acme Company – Sample Sale Order ................................................................. 16

Exhibit 4: FTP Integration with Documentum xCP ............................................................... 17

Exhibit 5: Query SAP using Process Services for SAP ........................................................ 17

Exhibit 6: SAP Query Results for SO # 2010060882 using Content Services for SAP......... 18

Exhibit 7: Documentum – SAP – SMTP Server Integration ................................................. 18

Exhibit 8: Acme Company – Approval email for Sales Order using html template ............... 19

Exhibit 9: Acme Company – Approval email for Sales Order on iPhone .............................. 20

Exhibit 10: Acme Company – Object Model for Sales Order Approval Process ................... 21

Exhibit 11: Acme Company – Taxonomy for Sales Order Approval Process ....................... 21

Exhibit 12: Acme Company – Case Folder Contents - Sales Order Approval Process ........ 21

Exhibit 14: Acme Company – Order to Cash Process ......................................................... 22

Exhibit 14: Forms Designer View – Order to Cash Process................................................. 23

Exhibit 15: Forms Application View (Active Preview) – Order to Cash Process ................... 23

Exhibit 16: Acme Company – TaskSpace Designer View .................................................... 24

Exhibit 17: Acme Company – TaskSpace Business User View ........................................... 24

Exhibit 18: Acme Company – TaskSpace Business User View with Daeja Viewer .............. 24

Exhibit 19: Acme Company – Business Activity Monitor – Sales Order Report.................... 25


Abstract All content management professionals (including me) are thought to believe that content is at

center of our universe and business rules (mostly metadata) revolve around it. There are billions

of stars (metadata) and millions of planets (content) in our universe but only a planet at the right

distance from a star has the ability to nurture intelligent life! An intelligent business application

can be developed only at this meaningful intersection of content and business rules. Enterprise

Content Management (ECM) applications are traditionally content-centric whereas Business

Process Management (BPM) applications are transaction-centric. Complex business scenarios

that require coordination between people, process, and data can be built when different schools

of thought, i.e., Process and Data, are bridged using a powerful toolkit such as EMC

Documentum® xCP.

There is a constant need to create, process, and manage large volumes of business content

with respect to certain business processes. These processes are in turn driven by business

rules targeted to achieve a business goal. There is a legitimate challenge now to manage this

business content, process data, and business rules together. They are not standalone entities

and need to be presented in a unified way for business users to accomplish their business

goals.

Case Management – Based on which analyst you reference, it is either Content Enabled

Vertical Applications (CEVAs - Gartner) or Content Centric Applications (CCAs - Forester).

These applications are also loosely called Case Management Applications by the larger

community. Let’s see why case management is different from business process management.

BPM systems are built based on business rules that ensure transactions are processed on

occurrence of defined trigger events whereas in case management there is a little leeway with

business rules.

Though both systems templatize core business process that is to be automated from initiation

through to completion, case management systems have a soft side. The decisions made are not

constrained by business rules set in the system. The case analyst exercises his choice along

with set business rules to decide on the case outcome. Let’s see this with an example of order

to cash process.

The system defined credit limit for processing a customer order is set at $100 whereas the

customer order totals $125. If this is a traditional BPM application, the customer order would be

rejected. What if this is one of your loyal customer who has excellent credit history? This is

where the human side of case processing takes over from BPM applications. The case analyst


looks at customer details and past purchase history and can opt to override set business rules

and process this customer order. This decision might require collaboration with the customer

and credit manager. If so, the case analyst initiates these collaboration activities and updates

the case history to document this exception. At the end of the day, we have a happy customer!

Case Management Process Flow – A definitive sequence of tasks need to be completed

for an application to qualify as a case-based application. These are:

1. Case Initiation – A trigger event (manual or automatic) initiates a case.

2. Case Creation – Once a trigger event initiates, a case is to be created.

3. Case Verification - All case-related artifacts are verified to ensure that it’s fit for further

processing.

4. Case Processing – This is where people, process, and data connect to perform all case-

related work.

5. Case Exception – All case-related exceptions which arise in case processing are

handled here.

6. Case Closure – Once the case achieves its intended business goals, it comes to a

logical closure.

7. Case Archival – Case artifacts are retained to meet compliance standards which are

imposed either by internal rules or external regulations.

Content Enabled Process Automation – This emerging technology area brings together

the best of both worlds, i.e, ECM and BPM, for the benefit of business users. In layman’s

language, it is Case Management (though not in a literal meaning). The primary objective of

content enabled process automation is to provide a content-centric collaborative and process-

centric dynamic work environment that aims to automate routine information management tasks

which do not need human intervention while providing complete visibility into all process related

events and metrics.

What is EMC Documentum xCP? – xCP (Accelerated Composition Platform) is a solution

framework which has composition tools and necessary supporting technologies for building a

content enabled process automation application. It is built on top of the time-tested

Documentum Content Management Platform. xCP tools and applications rely on Documentum

for all content- and process-related functionalities. There are a few non-core products which

provide for enhanced functionality such as Document Sciences xPression for Documentum

Output Management and EMC Captiva® for Scanning and Imaging Management. xCP differs


from a conventional development-oriented approach of building a workflow application and is

more configuration-driven where working prototypes are built and refined over a period of time.

xCP Solution Approach – Content Enabled Process Automation typically starts with a

process analyzing and reengineering phase where all current business processes are

documented and analyzed for automation. The touch points where automation is proposed are

reengineered to accommodate it. These tasks are done by a process analyst in coordination

with business processes owners. The process blueprints are handed over to an xCP project

team to design and build a solution for automating this process. The lead time to develop an

xCP-based application is minimal once the to-be business process blueprints are available as

the design is model-driven which utilizes lots of reusable components and industry standards for

integration with existing line of business applications. An initial prototype for the process is

modeled and refined based on constant business feedback over a period of time. Once this

prototype is certified to meet reengineered process requirements, a full-blown development and

testing phase completes modeling to deployment phase of a solution which is ready for end

user testing and acceptance.

Let’s look at an example that details what goes into making a Content Enabled Process

Automation application taking a generic Order to Cash process along with soft areas such as

project management.

xCP Project Execution Methodology – xCP projects are a unique combination of content

management and business process management application. Conventional wisdom suggests

that we should follow the same execution methodology collectively that is applicable for them

individually (ECM and BPM) but I beg to differ. This approach results in a solution design that

focuses exclusively on managing content and/or processes. My experience in implementing

xCP solutions shows that this approach often distracts the project team by making them focus

on eliciting all required requirements at the beginning of the project itself. The main selling point

of a case management application is the ability to be flexible and accommodate any and all

ongoing changes. The process that is being automated by xCP is fluid and changes with

changing business needs. In essence, it is not a traditional design, deploy, and maintain type of

business application as xCP solutions constantly evolve in the direction of changing business.

We need an integrated approach where the focus is on presenting tasks and content at the right

time to relevant knowledge workers based on their role. In essence, we don’t focus excessively

on knowing all the requirements or exceptions or documenting all of it before we commence

design. We don’t need to describe or know complete end-to-end business process before we


commence work. Our focus is to define all tasks that are relevant to complete a business

objective. A Task (e.g. Quality Control) is executed according to set of business Rules (e.g.

Checklists) and is performed by a certain Role (e.g. Quality Analyst) with the aid of relevant

business Content (e.g. Procedure). When we focus on tasks, we are sure to collect all allied

requirements that are required for designing an xCP application. The case worker dynamically

decides which route (set of tasks) to take to reach the end point.

Change is an integral part of xCP projects and we run a very high risk of schedule and cost

overrun along with proportionate customer dissatisfaction if we stick to our waterfall model of

project execution. If we still insist on the waterfall model, one should expect a significant amount

of rework when the application is released for acceptance testing. I strongly recommend a rapid

release approach (not truly agile but a hybrid of agile and waterfall model) where we create a

prototype in a sandbox environment for core processes which are released to business users

for review. These prototypes (agile model) are refined until it reaches business acceptance

(document details of this baseline prototype) and then application development (waterfall model) takes shape. This win-win approach enables the customer team to accommodate

ongoing changes while at the same time insulating the implementation partner from scope and

cost overrun.

xCP Project Team – An xCP Project Team comprises:

Information Architect – Responsible for creating core object model for the proposed system.

This person also ensures that a well-defined taxonomy is in place along with appropriate

security model to accommodate all business content that will be managed by this application.

Process Architect – Primarily responsible for converting process blueprints into process

models which will be orchestrated centrally.

GUI Specialist – Focuses on providing the right combination of forms and other interfaces to

enable business users to capture all metadata and other collaboration related items.

Reports Specialist – Responsible for creating, managing and enhancing reports that are

available for use from the system.

Integration Specialist – Focuses on building integration components or extending existing

integration tool kit.

This core team collaborates to produce an initial process automation design which is then built

as a fully functional prototype. This prototype is reviewed and revised multiple times based on

process owner’s feedback. All five roles described above do not work independently of each

other (e.g. a reporting requirement might need an additional form level input or fetching data


from external applications) and need to work cohesively to bring out a robust and scalable

business application. Other generic roles such as Business Analyst, Project Manager, and

Business User are not described for obvious reasons (I assume you are familiar with these

roles).

Acme Company

Assume Acme Company is in the distribution business and runs SAP for its

Enterprise Resource Planning needs. Using a distribution business as an

example enables us to not include any value-adding process that a

company performs before finally selling a finished product. The reason

behind choosing SAP as an ERP application is to demonstrate strengths of

a standard Documentum and SAP connector. Customers who run other ERP applications can

seamlessly integrate with Documentum platform using industry standards such as Web

Services.

The business process described for Acme Company can be generalized to any business

organization cutting across various industrial domains if we leave out the value adding process.

What do most companies do? All of them essentially have four core business processes which

are logically grouped under two streams:

1. Procure to Pay (Buying and Accounts Payable);

2. Order to Cash (Selling and Accounts Receivable).

Let’s define Order to Cash process in detail before going on to automate the Sales Order

Approval flow using xCP components. Choosing this sale order approval use case illustrates

close integration between Documentum and SAP using xCP components.

Order to Cash Process – Order to Cash (OTC) is a key business process that has direct

bearing on working capital and operational cash flow thus impacting all key financial metrics by

which a company is measured. OTC is a multistep process which is initiated by customer sales

inquiry and continues until payment is realized for product sold or services offered to a

customer. The key steps are:

1. Presales / Sales – What do we do before we buy? We all enquire about the products,

price, delivery, warranty, and other terms. This is the beginning of a sales cycle which

typically starts with an inquiry for which a company responds with a quotation.

Customers negotiate with sales or product managers to arrive at an agreement after


which the customer places a Purchase Order for a product or service. Input = Quotation; Output = Customer Purchase Order

2. Order Verification / Entry - We assume that the customer has expressed interest in

buying the product by placing a purchase order. Before an order can be processed, a

sequence of checks and validations need to be performed. What are they? We need to

check if the customer has a purchasing relationship or agreement with us which is

essential for payment realization. We need to check if the product being requested is

available in inventory. If it is a new customer or new product, a corresponding customer

code, material code, and vendor code needs to be created in ERP. These checks and

validations differ across organizations but only after the order passes verification is it

passed on to the Order Entry team for further processing. Input = Customer Purchase Order; Output = Sales Order

3. Order Processing – The sales order created in the earlier step needs to be approved

by the organization before it can move to fulfillment stage. Again, the approval process

differs across multiple organizations but at the basic level it requires two levels of

approval. The first approval is required from the business unit selling the product for

price, margin, and discount that the sales team has promised earlier in quotation. The

second approval is required from finance for credit exposure and history, payment terms

and time, along with other relevant items. Input = Sales Order; Output = Order Approval

4. Order Fulfillment / Delivery – Once an order is approved, it moves to the delivery and

fulfillment team. Multiple orders for the same customer or delivery destination are

clubbed together to optimize pallet size during transportation to reduce shipping and

forwarding cost. Delivery authorization by way of Outbound Delivery Notification (OBDN)

is prepared in ERP systems to account for stock movement. Shipping documents such

as Traffic Invoice and other customs-related documents are prepared before the logistics

provider is notified of goods availability for pickup. Input = Order Approval; Output = OBDN and Shipping Documents

5. Logistics – The logistics provider would have received shipping notification and related

shipping documents at the end of the previous step. Transfer of ownership of goods

takes place at a designated pickup point between the company and third party logistics

provider or customer forwarder. Once the delivery team hands over the goods,

Customer Finance is notified to invoice the customer for goods being delivered. The

customer coordinates with the logistics provider for shipment tracking and delivery.

Input = Goods and Shipping Documents; Output = Proof of Shipment


6. Accounts Receivable – The Customer Finance team prepares the invoice and sends it

to the Accounts Receivable (AR) team which sends invoices along with payment options

available to the customer. Accounts Receivable (AR) team intimates filed collection

executives about expected customer payment. Invoicing need not wait for actual

shipment or delivery of goods in most cases. Most vendors offer discounts on net

receivable if the invoices are paid upfront before delivery of goods or when goods are

prepaid (in such cases invoices are raised for adjustment). Input = Proof of Shipment; Output = Invoice

7. Payments and Collection – The Field Finance team ensures there is continuous follow

up with the customer for collection of dues. Based on payment option chosen by the

customer, the field finance team collects either the payment instrument or proof of

payment and sends it to AR team which closes the Order to Cash process. Input = Invoice; Output = Payment Proof

8. Sales Returns – Once goods are received at the customer warehouse, an audit is

normally performed to ensure that goods received are in order. Any non-conformance

(e.g. mis-shipment, dead on arrival items, defective and damaged) to set quality

standards results in sales returns. The customer contacts the Service Desk to obtain a

return material authorization (RMA) to return goods for replacement. Input = Goods Received Note; Output = Return Material Authorization

Note: This is an end-to-end process which includes various sub-processes. There is no

assurance that all process instances will go through all these steps—e.g., process is terminated

if there is no approval to sell or when goods delivered are in order, there will not be any sales

return and likewise. If you carefully note both input and output for each sub process they are

essentially business content (documents).


Exhibit 1: Acme Company – Order to Cash Process

What should we automate? A very good candidate for automation is a process that has a

series of clearly identified tasks which are required to be performed in a predetermined fashion

in collaboration with either internal and/or external stakeholders and completion of such tasks

are normally time consuming. This helps increase information throughput for an employee who

needs to process large volumes of data from a multitude of sources which can either be static or

dynamic in nature.


Why should we automate? An automated process frees employees from mindless work

performed manually so they can focus on more productive tasks requiring their time and

attention. Process automation helps enforce discipline in adhering to established SLA’s for

service delivery, measures throughput, helps identify or even forecast bottlenecks based on

analytics, and enables business leaders to have complete control over processes done remotely

from diverse geographical locations.

Where do we automate? There are two parts to this process; manual and automatic/semi-

automatic. In the Order to Cash process illustrated above, the Quotation, Sales Order, OBDN,

and Invoices are generated in SAP (or other ERP applications). The rest of the tasks are driven

either manually or on emails. This gives excellent scope for automation to reduce order

processing time and reduce the burden of working with multiple systems. The key to success

lies not in automation of manual tasks but integrating with SAP (or other ERP applications)

seamlessly so that most of the manual touch points (often error prone) are driven after certain

SAP (or other ERP) actions are automated and there is bidirectional data transfer between xCP-

based Workflow Management System and SAP (or other ERP applications).

How do we automate? We need to manage both process and content in a unified way.

There is no doubt that there are standalone ECM and BPM products which will perform very

well in their own domain for the use case we are discussing (Order to Cash). If we go with such

a choice, the only path that is available for a customer is a costly custom integration between

these two products i.e., BPM and ECM. The difficulty doesn’t end there as another set of

integration is needed with the backend ERP application (in this case SAP). A powerful

alternative from EMC combines the best of both worlds; the xCP platform, when combined with

integration toolkits available in Documentum, can seamlessly integrate with SAP or other ERP

applications using industry standards such as Web Services most of which is already available

(ERP Integration Services) for invocation from within Documentum.

Bill of Materials – What core and optional components along with platform extensions do we

need to automate an Order to Cash process?

What is a core component? They are platform- independent building blocks which package

essential features, functionalities, and necessary integrations without which, neither content

management or process orchestration is possible. These are must-have features in layman’s

terms.


What is an optional component? They are platform-dependent (Documentum or other

enterprise applications) building blocks which package essential features, functionalities, and

necessary integrations (to Documentum) without which neither Input Management (Captiva for

Scanning and Imaging Automation) or Output Management (Document Sciences xPression for

Creation and Delivery of Customer Communications) is possible. These are nice to have

features in layman’s terms.

What is a platform extension? These are essentially services that depend on or extend core

components to offer a rich client experience or offer loosely coupled integration to third party

enterprise applications.

Core Components 1. Documentum Content Server – Provide for Content, Process, and Repository Services.

2. Documentum Administrator – Configure, Manage, and Administer Documentum Suite.

3. Documentum Composer – Create, Customize, Package, and Deploy Applications.

4. Documentum Business Activity Monitor – Process Analytics, Dashboards, and Reports.

5. Documentum Process Analyzer – Analysis and Validation of Process Models.

6. Documentum Process Builder – Compose and Model Business Processes.

7. Documentum Process Engine – Process Execution and Orchestration, Outbound

Integration.

8. Documentum Process Integrator – Inbound Integration.

9. Documentum Process Simulator – Offline Process Simulation.

10. Documentum Forms Builder – Compose and Design User Interface.

11. Documentum TaskSpace – Configurable Client Tool.

Note: All the products listed above under core components along with Documentum Imaging Services platform extension are

bundled into Documentum xCP Platform.

Platform Extensions 12. Documentum Imaging Services – Annotations, Page Serving, and Modification.

13. Documentum Process Services for SAP – Two-way SAP Connector extending Process

Manager functionality.

14. Documentum Content Services for SAP – SAP Standard DMS and ArchiveLink

Interface.

Optional Components 15. Captiva InputAccel for Invoices – Invoice Processing and Accounts Payable Automation.

16. Document Sciences xPression – Customer Communications Management.


Note: The optional products discussed below are enterprise class products by themselves. They can work standalone but they are

more of an enabling application (meaning, either they have a downstream application which consumes their output or an upstream

application to which they look up for work).

xCP Sales Order Approval Automation Documentum xCP – SAP – Mobile Integration – Where do your managers work?

Undoubtedly, the answer is close to your customer, mostly travelling and meeting with

customers. All sales orders typically need approval of respective group managers who are likely

to spend a good amount of time travelling. So if an application is available only via regular

channels, group managers must either come to the office to clear all approvals or connect to the

corporate network via VPN to access workflow application. Is this true automation? What if they

don’t have a reliable Internet connection? Or, do they need to log in to the application at all in

the first place? Decision making only needs information relevant to context. Too much

information in this case doesn’t help or have an effect on outcome of the decision-making

process.

Let’s see a use case of Sales Order Approval within this Order to Cash process to understand

how a complex integration between two enterprise applications (Documentum and SAP) can be

achieved with very minimal work. The core objective of the Documentum xCP suite is to be

configuration-driven and avoid complex custom integration. I will illustrate Sales Order Approval

to bring out integration touch points between Documentum and SAP then move on to show how

information from these applications are served on a handheld device.

Documentum xCP empowers today’s mobile workforce with multiple non-synchronous options

to respond to a request for approval or review on the fly. The application truly reaches to end

users’ mobile and handheld devices to decide on the go.

Sales Order Approval 1. Sales Orders are emailed by customers or sales managers or product managers to a

designated inbox (xCP uses SMTP Integration to read and process incoming emails and

triggers appropriate workflow tasks for initiation, hold, approval, or rejection). In this example,

we assume a customer has placed orders for three products from three different business units.


Exhibit 2: Acme Company – Incoming Mail Integration

2. Order Processing Team takes hold of this task and creates a sales order in SAP (after

resolving exceptions such as creation of customer or material code). A sample sales order is

show below. This order has three different types of products. Assuming each product is being

sold by different product groups within Acme Company, all three product managers should

approve or reject sale of goods at that price committed by the sales team. In the example below,

line items 1 and 2 are being sold for a negative margin (meaning loss) whereas line item 3 is

being sold for a profit. Also, the consolidated order fetches a profit though there are two loss-

making components in this order. After creating Sales Order in SAP, the order processing

analyst enters the sales order number in TaskSpace screen (in this case 2010060882) and

marks those task assigned to him as closed, which moves it to next step in the process.


Exhibit 3: Acme Company – Sample Sale Order

3. A sales order thus generated in SAP is exported as a PDF file to a designated folder location

which is being watched by (FTP Listener) Documentum Process Integrator. The file name is

usually of convention so_1234567890.pdf (in this case so_2010060882.pdf). Once

2010060882.pdf is available in the FTP folder, Documentum Process Integrator picks up this file

and uploads it to a case folder using sales order number 2010060882 as correlation identifier.


Exhibit 4: FTP Integration with Documentum xCP

4. Once the file is uploaded from FTP location to case folder, an automatic activity queries SAP

to fetch header and line item details of the relevant sales order (in this case SO # 2010060882).

The original pdf file can either be deleted or archived in FTP server. The query results are

stored temporarily in Documentum as process variables.

Exhibit 5: Query SAP using Process Services for SAP


Exhibit 6: SAP Query Results for SO # 2010060882 using Content Services for SAP

5. A two-level approval process is initiated. There are three product groups in SO # 2010060882

and sale of each product has to be approved individually by three different business units. A

group manager then consolidates individual approvals from product managers and provides for

approval or rejection. The query results from the previous step is mapped to an HTML email

template; final mail which goes to individual product managers looks like the sample mail below.

Documentum xCP SMTP Integration is used for sending mails to product managers.

Exhibit 7: Documentum – SAP – SMTP Server Integration


Exhibit 8: Acme Company – Approval email for Sales Order using html template

Note: Company and Customer Name are masked.

The managers are to reply to the above mail with just one of the four key words; “Approved”,

“Rejected” “On Hold”, “Exception”. The system is also designed to capture variations such as

“Approve”, “Reject”, “Hold”, “Discuss”. In the mail above there is a unique sixteen digit

alphanumeric code (work item id, which is uniquely generated for each task by xCP) enclosed in

square brackets. This is used to match all outgoing mails with incoming approvals or rejections.

The system is designed to save both outgoing mails and incoming approval mails within the

case folder so there is no question of approvals or rejections by product managers.

A consolidated SO approval mail is sent to each group manager for approval together with a

sales order (as a PDF attachment) to their Exchange inbox. The mail is sent in HTML format,

making it readable in all mobile and handheld devices. Why not a mobile app? We wanted to

stick to the true idea of using xCP – no custom development required to explore and use out-of-

the-box features of Documentum xCP. The screenshot below is from an iPhone user logged into

his Exchange inbox over a cellular service provider.


Exhibit 9: Acme Company – Approval email for Sales Order on iPhone

Note: Company and Plant details are masked.

How did we do it?

xCP Object Model – It is a well established fact that object model and taxonomy is the core of

any content management system. This helps us visualize the possible types of documents that

will be handled by this system and how each of these different document types are related. This

further helps us relate tasks, roles, and user privileges. To us, each Sales Order approval is a

case (in our example) and hence each sales order approval process is stored under a unique

case folder. This case folder is the logical collection all related documents; customer purchase

order, mails from the sales team, quotations, company sales order, approval mails from

business unit and finance team, and so on.


Exhibit 10: Acme Company – Object Model for Sales Order Approval Process

Exhibit 11: Acme Company – Taxonomy for Sales Order Approval Process

Exhibit 12: Acme Company – Case Folder Contents - Sales Order Approval Process

Note: Company details are masked.

xCP Process Design – A process model is built before most other work in a xCP project. The

process model serves as the base around which forms, object model, reports, and other

building blocks connect. Documentum Process Builder is used for process modeling and

validation. It serves as a two-in-one tool to design and validate the model before it is installed for


use by downstream tools. Let’s consider Order to Cash processes and see how this can be

modeled into a process. There are ten sub-processes (quotation to sales return) in an OTC

process – each of which might be a multistep individual process by itself. To keep it simple for

illustration, I have just depicted sub-process in a process flow. Each sub process when

expanded has its own set of internal activities such as SAP query and SMTP approval flow

which are explained in detail above.

Exhibit 13: Acme Company – Order to Cash Process

xCP Forms Design – The front-end design takes the most time in most projects. It needs to

be intuitive and conform to accessibility and corporate branding requirements. It also needs to

capture all user inputs and present all user information in a clear role-specific context. The idea

is always to present the user with a set of data or action points to choose from as this minimizes

human error. This requires integration with external data sources and needs to perform complex

logic to present a relevant list of values. All this can be achieved with Documentum Forms

Builder. It brings development work down to next to nothing and focuses more on configuration.

This helps customers change user actions and other items on the fly. An active preview helps

developers visualize how the form will look and feel in a client application.


Exhibit 14: Forms Designer View – Order to Cash Process

Exhibit 15: Forms Application View (Active Preview) – Order to Cash Process

xCP TaskSpace Configuration – The primary client tool for the xCP stack of products is

TaskSpace. It serves not only as a client tool but also doubles as a powerful configuration and

administration utility thus empowering business users to configure the way a client tool needs to

look for different roles. This comes with integration to various document viewers such as Daeja

ViewONE Pro, Informative Graphics Brava, and others. With viewer there is no longer need for

native applications such as MS Office or CAD to be installed to view these files or add

comments or markups.


Exhibit 16: Acme Company – TaskSpace Designer View

Exhibit 17: Acme Company – TaskSpace Business User View

Exhibit 18: Acme Company – TaskSpace Business User View with Daeja Viewer


xCP Business Activity Monitor Configuration – Business Activity Monitor is a real-time

analytics engine which aggregates millions of data sets to bring out useful dashboards, charts,

and other reports to monitor and/or review ongoing or completed processes. Again, core

functionality is built in and customers just need to configure it for usage which gives a good

head start over other process analytics tools. A sample sales order report by state is given

below.

Exhibit 19: Acme Company – Business Activity Monitor – Sales Order Report

Case Management, Intelligence and Beyond – xCP differs from everything that we have

seen from EMC in the Documentum Platform. What make it a leader among other products is

sticking to its core commitment of configuration- and model-driven approach rather than

traditional customization. This enables customers to realize return on investment in a much

shorter time and also provides for significant cost savings due to reduced time to rollout

complex solutions. xCP has broken traditional belief of what is case management and bring a

new sense and meaning to content-enabled process automation. xCP provides for limitless

opportunities to think, innovate, and adopt an intelligent way to conduct your business. Think Smart, Think xCP!


Reference All the items described here belong to the Documentum xCP family of products. One can find

more descriptive information about these products, their capabilities, and relevant case studies

in the following links: 1. http://www.emc.com/products/family/documentum-xcp-family.htm

2. https://community.emc.com/docs/DOC-4209

3. https://powerlink.emc.com

EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without notice. THE INFORMATION IN THIS PUBLICATION IS PROVIDED “AS IS.” EMC CORPORATION MAKES NO RESPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Use, copying, and distribution of any EMC software described in this publication requires an applicable software license.

xCP - Dell EMC Education Services

Documents

Transcript of xCP - Dell EMC Education Services