Beyond Dynamics AX with Business Intelligence

I hope everyone is having a blessed day, and you find yourself productive in our Dynamics filled world. May is once again here, and that means we tilt ever so closer towards our solar systems star - in the northern hemisphere that is. That also means planning for summer time vacation, baseball / softball, as well as an assortment of water related activities. The march towards summer begins, and that means the world around us continues to come alive.

With spring in full force, I thought it was time to talk about the needed topic of beyond Dynamics AX with Business Intelligence. Lets face it, more and more projects are being sold & implemented well, that has Microsoft Dynamics AX only acting as an operational ERP element. It's one spoke in the total solution for larger companies. When you have this reality, Dynamics AX is no longer the single data mart from which analytic's & insights are derived from.



As we see from the above image, when Dynamics AX is the data mart in which such BI artifacts solely are crafted around, then you have a very compelling story in which a companies total reporting needs can be told by. This is Sunrise's standard offering for business intelligence needs. That is: Office+SharePoint+SQL Server.

Are focus is expanded however, when the needs of the customer expand. To help facilitate the understanding of when and where this might be the case, let's start by listing a high level set of topics, that in turn will be used to guide into greater business insights for customers. Further, how each of these topics would drive to a more complete or total BI story that is crafted for a customer. All the while, keeping in mind that the tool is the last thing you focus on for a real BI project.

• Dynamics AX is a spoke, not the hub - Here we have a total solution scenario, where Dynamics AX is an operational ERP element in a customers total solution. This means 2:n possible line-of-business applications that complete an end-to-end solution for a customer. When this is the case, items like real data warehouses, ETL, Master Data Management across the systems, and more must come into the picture. This further means that what tools are best for achieving the ultimate end goal might need to be extended beyond the Office+SharePoint+SQL Server.
• Security & Exposure beyond the Dynamics AX walls - Here we have a need for an organization that has reporting requirements. These reporting requirements however dictate that there are business insights needed for employees that will not have, nor should not have access to Dynamics AX at all. When this is true, again, then we have directive for something that extends beyond the walled garden of Dynamics AX.
• Mobile BI across a multitude of platforms - There is a very compelling story that can be told with the BI stack of Office+SharePoint+SQL Server. Mobile is very much apart of this, specifically with the release of Office 2013 and SharePoint 2013. However when you want a mobile BI platform, that needs to reach beyond the Microsoft world, in a more native way, then extending beyond the BI stack that comes with Dynamics AX is needed.
• Abstraction - This last point is more focused around that true executive information system, or dashboard. With the continued improvements being made for Dynamics AX, and those improvements driving more technology and model churn, the need for abstracting away the C & B level executives from such churn is a valid one. Having something that extends beyond the Dynamics AX BI stack, can help abstract out the executive's and their analytical needs. Reality is, these might change some, but not at the rate in which technology, and further Dynamics AX is changing.

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.

The above, by far is not a final list but something that hopefully has you thinking in terms of a more complete BI solution. There is hardly ever any truth in we bought (insert product name) now we have BI! Real business intelligence for customers is always about the data first, then reporting need second, and finally the product or products that help delivery on said need last. Take into consideration any of the above points, and you have a more larger requirement - where selecting specific tools first could halt the needed progression that is demanded by the organization.

Over the next several weeks, I will continue to expand upon each of the above topics, and others in how I feel these are best addressed. This includes both the stack that comes with Dynamics AX, and beyond that for a total solution offering.



That's all for this post, I hope you have enjoyed it and your excited to hear more. One final note, I would like to say that I'm honored to have been listed once again this year in the DynamicsWorld Top 100 list. Top 25 again this year! Honestly the amount of work that some of the people put into the ecosystem, that I can be included with amazes me. This community as a whole has grown leaps and bounds over the past 3 years. I can't say enough of how honored I am to be included as part of it. Til 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.


Follow Me @:
       

"Visit the Dynamics AX Community Page today!"

Planning for data import, export & migration with AX 2012

With every Microsoft Dynamics AX 2012 implementation, a very import topic, that involves a lot of planning, and technical work, is around the process of migrating data. This includes a lot of exporting, importing, transformation and so on.

Like all task relating to an AX 2012 implementation, these should be governed and defined based on functional business requirements and discovery. That is what should drive the choice being made, for how specific entities are imported, migrated or even entered into AX 2012.

To that end, and with this in mind, lets look at some new content on MSDN, specifically on this topic.: Plan data import, export, and migration [AX 2012]

From the article:
"This topic describes the tools and strategies to use when planning to import or export Microsoft Dynamics AX data. It describes how to plan to migrate data from one enterprise resource planning (ERP) system to another. Finally, it describes performance and security considerations for data import and export."

This is actually a very well thought out, and put together article, and I highly recommend it be used as a source when in reference to such task, when working in this area of a AX 2012 project.

With that said, there are some understandings that we need to circle back around to, to allow business requirements and customer needs to drive what is completed, in regard to such task.

One broad stroke statement that is not always applicable from this article is the following.:
"We[MSFT] recommend that you do not migrate transactional data or historical data to Microsoft Dynamics AX. Instead, close all open transactions before migrating, if it is possible. Maintain the database that contained your previous transactional data for reporting and compliance purposes."

This, as many of you senior consultants understand full well, is a great statement, and if it's possible really helps reduce the cost of data migration efforts in a project. However, it's hardly always true, and would say that the above statement is typically not what takes place for open transactions on any AX project.

Instead, what we try to push for, in the above statements place, is based on volume for open transactions. With that, if the volume is not to large, then a two birds, with one stone event can occur.

Instead of having to write data migration logic, this can be used as a training opportunity and get the open transactions into the new AX 2012 instance. There still can be an argument that even if there is a perceived large amount of volume to such data, that it's cheaper and better ROI to have more hands entering in the open transactions than writing migration code.

Why would that be? The reason is, any time spent, and therefore budget dollars burned, on the process of data migration is all throw away once the go live takes place. This means it looses it's value, as soon as the new AX 2012 instance is up and running.

So the trick, for adding the most value to such projects, is to perform the least complex, and spend the least amount of time possible in this area. It's not the the point that it should be overlooked, I'm not stating that at all. What I am saying, is that whatever the solution for migration is, it should be defined based on the understanding that the work will be throw away as soon as the go live takes place.

Now, on larger implementations, most likely all of the options that you see listed in the above document will be used. There is no single way to achieve importing all entities, instead, each should be defined, based on volume, complexity, and level of transformation that needs to take place. The process should be as fast as possible, and least amount of time and therefore budget dollars. Simple is king of value, and rules over it in this area with an iron fist.

Another point I would like to bring up, that is not listed in the above article, is around RapidStart Services and it's impact on data migration, specifically around reference and setup data. With the release of RapidStart Services for AX 2012, this too should be considered, weighted and then valued for helping create data entities, and for importing other entities via.

I will leave with this, always look for the most simplest approach when migrating data. Only be as complex as the requirements and customer constraints force you to be. Sometimes the most elegant solution, is the worst in value, when it comes to the task related to data import, export & migration.

Finally, I will reference back to this post in future articles, as I review some of the options in detail. Talk about the real world impact, by example, and give some food for thought to help better understand the value of the choices made on real projects.

That's all for now, till next time!



"Visit the Dynamics AX Community Page today!"