NetSuite is deployed. Why are operations still in chaos?

There's a moment that almost every team experiences between the third and sixth month after deploying NetSuite.

The ERP is working. The data is centralized. The promise of visibility and control that motivated the implementation is being fulfilled, at least in part. But the equipment is still in reactive mode. Requests come in through Slack, email, and hallway conversations. No one knows clearly what is urgent and what to expect. Managers spend more time managing chaos than working on what matters.

This pattern has a name in the community of professionals who work with NetSuite: the post-go-live valley. And it has a specific cause that ERP, by design, cannot solve alone.

The moment that no one tells you before the go-live

The implementation of an ERP such as NetSuite is evaluated by its ability to centralize operations, automate core processes and provide financial visibility in real time. At that, NetSuite is extraordinarily good.

What is not evaluated before go-live is what happens in the layer between the ERP and the daily work of the teams.

This layer includes things such as: how change requests are entered and prioritized, how support work is managed versus improvement work, how resources are allocated between ongoing projects, how status is reported to management clearly and without manually preparing a report each week.

Before go-live, that layer existed informally—emails, spreadsheets, meetings. After go-live, with more volume and more dependence on the system, that informality becomes a visible problem.

ERP doesn't solve it because it's not designed for that. NetSuite manages transactions, records and core processes. It does not manage the operational workflow of the team that maintains it and makes it evolve.

Why ERP doesn't solve the operational layer

NetSuite centralizes business information — finances, inventory, customers, suppliers — and automates the processes that revolve around that information. It is its purpose and it does it well.

But between ERP and the actual operation of the teams, there is a layer that no ERP covers natively. It is the layer where processes that are not transactional but that sustain the operation of the business live: coordination between teams, management of internal requests, monitoring of improvement projects, visibility over the state of operations in real time.

This layer has specific characteristics that differentiate it from what the ERP manages:

It's not transactional. The ERP manages well what has a clear structure — an invoice, an order, an inventory record. The operational layer manages work in progress, changing priorities, and coordination between people with different roles.

It's dynamic. Operational processes change with the business. What worked for ten people doesn't work for fifty. What a centralized team solved doesn't work when external contractors are involved.

It requires different visibility. The CFO needs to see financial metrics. The Director of Operations needs to see the status of ongoing processes. The team leader needs to see each person's workload. ERP is designed for the former, not the other two.

When that layer is not resolved, the team operates with informal tools — email, Slack, spreadsheets — that don't scale and that generate exactly the chaos that the ERP should have eliminated.

The three types of work that NetSuite doesn't distinguish alone

One of the most common problems in post-implementation teams is that all incoming work is treated the same way, even if it has completely different natures.

There are three types of work that need to be managed differently for the team to work without friction:

Corrective work — incidents and break/fix. They are interruptions. Something has stopped working and needs immediate attention. This work doesn't go into sprints or planning — it goes into a priority queue and is serviced as quickly as possible. Its metric is resolution time.

Evolutionary work — improvements and changes. These are requests for change or improvement that have a significant impact but are not urgent. They need backlogging, prioritization, and planning. They enter into sprints or structured work cycles. Its metric is throughput and alignment with business priorities.

Project work. These are initiatives with a defined scope, time frame and resource allocation. They need scheduling, dependency management and reporting to management. Its metric is progress against the plan.

When these three types of work live in the same queue — as is usually the case in the months after go-live — everything feels urgent, nothing gets the focus it needs, and the equipment is constantly operating in reactive mode.

The solution doesn't start with the tool. Start by defining how work is classified and prioritized before choosing which system will manage it.

What happens when everything lives in the same queue

The most visible effect is what teams describe as “putting out fires all the time”. But behind that feeling there are concrete operational consequences that have a real impact on the business.

Strategic improvements are not moving forward

‍When incidents and urgent requests compete for the same resources as improvement projects, the latter always lose. The result is an ERP that never evolves beyond the initial configuration, even though the business has changed significantly.

Resource allocation is invisible

‍Without structure, no one knows exactly what each person is doing, what capacity is available for new initiatives, or where the bottlenecks are. Resource management becomes an intuition rather than an informed decision.

Reporting to the direction is done manually

‍If there is no system that captures the status of the operational work in a structured way, someone has to prepare that report every week by extracting information from various sources. It's time spent consolidating data rather than analyzing and deciding.

Dependency on key people is growing

‍When operational processes are not systematized, knowledge about what is happening and why lives in the minds of people who have been around the longest. If that person leaves or is not available, the equipment loses its ability to operate.

How to resolve the layer that NetSuite doesn't cover

The solution to this problem is not to add more generic tools. It is designing the operational layer with the same attention with which the implementation of the ERP was designed.

That involves three specific things.

First, separate workflows by type

‍Incidents, improvements and projects need different lanes with different entry rules, prioritization and metrics. Before choosing tools, it is necessary to agree at the leadership level how work will be classified and prioritized. Without that alignment, any tool that is implanted will generate more friction than clarity.

Second, build the visibility layer that the team needs

‍The Director of Operations needs to see the status of ongoing processes. The team leader needs to see the workload and dependencies. Management needs to see progress against objectives. These three views are different and need to be explicitly designed — they don't arise on their own from implementing a tool.

Third, integrate that layer with NetSuite

‍Real power comes when the operational layer and the ERP share data. An improvement project in Airtable or in n8n that is automatically updated when a record in NetSuite changes. A change request that generates a ticket in the operating system when created in the ERP. A management dashboard that combines NetSuite financial metrics with operational metrics from team processes. These integrations reduce manual work and provide real visibility without relying on someone to consolidate information by hand.

When you need to build something to measure

Not all operational layer problems are solved with generic tools such as Jira, Monday or Linear. There are situations where the right solution is to build something specific to the context of the organization.

It makes sense to build something tailor-made when the process logic is business-specific and doesn't fit into the predefined flows of standard tools. When the integration with NetSuite needs to be bidirectional and in real time, not periodic synchronization. When the profiles that are going to use the tool are very different from each other — operations, finance, IT, management — and each one needs a different view of the same process. Or when the volume and complexity of the work make maintaining a generic tool as much effort as maintaining the original problem.

In these cases, building the operational layer with NoCode and LowCode tools — integrated with NetSuite through its API — can be the fastest, most flexible and most economical solution than any traditional development alternative or standard software deployment.

The result is a system that works exactly as the organization needs it, integrates with what it already has in place and can evolve when the business changes - without depending on an external supplier for each modification.

Is your team in the NetSuite post-go-live valley? At Yellow Glasses, we design and build the operational layer that ERP doesn't cover: internal tools, automations and custom integrations, integrated with NetSuite, in weeks. Tell us about your case.

References

1. Methodological note: The pattern described as a “post-go-live valley” between month 3 and month 6 after the implementation of an ERP is consistent with the experience documented in communities of NetSuite professionals and with the change management benchmarks in ERP system implementations published by Gartner and Panorama Consulting. There is no single primary study with that specific temporal segmentation; it is presented as an indicative reference derived from the observation of consistent patterns in comparable projects.
2. Oracle NetSuite. (2024). NetSuite ERP documentation and API reference. https://www.netsuite.com
3. Panorama Consulting Group. (2024). 2024 ERP Report: Implementation challenges and post-go-live performance. Panorama Consulting. https://www.panorama-consulting.com/resource-center/erp-report/
4. Gartner. (2024). How to Build a Productive IT-Business Relationship Post-ERP Implementation. Gartner Research.