turnondynamics.com

Technology and ERP – the Productivity Conundrum

Thu, 27 Aug 2020 18:56:00 GMT

A Major Step in Reversing Years of Failure

I am pleased to present a technology that dramatically improves ERP Software Productivity. The HandsFreeERP Document Automation Platform

Accounting software, as it was known back in the day, is one of those “things” where the application of technology did not improve the core product. Think sensors for sinks that have you waving your arms about wildly trying to get a quick burst off the too hot or too cold water, and you get a general idea. Too much arm waving—not enough process flow. Cool tech, lukewarm results.

During my life in the ERP industry, there have been multiple advances in technology that have had the opposite of the intended effect. “Upgrades” that made the software harder to use, more expensive to install, maintain, and upgrade. “Automation” that just shifted the burden from an end user to IT—or to a service bureau.

If cars evolved similarly, each new model year would feature a more powerful (and “easy to use”) hand brake permanently locked in the on position.

The mouse, graphic user interface, and most recently, a browser interface are some prime examples of crimes committed against ERP productivity all packed up as “a better user experience.”

NOW, finally, after thirty years, I am pleased to present a technology that dramatically improves ERP Software Productivity.

How? By overcoming the biggest bottlenecks in ANY business process—the mouse, the keyboard and the re-entering of data from documents and emails.

The Right Technology, and NOW the Right Problem Solved

And up until now, this technology solution has largely been misappropriated for one niche application—the processing of accounts payable invoices.

The HandsFreeERP Document Automation Platform is based on tried and true technology most often used for AP Automation, BUT that has NOW been applied to more critical business process that suffer from the same bottlenecks and pain points. Like handling customer orders, so you can fill orders more efficiently and bring cash IN the door more quickly.

The HandsFreeERP Document Automation Platform opens up capabilities such as customer orders or “AR” Automation and other target-rich document automation opportunities. TurnOnDynamics is pleased to announce that we are the premier implementation partner for the HandsFreeERP platform.

The post Technology and ERP – the Productivity Conundrum appeared first on turnondynamics.com .

The Dynamics GP to Business Central Assessment Process

Wed, 24 Jun 2020 20:58:00 GMT

The post The Dynamics GP to Business Central Assessment Process appeared first on turnondynamics.com .

Microsoft Dynamics GP to Business Central Upgrades Thoughts, Ep.3 – by TurnOnDynamics

Fri, 19 Jun 2020 14:30:00 GMT

EPISODE 3: CLOUD OPTIONS AND STRATEGIES

PART 3

Examining the Dynamics GP to Dynamics 365 BC upgrade conversation

In the first episode of this series about upgrade strategies for Microsoft Dynamics GP customers, Karen Riordan of Menlo Technologies and Peter Joeckel of TurnOnDynamics joined us to discuss the wide-ranging the experiences of these organizations and varied viewpoints they hold today when it comes to the much-hyped promise of moving from on-prem ERP to Dynamics 365 Business Central in the cloud.

On this second episode, we go deeper on the needs of GP customers today. The tens of thousands of GP customers in the world are a diverse group. Some have watched carefully as Microsoft and other vendors have released their new generation of ERP solutions, while others need someone to come in and start from the beginning on what cloud is all about. Peter and Karen agree that GP customers should expect their partners to take a consultative approach rather than acting as an extension of their IT team. And they discuss some of the signs that a company is a good candidate for moving to pure cloud ERP as opposed to some other alternative.

SHOW NOTES

2:15 – Why now is the time to talk about GP customer upgrade options
8:45 – Defining two of the unique reasons why GP customers are
motivated for a change
16:45 – Are GP customers moving to cloud hosting?
20:15 – Multi-tenancy – what it means that GP doesn't support it
22:45 – Peter makes the case for why GP to BC is not an upgrade
24:45 – Are GP users educating themselves?
28:45 – Why Karen is seeing interest in Intelligent Cloud
30:15 – Where should this series go from here?

The post Microsoft Dynamics GP to Business Central Upgrades Thoughts, Ep.3 – by TurnOnDynamics appeared first on turnondynamics.com .

Microsoft Dynamics GP to Business Central Upgrades Thoughts, Ep.2 – by TurnOnDynamics

Tue, 16 Jun 2020 20:20:00 GMT

EPISODE 2: ADVANCED STRATEGIES

PART 2

SHOW NOTES

1:00 – When talking about upgrades, why talk about the GP market’s decisions?
4:30 – Why don’t companies have a great understanding of what a newer ERP system can do for their businesses?
6:30 – The challenge of taking a consultative approach rather than a technical approach to ERP discussions
10:30 – Signs that an organization really needs to consider a new ERP
15:30 – What roles or groups tend to support new technology investments and why is there resistance in other areas?
19:30 – Distinguishing between different types of GP deployments and why the broad use means different future needs
22:30 – Why executive vision is the critical foundation to enterprise application investments, both for the organization and the success of an implementation partner
24:30 – How coronavirus has impacted the ERP and broader IT priorities of organizations

The post Microsoft Dynamics GP to Business Central Upgrades Thoughts, Ep.2 – by TurnOnDynamics appeared first on turnondynamics.com .

MICROSOFT DYNAMICS GP TO BC UPGRADES – CLOUD OPTIONS AND STRATEGIES

Thu, 04 Jun 2020 13:44:00 GMT

As an existing on-premise Microsoft Dynamics GP (GP) customer, if you have asked yourself the question, “why do I need to upgrade?” and the answer was to move to the cloud, then you have multiple options.

Those options may not be readily evident if you look at the current wave of Microsoft and GP partner marketing that distills the on-premise GP cloud option into a straightforward “Upgrade to Microsoft Dynamics Business Central (BC)” message.

Instead of focusing on that strategy exclusively, it can be informative to take a step back and look at the actual range of choices available to move an existing GP on-premise solution to the cloud.

Let’s start by thinking about the existing server or servers that are currently tucked into a spare closet or utility room in your office used to run your current on-premise GP implementation. The servers with the rat’s nest of wiring in the back that you pray never get accidentally unplugged. Cloud computing simplified just means sticking those servers and rats nest of wires into someone else’s closet and paying rent for them to “host” it for you.

Consider this; if you have a traditional GP on-premise implementation and like thousands of companies, have utilized a standard technology such as Remote Desktop Protocol (RDP) to have remote users “dial into” that on-premise system, then you are hosting GP in the cloud. You’re just not getting paid for it.

Here is the critical point, if you are happy with the business functionality that you are currently getting from your GP software, then there are much better options to move to the cloud than implementing a new ERP solution. Consider these options:

If your hardware is old and in need of a refresh, you can rent servers in the cloud, install your GP software on those hosted servers and access it remotely.
If your hardware is relatively new, you can locate your existing servers in a co-location company that specializes in having ideal environments to secure, monitor, and manage your hardware.
If you don’t want any of the headaches associated with maintaining your servers, then there is an excellent option of moving your GP implementation into a hosted environment run by companies that specialize in running traditional or existing GP solutions in the cloud for you.

Any of these solutions can be an acceptable long-term strategy or can buy critical time before making a move to a new ERP system. The new and improved commitment by Microsoft to supporting GP makes this a safe option if GP fits your requirements.

Upcoming podcasts will delve into the specifics behind each decision of these cloud decisions and provide valuable insights to help you make a more informed choice.

The post MICROSOFT DYNAMICS GP TO BC UPGRADES – CLOUD OPTIONS AND STRATEGIES appeared first on turnondynamics.com .

Microsoft Dynamics GP to Business Central Upgrades Thoughts: Consider all of your options

Mon, 25 May 2020 18:16:00 GMT

As the ERP landscape has shifted over the years, consultants that started in the same place have followed a different paths in terms of the products, industries, and clientelle. For a couple of Great Plains OGs like us, our individual journeys have led to interesting differences in how we view the current ERP upgrade landscape, especially for today’s Microsoft Dynamics GP users.

One of us (Peter) has spent the better part of two years deeply immersed in the Microsoft Dynamics AX to D365 F&O conversation , with very little visibility into the effort to migrate from Dynamics GP users to Dynamics 365 Business Central (BC). The other (Karen) has had more of a traditional GP partner career, staying the course and now helping companies make the transition to BC.

What we both found fascinating since recently re-connecting were the alternative views we brought to the GP-to-BC discussion, and how our individual Dynamics GP histories shaped our thinking in several critical areas:

What does the future hold for GP customers and the GP partner channel?
What are an organization’s critical ERP requirements for the future?
What are the critical factors that go into the decision making process for a GP customer planning their future?

The discussion regarding GP to BC upgrades came up casually at first. The tone of the conversation changed as we discussed the considerations and options that we do not see in the current migration marketing push.

Here are our key takeaways, distilled from conversations that spanned several hours:

Upgrades from Dynamics GP to BC are not a one size fits all proposition. There are dramatic and nuanced factors that we do not see discussed in the general messaging.
GP customers would be best served if educated on a broader set of options presented to them when considering an upgrade.

Our guidance suggests that the first question a Dynamics GP customer should ask is, “why am I upgrading”? The answer could be one or more of the following:

I have outgrown my GP software, and it is hindering the growth of my business.
I want to move my ERP solution to the cloud.
I am following Microsoft’s or my GP partner’s messaging.

Next, the following are essential upgrade factors to consider:

There are no upgrades to a new ERP platform. With today’s complex ERP systems, “upgrade” is more of a marketing term than an exact technical definition. Even within product lines themselves, upgrades are now re-implementations. Also, upgrade toolsets are, in reality, often just generic spreadsheets and marketing hype with little technical substance.
There are significant functional and technical reasons why companies outgrow GP . If that is the case, then it is critical not to make an incremental ERP move that does not address all of those technical and functional issues.
If the primary motivation for a GP upgrade is to move your on-premises implementation to the cloud, then a better solution may be to host your existing GP system. This solution can buy critical time before making a move to a new ERP system or be a permanent solution if the proposed Microsoft life span for GP fits your requirements.

The most important takeaway is that all upgrades are complicated and expensive. The real cost of the upgrade is never the cost of the new software, that is just the tip of the iceberg. In making that decision for your company, consider all of your options carefully and do not base that critical business decision on marketing materials promoting the latest shiny toy.

The post Microsoft Dynamics GP to Business Central Upgrades Thoughts: Consider all of your options appeared first on turnondynamics.com .

Microsoft Dynamics GP to Business Central Upgrades Thoughts, Ep.1 – by TurnOnDynamics

Mon, 25 May 2020 15:16:00 GMT

EPISODE 1: CONSIDER ALL OF YOUR OPTIONS

PART 1

Our guests on this episode, Karen Riordan of Menlo Technologies and Peter Joeckel of TurnOnDynamics , walk us through some of the reasons today’s on-premises SMB ERP customer may be tomorrow’s SaaS enterprise ERP customer – or not.

2:00 – Karen’s background in the ERP channel
3:00 – On being challenged to think about more than just Business Central for today’s GP customers
5:00 – When a GP customer should stay on GP
7:45 – Microsoft’s advantage by improving GP to BC cloud migrations
11:00 – The importance of master data cleanup
14:00 – Why GP customers may not be aware of the extent of the customization and ISV add-on solutions in their ERP
18:30 – Consolidating legacy systems
20:30 – Why leaving GP ought to be a move to the cloud in some form – whether BC, F&O, or another

What does the future hold for GP customers and the GP partner channel?
What are an organization’s critical ERP requirements for the future?
What are the critical factors that go into the decision making process for a GP customer planning their future?

Here are our key takeaways, distilled from conversations that spanned several hours:

Upgrades from Dynamics GP to BC are not a one size fits all proposition. There are dramatic and nuanced factors that we do not see discussed in the general messaging.
GP customers would be best served if educated on a broader set of options presented to them when considering an upgrade.

Our guidance suggests that the first question a Dynamics GP customer should ask is, “why am I upgrading”? The answer could be one or more of the following:

I have outgrown my GP software, and it is hindering the growth of my business.
I want to move my ERP solution to the cloud.
I am following Microsoft’s or my GP partner’s messaging.

Next, the following are essential upgrade factors to consider:

