Transcript Object Orientation in Action: A System for Designing

Planning and Implementation of
an ERP in a University: Some
Insights and Guidelines
Raj C. Somarajan
John R. Weber
Ken Surendran
Southeast Missouri State University
Presented by: Ken Surendran
Topics
• Background
– Institution
– Rationale for ERP
– Legacy Systems
• Financial Planning
• Technical Planning
• Organizational Issues
• Operational Issues
• Implementation
– Project Phases
• Lessons Learned
– Potential Risks
– Success Factors
Background: Institution
• Southeast Missouri State University
– Rural (covers 25 counties; three regional campuses )
– 1873 (normal school); teachers’ college(1919); SEMO
college (1946); SEMO University (1972).
– Steady Growth (now just over 10,000 students)
• Information Technology Services (2001)
– Integration of Telecom and Computer services
– IT Committee formulated the following vision:
To be the regional leader for the appropriate deployment
and effective assimilation of IT for supporting the
delivery of world class educational service.
Background: Rationale for ERP
• Difficulties in maintaining the interfaces
between the various legacy systems
• Mushrooming shadow systems (that were not
adequately supported)
• Difficulties in scaling the legacy systems to
meet the growth in operation
• Difficulties in offering web based services
• Difficulties in incorporating new technologies
like GUI and web services with these
mainframe based legacy systems
Background: Legacy Systems
• In-house Legacy Systems (on Mainframe):
– Student management system
– Materials management system
– Interfaces to link many third party systems and others
• Third party systems:
– DARS (an advising system from Miami Univ.)
– MUSIC (an editor from McGill Univ.)
• Others:
– Data warehousing (SQL server)
– Front-ends to provide access to web
– Shadow systems in many functional areas
Financial Planning
• Two Options: (For more or less same cost)
– Enhance existing system using mainframe within
four years
– New integrated database solution (allowed for
future growth) – chosen for Quality of Service
• Budget of $3M and financial plan over 6 year period
– Hardware, system software licenses, application
software licenses, installation, training, annual
maintenance. Special fund was made available
• Justification:
– Value perceived from improving quality of service.
– Maintenance cost (mainframe system) recovered
over subsequent six years – breakeven period
Technical Planning
• Map a comprehensive IT infrastructure &
architecture
• Several sub-projects (upgrades network with
standard equipment & OS and other system
software for ERP)
• No ERP can replace all legacy systems. Hence
plan for procuring compatible third party
replacement products
• Follow the routines: Request for proposal,
proposal presentation by vendor, set criteria for
adjudication, contract negotiations with the
selected vendor
Revised University Electronic Portal
Internet
Information
Channels
Instructional
Services
University
Custom
Information
Channels
User Log in
Commercial
Portals
University Web Portal
Library
Services
University.edu
ERP Administrative
Information System
Self-Service Functions
(Administrative users,
faculty and staff)
Addressing Organizational Issues
• Other units such as Library (information
common), Instructional Support (mainly
online these days) use IT extensively.
• Home-grown system used in Instructional
Support
– Leads to ongoing integration issues.
– May not be a big issue if good third party
products are used.
• Need to involve them in the overall planning
• Prepare University electronic portal. This links
ERP with the rest (Users access all services
with one password)
Operational Issues
• Three main user groups: students, faculty,
administrative staff
• Address their needs separately (concerns are different)
• Reluctance to change over to new system
– comfort zones and use of Shadow systems
• Organize separate open forums and training sessions
for each group
• Inputs from these groups at each stage of the project.
• Two IT connection groups (students, Faculty & staff)
• Increased user responsibility (the user units maintain
rules tables)
• A user service director within ITS to handle all these
Implementation
• Several parallel activities took place (not in shown):
• Data Conversion
– Banner has open database connectivity (hence painless)
– Shared responsibility between user and system provider
– ITS (through user) provided data ina format specified by Vendor
and Vendor provided software tools for populating the database
• Customization (took a plain vanilla approach)
• Training (creation of three environments; customized)
• Change Management
–
–
–
–
No need for mainframe operators & software specialists
Need personnel in client-server environment
More personnel in customer service
Retraining opportunities to retain employment
Post Banner Implementation
• All modules in use; no rollbacks at any stage
• Third party products are being implemented since 2006
– Facilities management (TMA) , Parking (BossCars)
– All integrate well with Banner
• Banner upgrades (first migration to Release 7)
• In Fall 2009 to Release 8
• No formal review as yet.
• Addressing system enhancement (changes and new
features): use PL/SQL and some C as well.
• Working with ITC these have requests were prioritized.
Lessons Learned: Potential Risks
• Starting without some sort of financial justification
• Allowing infrastructure to be user department’s
responsibility
• Ignoring heavy IT users (having their own IT sub-units)
• Assuming data conversion is easy
• Not getting sufficient buy-in from important user groups
• Including heavy customization (examine the business
process before deciding on them)
• How UIs work may not be ideal (some may take more
than the standard three)
Lessons Learned: Success factors
• Work with ITC and share the responsibility
• Prepare an overall architecture then scope projects
• Choose the appropriate timing
–
–
–
–
To start project: when funding is not a major constraint
For releasing different modules
For mock student course registration (controlled group)
For training different groups
• Involve users and user reps in decision making process
• Ensure continued support from Administration
• Essential to have or recruit an experienced person (has
implemented ERP before) to lead the project
• Create opportunities for retaining IT staff.
• Go for plain vanilla; gives you better control
• Implement the base system first then consider third parties