Establishing ERP Implementation Principles and Desired Outcomes?

Earlier today I participated in a webinar sponsored by the Center for Digital Research and Converge Magazine. I was asked to share some of the lessons learned from ERP implementations along with ways to leverage an implementation to derive the most business value out of it. At one point I mentioned that a recent project was governed by the most senior of campus officials and a set of 9 principles that were adopted by the governance group. After the completion of the webinar I was asked if I would mind sharing what those principles were; they are reproduced below.

Recognizing that these principles along with their accompanying desired outcomes were created almost six years ago, I started to think what if anything would be changed, added, or deleted if they were written for an ERP implementation today? I would welcome your thoughts, ideas, and suggestions as to how they might be enhanced for the ERP challenges of today.

I. PRINCIPLE: This is a business realignment project with the focus on providing 21st century services to students, faculty and staff as well as providing the technological infrastructure upon which the educational tools and services of tomorrow can be built. Today’s students expect an environment that enables them to find information and to self-manage their experiences with our institutions. Desired outcomes:

• Flexibility in course offerings and scheduling.
• Improved planning and decision making capabilities for classes, HR/Payroll, finance, financial aid, marketing, and program offerings.
• Enhanced reputation for student centric support (24x7 access to virtual business services, their faculty, and essential learning tools).
• Ability to reach benefits, budgets, expenditures, revenue, etc. on-line.
• Ability to quickly adapt to future needs.
• Enable information from data.

II. PRINCIPLE: Customization at the system and campus levels must be minimized, and considered only where there is a statutory requirement or a business case that benefits the system as a whole. Shadow systems should be eliminated completely. Desired outcomes:

• Financial savings in the reduction of existing customization where possible and the elimination of the creation and maintenance of shadow systems.
• An understanding of the real costs versus the perceived value of shadow systems and other third party software.
• Significant reduction in the time to take advantage of features in new software releases.
• Greatly reduced risk in the installation of new software releases.
• Elimination of errors and inconsistencies in reporting brought about by shadow systems.

III. PRINCIPLE: Any options which can reduce the overall one-time and recurring costs for the ERP system must be considered. Desired outcomes:

• Cost analysis of the true cost of ownership.
• An understanding that there isn’t any competitive advantage for any TBR institution to continue to operate its own administrative systems in a silo.
• An understanding of the tremendous competitive advantage in redirecting any cost savings we can realize into expanding our academic programs, research, and outreach services.
• Better understanding of the risks through their analysis.
• Better network management and proactive monitoring.

IV. PRINCIPLE: Campuses and the system office will need to commit the necessary human resources to design, implement and test the system in a timely and efficient manner, with the understanding that it will require the dedication of many of their best “key” staff members. Desired outcomes:

• Historical perspective of current business practices.
• Willingness to seek out best practices and to improve present practices, with a goal not be to replicate the way business has been done in the past nor to modify the new system to sustain our historical business practices.

V. PRINCIPLE: We will choose our project leaders, steering committee members, etc. wisely and empower them to make the necessary decisions. At the same time ensuring that all interested parties understand that these decisions must be entrusted to those so empowered for the project to be successful and that we must accept and support their decisions. And those decisions must be made within the values set by the Steering Committee and quickly so that the project stays on time and in budget. Desired outcomes:

• Adoption of a rapid implementation methodology.
• Creation of a rapid decision making processes with 24 hour turnaround on every issue.
• Accountability and senior level reporting.
• Management of the change process and not allowing significant changes to either the software or the calendar.

VI. PRINCIPLE: Consistent data structures are essential. Access to information between campuses and the TBR must be governed by security policies and operational procedures and policies, and not limited by the design of the architecture of the ERP system. Desired outcomes:

• Adoption of common chart of account, data dictionary and “best practices.”
• Creation of a formal and informal technical knowledge transfer network.
• Technical training programs which can be used across all campuses.
• Better trained work force that can support other campuses when the need arises.
• The establishment of a common data warehouse and consistent reporting requirements to populate that warehouse.