There are no upgrades to a new ERP platform. With today’s complex ERP systems, “upgrade” is more of a marketing term than an exact technical definition. Even within product lines themselves, upgrades are now re-implementations. Also, upgrade toolsets are, in reality, often just generic spreadsheets and marketing hype with little technical substance.
There are significant functional and technical reasons why companies outgrow GP . If that is the case, then it is critical not to make an incremental ERP move that does not address all of those technical and functional issues.
If the primary motivation for a GP upgrade is to move your on-premises implementation to the cloud, then a better solution may be to host your existing GP system. This solution can buy critical time before making a move to a new ERP system or be a permanent solution if the proposed Microsoft life span for GP fits your requirements.

The post Microsoft Dynamics GP to Business Central Upgrades Thoughts, Ep.1 – by TurnOnDynamics appeared first on turnondynamics.com .

Microsoft Dynamics GP to BC Upgrades – Advanced Strategies

Mon, 11 May 2020 15:41:00 GMT

The messaging from Microsoft and the general Microsoft Dynamics GP (GP) partner community is that the optimal upgrade option for GP users is a natural choice: upgrade to Microsoft Dynamics Business Central (BC).

Listen to the MSDynamicsWorld podcast hosted by Jason Gumpert that discusses how that message misses several vital options that lead to a better solution based on your business requirements and plans.

Listen in as Jason, Karen Riordan, Vice President of Sales & Marketing at Menlo-Technologies and Peter Joeckel, President of TurnOnDynamics, Dynamics ERP industry veterans, as they discuss GP to BC upgrade strategies from their unique perspective.

Listen as Karen and Peter discuss a more complete and nuanced approach to the GP to BC upgrade question.

A COMPLETE STRATEGY

A more realistic GP to BC decision tree looks like the following and contains three significant decisions forks to help will determine the optimal “upgrade route” or strategy:

DECISION 1 – UPGRADE?

Our guidance suggests that the first question a Dynamics GP customer should ask is, “why am I upgrading”? The answer could be one or more of the following:

I have outgrown my GP software, and it is hindering the growth of my business.
I want to move my ERP solution to the cloud.
I am following Microsoft’s or my GP partner’s messaging.

DECISION 2 – CLOUD?

Is the primary motivation for a GP upgrade is to move your on-premise implementation to the cloud? Assuming that you are happy with the business functionality that you are currently getting, that leaves us with three options:

Locate your existing servers (or upgrade) in a co-hosting environment.
Move your GP to hosted servers.
A better solution may be to have your GP hosted by a company specializing in hosting your existing GP system.

These solutions can buy critical time before making a move to a new ERP system or can be a permanent solution if the proposed Microsoft life span for GP fits your requirements.

DECISION 3 – REQUIREMENTS?

If the determination has is to upgrade to a new ERP platform, then several important questions should be answered.

It is critical to understand that there are no simple upgrades to a new ERP platform in the SMB world. With today’s complex ERP systems, “upgrade” is more of a marketing term than an exact technical definition. Even within product lines themselves, upgrades are now some flavor of re-implementations.

Upgrade toolsets are becoming more powerful and user friendly but come with limitations that may be critical, especially in larger, more sophisticated implementations that require enterprise-level ERP platform capabilities.

There are significant functional and technical reasons why companies outgrow GP. If that is the case, then it is critical not to make an incremental ERP move that does not address all of those technical and functional issues.

Upcoming podcasts will delve into the specifics behind each decision and provide valuable insights to help you make a more informed choice.

Peter Joeckel, President of TurnOnDynamics, a Microsoft Dynamics consultancy specializing in providing senior functional and technical resources for Microsoft Dynamics AX/D365 upgrade and rescue projects.

The post Microsoft Dynamics GP to BC Upgrades – Advanced Strategies appeared first on turnondynamics.com .

Dynamics GP to BC Upgrades Thoughts

Tue, 05 May 2020 15:35:00 GMT

Consider ALL of your Options

Having spent the better part of two years deeply immersed in the Microsoft Dynamics AX to D365 F&O conversation , I have had very little visibility into the effort to migrate from Dynamics GP users to Dynamics 365 Business Central (BC). That changed dramatically during a series of conversations with my new favorite Dynamics GP partner, Karen Riordan, the VP Sales & Marketing for Menlo Technologies.

What I found fascinating were the alternative views we brought to the GP to BC discussion, and how our individual Dynamics GP histories shaped our thinking in several critical areas:

What does the future hold for GP customers and the GP partner channel?
What are the critical factors to consider when deciding your companies ERP future?
What are the critical factors that go into the decision making process for a GP customer planning their future?

In summary, we are both Great Plains OGs whose companies took different paths. Karen is more of a traditional GP partner that stayed the course and is now helping companies make the transition to BC. My Great Plains adventure took a different route, moving me first to Dynamics AX and now Dynamics D365 F&O.

Here are our key takeaways distilled from conversations that spanned several hours:

Upgrades from Dynamics GP to BC are not a one size fits all proposition. There are dramatic and nuanced factors that we do not see discussed in the general messaging.
GP customers would be best served if educated on a broader set of options presented to them when considering an .

Our guidance suggests that the first question a Dynamics GP customer should ask is, “why am I upgrading”? The answer could be one or more of the following:

I have outgrown my GP software, and it is hindering the growth of my business.
I want to move my ERP solution to the cloud.
I am following Microsoft’s or my GP partner’s messaging.

Next, the following are essential upgrade factors to consider:

There are no upgrades to a new ERP platform. With today’s complex ERP systems, “upgrade” is more of a marketing term than an exact technical definition. Even within product lines themselves, upgrades are now re-implementations. Also, upgrade toolsets are, in reality, often just generic spreadsheets and mostly marketing hype with no real technical substance.
There are significant functional and technical reasons why companies outgrow GP . If that is the case, then it is critical not to make an incremental ERP move that does not address all of those technical and functional issues.
If the primary motivation for a GP upgrade to move your on-premise implementation to the cloud, then a better solution may be to host your existing GP system. This solution can buy critical time before making a move to a new ERP system or be a permanent solution if the proposed Microsoft life span for GP fits your requirements.

Karen Riordan, VP Sales & Marketing for Menlo Technologies , a Quisitive Information Technology & Services company.

Peter Joeckel , President of TurnOnDynamics , a Microsoft Dynamics consultancy specializing in providing senior functional and technical resources for Microsoft Dynamics AX/D365 upgrade and rescue projects.

The post Dynamics GP to BC Upgrades Thoughts appeared first on turnondynamics.com .

The Hidden Cost of Cloud ERP Software

Fri, 07 Feb 2020 13:15:00 GMT

The latest application of technology to enterprise resource planning software (ERP) is the magic of the cloud. Sales and marketing literature touts a long list of benefits derived from moving ERP and related software from on-premises hardware to the cloud.

The point of this article is not to discuss the technical benefits of a move to the cloud. Instead, it is to examine a serious unintended consequence having a dramatic impact on ERP implementation projects.

Traditionally there is a high rate of failure for enterprise ERP software projects that are glossed over by software publishers and implementation partners.

A quick internet search will confirm that billion-dollar ERP implementation project failures do occur. That is billion with a B. As Lewis Black famously noted in another context, “what were they doing, building their own space program”?

It has long been my contention that ERP project success is based on three simple criteria: on-time, on-budget, and delivering promised functionality. There has never been a successful ERP implementation project, and cloud ERP licensing will add to the problem.

How can license policies possibly affect implementation quality? In short, subscription licensing, and the resulting loss of attractive perpetual license margins, means less money for partners to defray the high cost of selling and marketing ERP projects. This shift puts significant downward pressure on implementation quality and success.

My first exposure to cloud ERP licensing models immediately raised the specter of higher rates of challenged and failed projects. Anecdotal evidence and empirical data starting to leak out from the partner community supports this premise, but at a much higher rate than initially thought.

Let’s look at the most glaring problem first.

Enterprise ERP software is The sales are typically highly competitive, with multiple solutions and even different partners for the same solution competing over long and expensive sales cycles. This highly competitive, lengthy, and expensive sales process leads to the inevitable bad behavior when “closing” deals:

Discounting to win deals against the competition
Software publisher pressure to close deals by quarter or year-end to meet sales forecasts. This is often tied to the need to meet expectations that directly impact stock prices at a company level and sales performance-related bonuses at an individual level.
Underestimated implementation budgets and the level of effort required to complete a project successfully.
Exaggerated functional capabilities that are often expensive or impossible to achieve. For example, “Now you can run your company from your phone”!

In the on-premises ERP days, the high cost of sales was offset or fully funded by the margin associated with the initial software sale. Additionally, annual maintenance renewals also provided a source of income for partners that provided a nice base of consistent income for well-run partners.

The partner margins on cloud ERP software sales have two distinct disadvantages:

The actual dollars are significantly smaller or non-existent in relation to the .
What little margin is provided by the publisher is now spread over an extended period of time.

This is a dramatic shift for partners looking to stay viable in an increasingly competitive and complex market. They will continue to feel even more pressure to sell new deals for the services revenue, which has the potential to create a spiral of more projects sold with unrealistic budgets, implementation timelines, and functional expectations. , more failed or challenged projects.

The question is, at what point do these implementation failures “swamp the boat” and sink a product line?

I have thoughts on how to reverse this trend and will share them in a future post, and I would love to hear your thoughts.

Peter Joeckel , President of TurnOnDynamics, a Microsoft Dynamics consultancy specializing in providing senior functional and technical resources for Microsoft Dynamics AX/D365 upgrade and rescue projects.

The post The Hidden Cost of Cloud ERP Software appeared first on turnondynamics.com .

Microsoft Dynamics AX to D365 Upgrade Journeys, PART 12: MORE ISV THOUGHTS

Thu, 12 Dec 2019 19:58:00 GMT

EPISODE 12: MORE ISV THOUGHTS

Our second “ISV Role” podcast features Luciano Cunha and the challenges he faces as the Global CEO of a leading ISV with products that “live inside” of the D365 FandO code. He provides invaluable insight, especially for enterprise-level AX customers contemplating the upgrade to Dynamics D365 for FandO process.

The post Microsoft Dynamics AX to D365 Upgrade Journeys, PART 12: MORE ISV THOUGHTS appeared first on turnondynamics.com .

Microsoft Dynamics AX to D365 Upgrade Journeys, PART 11: SURPRISING INPUT FROM A MICROSOFT SHOP

Thu, 12 Dec 2019 19:46:00 GMT

EPISODE 11: SURPRISING INPUT FROM A “MICROSOFT SHOP”

Darren Goebel runs a “Microsoft Shop” with a long-time investment in AX with significant manufacturing requirements. Darren provides the most honest technical and functional overview regarding his detailed D365 FandO upgrade research leaving him with a difficult decision regarding his ERP direction.

The post Microsoft Dynamics AX to D365 Upgrade Journeys, PART 11: SURPRISING INPUT FROM A MICROSOFT SHOP appeared first on turnondynamics.com .

When NOT to Upgrade from Microsoft Dynamics AX to D365 Fast 5 Factors to Consider by TurnOnDynamics

Fri, 01 Nov 2019 15:04:00 GMT

The post When NOT to Upgrade from Microsoft Dynamics AX to D365 Fast 5 Factors to Consider by TurnOnDynamics appeared first on turnondynamics.com .

D365 Upgrade Success Lessons Learned by TurnOnDynamics

Fri, 01 Nov 2019 15:03:00 GMT

The post D365 Upgrade Success Lessons Learned by TurnOnDynamics appeared first on turnondynamics.com .

Fast Five Questions to Ask Before Upgrading to D365

Fri, 01 Nov 2019 15:01:00 GMT

The post Fast Five Questions to Ask Before Upgrading to D365 appeared first on turnondynamics.com .

Fast Five Keys to Accurately Quoting Your D365 Upgrade

Fri, 01 Nov 2019 14:57:00 GMT

The post Fast Five Keys to Accurately Quoting Your D365 Upgrade appeared first on turnondynamics.com .

Microsoft Dynamics AX to D365 Upgrade Journeys, PART 10: THE ISV ROLE

Wed, 18 Sep 2019 15:57:00 GMT

EPISODE 10: THE ISV ROLE

If an AX to D365 upgrade is complex and expensive, imagine the life of the ISV. Listen to issues facing ISV partners and how those can inform your upgrade plans.

The post Microsoft Dynamics AX to D365 Upgrade Journeys, PART 10: THE ISV ROLE appeared first on turnondynamics.com .

