Comments on: Top 7 reasons why to avoid (much) customization http://navigateintosuccess.com/blog/top-7-reasons-why-to-avoid-much-customization Ensuring Microsoft Dynamics NAV implementation success since 2003 Thu, 17 May 2012 21:05:45 +0000 hourly 1 http://wordpress.org/?v=3.3.2 By: Vjekoslav Babic http://navigateintosuccess.com/blog/top-7-reasons-why-to-avoid-much-customization/comment-page-1#comment-948 Vjekoslav Babic Tue, 31 Mar 2009 10:57:54 +0000 http://NavigateIntoSuccess.com/blog/top-7-reasons-why-to-avoid-much-customization#comment-948 Manual trackback: http://niiranen.eu/crm/?m=200902 Manual trackback:
http://niiranen.eu/crm/?m=200902

]]> By: Vjekoslav Babic http://navigateintosuccess.com/blog/top-7-reasons-why-to-avoid-much-customization/comment-page-1#comment-947 Vjekoslav Babic Tue, 17 Mar 2009 13:11:05 +0000 http://NavigateIntoSuccess.com/blog/top-7-reasons-why-to-avoid-much-customization#comment-947 Yehia: I don't know much about GP, but the guidelines I gave shouldn't ever be cast in stone. If you have a valid reason for change, by all means change. What I was primarily arguing against in my post is "customization by default" approach, under which just about everything is customized--something that I've been seeing around a lot. In NAV, you have security roles that can take care of record-level security, I don't know if something like that exists in GP. If it doesn't, then modifying forms (or windows, I don't know what's the correct GP term) might be the only solution, and in this case it might be a valid reason to do this modification. If you need a good GP blog to look for the answer to your question, I suggest Mark Polino's excellent blog at http://msdynamicsgp.blogspot.com/ Yehia: I don’t know much about GP, but the guidelines I gave shouldn’t ever be cast in stone. If you have a valid reason for change, by all means change. What I was primarily arguing against in my post is “customization by default” approach, under which just about everything is customized–something that I’ve been seeing around a lot. In NAV, you have security roles that can take care of record-level security, I don’t know if something like that exists in GP. If it doesn’t, then modifying forms (or windows, I don’t know what’s the correct GP term) might be the only solution, and in this case it might be a valid reason to do this modification.
If you need a good GP blog to look for the answer to your question, I suggest Mark Polino’s excellent blog at http://msdynamicsgp.blogspot.com/

]]> By: Yehia Kamel http://navigateintosuccess.com/blog/top-7-reasons-why-to-avoid-much-customization/comment-page-1#comment-946 Yehia Kamel Tue, 17 Mar 2009 12:39:16 +0000 http://NavigateIntoSuccess.com/blog/top-7-reasons-why-to-avoid-much-customization#comment-946 I totally agree with you, but with Microsoft dynamics GP we are facing a big problem regarding record level security for multi branches organizations, because GP does not have such security privileges for each branch to secure his data from being modified by another branches like (customers, vendors, checkbooks, SOP types and sites), so could you please inform me how can I secure my customer's information without customization those windows? Thanks I totally agree with you, but with Microsoft dynamics GP we are facing a big problem regarding record level security for multi branches organizations, because GP does not have such security privileges for each branch to secure his data from being modified by another branches like (customers, vendors, checkbooks, SOP types and sites), so could you please inform me how can I secure my customer’s information without customization those windows? Thanks

]]> By: Vjekoslav Babic http://navigateintosuccess.com/blog/top-7-reasons-why-to-avoid-much-customization/comment-page-1#comment-945 Vjekoslav Babic Wed, 18 Feb 2009 01:52:12 +0000 http://NavigateIntoSuccess.com/blog/top-7-reasons-why-to-avoid-much-customization#comment-945 <strong>Felipe: </strong>welcome to the blog, and thanks for comment! I'd say that with NAV it's the same story: there are many layers that you can customize, and you must take good care about what to touch, and what not to touch. In my book, I've explained how to do customizations so that they have little impact on upgradeability. <strong>Erik: </strong>I am not sure that the criteria you listed (about the competition, and "stealing" customers) have anything to do with being 100% dedicated to add-ons. It's definitely bad practice to "steal" customers, but I wouldn't say that you shouldn't ever sell services directly to end-users, provided that these services are about your add-ons, and not about general implementation. If a customer decides to hire you, and their partner does not object, then it should be ok. When it is about general implementation, I totally agree - it's something that add-on vendors generally should not do. But I am sure that most of serious add-on vendors are very well aware that they can make more money and deliver more quality if they focus on their add-ons and leave implementation projects to other companies, and most of those that you listed actually did that, successfully. Felipe: welcome to the blog, and thanks for comment! I’d say that with NAV it’s the same story: there are many layers that you can customize, and you must take good care about what to touch, and what not to touch. In my book, I’ve explained how to do customizations so that they have little impact on upgradeability.

