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


Friday, September 28, 2012

Jump-Start to OBIEE with Noetix

Last year around this time, I was on the exhibition floor at Oracle Open World in San Francisco, looking for inspiration. My shop runs PeopleSoft HCM, E-Business Suite Financials, and Hyperion Planning and over the last two years we have been mired in upgrades (R12 going live 59 days from now will be the last... and then we will not speak of upgrades for at least six months, I hope!) But I was grappling with one key issue: how to advance business intelligence and reporting, especially for the financial management community here. So I took full advantage of the crowded exhibition floor(s) at the Moscone Center, spending several hours watching demos and asking questions about packaged analytics for core financials, hoping something would click.

We chose Noetix in large part because of the Noetix Generator, a feature that converts those NoetixViews into an RPD (metadata repository) compatible with Oracle Business Intelligence. From all appearances, this was a "turn-key" solution that within mere hours (literally) would give my team a solid base from which to start delivering analyses and dashboards to our hungry-for-data business end users, heretofore accustomed to hours of manual manipulations. Of course I had heard about the (in)famous views and knew that many of our higher education EBS peers use the Views to power Discoverer (which we never implemented here).

Of course it didn't happen that fast... A seed planted in San Francisco in early October sprouted in the spring and blossomed in the summer. There were contracts and demos and reference calls and internal discussions before we made the decision; the software was installed to our test environment in mid-August. Which brings us to today, about to go-live in 2-3 weeks with a dozen Payables and Receivables reports despite an R12 Upgrade looming on the horizon...

So how does it work? After trying to find answers on the web, this blog intends to pay it forward and give a little insight into the process and what we have learned so far.

1. NoetixViews are NoetixViews are NoetixViews... If you know them, there is nothing else to say. If you don't, these pre-built views are installed in a new schema on your E-Business Suite database server. Standard views (not materialized) and although initial testing has been positive, many here harbor reservations about adverse performance impacts... We shall see! So far we have been pleased with the breadth / coverage of the views themselves, although there is a learning curve to navigating the views, which brings me to...

2. The incredibly intuitive Noetix Search tool (shown below) is my new best friend (when I am secretly developing reports instead of managing my department). The director of back-office operations told me that this feature alone might justify the investment.  It is hard not to wish we had a data dictionary like this for our enterprise data warehouse... 

Noetix Search: My New BFF

3. Noetix Generator automatically generates OBIEE application roles, meta-data repository, and pre-delivered report templates known as "Answers" (more on this below) -- the three critical components of the OBIEE solution. It really does work as advertised -- in mere minutes after installing the Views to EBS we had a fully functioning data model to write reports against!
Action Shot of NoetixViews in OBIEE
4. Noetix Workbench is a tool for customizing NoetixViews and the corresponding RPD...  And you will need to customize, there's no two ways about it. We own this new module but have not yet had a chance to use it. since I laid down a "no customizations" edict for the first roll-out! We are building a backlog of required customizations; nothing earth-shattering, but it has become clearer to me that some degree of customization is inevitable for every customer...

And now for some initial observations / fun facts about our implementation so far:

The first fun fact about this Noetix/OBI solution is that my team was able to build a robust library of reports in a matter of hours. If you're starting with inexperience in OBIEE or lack of knowledge of E-Business Suite data terminology, the curve is steeper. But this solution represents exactly the jump-start I was hoping for. People were shocked.

The second fun fact is that the delivered Answers, which are plainly advertised as templates rather than ready-to-use reports, provide a useful window into the data model and potential performance issues. We executed a time-consuming but ultimately valuable exercise of creating a Confluence page for each report with a screenshot, high-level description, performance results, and an initial assessment of the functional fit given what we know of the University business. We then made these pages available to the business stakeholders to gather their feedback. The reports accomplished exactly what I expected -- they spurred conversation and helped my team learn their way around; none of the "Answers" will be deployed to our PROD environment, but several will serve as inspirations!
Analyzing Packaged Noetix "Answers" (Report Templates) in Confluence

The third fun fact is that by default  the Noetix Generator RPD sets the cache property to "Never Expire" for all the Views... And the only other option is No Cache... We are working with them to figure out how to get to someplace in between.This also raises an issue that if you promise "real-time" to people but there's a data cache... Guess what? Not real-time after all!

(There is a much broader topic for future blogging on how to define a cache management strategy. The impact on the user experience is tremendous... Just think about the potential frustration from a user if a prompt list takes 45 seconds to render -- put that baby in cache!)
 
And the fourth fun fact: the Noetix subject area is NOT a dimension / fact structure the way that OBIEE gurus might expect it to be. These are big, fat, traditional views. This takes some getting used to... And there are some disadvantages if you've grown accustomed to star schemata. But it also proved something important to me -- are we making this thing (OBIEE) too complicated? Are there traditional views that might be fit for use without jumping through a bunch of data modeling hoops?