Microsoft Dynamics AX to D365 Upgrade Journeys, PART 9: AXSMB’S

Mon, 17 Jun 2019 02:35:00 GMT

EPISODE 9: AXSMB’S

Microsoft Dynamics AX to Dynamics D365 for Finance and Operations upgrades are complex and expensive. This presents a problem for those small and medium sized companies that implemented AX because they required the advanced functionality of an enterprise platform. The cost and complexity for an upgrade is a particularly difficult challenge for this group of companies.

STUCK IN THE MIDDLE? EXAMINING THE TYPICAL AXSMB’S ERP LIFE-CYCLE

The typical life-cycle of a business sees it implement three ERP systems. QuickBooks, an “Upgrade” to QuickBooks and finally a “Real” system. This is at least one, if not two systems too many.

Over the last decade an “AXSMB” was the term used for that special class of company that had “champagne requirements but a beer budget.” These were companies that would have loved to be on QuickBooks or Dynamics GP based on their budget. However, because of sophisticated business requirements that could only be met with an enterprise-level ERP solution, bit the bullet and made the investment to step up to Microsoft Dynamics AX.

From a strategic standpoint, I always talk to my clients about the real cost of a software implementation. My favorite quote from such a client was, “We did not make this investment for who we are as a company today but who we plan to be in the future.”

THE TRADITIONAL PATH

The typical reason for following the traditional ERP system trajectory is cost. However, I see that as being shortsighted and self-defeating for an individual company as well as an industry. The direct costs of ERP software and the implementation services are only the tip of the iceberg. The real cost also includes the time and effort to implement—and then re-implement the system later. That does not consider the lost opportunity costs of systems that restrict growth and provide poor information in the meantime. A typical ERP implementation is a long and exhausting effort that no one undergoes for fun or vanity.

There is a predictable lifecycle for ERP that any growing company recognizes:

The Startup or QuickBooks phase
The “we are torturing QuickBooks” phase, a.k.a. “Let’s move to a mid-market solution such as Dynamics GP”
The “we went from being a ‘company’ to an ‘enterprise’ and need an ERP platform like Dynamics AX” phase

While it may be true that the licensing cost for an enterprise-level ERP solution looks daunting to a growing company looking to upgrade from QuickBooks, the fact is that it may be dramatically more cost-effective if analyzed in terms of opportunity costs:

The lost growth in business reflected by an ERP solution that does not serve as a strategic tool
The real cost of doing another software upgrade when the software cost is deemed to be acceptable for a true Enterprise level platform

Over time, some of these AXSMBs have grown into their AX implementations because of business expansion and growth that they were ready to execute on thanks in part to their enterprise-level ERP solution. The companies that have not experienced the type of growth that would have justified the cost of maintenance and upgrades find themselves in a tricky situation. Especially those with heavily modified systems.

PICKING THE RIGHT UPGRADE PATH

For smaller AX customers, the struggle is one of picking the right upgrade path:

Do nothing until the current software becomes inoperable?
Switch to a new ERP solution.
Stabilize on the latest version of AX. Port modifications or hope that the latest and greatest version can meet your requirements.
Upgrade to D365FO with a commitment to go “vanilla.”
Bite the bullet and upgrade to D365FO with an upgrade of your existing customizations.

The costs of upgrades are especially high for smaller companies with extensive requirements. The task of estimating the number of deprecated objects can be daunting if you fall below the 150-user threshold required to have a dedicated Microsoft solution architect work with you during an upgrade to Dynamics 365 for Finance and Operations . Or you may not want to make the investment in the 20-user minimum D365FO license to use the tools provided in LCS.

Regardless of the ultimate decision, one fact is clear: champagne requirements on a beer budget often lead to painful business decisions when it comes to the AXSMBs.

Listen to Episode 9 of our co-hosted MSDynamicsWorld podcast as we interview two of these AXSMBs and learn about their journey and decision-making process.

The post Microsoft Dynamics AX to D365 Upgrade Journeys, PART 9: AXSMB’S appeared first on turnondynamics.com .

Stuck in the Middle? Examining the Typical AXSMB’s ERP Life-Cycle

Wed, 29 May 2019 12:28:00 GMT

The Traditional Path

There is a predictable lifecycle for ERP that any growing company recognizes:

The Startup or QuickBooks phase
The “we are torturing QuickBooks” phase, a.k.a. “Let’s move to a mid-market solution such as Dynamics GP”
The “we went from being a ‘company’ to an ‘enterprise’ and need an ERP platform like Dynamics AX” phase

The lost growth in business reflected by an ERP solution that does not serve as a strategic tool
The real cost of doing another software upgrade when the software cost is deemed to be acceptable for a true Enterprise level platform

Picking the Right Upgrade Path

For smaller AX customers, the struggle is one of picking the right upgrade path:

Do nothing until the current software becomes inoperable?
Switch to a new ERP solution.
Stabilize on the latest version of AX. Port modifications or hope that the latest and greatest version can meet your requirements.
Upgrade to D365FO with a commitment to go “vanilla.”
Bite the bullet and upgrade to D365FO with an upgrade of your existing customizations.

Regardless of the ultimate decision, one fact is clear: champagne requirements on a beer budget often lead to painful business decisions when it comes to the AXSMBs.

Listen to Episode 9 of our co-hosted MSDynamicsWorld podcast as we interview two of these AXSMBs and learn about their journey and decision-making process.

The post Stuck in the Middle? Examining the Typical AXSMB’s ERP Life-Cycle appeared first on turnondynamics.com .

Microsoft Dynamics AX to D365 Upgrade Journeys, Part 8: FastTrack

Tue, 14 May 2019 14:33:00 GMT

EPISODE 8: OVERVIEW OF THE MICROSOFT FASTTRACK PROGRAM

Possibly the crown jewel in our upgrade podcast series where we talk to Microsoft engineers that work on upgrade projects daily and get their input on challenges and best practices.

The post Microsoft Dynamics AX to D365 Upgrade Journeys, Part 8: FastTrack appeared first on turnondynamics.com .

Microsoft Dynamics AX to D365 Upgrade Journeys, Part 7: Hosting and cloud services

Fri, 03 May 2019 02:30:00 GMT

EPISODE 7: HOSTING AND CLOUD SERVICES

With Microsoft hoping to move everyone onto their cloud the question arose what place is there for private cloud providers in this brave new world. Surprisingly, there are many opportunities.

The post Microsoft Dynamics AX to D365 Upgrade Journeys, Part 7: Hosting and cloud services appeared first on turnondynamics.com .

Microsoft Dynamics AX to D365 Upgrade Journeys, Part 6: The Constrained Enterprise Conundrum

Mon, 08 Apr 2019 02:26:00 GMT

EPISODE 6: A USER’S CLOUD JOURNEY, WITH A WAYPOINT

Typically, an upgrade project is linear, moving from the current version of the software to the latest and greatest upgrade. We discovered unexpected paths and options from customers and prospects forging their own path.

While researching a long forgotten arcane technical detail for an ongoing Microsoft Dynamics AX to Dynamics 365 for Finance and Operations (D365FO) project I came across the following upgrade graphic:

Holy sheet rock, Robin!

I sure wish I had seen this earlier. The client would have appreciated it as well. We could have replaced our 500+ line project plan and daily project update calls, had we only known about this plan!

Considering that the project I was working on at this time was a fairly straightforward financials upgrade with limited customizations and integrations, my mind flashed to the challenges faced by other implementations, those with enterprise-grade complexity including many or all of the following issues:

A broad functional footprint, distribution and manufacturing being good examples.
Heavily customized code impacting critical business processes.
Multiple sites, languages, currencies, etc.
Intricate and often fragile integrations with legacy systems and antiquated hardware.
Large user numbers.

The typical AX implementation with these characteristics falls into the middle of the following company size spectrum:

The post Microsoft Dynamics AX to D365 Upgrade Journeys, Part 6: The Constrained Enterprise Conundrum appeared first on turnondynamics.com .

Microsoft Dynamics AX to D365 Upgrade Journeys, Part 5: The value of project management

Fri, 08 Mar 2019 02:22:00 GMT

EPISODE 5: PROJECT MANAGEMENT FROM THE FRONT LINE

If you have a hard go-live date but no project plan and project manager that adjusts the critical path daily your project will fail. Listen to actual partner and client project managers discuss their challenges mid-project.

As experienced project managers tend to do, I was reflecting recently on some the well-worn wisdom that seems to bring comfort to people in our role, for example:

The fact that nine women cannot have a baby in one month, aka the critical path concept of project planning, and;
The Goldilocks concept of project management – what is the right amount for projects of varying size and scope.

In the Microsoft Dynamics AX and Dynamics 365 for Finance and Operations (D365FO) world I have seen project teams ignore one or both of these concepts. A partner in a national firm once told me that project management is a waste of time when I asked him about how he could improve his probability of success. His firm had just overseen two failed go-live attempts and an implementation budget that had ballooned from $200k to over a million dollars, much to the client’s delight. On the flip side, I have friends in the industry that are full time project managers on AX and D365FO implementation and upgrade projects. Most of their projects are significantly over budget.

So, what is the answer?

In my experience, the project manager, and the wider project management function in our industry, is mainly a clerical function. Even on projects that have full time professional project managers I see very little push back on scope creep and unreasonable mid-project requests from clients.

Project managers must have the experience and the authority to identify the critical path of a project, the available resources at their disposal, and be able to manage specifically to those constraints and, more importantly, customer expectations. These responsibilities are a key discussion point in part 5 of our D365FO upgrade journeys podcast series.

Ironically, I see the new and improved D365FO business model, with its strong trend toward the public cloud, as adding additional stress on the project management function in two specific areas:

The post Microsoft Dynamics AX to D365 Upgrade Journeys, Part 5: The value of project management appeared first on turnondynamics.com .

Dynamics AX to D365: Hybrid Model

Thu, 28 Feb 2019 00:09:00 GMT

It’s ALL About a Complete Cloud Strategy!

The critical infrastructure question we have had to address for companies contemplating an AX to D365 upgrade has to do with on premise data collection. Distribution companies with bar coded inventory control, manufacturers with shop floor data collection stations or retailers with point of sale cash registers all have some local requirement to capture, store and update data if their connection to the cloud ERP system goes down or has latency issues.

In speaking to Ken Edwards on our AX to D365 podcast series focused on considerations for the hybrid infrastructure model he posits out that the infrastructure requirements for D365 are just a part of the puzzle. In his words, the fait accompli of businesses moving all of their business applications to the cloud, it is critical for organizations to develop a complete cloud strategy that includes legacy systems.

Ken Edwards, Director of Delivery at Centric Consulting, is in a unique position to understand these requirements. Before joining Centric, Ken had overseen the AX deployments at two large, multinational, multi-site manufacturing companies.

With his industry insight, his message is that for those companies thinking they are better suited for on premise solution or unable to move to cloud, it is time to start a strategy now. For those looking to move to the cloud, the industry is moving very quickly and the longer you wait, the more it will cost later.

With all the focus on the cloud, Ken still sees reasons for on-premise implementations.

AX to D365 Hybrid Model Blog

AX to D365 Hybrid Model Podcast

The post Dynamics AX to D365: Hybrid Model appeared first on turnondynamics.com .

ABOUT THE AUTHOR

Dynamics AX to D365: Pricing

Tue, 26 Feb 2019 00:29:00 GMT

Does Cloud Pricing Make Your Company Less Valuable?

The sticker shock and lack of tools available to develop accurate AX to D365 upgrade costs have been the biggest takeaways for me regarding pricing.

The upgrade “Price” podcast, featuring Kenny Mullican, added significantly to my understanding of the mindset of a customer evaluating such a significant project.

As the CIO of Paragon Films in Tulsa Oklahoma, Kenny has a significant number of technical, functional and financial considerations to juggle as he plans out his company’s upgrade path. His thoughts on the subject during the pricing podcast are well worth the listen. As he recently recapped:

There is not a lot of information about what it takes to upgrade from AX 2012 to D365. There seem to be plenty of companies implementing D365, but harder to find success stories of upgrades.
Hard to judge what it will cost. Estimates are all over the board. Could it be more than the original implementation?
Verdict still out on viability of total cloud solution for manufacturing, yet Microsoft seems to be pushing everyone that way – not necessarily making it easy or desirable to do on-premise or a hybrid approach.
D365 is still playing catch-up on some features that were already there in AX 2012 but missing in D365.

