Ever since Microsoft decided to embed the APQC process classification framework into the Business Process Modeller in Lifecycle Services (see previous post), the question to anyone responsible for a Dynamics AX implementation has been: is APQC the way we should go with our implementation?
When we started out on the Dynamics AX programme I am currently responsible for, we had to decide on a number of things:
- Did we, as a company, have a common global process language or classification framework we could leverage?
- How should we structure our workshops?
- Did our implementation partner have a process classification model we could use as a starting point?
Since the answer to number 1 was a definite NO! – and this is probably the case for many (most) companies, we could go two ways:
- Spend a lot of time (and consultancy fees) mapping our processes, classifying them and building a common language from that or
- use an existing process classification framework and map our processes back to that.
We chose option 2!
When you are at the formative stage of an implementation and need to decide how to structure your analysis and design workshops, in the main, you decide between a functional approach or a swim lane approach. With a functional approach you often end up replicating the processes you have today because you analyse them from the same functional view you are already used to. With a swim lane approach you tend you challenge the processes more because of the holistic approach, but a classic swim lane such as order-to-cash (including fulfilment) may prove too all-encompassing and you end up trying to handle all the company’s processes in one swim lane.
Instead of these more traditional approaches we chose to use the APQC framework to structure our workshops. This means that we divide the project into a number of work streams based on APQC L1. Subsequently we structured workshops based on L2 and discussed processes on L3. It did not work for everything, so some creativity and improvisation may be required, but it gave us a good starting point for our planning.
Lastly, our implementation partner did not have a process classification model, so choosing one ourselves was necessary and easy. Choosing an industry standard instead of a proprietary model from our partner, which was likely to tie us in with that partner, I think is the sensible way to go.
Will the choice ultimately make a significant and positive difference to our Dynamics AX implementation? The jury is still out on that one since Microsoft has not actually changed the product to align with the model as far as I can tell, but maybe that is not the point.
The point, for us at least, is that using APQC in the formative stage of an implementation may save you time and frustration and give a structure on which to build up you programme organisation and processes. Whether this is a sustainable advantage or not, I will report on in a future blog post.
Could we have gone with a different framework? Yes, we could for instance have gone with APICS SCOR(r), but this model is heavily biased toward supply chain processes and Microsoft chose APQC, so going with something else did not seem to make a lot of sense.
So far APQC seems the way to go…