ERP FOR MACALESTER: REPORT AND RECOMMENDATIONS
The college is moving through a period of renewal and refocus around its mission and its place in the competitive landscape. The outcome of this work will likely confirm an expectation of excellence that is visible to key constituents in all that we do. Our ability to routinely deliver operational effectiveness, while not the core of the enterprise, is important to our cost control efforts and provides symbolic evidence of our commitment to excellence and service to our key constituents Ð prospective and current students, faculty and staff, and alumni.
The administrative tools that are currently available on campus are aging and the vendorÕs ability to upgrade them is questionable based on past history, so our ability to give constituents the same high quality ÔfeelÕ is becoming increasingly difficult. Over time, this will also become visible to our constituents when they compare their interactions with Macalester to other service providers and institutions.
We will arrive a decision point in the next year or two which will require an affirmative choice regarding the direction that we will take with respect this important functional area of the college. While the decision probably does not have broad strategic implications for the future success of the institution Ð this is not a point of institutional strategic differentiation Ð we will be faced with the need to continue to improve our service and efficiency in this area so we can meet the expectations of students, alumni, and employees.
The details that follow play out in three dimensions, risk, functionality and meeting needs of the future. The initial impetus of our ERP planning effort was avoidance of the risk of a vendor in a bad financial situation. As CFO David Wheaton puts it, the vendor, Jenzabar, has taken a step back from the brink. As with the other subjects, details are provided below. At the time we initiated our planning, the vendorÕs first attempt to redevelop the system had failed and the Òplan BÓ was unclear. While that plan now is clearer, we have not seen actual, working product. To meet the future and the competitive standard set by competing systems and their college clients, we would need higher confidence that the vendorÕs planned upgrades will work, will be delivered soon and will be cost-effective.
Another planning dimension underlies these assumptions and that is the question of selectively upgrading individual modules of a college administrative system rather than assuming an integrated solution. Macalester, alone in our planning consortium, gave careful consideration to this issue and our final recommendations include the options that seem right for us.
In our investigation and analysis, we are guided by four over-arching goals for administrative services, which essentially describe success. In the course of comparing MacalesterÕs current dominant solution against those of other vendors, we noted the divergences against our success measures. It is the case that any client of an ERP vendor has a long list of inadequacies of the current software and, usually, feelings about the current vendorÕs willingness to take them seriously. We, then, should not be surprised that there is such a list but should gauge the seriousness of the divergences.
Another advantage of the list is that much of the value of an administrative system is the business process efficiencies and service improvements it enables. The cumulative effect of these vastly exceeds each individual instance, making precise measurement and costing of the total very difficult. A series of examples, itself incomplete, serves to exemplify the effect on staff productivity and service to the college.
a. Provide effective support for mission-critical educational program
GRANT ADMINISTRATION
Grantors require that we report according to their budget schema and in their fiscal years. These data must be reconciled to Jenzabar-based accounting. Currently, about ten staff members contribute time to this process. Data must be double entered into Jenzabar and also into manual spreadsheets in order to produce needed reports to grantors. The alternate vendors have grant administration modules that do the work.
FACULTY CONTRACTS
Human Resources and college hiring centers, e.g. the Provost's office, exchange spreadsheets in multiple cycles before contracts are complete and entered into Jenzabar. Alternate systems offer field-level security of contract data, enabling one office to enter (and "own") selected elements of a contractual agreement, while HR or another central office securely handles the rest.
STUDENT SERVICES
Either through a proven and flexible portal or through a Web page, alternate systems offer students room and board contract and event sign-up online.
OPEN STANDARDS
Jenzabar evidently is developing a relatively closed, proprietary system whereas alternate vendors are supporting partnerships with third-party vendors and open standards. For example, the portal products of at least two alternate vendors are written to the open-standards of uPortal, which is widely adopted in higher education.
MAC/PC ENVIRONMENT
Many of the faculty prefer the Macintosh platform. Jenzabar does not equally support PCÕs and Mac's. Some Macintosh users still do manual paper processes instead of using online capabilities because of this. Both systems would be fully supported by alternate vendors who have brought transactions to the Web.
b. Achieve efficiency in administering the business processes of the college
SECURITY AND PERMISSIONS
Too many people now can get into too many places within our Jenzabar system. This is because the system offers crude management of security and permission levels, necessitating overly broad access to enable staff to do their work. Alternate systems offer granular control of access permissions.
AUDIT TRAILS
Jenzabar's implementation of logging and recording transactions is not efficient and we have implemented it in a limited way. Alternate systems provide higher risk management by smoothly integrating audit trails
PAYROLL TAXES
Basic payroll reports, such as the 941, cannot be produced directly from Jenzabar. These forms have to be done manually.
CREDIT CARD PROCESSING
Most increases in use of technology require manual efforts to integrate into the Jenzabar system. An example is credit cards. Manual journal entries must be created and data entered for credit card transactions. Other uses of technology are being delayed due to lack of staff to take on additional manual work, such as:
Development Ð using direct deposit for pledge payments or gifts
Admissions Ð using credit card payments for applications
VALIDATE TRANSACTIONS
Our transactions cannot be validated against our account code scheme before attempting to run the transaction and then intervening because of an error. Alternate vendors validate transactions before they are run
AUTOMATIC CALCULATIONS
Alternate systems offer automatic data calculation that currently is maintained on the side in spreadsheets at Macalester. For example, Macalester handles calculation of vendor interest charges on non-student accounts receivable with a spreadsheet and typewriter
BANK RECONCILIATIONS
Most systems currently have the ability to completely automate the bank reconciliation process. In Jenzabar only check reconciliation is automated. All other transactions are manually reconciled. The more use of credit cards, direct deposit, wires there is, the more manual reconciliation work.
INTEGRATED ENDOWMENT SUBSIDIARY
Jenzabar does not have endowment capabilities. The Endowment subsidiary we do have was programmed and is maintained by CIT staff. Because this is not part of Jenzabar, double entry of data is still required. This could be fully automated and supported by a different software product.
FLEXIBLE GL ACCOUNT STRUCTURE
Current structure in Jenzabar is limited. All other software had a more flexible structure. A flexible structure can provide for user needs more easily, such as tracking conference costs as a sub level to department tracking. This could be extremely helpful for departments when tracking one-time type events such as a conference or hiring costs.
INTERNATIONAL TAXATION
1042 reporting is not part of Jenzabar. CIT and Business Service staff time is needed to make this happen. In addition, some of the packages had fields designed for tracking some of the information needed to manage this database of employees. Currently, this is done manually. In addition, one of the software packages supplied tax treaty information, which currently, if we wanted to obtain purchase the information.
c. Incorporate new technologies that offer value to our primary constituents
PERSONAL DATA REVIEW
Alternate systems offer individual review and update of personal information over the Web. For example, change of address, marital status, etc. are accomplished by the user rather than necessitating intervention by staff.
TIME ENTRY
Macalester employs about one thousand students and tracking their time and pay currently is a manual operation. Alternate systems automate time-entry through the Web and integrated with the back-end payroll system.
OFF CAMPUS ACCESS
Fully developed, contemporary systems support secure access from off campus, enabling Admissions and other travelers to stay productive on the road. This is generally done using Web technology.
RESEARCH AND DEVELOPMENT
All the other products we looked at contribute significant amounts to R&D and are years ahead of Jenzabar. How will Jenzabar catch up? How much can they afford for R&D with their financial situation? They have been losing staff to other companies. It would appear that Colleges that stay with Jenzabar will not catch up to the technology level of the other software companies and we will always have these inherent inefficiencies built into our process as a result.
USING THE WEB FOR SELF-SERVICE
Below are typical self-service options. Although available in leading higher-ed ERP solutions, they are either not currently available from Jenzabar, their offering is limited or unacceptable, or our computing staff has created a custom solution. An asterisk signifies that Macalester staff has built the function instead of the vendor.
Using a familiar web interface students can:
á View Student Accounts balance and info
á Submit payments to College online
á View Financial Aid balance and info
á Complete student timesheets
á View Admissions status*
Using a familiar web interface employees can:
á Update tax exemption info
á Update benefits
á Update their directory profile
á Update miscellaneous biographic information (e.g. emergency contact)
á Complete timesheets and leave reporting
á View a personalized benefits summary
á View payroll history
á View job history
á View pay stubs
á View leave history
á View vacation and medical leave balances*
á View year-end tax statements
á View flexible spending account activity
Using a familiar web interface departmental financial administrators can:
á Create a purchase requisition
á Create a purchase order
á Create budget transfers
á View departmental, operational budget status:
o By summary or detail
o Compare budget status between fiscal years
o Review position funding throughout the year
á View departmental encumbrance activity
d. Improve operational and strategic decision making through the use of improved data analysis and reporting tools
POSITION BUDGETING
Macalester programmers had to customize Jenzabar to offer this rudimentary function in a limited way. Alternate systems offer position budgeting as an expected part of the base package, enabling management of our staff resources.
REPORTING
Reports currently done manually could be produced directly. Because of the long, difficult, manual process we are currently unable to provide certain types of quarterly management reports that could be helpful to Line Officers, Department Chairs and managers in managing their budgets.
Where Macalester College needs to be in this area summarizes the detail points above and can be succinctly stated in four propositions. The migration path and technology behind each, however, is complex.
a. Users engage pervasively available systems with minimal intermediation
Fulfillment of this vision means faculty and staff being able to manipulate their personal information on the fly, Web-compatibility so that access is pervasive and platform-independent and that the various systems we need interoperate easily. All this means introducing systems that make full use of the Web, are open to new software standards and integrate with third party higher education products, enabling us to seamlessly integrate our campus systems.
b. Each business process is accomplished efficiently and in a mode appropriate to task
Any system can be made to work in some manner, JenzabarÕs included. The question is how far off the mark we get in terms of services visible to users and the efficiency with which we run the college. These two are thoroughly interrelated. The ability of our staff to respond to student and faculty needs is chiefly determined by the flexibility and efficiency with which they can accomplish their daily tasks.
c. Academic and administrative support services are integrated
Academic and administrative workflows are, in many cases, growing together. In the Òold days,Ó when academic administration was paper-based, the nature of the back room processing was largely irrelevant to our students and faculty. Now, course registration, personal directory data, advising information and many other data stores that formerly were silo-ed, now are accessible to all.
d. Users have easy, intuitive access to important and relevant data for decision support and analysis
Getting relevant information into and out of administrative systems is an unexpected chore for many users. The ideal is to enable users to accomplish this themselves, without reliance on intermediary programmers putting each of their requests into SQL code. Macalester has made great strides in training selected users on the use of business intelligence tools but continued progress depends on a system that integrates such access.
In this section, we briefly review current administrative systems at Macalester, how they relate one to the other and implications for the future. We will also assess the current Jenzabar system.
a. Current systems
It is no longer reasonable to expect that all higher education functions be to be performed by one integrated system. It remains true, however, that achieving interoperability and efficient leveraging of staff time and skills in the face of disparate systems is a compromise. Thus, most institutions have a systems landscape that reveals past politics and technology issues. Macalester is no exception.
A typical integrated higher education system consists of the following modules. An asterisk marks those at Macalester using solutions other than Jenzabar.
In addition to these, colleges and universities usually present related services, often supported by third party vendors. These include:
The Advancement and Financial Aid departments left the integrated Jenzabar solution and purchased different systems before 1997. Data sharing between these departments and others is accomplished by CIT staff-designed batch file uploads, often scheduled nightly. The underlying database technology, report writing tools and other features are unique to each system. Both departments are satisfied with the functionality of the product although both strain to provide staff resources to support the system and fully leverage its features. Between the two, our analysis showed greater inefficiencies arising from a separate financial aid than a separate advancement system. This is because of the need for consolidated financial reports for individual students.
b. Integrated and selective upgrades
There is a trade-off between integrated solutions and selective ones. By selective, we mean upgrade of one of the classic ERP modules while the remainder remains within the integrated orbit. The cost-effectiveness ideal of the integrated solution is leveraging staff, hardware and software resources across the maximum number of user departments. Thus, the Admissions, General Ledger and Student Records operations share the same database management system, using the same operating system and hardware, accessing data with the same report-writing tools and deal with the same set of vendor relations and contracts. In addition, in the case of data that is shared among many users, its presence in the central, shared database renders it immediately available to users of other departments.
The opposite side of this coin is the likelihood that a department-specific solution was designed by practitioners and is more in tune with user needs and benefits from a developmental focus on a particular area.
Central to the analysis of this conundrum is the extent to which a particular department must share its data with other departments. If the answer is Ònot much,Ó then the costs of integrating disparate solutions are lower than if a multitude of other departments needs real-time access to just this data.
Macalester C.I.T. staff worked with their colleagues in user departments this fall to chart data relationships among the departments. This is not the sole variable to consider, of course. The results show very large differences among departments on this scale. The Registrar and Business Services departments are examples of ones that would be very costly to re-integrate, were they using disparate systems. The Admissions and Advancement departments have fewer such connections.
See Appendix: Data-Sharing Models (by department)
The Advancement Department already operates and staffs their own system (BSR Advance). Admissions shares the Jenzabar solution but rated an independent product as their preferred solution.
c. Jenzabar issues
Our planning began in 2002, when four local Jenzabar clients found they shared concerns about the companyÕs viability and ability to support their product.
i. Company history and financial viability
XXX
ii. Company product strategy vs. competing vendors
It is clear that the 2000 Ð 2004 period was detrimental to the company, not just financially but in its ability to keep up with progress in technology being made by competing vendors. While they were taking their character-based systems to client-server and to the Web, Jenzabar lagged after introduction of the popular student and faculty Web information systems under the old management. Much of the time and money went into a failed system rewrite project that was off-shored to India. The software failed to perform and the whole effort was scuttled in 2003. Since then, the company has scrambled to finance and develop an improved system. Jenzabar typically services a different market segment than that occupied by Macalester, which typically uses the Datatel and SCT solutions.
iii. Jenzabar plans for upgraded ERP system
The company now plans to retain the current Informix relational database and the basic application software that goes with it. This strategy is a realistic and practical one but compromises our ability to fix some of the problems outlined above. To this core, the company will add a portal and, to that, Web access services, called Customer Relationship Modules, or CRM's. In addition, business intelligence tools will be integrated with the new product look and feel and will be called data marts. All of these services will be charged as new product.
See Appendix: Jenzabar Development Plan
iv. Anticipated costs of continued partnership with Jenzabar
The list prices of these new products from Jenzabar are well over a million and a half dollars. To compare with the cost of migrating to another solution, we should add adjustments for the financial aid and advancement modules that were part of the bids and two staff to integrate and adapt the new product. The total over five years then comes to just over two million dollars.
See Appendix: Costs Ð Jenzabar, PeopleSoft, SCT
v. Jenzabar track record on execution and support
The company has performed poorly since the new management took office in 2000. This is borne out by our experience, that of other clients and confirmed by Gartner Group analysis. During this period of financial exigency and high staff turnover, support suffered (except in selected areas where veteran staff were retained) and we received immature software. The experience of neighboring schools with attempted installation of the first data marts has been bad.
See Appendix: Gartner Group report
a. Twin Cities collaboration
One factor in MacalesterÕs choice of the Jenzabar system in the late 1980Õs was the presence of neighboring colleges who are also clients. These include Bethel College, College of Saint Catherine, Northwestern College, and William Mitchell School of Law. We find advantages in sharing staff expertise and information while shaping implementations to our own environments. The CIO's of these colleges found in early fall, 2002, that they shared concerns about Jenzabar viability and lack of progress with new product. The CIO's formed a planning alliance that leverages advantage by acting collectively while preserving each collegeÕs autonomy. For instance, commitment to implementation of an alternate system or whether to migrate at all is held out as a decision to be made by each college after costs of a joint implementation are fleshed out.
See Appendix: ERP Timetable
b. Meetings with Jenzabar business and technical leadership
The collaborating college CIO's and CFOs recognized the need to gain clearer information on Jenzabar product plans and finances. Accordingly, corporate leadership came to St. Paul in April, and November 2003, to disclose product plan and company financial statements.
c. Macalester user involvement
Beginning in fall, 2003, Macalester user groups in various forms guided planning and contributed to a systems requirements document. David Wheaton chairs the current group. The system requirements document was a joint effort among the staffs of the collaborating colleges, who were asked to converge on consensus-based top priority requirements and who succeeded in a difficult task.
See Appendix: System Requirements summary
d. Presidents review
Collaborating college Presidents attended a review meeting in August 2003. At the meeting it was emphasized that (a.) we are comparing alternatives to Jenzabar as opposed to having decided to leave Jenzabar and (b.) each college has opt-in/opt-out privileges up to commencement of serious negotiation.
e. Vendor demos and costs
The CIO's led an RFI process that included dozens of vendors targeting higher education and that identified four with potential to deliver value to the colleges of the consortium: Agresso North America (a Dutch company), Datatel, PeopleSoft and SCT. Datatel and SCT focus on the higher education market; all except Datatel are publicly traded.
See Appendix: Summary data: Jenzabar, PeopleSoft, SCT
f. Evaluation by CFOs, CIO's and users
Demos by these vendors in December 2003 identified PeopleSoft and SCT, in that order, as the vendors offering product that most closely matches system requirements.
See Appendix: Summary vendor ratings
The first recommendation (6.a) outlines an architectural approach to systems at Macalester. The second (6.b) presents two basic options for our ERP choice.
a. Administrative systems strategy for Macalester
i. Utilize new and familiar technologies to focus on mission-critical service and keep up with the competition with minimal overall expense
ii. Converge departments on integrated system unless
a. there is good evidence of compromised mission-critical functionality AND
b. the area is of especially high strategic importance to college AND
c. necessary data sharing can be efficiently accomplished by other means.
iii. Consolidate technologies to simplify and minimize maintenance, support and staffing expense (minimize database, OS, hardware, report-writer diversity)
b. Administrative data strategy alternatives for Macalester
i. Migrate to PeopleSoft or SCT in concert with the collaborating colleges with a 5-year budget of $3.2 million.
This alternative lessens risk by associating Macalester with a more reputable vendor but incurs system migration expenses at a difficult time in MacalesterÕs financial history. Assuming successful migration (which is itself a risk), both products provide the sought after operating features and utilization of new technologies.
ii. Accept JenzabarÕs development strategy and stay with the product, with a five year budget of $1.5 - $2 million.
The second alternative accepts more risk with continued association with Jenzabar and attempts to add back functionality by a mix of promised vendor solutions and in-house development. There is opportunity cost in not participating with the college collaborative now.
1. Attempt negotiation of more reasonable pricing of Jenzabar modules.
2. Provide most needed Web services by developing them in-house and integrating third-party products with additional Web and database programming capability
3. Continue evaluation of the adequacy of the current product for Admissions and cost out alternatives.