Infosys’ blog on industry solutions, trends, business process transformation and global implementation in Oracle.

« December 2014 | Main | February 2015 »

January 28, 2015

Oracle Customer Experience Applications- The SI dilemma - What should one recommend?

Since Oracle Open World 2014, Oracle has been focusing on its Customer experience suite of applications which span across all customer touchpoints and cover all the pillars of CRM.

Oracle is proposing an integrated Customer experience(CX) on the cloud where all these modules are loosely coupled to allow flow of important information across the various applications. So clients would have an option to deploy specific modules to tackle certain business problems or use an integrated suite.  These applications are hosted on Oracle's extensible cloud platform and are available in the Application-as-a-Service mode.

Blog pic1.png

Oracle also has a comprehensive CRM suite in the form of Siebel CRM, which is a part of its Customer Experience applications portfolio. The modules and capabilities of Siebel have a lot of overlap with the Oracle Cloud apps. So as a CRM consultant, I am faced with a dilemma as to which solution should one recommend for a customer.

 SPS Blog pic2.png

There are various parameters that one needs to consider while recommending an Oracle cloud based solution in the context where the client already has an on-premise CRM implementation. For this blog, I will use the example of an on-premise Siebel CRM implementation. Some of the important parameters are listed below:

Decision 1: Cloud vs On-premise vs Hybrid
First of all, we will need to identify if the client is open to cloud based solutions. There is a comprehensive list of parameters that help determine the cloud vs on-premise fitment. At a high level if the client does not have to adhere with strict regulatory requirements, has processes that can be supported with OOTB/configured capabilities and is keen on an Opex based service model, the cloud based modules are a good fit. Eg: If the client is using Siebel sales and wants to enable Enterprise Marketing, Oracle Marketing cloud can be considered as an option given its superior digital marketing capabilities.


Decision 2: New cloud modules vs extend existing on-premise implementation
For areas where the existing on-premise CRM can be configured to deliver the requisite capabilities, we would need to determine if there is merit in recommending a brand new cloud module. Eg: If the client is already using Siebel for sales capabilities, and needs to enable the quotation and ordering process,  it would be more appropriate to recommend leveraging Siebel quote management as it would be a seamless extension of the sales process, rather than bring in the Oracle CPQ cloud into picture.


Decision 3: Availability of industry specific capabilities
Most of the Oracle cloud applications are still horizontal and do not have in-depth industry flavor. Eg: Solution for the Communications industry needs asset based ordering, product catalog, complex pricing rules, order configuration and billing management functions to be supported. This capability and tight integrations for Order to Cash and Billing processes do not currently exist in the Oracle cloud applications. Therefore, Siebel as a part of the Oracle RODOD stack continues to remain the more comprehensive solution for CSP's till equivalent capabilities are made available in the cloud suite.  


There is certainly no one-size-fits-all recommendation as far as the Oracle CX cloud applications are concerned. However, by analyzing the fitment of the product capabilities and client landscape, it is possible to recommend the right solution for the customer.

 

 

 

 

January 23, 2015

FDMEE : Patch 510(11.1.2.3.510)

In previous part we discussed the different integration tool and their comparison with FDMEE. In this blog we will discuss the functionalities that were added as part of PSU510 for FDMEE. Also, we will discuss the bugs that have been fixed and the functionalities that are still missing.

Below are the defects that have been fixed.

 

FDMEE_Blog3_Pic1.pngNow we can discuss the functionalities that have been added since FDMEE evolved from version 11.1.2.3.500. Below is the list.

1.      Custom Scripts

2.      Multiload data loads are now possible

3.      Tab delimiter for flat file based import format

4.      Object for Period Name added to aid the scripting

5.      Filter for list of periods in POV in workbench

Let us go through each of the addition briefly.

Custom Scripts :

Custom scripts are now available through Script Editor in FDMEE. Custom scripts allows to run various FDMEE tasks including running batches and data load rules. These scipts are supported both in Jython and Visual Basic.

P.S. These scripts can not be migrated using LCM.

Multi Load :

