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!"

Dynamics AX, SOA and Oslo on the mind...

Alright, so I have been doing a lot of degrees of seperation lately, or thinking in such terms. The area's of topic, by choice, are Dynamics AX, SOA and Oslo. I started thinking about these 3, two products and one an arch. that is used to bridge systems, interconnecting products.

Then, even as I was typing that, about being products, in turn I realized that Dynamics AX and Oslo are not products really, not anymore, well not anymore for Dynamics AX.

When Dynamics AX was called Axapta, and back before Microsoft bought it, you could consider Axapta a product on the verge of becoming a platform.

With the release of Dynamics AX 4.0, this product grew up and became a real platform for the first time. It integrated and fit, nicely sometimes and not so nicely on others, into the Microsft stack. And why not right?

Microsoft is a platform company, that is what they are. They provide the platform that partners and customers use to provide and create solutions with.

Alright so Dynamics AX and Oslo are platforms, and SOA is an Arch. Well recently, Microsoft hosted their SOA conference. The home page can be found here: Real World SOA: 2009 Microsoft SOA & Business Process Conference

At the conference there was a lot of different topics covered, and I plan on getting into some of the details in a later post (hopefully) about in specific session. For now though I wanted to talk about these two platforms and the one arch. The reason is, in the not to distant future Oslo (along with "Dublin") will be released from Microsoft as live products platforms / services, and they are already in the line up for Microsoft Dynamics AX roadmap.

The reason they are is that Oslo, Dublin and Dynamics AX with the help of SOA will become platforms that work together with the rest of the Microsoft stack, like office, to help deliver to business that make use of the Dynamics AX business platform, create and manage business workflows.

Big deal huh? I mean this is already happenning right with the release of Dynamics AX 2009 and it's use of the .Net 3.5 workflow engine right? Technically the answer is yes. But... (and you knew there was a but) there is a lot of code that goes into these workflows, the designer is a tree down designer, and the flow of these workflows are not very flexible.

Enter WF in .Net 4.0. This will come into play, along with Visio like diagram ability to offer partners and customers to create workflows with greater ease soon, that are more flexible and less code.

A little later, enter Dublin + Oslo (along with the letter "M" [more in a bit about M.]) with WF 4.0 (and beyond) and you have the *desired* goal of creating business process workflows that are managed and created by users, with complex flows and use of logic, with 80%-90% estimated less code than currently exists with workflows in Dynamics AX 2009 and .Net 3.5.

So with all this said, what's the point?

1.) You can create workflows now in Dynamics AX 2009, that will help manage your business processes, out of the box.

2.) In the very near future, this will be improved with .Net 4.0 and WF, along with a new designer for the workflow that will be Visio like. The workflows will be easier to manage and offer more flexibility, with less code.

3.) In the next release of Dynamics AX (based on current road map) Oslo + Dublin, along with the modeling language "M", yes a new language that we will explore here, will be used by normal super users to create, manage and maintain business work flows and processes, without the need of much coding in X++ or C#. (Based on information from Microsoft)


So we have some exciting new things to look at with this. Look for more on this, later this week, as we look back in time at the PDC 2008 that happended last October to talk about this in greater detail and to get some direction on the who, what, when, how... and why of this topic.

Check back soon...






"Visit the Dynamics AX Community Page today!"

Dynamics AX project success - Business Processes Streamlined

When entering into a new implementation, one of the key things that needs to happen for a project to be a success is the discovery phase. This phase is very much customer intensive as they must provide the consultants with business process documentation and review of such documentation. The point of this phase is to really define the full scope of the project. In doing so you create the real project plan, and can start to talk about educated timelines, vs. wild guessing of such. So the discovery phase is very important, and has a lot of key aspects to it. One of which is making sure the customer takes advantage of the time to review their business processes and use of software to see if they can steamline their BPs. This is one of the Points in implementing a new ERP, or parts there of, for taking advantage of what the ERP offers out of the box, and also what needs to be modified to achieve the business needs.

To often I have been involved with projects, or heard of projects, where the customer wanted the new system to do exactly the same as the old system. This is understandable, but the real benefit and actual point of this is missed. See what the goal should be is to achieve the business need, but possibly with totally new ways and new business processes. Now it does not make sense to add work to achieve the same ends, but the goal would be for the customer to look at their business processes in an entire new way, the Dynamics AX way.

So while the overall Discovery phase is most very important, an outlet or faucet of the phase is taking the time and having the customer see and take advantage of reviewing the business processes at hand and streamline them with the new solution. Proper planning for this can make sure such streamlining is considered in the project plan, and therefore timelines can be meant at a better percentage rate.

Well check back as I continue to post. I will be switching back to more technical postings, as well as some surprise post that might interest a few of you!

Find a job at: www.DynamicsAXJobs.com