Evaluating Customer MDM Options

Many enterprises are faced with the challenge to implement a robust customer MDM solution. One of my clients had a very similar challenge and in this post I have explained in detail the approach we took to evaluate two different customer MDM options and the recommendation we made at the end of the evaluation.

The client in question had Siebel CRM as the front end Prospect and Customer Account creation system. The client had implemented Oracle R12.1.3 Ebusiness suite for their Order to Cash solution.

Customer MDM Option 1:

• Siebel will be the single point of entry for Customers and Address records
• Siebel will integrate with Trillium and D&B
• Oracle EBS will be the source of truth for Customer Records (GOLDEN RECORD)
• Other Enterprise Systems will subscribe to EBS for Customer Data
  
  

Customer MDM Option 2:

• Oracle EBS will integrate with Trillium and D&B
• Oracle EBS will be the source of truth for Customer Records (GOLDEN RECORD)
• Other Systems will subscribe to Oracle EBS for Customer Data
• In future Source systems can be added/removed without a significant change to the process

 

 

Comparision between Option 1 and Option 2:

Recommending Option 1 for the client:

• Recommended approach
• EBS is the master and system of record for Party and Customer Accounts
• Siebel would be the system of record to initiate it with data cleansing and validation
• Leverage client's current knowledge base and use of Trillium, D&B, SDR
• Use Trillium Realtime connector for data cleansing and enrichment
• Define D&B call details for enrichment
• Data Stewarts would exist both within Siebel Apps and EBS for addressing data relating to:
• Customer and Party attributes, including relationships
• EBS specific attributes for customer accounts etc (for example ACH, Credit card No, etc)

Project to Cash Enterprise - need for Order Management

One of my clients was implementing Oracle Ebusiness Suite 12.1.3 and was in construction business. The proposed foot print was to implement the Project to Cash suite of applications. But they were confused whether to implement Oracle Order Management or not.

For Project to Cash enterprises the key design decisions which need to be considered are presented below:

EBS Order Management key features and benefits for Project to Cash enterprises:

• Order references one or more lines, and each line is for a specific Inventory Item. Ship To can be defined at the line level
• Each order line is associated with Pricing through Price List
• Out of the box integration with AR for billing and revenue
• Integrates with Revenue Management functions in AR for deferred revenue and earned revenue accounting based on revenue contingencies and events (for example revenue to be earned only when customer pays in full)
• Native integration with Inventory for shipping and Cost of Goods Sold
• Full integration with Bill of Material and Configurator whereby by selecting a Model (product group for example), system will configure its components and explode each item into the Order Line
• Integration with WIP Manufacturing application to create Work Order for the SO Line and capture Material & Labor costs to the Work Order (based on Bill of Material)
• Native integration with Project Manufacturing for cost collection from Manufacturing (Labor and Material) into Project costing
• Integration with Service Contracts, Installed Base for selling services
• Connects with Credit Management for credit profiling, credit limits, etc

EBS Order Management key constraints for Project to Cash enterprises:

• Doesn’t have the capability to do milestone/progressive billing
• Application assumes that the billing has to be for the full amount of the line value upon shipment. Hence cannot model install job billing requirements.
• Significant work done so far for developing POC revenue cannot be ported to revenue management model and need to be developed from scratch
• Cannot leverage POC revenue work done so far for building completed contracts based revenue in revenue management model
• Forces the use of Bill of Material (BOM) and Work in Process (WIP) applications for being able to associate Labor and Material costs to the Work Order and booking the Cost of Goods Sold upon shipment. Overkill and complex for Project to Cash Enterprise business needs
• Doesn’t integrate with Project Costing and billing
• Projects integration requires implementing Project Manufacturing. Project Manufacturing needs to be turned on and configured for associating the project and task with OM Line for Manufacturing cost collection.
  
  

Credit Card Payment Processing in AR

Many clients will have the requirement to process customer credit card payments in a seamless fashion within Oracle AR. The Oracle Payments (previously iPayments in Rel 11) module enables this functionality working with Oracle AR using a 3 step process:

• Create Invoices: Create invoices in AR with payment method= ‘credit card’
• Credit Card Authorization: Create and approve receipt which includes getting approval codes through Oracle payments and Payment gateway/Payment Processor. Tyco is currently using Chase Paymenttech as a payment processor which Oracle has certified for R12 (Metalink Doc. ID: 471385.1) so we may want to use the same in the future.
• Credit Card Fund Capture: Generating remittances and capture fund through Oracle payments and Payment gateway/Payment Processor. 

What is PSON?

• PSON stands for Payment Server Order Number and this is used by Payments during the funds capture settlement process. This field is located at receipt workbench and is populated by Oracle Payments after authorizing fund.
• Process for ACH processing:
• Oracle Payment, through Funds capture, supports ACH payment and can be integrated with any Payment system for Electronic fund transfer. For Tyco, Payment system can be their remittance banks. 
• Process for ACH processing is same as credit card processing (Create Invoices, Authorization and Fund Capture/ Settlement) with following differences: 
• Authorization step is optional for ACH
• ACH does not block funds during authorization
• Bank information is validated only once and then it is stored as a profile in Oracle payments whereas credit card payment needs approval (PSON) for every transaction.

   

CAS compliance for Federal Business

Cost Accounting Standards (CAS):

Cost Accounting Standards (popularly known as CAS) are a set of 19 standards and rules promulgated by the United States Government for use in determining costs on negotiated procurements. CAS differs from the Federal Acquisition Regulation (FAR) in that FAR applies to substantially all contractors, whereas CAS applies primarily to the larger ones.



When CAS will be applicable to your enterprise:

