Answer
On IBM i, this typically means orchestrating work that spans the job scheduler, the IFS, EDI transactions with trading partners, and calls out to external APIs or cloud services, all of which used to be stitched together with CL programs, cron-like job scheduling, and an admin's personal notes about what order things had to run in. A mature automation platform tracks dependencies between steps, so if an inbound file does not arrive on time, the downstream job does not fire against incomplete data, and someone gets alerted instead of finding out the next morning that a report ran against yesterday's numbers.
What separates real automation software from a slightly nicer job scheduler is how it behaves when something goes wrong. A basic scheduler starts jobs at the right time and stops there; automation software understands that a failed step might need a retry, an escalation to a person, a rollback, or a substitute path, and it keeps a record of exactly what happened for later review. Buyers evaluating this category should ask less about how many jobs the tool can schedule and more about how it behaves during a bad night: a file arrives late, an API times out, or a step fails halfway through a multi-system process. That behavior is the actual product.