As a non-finance, non-accounting guy, my favorite takeaway was his discussion on how OPEX versus CAPEX costs can have dramatic impacts on the upgrade decision making process.

Thank you, Kenny, for the great input!

Read the AX to D365 Pricing BLOG

Listen to the full AX to D365 Pricing PODCAST

The post Dynamics AX to D365: Pricing appeared first on turnondynamics.com .

ABOUT THE AUTHOR

Microsoft Dynamics AX to D365 Upgrade Journeys, Part 4: Hybrid model considerations

Mon, 18 Feb 2019 14:19:00 GMT

EPISODE 4: HYBRID MODEL CONSIDERATIONS

Yes, the cloud is “amazing” but what happens when you have operations that run 24/7/365 or shop floor control devices that must talk to that cloud over sketchy internet connections? A sales answer to this question could ground your business.

Editor’s Note: This article coincides with part 3 of our new podcast series on AX to D365FO upgrades.

The post Microsoft Dynamics AX to D365 Upgrade Journeys, Part 4: Hybrid model considerations appeared first on turnondynamics.com .

Microsoft Dynamics AX to D365 Upgrade Journeys, Part 3: Understanding the cost

Fri, 08 Feb 2019 10:17:00 GMT

EPISODE 3: UNDERSTANDING THE COST

AX to D365 projects are complicated and expensive. Unfortunately, few people understand the true costs involved. We dig into the details.

Editor’s Note: This article coincides with part 3 of our new podcast series on AX to D365FO upgrades.

The post Microsoft Dynamics AX to D365 Upgrade Journeys, Part 3: Understanding the cost appeared first on turnondynamics.com .

Dynamics AX to D365 Upgrades

Wed, 06 Feb 2019 18:12:00 GMT

The upgrade process from Microsoft Dynamics AX to Microsoft Dynamics D365 for Finance and Operations is a unique in terms of the scope of decisions and cost. It includes critical decisions not encountered in a typical upgrade process to the extent it is on these projects including:

Platform
Cost
Technology
Functionality

Each must be considered carefully. For example, the pricing for AX to D365 upgrades has been a major shock for companies!

While every upgrade project is unique, there is a base of commonality that if addressed correctly can increase the probability of project success while reducing risks and cost.

It is not uncommon that upgrade quotes from AX to D365 for Finance and Operations are from one to one and a half times the size of the original implementation costs. Those are the pure service costs. It does not include the license and new hardware costs for on-premise implementations or the monthly user fees for cloud deployments.

Understandably, this creates enthusiastic and spirited feedback form potential customers.

In addition to the obvious sticker shock we are seeing a lack of focus and specific tools and processes for developing accurate quotes upgrade quotes.

In my experience, the success of the D365 for Finance and Operations product line has stressed the number of competent technical resources available to deliver consistently excellent projects. With the focus on “net new” sales the time and resources allocated to upgrade projects often gets relegated to the back burner. If not in the sales and project quoting process, then definitely in the staffing of resources in the delivery phase.

As a result, we have seen upgrade quotes that consist of a simple spreadsheet that in just over a dozen rows and columns lays out resources and monthly billing totals per resource. No detail as to the tasks that each resource will be responsible for. Never mind a detailed project plan with an analysis of critical project milestones or critical path analysis.

In one case, a multi-million-dollar quote was literally delivered as an estimate based on industry experience. I believe that the bank routing information for the project deposit included more detail.

We have found that the most accurate methodology for preparing an upgrade proposal is to start with a detailed technical analysis of the objects that are required to be upgraded. Objects come in different categories and not all objects are created equally. This requires one to have the ability to not only count the number of objects that must be upgraded but also the relative work effort required for each object under consideration. With hundreds of objects to consider on a typical upgrade project we have had to develop software IP to speed up this process. Manual inspection is too time consuming.

For the technically uninitiated, Dynamics AX objects that must be upgraded include:

Forms
Reports
Classes
Custom objects
Custom integrations
Custom functionality

After objects, what are the next big variables that must be reviewed and quoted for an accurate upgrade project? Typically, these include:

ISV’s and 3rd party solutions
Integrations with legacy, proprietary and/or other business systems
Business processes and operations
Breadth of functionality used (for example, are we a GLAPAR customer or a global manufacturer)
Technical capability of the client
Client users base and subject matter experts SME
Infrastructure

Each one of these could easily be a topic for a full blog post and associated podcast.

Giving a quick review on a topic that will be covered in greater detail in an upcoming project management discussion:

Q: What is the one guaranteed method for preventing upgrade quote growth due to scope creep?

A: Don’t upgrade.

For more details regarding our unique qualifications for AX to D365 Upgrades.

The post Dynamics AX to D365 Upgrades appeared first on turnondynamics.com .

Microsoft Dynamics AX to D365 Upgrade Journeys, Part 2: Choosing a deployment model

Thu, 31 Jan 2019 13:28:00 GMT

EPISODE 2: CHOOSING A DEPLOYMENT MODEL

My initial thought that everyone looking to upgrade from AX to D365 would automatically select the cloud option was quickly proven to be incorrect. Almost everyone wanted to analyze cloud versus on-premise. Here is what we found helping companies with their decision-making process.

Editor’s Note: This article coincides with part 2 of our new podcast series on AX to D365FO upgrades.

The biggest surprise for me in discussing the upgrade from Microsoft Dynamics AX to Dynamics 365 for Finance and Operations (D365FO) with multiple clients and potential clients is not that to-date everyone has decided to go the cloud, but rather that everyone wanted to engage on a detailed analysis of the options available to them:

Cloud
On-premises
Hybrid

The second major surprise for me was that these sophisticated debates were often tossed out the window because of some minor “inconvenience” in the on-premises approach.

The post Microsoft Dynamics AX to D365 Upgrade Journeys, Part 2: Choosing a deployment model appeared first on turnondynamics.com .

Microsoft Dynamics AX to 365 Upgrade Journeys, Part 1: The Setup

Thu, 24 Jan 2019 01:17:00 GMT

EPISODE 1: THE SETUP

Early in our first AX to D365 upgrade project I realized that this was not like any project that I had seen in over thirty years in the ERP business. Looking for help I found either marketing hype or highly technical tidbits for isolated issues. Nothing to prepare a business decision maker for the expense and complexity they were about to encounter. So, we decided to create our own library of useful information.

Editor’s Note: This article coincides with part 1 of our new podcast series on AX to D365FO upgrades.

Microsoft Dynamics AX to Dynamics 365 for Finance and Operations (D365FO) upgrade discussions, planning, and the actual projects are in full swing!

For the past six to nine months, upgrades have taken up most of our group’s mindshare, on both the sales and delivery sides of the business. These projects have created more teeth-gnashing than anything I have seen in the industry, perhaps since all the Y2K excitement.

Most surprising to me is the amount of “information” I am picking up as we discuss and execute on these projects.

Based on my experience, the move to D365FO may be the most financially significant and technically involved project that companies will have to undergo since their initial AX implementation. I’m especially interested in anything that helps lessen the impact of the three horsemen of the ERP project apocalypse:

Over time
Over budget
Over-promised functionality

The post Microsoft Dynamics AX to 365 Upgrade Journeys, Part 1: The Setup appeared first on turnondynamics.com .

What If Cell Phones Updated Like D365 FandO

Thu, 27 Dec 2018 17:31:00 GMT

It’s update season, including various versions of Microsoft Dynamics AX, all across the Microsoft ERP landscape. Some non-essential. Some forced.

Selling and managing several of these projects is giving me a front row seat to the excitement.

Recently, preparing for the daily (yes, daily) project status call with the project team for a small mid-market upgrade project, while simultaneously prepping the weekly executive overview, my iPhone informed me that it was time for a system update.

Almost subconsciously I entered my password, then got back to my meeting prep. A couple of minutes later my phone screen flashed to let me know that its latest update was finished, and I did not give it a second thought when I picked it up a minute later to answer a call, send out a text, and check the news on my favorite app.

All without a hitch or more importantly the fear of a hitch.

That is when it hit me! What if that update process mirrored the typical ERP update/upgrade?

First, and most importantly, there would be fear. Lots of fear.

Or more accurately, first there would be the marketing campaign. The marketing campaign geared at non-customers touting the fact that a desperately needed combination of new technology and functionality would allow C-Suite types to finally run their business from their Dick Tracy wrist watches.

Of course, I am exaggerating. The ACTUAL marketing messages say cell phones. Irony is not dead in this post. THEN comes the fear. The fear from the folks tasked with carrying out the project.

Next, I would put the project out to bid. My process would identify likely companies, make them fill out lengthy documents laying out in great detail my specific requirements and asking for timely responses.

The responses would be weighed, on a scale, but not read, and then promptly ignored.

Based on the weight of the responses, the next step would be to get a quote and a project plan that would ensure that a timely update will ensure that I can access the latest batch of emojis ASAP!

Several rounds of price negotiations would allow me to identify the company with the biggest disconnect between the sales and implementation team, as well as the most shameless salesman.

Having identified the low cost, most unrealistic provider for my update I would be ready to go!

Did I mention that the update is going to cost more than the original? That only some of the apps will work after the update, and depending on the current version, there might not even be an update available? Just a complete do over.

After firing two partners and spending three times as much as the original quote called for, I would finally turn on my updated phone and find out that nothing looks or works the same.

But there is an update right around the corner to fix that!

Bottom line, can anyone honestly say that the technology required to update cell phones and their associated functionality is logarithmically easier than updating an ERP system?

An ERP system allows me to print checks; my cell phone allows me to instantly communicate with people around the world with a handheld device that has more raw computing power than NASA had to land on the moon while simultaneously launching angry birds and using an updated list of emojis to add color to my “LOL” texts.

The post What If Cell Phones Updated Like D365 FandO appeared first on turnondynamics.com .

ABOUT THE AUTHOR

Order Automation in a World of Amazonian Expectations

Thu, 13 Dec 2018 03:14:00 GMT

In the world of elite corporate branding I have often seen the sly subliminal “message” hidden in the Amazon logo.

The arrow below the word amazon has several interesting qualities. It goes from “a to z” indicating that you can get everything you need at Amazon.

It looks like a smile giving you that warm and fuzzy feeling.

My question, why does nobody ever point out this: The Amazons were famous for being all women and for hating men. No men were allowed to live alongside the Amazons. They were an entirely female tribe.

You would think that cuts the e-commerce giant’s customer-base in half!

But I digress.

Over coffee this morning I decided that I needed a new pair of cross training athletic shoes to hit the fancy gym that just opened around the corner. Remember when sneakers were not specialized? But I digress again.

Too lazy to drive the 1.2 miles to Sports Academy and try on a selection to make sure I got a good fit, I popped open my trusty Amazon account and searched for a pair that would make me look sleek and serious about my commitment to fitness.

Bad News

Now the bad news…my pair of deluxe gym kicks was NOT available for delivery that afternoon! I would have to wait until the next day. Oh, the horror!

The clear majority of RPA in the Dynamics ERP space is focused on AP automation. My frustration with my Amazon order has me thinking that Sales Order Automation is much more important in a world of “Amazonian Expectations.”

Think about it!

The expectation of immediate satisfaction must spill into the business world. Can you afford to get product to your customers “next month or next week”?

If buying decisions are made on availability, price,and quality, can you afford to lag on delivery time?

The Bottleneck

Studies show that a major bottleneck in the sales order fulfillment process is the manual input of sales orders. Speed and accuracy is critical. Our webinar will focus on reducing the time it takes to enter sales orders while also improving accuracy. The impact on your organization can be dramatic, with improvement in:

Delivery times
Customer satisfaction
Supply chain visibility
Cash in the bank!

A logo is a curious thing. That warm fuzzy feeling may not be built into yourbrand, but sales order fulfillment that outperforms your competition will give you one reason to smile.

The post Order Automation in a World of Amazonian Expectations appeared first on turnondynamics.com .

D365 F&O On-Premise

Thu, 05 Jul 2018 16:59:00 GMT

