Maintain Custom Account Structure Requirements in Planning via Oracle DRM Sourcing: The Oracle Data Relationship Management (DRM) product has always offered impressive flexibility when it comes to meeting the metadata requirements of subscribing target systems. This flexibility extends across numerous products and systems and is not limited to just the EPM stack. This core strength goes back to the origins of the product and has been key to its evolution from its inception with Razza, on to Hyperion MDM, and now within Oracle DRM.
Anyone who has used FDMEE to automate loads via OpenBatch has come across the problem of the “openbatch” directory filling up with archive directories. FDMEE creates an archive directory each time a Batch Execution is run, whether or not any files are processed. This not only clogs up the directory, but also makes it very difficult to find previously loaded files due to FDMEE’s naming convention for archived files.
Let's discuss intra-application modular database metadata hierarchy alignment. What does that mean? When a company develops an out-of-the-box Oracle Hyperion EPBCS application such as Project, Workforce, and Capital Planning there are pre-defined dimensional members and hierarchies that probably do not align with the chart of accounts or other metadata structures specific to that organization. For example, in EPBCS Project the pre-defined account structure has separation of account types such as Revenue, Expense and then more detailed COA categories.
The focus of this blog (#4 in the series) is how to leverage the investment your company has made in establishing a Cloud EPM Vision and Executing successfully on the project. It is in this final phase of the Cloud EPM project implementation that we define our 'success'. Is this project a one-time triumphant event or will we create a Legacy of ongoing improvements and optimal return on our investments?
In my previous blog post, I talked about the critical importance of the executive sponsor when implementing a Cloud EPM project. Over the next few posts, I’ll expand the focus of this discussion to cover best practices to leverage throughout not only the lifecycle of a Cloud EPM Implementation, but also the environmental factors that are important before, during and after the project. Implementing new technology can be full of pitfalls, both technical and organizational. This can especially be true for Oracle Cloud EPM projects. Oracle Cloud EPM projects will require the functional departments to give up some control to the IT group and perhaps need to integrate their processes with other departments. In the twenty-five plus years and dozens of implementations that I have been involved with I have identified many crucial success factors. Additionally, my colleagues at CheckPoint have collectively delivered well over a thousand projects. I will describe best practices for engaging all areas within a company to deliver a successful Oracle Cloud EPM project.
Today’s global business environment is more challenging than ever. Trends such as the accelerated pace of change, disruptive innovations across multiple fields and emerging competitors require leaders to respond in strategic and original manner. In IT, doing business as usual will not provide the required nimbleness to face these challenges. Cloud technology such as Oracle’s EPM has significantly altered the entire IT landscape. With the vital role of IT, cloud computing is fundamentally changing the way that companies operate. Executive level sponsorship is considered to be the most intricate and vital role in disrupting IT-norms within the enterprise. As companies contemplate cloud strategies aligned with delivering growth and performance objectives, executive sponsors have countless concerns to carry out before, during and after cloud projects.
Regular readers of my blog posts will know that I like to spend a fair amount of space talking about the ‘how’s’ of owning and managing an EPM system. In all honesty, anyone can purchase a software solution, and many companies do, but the real test comes during implementation and support. Over my many years of consulting I’ve noticed that clients who enter the implementation stage with a support and maintenance plan already in mind tend to be more successful. The same success also follows clients who start a project with some sort of future product lifecycle in mind. But what happens when your company hasn’t had the luxury of time to be proactive, or if you have inherited a system that is out of date through an acquisition, or being used for cross-purposes? Now is the time to have an open conversation around these intricacies. The following article, and a Q&A panel I am hosting next week hope to answer some of those questions. So here are some opening thoughts to get the dialogue rolling: