This Beyond the BC Bits blog series focuses on the non-technological factors that play crucial role in determining the overall success of an organization’s Business Central implementation project. The goal is to highlight and provide guidance on many of the major factors that will most significantly impact your project’s success.
Part 1 of this series covered how to properly prepare for your implementation project, while Part 2 covered how to work with a Business Central partner, Part 3 covered the best practices for managing the implementation project, Part 4 provided strategies for how to approach training and testing of the application. Future articles in this series will cover data migration and deployment, and long-term management of Business Central.
In this article, the focus is on customization of the Business Central application. Topics will include strategies for defining which situations are the most ideal for customization, alternatives to customization, when to customize, and how to ensure long-term success when deploying customizations.
Customization capabilities are what makes Business Central special
Most of the guidance I will be providing in this post may come across generally as “Do not customize Business Central”. But that is not my position at all. Quite the contrary. I believe that the customization capabilities within Business Central are exactly what makes Business Central special. For many, many years, the tagline for this application was “Made for the way you do business” (or at least that is the tagline we applied to it!). The organizations most suitable for Dynamics 365 Business Central (formerly Navision, and then Dynamics NAV) were very often those organizations that required a broad-based ERP solution with a wide horizontal set of features and functionality, but also knew that they were unique in some way and that these unique requirements could only be met with customization to the ERP solution. And Business Central provides this very wide and very strong foundation for building a tailored solution designed to fit each organizations requirements.
Now that Business Central is hosted online by Microsoft with monthly updates and major releases being auto-applied on a consistent basis, the development environment has been modernized, but the same strong development capabilities exist. Being able to tailor the application to provide the absolute most efficient processes continues to be one of the great strengths of Business Central and will be for years to come.
So as you continue to read through this post, please understand that I am a proponent of customizations to Business Central. However, the customizations being made must be structurally sound, they must have a positive return on investment, they must be done in a thoughtful manner, and they must be documented and approved so there is transparent buy-in across the organization. A great strategic customization has the potential to be what separates your organization from your competition, and when I see those customizations being put in place, it brings a smile to my face. Let’s proceed with figuring out how we can differentiate these great customizations from the not-so-great customizations!
Only change the application when absolutely necessary
It is particularly important to limit customizations during the implementation of Business Central. I would go so far as to say that the only time a customization is warranted during the implementation is when the standard functionality provided within Business Central prevents you from completing a required function or task. Limit all customizations except in cases where a key task cannot be completed without a customization. This guideline is essential to managing the project budget and timeline.
Once users become more familiarized with Business Central through daily use of the system over a period of time, they may realize that the standard method of processing a transaction is actually not as difficult as it initially appeared. System optimizations and work-arounds can always be addressed after the initial deployment has been completed.
And even if after a period time, if it is determined that a customization is the best solution for the improving user efficiency and accuracy, the Business Central internal user community will be much better prepared to ensure that the customization is properly designed to meet the long-term objectives of the organization.
Some customizations are better than others
Not all customizations are created equally. The best customizations are those that provide small adjustments and enhancements to the standard functionality without changing the core functionality of the application.
Examples of “good” customizations are creating additional fields on an Item or Customer record to store some additional pieces of information that are meaningful to users or beneficial for reporting purposes. Other examples include new logic to default values into fields to improve user efficiency, or providing new warnings or validations to the user if specific conditions aren’t met prior to posting a transaction as these can eliminate significant time in correcting data. These types of customizations do not impact the way in which transactions are created and processed within Business Central, which means that these customizations should have minimal impact on any future changes or new features that are deployed to Business Central.
Examples of “bad” customizations are those that directly impact how transactions are created or processed within Business Central. A great example of this would be a customization to the logic used when generating inventory cost entries to the Item Ledger and/or General Ledger. This type of change impacts a large number of transactions, impacts the reconciliation of the inventory valuation of the General Ledger, may result in rounding issues when extending to multiple decimal places, could have impacts on alternative currency amounts, and would limit your partner or Microsoft’s ability to adequately support your Business Central environment when related issues arise. Another example of a bad customization would be one that changes the planning logic used within the Requisition Worksheet or Planning Worksheet since there are such a large number of variables that must be considered as suggested purchase or production messages are created.
These examples above are clear and concise in terms of good or bad, but unfortunately not all examples are this clear cut. The best way to proceed is to ask your partner to confirm if a customization should be considered to gain their perspective. Also, be sure to confirm what the long-term impact will be in terms of upgrading to new releases and being able to support the solution when issues inevitably arise.
Don’t be afraid to ask “Why?”
The implementation of a new ERP solution is an excellent opportunity to ask "Why". While reviewing how each process is handled within your organization, if someone on the team declares that the standard functionality of Business Central is not adequate and a customization is required, ask "Why?". While the request may be valid, it may just be part of a legacy process that is no longer relevant and can be eliminated with the deployment of Business Central. A common mistake made during the implementation process is forcing the system to perform tasks that were previously done because “That’s the way we do it.”. Oftentimes, processes can be simplified or even eliminated due to inherent differences between the old system and the new system, outdated business rules or practices, or changes to the business over the years.
Consider alternatives for each customization request
When the standard functionality will not meet the needs of the user community, this is referred to as a gap. Meaning there is gap or difference between the functionality provided and how it needs to work in order for people to be able to do their jobs effectively within the application. But a customization is not the only possible solution for a gap.
One option is to change the business process so that a customization so that the customization is no longer required. This could mean a few additional clicks of the mouse in order to complete a transaction, the need to run a report as part of a process to validate the data, or differences in which users complete specific tasks. While a change in business process is certainly not ideal in many situations, it is the best place to start when verifying if a customization is truly required.
A second option is the use of a third-party application to supplement Business Central. There are thousands of certified apps for Business Central that have been designed and provided specifically to fill gaps for processes that many organizations require. The benefit of a third-party app is that the functionality has already been designed, tested, and deployed elsewhere this can provide a more robust solution in a much quicker timeframe.
The potential downsides of apps is that the functionality may not be exactly what is required or it may include a lot of functionality that is not really required within your organization, and of course there may be a long-term licensing costs that need to be considered when making a purchase decision.
One final solution for filling the gap is a combination of the above options. Perhaps some minor adjustments to the business process combined with some light customizations to the application provides a complete solution for the user community. This is ideal as an effort should always be made to reduce or limit the number of customizations.
Document each customization both before and after it is completed
Each customization to be created should be formally documented on a specification document. Some people may refer to this document as a Functional Specification, Software Design Specification, or other term, but the key is that the detailed changes to be made to the system are well-documented in order to ensure that there are no mis-communications or bad assumptions made regarding what the customization does and does not do.
Not only does the specification document provide short-term benefits by providing a detailed explanation of the changes to be made, but it can also serve as a testing guide, a user documentation guide, and a post-implementation reference guide for users who may not remember the detailed design of a custom feature.
After the specification document has been completed and the new design approved by all key users of Business Central, the document should be signed by both the Project Manager and Executive Champion prior to beginning development of each customization. This formal approval structure ensures that each customization has been reviewed and confirmed by multiple levels within the organization and that the customization will have a positive return on investment for the organization.
Finally, create end user documentation for each customization. The specification document should be used as the starting point and basis for creation of the end user documentation. This user documentation should be shared with all Business Central users and should be stored on a shared location where users can access these in the future. Finally, remember to update the user documentation whenever any future revision or enhancement has been made to the customization. It is very common to make additional customizations and if these have not been documented, this will lead to confusion and frustration as users work to figure out how the customization works.
ความคิดเห็น