It's a mojor functionality that has been added in this patch. This has been completely changed if compared to classic FDM. It allows the loading of multiple months for a year in a single execution for flat file source systems. It is availble while defining Import format and there is no separate module for Multi Load.

 

FDMEE_Blog3_Pic2.pngTab Delimiter:

Now tab is available as a delimiter in the Import format for the flat file based loads. It was a very generic requirement to have a tab as delimiter because most of the files generated from the standard source systems are tab delimited.

 

FDMEE_Blog3_Pic3.pngPeriod Name Object:

This property was created to refer directly in scripts to provide a flexibility to write custom codes. This property can be used with fdmContext object by referencing it as fdmContext["PERIODNAME"]. To execute any script for a specific period this property can be used.

Features still missing:

1.      POV Locking

2.      Controls Review

3.      Missing Timestamp in process monitor reports

4.      Missing Classic analysis reports

We will discuss in detail few imprtant FDMEE functionalities which adds a new dimension to its functionalities in our upcoming posts. Stay tuned. 

 

January 14, 2015

Hyperion Data Integration Tools - A Comparison

Hyperion Data Integration Tools - A Comparison

Data integration is an integral part of any Hyperion implementation. All the Hyperion EPM applications, be it Planning, Financial Management or Reporting, rely on that one integration tool which will gather data from a company's various transactional systems and transform or convert it into a form which can be loaded to the EPM applications.

Oracle provide some very useful Hyperion integration tools like:

1.       Oracle Data Integrator (ODI)

2.       Enterprise Resource Planning Integrator (ERPi)

3.       Financial Data Management (FDM)

4.       Essbase Studio

5.       Data Synchronization

6.       Data Integration Management (DIM)

7.       Hyperion Application Link (HAL)

Out of these, DIM is an old tool and is no longer used - it has been replaced by ODI. It was mainly used to load data from external sources into Essbase.

Similarly, HAL too was an old world integration tool now replaced by FDM and ODI.

FDM and EPRi have been combined and released as a new integrated tool called FDMEE (FDM Enterprise Edition) which beautifully combines the best of both worlds and is a new improved and more powerful blend of both.

Essbase Studio was required to be used as an Integration tools since FDM, up to version 11.1.2.2, did not support data load to Planning applications if the planning applications were hosted on a clustered environment. However, this bug is fixed with the release of FDMEE and Planning integrations became seamless thus eliminating the need to use Essbase Studio.

Data Synchronization was used to load data between Hyperion EPM applications e.g. when budget/forecast data was required to load between Planning and Financial Management applications. However the latest release of FDMEE 11.1.2.4 will be integrating Data Synchronization inside FDMEE itself thus eliminating the need to use a different tool for inter-application data loads.

So we can narrow down our search for Integration tools and ultimately decide between ODI and FDMEE depending upon the business requirements and the respective pros and cons of each tool.

 

Oracle Data Integrator (ODI):

Pros:

1.       Based on EL-T architecture.

2.       Capable of transforming large volume of data efficiently.

3.       Supports a number of different types of source and target systems which can be easily configured to extract data.

4.       Useful for loading metadata to the Hyperion applications.

5.       Ideal tool for one-time data loads to applications e.g. if historical data needs to be loaded to the applications, it will be a one-time activity which can be scheduled to run in the background or will be done by the IT support team.

Cons:

1.       ODI processes will run in the background - either through scheduled jobs or manually - and business users will always need the support of the IT staff for maintenance or reconciliation of their data.

2.       Very technical tool and not at all user friendly.

3.       No audit trail support.

4.       License cost is high.

 

Financial Data Management Enterprise Edition (FDMEE):

Pros:

1.       Extremely user friendly - data can be loaded by the business users themselves instead of relying on the IT support team. Also transformation errors, if any, can be resolved immediately by the users and there is no delay in the data load process.

2.       Provides an extremely useful drill - back feature where users can see where the data came from and how it was calculated. Drill back is supported from Planning, Financial Management applications to FDMEE and from FDMEE to EBS General Ledgers.

3.       Provides users different out-of-the-box reports useful for auditing purposes.

