Modeling Business Processes with AX 2012 and Workflow

With the release of Microsoft Dynamics AX 2012, a powerful new way of approaching business process design is given to us. I spoke about this back in an earlier post this year, on Modeling the world, with Dynamics AX. I also continued to talk to this point, with my last interview with Microsoft's own Lachlan Cash.

In that interview, I asked Lachlan about the vision Microsoft has for modeling business processes within Microsoft Dynamics AX 2012, through the use of the Workflow designer. I don't want to re-hash the entire answer, you can go back and read that post from the link above. I do however want to preface this series of post I'm starting, with the following quote from that interview.

"The goal with such items, as the workflow engine is to address the need to bridge the gap between development vs. business process modeling. To take and drive true BP workflows, down to the end user level."

Well here we are, now with AX 2012 alive, kicking and screaming. Well, not sure about the screaming part, but you get the idea. So it's time to start taking the tools, and taking the vision, and by example see this in action, and the value it brings now, and for the future.

To that end, and as I have already mentioned, this is the start of my series on Modeling Business Processes with AX 2012 and Workflow.



For this first post, I want to spend time talking about the value this vision is meant to bring. Talk to the reality of what we currently have, and the ability for partners and customers to adopt this type of approach as part of the overall implementation project, for meeting business requirements.

First the value of such a vision. I've had long talks about this with plenty of people inside and outside of Microsoft. If you read through some of my earlier post, I mention terms like domains specific languages, and the ability to model more and code less. Such terms help describe the vision, and the perceived value supporting the vision is around being more agile, and flexible in the business processes that a company governs and uses.

There have been plenty attempts in the past to do code generation, and this is not the same vision, as what we are talking about doing with workflow to model business processes with. No, instead we are talking about enabling the ability to create workflow elements, that connect into custom components, to enable a business process to exists. The idea, is that this workflow framework, and the elements that make it up, could be used, to create and model business processes, that, in the past would be done through mostly custom code, and parameter based configurations.

So, that is the targeted value, for taking this vision and making it a reality in your AX 2012 projects. The next area we need to look at, is the reality of the current offerings, within AX 2012.



Here we will see, that Microsoft does provide some out-of-the-box offerings, that follow this vision, to enable business process modeling. For example, if you go to Organization Administration, Setup, Workflow, Organization Workflows then you will see, on creating a new workflow whats comes with AX 2012. These are: Case Management workflow, Document Handling & Signing limits workflow. These are workflow templates, that are made up of the elements you see in the image just above this paragraph.

So the reality is, there are some out-of-the-box offerings, in which we can start to use for taking and making the vision a reality. We must also taper this vision, to reality, with the fact that value should drive what we do. I know I sound like a broken record at times, when it comes to business value, but I don't think it can be said enough.

Also, while speaking to the point of reality, AX 2012 is actually the first major stepping stone, in this grand vision of modeling the world, from a business process modeling point of view. So to this point, this is why we see in the offerings from Microsoft that comes with AX 2012, are not very deep, and only enabled and used in certain parts of the application itself.

This brings me to my final point for this first post, which is the ability for the partner and customer to adopt this vision, and thought process, for achieving business requirements, via business process modeling through workflows.

Because there are so many options, and great new features within AX 2012, and we still have time lines and budgets to meet when it comes to AX 2012 implementations, the temptation will be to get this done, and not make use of workflows that much. When weighted against value, which is what should drive the design, and a workflow could meet the business requirement needs, for the business process, that would actually reduce development effort, but require some custom workflow elements, then that approach should be considered.

This is where the rubber meets the road, and where AX 2012 projects, and those who are implementing it, need to really understand the ability of AX 2012. They need to know the vision for the workflows modeling business processes, and the reality of the value this might can bring.

The flip side of that, is not everything is meant to have a workflow govern it, and you can never get away from custom code. I hope, however, to take and through my series on Modeling Business Processes with AX 2012 and Workflow's, that you will see the power this brings, the flexibility, and good examples of using this on projects now, and in the future.

That's all for this part in the series, but check back soon as a whole lot more to come. Till next time!


Visit Hillstar Business Intelligence (www.HillstarBI.com) in order to truly unlock your data trapped in your Microsoft Dynamics investment. With our value driven business intelligence strategy Hillstar help you transform into a data informed company.




"Visit the Dynamics AX Community Page today!"