Dynamics GP customizations are like tattoos

June 12 2013

Customizations in Microsoft Dynamics GP are like tattoos. A few, strategically applied are fine, but they are hard to remove when you change your mind. Plus, you'd better know what you have and where it is.

My wife has a tattoo to commemorate the loss of her sister to ovarian cancer. That's a tough tattoo to argue with.  Likewise, for most companies that customize Dynamics GP, the first few usually make pretty good sense.  An item gets identified in the implementation stage as a gap and a customization is the best solution. Congratulations on your first tattoo!

About Mark Polino

Mark Polino is a Certified Public Accountant (CPA) and a former Microsoft MVP (2007-2018) for Business Solutions. He is the author or coauthor of 5 books related to Microsoft Dynamics GP.  Mark also maintains the Dynamics GP focused website DynamicAccounting.net. He speaks and writes regularly about ERP related topics. Mark has been a controller and CFO for a division of a publicly traded company and he has  worked as a consultant implementing ERP solutions. Mark holds additional certifications including Certified Information Technology Professional (CITP), Certified in Financial Forensics (CFF) , Chartered Global Management Accountant (CGMA). Dynamics Credentialed Professional for Dynamics GP 2015 (Core Install and Core Financials), Xero Certified. He holds a bachelor's degree in accounting from the University of Central Florida and an MBA from Rollins College. Mark lives with his family in Florida.

More about Mark Polino


mgomezb's picture

Mark, excellent article! Arguably, tattoos are an extension of someone's identity. Likewise, customization can provide that unique competitive or strategic advantage a company is looking for in the market place. Like tattoos, customization should carefully be selected and evaluated prior to their implementation and deployment. I strongly advise customers to look into the pool of great Microsoft Dynamics GP ISV products in the market prior to deciding for a customization. After all, companies would not have to rely on one or two individuals to maintain these customizations, but rather another organization whose sole purpose is to make a living from a widely available product. Also, customers may be surprised how willing the ISV community is to work with them to tailor their solutions to specific customer needs. I truly enjoyed the article. Keep up the good work. MG.- Mariano Gomez, MVP

bklenzman's picture

Hi Mark- Good article. I'd like to emphasize your point that software does not fix procedural problems. I often encourage customers to "flow chart" their business. What I mean by this is that they need to work with all departments to figure-out HOW they do things now, document those processes, and ask WHY every step along the way. If you do not know why you are doing something, it is a mistake to freeze it into software. Down This Path There Be Dragons. Often the activity of an organization having these business process discussions leads to Ah-Ha moments which result in procedural changes, which eliminate the need for customization. I was working on a manufacturing implementation years ago where the client needed a way to record the Lot Number of water used on the manufacturing order. They filtered their own water into a 500 gallon tank. Water used "today" was drawn from the large tank into a smaller container and the "lot number" was the date. At the end of the day they dumped the water. And, the MO was created and received on the same day--so the fact that the MO was received "today" meant you used "today's" water. They had never asked themselves WHY they were recording the date of the water, and not doing it solved a data recording problem in the software and saved them some time. I think it's a bit of a straw-man argument to fault the "change location code & lock it" customization for the organization not knowing WHY they had it. It may have saved them many costly mistakes. Also, the same "failure" applies to implementations as a whole: * Why did we decide to use one U of M Schedule for all items? * Why did we create Customer Numbers containing the Street Address? * Why do we manually enter the User ID into SOP User Defined #1 (it's captured in the database anyway)? WilloWare has done over 600 custom projects over the years and not one has prevented a client from upgrading, which I believe emphasizes your point: a carefully planned, cost-justified, professionally executed customization is a work of art that you'll be happy to have. -Brenner Klenzman