"Can’t We Just Build This Ourselves in Ignition?"
It is a fair question.
If your team already uses Ignition, has strong internal engineering capability, or works with an experienced systems integrator, it is reasonable to ask whether you can build MES functionality yourself.
In many cases, the answer is yes. Ignition is a strong industrial application platform. It gives teams the tools to connect to plant-floor systems, build operator interfaces, move data, write scripts, create dashboards, and integrate with business systems. Skilled Ignition teams can build a lot.
But “can we build it?” is not the most useful question.
A better question is:
What should we spend custom engineering effort on?
That distinction matters. MES projects are rarely hard because a team cannot create a screen, write a query, or connect to a PLC. They become hard because production execution has a lot of repeated patterns, edge cases, data relationships, and long-term ownership requirements. When every team starts from a blank slate, a large amount of engineering effort gets spent solving the same foundational MES problems again and again.
That is where Kanoa MES fits.
Kanoa MES is a modular Manufacturing Execution System product for Ignition. It gives manufacturers and Ignition teams a productized MES foundation that can be configured and extended through Ignition. The goal is not to replace Ignition or prevent custom development. The goal is to reduce the amount of custom MES development required so teams can focus their engineering effort where it creates the most plant-specific value.
At the beginning of a custom MES project, the first workflow may look straightforward.
You need to show an operator the current work order. You need to capture counts. You need downtime reasons. Maybe you need a quality form, a lot number, a dashboard, or an ERP update.
Each individual piece may be buildable. The complexity comes from making those pieces work together reliably over time.
A custom MES effort has to answer questions like:
These are not small details. They are the MES.
The risk is not that custom Ignition development is wrong. The risk is that teams underestimate how much foundational MES design they are taking on when they decide to build everything from scratch.
Most manufacturing environments have unique requirements. Equipment varies. Processes vary. Operators have local workflows. ERP systems differ. Quality and traceability needs can be highly specific.
But many MES concepts repeat across plants and industries.
Manufacturers commonly need production context around assets, items, work orders, schedules, shifts, modes, events, downtime, scrap, quality checks, lots, and reporting. They need operator-facing workflows that are practical on the floor. They need structured production data that supports visibility and continuous improvement. They need integrations that reflect what actually happened in production, not just what was planned.
If a team is solving those common patterns from scratch, the engineering effort can quickly move away from plant differentiation and into rebuilding MES plumbing.
A productized starting point changes that starting position.
Kanoa MES provides an MES foundation inside the Ignition environment. Kanoa Ops provides the required operational foundation for production execution, OEE, downtime tracking, scheduling, work execution, and production visibility. Kanoa Trace extends that foundation into lot and serial tracking, genealogy, routing, inventory visibility, and traceability reporting. Kanoa Quality extends it into quality workflows, electronic forms, Check Sheets, specifications, inspections, SPC, and quality records.
That does not mean every implementation is automatic. It means the team starts with productized MES structure instead of a blank page.
The best use of a productized MES foundation is not to avoid all implementation work. That is not realistic, and it is not how manufacturing software succeeds.
The better pattern is:
Configure first. Extend where needed.
Configuration should handle as much of the standard MES model and workflow setup as possible. That includes defining production context, assets, items, schedules, modes, quality checks, lot behaviors, dashboards, and other standard patterns where the product supports them.
Extension should be reserved for the areas where the plant is genuinely different. That might include a specialized operator workflow, a customer-specific report, an ERP integration, a barcode process, a data collection path, or a screen that needs to match a particular production environment.
Because Kanoa MES is built on and for Ignition, those extensions can still happen through the Ignition environment. Systems integrators and internal teams can configure, adapt, and extend the system using familiar Ignition patterns. The point is not to remove flexibility. The point is to make flexibility more productive.
A custom MES is not finished at go-live.
After go-live, production changes. New lines are added. Reports evolve. Operators give feedback. ERP workflows change. Quality requirements shift. Plants standardize across sites. Software updates need to be tested. Custom scripts, modified screens, database logic, and integrations need to be maintained.
That long-term ownership model should be part of the build-versus-starting-point decision.
When a team builds everything from scratch, it owns every design decision, every data relationship, every edge case, every upgrade path, and every future extension. That may be appropriate for highly unique or experimental requirements. It may also be the right choice when the MES scope is narrow and the team has a clear long-term support model.
But for common MES patterns, starting with a productized foundation can reduce avoidable ownership burden. The team still owns the implementation decisions that matter to its plant, but it does not have to invent every foundational MES concept before getting to the plant-specific work.
There is no single implementation model that fits every manufacturer.
Some manufacturers have internal Ignition teams that want to own and evolve their MES over time. For them, Kanoa MES can provide a productized foundation they can configure and manage inside their Ignition environment.
Some manufacturers work with systems integrators. For those teams, Kanoa MES can provide reusable MES structure that integrators can configure and extend instead of starting from a blank slate for every project.
Some teams want Kanoa-guided delivery or implementation support. In those cases, Kanoa can provide guidance and support where appropriate while keeping the software product at the center of the implementation.
The common thread is implementation ownership. Kanoa MES is designed for manufacturers and Ignition teams that want the structure of a productized MES without giving up the flexibility and ownership model of Ignition.
Building from scratch can make sense when the requirement is highly unique, experimental, or outside the scope of a productized MES pattern. It can also make sense when the team intentionally wants to own every layer of the application and has the engineering capacity to maintain it long term.
A productized starting point makes sense when the team is solving common MES problems: production execution, downtime, OEE, quality checks, traceability, lots, operator workflows, dashboards, and reporting. In those cases, the highest-value custom engineering work is usually not rebuilding the foundation. It is adapting the system to the plant, integrating with the surrounding environment, and creating the workflows that make the deployment useful in daily operations.
So yes, you may be able to build it yourself in Ignition.
The better question is whether building all of it from scratch is the best use of your engineering effort.
Kanoa MES exists for teams that want to start with a practical MES foundation for Ignition, configure what can be configured, extend where the plant requires it, and preserve custom engineering effort for the places where the operation is truly different.