Barriers to Enterprise Standardization

The following excerpt is based on an interview conducted at the EDUCAUSE Enterprise and Information Technology Conference 2011. To listen to the full podcast, go to <http://www.educause.edu/er/WilliamAllison>.

Gerry Bayne: You recently delivered a presentation entitled “Breaking through the Barriers to Enterprise Standardization, Without all the Pain.” Let's start by talking about that pain. What are some of the barriers to enterprise standardization?

William Allison: In many institutions, part of the barrier is historical. For example, the first payroll system came to the University of California, Berkeley, in 1976, and the argument was about being able to standardize on a monthly pay versus a biweekly pay. The company that was working on that project was founded by Dave Duffield, who also founded PeopleSoft and has reappeared lately with Workday. So the history matters, and that burden of history remains with us. Then there's also the cost of changing systems.

We are universities. We're not corporations, and we do have some truly unique processes. For example, we hire rocket scientists at Berkeley. That is not the norm. Rocket scientists’ resumes are 100 pages long. Those exceptions are real barriers. There are also more cultural factors. Often in the past, software was marketed as “no change required.” In other words, the organization did not need to change at all because the software was infinitely malleable. That has led to cultural barriers, since people are not used to having to rethink the way they do business.

Bayne: What were some of the standardization issues that Berkeley ran into with its ERP roll-out, and how did you solve those issues?

Allison: We're still solving them. We introduced the first enterprise?wide system in 1976, although in those days the software was designed; it wasn't off?the?shelf. There was a grassroots effort among administration to get an ERP launched, and at that time, the original premise of ERP?type software such as PeopleSoft was that the institution could bypass the IT department, same as we talk now about the cloud bypassing the IT department. The institution’s administrators realized they could bring in PeopleSoft on PCs and walk them right past the IT department.

One of the issues we ran into during the mid?1990s was that ERP software wasn't mature. So the way we did customizations wasn't as well thought through at the time, and the process refinement was not as involved. There was a process called fit/gap: you looked at the requirements of the organization, you looked at the functionality delivered by the software, and then you looked to see where the gaps were.

Today, when you accept this kind of software into the enterprise, you would probably change your organization rather than modify the code.

Bayne: Why is that?

Allison: Because creating a lot of modifications to the software results in an ongoing burden that has to be maintained. There are definitely cases when that is needed, but not all the time. People's jobs and the tasks they do in their jobs are a part of their identity. Today many people realize that change is the norm. The tasks that I'm doing today I don't expect to be doing next year. But if employees aren’t looking at their jobs through that prism or lens, they may think that the change is a reflection on them. An employee may think, “Oh, my job is unimportant now.” That is a significant barrier to overcome.

Bayne: Is there a danger of software companies saying, “This is what you get: change your organization”? Can that become a vicious circle?

Allison: I think we need to have the competency in our organizations to carefully look at where it would be appropriate and beneficial for us to change in order to save money. And that's true whether we're going to install a Kuali package, whether we're going to use a software?as?a?service vendor, or whether we're going to install commercial off?the?shelf software.

Bayne: Do you have advice for other departments and institutions facing some of these issues?

Allison: One lesson we learned is that we have to do enough outreach and communication throughout the process that all of the stakeholders are consulted.

Berkeley did a study on funding and governance in 2006. One of the conclusions was that the units that operate the financial system or the HR system or any of these systems are represented better than some of the departments and other constituencies, so we're doing a lot more outreach now to pull people in.

Higher education has a judgmental culture. One of the biggest lessons we've learned is that leadership needs to be more agile. We need to make faster and better decisions. Our typical anti-pattern is that we try to reach a decision, but we feel that it has to be the right one. We're very afraid of making a wrong decision. So then we do a lot of analysis, and we try to gather a lot of information. The end result is that even though we take a long time, we're often still not comfortable that we’ve reached a good decision. The decision is delayed so long that finally the project is running late and we make a snap decision, because the folks involved are saying: “Make any decision—we'll take it.”

Bayne: And also the technology can change during that process. So even if the decision was supported by the evidence initially, it might be the wrong decision now.

Allison: That's right. The pace of change has accelerated rapidly and has expanded to many dimensions, meaning that the technology is changing very rapidly. The nature of how we do business with one another and the demands of our students are evolving.

At Berkeley, the big thing we're working on now is looking at the staffing organization that we have today and then looking at what the model is for the future. The way that we're talking about this is: demand, design, and delivery. Right now, we have 42 people who work in demand management: project managers and program managers who document the nature of the problem we're trying to solve. We have 46 people who work in the design of the solution. And we have 696 people who deliver services: network engineers, system administrators, coders. I jokingly refer to this as the “ready, fire, aim” organization. It's not that that the people aren't smart; it's just that we don't have the right balance of staff involved in the different aspects of providing IT solutions. The reshaping of our IT organization involves having 25 percent of the staff documenting the demand, 30 percent of the people working on a detailed design, and 45 percent actually delivering the solution.