Each month I endeavor to present a new topic. In general, I have a couple of topics in draft at any point in time, call it my virtual notepad. When an interesting topic (or what I think could be interesting topic) comes to mind, I log in and start a draft. This month’s topic has been in draft form for a few months.
Today I am going to expand on a concept that I highlighted in my very first post – the ability to load to multiple EPM applications from a single FDM application. I was recently at a client teaching them FDM (insert shameless plug here) and this capability came up. They asked me what was the benefit of using 1 FDM application to manage data loading to both a Planning and HFM application as opposed to multiple FDM applications. The next day, I was delivering a presentation at a local Hyperion User Group meeting and a person in the audience asked me the exact same question. I smiled, looked at the client who had asked me the same question just a day before to see if he was laughing yet, and answered the question. Based on these back to back experiences, I decided it was time to dust off the draft and get this month’s topic published.
Before we get started, let me share a little story. I recently discovered The Traveling Consultant. This blog is frankly hilarious. Sadly, this story is not as funny but I still think it’s a funny aside and let’s be honest, EPM is not the sexiest reading out there. A fun story every now and then makes this blog a lot more interesting. Several years ago, I had a new client. They had previously worked with another consulting firm. Their FDM needs were not being met so they engaged the firm where I am employed. My first day onsite, I sit down to review their current environment and immediately notice that they have 12 FDM applications. That’s not a typo, I didn’t mean to type 1 or 2, I mean 12 as in the number twelve, a dozen, XII.
Being a bit less seasoned than I am today, I blurted out, “why do you have a plethora of FDM applications?” One of my colleagues was there to witness this. He maintained his composure but at dinner that night he nearly split his sides laughing at my choice of words. His comment was something along the lines of, “you use the most elegant language, most of us would have said something like why do you have so many apps but you break out the SAT words like plethora.” To which I responded, “dude, having that many apps is just stupid” and then we both burst into laughter. The reason I share that story is not to paint myself as lofty or arrogant (because let’s be honest, plethora is not all that impressive of a vocabulary word) but instead lay the groundwork for the discussion of why a single FDM application is often a better practice.
Before we delve too deep into the discussion, let’s talk about how technically FDM can even manage integration into multiple target systems like HFM and Planning from a single application. The answer is actually quite simple. The target system adaptor controls how FDM integrates with an application like HFM. You can have an Essbase and HFM target system adaptor within the same FDM application. In fact, you can have multiple HFM and/or Essbase adaptors within a single FDM application.
Let’s assume you have an HFM application and a Planning application. Within your Planning application, you have 3 cubes: 1 for Revenue, 1 for Operating Expense and 1 for the consolidated Income Statement. You need to load actual data to HFM as well as the Revenue and Opex cubes. You configure 3 target system adaptors within the FDM application.
First you import the HFM and Essbase adaptor. The next question I inevitably hear is, FDM won’t let me import a second copy of the Essbase adaptor so how do I have 2 Essbase adaptors? You are correct. You can only have 1 copy of each adaptor name; for example, ES11xG4-J. However, you can create a copy of the adaptor within the Workbench. Simply right-click the adaptor and select Copy.
Great, now you have 2 copies of the Essbase adaptor – each with their respective integration settings. The next step is to assign the appropriate adaptor to the location that will be used to load data to the target application as defined by the integration settings of the adaptor.
The last component of this functionality that often draws questions is the control tables. The control tables build the relationship between the FDM period & category and the target application period, year & scenario, respectively. The control tables are specific to each adaptor. The system/global adaptor is where the application periods are defined. For example: 1/31/2013, 2/28/2013. The alternate adaptors then inherit these period keys and the relationship to the target system (for that adaptor) is specified. Notice the prior period date key and descriptions fields do not display on the alternate adaptor control tables. This is by design as these are controlled by the global adaptor.
OK, so now you understand a bit about how to set this up. So back to the question posed, why is 1 FDM application preferable to multiple applications?
End User Experience
First and foremost, I strive to provide the end-user an optimal experience. Let’s assume that there are business units that have responsibility for loading their actual data to both HFM as well as Hyperion Planning. With 1 application, the user logs in to the FDM application, selects the HFM location and loads data. They then change their point of view to the Essbase location and process the data. With more than 1 application, the user logs in, performs the workflow, logs out, logs into another application, performs the workflow and logs out. That cycle repeats for the number of different target applications that need to be loaded. Anyone else frustrated with the login times on v11 of FDM?
Now let’s take it one step further. Using 1 application, I can develop automation that requires the end-user to load just to HFM. The load to Essbase can be triggered automatically without requiring the end-user to manually perform the workflow. Sure I could accomplish a similar level of automation with multiple applications but a single application is going to be more efficient and less prone to error.
Providing an optimal end-user experience is extremely important to me. However, I am also very cognizant of idea that finance and IT organizations run very lean. A single application means that the administrator does not need to manage application access across multiple applications for a single user. He/she provisions users to the application in Shared Services and then uses location security in FDM to assign access to the proper locations. Don’t underestimate the task of provisioning users, especially in organizations with hundreds of users.
Second and equally important are the scripting assets that can exist in an FDM application. For applications with significant scripting, this is a key consideration. The business use of an application changes over time and no matter how well written a script (or how poorly), the script will likely need modification at some point. A single application means a single point of maintenance for these assets whereas multiple applications obviously means duplicate (or triplicate or whatever the word is for 12 times) maintenance. Moreover, if a scripting change does not get propagated to one of the secondary applications, you risk a break down in the process and/or compromised data quality.
Next we need to consider the application backups. Having a single database & file system to backup means less work for our friends in the data center. Many of us never get full visibility into the demands on these teams. While it seems like it should be easy to add another database/schema to the nightly or weekly backup procedures, it may result in a significant amount of work or even expense. Moreover, if we don’t manage this properly, you could end up with applications that are not being backed up because the team was unaware of the new application. I don’t think I need to get on my soapbox and preach about the risk of an application that is not included in the backup procedures.
Finally, application upgrades are another consideration. As you consider upgrading to the latest EPM version, multiple applications means multiple iterations of the upgrade procedures, application updates (post upgrade) & testing cycles that accompany a well planned upgrade. Yes, you still need to go through each of those steps during an upgrade but limiting the number of iterations can shorten the upgrade timeline and thereby expense.
I hope I’ve given you some food for thought. Now I’ve said it before and I’ll say it again, there is no 1 right answer. This discussion addressed the majority of applications. There will always be exceptions. Your EPM environment & application architecture should be a collaborative effort between you and your consulting partner. I hope the above provides you some additional information that will enable a more productive dialogue and understanding of the capabilities of FDM when you engage with your partner.