Main Nav

Hello,

We have a policy of not modifying baseline code in our ERP system (we're running Banner).  We're often asked to provide functionality that would necessitate core code changes, and we explain that we have a policy against it, and why. Typically, cost avoidance is the most compelling argument we advance.

What I don't have is hard, quantitative data to support our contention that modifying baseline code imposes real costs on the organization; everyone agrees that this must be true, but we don't have the numbers to back it up. Lately, we've had serious inquiries from higher up the food chain about the costs and considerations involved in changing our policies; they're willing to accept the added cost and risk, but they'd like us to quantify them.

Can anyone point me toward studies, surveys or other data to help me quantify the potential costs and risks involved in modifying delivered code? Comparisons of IT development staff size for similar institutions with dis-similar polices regarding baseline code modification would be perfect, but I'm open to suggestions on how to advance a defensible case.

In the absence of studies, I'd love to hear from institutions of similar profile to EMU (regional public with approx. 23,000 students) about your policies, extent of modifications you've made, size of your applications support group, IT budget overall, added governance structures, etc.. Anything you're willing to share will be gratefully received and held in confidence.

Thanks,

Robert Goffeney
Senior Director, Enterprise Systems
Eastern Michigan University
rgoffene@emich.edu
734-487-3428

********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.

Comments

I would be interested as well in this information

 

Thank you

 

 

Wm. Kenneth Freeman

 

Wm. Kenneth Freeman, VP-CIO

Webster University

470 E. Lockwood Ave.

St. Louis, MO 63119-3194

Phone:   314.246.5990

kennethfreeman@webster.edu

http://www.webster.edu/

 

 

We have a rule that modifications are outsourced since we cannot manage the multiple upgrades each year and also reapply the modifications.  Any exceptions are authorized by the university president, due to the resources involved, and the work is outsourced, to avoid having staff whose jobs are groundhog day (get up, reapply the mod, go home).

That said, our president authorized one modification, and following the rule, we outsourced it.  The current bill for the one process modification is over $40,000 per year.  Interesting in that the vendor originally thought $23,000 a year, but after 3 years found they were losing money on the maintenance, and the next renewal came in at the $40,000 amount.  The costs are not just time.  The costs include:
  • Doing research into what is needed and when it is needed.  Our mod involves financial aid, so there's the constant watching of, and analysis, of federal guidelines.
  • Development licenses and tools, including versioning platforms.  Our run-time only environment can skip all that.
  • Development databases, development DBA time and support, storage and such.
  • Training on development tools; maintaining an ERP and developing enhancements may involve different staff skillsets, necessitating different training budgets.  After years of working on a heavily modified ERP, and now years of running a vanilla ERP, my experience is that you need different skills sets on your administrative systems team.
  • Timing.  You have to wait for the ERP upgrade to be released.  Then you can analyze and reapply the modification.  In the case of financial aid, this could delay your ability to start the new aid year in February.  We pay the premium to have the modification released closely with the ERP upgrade.  When we used to modify financial aid internally at the university in our old ERP, there were times when the university had to budget in extra staff to handle a change manually until we could rebuild the modification.  You need to build in those backup costs to accommodate timing issues. 

Theresa


A lot of us have been looking for a long time for some good metrics or ROT (rules of thumb) for the total cost of ownership for a modification to an ERP package. We usually have to make some guesstimate for the long term cost of continually tripping through our mods and comparing them to vendor patches/updates.

 

This blog posting provides a pretty good overview of the cost areas to think about when you create the business case for mods. You might want to ping the author to see what numbers he may have found. Having read his blog for a while, it’s also a pretty source of good things to consider with our ERP systems.

 

ECAR – are you listening? Want a new topic that we all could use?  8-)

******************************************
Charlie Moran
Sr. Partner & CEO

1215 Hamilton Lane, Suite 200
Naperville, IL  60540
Toll-Free (877) 212-6379 (Voice & Fax)
Website: 
www.MoranTechnology.com
******************************************
P Please consider the environment before printing this email...

 

