NetSuite Implementation Failures

NetSuite Implementations: Why Do So Many “Fail”?

If you were – or are – a part of your company’s NetSuite implementation, then you know the struggles that come with it. It was a process that started so long ago, and now it’s over-budget, over-time, and over-your-limits-of-patience. Maybe you’ve already gone live, but it feels like so much was left uncompleted, half-completed, or implemented incorrectly. I have been in your shoes. In fact, I make a living at it.

 

The Truth About NetSuite Implementations

 

Most of my work is post-implementation. I don’t like the sales part of the gig, so I don’t focus on selling new systems to companies. Trying to compete with bigger firms for implementations just seems like a rat race, so I don’t focus my energies there either. Instead, I constantly find clients that are mid-implementation and frustrated with how the process is going, or they are already live with NetSuite but unhappy with the results. Some are even years down the road and still feel like it is not a fully functioning system.

 

So what goes wrong?

 

Mainly, it’s just a communication issue. While interviewing with a company recently, I was asked why I think implementations fail. My answer was communication. The users have a hard time communicating their exact needs to the solution provider. The solution provider has a difficult time interpreting that into something NetSuite can actually offer and communicating back their options. Users know what they have in their current system, but don’t know what they really need from NetSuite. Solution providers know what NetSuite can offer, but don’t know how that compares or translates to a user’s old system.

 

Plainly speaking: users struggle to really identify what they want out of NetSuite, and solution providers often don’t do a good enough job explaining what NetSuite can and can’t do.

 

The main miscommunication surrounds one thing: expectations. Users expect NetSuite to be like their old system, only better. Solution providers don’t communicate the reality that NetSuite may be better than their old system, but it will be different. When expectations are not met, the project goes off the rails.

 

Understanding Where the Process Fails

 

You sat through a demonstration of everything NetSuite offers, and it looks like rainbows and glitter compared to your current system from 1994. As great as that is, it will have its own strengths and weaknesses, just like your old system did. You’re excited about all of the new features that you will get out of NetSuite. What often gets missed – at least in the beginning – is everything NetSuite can’t do that your old system did.

 

As soon as you realize what NetSuite can’t do, you go back to the implementation team with a list of customizations and fixes that need to be made. You want NetSuite to do everything your old system could do so that you don’t have to change internal processes. The costs go up, the deadline gets pushed back, and a flurry of new projects are started. OK, great, you’ll get what you wanted, even if there was a cost. Well… not exactly.

 

The problem is that too much scripting and customizations just bog down the system and lead to endless errors. Yes, I write code for a living. But no, I don’t believe everything needs a script or workflow. I just came off a project that was so overly-customized that pages loaded incredibly slow, there was an infinite number of errors and bugs, and they just couldn’t get their system to work right. Honestly, the only way to fix that mess is to burn it to the ground and start fresh. Only joking, but DON’T LET THAT HAPPEN TO YOU!

 

Accepting Reality

 

If you were to change jobs, you have to learn the new processes at your new company. You can’t tell your new boss, “Well, I used to do my job this way at my old job.” It doesn’t matter. You have to learn how your new company functions and learn how to do your job in line with that. It’s not what you’re used to, but we do it every time we change jobs because we expect for that to happen.

 

The same is true when switching over to NetSuite. Your old system is what defined most of your current processes. Well, that system has changed (by your company’s choice), and you have to adapt your processes to go with the way NetSuite functions. You can wallow in the misery of missing the way your old system functioned or learn how to do the same thing a slightly different way in NetSuite.

 

I’m not saying that you can’t make some changes to NetSuite to make it better match your old processes, but simply stating that you need to be flexible. Solution providers can use NetSuite’s flexibility to work with you, but you also need to be flexible enough to work within NetSuite’s limitations. Meet NetSuite in the middle, and you’ll be a lot happier in the long run.

 

What Should Customizations Be Used For?

 

In my opinion, customizations should improve the performance of NetSuite, not slow it down. If you have 25 scripts running on your sales order every time it saves, something is wrong. I have seen systems where it would take minutes for a record to save. Editing a single field would kick off a host of scripts all fighting with each other and throwing numerous errors. Changing the values for one field could be catastrophic for some scripts. With all of those “optimizations”, is your system really optimized?

 

At implementation, don’t try to solve every problem. You often won’t know what needs to be automated until you are living and working in the system for some time. Make the system functional at go-live, and go from there. Once you realize what works and what doesn’t, address those needs from there. Trust me, I’ve removed a lot of pre-implementation scripts that simply were not needed or did not function the way they were intended. Sometimes, they become so integral that they can’t be removed, and you end up with a lot of unneeded baggage in your system.

 

What About Data?

 

Data is another implementation headache. Someday, I’ll write a whole post about bringing data in pre or post-implementation and what works/doesn’t work. For now, I’ll relate it back to the original concept: a miscommunication about migrating data often causes implementations to go off the rails, and the main reason is that expectations are not clearly communicated between the two parties.

 

As a former admin and user, I understand that you want all of your data from your old system in NetSuite. Everything should match up perfectly, right? As a consultant who has tried to do this, I can tell you that it’s like fitting a square peg into a round hole. The two systems have completely different footprints. Before anything can be done, a lot of work has to go into making the pegs as close to the same shape as possible. Often times, though, you end up with a square peg with rounded off corners, and it gets wedged into that round hole as best as possible.

 

The other tough part about data migration is the link between all of the records. For instance, transactions are linked by NetSuite from the original quote to the time you collect a payment from the customer. Importing them in separately, quotes, sales orders, fulfillments, invoices, and so on, does not create that link on its own. The system is simply not smart enough to do that. It can be done, to some degree, but not without a mountain of effort and struggle. More times than not, this pushes projects further and further off budget and timeline.

 

What’s the solution to this? There are ways to, again, meet NetSuite in the middle. You can bring in the data you need (for financials, reporting, etc.) without having every binary bit from your old system. Again, it’s about compromise. You have to meet NetSuite in the middle. Solution providers need to stop promising the world and sharing the reality from the start, as well.

 

Where Do You Go From Here?

 

As bleak as this all has been, it’s not the end of the world. Your system can be cleaned up, tuned up, and made to perform a lot better than it may be currently. If you’re still in the middle of your implementation, you can re-evaluate priorities with your solution provider or look for some more outside help. Don’t give up yet.

 

 

This is my specialty – coming in after implementation. The relationship you had with your solution provider has gone sour. The consultant you were working with has moved onto the next project. You’re being passed from one support person to another – and none of them understand the state of disaster your system is in.

 

Work with me, one on one, and we will start to get the ship sailing in the right direction again. Most of my clients spend anywhere from 3-9 months with me – working ad hoc, no commitments – to address all of these issues. From data clean up to optimizing performance, I can get it done. And for those larger projects left uncompleted, I do have some resources that I bring in to help get that done.

 

If you’re unhappy with NetSuite, don’t give up yet. Give me a call, and let’s see if we can get this figured out.

 

user-gravatar
Chad Torgerson

Chad Torgerson is the wizard behind the curtain at SMB Ally. He is a husband, father to 4 kids, an Iraq War veteran, and a nerd that is well-versed in a number of technologies (primarily NetSuite).

No Comments

Sorry, the comment form is closed at this time.