More questions than answers, but I am extremely excited about our prospects!

Labels: , , ,

posted by JasonShaffner @ 10:30 AM Add a comment!

Wednesday, September 26, 2012

Telling Stories

I like telling stories. For a while I thought I might have a future in telling stories, and someday I'll write that Great American Novel, I swear... But for now I must content myself with Agile stories.

"Story" is an interesting word. For me -- perhaps for anyone who has studied or practiced creative writing -- those five letters prompt an avalanche of thoughts; now that I have tried my hand at writing user stories according to the Agile/Scrum methodology, I realize some of that training might actually come in handy in my "real" career after all.

The concept can be quite foreign, and initially I have refrained from explaining the concept to my stakeholders, anticipating that illustration by relevant example will be infinitely more effective than abstract, slightly jargon-y concepts. So yesterday I sat with one group of stakeholders and worked through a story-writing session (without ever calling it that). I listened carefully, asked "why" about a thousand times and captured exhaustive notes. In the back of my mind, I was writing the user stories as I went along and shaping my questions to fill in those critical blanks in the formula. 

User stories are a lot like "ad libs" (I'm surely not the first to say so, but I haven't checked). "As a ____ I need ____ so that I can ____." The first blank is a cinch -- usually obvious from the person stating the need. The user often thinks the middle blank is the easiest. Much of the time, I think the third blank is the hardest. (And the second blank is seldom quite right once you gain clarity on that third blank!) When it comes to the "so that" question, a blank stare certainly tells me something... But it often takes some probing to get to the good answer, which is essential to breaking down a story into discrete (and more digestible) sub-stories. In some ways, I think it makes sense to walk in with a pick-list of potential so-that actions -- in all honesty there aren't that many possibilities!

Here are a few of the stories I wrote: (accepting any and all feedback)
  • As AP SUPERVISOR I need to understand the gaps between key procure-to-pay dates so that I can identify potential process bottlenecks and local (dept) interventions.
  • As REIMBURSEMENTS MANAGER I need to analyze employee reimbursements data by Object code (Air, Meals, Lodging) by School to facilitate conversations with departments, employees, card services provider, procurement, etc.
  • As DISBURSEMENTS MANAGER I need to be able to see a list of the top employee reimbursees so that I can identify potential under-utilization of the Corporate Card, potential fraudulent activity, and/or other policy issues.
  • As AP SUPERVISOR I need to analyze the gap between Invoice Date and PO Date for Payment Requests by School/Cost Center to identify areas where users are holding invoices locally so that I can reach out to School leaders.
Our (my) journey down this path is just beginning. I wrote a dozen stories today and my team will take a crack at another dozen tomorrow. The stories can be powerful in succinctly stating who, what, and why all in the span of a Tweet. But we shall see how things go when we try to go from building a backlog to planning a sprint! Next step -- story points and technical tasks!

Labels: , ,

posted by JasonShaffner @ 9:23 PM Add a comment!

Friday, September 14, 2012

The Complicated Skillset for Modern BI

The requisite skills for success in Enterprise IT are constantly evolving. But whereas once upon a time this evolution might have followed linear / predictable paths with a sub-discipline (programmers: COBOL to Java; DBAs: VSAM to RDBMS; App Developer: Oracle Forms to OAF) today we confront increasing ambiguity around the very definition of the world "developer" and an ever-more-porous membrane between sub-specializations under the broad IT umbrella. To make things even more complex, modern technology -- my focus here is on Business Intelligence, but the case extends to other business applications -- blurs the line between end users and analysts, plopping robust features previously hidden behind the curtain right at the user's fingertips.

This shift in paradigm is demonstrated below:

Figure 1: The legacy model, with clearly delineated roles and responsibilities, skills, and knowledge, with articulated hand-off moments between groups

Figure 2: A blurry model with overlapping responsibilities, requiring more extensive cross-training and relinquishment of control by certain groups; as application customization has moved from code to configuration we have been forced to confront this model.

Figure 3: The my shop faces in deploying Oracle Business Intelligence (OBIEE) (but hardly unique to that vendor or that platform). Here, technical developers, functional (quasi-IT) analysts, and business users are almost indistinguishable.

There are clear advantages to the third paradigm: it broadens the base of potential report "authors" (perhaps a better word than "developer") and eliminates the necessity for middle-men and low-value-added hand-offs. I have argued that it ought to off-load certain changes to the business users so that IT staff can focus on harder stuff. 

However, when I rolled up my sleeves and put my own hands on the technology (OBIEE) even I was somewhat shocked by the dizzying array of skills required to implement solutions:
  • Domain Expertise
  • Business Analysis / Requirements Definition
  • Quality Assurance
  • Data Modeling
  • SQL (and not just basic SQL, either...)
  • Web Development (HTML, JavaScript)
  • User Experience (UX)

