Approaches compared
Two ways to
integrate systems.
This page sets out honestly how Tsumugi's approach compares with the conventional ways organisations tackle integration work — what changes, what we keep from existing practice, and what we do differently.
← Back to homeWhy comparison matters
Integration work looks similar from the outside
Most organisations considering AI integration receive proposals that promise similar things: faster processes, less manual work, connected data. The differences between approaches are less visible until the project is already underway.
The questions that matter most — who owns the system after handover, what happens when something doesn't match, how staff learn to adjust it — are often not addressed until problems arise.
This comparison isn't intended to argue that other approaches are wrong. It's intended to make the specific differences in how we work visible, so you can make a considered decision about what suits your organisation.
Side by side
Conventional approach vs Tsumugi
| Dimension | Conventional approach | Tsumugi |
|---|---|---|
| System ownership after handover | Often dependent on the integrator for changes, adjustments, or troubleshooting. Documentation may be incomplete or in technical formats staff cannot act on. | Written documentation and staff training provided before the project closes. Responsibility for each component is named explicitly. No dependency on Tsumugi for routine operation. |
| Handling of data mismatches | Often discovered late in the build phase, leading to rework or workarounds that aren't documented. Error behaviour may not be tested until production. | Addressed during the mapping phase, before build begins. Behaviour for records that don't correspond is defined and documented explicitly, including reconciliation schedules. |
| Validation against existing process | New process typically replaces old at a switch-over point. Validation is done against test data, not live operations over time. | Old and new processes run in parallel during a defined trial period. Figures are compared against live operations until results are consistent before the old process is retired. |
| Replacement of existing systems | Integration proposals often involve replacing one or more existing systems, creating retraining requirements and transition risks. | We work with the systems you already operate. No replacement is required. Connections are built between existing tools, not around them. |
| Project duration transparency | Timelines are often estimated and subject to revision based on discoveries during build. Scope changes are common. | Each service has a fixed duration defined before work begins: six, eight, or twelve weeks depending on the scope. Phases are described at the outset. |
| Rollback provision | Reverting to a prior state after system replacement can be complex and is rarely defined in advance. | A defined rollback path is included in every engagement. If the connection is later withdrawn, return to the previous state is documented and executable. |
What's distinctive
Where our approach differs in practice
The ownership panel
At handover we produce a named ownership panel — a document stating who in your organisation is responsible for each component of the system. It isn't just documentation, it's a transition of real responsibility.
Field-level mapping before build
We produce a complete field map — how data in system A corresponds to data in system B — before any connection is built. Decisions are made on paper first, not discovered in code.
Parallel running as standard
We don't switch off the existing process until the new one has proven consistent against it over live operations. The trial period is built into the timeline, not offered as an optional extra.
Defined error handling
What happens when a record doesn't match is not left to chance. We define explicitly how mismatched items are flagged, stored, and reviewed — before those situations arise in production.
Scope defined at outset
We agree what is and isn't within scope before work begins. This shapes the fixed timeline and means you are not billed for scope that changes during the project.
The integration weave
We use a static grid to map which connections will be built and which will not. This makes scope visible and prevents assumptions about what's included from building up unnoticed.
In practice
What the differences produce
Common patterns in conventional integration
Staff continue to perform manual checks alongside the new system for months after go-live, because trust in the output has not been established through validation.
When something fails or changes, the organisation cannot fix it without returning to the original integrator, creating ongoing dependency and cost.
Records that the system cannot process accumulate silently, creating data quality issues that are only discovered during reporting or audit.
Project costs exceed initial estimates when scope expands to address issues discovered during build.
What our approach is designed to address
Parallel running establishes confidence in the new process before the old one is retired. Staff see matching results across both systems before any switch is made.
Documentation and training at handover means your staff can adjust the system themselves, without needing to contact us for routine operation or small changes.
Error handling is defined during mapping. Unprocessable records are flagged explicitly on a schedule, so nothing accumulates silently.
Scope is fixed before work begins. The price and timeline do not change as a result of discoveries during build.
Investment perspective
What you're paying for, and what you keep
Transparent pricing
Fixed scope, fixed cost
Our three services are priced at ¥36,000, ¥43,000, and ¥45,000 respectively. These figures don't change based on discoveries during the project. What you agree to at the start is what you pay.
What you keep after
Full ownership of the system
Unlike engagements where the value sits with the integrator, our handover includes everything needed to operate independently: field maps, error handling rules, reconciliation schedules, and training for your team.
Long-term view
No ongoing dependency
There is no support retainer or maintenance contract at the end of a Tsumugi engagement. You own the system. If something needs to change later, your staff have the documentation to make that change, or to brief someone else.
Working together
What the engagement feels like
A typical conventional project
Discovery
Requirements are gathered. The scope document is long and technical. Assumptions are made about what systems can do without verification.
Build
Work happens largely offsite. Milestone reports arrive periodically. Questions about progress require chasing. Scope changes emerge and are priced.
Go-live
The system is switched on. A period of intensive support follows. Issues are resolved. Staff adapt as they go. Documentation is delivered eventually.
After
A support contract is offered. Changes require the original team to implement. Questions go back to the integrator.
Working with Tsumugi
Discovery
We meet with the people who operate the systems daily, not just the decision-makers. We ask about edge cases and exceptions before we write anything down.
Mapping and build
The field map is reviewed with you before build begins. You see what decisions have been made and why. Build follows the agreed map.
Parallel running
Both systems run together. You compare results. When they match consistently, we move to the handover phase together, not at our discretion.
Handover
Documentation is delivered and reviewed before the project closes. Staff are trained on what they can adjust. Responsibility is named and confirmed in writing.
Over time
What lasts after the project ends
Integration projects that create dependency on the original supplier are, in a sense, never finished. The organisation continues to pay — in support contracts, change requests, and the cost of waiting when something breaks.
Our approach is designed so that what we build becomes genuinely yours. The documentation is in plain language your operations staff can act on. The training covers not just how to use the system but how to adjust it when your process changes.
The measure we apply internally is simple: after six months, should a client need to contact us about a system we built, that's a sign the handover was incomplete.
Plain-language documentation
Written for the people who will operate the system, not for the people who built it.
Named responsibility at handover
Each component has a named owner in your organisation before we leave.
Defined rollback path
If the connection is ever withdrawn, the path back to the previous state is documented and executable without our involvement.
Common questions
A few things worth clarifying
"AI integration means replacing our current system"
This is not how we approach integration. We build connections between systems you already use. Your existing tools stay in place. The investment is in the path between them, not in new platforms your team needs to learn from scratch.
"We're too small for this kind of work"
Our clients are typically small and medium-sized organisations in Kansai. The services are scoped for that context. A manufacturing company with forty staff operating one production line is exactly the kind of client we work with.
"Once the project ends we'll be dependent on the integrator"
This concern is worth taking seriously — it describes what often happens with integration work. Our answer is structural: we do not offer support retainers. Handover documentation and staff training are part of every engagement precisely so that ongoing dependency is not necessary.
"AI checking will remove our quality inspectors"
Our Quality Inspection Support service is implemented alongside your existing inspection process, not as a replacement for it. During the trial period, manual inspection continues in full. The image-based layer is an addition, not a substitution. Decisions about staffing remain with you.
In summary
Reasons organisations work with Tsumugi
They want to connect existing systems without replacing them or retraining staff on new platforms.
They want to know the cost before the project starts and not receive revised estimates mid-way through.
They want staff who can operate the system independently after handover — not a support contract.
They want confidence from parallel validation — seeing the new and old systems match before committing to the change.
They want to understand what happens when the system encounters a record it can't process — not discover it later.
They want a defined timeline and a rollback path if circumstances change after the work is done.
Next step
Ready to talk through your situation?
If what you've read here matches what you're looking for, we'd welcome a direct conversation about your systems and where the friction is. No obligation on either side.