When it comes to deploying the D365 On-Premise product, there is a lot of confusion. In many ways, it is very similar to the cloud version. The on-premise is still deployed thru the LCS where you create the project and go through your pre-implementation questioners. The major difference is that your SQL server, your AOS, and MR all reside on your servers.

Here is how AX2012 and D365 F&O On-Premise compare:

D365 On-Premise

In a nutshell, here is what is involved:

Make sure your servers are setup and ready to go. You will need the server IDs and IP addresses.
You will need the AAD tenant to create your LCS so make sure you have that.
Create your LCS project after you have purchased your licenses. Your consultant should be able to assist you with this process.
Deploy your LCS D365 and select the on-premise option, follow thru with the rest of the setup questions.
Once your setup is completed, the AOT, Load Balances, SQL Server 2016, Local Storage, Power BI, SSRS, and MR should all be installed on the servers you defined.
For development environment, you will need the VSTS and a full VS licenses for development and code customizations.

Note that you will still promote all your customizations thru the LCS, and your product updates will also be managed through the LCS platform along with your support incidences.

Click here for full details on the On-Premise solution of Dynamcis D365 F&O .

Also, check out the Microsoft portal for D365 roadmap .

The post D365 F&O On-Premise appeared first on turnondynamics.com .

ABOUT THE AUTHOR

Have You Outgrown Microsoft Dynamics GP?

Thu, 10 May 2018 14:02:00 GMT

There are many reasons why you may be outgrowing your Microsoft Dynamics GP software. However, primarily it falls into either a functional or a technological issue. Understanding those issues in the context of what the Dynamics GP solution is intended to deliver can help you decide if it’s time to “get fitted” for a more robust solution.

As a product, Microsoft Dynamics GP is quickly becoming the “Grand Old Dame” in the Microsoft ERP fleet. Hugely successful, loved by many, and at one point supported by the greatest partner channel in the world, the product is showing its age as it winds down its career as a strategic solution. For companies that currently use Microsoft Dynamics GP but are outgrowing its capabilities, there are many questions regarding potential solutions and options:

Am I using the software to its full potential?
Is there a third party solution that fixes my issues?
Am I working with the right partner to understand and fix my problems?

WHAT ARE MY BEST OPTIONS IF I NEED TO MAKE A CHANGE?

Of course the answers are often complex and intertwined, but what if you just want a “rough idea” of whether or not it is time to make a change? In my years of evaluating ERP solutions and extensive experience with larger and more sophisticate GP implementations, I have found that a useful method of deciding if it is time to consider a new potential solution is the “Rule of Multies.”

Each of the following “Multies” that you check off on your current functional requirements list is a clear indicator that it may be time to consider a change:

Multi Company
Multi LOB (line of business)
Multi Location
Multi Currency
Multi Country
Multi Language
Multi-Dimensional Inventory or Financials

The more line items you check off the more certain it becomes that GP may not be your best long term solution. Multi-company and multi-location can go hand in hand but do not necessarily have to as in the case of a business that runs multiple lines of business or companies out of the same location. Especially noteworthy is the case where there are multiple production facilities or warehouses that create a supply chain. Multiple currency, country, and language often go hand in hand but of course do not have to.

Business regulations and tax considerations are usually found to be critical in companies with these requirements.

Not as straightforward or common is the requirement for multidimensional inventory or financial reporting. In many ways I find these to be the most challenging of the “Multies” to understand and therefore the most difficult to implement.

More challenging to analyze are the questions of partner and direction. Having taken customers from their existing GP solution to other, more complete Microsoft Dynamics ERP packages solutions, I know many of the technical, functional, and even emotional pitfalls associated with that discussion. Yes, emotional.

If you make your living selling hand saws, it becomes an issue when your customers are shown a chain saw. Not to mention that your current GP dealer does not know or won’t tell you the potentially most compelling advantage of speaking to a partner that has the capability to analyze your existing GP implementation and discuss scaling it appropriately.

ABOUT THE AUTHOR

Taking the Leap from QuickBooks to Microsoft D365 F&O

Thu, 05 Apr 2018 14:00:00 GMT

The typical life-cycle of a business sees it implement three ERP systems: QuickBooks, an “upgrade” to QuickBooks, and finally a “real” system. This is at least one, if not two, systems too many!

The standard rationale for following the traditional ERP system trajectory is cost. However, I see that as shortsighted and self-defeating for an individual company, as well as an industry.

The real cost of an “ERP System” is not the cost of the software and the implementation services. That is the tip of the iceberg. The real cost is the time and effort to implement and then re-implement systems, not to mention the lost opportunity costs of systems that restrict growth and provide poor information.

My favorite quote from a customer who “overbought” a Microsoft Dynamics solution rather than settling for QuickBooks is:

“I made the decision based on what we can be not on what we are today!”

I got goosebumps just typing that.

Let’s set that aside for a moment. What is the impact on your team of getting a solution that you must implement only once? A solution that you can grow into? A solution that does not inhibit growth artificially? A solution that screams confidence about your potential?

The Microsoft Dynamics Cloud ERP offerings have generated a lot of attention from companies that are overloading their QuickBooks system to the point that it is holding back growth.

Many of them are “stuck in the middle” of the ERP solutions available to them and forced to make a sub-optimal buying decision between functionality and cost:

Their current QuickBooks has completely crippled them and limited growth.
An affordable “mid-tier” ERP solution, such as Microsoft Dynamics GP or Microsoft Dynamics D365 for Business, only gets them part way to the functionality that they will eventually need.
A robust solution like Microsoft Dynamics D365 for Enterprise that provides all the functional and technical requirements for a sophisticated company and is the platform for future growth is “too expensive” from a licensing standpoint.

While it may be true that the licensing cost for an enterprise level ERP solution looks daunting to a growing company looking to upgrade from QuickBooks, the fact is that it may be dramatically more cost effective if analyzed in terms of opportunity costs:

The lost growth in business reflected by an ERP solution that does not function as a strategic tool
The real cost of doing another software upgrade when the software cost is deemed to be acceptable for a true Enterprise-level platform

To understand the true cost of ownership of an ERP solution, contact us. We can also show you how a rapid implementation of an enterprise level ERP solution can dramatically save and even make you money.

ABOUT THE AUTHOR

Eliminating the Confusion Around D365 F&O

Sat, 31 Mar 2018 17:01:00 GMT

If you’ve been following the Microsoft Dynamics AX evolution, like many others, you might be confused about D365. First, the cloud-only offering, then the on-premise offering that was AX2012 R3 CU8 and now finally D365 On-Premise.

This also had the partners confused, which was evident by the relatively few deals that were singed and the low quality of these early implementations.

Now that the dust has settled, we are finally begging to see good implementation results. Though many customers still ask me if D365 is a good product.

Here is what tell them: D365 is a good product; however, customers are much more dependent on Microsoft for many of the functions that were available to local admins in AX2012. In some ways, even some of the Microsoft technicians have recognized this shortcoming.

Here are some specifics to consider:

Access to AOT is no longer an option in Tier 1 environments. You have to create a Dev machine and access AOT that way.
Data tables—Not all the tables and values are fully represented in the data migration utility.
Custom code moves are much more complicated.
Simple troubleshooting and fixes like locked records now require Microsoft’s help.

But D365 does offer many improvements:

D365 offers better out of the box workflow templates.
Security setup and custom roles are easier to work with.
You get much more enhanced functionality in several modules.
Azure AD is better integrated and so is the LCS.

Also, it’s worth mentioning that the tables in D365 have grown considerably, going from about 8,000 in AX2012 to more than 11,000 in D365.

These are just a few of the observations I have noted about D365.

ABOUT THE AUTHOR

ERP Marketing BS—Acumatica Poppycock

Fri, 16 Mar 2018 16:32:00 GMT

“Modern” Manufacturing ERP Software

In a recent marketing blog from Acumatica that included access to a “free” video (insert eyeroll) the major takeaway was, “Having modern manufacturing ERP software wrapped up in a single system is quickly becoming a necessity for the manufacturing industry to compete in our technology-driven marketplace.”

Finally! Someone came out with manufacturing software wrapped in a single system.

But wait…it’s also functional, flexible AND affordable!

Once the initial excitement passed, and I could read further, I found an extensive list of available modules including: Bill of Material and Routing, Production Management, Material Requirements Planning (MRP), Product Configurator, Estimating, Advanced Planning and Scheduling, Order Management, Sales Order Management, Purchase Order Management, Inventory Management, Project Accounting and CRM. Granted, only five of those are specifically manufacturing modules, but that’s not the point.

For some historical (or perhaps hysterical) reference, I decided to look up the modules available in the market-leading solution that I was selling to manufacturing firms back in the 1980’s.

For a DOS-based system that ran on Novell networks, it had an impressive list of manufacturing modules:

Of course, not being a modern system weighed down by the overhead and speed-killing technology of a browser based system, it ran a lot faster and was much easier to install.

While the Acumatica marketing piece is nowhere as egregiously over the top as the recent NetSuite pronouncement that I wrote about in my blog Latest NetSuite Marketing BS , the problems here are more subtle, but just as likely to set inappropriate expectations in the sales cycle, and therefore lead to a challenged or failed implementation.

For a detailed explanation of how manufacturing is best positioned and implemented in the SMB space, please refer to my more detailed explanation in The 20/80 Rule for Manufacturing ERP Software Implementations .

Bottom line, manufacturing software is sold in the SMB market touting functionality that the customer does not have the time, the money, or most importantly the information to implement. In the Acumatica list above, of the five manufacturing modules touted by the publisher it would be a major accomplishment to implement two, maybe three successfully.

Importantly, that success depends on a knowledgeable partner or consultant who has the ability to push back on sales and marketing nonsense to set realistic expectations. With the mortgage due monthly, that can be brutally difficult.

Modern does not equal better if it does not fix the core problems that consistently plague ERP implementation projects.

Not thoroughly modern or Millie…out.

ABOUT THE AUTHOR

Latest NetSuite Marketing BS

Tue, 27 Feb 2018 18:52:00 GMT

Back in the day NetSuite absolutely killed Great Plains dealers with their “hairball” sales pitch and an assortment of outright lies. The latest fairy tale they’re selling is “Run Your Business from a Dashboard on Your Phone.”

Recently, I was driving in my car, listening to my favorite Sirius Radio station (yes, I have that kind of swagger) when I heard a radio commercial for NetSuite Software as the “Number 1” blah blah blah blah blah….

I had tuned out until I heard the claim that they are the “number one cloud-based solution for companies that have outgrown QuickBooks!”

What the what? That got my attention!

OK, OK, maybe that claim can be backed by some defensible metric, but then I get hit with the inevitable NetSuite whopper. Not only is it fast and easy-to-install, but “It allows you to run your business from a dashboard on your cell phone!”

When NetSuite first hit the scene, their ultra-aggressive sales tactics absolutely killed Dynamics GP (formerly Great Plains) dealers. The Great Plains channel at that time consisted largely of ex-CPA types who sold primarily by doing detailed analyses of business needs and by doing extravagant product demos that left no screen or function behind.

Conversely, if you had the misfortune of getting on a call with a NetSuite rep, chances were that they had you sold on some entry level system before the call was over. If you did manage to get off the call without whipping out a credit card, you were loaded with “facts” regarding what an integration mess Great Plains was.

The typical sales cycles for NetSuite was literally an almost immediate phone call from a sales rep when you inquired for information. The same was not true for Great Plains.

An inquiry to Microsoft was first sent to a local sales rep where it was funneled through a complex partner matrix to determine the best partner to contact the lead. This process was swift and efficient, sometimes only taking several weeks.

Next came the all-important follow-up from the partner to set up a discovery call, often accompanied by a “show up and throw up” demo session. These processes were also highly effective and resulted in Great Plains partners literally going out of business.

If a Great Plains partner was lucky enough to get into a situation where a prospect was comparing functionality with NetSuite, they got killed with “The Hairball,” FUD and outright lies. I spent a lot of time trying to fight the good sales battle with seminars and blogs like:

Moving to the AX world and now Dynamics D365 for Enterprise, I thought I had left NetSuite and their sales tactics in the rear-view mirror. Until I heard this ad and learned that now it practically installs itself AND I can run my entire business from my phone!

I may never get off this barstool.

ABOUT THE AUTHOR

The “Uh-Oh” Factor of Failed ERP Projects

