“Integrate these two systems” sounds like a technical request. In a factory, it is also a question about people, timing, exceptions, and responsibility. What information needs to move? Who relies on it? What happens when it arrives late—or not at all?
Business analysis is a useful starting point for integration work because it helps make those questions visible before implementation details take over.
Follow the information through the process
Begin with the operational event: a new order, a completed production step, a label request, or a device update. Trace where the information originates, how it is transformed, and who or what depends on it next. The map should include the ordinary path and the exception paths.
This often reveals that two systems use similar words to mean different things, or that a manual handoff is doing important validation which no one has documented.
Reliability is a workflow concern
Retries, duplicate messages, delayed updates, and partial failures are not edge cases when a process depends on continuous operations. The integration should define how it detects these conditions, how a person can see what is happening, and how the work can be recovered.
That is as much about operational clarity as it is about protocols. A technically successful connection is not useful if people cannot understand its status or safely resolve a problem.
Connect systems around outcomes
The goal is not to connect every system to every other system. It is to give the right people and processes the right information at the right time, with enough traceability to know where it came from.
The better the shared understanding of the work, the easier it is to choose a sensible integration pattern—and to know whether the result actually improved the process.