Quick question for the leaders and consultants here: When you've put your reputation on the line to lead a major NetSuite implementation, what was the one non-technical risk that worried you the most? I'm less interested in API limits and custom script performance, and more in the 'people and process' disconnects that can quietly sabotage a project's business case. Your feedback is greatly appreciated!

People management and overall change management. You have a couple people who aren't bought in and/or were actively against getting NetSuite or just changing ERPs in general, you're gonna have a bad time if you can't get them bought in or at least get along with them enough to stop them from trying to sabotage the whole thing. And just change management in general in hard. Until proven otherwise, you need to assume that people are not going to understand things and/or are going to have difficulties using the system. If that's not the case, great! But you unfortunately have to start off assuming the worst and then if that's not the case, then things can go more smoothly. Last but not least, finding an "internal champion" helps a lot. It may or may not be the person who ultimately made the decision to go with NS, but if there's someone internally who people already trust championing the system, it makes your life a lot easier.

@RJMNS That's a great point! It seems like the 'people problem' is the ultimate make-or-break factor. The idea of an internal champion is critical. It makes me wonder: how much of that user resistance and 'buy-in' trouble is a direct result of a disconnect during the initial design phase? For example, have you seen situations where users resist because the final product doesn't actually match the reality of how they work, due to a misunderstanding between the business team and the implementers early on?

my 2 cents is almost similar to @RJMNS - ERP Implementation for me is less about the ERP/ new system. It is more about: 1. Right Business processes 2. Discipline (in processes and using the system) 3. Change management (and getting everyone on board)

@Kman You've hit on three pillars that determine success or failure. It makes me wonder about the 'Right Business Processes' point. In your experience, where does the breakdown most often happen that leads to the wrong processes being built in the first place? Is it a failure of discipline, or does it start earlier—with a fundamental misunderstanding between the business experts who know their processes and the technical team who know the new system?

how much of that user resistance and 'buy-in' trouble is a direct result of a disconnect during the initial design phase

Well in the specific case I was thinking of, the user in question was the internal expert on their old system (Quickbooks) and didn't want to change systems at all. The switch to NS was pushed through over this person's objections; they thought the company didn't need it. So we started off in a deficit with them. I think they were ultimately concerned they'd lose their "importance" if they were no longer the company expert on the accounting system. We positioned them the main super user, so they could see they could still be important. Once they realized they could still be the expert, just on the new system, they were much more receptive and easier to work with.

have you seen situations where users resist because the final product doesn't actually match the reality of how they work, due to a misunderstanding between the business team and the implementers early on?

If you get to be in this position, you failed as an implementer. You shouldn't be taking the initial requirements, going off and building the system based on that, and then coming back with the final product with little to no user input. There are bound to be misunderstandings between the business team and implementers. You just need to involve the business team from the start so you can catch those kinds of things long before go-live. If within the first couple days of go-live, users come back with major issues, you obviously had a major communication problem somewhere. It could be that users blew off UAT and other forms of testing and just passed things without really testing it, but if you're not close enough at that point with the users to be able to pick out that they're half-assing, that's another failure.

@RJMNS That's a fantastic breakdown! The line, 'There are bound to be misunderstandings between the business team and implementers,' is the core of the issue. It sounds like the only defense is constant vigilance from a really experienced implementer who can catch these things. My question is: in a complex project with multiple stakeholders, workstreams, and a firehose of daily communication, how often do these 'minor' misunderstandings still slip through the cracks, even with a good process, and only become apparent after it's too late?

IMHO - 1. the issue is most business users, don’t understand systems design and processes. They only know how things currently work. They want to replicate that exact thing in the new ERP. Most ERP systems - the process design is clean and should work. It’s when a company decides they want to do something that isn’t standard, they then say - oh the system can’t do it. Let’s reprogram it. The major processes - Procure to pay, order to cash, Make to stock, record to report etc - should work just fine. 2. The systems experts (tech guys configuring the ERP) don’t understand business operations and can’t figure out how to configure it right and help the business users get the same output/results they need by following the standard process. They either fail to understand what is needed, or configure it right. Then when the implementation is done, nothing works right and everyone is pissed. Sadly, I’m an engineer, who worked in business operations all my career. I love systems and volunteered to work on ERP projects and systems projects for fun - because I was mad that I couldn’t get the data and reporting I needed or the config wasn’t done right. ERP implementations fail because the key business users don’t understand systems and technology, and they get put in charge of implementation from the business side. Go figure!

@Kman Kman, thank you. That is the most insightful and brutally honest summary of the core problem I have heard. You've perfectly articulated the two-sided failure. It's a classic 'lost in translation' problem, but with million-dollar consequences. Final question for you, given your unique perspective: How valuable would a 'neutral translator' be in this process? Imagine a tool that could analyze the business team's stated processes and automatically flag where they conflict with NetSuite's standard best practices, forcing a conversation on the right way to configure it before a single line of code is written. Is that a 'nice-to-have,' or would that fundamentally change the odds of success?

Can I ask, how much of the risk is data migration? I’ve heard stories about projects getting hit with delays ranging from a few months to half a year when the data migration from the old ERP goes haywire.

@Marc T not sure I am qualified to answer that question. At the end of the day, the user has to input what the current process is. And what are the “exceptions “ to it. I don’t know how much a tool can help there. @Stony Grunow I only do current year/ last year. That too is only importing trial balances to build P&L and BS. Nothing else. The lesser you do the faster it goes. I’ve had to build templates to convert Trial balance files from previous months to be able to import into NetSuite format with the new COA. And then you need to do it first in Sandbox, validate and then in Production- adds a lot of work. I just start with a - we aren’t importing history. Then i settle for current year/ last year.

@Kman and @RJMNS - I want to sincerely thank you both. This has been an incredibly insightful discussion and has given me a much deeper understanding of the real-world challenges. I'll step back now and digest all of this. I appreciate you sharing your expertise so generously.