Hi, Charlie, yes, ECAR is listening. This is a tough area to study and provide truly useful information. If you're too general your findings will simply be the common sense that everyone already knows. Too specific and you'll wind up with, say, a median cost with a huge standard error (+/- 80%, anyone?) . That said, I've been following this thread with interest, because we actually are in the midst of seeing whether we can mount a careful, initial study of ERP cost drivers. More to come — I hope! — in a few months. Sincerely, Susan Susan Grajek Vice President Data, Research, and Analytics EDUCAUSE Uncommon Thinking for the Common Good 1150 18th Street, NW, Suite 900 Washington, DC 20036 direct: 202.331.5350 | main: 202.872.4200 | educause.edu
Susan, One possibility here would be for ECAR to help us define a protocol for campuses to use that would begin to get at this data and allow us to compare apples to apples so to speak. Obviously, the hard part of this is campuses have to track time at the individual level across a number of areas, many outside of IT, to get an understanding of these costs but it would be important data. Saying that, if ECAR helped define standard methodologies it would at least allow those that participate to compare results at the end. Whether ECAR helped analyze those results could be determined by ECAR and it's work plan. I would guess if we were willing to follow a standard protocol we might even find masters students at our institutions interested in reviewing the data and using it for a masters thesis or class project that we could leverage. As usual, Theresa's post was most enlightening. It does highlight that one way to get a rough cost estimate is to consider putting the customization work out to bid and see the cost. Jack Suess UMBC Division of Information Technology (DoIT)
Thanks, Jack. The study we’re doing is part of a collaboration with CAUDIT, who invited us to participate in an ERP cost drivers survey they are doing. Several countries are participating. We’re taking their survey and augmenting it with additional questions to get more detailed information from US institutions. Your suggestion is quite relevant to both ECAR and to a direction we’re taking with the Core Data Service. We want to identify key core metrics for IT and work with members to define those metrics in ways that are feasible for and comparable across institutions. The metrics will become part of the Core Data Service content for institutions to use in benchmarking. ECAR helps research the issues and explore the findings, resulting in stronger Core Data content and some very useful ECAR research. Your notion of standard methodologies and protocols for defining, gathering, and reporting data is foundational to this work. Right now we’re doing research (using multiple methods) to try to identify some key core higher ed IT metrics to start with. I’d welcome ideas from anyone with a strong interest in this area. Of course job number one with the CoreData Service is reinstating the reporting tool. I’m pleased to say that we’re making great progress with that work and expect to release the tool this fall, as we'd hoped. Susan Susan Grajek Vice President Data, Research, and Analytics EDUCAUSE Uncommon Thinking for the Common Good 1150 18th Street, NW, Suite 900 Washington, DC 20036 direct: 202.331.5350 | main: 202.872.4200 | educause.edu From: Jack Suess > Reply-To: EDUCAUSE Listserv > Date: Saturday, September 1, 2012 9:08 AM To: EDUCAUSE Listserv > Subject: Re: [CIO] ERP customization metrics? Susan, One possibility here would be for ECAR to help us define a protocol for campuses to use that would begin to get at this data and allow us to compare apples to apples so to speak. Obviously, the hard part of this is campuses have to track time at the individual level across a number of areas, many outside of IT, to get an understanding of these costs but it would be important data. Saying that, if ECAR helped define standard methodologies it would at least allow those that participate to compare results at the end. Whether ECAR helped analyze those results could be determined by ECAR and it's work plan. I would guess if we were willing to follow a standard protocol we might even find masters students at our institutions interested in reviewing the data and using it for a masters thesis or class project that we could leverage. As usual, Theresa's post was most enlightening. It does highlight that one way to get a rough cost estimate is to consider putting the customization work out to bid and see the cost. Jack Suess UMBC Division of Information Technology (DoIT)

Sorry! I forgot to paste the link to the ERP blog!

 

http://gbeaubouef.wordpress.com/2012/01/29/business-case-for-erp/

 

Thanks!

******************************************
Charlie Moran
Sr. Partner & CEO

1215 Hamilton Lane, Suite 200
Naperville, IL  60540
Toll-Free (877) 212-6379 (Voice & Fax)
Website: 
www.MoranTechnology.com
******************************************
P Please consider the environment before printing this email...