VII. PRINCIPLE: Though processes and procedures need not be identical on each campus they must be sufficiently similar to remain within the common academic and business services and framework of the TBR. Thus data elements, screens, scripts, etc. should generally have the same meaning, look, and feel across the TBR. Desired outcomes:

• Adoption of functional “best practices” (learn from within, learn from others outside TBR).
• Create a formal and informal functional knowledge transfer network.
• Functional training programs which can be used across all campuses.
• Better trained work force that can support other campuses when the need arises.

VIII. PRINCIPLE: ERP systems do not eliminate people/positions. The project is not an employee reduction effort but rather a staff development process to provide enhanced services. A new ERP system can enable employees to acquire new software tools/business skills which will make it possible for them to work at a higher skill level. Desired outcomes:

• Shifting staff time to problem solving and higher priority concerns rather than transactional and “heads down” activities.
• Staff focusing on value added functions with high touch and high customer service rather than on low value and invisible back office data entry.
• Higher skilled workforce where decisions and accountability can be pushed down to the operational levels.
• Professional growth and advancement opportunities for staff.
  

IX. PRINCIPLE: Communications, education & awareness, and marketing plans, geared toward a broad range of constituents, should be prepared and delivered on a frequent basis, along with relevant measures of progress. Leadership must require a regular and visible progress reporting and feedback mechanism. Desired outcomes:

• Constituents developing a better appreciation for the project and its objectives.
• Valuable feedback giveing project management another pulse of how the project is progressing, thus enabling them to head off problems before they have a serious impact.

The “Good and Bad” of Peer/Aspirational Facilitated IT Assessment?

Recently I witnessed a listserv thread about performing an assessment of information technology for a college or university. Originally the request was for names of consultancies that perform such services with the dialogue morphing into a suggestion of asking peer and/or aspirational institutions to visit the campus as a team to do the assessment. Having participated in consultant and peer/aspirational led assessments in the past, I started thinking about the positives and negatives of each approach and began to try to catalog them as best I could:

Costs: Peer/Aspirational led assessments will most likely be the most cost effective. Even if the team members are paid a small honorarium along with expenses it will still be significantly less than contracting for a professional consultancy.

Technical Expertise: I’m somewhat undecided on if one would bring more expertise than the other, but I would tend to think that the consultancy would bring more expertise to the table than a peer led approach because of the volume they will have with technology refreshes. Peers/aspirants swap out technology typically after it has been depreciated whereas consultants primarily work with customers on new technology projects practically on a daily basis. This constant exposure to new technology would suggest the consultant has an advantage. Nevertheless, educational institutions are in the researching technology business, so there could be exceptions to this generality.

Organizational Issues: Personnel costs are typically the largest cost driver in an IT organization, not technology. Additionally, dysfunctional IT organizations are usually dysfunctional because of personnel issues and not technology. I would tend to think that consultancies are in a better position to identify and make recommendations on organizational issues than peer/aspirant led assessments based upon their greater experience in dealing with large numbers of customers, along with matters related to candor discussed below.

Commitment/Thoroughness: Who will do the better job: the professional consultant or the volunteer peer/aspirant? I would think that assessment isn’t the core competency of the peer/aspirant whereas it is for the consultant. Peers are learning on the job while professionals come to the job with many assessments behind them, along with a methodology for conducting, scoring, etc. I’m not convinced the volunteer peer/aspirant would or could be as thorough or committed to the assessment as the professional.

Candor/Discretion: My inclination is to think that the consultant is going to be more candid about the problems in an organization than a colleague, especially as they relate to personnel issues, management style, etc. I would also imagine consultants are better prepared in how to break disturbing news and proposing solutions than colleagues who you’ll run into time and time again at meetings, symposiums, and the like. Finally, if there are major problems, is it really a good idea to air such dirty laundry with colleagues?

I recognize I’m most likely missing a lot and have perhaps oversimplified in many respects. So … what’s your opinion? I welcome your thoughts and commentary on the strengths and weaknesses of each approach. Consultants are especially encouraged to comment!