NetSuite/Enterprise Software Customization
Enterprise software customization and by extension NetSuite customization still gets a bad rap. Yes, there are risks involved in NetSuite implementation, and yes, customization does add yet another layer of uncertainty to the situation. But enterprise software customization isn’t the wild west it used to be. Just a few more years of experience has led to improved processes that significantly reduce the risk involved with large-scale customization projects.
The data shows that businesses are becoming more open to customizing their IT portfolios. However, the rate of adoption is still out of touch with the opportunity custom options provide. Still, too many executives and admins see the risks involved with the projects and gloss right over the opportunity that a customized version of the worlds best cloud ERP can bring to their business.
So to help NetSuite customization get rid of its poor reputation, eMerge Technologies is offering the NetSuite community three tips. We believe these three guidelines significantly improves the chance of a NetSuite customization project being a success and a much more positive experience in general.
I want to take this moment to clarify what I mean by NetSuite customization as opposed to NetSuite configuration. As there may be some semantic confusion between these two concepts. For this article, consider NetSuite customization as anything that involves scripting or third-party software to enable NetSuite to do something it does not have any configurable or native functionality to do out-of-the-box.
NetSuite Customization Guidelines
1. Customize During Implementation
The absolute best time to get all/most of your customizations and integrations done is during the implementation phase. Plan out and build the custom objects, processes, scripts, integrations, functionality while everyone is still getting acclimated to the new system.
This will help you in at least three areas.
- Employees learn all the new and custom processes at the same time and won’t get strung along a seemingly endless chain of new routines to learn.
- Real data will not get corrupted by untested customizations, as real data will be imported after custom functionality is fully tested and operational
- Customizing/Debugging/testing after go-live could slow down or prevent employees from handling their normal day-to-day tasks
2. Get a Sandbox
It is ideal to have test environments for the applications you’re working in. For this reason, we strongly recommend getting NetSuite Sandbox if you are planning to engage in customization of the platform. A sandbox will give you a replica of your current NetSuite environment with all of your data. You can do whatever you want with this data, including testing new applications and integrations.
There are a number of reasons to get a Sandbox but developers love their ability to test before go-live. This allows them to catch small bugs before they snowball. Sandboxes can easily pay for themselves by preventing disasters.
3. Keep Proper Documentation
Documentation is an important part of enterprise software customization. This is no different for NetSuite. Good documentation will discuss the goals the end-users wish to achieve and how the developers plan to achieve those goals. Good documentation will also provide a way for future developers and end-users to retrace the logic and thinking behind the customizations in order to evaluate or improve it as time goes on. Also as time goes on, you may end up with a number of customization projects from a number of developers. Documentation can help you keep track of these customizations and get new developers up to speed faster. For these reasons, we strongly recommend that NetSuite users get extensive documentation on all of their customization projects.
Technical Requirements Document
A “Technical Requirements Document” (TRD) is the first document NetSuite users should ask for when engaging in any enterprise software customization. The TRD is the agreement between users and developers that states, in great detail, what functionality is being developed and what exactly it is supposed to do. This document will catch communication errors between users and developers as well as provide both parties with a road map to success.
Be sure to include “Test Cases” in the TRD. On the road map of success, the test cases are the finish line. Test cases represent the functionality or use-cases the customizations are supposed to accomplish. Test cases should replicate the exact conditions the customization would be expected to succeed in during a production run. Once the test cases are all knocked out, devs can bring back in the end-users for final inspection and approval.
NetSuite Descriptions/Help Fields
An easy way to help end-users understand what is happening with a customization project is the description fields and help boxes provided by NetSuite. Custom records, fields, and scripts come with description fields. Developers should take advantage of these to easily answer questions end-users may have about new functionality.
Custom Field level Descriptions
Script level Descriptions
Code Level Comments/Syntax
Another layer of documentation occurs in the coding itself. Comments can be written directly into the code. These comments should provide context for the code and help future developers and administrators understand how to use or evaluate the code.
There is also something to be said for how the code is written. Sloppy or hastily written code can be harder for future developers to understand. Make sure the developers you work with are taking their time to write the code in a way that can be easily deciphered during later inspection.
I hope this article helps NetSuite users get a better experience from their NetSuite customization projects. But if you walk away with anything from this article, please let it be these points:
- Customization and integration is best done at the same time the platform is being implemented.
- Testing customizations is important. Getting a NetSuite Sandbox will make testing much easier and can help you avert crisis down the road.
- Documentation of the customization process is critical to staying organized over time. Many times projects will be picked and dropped by different teams; detailed documentation will make these transactions smoother.
- Get a Technical Requirements Document signed by both parties so there are no early miscommunications and everyone has a ‘path towards success.