Sun, 18 Feb 2018 19:02:00 GMT

Research casts new light on how project teams work and how that behavior can shed light on challenged or failed ERP projects.

It has long been my assertion that all ERP projects fail.

If we reasonably define a successful ERP implementation as meeting the following three reasonable criteria regarding:

Time – successfully meet a reasonably scheduled “Go-Live” date.
Budget – minimal or “non-material” cost overruns.
Functionality – deliver the key business processes and functionality as defined in the sales process.

Based on those three metrics all ERP systems fail. The only variable is to what degree:

Spectacularly – bringing down companies.
Critically – requiring a complete do-over with a new team or new solution.
Incrementally – slowly draining resources and enthusiasm while delivering only a portion of promised functionality.

While many challenged or failed ERP projects can be attributed to “tried and false” selection and implementation strategies such as:

The RFP
The Structured Demo
The Gap Fit Analysis

There is new research that project team behavior follows an interesting pattern. From the Behavior and Society section of the Scientific American in an article titled Timing is Everything , Gareth Cook writes:

Connie Gersick, an organizational behavior scholar, has found that teams proceed through projects in a peculiar way. Instead of a steady, linear path to accomplishing their goals, they begin by doing very little. They hem. They haw. They posture. They procrastinate. It’s only at a certain moment that they sound the alarm and get moving. What is that moment? The temporal midpoint. Give a team 34 days to complete a project, Gersick found, and they don’t really get started in earnest until day 17. Give a team 11 days, and they get going on day 6. At the midpoints, teams say, “Uh-oh, we’ve squandered half of our time. Let’s go!”

(The source material, “MARKING TIME: PREDICTABLE TRANSITIONS IN TASK GROUPS” can be found here ).

Think about how this behavior dove tails with some standard ERP implementation strategies.

GAP FIT / DETAILED REQUIREMENTS ANALYSIS, ET AL

Typical ERP project plans start with a detailed analysis of existing systems, their flow and the gaps exist between them and the new ERP platform.

Often this work results in an incredible amount of detail stored in handsomely bound binders that no one ever looks at once the real implementation work starts.

However, tons of project time and resources have been expended.

THE “BLANK SLATE” NAVEL GAZING EXERCISE

One of the greatest features of modern ERP platforms is also the source for the greatest challenge to successful implementations, flexibility.

Salesmen love the flexibility of modern ERP software because they can basically say yes to all feature/function questions. Similarly, implementation partners that specialize in developing customized ERP solutions on a customer by customer basis can barely contain their glee when customer project team members try to outdo each other with lengthy lists of “must have” items.

Combine these sub-optimal project tasks with how project teams work and you have a recipe for disaster.

THE SOLUTION

If you want to increase your chance of having a successful ERP implementation think about the following:

Avoid the endless “Top Ten Lists to a Successful ERP Implementation” that can be found with a simple internet search. They endlessly rehash tips that have done nothing to increase the rates of project success.

Identify an actual Architect to lead the project
Hire or form a great team not a Big Important Partner
Consider a highly structured rapid implementation plan to completely to change the tried and false implementation strategies.

ABOUT THE AUTHOR

The 20/80 Rule for Manufacturing ERP Software Implementations

Thu, 15 Feb 2018 19:06:00 GMT

Implementing ERP software is hard. Implementing manufacturing ERP software is even harder. With our tried and true approach, it doesn’t have to be.

There is a lot of great ERP software available for mid-sized manufacturing companies that is packed full of features and capabilities. It has been like that for the majority of my more than thirty year career helping companies with their selection and implementation projects.

Starting my career, fresh out of engineering school, implementing tier-1 manufacturing software suitable for Fortune 500 companies, I received an immediate education on the wide range of complex functionality available in these solutions. My second lesson was how impossible or incredibly expensive it was to implement.

I moved from Price Waterhouse to my own practice in 1986 when my idea to start a mid-market manufacturing practice was given a thumbs up with the caveat that a partner had to run it. As a twenty something year old know-it-all, I did not agree with that assessment.

My plan was predicated on the amazingly complete set of accounting, distribution, and manufacturing functionality found in some of the first DOS-based, mid-market offerings such as Macola and Syspro.

What I quickly figured out was that most of that functionality was overkill for the typical mid-market manufacturing company. That insight led to the highly successful model of selling and implementing “black-hole” manufacturing systems. In a “black-hole” manufacturing system you know what your inventory is at all times in its three critical stages:

Raw materials or parts
In-process or being worked on
Finished widget–ready to sell

Note: a widget is a hypothetical item used to discuss manufacturing concepts. A completed widget could be a little red wagon as an example. The inventory parts that go into the red wagon might be:

Wheels
Axels
Bed
Handle
Various nuts, bolts and other hardware

What you “lose” in the “black-hole” manufacturing model is most significantly:

Where exactly are we in the process of making a specific widget
Broken down by material labor and overhead, what is my exact cost structure to build a widget
Advanced scheduling and capacity analytics

Without getting overly complicated, manufacturing software builds on two fundamental building blocks:

The Bill of Material or BOM
The Bill of Labor or BOL or Routing

The BOM uses the list of inventory parts it takes to manufacture a widget and creates a logical tree structure that shows us exactly how the parts come together to make a completed widget.

Creating a BOM is mostly science. A list of parts can be combined in multiple ways to make different finished products. The BOM for our little red wagon must be exact so that you make the desired product correctly. For example, you would not put handles where the axels should go and vice versa.

The Routing defines the people, machines and tools needed to “make” or manufacture the widget.

It is my experience that a typical mid-sized manufacturing company has the information needed to create an accurate BOM readily available. They probably don’t have accurate BOM’s but they do have the information. The difference is important.

That same mid-sized manufacturing company will have almost none of the information needed to create useful routings. More importantly, they do not realize the time and effort needed to create and maintain useful and functional routes.

This fact is carefully ignored in the sales cycle much to everyone’s detriment (with the probable exception of commission based salespeople). It is my experience that mid-sized manufacturing is sold exactly and specifically on features and functions that will never be implemented!

Here is my suggestion to any small and mid-sized manufactures looking for a new ERP software solution: the information that you will gain implementing a “black-hole” manufacturing solution will give you 80% of the information you can realistically manage and afford for 20% of the time, effort and cost of implementation and maintenance. With that solution up and running you have two options:

Run forever with this model because it gives you all the information you need or can afford
Use this model as a logical building block to use as a stepping stone for more complex functionality that will get you 20% more information but at 80% of the implementation and maintenance cost.

For a realistic evaluation of your manufacturing ERP needs and how to employ these principals in your selection and implementation processes, please give us a call.

We can show you how a rapid implementation of an enterprise level ERP solution can dramatically save and make you money.

ABOUT THE AUTHOR

The Case for Rapid ERP Implementation Plans

Tue, 06 Feb 2018 19:12:00 GMT

Reduce the risk of the inevitable, a challenged or failed ERP implementation by eliminating paralysis by analysis.

The seeds for a failed ERP implementation are normally sown in the sales process with ridiculously antiquated processes like the request for proposal (RFP) and the structured product demo, which is usually a complete comedy of errors.

The road to nowhere really picks up speed, ironically, due to the power and flexibility of modern ERP platforms like Dynamics D365E.

The worst-case scenario of having a vanilla ERP platform processing critical business transactions is having a vanilla ERP platform processing critical business transactions!

Savvy salespeople and billable-hours hungry development partners pitch the “blank slate” project process. Before long, every minor whim is thrown into the project plan chocking key requirements with one-upmanship and navel gazing, which ends up creating the biggest list of critical “must haves.”

True story.

Engaged on a project to discover why a monstrously large company was having trouble going live on AX, we reviewed customizations that were running about $500k per month.

Lo and behold, the customizations included a complete replica of the character-based legacy system UI.

For anyone confused by that last sentence imagine selling someone a Ferrari and then insisting that instead of wheels we design it to run like a horse with retrofitted mechanical legs. Of course it has to have a fancy saddle…so no expense is spared.

We see the following bad processes in project after project:

Projects sold with the promise of doing anything
Partners driven by billable development projects
Endless requirement wishes
The “we are special” mentality of key executives

Combined with a lack of great consistent resources available to drive and deliver major ERP projects what do you get? Universal success in completing projects on time and under budget.

Sorry, fell asleep there for a moment and visited La La Land.

Let’s look at a completely different implementation approach—the highly structured, rapid implementation plan.

But let’s not confuse what we are about to suggest with your classic “rapid implementation” packages that are highly confined in scope, low in deliverables, and high in legalese, looking to expand the scope of the project with endless change orders.

What I am suggesting is a customized rapid implementation plan focused on delivering critical business functionality using only vanilla software ASAP. Rather than an endless wish list of “nice-to-have” functionality and business processes, let’s focus on the key requirements to run the business in a lean, stripped down vanilla environment.

If you can’t simplify existing complex processes, it may be that you don’t understand business well enough, or have a broad understanding of standard best practices.

Once a system is up and running and processing critical business transactions we can take a step back and analyze how our ERP platform can be transformed into an competitive advantage rather than simply a record keeping system.

Making changes to a system that is processing critical business functions at this point has the following advantages:

There is a knowledge of the capabilities of the ERP platform that cannot be gained in a fundamentally flawed demo process.
The implementation of a vanilla system forces companies to look at business processes that have developed over time that are sub-optimal but deemed to be critical from a standpoint of “company culture.”
The project team has a better understanding of relative skill levels and how to best leverage those skill sets.
The “list” of what is critical versus “nice to have” comes into sharp focus and is much smaller.

The worst-case scenario of having a vanilla ERP platform processing critical business transactions is having a vanilla ERP platform processing critical business transactions! This is a dramatically better result than having the perfectly designed system that is over-budget, overdue that will possibly result in complete failure.

The key, of course, is having the right team to properly execute such an implementation.

For further information on how your ERP project can benefit from non-traditional project thinking to eliminate challenged or failed projects, contact us now. If your project is suffering cost overruns or project delays, call us yesterday.

ABOUT THE AUTHOR

How Artificial Intelligence Will Impact ERP Software?

Thu, 18 Jan 2018 19:30:00 GMT

HINT: Don’t hold your breath.

You’ve probably noticed that claims of AI-powered software solutions are starting to pop up more frequently, including in the context of ERP. To be clear, regardless of what breathless marketers and science fiction fans love to dream about, there is currently no such thing as artificial intelligence in its truest form, and technology advances that improve ERP solutions today aren’t AI.

Sure, there is faster processing of complex problems and machine “learning” based on access to relatively inexpensive statistical processing power. That improved access has helped some organizatinos improve insight into their businesses, but it has also created the illusion that computers and software have achieved AI.

My main concern is not that there is not a clear understanding of what AI entails but that its hype will become another rabbit hole that ERP vendors can run down to create slick marketing campaigns rather than fixing fundamental issues that have plagued the ERP industry:

Poor software design
Poorly and under trained implementation channels

Combine those and other factors and we fail to fix the fundamental problem of the ERP industry: that there are no successful implementations.

If we agree on a basic set of goals for a successful ERP implementation – on time, on budget, delivering promised functionality – then there has never been a successful ERP implementation in the history of the market. Something always gives.

Cries of outrage from offended implementers are expected and will be memorialized in a soon-to-be-established ERP Implementation Hall of Fame.

But back to the AI discussion and why it doesn’t come close to the hype yet.

Advances in how computers perform against humans in games is one of the primary areas where the myth of AI has advanced. So the fact that computer programs have made significant progress in regularly spanking the best and brightest humans in games like chess, Go, Jeopardy, and no-limit Texas Hold’Em is a sign that computer processing power is greater and that the design of software has become more sophisticated, but it is not evidence that HAL 9000 is going to take over at any minute in your home or in your business.

INTELLIGENCE AND AI

Let’s start by looking at a relatively simply game, tic tac toe. It does not take a computer to “solve” this game because the potential moves are easily computed. We start with 9 possible squares to place our initial O or X and once we have done so we are left with 8 empty squares to make our next move. With each subsequent move the number of open squares is reduced by one until we rapidly get to the point where there is a winner or a tie.

Because every possible game of tic tac toe is easy to calculate, the game has been solved and every move has a perfect counter move that will lead to a tie or a win.

