Microsoft Partner and Senior Technical Architect Brandon George's column is focused primarily on the high-level architect, CIO and CEO roles within Microsoft Dynamics Partner and Customer organizations. Brandon reviews topics ranging from Microsoft Dynamics AX, general trends in technology, and how it can help solve business domain issues today and tomorrow.
Today I wanted to focus this column, around the concept of creating a System of Engagement (SoE) with Microsoft Dynamics AX 2012. This focus spans all user types that make use of Microsoft Dynamics AX 2012. From the basic user of Dynamics AX and all the way to the highest C-level executives within an organization, the goal is to engage.
Exactly what does the term mean system of engagement? To start with semantics, per dictionary.com the word engagement means: "the act of engaging or the state of being engaged" How do we create a system, that puts it's users in the state of being engaged? This is achieved through several efforts, including but not limited to how we approach projects, reporting, business intelligence - as well as social and more!
Though is seems like I just crossed the board on a lot of different topics, in reality what we are trying to achieve in these efforts is to truly create a System of Engagement using Microsoft Dynamics AX 2012. This is the evolution and merging of technologies & concepts that been building through the progression of Microsoft Dynamics AX. The idea, simply put, is to engage the end user - so that what was once just a system of record can truly become a system of engagement. That Microsoft Dynamics AX is more than a new transactional system, but it really engages users through all levels of the organization.
Let’s look at what practically makes up such a System of Engagement, with AX 2012. With this, we must start - in my own thoughts - with a focus around Business Intelligence (BI) and reporting. The reason I state we should focus on the end result, which just BI artifacts as reports, Cue, Role Center pages and more - are for an instance of AX, is that this is the touch point mostly used by end users. They understand executing a report, and getting back information.
Model Drive Approach to AX 2012 Reporting
With the creation of Role Centers, and it's use of web parts and specific reporting elements, including KPI's and others, the evolution of engaging the end user was born. I''ve covered the topic of BI to a good extent myself, from Reporting Architecture, Report Development & Design as well as a dive into the personal BI options with PowerPivot. Further a focus on the BI Semantic Model, and it's impacts for Microsoft Dynamics AX now and the future, as well as a focus on the concept of Queries Elements being a re-usable API for AX 2012.
Code Driven Approach to AX 2012 Reporting
The goal, of such building block post has always been how to make the most use of Microsoft Dynamics AX 2012, to truly engage the user base - to help shape and turn the mindset away from being 'just another transactional system' and truly into a real System of Engagement.
This focus, though needed to create a System of Engagement with AX 2012, is not by itself enough. This is just part of the story, or pieces of the narrative - what has to come into focus around this context so that we understand who and what we are trying to engage, is Workloads & Roles. Any functional or technical scope for a Microsoft Dynamics AX 2012 project must have Workloads & Roles at the center of why such scope even exists. Having this as a foundation, helps set forth everything from creating a functional Map for your BI artifacts, through Role Security modeling and solution scope.
This means, of course the focus on reporting, but also further you can truly then shape your Role Tailored Experiences with Role Centers. You can add social feeds that are relevant by the Roles. You can correctly create everything from Cue's to KPI's, and every reporting aspect in-between that helps meet the real functional scope, as defined when looking at a Microsoft Dynamics AX 2012 project.
To close out this thought process, to enable Microsoft Dynamics AX 2012 to truly become a System of Engagement the focus has to be placed on Workload and Role modeling as part of the implementation. Doing this, with an understanding that the end result is just not a new transactional system at go live - but more than that, the end result is to truly create an engaging, role based user experience - that makes use of all the technologies, and points I have mentioned in this post and more! In short, to create a system of engagement, that has to be the goal on the onset of a project. It has to be the focus of what is trying to be achieved.
I will end with this is just the start of such a topic, or conversation. Such a focus deserves real world examples beyond what I've linked to and stated as well as community contribution. So I open the door to any and all on this topic. And further commit, that I will follow this post with a continued focus on examples for using Microsoft Dynamics AX 2012 to truly create a System of Engagement.
Other Microsoft Sites
I'm a Customer
I'm a Partner
Use the official Twitter tags:
#MSDYNCOMM | #CONV13