BI for the BlackBerry Crowd

During the recent COLLABORATE 2009 Conference, Ranzal was selected to present a session designed around showing how to use the reporting tools from either traditional Hyperion or Oracle (formerly Siebel Analytics) and deliver content to smart phones.  The session started off with an overview of smart phones, methods of delivery to those phones and some potential pitfalls and considerations, such as what if a user loses their phone? What kind of security policies need to be in place?  Then a couple quick demonstrations in Hyperion were given which included a few tips and tricks on formatting.  This was all done using Interactive Reporting and Workspace.  Lastly, a couple quick demos in OBIEE Answers were provided to the attendees.

The demos were done in Hyperion version 9, although the content was pertinent for version 11 as well.  Some of the common themes in the demonstrations were focus around timely information (i.e. there is no need to send a month report to a cell phone) and focus on exceptions instead of a whole data set (cell phone reporting should be more around focusing on a problem that needs attention than sending a whole dashboard or report).

A copy of the presentation from COLLABORATE 2009 can be found at ranzal.com.

Business Intelligence Technology Environment – Welcome to the Buffet

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.

The Goal: Using Theory of Constraints (TOC) to optimize EPM project delivery

Used in thousands of companies and taught in hundreds of business schools, The GOAL by Eliyah Goldratt is one of the most influential novels within operations management. Set in a manufacturing environment, the book describes a systematic approach to running and improving an organization. Yet, the concepts described are not unique to the Manufacturing industry.

The goal of an organization is to increase throughput while simultaneously reducing both the inventory and operating expense. From an accounting point of view, “Throughput” is defined as the net revenue made from selling a product or service.” Inventory” is defined as the money tied up in fixed assets to enable Throughput. “Operating Expense” is defined as the money spent to produce Throughput. However, these current definitions are not easily transferrable to the operations and management world, specifically Enterprise Performance Management projects.

As identified in our previous blog, Structuring flexibility in your EPM project: A guide for Maximizing Project value, the goal of Enterprise Performance Management “EPM” software is to drive profitable growth by delivering predictable results, improving transparency and compliance, and increasing business alignment.

The diagram below shows how the Throughput, Inventory, and Operating Expense definitions can be translated to meaningful terms within the EPM realm.

The goal still remains to increase Throughput while simultaneously reducing both the Inventory and Operating Expense. However, reducing implementation costs does not necessarily mean not hiring a consulting partner or choosing a partner with the lowest bid. As the saying goes, you get what you pay for. Reducing implementation costs also includes optimizing delivery of your EPM project  to reduce inventory and deliver overall project benefits faster. The most commonly used strategy for delivering a project faster is to utilize more resources. However, all organizations have constraints that limit their ability to delivery projects. Unless these constraints are addressed, increasing resources only increases the project implementation costs while leaving Inventory unconverted.

TOC proposes five (5) steps for optimizing EPM project delivery with regard to the organizational constraints and EPM goals:

1. Identify the project constraints
2. Decide how to exploit the project’s constraints
3. Subordinate everything else to the decision made in step 2
4. Elevate the project’s constraints
5. Continue to evaluate for new constraints

Identify the project constraints

Projects have many constraints. The key is to identify that constraint that affects project flow more than any other. Common project constraints within the EPM include

· Challenges with metadata and a lack of a common chart of accounts

· Challenges with sources of data and data cleanliness

· Lack of resource commitment and availability

· Unclear or unknown requirements

Decide how to exploit the project’s constraints

Even though many constraints may be important, one primary constraint should be identified and all other activities within the project should be staggered in such a way to squeeze maximum value from the primary constraint without overloading it.

Subordinate to the constraint

The key to this step is to make the primary constraint the focus of attention and eliminate rules and assumptions that inhibit the maximum value that can be provided by the primary constraint. Agreement must be made that additional tasks and activities are not to be interjected above and beyond the capacity of the primary constraint.

Elevate the constraint

Once all other activities have been subordinated to the primary constraint, it is highly likely that the primary constraint will become a further bottleneck within the project flow. At this point, additional time and resources can be added to the primary constraint in order to increase project flow.

Continue to evaluate for new constraints

As may have been recognized, constraints never disappear. They just shift from one area to another. Once the identified project constraint no longer becomes the primary project constraint, Steps 1 through 5 should be repeated again with a new primary constraint in mind.

Even if not utilized, these five (5) steps produce a new way of thinking about EPM product delivery. Used at strategic points, they can reduce project implementation costs while accelerating benefits. When implementing wide-scale Organizational Change, any advantage helps.

Structuring Flexibility in Your EPM Project: A Guide for Maximizing Project Value

The goal of Enterprise Performance Management (“EPM”) software is to drive profitable growth by delivering predictable results, improving transparency and compliance, and increasing business alignment. However, the competitive environment is hardly predictable and business objectives change based on environmental feedback. As projects are typically linked to business objectives, functional requirements and needs may change even during the project implementation cycle. If business alignment is a primary objective, then the software must be adaptive enough to accommodate the changes in order to maximize value.

Based on the results of a recent survey of IT Software Project Failures, the second highest ranked reason given for project cancellations was too many requirements and scope changes. Project management is often seen as the solution for achieving project success. The traditional approach is predominantly taught and utilized in most organizations. However, this approach has its limitations. The traditional project approach is best used when

· The solution and requirements are clearly defined

· You do not expect too many scope change requests

· Prior EPM knowledge is available in-house

· You can utilize existing templates.

Given the unpredictability within the competitive environment, and the dynamic discovery and delivery processes inherent in an EPM project, a more flexible project approach that allows for changes in scope is required. This flexible approach works best when

· The solution and requirements are only partially known

· There may be functionality that is not yet identified

· There may be a number of scope changes from the customer

· The project is oriented to new product development and/or process improvement

· The development schedule is tight and you can’t afford rework or re-planning.

Although scope changes are necessary evils within an EPM project, too many scope changes without a surrounding process can lead a project to failure. From the view of a business stakeholder, implementing an EPM project is partly getting what you want and partly discovering what you really need. The more transparency obtained, the more likely business stakeholders will attempt to enable discoveries via new or modified requirements. Not having the appropriate boundaries or structure in place can easily lead to exceeded budgets, delayed timelines, and ultimately a solidly implemented solution with not enough business value.

The key components required are adequate levels of flexibility and structure (otherwise known as structured flexibility).

As the diagram represents, structured flexibility provides project stakeholders with a wide range of flexibility to aid the discovery and delivery processes. However, a boundary exists that allows the project to remain structured and meet the project time, budget, scope, and quality objectives. The points where structure meets flexibility should be determined jointly by the project stakeholders. Effective methods should be used to ensure adequate communication within and about the structure. The following seven (7) steps, when used appropriately, can serve as a guide for achieving the structured flexibility that can maximize project value:

1. Develop the initial ground rules for maintaining structure at the very start of the project;
2. Obtain buy-in for the ground rules from all project stakeholders and modify if necessary to create a common language;
3. Ensure all project members are aware that a structure exists and what the protocol for operating within that structure will be;
4. Allow project members to be flexible in their thinking and approach;
5. Document and prioritize changes and new ideas;
6. Focus on the highest value items first  (needs not wants); and
7. Enforce ground rules where and when flexibility meets structure.

Although these steps may appear simple, high levels of project management and leadership skills are required to implement them. Having an objective project management partner helps.