Friday, August 16, 2013

Two potential Dynamics GP design limitations for larger or growing companies

By Steve Endow

I recently spoke with a Lawson consulting firm.  One of their Lawson customers acquired a company that uses Microsoft Dynamics GP.  The Lawson client manages 3 companies in their system, while the GP client manages 9 companies.

In Lawson, the 3 companies are managed in a single database.  But in Dynamics GP, the 9 companies are managed in 9 separate company databases.  The client was debating whether to continue to use Lawson, or to transition to Dynamics GP.  The Lawson partner's concern was whether the client would be willing to transition to a system that kept the companies in separate databases and required them to switch companies all the time.

Obviously, there are thousands of Dynamics GP customers that have multiple company databases and manage them without issue.  And I know of several companies that have over 200 active company databases in Dynamics GP.  I am not sure how they handle that many companies and retain their sanity, but they apparently manage.

Anyway, the Dynamics GP design where each company uses a separate SQL Server database is often considered a limitation or weakness for multi-company entities that are evaluating ERP systems.  Some companies don't mind multiple databases, whereas others consider it a significant weakness and hindrance, perhaps due to administration, reporting, data entry, etc.

Sheldon Gitzel recently discussed this issue and a few possible solutions in a blog post on the Etelligent ERP Blog.

So if any GP competitor claims that GP can't effectively manage multiple companies, such a claim is clearly not true--the solution is just different than some larger ERP systems.  Systems that manage multiple companies in the same database may have some advantages, but such a design also has potential disadvantages, such as having to deal with a single very large database.

So that is one potential concern for a large company.

A second Dynamics GP design limitation is lack of global support for "effective dates".  If an employee's pay or benefits or deductions are going to change next month, there is no option to enter those changes in Dynamics GP with a future effective date.  Many "higher end" systems have native global support for effective dating.  With effective dating, an inventory item can be discontinued on a future date, future pay raises can be entered and put into effect automatically, or special prices and discounts can be date-based.  I have only worked with one GP customer that really needed effective dating--they had hundreds of employees and effective dating was critical for their HR and Payroll processes--but as companies grow, such a feature often becomes more important.  If anyone knows of an add-on that allows Dynamics GP to have effective dating, please post a comment and let me know.

Related to the lack of effective dating is that record changes are not tracked in Dynamics GP.  So if an employee or customer or vendor address record is updated, there is no record of the prior value--only the current value is saved.  The customer could purchase an add-on such as Rockton Auditor to track the changes made in GP, but that is an additional $250 per concurrent user and still doesn't provide effective dating.

This isn't intended to be a criticism of Dynamics GP, as these features are typically fundamental design choices and add complexity.  I just wanted to explore two general areas where larger companies might indicate that they need a "larger" or "tier 1" ERP system and claim that Dynamics GP doesn't meet their needs.

Have you observed any situations where a customer felt they couldn't use Dynamics GP because it didn't have a feature of a "larger" ERP system?


Steve Endow is a Dynamics GP Certified Trainer and Dynamics GP Certified IT Professional in Los Angeles.  He is also the owner of Precipio Services, which provides Dynamics GP integrations, customizations, and automation solutions.

You can also find him on Google+ and Twitter




No comments: