Strategy
“We didn’t know how good we had it.”
A prominent university rolled out a new enterprise software system to replace an aging homegrown legacy system. By many conventional measures, the project was "successful."…
Strategy
Enterprise software is so much more valuable than only the data stored in it. Institutional knowledge is deeply intertwined with the software used to run universities.
Picture this: you are the CIO at a medium-sized university, and several years ago you implemented a Student Information System (SIS) from an external vendor. It works great! It’s redefined how your staff operates, allowed you to grow your team by 5x and created consistent implementation of your university’s policies. It’s been a total success for many years.
But then you hear the news: the vendor was acquired by a larger company, and the product that has served your university so well is being deprecated at the end of the year.
Luckily, you did your due diligence and selected a fair vendor who believes you should own all of your data. They don’t want to hold you captive, so they provide the ability to download all of your data, in any format you like: HTML, XML, PDF etc. So, you export the data … and then what?
You’re looking at this huge stack of files, everything you need to continue to run your university—except it’s not.
What you’ve uncovered is that your institutional knowledge is much more than the data that was in the system. It is the combination of the way the software worked, plus the endless configurations you made to the software to perfectly fit your university—the data itself is essential but not the whole.
Over the years, you’ve intertwined the institution with the software. You adapted the institution to its workflows. You built your processes around it, and it was really efficient.
But now, as you’re trying to figure out how to proceed after having lost the software and configurations that had all of this institutional knowledge baked into it, it’s important to remember that you didn’t do anything wrong. Having this entanglement with your software isn’t a bad thing. It should be this way. After all, it would be really expensive and inefficient to try to prevent your institution from intertwining with its software products. Developing processes outside of software would cause a perpetual documentation nightmare.
Having gone through this heart-wrenching realization, you’re coming out stronger for it. As you’re making the decision around choosing your next Student Information System, you understand the commitment the institution is making to the software. When the next vendor comes along and says “All of your intellectual property is yours!” you can read between the lines and realize that your IP is not terribly useful unless it’s in the context of their software. You can understand the impact of losing their IP in the event of an unplanned breakup.
So this time around, owning the Student Information System software looks a lot more appealing.
A prominent university rolled out a new enterprise software system to replace an aging homegrown legacy system. By many conventional measures, the project was "successful."…
Universities ask the vendor during the purchasing process, “does your software support [this unique need that my university has]?” The vendor has to either figure…
The word “home”. It’s inviting, familiar, and comforting. But in certain contexts, it can take on a somewhat negative connotation. This includes in-house software within…
The first step is often a zero-pressure phone call to answer questions and explore whether we both feel that there could be a fit.