This summer I attended a Workday partnership event where I had the pleasure of meeting Petros Dermetzis, Executive Vice-President of Development at Workday. He spoke to us about the birth of ERP applications, how they evolved over the years, and what happens when vendors can start over in the cloud. On the topic of updates, Petros mentioned that in the past, Workday brought out 4 updates per year, for maintenance and to enrich the system with new functionality. They’ve now slowed it down to 2 as most customers can’t keep up with the pace of change.
Switching to a lower release frequency is a natural consequence of the system being more mature and having less need for major updates that introduce new functionality. What was illuminating was that Petros told us that in the background Workday continuously applies updates (every weekend), while new functionality is pushed to clients in the form of a “twice a year release” because that is in line with expectations. New features are disabled by default and must be switched on by the user – one of the reasons why many companies, despite being on the latest release, only use a subset of the functionality that is available (too much in line with all those ERP licenses sitting on the shelve…).
Which led me to think about how users deal with updates: If you look at updates in an App store, the accompanying text will mention something like “we bring updates to you every few weeks” (think LinkedIn, Twitter, YouTube etc) but does not describe the changes itself. New functionality is introduced overnight and automatically on, whether you like it or not, whether you need it or not. A week from today, your time line can look very different, as vendors experiment with best product placement and other commercial efforts. The difference is that these are often free apps; are we willing to put up with ongoing change because we don’t pay anything, and thus have to accept the way it is offered? But continuous change is happening to paid apps as well, so that can’t be the answer.
If systems are continuously updated in the background, it follows that the reason why cloud vendors “package” feature updates is because of our organizational culture. When new functionality is introduced, our current approach is to control that centrally. We want to evaluate what’s new and decide how and when to bring that to employees. It’s expected that we set up a project team, start a change program and organize training and communication to govern the roll-out. This approach finds its roots in ERP, where every update was a major release and very different from the previous one. But our workforce lives in a world where apps change overnight and they are fine with that: no training required. Just think about the introduction of Apple Music – a major overhaul which users are eager to try without training or a helpdesk. So what if you HR system would do that too?
Now that we have arrived in the mobile cloud era, it’s time to adopt a mobile mindset. Why can’t we introduce new HR functionality by enabling it and observe how user adoption progresses? Why not assume that the vendor has created a best practice based on customer input that could work well in your company? If it’s any good, early adopters will find it, check it out and share it with others, who will follow. If it isn’t, no one will use it and it will slowly die. If there’s a release every few weeks, we would not run change or learning programs, and we shouldn’t have to – not every release is a game changer. Think about all the project time and communication hours that would save…
So what do you think – is your company cloud-ready? Do cloud vendors understand HR processes well enough so new features can be enabled by default? Are you willing to step away from “we’ve always done it like this” and accept the standard? Can we expect users to just explore the HR app and understand what is expected? I think it’s just a matter of time – and we’re almost there.