A couple of years ago, I was back on the East Coast working for a nonprofit study abroad organization. The organization aided college and high school students working and studying abroad, with kids going in both directions - US students visiting the world, as well as students from other countries visiting the US.
Our system for managing all the moving parts of these programs was outdated and we found ourselves inventing ways to get it to work for our needs. The original system worked off of an office-based server, so migrating solutions meant moving to a cloud-based system. Additionally, we were changing from many accounts used to track every revenue and expense for each department, program, location, and time of year; to few accounts with the department, program, location, and time of year getting attached to one account as separate fields. This new way to organize had some pushback from the accounting team and the department heads - this was mainly due to the need for relearning a different coding system - the new solution used words while the old system had numbers representing those words.
Our system was tied into an online “store” - i.e., students could sign up for classes online. Previously, the code to link the location, semester, and program to the online store had to be written in-house. The new system would need to link to the same store, but trigger similar (yet new) sales instances and fields. Testing had to be done both with the link between the two systems and with how the new system translated data.
The software vendor we were moving to did not provide much in the way of assistance or training. We needed to learn the software as best we could without much oversight, while also testing the linking capabilities that were necessary to keep the link between our software and the “store.”
The new system was chosen mostly for its reporting capabilities, so we needed to set up a number of procedures at the beginning that did not use the software’s full potential. But, by using our own team’s curiosity, we were able to find ways to use system functions that made our positions easier.
In the beginning, we used very canned reports. But the increased capacity of the new system to record details meant that, after some internal training, we were eventually able to create much better reports. This capability allowed us to recognize revenue with the push of a button. Previously, it had been a series of manual calculations to get the correct entries figured out. We then needed to enter those into the system...increasing the chances of human error. If there was an error, it was tough to untangle. The new system allowed us (if we noticed an error) to simply roll it back with the push of a button and redo. Although the capabilities of the new system would give us much better processes in the long-run, it also presented many difficulties we hadn’t anticipated for our migration and implementation phase.
We ended up having to do the implementation twice. The first time we did it with a new employee as the project manager. It turns out, this employee didn’t know the software as well as advertised and didn’t know the company as well as a more seasoned employee might. This was also a challenge because they did not have the experience to implement ideas or address concerns about how things were, or might be, set up.
A large issue that arose, was that the company was worldwide, but business was mostly done in US dollars and recorded this way. The migration data was converted to local currency for revenue, however, the calculations were incorrect leaving many accounts out of balance.
The other reason for reimplementation was that the old system had less detail within each transaction. When revenue was recognized, the new system used the new amount of detail. This left gaps in data and strange balances in accounts, as items did not match up. One of my final projects prior to joining the Foundant team when I moved back to Montana was working to undo these calculations and correct the data gaps. Good thing I have an accounting degree and enjoy systems management!
There were team members who were worried the new workflow would be more difficult than what they were used to - the old way was so ingrained, it was like autopilot. It was difficult at first - learning a new system, is like relearning your job - but, eventually, this new way becomes your autopilot method.
When I joined the Foundant Team as a CommunitySuite Client Success Manager, it was a perfect match. I had already gone through switching systems with little to no support, so I knew what it was like on the other end. I understood the fears and frustrations that trying to migrate data (especially financial data!) creates for a team.
Understanding the “four P’s” in situations like this is essential, and working with a company that understands this as well is even better. Knowing your People, Processes, Product, and Project Management when you’re making a system change will (without a doubt) make your migration and implementation easier and more successful.
Key Takeaways and the Four P’s:
People: Understand who is in a position of enough experience within your organization to recognize roadblocks and be able to see the big picture...thinking seven steps down the road, and not just what’s next.
Processes: What processes need to be in place for your migration and implementation to be successful? What old processes need to stay the same, and which ones will need updating? Document these.
Product: Understand both your old system and the new. If you’ve done your homework, it should be easy to say why you’re moving systems. What did the old system not help you accomplish that the new system will?
Project Management: Outlining your migration and implementation, managing expectations, and keeping an eye on scope creep are all essential to a successful system change. Managing change such as this is a big undertaking. Don’t be afraid to ask the vendor you’ve chosen what kind of project management experience they have and how they’ll be able to help with this process.