This is a lot to ask for in one person. On the one hand, your typical technical developer does not have deep domain expertise and may be accustomed to receiving explicit instructions rather than working with end users to define the requirements; on the other hand your crack functional analyst may be able to execute drag-and-drop reporting but balk at writing CASE...WHEN statements. And only a very select few will come to the table with robust usability and graphic design talents.

When you click "New > Dashboard" in OBIEE, this is what greets you:



To fill this void requires asking and answering "web developer" questions. How much information should appear here? With what density? How will it scale based on individual screen resolution? User device form factors: the 19-inch desktop monitor vs. the 15-inch laptop vs. the tablet vs. the iPhone? And then there is the issue of navigation. Where will users click? What will the expect to happen when they do? What additional information belongs on the page? Look at all those options -- links and images, embedded content, text (don't be deceived -- this really should say "HTML" and/or "JavaScript"), or actual report artifacts?

As G.I. Joe taught me many years ago, "knowing is half the battle." My group has started to pay more attention to user experience sessions at conferences and resources such as Oracle's Usable Apps and Patterns pages. I launched a style guide on our Confluence portal: fonts, font sizes, alignment, color palette, text styles, icons and images... This is not the way we think! But this is our world.

We are also trying to define criteria to route emerging requests for reports to the right type of "author" -- if advanced visualization is going to be required, let's get that over to the IT team; if the change requires XSLT, hand it to the functional IT analyst; if the changes can be accomplished through the GUI, let the business user run with it. We are brainstorming a checklist and I hope to post something later this fall. We have also started to build a library of best practices and samples; this will expand rapidly as we deploy the application!

Our journey is just beginning... I would love to learn how others tackle this challenge and will be on the lookout for sessions during my upcoming conference junket!

Labels: , ,

posted by JasonShaffner @ 8:15 AM Add a comment!

Thursday, September 13, 2012

OOW 2012 Preview

Last year I blogged about the struggles establishing my schedule for Oracle Open World. Lo and behold, another year gone by, my next flight to San Francisco is only two weeks away, and I find myself in the same quandry. I spent more than an hour sifting through hundreds and hundreds of sessions, yet I feel unsatisfied with my schedule. The current iteration is heavy on E-Business Suite, dips one toe in the water for Fusion Apps, PeopleTools, and EPM, and somehow OBIEE, my personal hobby-horse, hardly makes an appearance. Yet the prospect of opening the schedule builder again is severely unattractive. What to do? Should I start over and put my faith in the automated schedule builder? Farm this out to my team? Wait until I'm onsite and employ the close-eyes-and-point technique?

Here is what I've got so far -- what should go?
  • Oracle Scorecard and Strategy Management: The Un-Scorecard Manual
  • Oracle Fusion Middleware in Higher Education
  • Higher Education User Group (HEUG) Update
  • Oracle OpenWorld Welcome Keynote: Oracle and Fujitsu
  • Oracle OpenWorld Keynote: Shift Complexity
  • Oracle WebCenter Strategy: Engaging Your Customers. Empowering Your Business
  • General Session: Executive Briefing on Oracle's EPM Strategy and Roadmap
  • General Session: A Panel of Masterminds: Where Are Oracle Applications Headed?
  • Oracle Financials: Strategy, Update, and Roadmap
  • Oracle iProcurement for Dramatic Business Performance Improvement Across the Enterprise
  • Achieving Business Transformation with Oracle E-Business Suite R12 Applications
  • Oracle Fusion Applications: Technical Architecture Deep Dive
  • Experience Procure-to-Pay Transformation with Oracle Payables 12.1
  • Oracle OpenWorld Keynote: Oracle and Infosys
  • Boost Oracle Hyperion EPM Reporting ROI with Oracle Business Intelligence Foundation Suite
  • Oracle OpenWorld Keynote: Oracle and Intel
  • General Session: How and Where Oracle Is Investing in Education and Research
  • Personalize and Extend Oracle E-Business Suite Applications with Rich Mashups
  • Five Reasons to Upgrade to PeopleSoft PeopleTools 8.52
  • Mobile Solutions for Oracle E-Business Suite Applications: Technical Insight
  • Oracle OpenWorld Keynote: See More, Act Faster: Oracle Business Analytics
  • Integrating Oracle EPM and Oracle ERP: Options and Implementation Examples
  • Improve Efficiency in Receivables with Oracle E-Business Suite 12.1
  • Cut Costs by as Much as 90 Percent with Accounts Payable Automation

Labels: , , ,

posted by JasonShaffner @ 6:46 AM Add a comment!