/Logos/ae-logo-pos-rgb.svg){kind=logo}
What is a project? In its most simple definition it means implementing a change in a controlled way so that the investor doesn't need to take a leap in the dark. The word 'controlled' and 'change' are key in this simple definition. In this post, I’ll focus on our approach to define the way in which the business needs to change its way of working and how we leveraged our corporate process model to do so.
It is common for companies the size of bpost to be organized in silos. From the highest level on, the company is divided in business units that are each structured in a department tree. As a consequence, each business unit tends to have its own way of working, its own culture, its own software and its own business processes.
Challenges
One of the challenges of the iHRM program is to avoid customizations of the new HR solution (PeopleSoft) as much as possible. This means that we would need to align our business processes to the tool’s capabilities. On top of that, we are also changing the way the human resources department will interact with the other business units and what kind of information needs to be exchanged. Sending out a few project newsletters and organize some training would not do the trick.
To fully understand the change that each and every department would have to go through, we need a solid and shared vision on the future way of working and the role of the human resources department herein. As always the challenge is to get everybody on the same page and make sure that they all understand the same thing. Avoid ambiguity. The only way to do this is by modelling out the to-be processes in a structured way and across all of the silo boundaries.
To-be model
A simple Visio drawing wouldn't work here as the scope of processes is far too big. The level of detail needed to take the right decisions is also too variable to include everything in a few simple schemas. To really achieve success, we needed a process architecture consisting of multiple layers with a different (but constant) level of detail. This would assure us that each level can be used to support the right decisions (going from 'what business unit is responsible for what?' to 'what tasks must role X execute?').
Ideally, we would have access to a corporate process model that already contains the decomposition of what the enterprise does and use that as a starting point.
Guess what; we were lucky to have such process model already in place on a corporate level. Bpost has believed in the value of a good process architecture for quite some years. The decomposition wasn't worked out to the same level of detail for every process but at least we had a good starting point. Even better; for the human capital management processes we executed a full process re-engineering in 2014. This gave us a recently validated starting point.
How does it work?
To put this into practice, we assigned one person as the overall responsible for the business process re-engineering of the full program. This person is responsible for the end-to-end integration (and design) of the business processes and collaborates closely with the overall program change manager. Each business project team also has its own 'process responsible'. These people will work out the details of the process. This includes the lower levels all the way to the task descriptions for the individual employees. By consistently adding detail while holding everything together on the higher (more abstract) process levels, we end up with an efficient model that allows measurement later on and guarantees that there's coherence between all business activities.
The return on investment of an explicit process re-engineering exercise goes without saying. You don’t want to be confronted with these issues and questions when your new systems are already up and running. Obtaining clarity on how you will organize yourself in your business processes is an essential element in any project that introduces a certain amount of change.
Tips & tricks
To conclude this post, I'd like to share some hands-on tips & tricks on performing a business process re-engineering exercise:
- Process modelling is about what happens and who's responsible for that. It's not about how this is done and should definitely not look like an application manual or a decision tree.
- If your scope is somewhat large, you need a layered architecture to effectively manage the process change
- Define for each process and on every level of detail what the business goal of that process is. Think this through. A business goal is something that really matters without jumping into solutions. The goal for instance cannot be: "complete screen x". It could be: "assure that all work to be done is assigned to an available employee".
- Use a standard process notation (like BPMN) but keep the symbol set as simple as possible. We use a subset of the BPMN 1.0 symbol set. It improves readability. Using an extended symbol set will only proof to be valuable if you want to automate your processes.
- It's okay to represent something in a different way (think of a beautiful Visio/Powerpoint drawing) to get the decisions you need. The decision taker will not be interested in your BPMN model and seeing you click through three layers to highlight your point.
- It's highly recommended to use a design tool to manage your process model, this will facilitate coherence between your models and it helps a great deal in managing your levels of abstraction. Bpost uses Mega for this purpose.
- Brown paper still works best for workshops. Don't try 'live modelling' in a design tool during workshops.
I want to give special thanks to David Bamps (bpost colleague) and my AE colleagues Wouter Steurs and Bram Vanschoenwinkel for the excellent work they have done in this challenging assignment.
We are approaching the end of this blog series. There's just one more post to come in which I'll share some thoughts on decision taking as part of the governance process. More concrete, I'll comment on how we achieve to limit our degree of customizations to the standard software package.