Erik: I am not sure that the criteria you listed (about the competition, and “stealing” customers) have anything to do with being 100% dedicated to add-ons. It’s definitely bad practice to “steal” customers, but I wouldn’t say that you shouldn’t ever sell services directly to end-users, provided that these services are about your add-ons, and not about general implementation. If a customer decides to hire you, and their partner does not object, then it should be ok. When it is about general implementation, I totally agree – it’s something that add-on vendors generally should not do. But I am sure that most of serious add-on vendors are very well aware that they can make more money and deliver more quality if they focus on their add-ons and leave implementation projects to other companies, and most of those that you listed actually did that, successfully.

]]> By: Felipe Conill http://navigateintosuccess.com/blog/top-7-reasons-why-to-avoid-much-customization/comment-page-1#comment-941 Felipe Conill Tue, 17 Feb 2009 20:52:18 +0000 http://NavigateIntoSuccess.com/blog/top-7-reasons-why-to-avoid-much-customization#comment-941 Great Post. Customizations should be seen as a last resort. Also its important to understand at what layer to customize. In GP you can go from triggers, dexterity, VBA, etc. It is important to customize at the right layer Great Post. Customizations should be seen as a last resort. Also its important to understand at what layer to customize. In GP you can go from triggers, dexterity, VBA, etc. It is important to customize at the right layer

]]> By: Vjekoslav Babic http://navigateintosuccess.com/blog/top-7-reasons-why-to-avoid-much-customization/comment-page-1#comment-944 Vjekoslav Babic Tue, 10 Feb 2009 07:23:56 +0000 http://NavigateIntoSuccess.com/blog/top-7-reasons-why-to-avoid-much-customization#comment-944 <strong>Vaidy: </strong>Thanks, that's what I hoped to do--to give people insight that they don't always have when doing implmentations. Implementations themselves are risky enough, too many customizations just introduce too many unnecessary risks, and there are better approaches, about which I will talk in a future post. <strong>AXManufacturing: </strong>Vertical add-on is not the same thing as customization, and they are definitely a preferrable choice. They work a little bit differently between NAV and AX, but generally their advantage is that they are developed and maintained by a company who generally specializes in them and doesn't do implementations directly. By choosing a vertical add-on, a company mitigates majority of the issues I discussed here in my post. What some customers do, however, is that they give up on an add-on and decide to develop the vertical functionality specifically for their project--such customizations have high risk of failure and introduce long-term maintenance costs. <strong>Both:</strong> Thanks for comments, and welcome to this blog! See you around! Vaidy: Thanks, that’s what I hoped to do–to give people insight that they don’t always have when doing implmentations. Implementations themselves are risky enough, too many customizations just introduce too many unnecessary risks, and there are better approaches, about which I will talk in a future post.
AXManufacturing: Vertical add-on is not the same thing as customization, and they are definitely a preferrable choice. They work a little bit differently between NAV and AX, but generally their advantage is that they are developed and maintained by a company who generally specializes in them and doesn’t do implementations directly. By choosing a vertical add-on, a company mitigates majority of the issues I discussed here in my post. What some customers do, however, is that they give up on an add-on and decide to develop the vertical functionality specifically for their project–such customizations have high risk of failure and introduce long-term maintenance costs.
Both: Thanks for comments, and welcome to this blog! See you around!

]]> By: Vaidy Mohan http://navigateintosuccess.com/blog/top-7-reasons-why-to-avoid-much-customization/comment-page-1#comment-943 Vaidy Mohan Tue, 10 Feb 2009 01:42:00 +0000 http://NavigateIntoSuccess.com/blog/top-7-reasons-why-to-avoid-much-customization#comment-943 Hi Babic, Your article has given me a whole new dimension to think of an ERP Customization. I do not argue for unwanted customizations, for sure, but with this article, now I am going to think twice for any customization as such. Thanks for this insight. Thanks Vaidy Hi Babic,

