Getting Your Banner Black Belt, Lesson One: Refuse to Become Overwhelmed
Mastering the art of Banner reporting can be easier than you might think! While Banner is a very complex ERP, the first step in understanding its inner workings is to refuse to become overwhelmed by working with the myriad data that exists in the system. This article is the first in series that will help curb your reporting fears and point you toward some resources that can help you get ahead and earn your Banner Black Belt.
Don’t Let the Database Overwhelm You
Early on in my reporting career, someone would come to me and ask for the simplest set of data, and I would stare back at them, looking like a deer staring down a Ford F-150. That was before I realized this simple truth:
Banner may have over 4000 tables, but they are very well organized, and more importantly, for any given request, you will likely only need data from a handful of tables.
As soon as I accepted that fact, the likelihood of me panicking in response to a report request went way, way down. The organization is really the key factor here. For any given functional area, there are only a handful of critical tables that you’ll use over and over—anything beyond those are typically for occasional use only.
To get comfortable navigating your institution’s Banner tables, I recommend keeping a quick reference guide to your most commonly used tables close at hand. I have found the one here – BannerBlackBelt_pt1_TableReference – to be very useful. Keep in mind that the tables listed on the guide in no way reflect all the tables you may need, but if you’re doing a report in one of these areas, the chances that you’ll use one or more of the tables listed is very high. The point of the guide is to remind you, in those moments when you’re feeling overwhelmed, that while Banner may have over 4000 tables, you’ll probably only need a handful of them for any given request!
Don’t Let The Report Requesters Overwhelm You
It’s an unfortunate truth that, as technical individuals, we often tend to think that what the functional folks do is none of our concern. When someone comes to us, requesting a report, our first impulse is sometimes to say: “Just tell me what you need, where to find it, and where to put it on your <insert expletive here> report!” But with a little bit of tongue-biting and a little bit of empathy, it can be surprisingly easy to defuse that initial frustration.
Oftentimes, we forget that our friends in the functional world can sometimes get overwhelmed themselves, paralyzed by not knowing what they can and can’t ask us to do. Keeping this in mind, there are couple things I try to do when first approached with a request. When talking to a functional user about their needs, I let them know up front, that I can probably do anything they ask of me. But, I also let them know that the harder (i.e. more complex/obscure) the request is, the more expensive it will be, in terms of both time and money.
Getting those two points out there, right out of the gate, accomplishes several things. For one, it reminds them that you’re all on the same team, that you’re there to help. For another, it puts them at ease, knowing that you’re happy to field any of the questions they have whirring around in their heads. And of course, establishing the fact that some reports will cost more—and take longer—helps manage expectations about the report generation process, right from the get-go.
After putting those points out there, I try to approach report writing from an AGILE or RAD mindset by focusing on delivering a working draft of the report as quickly as possible, with the expectation of fine-tuning it during subsequent iterations. As a rule, I try to spend much less time on the specification process than on getting sample reports in front requesters so I can collect feedback. Keeping the requester in the loop on your workflow plans is another good way to keep their expectations in step with your own.
Don’t Let the Data Overwhelm You
Another element of Banner reporting that can be mightily overwhelming is the discussion of the data itself. For example, when a report requester asks for information on FTE students, what do they really mean by that? Which definition of the term are they using? Do they know there’s more than one? Fortunately, a lot of the stress inherent in this part of the process can be avoided with simple, well-developed requirements documents…which we will discuss in-depth for the next post in our Getting Your Banner Black Belt series.
Until then, we’d love to hear from you: What reporting tricks you use to keep from getting overwhelmed? Let us know in the comments section below!
Latest posts by Zach Heath (see all)
- Best Practices for Designing OLAP Cubes - 05/01/2014
- Deconstructing Business Intelligence & Analytics for Higher Ed - 12/04/2013
- Configuration Tips for Improving your Data Security - 08/15/2013