When we move to more complex abstract strategy board games like chess and Go the problem of “solving” these games become currently impossible. For example, it is estimated that the legal number of moves possible in a game of Go is larger than the number of atoms in the theoretically known universe. (It is “estimated” because the exact number is too large to calculate.)

It is only recently that computers could beat the best chess players in the world. That was a result of how software approached the problem of trying to solve the chess problem rather than computers becoming artificially intelligent.

It is easy to see how IBM could program a computer to be a Jeopardy champion, just imagine being able to instantly Google every question asked and the solution is straightforward but chess presented a different set of problems because humans were able to bring a level of intuition to the game that raw problem solving could not replace with existing software and hardware.

Initial chess playing programs quickly developed to the point where they could regularly beat average players consistently but had trouble with world class competition. These first programs were based on programmers loading historical games into the software’s database and on the development of increasingly sophisticated algorithms that evaluated millions of potential moves per second and used values assigned to game pieces and their positions on the board to arrive at statistically based “best” moves.

While this approach led to chess programs increasingly hard to beat, it took a fundamental change in the approach of how to program software to win at chess to finally beat grand masters on a regular basis.

That change was not “thought of” by computers becoming frustrated with losing games and looking for a better way to solve the game of chess. The change came about when programmers decided to take advantage of more processing power to try and solve chess and therefore beat any competition.

The new approach fed the computer the rules of chess but did not bother with any historical database of games or mathematical approximations of the strength or pieces or their position on the board.

The new approach was just to let the computer play games against itself. Millions and millions of games. Based on this internal gameplay and massive computational power, it is now impossible to beat computers at chess.

Nothing in that process had anything to do with artificial intelligence. It was all true intelligence on the part of humans and their spark of insight or ingenuity to take advantage of better and faster tools.

THE HUMAN TOUCH

How many accountants and CPA’s have been replaced because spreadsheets can add columns and rows of numbers faster?

And while we are on the topic, simple and complex spreadsheets alike are commonly filled with errors. Where is the AI to spot those errors and fix them? Sure, we have baked in graphical displays that show the logic behind calculations and point out simple errors but none of that is AI. True AI would look at your P&L and tell you that being an ERP VAR is insane and recommend a better, saner line of business. Sign me up for that software today!

As complex as games can be to “solve” there are other relatively simple tasks that humans perform daily that computers with all their processing power cannot yet duplicate at similar levels of accuracy and speed.

Looking at something infinitely more complex, such as painting a landscape. We can feed a computer images of every landscape in the world and have it create an infinite number of variations or copies of that landscape but no computer program will become tired of that task or step back and say let’s look at this another way and create an impressionist movement around how landscapes are looked at and created and ultimately felt by the view. That spark is intelligence and it does not exist in any computers or software today.

The real issue as I see it is that the energy and resources that go into new and exciting technology draws as much away from the fundamental issues with ERP software. It creates marketing opportunities that result in more hype that will not be delivered on and distracts focus and effort from making ERP software easier to implement, maintain and use daily.

The moment that true AI is introduced into the world of ERP software I expect it to start yelling at its creators to fix it!

Or as Rutger Hauer most famously said in the science fiction gem based on a book call, “Do Androids Dream of Electric Sheep”?

“I’ve… seen things you people wouldn’t believe…

Attack ships on fire off the shoulder of Orion.

I watched C-Beams glitter in the dark

Near the Tannhäuser Gates.

All those… moments… will be lost in time,

Like tears… in… rain.

Time… to die…”

Perhaps too dramatic for the next release of Dynamics 365 but at a minimum:

“Time to change!”

ABOUT THE AUTHOR

Hire a Great ERP Team, Not an Average Partner

Wed, 29 Nov 2017 19:34:00 GMT

THE GOLDILOCKS PARADIGM

Challenged or failed ERP projects continue to be a plague and demand a shift in the industry. Why do we continue to embrace the “tried and true” sales and implementation processes? It’s time we focus inward and select a better implementation partner. With more than 30 years’ experience in the sales and implementation of ERP software, even I find this a bit uncomfortable.

During my career, I’ve worked with more than a dozen software vendors, hundreds of clients, and I’ve seen or been involved with every imaginable partner model. I’ve discovered the sweet spot for maximizing partner efficiency and refer to it as the “Goldilocks Paradigm.”

In a previous post, The Myth of the Big Important Partner, I describe in detail the internal and external forces that plague large implementation partners and the reasons for their continued project failures. These dynamics lead to a fundamental but unspoken conflict between partner and client in which the interests of both parties never align.

The client, or ERP project, needs dependable great resources, but the big partner will never be able to deliver them consistently. The small firm that does deliver exceptional service often grows quickly and sees a corresponding decline in the quality of their project delivery as a result.

In the ERP implementation industry, an entire sub-ecosystem of small firms and impendent contractors exist with the sole purpose of “mopping up” and servicing challenged or failed ERP projects. It is only a lack of “net-new” sales that keeps them anonymous.

The best of these companies has a cohesive team that has worked together on multiple projects for many years. They manage to combine the best of both worlds: The ability to deliver on a consistent basis an implementation team composed of senior resources that the one-man band or big partner couldn’t deliver.

This point was driven home to me in a recent Wall Street Journal article. In his post, Why Companies Should Hire Teams, Not Individuals, Dr. Sidney Finkelstein, the Director of the Tuck Center for Leadership at Dartmouth College focuses on internal hiring practices, but these benefits also apply to hiring an ERP project company:

Confidence that the new employees will work well together
Lower risk that any individual won’t be as strong as advertised

“Existing groups work well together, they contribute more quickly, and they are more likely to shake things up (in a good way).” Dr. Sidney Finkelstein

The big partner can’t deliver the resources needed on a consistent basis and the individual practitioner does not have the bandwidth either in skill set or available hours to successfully staff large, complex projects.

Enter the proven team. The one that fits “just right” as the Goldilocks Paradigm suggests.

The ideal team may be small, but they are flexible. They are a team of senior resources who have worked together on multiple projects over many years. They are “big enough” to deliver a project team with sufficient resources to complete sophisticated projects.

When you discover that the big partner chair is too big or you break the tiny chair of the independent consultant, talk to us about finding the right fit for your project. Our group of Dynamic Architects is ready to answer your ERP questions.

ABOUT THE AUTHOR

The Myth of the Big Important ERP Partner

Sun, 29 Oct 2017 18:39:00 GMT

THE ISSUE

The recent purchase of a big, important partner in our industry was followed by a slew of articles about the transaction with glowing accounts by the owner extolling his own business acumen. Those articles were nearly impossible to read without bringing to mind numerous accounts of a large, “challenging” ERP implementation where the same partner was failing spectacularly despite hundreds of thousands of dollars in billings and a rotating cast of consultants.

The highlight for me on this project was the sleepy consultant who tried to hide away in the company boardroom for daily naps. It worked pretty well, until the President of the company walked in on him mid-slumber. Fortunately for him, he hadn’t changed into his jammies.

Unfortunately, in the industry, challenged or failed ERP implementations with “Big Important Partners” such SNAFU’s happen more often than not. These BIP’s have unintentionally created a thriving, secondary implementation economy composed of smaller specialty firms and independent consultants that specialize in “mop-up” operations. It is with these firms and individuals that you will often find the best technical resources in the industry.

In anticipation of the “mop-up” crews needed when working with BIP’s, major ERP vendors have project escalation processes and teams. Typically, the cycle looks something like this:

BIP makes fancy promises they don’t fulfill and ERP Customer is unhappy.
Unhappy Customer reaches out to Software Publisher to express concern.
Software Salesperson listens carefully and promises to have harsh talk with Partner.
Publisher Salesperson talks to Sales Manager about the issue, and they have a conference call with the Partner to see if this issue is going to affect quarter-end sales.
BIP promises Customer to do better and write-off some implementation dollars.
Customer eventually switches Partners or calls the Software Publisher to discuss legal remedies.
Software Publisher Legal Team introduces Customer to the reality that the payroll of their in-house legal department is larger than the GNP of Western Europe.
Escalation team at Software Publisher calls smaller, unknown-but-dependable, Implementation Partner to save the day.
Sales Teams from BIP are presented various partner awards at swanky resorts during annual mutual back slapping events.
Rinse. Repeat.

If you’re in the middle of a struggling ERP implementation, you may recognize the symptoms of the Big Important Partner myth and its effect on your project. If you’re in the process of changing or selecting a partner for a new ERP implementation, understanding partner-related ERP project issues may save you time and money. And maybe an ulcer, your job, or even your company.

THE PROBLEMS WITH A BIG IMPORTANT PARTNER

Having worked in a wide variety of business models in the ERP implementation world for more than 30 years, my observations are grounded in real-world experience. It turns out that I learned several critical ERP implementation lessons on my first job fresh out of college; I just wasn’t smart enough at the time to fully appreciate what I’d learned.

First and foremost is the “nobody ever got fired for hiring IBM” thinking of ERP implementations. In the “olden days” it was taken as gospel that many IT projects would go to an IBM solution because they were considered the gold standard in the industry. Therefore, by selecting IBM, decision makers sought to insulate themselves and their paychecks against potential criticism by making the “safe choice.” Today, you see companies hiring ERP implementation partners for the same reason. Big Important Partners give them the sense of comfort that they are in good hands.

I started my career working for a big partner, a real big partner: Price Waterhouse. At the time Price Waterhouse was not yet PWC and part of the admired “Big Eight” group of accounting firms. Interestingly, a saying I was soon to learn was that in the Big Eight, “The good leave, the bad leave and the mediocre prosper.”

I also learned that experienced partners and senior managers sold projects on the promise of size, references, and an endless pool of experienced resources. However, I was sent out as a seasoned consulting resource with a meager opportunity to get up to speed on software that I had never seen before. In the ERP space, I have seen this play out over and over, resulting in failed or mediocre ERP implementations that are over budget, over time, and not delivering on promised functionality.

Having been exposed to multiple business models in the industry I have come to see that there are fundamental drivers behind the behavior of the Big Important Partner firms that put them fundamentally at odds with their customer base and will forever hamper their ability to deliver excellent projects. These include:

Net new pressure
Overhead and scarce resources
Resource baiting and switching
Mergers and acquisitions and VC money

Let’s look at these issues one by one.

1. NET NEW PRESSURE

Software partners are rewarded primarily by their ability to sell new software deals or “net new.” The more you sell, the bigger the software margins, and end-of-year trips to resorts for fancy sales types and their spouses or girlfriends/boyfriends. Some bring both.

Sure, they pay lip service, and the occasional attempt to install implementation satisfaction metrics, but at the end of the day, new sales are king.

This conversation has NEVER happened at quarter, or especially fiscal year-end:

Partner: “I know we have had trouble getting our last several projects up and running, but just this once, could you look the other way and let us place this big order?”

Software Publisher: “We are sorry but our management is standing by our principle that every implementation has to meet strict satisfaction requirements for us to allow you to sell new deals.”

But wait; it gets worse…

The pressure to maintain the highest software margins creates incredible pressure to constantly sell new deals. Of course, large sophisticated ERP projects are, by nature, complex, expensive to sell, and have fierce competition between products and within product lines with competing partners.

This environment leads to two common sales strategies: Discounts, and dishonesty about the budget, timeframe, and software capabilities.

The typical project manager on an ERP implementation is easy to identify: He or she has the constant look of surprise/horror permanently imprinted on their face when they learn what the sales team promised the customer. In fact, a list of ERP project managers is worth its weight in gold for Botox providers.

2. OVERHEAD AND SCARCE RESOURCES

The double-edged sword plaguing a successful software product is a lack of quality resources to implement all projects with high quality teams.

Good ERP resources are brutally difficult to identify, hire, and keep. Especially in a hyper-competitive market that promotes job jumping and resource poaching. Great ERP resources are nearly impossible to find. They exist, but you just don’t know how to find them.

This shortage of resources inevitably creates an environment where top sales partners must staff projects with new, untested and often poor resources. Unfortunately, these resources demand high salaries and jump jobs with ever increasing offers of bigger and better compensation packages.

The result is predictable, poor implementation projects, write-offs, and more pressure on the bottom line. The resulting pressure creates poor morale on projects for both the customer as well as the implementation resources. Both move on to new partners and the cycle starts all over again.

3. RESOURCE BAIT AND SWITCH