4.       Security can be user specific and component specific - hence multiple users can load data to multiple systems without interfering with each other's loads.

5.       Supports write-back functionality as well where budget/forecast data from the Hyperion applications can be written back to the source EBS systems.

6.       Comparatively easier to create data load interfaces with FDMEE.

7.       Once configured, very minimal IT support needed.

8.       Ideal tool for monthly actual data loads and yearly budget or forecast data loads.

Cons:

1.       Since it is a web based tool, network speed directly impacts the performance.

2.       Performance is a bit slow for very large volume of data.

3.       If source data is required to be extracted from database tables, additional coding needs to be done which may need IT support.

 

Conclusion:

When it comes to an integration tool, the most important feature that business users look for is a good UI, ease of use and flexibility along with auditing capabilities which FDMEE provides very effectively.

Considering various business requirements and scenarios, I would say that ODI is the best tool for one-time Historical Data Migration done by IT support and FDMEE is the best for monthly actuals and yearly budget and forecast data loads done by the users themselves.

 

January 13, 2015

The new improved Multi-Load functionality in FDMEE

Part 3

The new improved Multi-Load functionality in FDMEE

FDMEE has introduced a hassle free great way to load multi-period files in the same way as single period files are loaded.

We no longer need to have an excel file with the location name, scenario, start period and number of periods in the file. All this and other features have been incorporated in the Import Format itself - there is a new file type introduced in the import format called "Multi-Period".

The multi-period format is very useful for loading budget and forecast data where data for the entire year or multiple years needs to be loaded.

Multi-Period Import Format:

To set up the multi-period import format, the following details are needed:

 Multiload1.png Select the File Type as Multi-Period and File Delimiter according to your source file.

In the mappings section of the Import Format, map the source files column numbers with the target application dimensions. 

Multiload2.pngThe dimension mapping is the same as the single period file.

The main difference here is the Amount column mapping. In the Expression column for Amount, open the Add Expression editor.

In the editor window that opens, select the following:

Expression Type: Column=start,end

Expression Value: column number of the first amount in the source file, column number of the last amount in the source file.

E.g. If the source file has budget values from Jan to Dec and the amount for Jan starts from column 7, the Dec amount would be at 18. Specifying 7,18 in the Expression Value will pick the amounts starting from column 7 and load them in the correct month for the next 12 subsequent amounts up to Dec.

Multiload3.pngThe remaining setup of location and data load mappings remains the same.

Executing a multi-period location:

A location with multi-period import format is not executed from the Data Load Workbench. It is only executed through the Data Load Rule.

To execute a multi-period data load rule, go to Data Load Rule, click on Execute and enter the details as shown below:

 Multiload4.pngSelect the start and end periods according to the data that is required to be loaded and click Run. Data will be imported, validated and exported for all the periods between the start and end period range.

Some more features:

  1. It is not required to have all 12 amount values for all the records in the source file. If there are no amounts for some months in between the start and end period range, the source file can have "#Missing" as well. Those months will not be loaded.
  2. Data need not always be loaded from Jan to Dec even if the source file has 12 months data and even if we have specified 12 amounts in the Import Format. We can specify the Start Period as, say, "Mar" and End Period as "Oct". The corresponding amounts from the file will be picked up and loaded at the correct periods.
  3. This is a very useful feature for the budget and forecast data loads between Hyperion applications. This can be implemented end to end in the following manner:

a. Call a batch in the BefImport event of FDMEE which will extract data from the source Hyperion application.

b. Fix up a folder on the FDMEE server where the file will always be placed after extracting the data.

c. Save the file name and path permanently in the data load rule

When the load rule is executed, the BefImport event will be triggered which will call the batch to extract data from the source application and the file will be created in the fixed folder. Since the filename is already saved in the load rule, it will be imported into FDMEE and data will be loaded to the target application according to the start and end period selected.

This simplified and more flexible way of processing multi period data is a very useful feature of FDMEE.

 

 

Subscribe to this blog's feed

Follow us on

Blogger Profiles

Infosys on Twitter