Buy or Build? NetSuite Customization

Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn
These days, figuring out how to implement a system that you need for your business can be a challenging process. Do you buy something “off the shelf” which has most of what you need, or do you build it on top of a SaaS system such as Salesforce or Netsuite, which allows you to build a lot of custom functionality while leveraging a best-in-class CRM or ERP system?

We approach the decision by breaking things into two important groups, the “knowns” and the “unknowns.” The “knowns” are things to expect, including: a prioritized functionality list, an assessment of “canned” products already out there, an assessment of how much config a “canned” solution would need, the need to set time & money budgets (don’t forget consulting costs), and finally, allocation of internal resources for the effort.

The “unknowns” are  examples of the unexpected, including the fact that custom software build projects are a “new thing” for most teams. Finding the right consultants can be time consuming, and un-planned impacts can slow timelines and increase internal team resource load. Change management, adoption and training are always more difficult than expected, and it can be challenging to align business stakeholders during the project (again, whether built or bought).

Building a formal process document, or several, (typically at a very high level) with all key users can allow internal and external project team to align around a single vision which is an essential factor when designing software.

We recently designed and built a custom part number configurator for the East Coast manufacturing firm Equilibar, LLC, working with the operations team under David Reed. We started with getting an idea of what they wanted and quickly moved into the design/build discussion based on our review of their ERP system (NetSuite) strengths and weaknesses. We looked at one viable “buy” option, and assessed the gaps if we followed that path. The end result was to build instead of buy.

I recently spoke with David Reed about their decision making  process.

The native functionality of Netsuite would not allow us to efficiently build specific elements we needed for our pressure regulator manufacturing business. For years we had used work-arounds that included databases written externally in Microsoft Excel. This added complexity required us to use multiple pieces of software for any given task rather than using Netsuite as a true full function ERP package. To find a solution that would allow us to build part numbers, for example, within Netsuite, we looked at both market ready packages and custom written software. The ultimate deciding factor was the realization that off-the-shelf products were not going to eliminate the need for custom development. The great likelihood was that we would still need to locate and engage a custom software company to modify the off-the-shelf solution. That approach did not mitigate any of the risks usually associated with custom software development, and in fact may have created additional risks given the greater number of parties involved. If we were going to need to write custom software anyway, why not just write the software from scratch to meet our goals exactly? That is what led us to engage with OpenIssue to develop our tool within NetSuite.

In working with David and his team at Equilibar, our first step was to create a meta-sales process allowing the team to “see” where a customization could be needed. We established a rough baseline specification to start the process, and moved into it designing both functionality and day to day business process, keeping in mind that the new software functionality will need to work for the team, and may change as we build it. We implemented an Agile design/build approach, working around a base spec and the needs of the team, and within 5 weeks had a working prototype.

We believe the time spent on process design/adjusting then clear documentation is a great way to align tech, vendor and internal stakeholders around any project, buy or build. The process becomes a go-to document to help with scope creep, prioritization and escalations.

SaaS Services (rental software) afford businesses lower cost system with everywhere-and-always access (mobile, etc), and scalability. While these benefits are clear, they come at a cost: one size fits all. Most SaaS systems offer customizability as the fix for this cookie-cutter approach. Customization is a cost.

This paradigm shift to SaaS has been so profound, and yet there are still gaps for specific business needs. How then does one make a decision on Buy or Build?  A few questions to ask yourself:

  • Is building this customization a part of a long term vision?
  • Have you looked closely at where your current systems are inefficient?
  • Do you have recommendations for consulting teams from trusted advisors?
  • Can customizations benefit the majority of current system users?
  • Could customizations replace manual process or duplicate effort?
  • Are you having a hard time finding “baked goods” available in the market?

These questions will help you not only make a decision of whether to buildor buy, but will also guide you in the process of building a custom system, or configuring an out-of-the-box product.

We love helping clients identify options, and make smart system design/implementation decisions. Let us know if we can help you with a technical project. 

Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn
tgroden
About the Author
Thomas writes about information systems and the transition challenges encountered when making a move to cloud computing platforms. He writes from a technical perspective for an audience of decision makers. The intention is to present practical guidance on how to embark on a conversion to a new, possibly consolidated, cloud based system.