Continuous Improvement in your Workday BAU structure
One question often posed to me by organisations of all sizes and industries is how a Business-as-Usual (BAU), sometimes known as Run-the-Business (RTB), team post implementation of Workday should be structured and sized.
The sales cycle with software vendors and Implementation Partners gives organisations a clear steer that their BAU team should be structured and operate fundamentally differently to their legacy system setup. However, the excitement and pressures of the implementation often take over and leave the Project Team with insufficient capacity to give the topic much real care and attention – consequently, clients often hastily revert to a ‘facelifted’ version of their legacy structure at the point of (or even shortly after, in some cases) go-live, and are rarely able to give it a second thought as they face into the inevitable questions and requests that come post system launch.
I’m certain these are not the first words penned on this topic and they are unlikely to be the last, so I will not attempt the ‘BAU structure to trump all BAU structures’. Simply put, this doesn’t exist; every organisation’s needs are different. Instead, I will focus on one, too often neglected facet of a BAU structure that every single client, regardless of any other decisions they make, should have at the heart of their thinking: Continuous Improvement.
For those with a Lean or process improvement background, the concept of Continuous Improvement or CI will likely be embedded in your everyday thinking (whether you realise it or not); for those for whom CI is a new term, think of it as constantly seeking to improve everything around you. Workday (and other similar SaaS solutions) is set up for clients to benefit from the CI that Workday itself has embedded into its product set – think of the weekly service updates and twice yearly functionality releases – so why is it that so few clients are set up in a way that allows them to benefit?
Simply put: capacity and team size. BAU teams of old often focused almost exclusively on ‘keeping the lights on’, perhaps making the occasional tweak to a system to respond to a change request or bug, waiting for the much-anticipated system upgrade that came every few years or so, driven by a sometimes sizeable, but very importantly largely separate project team. This upgrade would bring the BAU team up to date with the latest and greatest functionality (although, ironically, it often took so long to upgrade that there was a new version available by the time the project was complete). To give an indication of the scale of these upgrade projects and associated teams, I anecdotally heard of one organisation who had a ‘BAU upgrade team’ whose sole purpose was to undertake upgrade project after upgrade project on one core system of record!
One of the reasons organisations often select Workday is the regular functionality releases and an escape from the lengthy (and expensive) legacy upgrade lifecycle. However, it’s no secret that a significant amount of Workday functionality doesn’t just turn itself on; at the very least it requires a bit of comms, training material updates, and testing, and at the very most it can require a mini project in its own right. How then are BAU teams that previously focused almost wholly on questions from end users and occasional system tweaks suddenly expected not only to continue to field questions (often from a much larger end user audience if the concept of employee and manager self-service has landed), but also to take on the work, albeit in smaller, bitesized chunks, that was previously undertaken by an entire upgrade project team…?!
Answer (if you hadn’t already guessed from the title of this article): by embedding CI roles into their BAU structure. Organisations that do this well don’t rely on the same sized team who were fully utilised pre-Workday implementation and don’t see the BAU team as an easy opportunity to make efficiency gains in their HR, Finance or IT headcount with the advent of Workday; rather, they invest in their BAU team as they have invested in their Workday solution – they have after all just saved the cost of an entire project every few years.
Not buying it? As my Workday career has started to transition away from implementations and towards optimisation (look out for an upcoming piece on what optimisation is and how it can benefit your organisation), I am seeing first-hand how embedding CI into a BAU structure up-front can pay for itself multiple times over by:
- Avoiding the re-engineering or even re-implementation costs that can come from a Workday solution that has stagnated for a number of releases
- Enabling an organisation to make the most out of its Workday investment from day one
If you’d like to talk to me more about how your organisation can benefit from embedding Continuous Improvement roles into your BAU structure, please contact us at info@3plusconsulting.co.uk
