Examining the ongoing challenges of delivering high-quality, value-added ERP services in Higher Education.

Saturday, March 19, 2011

What a User Wants

The typical budgeting user wants a simple user interface for entering budget data; around the implementation team we called this data form the “blue sky” (for reasons that will soon become clear).

The requested design was simple enough in concept:
  • 1 Page drop-down to select (Org)
  • Scenario, Version, and Period in the columns
  • All other Chart of Accounts dimensions in the rows
  • Take advantage of dimension security to limit output
  • Rely on Planning’s suppression feature to show only valid (previously used) combinations

Figure 1: The “Blue Sky” Data Form In Action

At first blush, the resulting screen looks rather innocuous. And during the first stage of unit testing, it rendered successfully—and quickly, at that. The room broke out in cheers and high fives; then the application server crashed.

“But it can’t be the data form!” the team pleaded. “It loaded! It was fast!” We logged an SR with Oracle and kept testing. Your form is too big, Oracle told us. Build smaller forms!

By default, Hyperion Planning warns the user if the potential grid (column elements x row elements) exceeds 1,000. At Harvard, even a small department in one of our smaller Planning Applications (roughly = school) would have nearly 4,000,000,000 potential combinations in only three dimensions (Fund, Act-Sub, Root). As we began to analyze the work Planning and Essbase were doing behind the scenes—calculating potential combinations, reserving in memory a virtual grid to store the data, executing the query, populating the grid, applying security and suppression logic, etc.—it became clear that we needed to pursue an alternate design paradigm.

Figure 2: Go-Live Data Form

This revamped design performed well for all applications, irrespective of size, as the maximum grid size was the same for all schools. However, the design was predicated on one critical assumption: that the end user knew his or her financial details well enough to select the chart of accounts combination from the application. Because there is no ability in Hyperion Planning to auto-filter or cascade lists of values based on previous selections, the user might be forced to pick randomly from the other lists of values, desperately seeking valid combinations.

Figure 3: When the User Can't Find Data

That users did not know their full accounting strings was something of a surprise to the application design team. Our immediate response was to train users how to use reports and data forms together, toggling within the Hyperion Workspace between the two. Although this was a reasonable short-term answer, it was hardly a long-term solution. The team went back to the drawing board to define a better data-entry solution.

To be continued… at the HEUG Alliance 2011 and OAUG COLLABORATE ’11 conferences:

HEUG Alliance 2011 - Monday March 28, 12:45-1:45pm, Room 712

OAUG COLLABORATE '11 - Sunday April 10, 1:30-2:30pm, Room W304D

Monday, March 14, 2011

Hyperion Planning Data Form Best Practices

In Oracle’s Hyperion Planning, data forms are configurable screens that allow end users to input and adjust data in their active budget and forecast scenarios. Configuration is remarkably easy–one of the true strengths of the application. Through a wizard-like interface, designers can easily define which dimensions appear as spreadsheet-familiar rows and columns, as drop-down “page” selections, and as fixed point-of-view (“POV”) dimensions. Unfortunately, the layout wizard will allow a designer to create any template—even one that can cause the application server to crash!

[One of my favorite lessons learned from the early days of our implementation of Hyperion Planning… As the project team began to build data forms in our development environment, the “preview” option in the data form wizard was identified as a root cause for frequent application-tier failures. Rather than identify the data form design itself as the culprit, we authorized a customization to prevent users from activating the preview feature!]

By default, Planning raises an alert to the end user anytime the potential data grid (row dimension members x column dimension members) exceeds 1,000. Any guesses about a typical potential grid size of our initial design? How about 4,000,000,000? Yikes.

Customers initially requested all Chart of Accounts members in the rows of the data entry forms—similar to the Excel spreadsheets they had long used for annual budget submissions. Unfortunately, the Hyperion Planning gurus gave us the following advice:
  • Row and Column contain dense dimensions only
  • Page and Point of View (POV) contain sparse dimensions only
  • Suppress Missing Data option enabled so as to not display Rows or Columns without data
  • Split data forms into multiple data forms that contain fewer Rows and Columns
  • To put it more simply – KEEP DATA FORMS SMALL!
Everything about our initial design contradicted the recommended practice. So how would we balance customer needs with performance standards?

