ERP Software Logo

Microsoft Dynamics vendors provide comparisons and opinions to professionals in the ERP/Accounting software selection process


Peter Joeckel, TurnOnDynamics

Leveraging Web Services and SSRS or More Real Differences between Microsoft Dynamics NAV and AX

    Email | Print

    The conversation on real differences between Microsoft Dynamics NAV and AX continues as contributing technical blogger and ex-Microsoft product expert Thom Doss discusses leveraging web services and SSRS.

    This is part three of a series. To review previous articles:

    Thom continues:

    Earlier, we examined some design objectives that companies should use when customizing ERP solutions. In this article, I want to look more at #2 and #3:

    • 2. They need to leverage external tools that can extend the business logic and collaboration to people who may not have the ERP client, or may not have access to the client all of the time.
    • 3. They need actionable business intelligence that tells them what exceptions to focus on.

    One of most exciting things for me to watch over the last few years has been the incredible increase of capability in “the stack.” Those of you who have spent much time around current or former “softies” (Microsoft employees), and me in particular, were probably expecting the appearance of that term. I won’t re-visit all of the presentations that have gone before, but .Net, Office, SharePoint, and SSRS work together in ways that deliver amazing automation capabilities with far less “programming” than you would expect. It is vital that your ERP be able to also play an active role in this “programmable tool” environment. This is why web services and SOA (Service Oriented Architecture) are so important. I don’t care how good your software is, it won’t meet all of your company’s needs everywhere your people are working.

    As nice as it is to be able to modify my ERP to meet my unique requirements, often it is just as important to “relocate” the functionality. Before I get castigated by purists, for the sake of brevity in this article, I’ll use “web services” to represent all of the .Net mechanisms for consuming another program’s business logic or data. (Later in the series we’ll look at why some methods are better than others).

    Web services are critical to sustainable engineering because they allow us to use the best tool available for a given problem and not have to duplicate logic or try to force any given tool too far outside its sweet spot. I’m often asked by technical and non-technical people to explain why web services are important to a business. Since it had come up so many times during presentations, I decided to take the challenge and do a non-programming session on web services at Convergence 2009. I delivered a session where we demonstrated how an “engineer to order” company using NAV could use workflow to facilitate the custom build process that is common to them even though some of the participants in the workflow are not ERP users.

    When I proposed the session, everyone loved the idea until I added “I’m going to do all of that with no programming.” What made this tricky was the fact that NAV didn’t have workflow, and while SharePoint has workflow, NAV doesn’t have integration to SharePoint, and so on for all of the products in the demo. There are many ways to solve the problem with code, but the point of the exercise was to show how to extend the reach of the ERP without programming. We used a combination of NAV, SharePoint, InfoPath and Outlook to show how users working in their normal environment could use the tools they already owned and probably used every day to engage with ERP data and execute ERP business logic without ever touching the ERP client.

    Why is that important? Well for one reason, that session cracked the top 10 for speaker effectiveness for all of Convergence that year and I still get to brag about that.  But more importantly, the hundreds of people who attended the session all left with a new appreciation for the flexibility and power of “the stack.” NAV’s new web services had allowed us to solve a common business problem in a seamless and non-intrusive way, and without needing a programmer, because now it could “play nice with rest of the children in the sandbox.” Everyone now understood what “better together” meant and that web services weren’t just for programmers anymore.

    Let’s take look at a few ways we can extend the reach of the ERP through web services:

    1. Integration to workflow as we just read.
    2. Using InfoPath (or other Office products) to collect information when off-line for later upload to the ERP
    3. Desktop or web applications can be created (or modified) to directly exchange information (read or write) with the ERP while respecting the ERP business logic.
    4.  Easily exchange information with business partners. Excel documents can be created to send inventory lists to customers and vendors.

    Many of these options require some programming, but in most cases, we can expect more sophisticated solutions with less development effort when the application developer can easily “consume” ERP data and business logic. Another way to put it is that we can expect a higher return on our development investment.

    The reporting features of SQL Server 2008 R2 can also be a benefit to ERP customers. One area of significant investment in SQL Server 2008 R2 is business intelligence. This trend continues in the upcoming SQL Server 2012 release.

    1. Many companies are now using the combination of SQL 2008 R2 and Office 2010 to enable compelling “self-service” BI capabilities. When accessing a SQL 2008 R2 DB, Power Pivot in Excel 2010 can create pivot tables in “real time” (without an OLAP cube) against very large datasets. This “ad-hoc” capability adds tremendous value to dynamic business since they do not have to wait until a requested dimension or measure is added to the data warehouse and the next refresh from production takes place.
    2. When SharePoint 2010 is added to the mix, many of these companies are able to fulfill 100% of their business intelligence needs without an expensive BI tool.
    3. SSRS provides many benefits as a reporting tool, including:
      1. Integrating charts and graphs with row data for ‘board room’ quality visuals.
      2. Allows export to Excel, PDF, CSV, etc. without any effort by the developer.
      3. Allows centralized distribution, deployment, and management of reports from a web portal.

    I could have made both of these lists much longer and I could probably have added a couple more products that are (or should be) ubiquitous in today’s IT. But like last week, these aren’t intended to be exhaustive treatises on the products and technologies, simply a few reasons why we should expect to encounter them and should be prepared to leverage them when we implement NAV or AX. Before I conclude, I want to include a quote from Will Hansen, then vice president of technology for Intuitive Manufacturing Systems.

    “Microsoft .NET is tangible evidence that commerce in the 21st century will be all about rich and often ad-hoc connectivity, leveraged by collaborating systems running on the ever smaller and more powerful hardware devices we’ve already come to expect. Microsoft .NET is a wakeup call, and some have missed it. To flourish in the coming years, mission-critical corporate software systems such as ERP must be designed from the ground up for connectivity and integration, delivering maximum corporate agility at the lowest possible cost.”

    Hansen wrote this in a white paper published in 2003, “Why .NET Technology is Important for ERP,” and I find it interesting that I am still explaining some of these things today.

    Now we are ready for the good stuff. I can’t remember how many times I’ve been asked to compare or contrast NAV and AX or make a recommendation for a prospect, but it is probably at least 100 times. This will be the first time I do it in public with the gloves off. During the next two weeks, I’m going to focus on them individually, giving you my impressions of their strengths and then we’ll wrap up with how the comparison has changed over time and may change again in the future. What I can tell you in advance is that they are both better than the other.  I believe MSFT has been very smart in continuing the development of both products and in the direction they are taking them. I believe that the directions the products are taking give us the opportunity to more clearly define the “line of demarcation” where a product’s strengths are leveraged and its weaknesses are less likely to be a liability. In other words, we should now be able to provide better advice to our clients when helping them decide on the proper approach for right-sizing ERP.

    Until then, I invite you to consider Dynamics CRM and try to envision ERP done like that.

    Peter Joeckel is the President and Founder of TurnOnDynamics a Microsoft Dynamics Partner servicing Texas, Oklahoma, Louisiana and Arkansas (TOLA) manufacturing firms. TurnOnDynamics has extensive experience with Microsoft Dynamics GP, NAV and AX.

    TurnOnDynamics focuses on the strategic concerns of executives and owners with a unique Dynamic CFO Service.

    Thom Doss has a long and distinguished career in the ERP software field. He has worked in the partner (VAR) community, at Microsoft, and has been on the customer side of the fence. He is a certified developer on a number of platforms, including Dynamics NAV and Dynamics AX. He is also a MCSD, a MCDBA and works with clients and partners to leverage SharePoint and Dynamics CRM in the context of their ERP implementations.

    Thom is available on interesting projects that concern manufacturing, sophisticated but troubled Microsoft Dynamics NAV implementations, and Dynamics NAV to AX projects. He can be contacted directly by leaving a note here or on his LinkedIn page.

    by TurnOnDynamics

    Ask This Expert a Question / Leave a Comment


    Show Buttons
    Hide Buttons