Following up on my last blog post about the future of administrative information systems, I want to spur your thinking and comments about the core elements that significantly drive costs upward on these implementations. EDUCAUSE and I suggested that we all need to raise an awareness that IT spending is done in support of functions across the institution, not just in or for information technology. And that the spending is often being done by the IT organization because functional areas and institutional activities demand customization of the systems for their specific and diverse wants (which are often classified as “needs”).
In the first key question we posed to the community in the previous blog post, we listed a variety of aspects to consider, including the development of realistic and pragmatic functional requirements, the drive for process and continuous improvement, and the need for organizational models. I would like to step back and challenge us to take a more critical look at those aspects I just listed. Because I think they are actually based on an assumption of an approach that has been employed in administrative systems development for decades: that our role in the IT organization is to automate the functions as they exist—to automate the status quo as directed by the functions already in place. I think we need to start before the beginning and examine what is meant by “the development of realistic and pragmatic functional requirements” and also “the drive for process and continuous improvement.”
Although there is plenty to rail about (and I will!) with regard to the vendor costs of these big systems projects, let us first gaze accusingly into the mirror at ourselves (institutionally speaking). Colleagues may have heard me refer to how we are all “special snowflakes”—unique in how our common challenges end up not being solved by the same solutions. Sometimes I use that reference to make a point that one size does not fit all, but I also use it to poke at this issue of how we frequently shrug off common solutions because they just don’t fit our “specialness.” The latter usage is particularly true when it comes to administrative systems, when we should be asking: Are we all really special snowflakes?
On the surface, one would think that the main administrative processes supported by these big systems would be pretty much the same at any and all of our institutions. All institutions have charts of accounts, general ledgers, payables, receivables, and procurements. All institutions hire faculty and staff, pay them, and administer their employment records for benefits and other services. All institutions admit and enroll students, register them, advise them on which courses to take, schedule them into those courses, bill them, apply their financial aid, and issue grades and transcripts to them. Thus, given that we all do these things, all these functions and their supporting administrative systems are mostly the same, right?
That was rhetorical. Of course the systems are not mostly the same!
At almost every one of our institutions, these processes are done differently . . . though they achieve the same results. This specialization is often viewed by the responsible functional areas—finance and administrative services, human resources, enrollment management offices (e.g., Admissions, Registrars, Bursars, Financial Assistance)—as part of a given institution’s “secret sauce” and the result of continuously “improving” their systems over the years. Cloaked in the guise of improving services to faculty, employees, and students (and students’ parents), these functional entities press to make significant campus-specific customizations to the basically fully functional systems that arrive “in the box.” And these customizations are often the most costly element of implementing and maintaining our administrative systems.
Because of the history and evolution of the IT role in these administrative systems—originating, as most did, in the basement of the administration building and the back room of the registrar’s office—CIOs are often not positioned well enough in the campus organizational culture to successfully resist (or even question!) the pressure to make these “special snowflake” modifications. But we must raise the question: Are our administrative processes and procedures, as represented in our administrative systems, really that much of a differentiator in the successful advancement of the missions of our institutions?
Let me make this personal. I have had three kids go off to college. In each case, we reviewed potential universities, ruminating on why a particular campus might be a best-fit and on which course of study might best advance my children’s ambitions and position them to achieve their goals in life. In our consideration of various institutions, not once did we ever discuss the quality of the registration and bursar billing system, nor did we evaluate whether the general ledger and accounting system suited the needs of my children as students.
Did I complain a time or twenty about the challenges in getting them registered or about their financial assistance applied? Yes, I sure did. Did I call one of the offices to complain about how a process and online interface was confusing? Guilty. However, these inconveniences were never of paramount importance to the overall goal of getting my daughter or sons educated and positioned to take the next steps in their life (and out of my wallet). And speaking of my wallet, I wondered how much of the money I paid was needed for the investments by these institutions in their administrative systems and the “special snowflake” customizations. Unfortunately, given my experience, I knew the answer all too well.
As a CIO and as a parent of former college students, I can state the answer to another question I asked above: These systems and their special snowflake modifications are not differentiators. Further, the perceived need for our institutions to treat our administrative functions (and thus our administrative systems) as key differentiators may, in fact, dramatically drive up the costs in the looming replacement cycles. To be clear, I am not saying that a singular, uniform solution employed by every campus is the answer. Our institutions—which vary by size, missions, locations, and cultures—do have process differences and diversities that must be addressed. Functional officers are legitimately concerned about serving and satisfying their customers. But to what extent is that satisfaction worth significant (even massive) cost to the institution—a cost that, more and more often, is passed on to those very customers?
What do you think? Do you agree? If so, what ideas can we come up with to help us make progress in overcoming our origins and recruiting our functional-area colleagues to the table to consider how we can melt all the snow?
Customization – Key Questions
1. Is the return on investment of extensive customizations supportable? Or have we let the “perfect” become the enemy of the “good enough”?
2. Are better budgetary/organization models the ones in which the functional areas own not only the responsibility for customization specification but also the responsibility for costs?
3. How can we improve the dialogue between functional areas and IT organizations in trying to reach pragmatic approaches to customizations?