• Your enterprise performs work for federal government customers
• Your enterprise may be subject to 'full' CAS coverage (required to follow all 19 standards) when you receive either one CAS-covered contract of US$50 million or more, or a number of smaller CAS-covered contracts totaling US$50 million
• Your enterprise may be subject to 'modified' CAS coverage (required to follow only Standards 401, 402, 405, and 406) when you receive a single CAS-covered contract of US$7.5 million or more
• Your enterprise may be exempt from CAS standards provided:
• Contracts awarded to small businesses are exempt from CAS, regardless of contract size
• Any contract less than US$7.5 million is exempt, provided the company has not been awarded a contract greater than US$7.5 million, and also any contract less than US$700,000 is always exempt
• Contracts for commercial items
• Contracts awarded under sealed bid procedures, or where "adequate price competition" was available (the latter meaning where at least two companies had the ability to bid and perform on a contract, even if only one bid was later received)
• Contracts where the price is set by law or regulation
• Contracts awarded to foreign governments
• Contracts awarded to foreign concerns (only the disclosure statement and CAS 401 and 402 apply in this case)

In general these cost accounting standards and compliance is synchronous with US GAAP for accrual accounting.

Oracle Projects Suite of applications

What is Oracle Projects Suite of Applications?

• Project Foundation (PJF) - Common setups for Projects Suite like templates, project types, expenditure categories, expenditure types etc
• Project Costing (PJC) - Costing related functions for projects
• Project Billing (PJB) - Billing (both Revenue and Invoicing). Billing module license includes access to Costing module features
• Project Resource Management (PJR) - Labor resource management features. Project team role requirements are staffed through this application
• Project Collaboration (PJL) - Project team member collaboration
• Project Management (PJT) - Functionalities relating to workplan management, enhanced budgeting and forecasting, change control & project performance reporting. Seamless integration with all of the above modules.

Projects suite features comparison chart:

BIG DECISION - do you want to turn on Item Serialization?

One of my clients whose primary footprint on the supply chain is Oracle EBS was at the crossroads of making a big decision - whether to turn on item serialization or not. This decision has lots of benefits but also comes with a lot of additional responsibilities to enter and track serial numbers. Here is the journey on how we evaluated the item serialization big decision for the client:



What is Serialization?

Oracle Inventory provides complete serial number support for inventory transactions. You can enable serial number control for specific items in your inventory. For items under serial number control, you assign unique serial numbers to individual units and

thereafter reference the same serial numbers each time you perform material transactions. This allows you to have tight control over every unit of every item in your inventory.



Serialization in Inventory & Installed Base tracking design:

Key considerations for the Client:

• Client does not create its own Serial No upon installing the Products and hence Serialization is applicable only to the Inventory ordered for the Project
• Serialization can be selectively turned on at specific item (A Type?) level

Key questions and design considerations presented to Client leadership team:

• Can we use serialization features at selective A type items such as Cameras?
• Can this be enabled using Item category/Catalogue definitions
• Can we model the Product sold (eg product1 product2 etc) as MTL Items (non tangible, but Item Master record with IB tracking enabled)?
• Can we define/track Client Serial No at that level?
• Is that scalable to future design of serialization turned on at lower levels?
• How does this get IB tracking benefits and for maintenance/upselling?

Based on the above framework and many deep dive sessions later, the client decided to turn on serialization only to key 'A' level high value items to begin with. This enabled them to adapt slowly to best industry practices and also have a scalable design to turn on serialization for 'B' and 'C' level items in the future.

Is Oracle Project Contracts a fit for your organization?

To understand if Project Contracts is the right fit for your organization, let us understand in detail its integration to other Oracle EBS modules:

Oracle EBS Integration:

• Provides several mechanisms to ensure timely delivery and receipt of products, services, and other contractual obligations.
• The Deliverable Tracking System (DTS) is the center of Contract Execution and is used to track all activities related to a contract.
• Deliverables can be inbound and outbound oriented, and can be internal or external.
• Examples of deliverables that can be tracked include planned receipt and shipment of items, mailing of an initial engineering drawing, or monthly submission of progress reports.
• The Deliverable Tracking System is integrated with other major components of the Oracle e-Business Suite, including Oracle Projects, Oracle Project Manufacturing, Advanced Planning and Scheduling, Oracle Internet Procurement, and Oracle Shipping Execution.
• This integration allows you to collect cost against a contract through projects and tasks, feed contractual demand into the planning system, create procurement documents such as purchase requisitions and purchase orders for direct-procured contract material and other items that are not sourced through planning, create shipment requests for shippable deliverables and track shipping and delivery statuses, generate billing events, and recognize revenue.
• All the manufacturing transactions take place at the project or project-task level depending on how the organization parameters are set, and if the project/project-task information is on the deliverable.
• Contract related information from the other products can also be viewed and tracked within the DTS with additional drill down capability.

Fitment and Suitability of Oracle Project Contracts for your organization:

• Project Contracts was designed and built primarily for Aerospace and Defence Industry. Enhancing its features or Web enabling it is on the current roadmap of Oracle Development
• Its powerful features is Contract creation, authoring and maintenance and handling Deliverables associated to the contract Lines (DTS)
• Funding association is at the Contract Line level and hence one contract can fund multiple related projects
• Billing integration is manual and the Application doesn’t call the Billing extension (for both Revenue and Billing)
• Sub Project associations can be modeled through the creation of a Master Project to represent the Contract and the associated projects created as Sub Projects
• Procurement integration is seamless based on Deliverables
• As an organization, you have to determine if you have any other similar modules / systems which provides project contract capabilities
• If not, then because of its powerful features and functionalities and its seamless integration with other EBS modules, you might want to consider implementing Oracle Project Contracts