Saturday, September 24, 2005

The relative importance of keeping score

Its been a while since I talked on the blog about the Student Information System (SIS). As you know, its a central component of the scorekeeping system here at ASU. The scorekeeping system includes Finance, HR, SIS, DARS, the Data Warehouse, and all the other data stores in Dickson's Database Diagram. These are the systems that let us keep track of who's who and what's what; how much we spend; who gets what grades; what classes are offered next term. You get the idea. Important? You bet. Absolutely vital. Can't play the game without a scoreboard; the match would be chaos without referees.

But as important as this function is, the scoring system isn't in any sense strategic. No student is going to choose ASU because of the student administration sytem that we pick. NSF won't select ASU to lead an ERC because we have a state of the art ERP (aren't acronyms great?). See "Good Enough! IT Investment and Business Process Performance in Higher Education" for more on this line of thinking.

So why are we even talking about the SIS now? If it isn't strategic, and it ain't broke, why fix it? And why now? Well, this is how the argument goes for me...


  1. In the considered and expert opinion of its authors and maintainers, the University's core information system, the Student Information System, simply does not have the flexibility to meet the needs of the New American University. While not strategic in and of itself, it is acting as an impediment to implementing things like differential tuition and flexible scheduling that are strategic.

  2. The only other user of ASU's SIS system, Northern Arizona University, has already experienced a failure of that system, and as a result, abandoned it in favor of an industry standard ERP solution from Peoplesoft/Oracle.

  3. The university is not prepared (nor should it be) to modify its enterprise goals and strategies to continue to fit within the confines of what the existing infrastructure can accomodate.

  4. Given the foregoing, a new system is inevitable for ASU. It is only a question of when we start, how long it will take, and how much it will cost.

  5. There are no serious alternatives to a vendor supplied system. No champion has come forward with a vision for internally writing a new system from scratch or radically rewriting the current system.


Based on this set of facts, I'm convinced that ASU should implement a vendor supplied solution that removes the scorekeeping system as an obstacle to change subject to the following criteria:

  • we want the lowest risk we can find.

  • we want the lowest cost we can find.

  • we want the fastest implementation we can find.


If the scorekeeping system is not strategic, then the goal is to remove it as a constraint as quickly and as cheaply as possible, while minimizing the risk of failure.


va·nil·la (və-nĭl'ə) adj.

  1. Flavored with the flavoring extract prepared from the cured seedpods of any of various tropical American vines of the genus Vanilla in the orchid family, especially V. planifolia, cultivated for its long narrow seedpods from which a flavoring agent is obtained.

  2. Lacking adornments or special features; basic or ordinary: “We went through a period of vanilla cars” (Charles Jordan)

  3. Implementing a full featured ERP product that has proven its ability to run a University by customizing the product as little as possible and instead adapting the business processes to match the software's capabilities.

  4. The fastest, lowest cost, least risk method for implementing an ERP.


rocky road - (rŏk'ē rōd) adj.

  1. A common ice cream flavor. Though there are variations on the flavor, it generally combines vanilla ice cream, chocolate ice cream, marshmallow and nuts. The flavor was created in 1929 by William Dreyer during the Great Depression "to calm jitters."

  2. A rough and difficult path, a metaphor for any challenging and uncomfortable journey.

  3. Implementing a full featured ERP product that has proven its ability to run a university by convening committees to redesign, usually on paper, the business practices the software supports, and then implementing these newly redesigned procedures through the use of custom code that overrides the base functionality of the product.

  4. The slowest, most expensive, highest risk method for implementing an ERP.


After talking with CIO's from around both the higher education and commercial communities, and reading the histories of failed and problematic implementations of ERP systems, I know what my favorite flavor is.

Several commercial product offerings have been successfully deployed to run Universities comparable to ASU. Among these are clearly SAP, SCT Banner and PeopleSoft -- perhaps one or two other serious contenders. Reasonable people certainly would differ on which product they preferred on a feature/function basis. In the end none of them is a clear winner. Each company's product has strengths and weakenesses. Each of the products is configurable to overcome those weaknesses. Each product has been involved in both successful and failed implementations.

In the end the choice is not about the features of the product. That would be a "please all, please none" discussion. So, in the normal course, an ASU selection would hinge on price and confidence in the outside members of the implementation team.

I say the in the normal course because there is an opportunity outside the normal course that promises to provide a clear winner in terms of cost, speed, and risk -- a vanilla implementation of NAU's Peoplesoft based Student Administration and HR System (SAS/HR) -- call it Regent's Vanilla.

What makes Regent's Vanilla so attractive? Well the NAU SAS/HR system was developed from a system with common roots to the ASU system. The organization that developed it, NAU's IT team, has an excellent working relationship with the ASU team. Regent's Vanilla has been in production successfully for 3 years, and has proven its ability to successfully run an Arizona Regents University.

If we implement the NAU system with the minimum set of changes possible (and defining that minimum is the key of course), what good will it do us? Well, it will be the fastest way to implement a new scorekeeping system that doesn't act as a gate for the go forward. It will also be the cheapest way, if for no other reason because development costs will be lower. And it will present the lowest risk, from a technical point of view, because it's already proven to work in the closest real time production environment to our own.

So what's the rub? Well, implementing vanilla means changing procedures, which is never popular and sometimes unwise. We're going to have to decide on this as an institution.

But the advantages of this approach make it something we at least have to aggressively look at. So, ASU and NAU are at this moment working out a cooperative agreement to get ASU a working copy of the NAU system that we can populate with ASU's academic structure and branding. Once its up, we can use to evaluate the procedures to see if we can live with the changes. We're shooting for the end of the year for the test system to be up and running.

This is not the end. It isn't even the beginning of the end. But it might just be the end of the beginning.

More on this later, but wanted to let everyone know that the ball is rolling. Watch the Administrative Technology section of the wiki for more information on how this strategy is coming together.

1 comments:

Jon September 26, 2005 at 6:55 AM  

I like it!

This works well on several points:

- NAU has finally gotten the system strapped down and working (insert "Giddy-up!" here) and from what I hear are quite happy with the outcome.

- We Have Max Davis-Johnson (Max Directed the NAU Peoplesoft implimentation/Support team until just recently.... I wonder if Max still reaches for his warm coat in the morning out of habbit...)

- NAU has (or HAD) a very similar business model to ASU's.

- We get the benefit of "been there done that", without making the same mistakes.

- The reporting tools are good.
- The system can be extended.
- Greater scope of technical support (more of us know and can maintain the system).

Jon