Your article has given me a whole new dimension to think of an ERP Customization. I do not argue for unwanted customizations, for sure, but with this article, now I am going to think twice for any customization as such.

Thanks for this insight.

Thanks
Vaidy

]]> By: AXManufacturing http://navigateintosuccess.com/blog/top-7-reasons-why-to-avoid-much-customization/comment-page-1#comment-942 AXManufacturing Tue, 10 Feb 2009 00:12:16 +0000 http://NavigateIntoSuccess.com/blog/top-7-reasons-why-to-avoid-much-customization#comment-942 I generally agree however the Microsoft Dynamics AX (Axapta) platform with its 100% Object Oriented Integrated Development Environment (IDE) is nicely suited for building vertical applications. Many AX customers get themselves in trouble by modify too many objects necessary to achieve horizontal customizations. Microsoft almost always enhances those objects with each major version which means conflict when you upgrade. If you create new objects for vertical customizations then they should upgrade without any conflict. Be insightful and mindful on the number and kind of customizations using the Dynamics AX (Axapta) platform. I generally agree however the Microsoft Dynamics AX (Axapta) platform with its 100% Object Oriented Integrated Development Environment (IDE) is nicely suited for building vertical applications. Many AX customers get themselves in trouble by modify too many objects necessary to achieve horizontal customizations. Microsoft almost always enhances those objects with each major version which means conflict when you upgrade. If you create new objects for vertical customizations then they should upgrade without any conflict. Be insightful and mindful on the number and kind of customizations using the Dynamics AX (Axapta) platform.

]]> By: Vjekoslav Babic http://navigateintosuccess.com/blog/top-7-reasons-why-to-avoid-much-customization/comment-page-1#comment-940 Vjekoslav Babic Mon, 09 Feb 2009 21:05:37 +0000 http://NavigateIntoSuccess.com/blog/top-7-reasons-why-to-avoid-much-customization#comment-940 Mark, I totally agree with you on this. I also can't stress out to my customers how important it is for them to rethink their processes, because there is no better moment do to that, thank the ERP implementation. The "our old software" sindrome is far too common, and there is no better cure for it than plain, standard ERP, whichever the flavor, Dynamics or other. Mark, I totally agree with you on this. I also can’t stress out to my customers how important it is for them to rethink their processes, because there is no better moment do to that, thank the ERP implementation. The “our old software” sindrome is far too common, and there is no better cure for it than plain, standard ERP, whichever the flavor, Dynamics or other.

]]> By: Mark Polino http://navigateintosuccess.com/blog/top-7-reasons-why-to-avoid-much-customization/comment-page-1#comment-939 Mark Polino Mon, 09 Feb 2009 16:10:13 +0000 http://NavigateIntoSuccess.com/blog/top-7-reasons-why-to-avoid-much-customization#comment-939 Very nice post. From the Dynamics GP side I would also add Improvements. I frequently see companies customizing a new ERP system to act like the system they are replacing. You know, the one they complain about, can't make work and are generally unhappy with? A new ERP system is the time to look at all those assumptions, processes and limitations from the old system and figure out how to make them go away. Mark Very nice post. From the Dynamics GP side I would also add Improvements. I frequently see companies customizing a new ERP system to act like the system they are replacing. You know, the one they complain about, can’t make work and are generally unhappy with? A new ERP system is the time to look at all those assumptions, processes and limitations from the old system and figure out how to make them go away.

Mark

]]>