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

posted by JasonShaffner @ 6:15 PM Add a comment!

2 Comments:

At March 23, 2011 at 11:51 AM, Blogger CM said...

Jason-
We just implemented Planning here at Fred Hutchinson Cancer Research Center in Seattle. Unfortunately I present at the same time as you at Alliance. But I'd love to connect with you and find out more about how you solved your problems. Maybe we can compare notes?!

 
At March 23, 2011 at 11:54 AM, Blogger CM said...

Sorry, should have left my contact info: This is Cameron McClurg from the GL PAG. I'll try to seek you out at some point.

 

<< Home