The following interview is with Brian Parish, president of IData. Parish recently spoke with Inside Higher Ed about some of the challenges postsecondary institutions run into when undergoing major systems changes. In this interview, Parish discusses those challenges and shares his thoughts on the differences between roadblocks to implementation and areas that require institutional change management.
1. When implementing a new enterprise resource planning (ERP) system at a higher education institution, what are the most common challenges and problems that arise?
Things have changed over the last five or six years in terms of how people approach an ERP implementation. We’ve seen it in our business and our interactions with schools and I think most schools would recognize this as well. …
What we would see a decade ago is that people would buy these systems … either from a homegrown or another legacy ERP system and purchase a major off-the-shelf product and go through an exercise where they would come up with a gap analysis between what that product does out of the box and what they want it to do at their college. Then, [they would] spend a very large amount of money and time and effort to customize that product to fit their need and it’s a bit of a common refrain that you hear in higher [education], where people say, “We are unique. Our institution is unique.”
It is true that every institution is unique. But they’re all running very similar businesses.
What’s happened in the last five years [is] … schools have learned to say no to their users around customizations. When schools are implementing a system like this, they’re looking for efficiencies, cost savings and ongoing support cost production. Their real push these days is to … look for opportunities to use that system effectively in a vanilla or as-written way.
Sometimes that’s possible and sometimes just having that frame of mind helps you find ways to use that system that you might not have been willing to look at. …
One of the biggest challenges that arises is saying, “How do we apply this product — this off-the-shelf product — to the way we do business and how do we avoid the high cost of customizations and maintenance of customizations to use the product effectively as written?” That’s a change. To do that effectively, you really need very good project management, which often times is an underinvested part of any implementation of any ERP product. That needs a decision maker and a process and documentation and artifacts that come with a well-run project to make sure everyone’s requirements and needs are being met … and managed effectively to budget into timelines.
2. Reflecting on these challenges, how do you differentiate an implementation roadblock from an area requiring institutional change management?
The important thing is to not look at the way you did things before — and make sure that the new system does things the exact same way — but to look at the outcome. [Institutional leaders] need to say, “What was the outcome that we were accomplishing before? What was the business need that we were solving with our previous process and how can we solve that same business need and have that same outcome with this new technology?”
The process may change, the steps may change, the people may change in terms of who’s involved in the workflow or who’s doing it — several things may change. But if the outcomes are still the same, then you can do an institutional change management around the process as long as the outcomes [stay the same].
When you find that you cannot get the same outcomes, that’s when you have to say there’s an implementation roadblock. …. In that case … there are several different routes to take to try to resolve that roadblock in partnership with the vendor and your implementer.
The main thing is to focus on outcomes as opposed to process because sometimes there’s lots of ways to get to an endpoint and that’s what’s important.
3. What tend to be the biggest issues in convincing institutional leaders of the difference between roadblocks and areas requiring change management and training?
When I talk about budget, there’s two big things that happen in an implementation; there’s obviously the financial budget, but time is a big problem. I’ve been involved in many ERP implementations and there is, without fail, turnover that occurs during a process like that. Some people will tell you that turnover is because people don’t want to learn a new thing or they’re hesitant to embrace the technology and they look for an opportunity to leave. I would actually say these projects are hard and many times if it’s 18 months or if it’s three years or if it’s even more, many people who are closely involved in this project — your heavy IT users, your business office and administrative people who are involved in both implementing the new system and making sure that the existing system continues to run — are a lot of times being asked to do two jobs for the same amount of time. … That’s a difficult thing to do over that time; and stress and heartache do persist over that implementation.
Convincing your leaders about dealing with this is about saying, “How can we make this change easy for the people who are going through this process?”
People who are implementing the system are already taxed and if you ask them to make a thousand changes or to do things differently it can be really difficult. But, in the long run, it’s going to be a benefit to the organization and to those people to find solutions within the system as opposed to necessarily going down the road of customization. The other budget thing [is] you can always get additional support either to back-sell your existing team to do their day-to-day job or to augment the implementation team.
The other big challenge you have … is that people don’t always know what they want until they’re using the system. … Sometimes, you’re seeing things as roadblocks that aren’t because you don’t have clear requirements or [are] ignoring problems that turn out to be issues that you don’t see until you get to production. That’s a big thing, making sure that you have the ability to give well-documented requirements.
The other big thing is testing. A lot of times these projects can be so large and have so many delays. … On these projects, timelines often flip and then you end up at the end of the project having, usually, three things thrown under the bus of the timeline. Testing; [it] is always a problem to get rid of that. Reporting; that’s another thing that people tend to leave out until the very end. … And system integration is the other one that’s often left to the end. There are some key system integrations that people don’t forget about — they want to make sure payroll runs and all these things — but most of the time schools now have a growing number of systems that they run on campus … and they all need to talk to the enterprise application. The system integration around those, the reporting around not just the new ERP data but how it works around the data, and then the ability to test the entire system and all those connections and reports, together, often suffers from the timeline constraints and compromises that are made in terms of what gets done in the timeline.
4. Is there anything you’d like to add about the differences between a roadblock implementation and an area that requires change management, and ensuring institutional leaders understand the value of internal training with major system changes?
Reporting is an area that my company, iData, deals with a lot; general data management. We have a saying: “Institutional reporting is not a technology problem.” What we mean by that is that you can do a perfect technology implementation of a reporting project. … Where those projects can fail is in the people problem.
Do you have well-defined definitions of what type of data you’re trying to pull? Do you know exactly what questions people are trying to answer from the data extract? Do the people who are going to look at this data trust the information? Do they trust the process of the whole project? Once they get this information, do they have the knowledge base or documentation to understand what was given to them?
Those pieces of a reporting project — dealing with requirements and definition and governance, in terms of ownership around the process, and then transparency after the fact — help build trust in the outcomes. There may be problems with whatever is being delivered, but if there is communication, documentation, transparency and trust, those problems can be resolved.
If there are no problems and you do something perfectly and you don’t have communication, documentation, transparency and trust, it’s still going to fail. With any implementation process, I highly recommend focusing on those people problems of communication, documentation, good requirements, transparency in the process and then some sort of reference for people to go back to.
I believe that process will resolve many roadblocks and will help them in decision making between what might be an actual technology problem or an actual data problem … and what might just be a misunderstanding or lack of trust in the process.
You Might Also Like
