Toss Out the Manual
By Glen O'Keefe
That’s what happened this fall at the University of Connecticut (UConn), Storrs.
In a way, the scenario was ironic. Like many institutions, UConn had developed a multimillion dollar, one-stop student services center. We built it six years ago in large part for such enrollment crunch times. But now, here we were in our new quarters, playing solitaire and eating snacks on overtime.
Not that we’re complaining. Only a few years ago, UConn exhibited all the classic signs of stress associated with returning students—long lines, busy signals, and high blood pressure for staff and customers. Based on these painful memories, we happily concede that our one-stop student center has many other benefits beyond its ability to accommodate large crowds.
To be sure, some of our newfound tranquility is the product of better coordination with other student services departments and implementation of an enterprise resource planning system in 2005. The ERP, in particular, nicely integrates bursar, financial aid, registrar, and other student services information into a single, Web-based application serving staff and students.
But much of our progress at the UConn bursar’s office actually began prior to our ERP implementation, with the use of a technology broadly known as workflow. Applying workflow, we were able to streamline many processes to boost customer service and free staff from time-consuming, manual tasks.
What Is Workflow?
Workflow may be defined as the automation of a task that requires review by multiple persons or offices within an organization. Of particular interest to us is that a workflow can be initiated by a customer and then processed appropriately by student financial services staff.
Where did workflow come from? The process has diverse origins but, at a certain point, someone figured out that the same basic technology that moves a plain text e-mail will also move tasks, documents, objects, and other information from person to person. In workflow, human input is combined with logic and routing information to initiate a task, review it, modify it, approve it—or disapprove it—and, finally, update the related information in back-end data files.
Workflow is particularly popular when used in conjunction with process re-engineering efforts. Typically, paperbound and labor-intensive tasks are converted into sleek, efficient automated programs. Generally, the preferred interface is a combination of the Web browser and the e-mail inbox. However, many proprietary applications include workflow that is administered through a local “client” installed on the desktop.
It may be helpful to know what workflow is not. It’s not simply taking selected information from mainframe terminal “green screens” and making it Web-accessible. Similarly, it’s not the mere “webifying” of a process or task that was previously paper-based or manual. Even in cases where an individual performs an online review or approval of a process (or part of a process), the task is not necessarily a workflow.
Workflow, in fact, has some distinguishing characteristics. In addition to the aforementioned logic and routing aspects, one of the most important elements might be termed awareness. In a true workflow, staff participants in the task are automatically notified (or made aware) that it’s time for them to execute their part of the process. Simultaneously, the other participants also are aware of who it is that is executing or holding up the workflow. This notification is generally done via some kind of administrative screen or “view” that each person involved in the particular task can access.
The benefits of workflow are numerous. Among them are:
- improved customer service;
- reductions in paper, labor, errors, and misplacement of information;
- tremendous time savings, as tasks that previously took days or weeks are reduced to hours or even minutes; and
- transactions permanently stored in a secure, searchable, and sortable database with views that can be tailored to various staff roles.
The Intimidation Factor
Although many institutions are already using workflow, others have hesitated. While they’ve wanted to reap the obvious benefits of workflow, they are intimidated by its apparent complexity. They envision the routing aspects of workflow as being a mass of complicated logic and decision trees.
Indeed, some of the non-student-related administrative workflows can be complicated. For example, UConn’s online transfer voucher, which departments use to make payments to one another, contains many routing “whistle-stops” along its journey. Typically, an office assistant initiates the voucher and routes it to a supervisor for approval. After approval, the document is sent to an individual with authority to accept or reject the charge for the particular department. Once accepted, the document moves to an accounting manager for final review and approval. Finally, the workflow system updates the financial system’s back-end files, debiting or crediting accounts accordingly.
Along with resistance to complex processes, a secondary point of anxiety can be the “signature authority” aspects of workflow. The work required to build the initial infrastructure that sends workflows to the right reviewers and approvers can seem daunting.
Fortuntately, though, customer-oriented workflows in the student financial services arena tend to be less complicated. At UConn, one of the reasons workflow began in student financial services was because of the simpler routing and authorization requirements. Often the only routing needed is from student to staff and back. Likewise, signature authority is generally a non-issue because the workflow is hard-coded to a specific person or area in the office as soon as a student signs in.
As the maxim goes, necessity is the mother of invention. At UConn, necessities were many when it came to making student financial services more efficient. Because of this, we began looking at workflow in 2004 and decided that it was worth trying. Since then, we’ve used workflow for just about anything we can think of, from the simple to the complex. Examples include appealing a late fee, requesting a deferment, or requesting a refund check.
Some of our workflows, such as making a credit card payment or requesting a deferment based on anticipated Title IV financial aid, were phased out because of ERP efficiencies. However, here’s an important lesson for institutions that have not yet purchased an ERP: You can have some quick wins today with workflows while you’re contemplating whether or not to make the ERP investment. Last January, The Chronicle of Higher Education reported a finding by EDUCAUSE indicating that the share of colleges with installed ERPs was still only 49 percent in 2004–05. Workflow permits business officers in the other 51 percent to serve up some pretty impressive self-service applications via the Web.
A Sample and Its Results
Our decision to use workflow to address a particular logistics problem has resulted in measurable benefits. Here is how it has worked.
Addressing an administrative roadblock. A huge problem occurred each year when graduate students collided with undergraduate students during the first week of classes. Like many research institutions, we permit students with a graduate assist-antship to apply for payroll deduction contracts. Payroll authorization is coded to the grant and the business office intercepts part of each paycheck to cover student fees.
To apply for GA payroll contracts, however, several things had to happen. The first and most troubling step was that everyone had to stand in line at a bursar’s office counseling window. This was problematic because grad students were taking up valuable “real estate” in the building, as we simultaneously endeavored to serve throngs of undergraduate students.
Subsequent to standing in line, graduate students filled out lengthy forms and gave them to our staff, who then placed the forms in an in box that students likely noticed was stacked precariously high. The individual student was then told to depart in peace and to call us in a few days to find out if everything had been approved. When time permitted, staff would undertake an analysis of the student’s situation—including verification that the individual had a graduate assistantship—and calculate whether the requested deduction could be supported by the stipend. Finally, if all was approved, staff would manually enter a series of seven deferments, coinciding with paydays, into our student financial system. The entire process of setting up the payroll contracts typically took a minimum of two weeks.
Introducing workflow self-service. After consulting with the graduate school, we developed a secure, Web-based self-service application that negated the need for grad students to come to the building. This alone drastically reduced our labor quotient.
The GA payroll workflow is highly efficient. When a student signs in, nearly half the form is filled out automatically, as the workflow pulls information from our data warehouse. The application checks to ensure that the student has an assist-antship and asks a series of questions to ensure that the requested deductions can be supported by the stipend. The student then is presented with some formal contract language and asked to e-sign the contract, using a combination of his or her student and Internet IDs.
From there, things move quickly, in the following sequence:
1. Confirmation. A confirmation notice is automatically sent to the student’s official UConn e-mail account. This is an important step in any workflow to help mitigate fraud. The notice includes language that informs students that, if they have not initiated this workflow, they should contact the Bursar’s Office immediately.
2. Payroll deduction. The GA payroll deduction request moves to a staff “view,” a process that can be very useful in workflow. Typically, our server would have e-mailed a link directly to a staff member’s in box. However, views are preferable when processing large numbers of documents, because staff in boxes aren’t inundated by messages relating to a single task.
It’s also important to mention that “moving” a form is quite different than sending a traditional e-mail attachment. Attachments are simply new copies of a document. In workflow, the server presents the original document to the next person to take action in the process. Thus, whether staff are opening the form from their in box or from a view, they are not looking at a copy of the form but at the original.
3. Reviewing requests. Staff review of the GA payroll deduction request is quick and easy. The workflow presents the reviewer with pertinent information, such as confirmation that the grad student’s current registration matches the information in the graduate assistantship. Once the reviewer completes the task, he or she clicks either an “approve” button or one of a series of preformatted “denied” buttons. Each of the latter buttons explains why the contract was denied and what the student needs to do, without the reviewer having to manually type the message.
4. Finalizing the transaction. Upon approval, the workflow sends the schedule of deferred credits to the back-end files of our student financials system. The credits are then reflected on the graduate student’s fee bill.
The entire sequence of steps is concluded within 24 hours.
A Conducive Environment
|First Impressions of an Open-Source Workflow|
Kuali Enterprise Workflow (KEW) is a key component of the emerging Kuali Financial Systems project. For the uninitiated, Kuali is an effort by a community of collaborating universities to develop what would essentially be free administrative software to member institutions. It’s part of a growing “open-source” movement that reflects institutions’ increasing dismay over the inflexibility and crushing costs of acquiring and maintaining vendor-supplied systems. Collaborative development is occurring not only in the area of financial systems, but also for student systems, Web portals, and the teaching and learning space.
The University of Connecticut, Storrs, decided to try KEW on a relatively simple project that would fill a pressing need: the completion of the dependent tuition waiver for children of university employees.
Before. Like many institutions, UConn provides a tuition waiver benefit to certain employees. Previously, eligible staff were required to fill out a lengthy, paper waiver application. The form was then sent to the human resources department. Staff there would review the form and forward the student IDs and related information to the Bursar’s Office. After we reviewed all of the information, the data related to the waiver was entered into our student financial system. The entire process was labor intensive, time consuming, and susceptible to lost or delayed waiver applications. Clearly, this process was a great candidate for workflow.
During. We downloaded the free KEW software and got to work. From the beginning, our developers liked what they saw. “Kuali workflow easily plugs into your personal directory, single sign-on system, and other institutional infrastructure,” notes Mike Oatley, assistant computer manager for enterprise systems. Likewise, Rajesh Dasari, business programmer analyst for the Bursar’s Office adds, “The code is well written and greatly reduces development time and implementation.”
The XML-based Kuali workflow engine moves documents from point to point (or “node to node”). Additionally, it provides users with a nice, out-of-the-box “action list” screen. Within this screen reviewers and approvers can view all their pending tasks or perform document searches based on nearly any criteria.
It should be emphasized, however, that KEW is only the “engine” that moves documents around. To build the client application, the Web forms and back-end data store still need to be developed. For these, UConn went with a typical approach by using Java Server Pages with an Oracle database.
After. Converting our dependent tuition waiver via KEW made our previous paper process seem almost embarrassing. We were astonished to discover that once an employee signs in and enters his or her child’s student ID, the form literally “fills itself out” as information is now pulled from our data warehouse. In short, all employees need do is click the “submit” button.
The Kuali engine then moves the waiver along its route like a train going from station to station. It first goes to an HR staff member for review and then to an HR manager. From there, the waiver is sent to a billing supervisor in the Bursar’s Office for final review. Once this is completed, the back-end files of our student financial system are automatically updated. A process that used to take weeks can now be accomplished in as little as a few minutes.
Early assessment. Our overall first impression of Kuali workflow is quite favorable. One minor weakness was the shortage of documentation; our developers occasionally had to “find their own way.” But, in the context of a collaborative, entrepreneurial project like Kuali, this was not particularly surprising. Developing is fun; documenting is boring. All told, the documentation did not prove a major hindrance to us, and we suspect it will be fleshed out as the project matures.
Based on the outcome of our first project, we plan to continue using KEW for new workflows. It’s a project with great promise and potential. You can try it yourself by going to http://kew.kuali.org/ for a free download of the latest version of Kuali Enterprise Workflow.
Institutions can develop workflow for numerous processes using a variety of available platforms. Many applications, such as document management and imaging systems, come with some degree of workflow ability built in. Even Microsoft Office, through its InfoPath software, now has some modest workflow capability when the applications are used in conjunction with a SharePoint 2007 server.
However, institution leaders who desire to take workflow to a more sophisticated level must evaluate certain factors. To build robust, free-standing applications, consider the following:
- staff skill sets,
- software and hardware costs,
- the speed in which you’d like the workflows to be delivered,
- availability of ancillary resources, such as a data warehouse.
After evaluating these elements and researching the available solutions, UConn selected IBM’s Lotus Domino product. Domino has many advantages, including low cost, excellent security, and ease of use. Programmers familiar with scripting languages and with building graphic user interfaces (GUI) take to the product quickly, which results in rapid workflow development and deployment. Moreover, the system easily pulls and pushes information from our data warehouse and back-end data files, respectively. It also can work with any available data tables.
While we’ve used this product to build student financials workflows, we’ve also had success in applying it to other business-oriented areas. These include inventory control, a time and attendance system, a budget workflow used by departments to submit their annual requests to our central budget office, and the transfer voucher mentioned earlier. Most of these have taken 8 to 16 weeks to develop and deploy.
However, a particularly exciting technology that is emerging is the Kuali Enterprise Workflow. In our first experiment using KEW, UConn recently developed an application that allows eligible employees to quickly complete a dependent tuition waiver (see sidebar, “First Impressions of an Open-Source Workflow.”).
Ways to Work It
As with nearly all application development, institutions can take four basic approaches to workflow:
Central IT approach. By an almost “conditioned response,” most of us tend to view our technology aspirations as goals that need to be sponsored, funded, and shepherded by our central IT department—from idea to implementation. In many cases this is neither practical nor fair to our IT colleagues.
“Small lab” approach. Often it’s advantageous to start small and grow incrementally. This is especially true in the case of workflow, which has an almost “entrepreneurial” quality about it. Starting small allows you to move quickly on a limited basis and permits the experimentation that’s inherent to workflow development. Later on, once your workflow efforts reach a mature stage in the organization, it will be important to incorporate your institution’s standard central IT support and oversight.
Based on this concept, UConn began with a “small lab” approach within our finance division. With just a couple of skilled programmers and a systems/business analyst, we were able to produce a new workflow every few months. Most of these entailed the re-engineering of existing tasks and processes, with an eye toward improved service and greater efficiency.
It’s important to interject, however, that developing workflows for re-engineering purposes doesn’t mean we simply copy or imitate the current processes by doing them on computers rather than manually. Instead, re-engineering via workflow offers us important time to evaluate what we’re doing, and how we’re doing it—or, sometimes, whether we should be doing it at all.
|Plan Now to Attend March Conference|
Learn additional details about the University of Connecticut’s use of workflows—and much more—at NACUBO’s Student Financial Services Conference, March 2-4, in New Orleans. This year’s lineup includes plenary sessions covering superior customer service, lender and other relationships, emergency preparedness and business continuity planning, and the latest legislative news from Washington, D.C. The multitrack program offers updates on organizational, technical, and personal issues related to operations and systems, career growth and development, and post-secondary education financing from the institutional and student perspective.
Interact with faculty, fellow business officers, bursars, and student services and financial aid professionals through issue-driven discussions. Meet with representatives from more than 30 student financial services companies to learn about the latest products and services. To register or for more information on this and other NACUBO professional development programs, visit www.nacubo.org or call 800.462.4916.
In addition, don’t miss an opportunity to explore a topic in depth at one of three pre-conference seminars on Sunday, March 2, including:
Hybrid combination. As community interest in workflow began to grow, the finance division and our central IT department recognized that it was time to begin working together. It was important that they do that in a way that continued the spirit of entrepreneurship while accruing the benefits of central IT support. To that end, we moved to a “hybrid approach” to development, whereby finance division programmers share lab space with central IT developers three days a week. This has produced excellent results and ensures that the quasi-independent enrivonment doesn’t morph into chaos.
Outsourcing solution. Although UConn doesn’t currently outsource any of its workflow development, turning to service providers can be effective. Careful planning is required, as the variety of services available is almost as numerous as the number of companies willing to vie for your business. Suffice it to say, however, that it’s critical to have one or more talented in-house systems or business analysts to shepherd the arrangement. Such individuals are most effective when they have intimate knowledge of the institution’s business processes and can bring together institutional stakeholders and consultants in a skillful way.
In economics, the “law of diminishing marginal utility” states that as we consume a product, each successive unit used will be less satisfying or enjoyable than the previous one. Workflow almost seems to defy this law. Our experience at UConn is that the more we develop, the more excited we become, as new things that we can do with it come to mind. In light of that, we plan to continue workflow development in student financial services and, moreover, to expand its benefits to several other business and administrative areas. These include the accounting office, budget office, grants and contracts, human resources, academic business offices, and facilities.
However, the main message we’d like to convey to our student financial services colleagues is that workflow is doable. Moreover, in comparison to many of today’s popular IT initiatives in higher education, the investment required to initiate workflow can almost be considered “budget dust.” With enthusiastic leadership, institutions can develop new services that will wow customers and excite student financial services teams.
GLEN O'KEEFE is university bursar and associate controller, University of Connecticut, Storrs.
- NACUBO Expresses Concerns with ED Proposal to Expand Federal Financial Responsibility Rules
- IRS Proposes Modifications to 1098-T Reporting
- ED Policy to Require Annual Student Aid Compliance Audits Beginning FY17
- 2016 Intermediate Accounting and Reporting Fall
October 24-25, 2016
- ON-DEMAND: The CBO's Role in Diversity and Inclusion on Campus
- ON-DEMAND: The Clery Act: Strategic Planning to Mitigate Institutional Risk
- ON-DEMAND: Title IX: Key Issues Surrounding Institutional Compliance
- ON-DEMAND: NACUBO Live! Higher Education Accounting Forum
- ON-DEMAND: Responsibility Center Management: Two Different Perspectives