 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 is going to 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. 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 is going to 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 finances. It's not what they're used to. I mean they're 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. For me personally it was to make sure that everybody in the functional departments understood what they're going to get into. 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. We thought reporting was easy in this new system. The 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. Functional team cannot do reporting. It still has to be IT that does the reporting. This is something that I would start early on to start thinking about it, getting people ready for it and then have the 20% of the reports that 80% of the time people use ready. When you launch it, it's immediately useful for the end user. We looked at best practice across the board and we started with that rather than going and replicating what we had, which was a system that was set up in 1999 for us. It was partially successful, to be honest, because it's basically the folks that have done this for a long time. But we evolve. When workday says it's going to be X amount of months to get this implemented, double it. We did it in 18 months and it was 18 to 20 months for everything. HR, finance, and it was a complete redo. 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 that's not the ideal way to do it. So I would double the time frame of whoever is telling it, if the implementation group or the workday or whoever is telling it, double it, because that's very critical and useful. The security structure set up is very, very complex. And the thing that we did was 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 implications to how the business processes are set up. Because each role and each action has a role that has implications to who has access and who sees what has implications to what report. So if I give you a report and there are fields in that where your role is not authorized to see, your report is going to 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 how 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 meetings 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 needs to be set up.