In 2016, the New School completed an enterprise resource management implementation.
Anand Padmanabhan: Implementation was for HR, finance, payroll, and time and absence. We went with Workday as a solution for those products. The traditional way of doing ERP is you have a group of people that go off, hear what's needed to be done, that go off and do the stuff. People wait for eight months, nine months, almost a year to see even the first vestiges of what the new system's gonna look like. Compared to the new paradigm wherein it's agile. So within 30 days you see some of your own data in the system and the big change is also how there's no coding. It's more on the business process.
1. Involve Everyone
Anand Padmanabhan: We took almost a year to really pick the product. And the reason we did that is we wanted to make sure that we included every single person within the functional group to see what the new product's gonna be. Everybody, I mean starting from the entry level person in HR all the way to the vice president for HR and the same with the finance. It's not what they are used to. They are used to telling the IT department, "Oh we need to make this change and that change," and then the IT department makes the change and then they go ahead and do it. So we wanted, for me personally, was to make sure that everybody in the functional departments understood what they're going to get into.
2. Begin the change management process early.
Anand Padmanabhan: The day we started implementing we had a change management team in place and probably about two or three months into the implementation we started informing the community. Across the community- this change that's coming forward in a year and a half, be prepared, here's what it's going to be. You see iterations of these things coming up quickly, you can actually show the end user what it's going to be like with their own data.
3. Establish reporting methodology even before rollout.
Anand Padmanabhan: We thought reporting was easy in this new system, that users would be able to create their own reports and do the stuff. It's not easy. That's one big drawback that I would say from a Workday perspective: the functional team cannot do reporting, it still has to be IT that does the reporting. So this is something that I would start early on, to start thinking about it, getting people ready for it and then have that 20% of the report, that 80% of the people use, ready. So when you launch it, it's immediately useful for the end user.
4. Abandon old practices for new ones.
Anand Padmanabhan: We looked at best practices across the board and we started with that. Rather than going and replicating what we had, which was a system that was setup in 1999 for us. It was partially successful, to be honest. Because, I mean, there are still, it's basically the folks that have done this for a long time. But we evolve.
5. The process will take more time and energy than you think.
Anand Padmanabhan: When Workday says it's gonna be X amount of months to get this implemented, double it. We did it in 18 to 20 months for everything. HR, finance, and it was a complete redo. And it burnt a lot of people. Both from IT functional, all the functional groups. We didn’t have enough time for UAT, the User Acceptance Testing. It can be done, but it's not the ideal way to do it. So I would double that time frame of if the implementation group or Workday, or Oracle, whoever is selling it- double it. Because that's very critical and useful.
6. Involve your security team from the beginning.
Anand Padmanabhan: The security structure setup is very, very complex. And the thing that we did is we thought, well nobody had talked to us about security being an issue and setting up the security being an issue. So we kind of deferred it towards the tail end of the project. And setting up the security has immense implication to how the Businesses Processes, are setup. So each role and each action has a role that has implications to who has access and who sees what. It has implications to what report. So if I give you a report and there are fields in that that your role is not authorized to see, your report's gonna be empty. So you need the data to do some decisions, or you need the data to do your day-to-day job, but then you have an empty report. So thinking through security, the architecture, not the technical architecture, but the architecture of security: the roles and groups and domains and all that stuff. Very early on have a security person, like the change management team, have a security person involved and sitting in every single business process meeting because they need to understand what roles and-- It's not who the person should be, but what are the roles, what are the domains, and what are the groups that need to be setup?