Two other important lessons I learned early in my consulting career are that it does not matter how big a firm is or how many consultants they employ, what is important are the guaranteed resources that they can staff on yourproject. The key word here is “guarantee.”

Which leads us to the second lesson, impressive partner level resources may very well sella project, but it is the rotating cast of B and C team players who end up staffingmost projects.

In my career, I was consulting on software that I had learned about the day before. Even companies that offer “extensive” training to college grads send out armies of robots who know which buttons to push but have no business experience or savvy.

4. MERGERS AND ACQUISITIONS AND VC MONEY

If you were to combine the first three problems, they would still be dwarfed by the fourth. Running a profitable ERP sales and implementation firm is difficult for three reasons:

Complexity of business
Scarcity of resources
Cost of acquiring new business

Mergers and acquisitions and VC activity, by their nature, take money out of businesses because they demand high return for investors. This leads to an increased sales pressure, over-promising on projects, and the inevitable challenged or failed projects.

THE BOTTOM LINE

Avoid these pitfalls on your current or planned ERP project by hiring a Great Team rather than a Big Important Partner. If you are already locked into working with a BIP, consider asking for guaranteed, vetted resources.

In either situation, we can help avoid catastrophic failure. TurnOnDynamics (TOD) is a specialty, consulting firm that focuses on Microsoft Dynamics AX/D365. We are a partnership of senior AX consultants (no juniors learning on your dime) that specializes in providing high-level consulting services and fresh ideas to management teams implementing Dynamics AX, both new and challenged.

In my next post I will talk about the benefits of hiring a great team rather than an average partner or a sole practitioner.

ABOUT THE AUTHOR

The Microsoft Dynamics 10 Suggestions

Sat, 07 Oct 2017 16:12:00 GMT

ECAUSE 10 COMMANDMENTS SOUNDED PRESUMPTUOUS

With the Microsoft ERP and CRM User Group Summit less than a month away I thought it was my humble duty to assist the Microsoft Dynamics management team with their to-do list for the next year.

Just trying to be useful.

As an aside, except for some minor product-specific issues, the following list could be used by any ERP publisher, in any market segment any year.

IMHO, of course.

These things are certain at annual software summits:

The pronouncement that this is the “best year ever to be a partner!”
The introduction of new software features and functions that promise to provide “the best solution ever!”
Keynote speakers holding their breath while giving advanced functionality or technology demonstrations that they pray don’t crash.
Confused partners milling about, complaining, and strategizing about how to react to the latest “plan of the day.”

So, instead of the usual re-heated Pablum, here are my suggestions that would really shake up the market and make a difference over the next year and beyond.

Code freeze – take a deep breath and give everyone a year to catch up and learn the software they already have. This step may actually take significantly longer, but it would be a start.
Focus on the real users – instead of trying to figure out how to add the latest and greatest technology, how about some help to the folks that do all the work? A browser interface and a mouse are not the ideal tools for entering hundreds of transactions daily. What was the last ERP software innovation that made life easier for the people in the trenches?
Technology freeze – the biggest laugh I get in talking to AX users is when I demand to know who exactly it was that asked for Cortana (son of Siri) integration with their ERP system. It reminds me of standing in front of the towel dispenser in every public restroom wildly waving my hands trying to figure out how to make the three inches of paper towel dispense. Not everything is improved with additional layers of technology.
Stop renaming / rebranding – trying to keep up with the product name changes over the past year or so has given me ADD. But the Adderall has me focused as hell and it is not as bad for my teeth as the meth was. As an aside, what is with the secret product code names? Is this ERP software or a missile program?
Ride one horse – figure out an ERP solution and ride it. The biggest hidden lifetime ownership cost in ERP is moving from one product to another. I propose that it is easier to develop a scalable product than maintain multiple offerings. Here is your goal and marketing slogan: “from QuickBooks to SAP… we can replace it all.” You’re welcome.
Sell GP – to the existing dealers. What was once the greatest ERP partner channel in the world still has enough strong, dedicated players to kick some Acumatica, et al. arse. By the way, their channel recruiting staff will be wandering around at Summit picking off more disgruntled dealers. If you need someone to point them out, send me a first-class plane ticket.
Simplify pricing – if I can’t instantly produce a quote on the back of a business card, it is too complicated. When I have to download a document that is longer than War and Peace, it is insanity. The hidden problems caused by confusing pricing are immeasurable. How about this: one price for all available functionality! It is better to give too much than too little and risk looking like you are nickel and diming the customer.
Recognize the cloud is not for everyone – I get it, a lot of personal wealth is tied to stock options and the underlying stock price is probably disproportionately driven by how Azure is doing versus AWS and other cloud providers. However, everyone is not ready for the cloud. Accommodate all customer needs. Even the technology laggards. I guarantee a standing ovation at ANY conference where you announced the return of AX 2012.
Invest in training – take a nice chunk of the R&D budget for the next year and use it to train up the partner community. Free. In-depth. Meaningful. Training. Excellence in implementing your solutions will go so much further than layering on more functions or technology. Think of the goodwill that would be generated among partners and happy customers when they are not training “senior consultants” on their dime.
Net good, not net new – the myth of the Big Important Partner can’t die soon enough. There is a huge “secondary” market of under-the-radar companies and independent consultants that make a living cleaning up after the mess made by Big Important Partners. Reward great implementation efforts and not sales where the implementation team walks in and says, “you were promised what”?

Bonus suggestion: while we are at it, give everyone the same margin, you don’t need the extra cash as much as the small partner that is trying to make a living supporting your product. Again, think of the good will and how that money is leveraged in the partner community instead of your bank account.

And finally, remember that mighty oak trees grow from acorns. There are potentially profitable deals that do not want to start with twenty users. There are good companies that have sophisticated requirements and startups with big growth plans that should be on D365 but are turned away by the 20-user minimum. Why send them to a competitor and lose that business for 10-20 years?

I make my living in this space and have over thirty years of experience selling and implementing ERP software. Everything from MAPICS to Macola to Dynamics GP to AX and now D365.

I would love feedback on my list and see what you would edit, add, or delete. I think this industry is dying for new ideas and healthy debate generates them.

ABOUT THE AUTHOR

Why ERP Software Is So Hard to Use

Sun, 08 Jan 2017 17:22:00 GMT

Full disclosure: I am not a video gamer, too old and more interested in analog pursuits. My actual breakfast bagel and coffee are 100% more appealing to me than the picture of your breakfast delicacy posted on Instagram.

But I have kids with an Xbox and over the recent holiday they tried to get me interested in playing Halo, evidently one of the more popular video game offerings in the market. But, again, what do I know.

OMG…what an eye opener!

The care and love that had to go into creating that game literally jumps off the screen. And at that moment it hit me… the people that develop and “program” games are themselves gamers! They are actual consumers of the product they produce. They do their jobs as much out of love for the product that they enjoy as they do for making money. Boy does it show.

Now let’s contrast that with the teams of developers that you have met that create ERP applications. Come to think of it, has anyone ever met an ERP software developer? Do they even exist? Do they hide the fact out of fear that there is a social stigma attached? Are the embarrassed that they don’t work on cool “apps?

One thing is obvious, none of them have to use the crap that they code on a daily basis!

That gives us the consequences that we, as consumers of ERP software, have to deal with:

Impossible to navigate user interfaces.
Flash over substance…Oooooh, let’s all look at that shiny dashboard…does anyone understand the underlying data?
Technology that literally slows down ERP system use for the average user.
Technology for the sake of technology that makes systems harder to implement and maintain. Anyone else remember when “C:install” was all that was needed to install your accounting software?
Technology decisions driven by business models rather than what makes sense for the consumer.

And no, I am not a luddite or an old cranky guy. At the same time, I doubt average users are demanding the continuous onslaught of “improvements” that do nothing for the average user.

If we have all of these technologies and tools, why aren’t ERP systems easier to install and keep running? Don’t other industries pride themselves on “progress”? Imagine if every year cars used more gas, cost more money and were harder to start, stop and handle but car makers trumpeted that this was the latest and greatest?

None of the major technological advances that have been applied to ERP software have benefited the average user. Everything is flash for the main stage at a conference. What has anyone done to speed up the entry of hundreds of vouchers? Go ahead, I’ll wait.

Maybe every developer should be forced to eat their own dog food for a month. Maybe the next release would actually “empower every person on earth.”

ABOUT THE AUTHOR

Making Sense of the Latest Dynamics Office 365

Mon, 15 Aug 2016 16:34:00 GMT

SITTING BACK AND TRYING TO UNDERSTAND THE DETAILS BEHIND MICROSOFT’S DYNAMICS OFFICE 365 ANNOUNCEMENT HAS ME SHAKING MY HEAD.

With all the money and resources at their fingertips, Microsoft gets one critical thing wrong in their Dynamics Office 365 strategy. My guess is that once again love of technology and/or a need to drive Azure licensing has overcome common sense.

The Dynamics Office 365 announcement is confusing to understand with a lot of moving parts but here is the Twitter version:

Dynamics Office 365 will have two versions. Small businesses will have a version based on a cut-down version of Dynamics NAV ( the Madeira project ) and enterprise customers a different version based on Dynamics AX.

Why does the shortsightedness of this not scream at anyone and everyone involved?

What is the most expensive, time consuming and disruptive event for any company in regards to their ERP system?

When they outgrow their existing system!

And please, spare me the inevitable upgrade pricing plan and upgrade tool set that will be announced to “seamlessly transitions companies and provide richer content to empower users”.

Why not create a small business version of Dynamics AX that will allow companies to grow into a full enterprise solution as their business grows?

Here is my guess.

AX has become so bloated with “technology overkill” that running it in the cloud is a nightmare. I hate to beat this horse to death but who exactly was screaming for browser based accounting software with Son of Siri…sorry Cortana integration?

So making a small business version of AX that runs economically in the Azure cloud was or is not possible. Instead of fixing that issue it was evidently easier to create a QuickBooks alternative using Dynamics NAV as the foundation.

Who is the ultimate loser in this strategy? The customer of course.

Maybe it would have been harder or taken more time to do this right but the clock is ticking on Azure revenue and the stock market is watching. Business publications have speculated that the legacy of Satya Nadella is tied to his pivoting Microsoft to be all in on his cloud direction.

So we have this bifurcated ERP cloud strategy for business reasons or because someone did not have the strategic vision.

Maybe I am missing a third explanation but what a missed opportunity!

Imagine being able to start a company on a small business version of your ERP software that works seamlessly in the Office 365 stack and never have to worry about outgrowing the solution.

Now that would have been The ERP Killer Product for partners and customers to embrace!

ABOUT THE AUTHOR

In Praise of ERP Architects

Mon, 04 Jul 2016 16:38:00 GMT

Why do sophisticated ERP projects require an “ERP Architect”? And why are ERP Architects the difference between sitting at the starting gate of the Kentucky Derby on either Secretariat or on a camel?

Think about your current ERP implementation or any other that you have been associated with.

I will wait a minute for the dull ache behind your eyes to subside.

Do your memories include any meetings where there was a clear visionary leader that understood the “big strategic picture” and was able to keep the team focused on that goal instead of mired in endless minutia?

Of course you don’t.

What you do remember is an endless series of long forgotten meetings with endless debate over tiny and often mostly irrelevant details.

Quick re-cap: Everyone sets out to design the Secretariat of ERP implementations but because “Camels are Horses designed by Committees”, everyone ends up with some version of the following:

ERP Architects exist but they are rare. Rarer is the company that has the self-awareness and ability to hire and follow an architect.

But what are the skill sets of great ERP Architects? In my experience they have the following abilities:

Functional – be able to process transactions in most major functional areas of the application.
Data – full understanding of the data structure underlying the application.
Financial – ability to understand and trace the general ledger impact of all major transactions in the application.
Technical – understand the position and function of the application in the Microsoft technology stack.
Experience – approach or exceed Malcolm Gladwell’s 10,000-hour rule in both new and challenged implementations in a wide range of businesses small and large.

But most of all a great ERP architect has to be able to combine all of these skills in a seamless ability to see the forest for the trees. All ERP projects are a combination of hundreds of “critical requirements.” The ability to ignore the constant noise and focus what is important is the key.

The great ERP Architect is able to eliminate the lack of strategic focus that plagues large ERP implementations.