Today is the first day after your go-live date, and your business is now running on NetSuite. Congratulations!
You sigh with relief as you close out the Implementation project, and open the new one. Some people call it Phase 1.5, some people call it the Support Window. Be it a month or a year, either way today marks the beginning of a new gauntlet of challenges, and you are telling yourself "I must be ready."
We find that even during implementation (but especially after go-live), people can can over-focus on the functionality of NetSuite and forget to treat it as the software application that it is. It is easy to become so focused on the accounting needs, access requirements, and reporting concerns of your business. When that happens, it is easy to see how one might fail to adhere to long-established industry practices that go into supporting a software product. Sure, you have your Sandbox account and you perform acceptance testing following whatever checklist and SOP was provided (hopefully) to you by your implementation team. But good software support is all about having a light touch that prioritizes not breaking anything over new feature development. And for projects which may have ran over-budget or over-duration, that may be a difficult pill to swallow.
Software Support Checklist
There are a handful of tools you should expect to use with your implementation or support team (if they are not the same) which will make living and thriving on NetSuite possible.
- Well-defined roles
Just as when you are preparing to start an implementation project, in a support cycle it is important to have defined roles and know who will be filling those roles. It is equally important that both sides of the table know each other. You should know who is supporting your software, what percentage of their work schedule they are dedicated to your project, and what their chain-of-command looks like. They should know who they can ask when they have a particular question, your availability window, and who to contact if they cannot reach you. When people join or leave the support team (on either side), it should be discussed and framed as "This is Jim, and he will be taking over as the [role XYZ]".
At minimum you want to ensure that your support team specifies the person responsible for testing adjustments to features. Typically a developer does not have sufficient accounting or process knowledge on their own to verify a change is stable and satisfactory to meet the business requirements.
- A support ticket system that is actively curated by you.
This system and the data that it contains it should be managed by one of your internal personnel (probably the person reading this article) on a daily basis.
Each task should have all the sufficient information to make the task actionable. This information should include references to the exact transaction ID, item, customer, etc. in the Sandbox account, steps to reproduce the problem if it is encountered, a reasonable status level, and an assignee.
You do not want every task to be marked as critical, and a task is likely not actionable unless it has a title matching this format:
"When [which user/role] [performs this action] [this behavior is observed], but [this is the behavior we expect]" Remember that a healthy software project is one with many tasks, milestones, and sub-projects, but has a healthy budget and burn-down (task completion) rate to match.
Old tasks with no assignee and no updates in weeks are a sign that new development is being prioritized over supporting the system you already have.
It is usually recommended to use an external project management system built specifically with software projects in mind, such as JIRA or Paymo, but not a spreadsheet. This should hopefully get you around any NetSuite user license limitations you might have, but be careful to use an actual project management system that supports sprints, assignees and notifications, task note history, etc.
- A weekly, or at least monthly check-in call with your entire support team
It is a good idea to keep open lines of communication with the boots-on-the-ground team doing the support work, not just the people who sell you licenses and modules. Your team needs to understand your business needs and how the tasks you define relate to those. It can frequently be the case that when you are asking for a series of band-aids to support your implementation, a proposed new feature by one of the team members may stop the bleeding entirely and improve your system for less capital than trying to support what currently exists.
This is also a good opportunity to discuss potential impacts from updating NetSuite releases, testing phases, revisions to business processes, etc. at a high-level.
- Process documentation, ideally in the form of a Wiki or Knowledge Base
Living documentation is a tricky thing to master, but critical for when new team resources must be on-boarded, or when new features are proposed which may have cascading impacts onto other design considerations within your system.
The best person to document a technical feature is the developer who built it. The best person to document an overall accounting process is the functional consultant. The best person to document the business requirements is you. Every feature and accounting process should be linked back to the business requirement which necessitated it; that way, when the feature or process needs adjusted, it becomes obvious what other areas of the solution it may impact.
When requirements change or new features/solutions go live, it is important to budget (in terms of time and cost) the time necessary to update the documentation.
When people come to you with questions, the easiest answer should ideally be "You can find it in the knowledge base under this term."
- Code versioning and backups (for everything)
When your implementation was started, your team should have informed you that they set up some form of a code repository outside of NetSuite. Your support team should continue to use this, and there should be talk of "bugfix branches" and "feature branches" as the software is revised and refined.
Every script, every workflow action, every Advanced HTML/PDF template, every custom record, and every point of configurable data can and should be safely backed-up outside of NetSuite using SuiteCloud Development Framework tools. Losing code under any circumstances, even a Sandbox refresh, is never acceptable.
It is perfectly reasonable to require that you be added as a viewer on the code repository so that you may see the evolution of the software that runs your business as it takes place.
Like all things in business, living with a software product is more an art than a science. This checklist will not ensure everything goes perfectly for you in the coming weeks, but we feel it is a darn good start to providing safeguards and confidence that your NetSuite environment will grow ever faster, more stable, and capable of meeting your business needs.