Managing a Dynamics AX 2012 implementation using Lifecycle services LCS

OK, so you got a new assignment to implement Dynamics AX. You have heard very often everyone tell you about how important it is to focus on business issues and not product or technical issues alone. So you collect the business challenges that you can lay your hands on and let them marinate for a while. You quickly realize that business challenges that customer wants addressed are at a forty thousand foot level like save me costs, improve visibility in my supply chain or increase product profitability and so on. There is unfortunately no function in Dynamics AX that you can execute and get those issues addressed. The only way is to break those challenges down, locate them in the business processes and then identify which Dynamics AX capabilities can be used to address them. So for instance introducing workflow (product capability) in managing purchases (business process) will result in saving costs (business challenge). But there are many challenges, many processes and many capabilities. Doing this one off will clearly not translate into sustained business value and you will also struggle with demonstrating to the customer that your implementation of Dynamics AX has actually led to improvement and/or has actually addressed the challenges. Once you see this, you quickly appreciate the importance of modeling the business processes, defining scenarios to break them down further, getting a project plan in place to execute against, etc. So how do you do it? Normally all such activities could be separate projects in themselves, but most likely, given the time & budget constraints you can’t indulge yourself in such luxuries. This post describes one simple and fast approach using existing tools which you could take even if you are standing neck deep in engine oil!

First, start with a business capability model that customer has even if it is old and inaccurate. Only very large companies have done decent work on such a model to get you the detailed business processes you would need under each capability. Mostly you will find customer business capability models are very high level like manufacture and design and so on. Some will break this down further and will have schedule manufacturing and release design and so on. If you find yourself staring at a capability model like that, don’t be dissuaded, use one of the industry frameworks or capability models. I prefer to use APQC process classification frameworks or SCOR model. In this post, I refer to APQC.

Second, use APQC PCF for customer’s industry to augment customer’s capability model. Find relevant nodes on customer’s capability model and add to these various levels from PCF like for instance under manufacturing/schedule manufacturing, add further levels like schedule production and schedule and sequence jobs. Usually this activity will lead to healthy debate about terminology or lack thereof. For instance in this example, don’t be concerned about production being added as a subset to manufacturing when this should be other way round. Reason is that customer thinks their capability is manufacturing and not production, so be it. Using customer specific language is more important than using terminology from a standard framework – remember this is simple & fast approach, so take some shortcuts to get ahead, come back and iterate if you encounter too much resistance.

By this time you have four levels – process category (manufacturing), process group (schedule manufacturing), process (schedule production) and activity (schedule and sequence jobs). By doing this, you are breaking down capabilities in customers’ business capability model to individual business processes and activities. At this stage, if you find yourself going down the path of mapping each and every business process and activity in this model – stop yourself. Remember that this is part of an ERP implementation project where the objective is to address business challenges by implementing Dynamics AX. So, focus on the processes and activities that are more likely to address the business challenge and leave the rest out.

Hopefully you have been capturing the unstructured information that you have been collecting in your interactions with business managers and users. If you want you can use an O365 account and store all such data in a sharepoint repository.

Third, now that you have four levels of your model already defined, add a fifth level called scenarios – for instance under activity - schedule and sequence jobs, use that unstructured information or customer provided requirements list and add scenarios like describe the production route to schedule and sequence jobs, run operations scheduling, run jobs scheduling. Strictly speaking these don’t always end up like the ideal scenarios that have a persona and action taken by the persona. Sometimes they might and at other times they may be at a higher level. Granularity that you can achieve will depend on detail in the business process that you want captured in the model. Scenarios at this level should not go across departments, they should be small and within span of control of one manager. If you focus them keeping customer organization in mind, you will find that you get a very attentive audience and you can churn through this activity at a faster pace without getting impeded by departmental politics.

Fourth, add a further level to scenarios – call these user stories. These must be the requirements that you want to fulfil using Dynamics AX. User stories are very targeted at one user, usually an action that one user takes in one flow through Dynamics AX like edit the resource loading for works order on Gantt chart and view the result.

Let’s recap what has been achieved by now. Instead of working of a requirements laundry list which itself has individual list items on varying levels of detail, you have (1) brought the requirements at same level (2) you have defined them in a way that they are targeted at individual users (3) you have defined them at a level at which you would normally configure Dynamics AX (4) placed the requirements in the right hierarchy of business processes they belong and as a result (5) you have created a model which explicitly states fulfilling requirement A will mean changing business process X which will mean improving business capability Z. You have identified specific users in customers’ organization who will champion a requirement to fulfilment. You can go further and add derived business value at the scenario level. Then you could explicitly state that completing this scenario will say, reduce manufacturing cost. For more quant oriented projects, if you can find, you can add an estimate of derived value (for instance, estimated cost saving) at scenario level and then add them up to show the total derived value.

And no, by no means you are doing this in MS Excel. You are doing this in Task Recorder that ships with Dynamics AX 2012.

Fifth, as you go through this process, you will identify gaps that cannot be filled by standard Dynamics AX 2012. To make sure that these are addressed add or modify scenarios and/or user stories to account for these gaps. Once the model is there in Task Recorder, get your team to start doing recordings. Use these recordings to show your prototype to the users. You should not aim to get the complete model in place at the first instance. Instead you should use the approach described briefly by Nalin in this post, keep iterating, and changing recordings until the user is satisfied. Then use the recording for training purposes later on in the project. Once scenarios and user stories are in usable shape, if a project plan already exist, place the user stories under relevant nodes in project plan or use these stories to create a project plan. If you use TFS for project management and if you use the Agile 6.0 template, it will look something like this.  

Sixth, add additional deliverables to user stories as required for instance add development and configuration tasks to each user story.

Seventh, add test cases to the project plan to ensure that user stories and associated deliverables do what they are meant to do.

 

Once you have the recordings in Task recorder, upload the .axbpm package file to business process modeller in LCS (Lifecycle services) for AX2012. BPM in LCS is a great tool for all your users to visualize the process and view the recordings. For instance in the picture below, there are four recordings for process group 3.4 and six recordings for process group 3.6. You can access other LCS resources on this page.

With such a structure in place, you are in control of the project. As deliverables complete, user stories will get completed. As user stories get completed, you can see which scenarios are getting fulfilled and find out what processes and being changed, what capabilities are being improved, what business challenges are being met and eventually what value is being added.