You are currently browsing the tag archive for the 'EPM' tag.
Business Intelligence Technology Environment or BITE is my own little tag line and acronym (maybe I should copyright it) to express the host of solutions available in the Business Intelligence application world today. (It could also be used as a verb to describe the plethora of poorly designed solutions… ahh but that is another story.)
My current blog series will be Oracle EPM/BI+ solution centric while remaining Oracle EPM/BI+ application agnostic (now dictionary.com is paying off). I hope that you will enjoy this real life approach to the process of decision making on software solutions interspersed with some genuine tips and tricks of the trade — some that you have seen before and some you have never imagined.
In other words, I hope that you will not find this blog to be represented by my newly coined acronym — BITE.
Rules of conduct while at the Buffet
First we need a definition. Yes a definition! Don’t be afraid, definitions are a good thing, they keep us grounded, they set limits and finally they determine if we are true to our mission. I define BITE as processes, software and goals needed to precisely solution the business data critical to the legal, accounting and business decision needs of a specific entity.
Inventive techno junkies, single tool consultants and one track sales people – CLOSE YOUR EYES / SHEILD YOUR COMPUTERS for this next statement else you might go blind. “Precisely Solution” in the definition of BITE includes the moral imperative of not misusing software for intent other than its design and picking software that fits the current business life cycle of a company. (Those of you with Software Misuse problems, I will be posting a number you can call to get help. Remember the first step is admitting you have a problem.)
The application stack for EPM / BI+; HFM, Essbase (with all its add-on modules), Smart View, OBIE, OBAW, FDM, DRM, ODI and a few products you might not have heard about or you’ve heard about but never assessed for your purposes. NO, NO, No, no folks this is not a software sales blog, it’s a solutions blog and in our solutions toolbox we need to do more than use a single hammer creatively to remain competitive from an efficiency and business life cycle standpoint.
The Personalities in the Buffet Line
Now that we have some parameters (and I know it was painful for you left brainers) by which we can solution, we need some realistic company situations to solution. Let’s start with four companies each different in their business life cycle, staff sizes and demands for a BITE at success. You can email me if you will absolutely die without a very specific company example however, I cannot boil the ocean here in this blog (small ponds are all that will be possible).
Our four companies need to be different to see solutions in the work. Let’s pick a manufacturer, a technology company, a retailer and a commodity group. In my next addition we will outline the companies, their mission, their needs and their resources.
Who among us has not heard about the “good old” days? My grandmother regularly peppered my Sunday dinner with stories, sometimes lectures, on how life was a little simpler way back when. However, if you apply some logic, it may be apparent that the premise might not hold water.
Technology is our revolution which has freed us from monotonous tasks, as well as provided new opportunities for insight and growth. Surprisingly, we need to learn how to free ourselves from our old ways.
So do you still have this on top of your television?
Take the “Betamax” player. Aside from taking the space of a small loveseat, it was pretty simple to use. Press the “on” button, insert the tape and press play. Soon consumers demanded a few more features and we were all graced with the latest and greatest invention of all time, the programmable VCR.
What more could I want in life? I now had the opportunity to record the debut of the “Thriller” music video while in detention room 101. However, we all know life is not that simple. I had to first learn to program the clock, channel and record time. Those benefits came with a small price to pay.
As a veteran Oracle / Hyperion Instructor, I could train our Oracle / Hyperion Enterprise clients how to press the “on” button, insert the tape and press play in about a week. Following the incredible success of Oracle / Hyperion Enterprise, Pillar and Essbase, clients wanted more features and functionality.
Oracle / Hyperion Solution’s met the challenges presented by their customers. With the acquisition of Hyperion by Oracle, the Oracle / Hyperion suite of Enterprise Performance Management (EPM) products merges a host of financial, reporting and analysis, and data integrations tools. These tools have refined how people work and interact with business information. It has also changed how we must provide training in order to prepare project teams, administrators and end users.
The System 9 and Fusion generation of products touch a much more diverse population of users. The products range from Executive Dashboards, to administrative budget collection forms and into the Information Technology (IT) back-office environment.
A one-size fits all training solution is no-longer as effective as it once was, like in the “old days” of desktop reporting. Now, we need to think about tailored training to meet the needs of each group of users and instruct them on how to most effectively incorporate the technology into their user-specific work day tasks.
The stepchild of training is managing change. Everyone is “fired-up” during the implementation phase. Each person striving to learn and understand all there is to know about the new system. But what happens when some people move on and others move in? Again, the scope of the latest products demands tailored training to meet the needs of the users, but also a plan to cover the entire cycle of ownership.
The challenge of providing training to an incredibly diverse user base, preparing users for multiple phases of projects, and how to live with and maximize their investment in technology has been exciting. Training solutions now weave together, printed materials, customized courses; web-based training seminars and re-usable recorded instruction. Training has become a separate and distinct project unto itself.
The products are not difficult to use, the challenge is ensuring people know how to thoroughly utilize all of the features and functions. Second, to make sure they understand how the technology fits into their daily tasks.
An Oracle / Hyperion competitor used to boast that one of their products was more user-friendly than HFM, and therefore required little training. That should throw a warning flag to the consumer. As the Oracle / Hyperion suite is an EPM set of applications, there must be an “enterprise” plan how to manage the needs of the users that the system will touch throughout the cycle of ownership.
A well-defined training plan must address educational needs across all phases of an implementation. It cannot be overemphasized that effective preparation can truly play a key role in keeping a project on schedule and budget. The results are that project leaders can more effectively communicate and understand design decisions. The members of the project team are able to test, validate and troubleshoot tasks more efficiently. Lastly, users understand the purpose of the project and how it fits into their daily tasks.
You will find that having a comprehensive training plan will be invaluable when you need to prepare new employees, manage employee movement, and preparing everyone for software upgrades and enhancements.
Master Data Management (MDM), as a concept, has drawn a great deal of interest from departments heavily invested in several Business Intelligence (BI) and Enterprise Performance Management (EPM) applications. MDM promises a utopian management center, a one-stop shop solution for master and metadata of quickly changing BI and EPM systems. Beyond the easier user interface to make numerous changes, MDM, as a purpose built tool, features the ability to create data governance workflows, auditing, and archiving processes. From an information technology (IT) perspective the final idea is that the MDM software will act as a central hub for all application administrators and designated business power users. The tool will seamlessly integrate into a current production process and feed the individual applications based on each systems native format to feed in changes or rebuild structures (think dimension load rules in Essbase).
There are obvious challenges that are expected to come up in an MDM initiative as the goals are often lofty, including agreeing on governance, production processes, user interaction, and workflow. This doesn’t even take into account the change management challenge of working with multiple departments that almost always have different goals and uses of the tool. Luckily, these items are generally a well understood reality as a part of the overall effort. However, the one item that is both thoroughly misunderstood is how the MDM software architecture integrates into an existing production and business process. Hint, the word “existing” is at the root of this misunderstanding.
The specific misconception I would like to tackle is the expectation that one piece of MDM software acts both as the user interface as well as handles all integration with existing systems. As well, it is perceived to still fit into the same production process from a business side that existed before the elimination of a lot of “boxes and arrows” in the existing process. I may be contradicting what many ‘sales’ types promise that a MDM product easily integrates into disparate systems and simplifies the architecture. One thing the ‘sales pitch’ does not clarify is that because of the advantages of the MDM product, a good MDM initiative also includes a re-engineering and tuning effort of the surrounding processes. Oops, they must have forgot that part.
In several recent experiences, the biggest hurdle in gaining operational buy-in during the MDM initiative was centered on the disillusionment that resulted from the recommendation to re-engineer existing integrations as well as adding new ones. One devil’s advocate reaction summarized the sentiment of this disillusionment perfectly: “So let me get this straight, we are going to simplify and consolidate our production process by adding additional steps?” Well in a single word response, “Yes!”
So how is this possible and why is it necessary? In order to clarify this struggle, the diagram below clearly demarks the MDM tool from the processes that typically happen externally of the tool. The diagram typically has three states:
- Current,
- Current with MDM; and
- The eventual MDM goal.
The specifics of the drawing changes from implementation to implementation but the basic result of the different states illustrates an initial increase in the amount of boxes and arrows, not less. There are two primary reasons why this is the case:
- The MDM initiative actualizes undocumented manual business logic and processes that are often not represented in current state architectures. After reviewing an often oversimplified current state architecture that a client provides me, my two favorite questions to begin probing for these undocumented secrets is to ask: “Ok, so is this really all there’s to it?” and “Is this always how the production process works? What happens when <fill in the blank> event fails?” The answers to these questions have to be key architectural considerations as they almost always are the leading indicators of why the current state struggles.
- The scope and charter of the initial MDM initiative is championed by only one or two target systems and therefore the initiative has to minimize changes to upstream systems and processes.
MDM Phase 1 implementations are often striving to “sow the seeds” of consolidation but end with creating and adjusting current processes resulting in more “pieces” to the architecture due to project charter and scope. Such an intermediate step is necessary in order to immediately show value, get organizational buy-in, and keep project length to “bites that can be chewed”. There is nothing wrong with this approach and this state is the reality for the vast majority of initial MDM initiatives. In fact, several phases for different source/target systems may initially all start out like this!
In future phases, however, the MDM tool becomes a true hub of existing systems and master data integrations are specialized on a per application basis. Separate management routines of master data (common or not) cease to exist in subscriber (source/target) systems. The consolidation of business logic continues until all business logic is completely removed from integrations. The integrations serve only to communicate from system to system. Additionally, maintenance and error handling business processes and logic are candidates to be consolidated and eliminated from the source and target systems. It is at this point that the architecture morphs into what the initial MDM concept prescribed a hub and spoke system.
Acknowledging and accounting for this incremental effort, especially the additional integrations, is a critical step in getting buy in for the MDM initiative as a whole. From an overall cost perspective, it is not uncommon that these integrations steps can equal the work load of the core MDM tool development. Even so, the value proposition the MDM tool provides immediately should not be ignored. In the long run it is always cheaper to correct un-auditable, manual, and error prone processes so they can’t fail or have controlled failure scenarios with auditing and user warnings/guides than it is to incrementally take a hit in user frustration and IT all nighters during the end of every reporting period? Tie to this the added benefit of beginning to figure out as a company what departmental and application differences exist in a centralized setting instead of conceding that Bob’s going to have to stay another weekend to contrive a way to get all applications in synch again (without obviously ever getting a chance to adjust the business process that created that issue), and it then allows a slow (and often painful) breaking down process in order to support an expandable and dynamic MDM solution.
Ranzal specializes in Business Intelligence and Business Performance Management with a concentration in Oracle/Hyperion’s toolkit. Ranzal works closely with corporate executives, line-of-business management, end users, and information systems departments alike to address the business issues and challenges inherent in data gathering, management, and dissemination. Organizations from various industries have engaged Ranzal with outstanding results.
Topics of discussion:
