The Situation
The Information Technology & Services (IT&S) function of this global oil & gas corporation was in the process of transitioning to more agile ways of working, as part of a modernisation programme involving the replacement of SAP HCM with Workday HRIS, and increased adoption of the ServiceNow platform.
An organisational restructure running in parallel had led the senior management team to identify a need to introduce work force management as a service, with the goal to provide better visibility of resource utilisation and availability.
The Task
Work force management (WFM) as a service was to provide a central point of contact for Service Managers and Line Managers, liaising with HR and any third party suppliers as required to:
- Provide an accurate view of resource supply and demand across the function
- Coordinate the end-to-end process for employee hiring and on-boarding
- Facilitate the requisition of agency and managed service workers, where the need for an increase in short-term capacity had been identified
I was engaged as an associate of a managed services provider to mobilise the on-site team, complete initial process work and conduct analysis on the as-is capability.
The Approach
To gain sufficient understanding of the business problem we needed to solve, I began by building relationships with the teams already involved with designing the upstream services within HR and Talent Acquisition, as well as the teams involved in rolling-out both Workday and ServiceNow.
It quickly became apparent that each of these teams were working in silos; none had a clear understanding of the hand off points between each of the stages they were working on, or how that would fit together to form a working ecosystem. They had each focused on their own particular part of the puzzle, but not how each section needed to come together to provide the full picture.
A coherent programme outcome needed to be defined, so that the various strands of ongoing work could be pulled together to achieve the desired objective.
Process maps hadn’t been produced, so the first task was to construct both As-Is and To-Be views that would enable us to:
- produce a gap analysis, which could be used to determine the work needed to streamline the processes and clearly identify the handover points
- map onto these the points where the new technology was intended to either facilitate the workflows, or to enable a decision to be made
We needed to create a shared understanding and agreement about the short, medium and longer term decisions that needed to be made by the Service Managers about their respective workloads, and when these needed to be made to ensure service provision remained consistent. Working backwards from these allowed me to define and design reports and dashboards that would provide the various audiences with:
- headline information about what people were working on, and when that work was due to end
- the pipeline of planned work
- snapshots of supply and demand, where mismatches already existed or were about to emerge
We could then work backwards again to determine the data needed to provide this information, including:
- where we expected it to come from
- whether it already existed or needed to be defined
- who was responsible for a) each person (either in place or needed), and b) each piece of work (either in flight or planned)
- where vacancies existed that needed to be filled, and what progress was being made towards achieving this
The Action
Actions identified from the gap analysis were used to create a backlog in Azure DevOps, with tasks then planned across sprints lasting two weeks each; daily stand ups and a weekly progress review session provided the delivery with momentum.
A large proportion of the tasks were necessarily focused on data quality, and integrity as it flowed between systems. As the Enterprise Architecture function had previously confirmed that APIs between the various systems were not considered a priority, it meant that business as usual (BAU) teams would be required to employ manual processes of uploading and downloading, importing and exporting data using Excel spreadsheet templates. This was by no means ideal, but a major symptom of the siloed work that had taken place so far.
Each software team had initially been reluctant to consider re-mapping their data to provide alignment with another, as they considered their individual projects ready to implement. By making the scale of manual work required to solve this issue apparent – alongside an MVP for the reporting that exposed the gaps in the information available – the impetus required to get the work done was provided.
The Result
My involvement in the programme ended once this message had been successfully communicated, and work continues at the time of writing.
Exposing and communicating the scale of the gap between what was in place and what was desired was a major turning point. There are many valuable lessons to be learned about the impacts of siloed working on the complexity of work flows that encompass several organisational functions.
The lack of defined programme outcome, along with an absence of overarching business architecture offers a word of caution to Enterprise Architecture functions seemingly focused on purely technical perspectives.
The shared understanding created around the decisions needing to be made helped to communicate the importance of the data required, and the flow of that data between each of the stages of the workflow. The technology solutions selected needed to function as part of an ecosystem rather than in isolation.