Learn more at the HEUG Alliance 2011 and OAUG COLLABORATE ’11 conferences:
HEUG Alliance 2011 - Monday March 28, 12:45-1:45pm, Room 712
OAUG COLLABORATE '11 - Sunday April 10, 1:30-2:30pm, Room W304D

Labels: , , , , , ,

Friday, March 11, 2011

Dude, Where's My Budget?

I have a busy few weeks ahead, traveling to Denver for the Higher Education User Group (HEUG) Alliance 2011 and to Orlando for the Oracle Applications User Group (OAUG) COLLABORATE '11. At both conferences, I will present a paper on Harvard's implementation of Hyperion Planning. The session, entitled "Dude, Where's My Budget? An Innovative Budget-Entry Solution in Hyperion Planning" (a groan-inducing title of which I'm very proud), was developed in collaboration with Ryan Sullivan, our crackshot Planning and Essbase Product Manager.

The session is targeted to a broad audience, balancing business context, solution design, and interactive demonstration, with a smattering of old-fashioned "geeking out."

Presentation summary: "Learn how Harvard University used Hyperion Planning features and outside-the-box thinking to build a robust data-entry solution for managing complex and confusing budgets. Harvard developed a network of interconnected data entry web forms to allow planners to drill-down from their high-level budget to the lowest level seven-segment chart of account budget. The end result is 50% report, 50% data form, and 100% geared toward improving the user experience and simplifying the process of entering budgets and forecasts."

My goal is to demonstrate the following themes:
  • Overview of Hyperion Planning implementation at Harvard University
  • The challenges (and potential solutions) for detailed budgeting and forecasting with a massive chart of accounts
  • Using under-the-radar native functionality to streamline navigation of data entry forms in Hyperion Planning
  • Effective techniques for managing continuous service improvement
Over the days leading up to the conference, I'll be posting details of the presentation and looking for questions or comments from potential attendees (please feel free to post here or contact via Twitter) that I can incorporate into the final presentation.

For those of you already registered for these conferences, time and location information provided below. I look forward to seeing you!

HEUG Alliance 2011 - Monday March 28, 12:45-1:45pm, Room 712
OAUG COLLABORATE '11 - Sunday April 10, 1:30-2:30pm, Room W304D

Labels: , , , , , ,

Wednesday, March 9, 2011

Four Upgrades

Two years ago we talked about the possibility of overlapping ERP upgrades as if it were an insane, doomsday scenario. Yet here we are, upgrading PeopleSoft Enterprise HCM, Oracle E-Business Suite Financials, and Hyperion Planning (a.k.a. "EPM"). And, oh by the way, let's replace existing reporting tools with OBIEE+. How did we end up here?

The economy had something to do with it. Not only because we put the brakes on funding our own large-scale IT projects, but because others did. We don't like being first movers, so when others postponed their projects, we postponed ours even longer.

Oracle's support timelines had something to do with it. Not only schedules for declining support levels, but also recent decisions about extensions of those timelines, waivers of extra fees, etc., which may have skewed behavior at Harvard and our peers.

Our upgrade strategy had something to do with it. Some organizations have a codified ethos. Upgrade immediately. Upgrade as late as possible. Upgrade in-kind. Upgrade with enhancement. Never upgrade. Our ERP upgrades have tended to follow a Goldilocks approach on timing—never too early, hopefully not too late. They have generally also taken a hard-line on scope—no new features unless absolutely necessary. So what happens when the business demands more dramatic expansion of features? And if new executive leadership defines de-customization as a strategic objective? Goodbye, miminum scope.

Our operational calendar had something to do with it. One business line says April or bust. The budgeting system is off-limits from December to June. Financials stakeholders don't want anything putting fiscal year end at risk, so that rules out June to September.

Slip a year here and a year there and you end up with 4 Upgrades proceeding in parallel.

We didn't want to be in this position, but there is a silver lining. We should realize economies of scale for project management and quality assurance. We can combine forces on common tools such as BI Publisher. We can share costs on dedicated testing and training facilities that no one project could afford. And from a cultural standpoint, the entire organization shifts into “project mode” at the same time, rather than in pockets. Scary as that might be, isn’t it also a little bit exciting? (Or maybe just for a dyed-in-the-wool implementation guy like me…)