From my latest post (Post 2), we talked about starting the process to identify your needs, the importance of a partner and the value of planning ahead. We will continue down that path in this post. I’m trying not to spend too much time on gathering project requirements in these posts; however, they are a building block for selecting the right product and I will give them the time they deserve here.
Whether you are planning ahead or have an emergency need, first you have to understand what you currently have. I am a huge fan of integration schema’s and data flow diagrams. These help you get the “big picture” of what your data inputs are, the existing processes and current outputs. Outputs can include any data that is used by end users, including reports and queries. If you don’t have a schema or data flow now, you should make one. It is hard to get where you want to go if you don’t know where you are coming from. Many times when creating one of these schemas, you will be surprised that there are additional inputs that are not documented (many times via cumbersome processes), exceptions to the processing performed and unknown users of your end data. Existing applications have a tendency to evolve over the years and putting it on paper is a way to capture what you really have and subsequently, need to replace or update.
Guide to Oracle Cloud: 5 Steps to Ensure a Successful Move to the Cloud
Explore key considerations, integrating the cloud with legacy applications and challenges of current cloud implementations.
I was in a design session once where we were reviewing data inputs for HFM. The most common input being Trial Balances that were being loaded via FDM. We asked if there were any other inputs and were told “No”. Pressing further, we asked about manually entered Trial Balances, adjustments, statistical data, supplemental data or operations data. The response was “Oh, now that you mention it, yes we do some of that”. We went person by person and about half of the people knew of some “little bit of information” that was an input to HFM.
When you are gaining an understanding of what you have, you will need to talk to a lot of people – inputters, processors, end users, analysts, administrators, report writers, etc. These are the people that know what is going in, work that is being done and what data is coming out. These are also the same people who should be driving your requirements. Be inclusive and keep the lines of communication open with these stakeholders. Getting everyone on the same “requirements page” ensures all are aware of your goals and how they will be achieved. In my HFM input example above, we had to expand our “user group” included in the discussions to ensure we had all the input details for HFM.
Document and Prioritize. Once you have identified what is required, document it! Putting the requirements on paper ensures everyone can literally see what is needed. This will drive the scope of your project and what Hyperion applications you will need. Also, you should have your stakeholders approve the requirements. This ensures there are no miscommunications. List the requirement, who wants it and the real priority of the item. I say “real” priority, because for some people, everything is a Critical priority. Also, make sure you understand why it is a priority. Just because “that is the way we have always done it” does not cut it! A reporting requirement from five years ago may not exist now.
OK. Now we have a list of what we want. Consider your timeline – are certain priorities needed sooner? Can some wait? The immediate needs should be driving the timeline; however, don’t ignore the other needs that will come later. Put them on your timeline too, even if it is a year or more later. This serves several purposes including ensuring you are looking at your application ecosystem holistically and it helps you manage expectations for your stakeholders.
In the next post we will begin looking at the available products. Fair warning here and now – I’m not going to go into excruciating details about each product. There are volumes that I could write if that were the case. I’ll cover major functionality, available tools and what you should consider. Also, no Cloud vs. On Premise debate in these posts. That deserves its own discussion and I won’t be tackling that one here. Instead, we will focus on major functionality that you should be looking at to meet your needs.
