On Monday morning, an engineer could begin extracting the reports needed for an assembly forecast. The data would then move from one person to another through SAP extraction, Excel processing, consolidation, and dashboard preparation. The final result might not be ready until Friday afternoon.
In 2016, I helped replace that chain of manual work and handoffs with an on-demand reporting system for an aerospace assembly operation in Brazil. An operator selected a few options, started the process, and could leave it running. About 30 minutes later, the dashboards and Excel exports were ready.
The project did more than execute the same steps faster. It moved stable configuration and procedural knowledge into software, removed routine coordination from the normal path, and gave failures a clear notification and recovery process.
Valuable automation does not merely accelerate a task. It turns a fragile sequence of people, tools, and waiting into an operable workflow.
The delay was spread across the workflow
The reports supported production and assembly planning. Engineers used them to forecast raw materials, components and consumables, tools, and staffing. They could compare requirements with previous weeks and keep track of budget and material availability.
Producing those views required data from several SAP reports. Engineers extracted the information and worked with it in Excel to assemble dashboards, graphs, and diagrams. One person completed a stage, passed the result forward, and the next person continued from there.
Monday
│
▼
SAP reports ─▶ handoff ─▶ Excel work
│
▼
handoff ─▶ consolidate
│
▼
dashboard + Excel export
Friday
The working week belonged to the workflow as a whole, not to one isolated calculation. The delay accumulated across the path: repeated extraction, manual preparation, dependencies between stages, and the time each result spent waiting for the next person.
That distinction changes how an automation opportunity should be evaluated. Measuring one task may reveal how long someone spends manipulating a spreadsheet. Mapping the complete workflow reveals how long the business waits for an answer.
The useful boundary was therefore not “automate this report.” It was the entire interval between requesting a forecast and receiving dashboards and exports that engineers could use.
We had to design around the interface available
The cleanest integration was not available to the team. We did not have licensed SAP API access for this workflow, so the practical boundary was the desktop interface already used by the engineers.
SAP GUI provided a recorder that captured a user’s actions as a VBS script. SAP still describes GUI Scripting as an interface for recording and replaying user interaction. A recording, however, reproduced only one particular sequence with the values used at that moment. It was a starting point, not a reusable automation system. See the SAP GUI Scripting overview.
We converted the recorded scripts into templates. Java supplied the values required for each run and orchestrated their execution. The extracted data was stored in MySQL, where it could support the views and exports expected by the production team.
A PHP and CodeIgniter application provided the operator interface. The stack reflected the system we could build in that environment, but the more durable design decision was the separation of responsibilities:
- recorded scripts handled interaction with SAP;
- templates separated repeatable procedure from changing values;
- the backend coordinated execution and persistence;
- the web application owned configuration and operator input; and
- dashboards and exports presented the result.
Working around a constraint is not the same as ignoring architecture. The unavailable API made the integration boundary less ideal, which made it more important to isolate that boundary from the rest of the workflow.
The operator experience was part of the automation
A script can automate clicks and still leave the overall process difficult to operate. The application had to reduce what a person needed to remember before starting a run.
Most settings were stored in the system. The operator only needed to choose a few options relevant to the forecast, start the process, and wait for completion. The workflow ran unattended for about 30 minutes—long enough to have a coffee, short enough to receive the result in the same working session.
operator selects options
│
▼
automated run ──▶ stored data ──▶ dashboard
~30 min └─▶ Excel export
│
└── failure ──▶ notification ──▶ investigation
The system provided dashboards in the web interface and retained Excel export. Preserving Excel was a practical choice. Automation should remove work that does not need human attention without taking away an output that remains useful for analysis, sharing, or another established process.
The workflow was also available on demand rather than tied to one weekly execution. Multiple operators could use it across different assembly-planning contexts. The system captured the common process while allowing each run to supply its own inputs.
This is one of the most important differences between a helpful internal tool and a technical demonstration. The operator should interact with the business choices, not the implementation mechanism.
Unattended execution still needs ownership
The SAP interface remained the most fragile boundary. The failures we encountered were usually caused by a form or interface change that stopped a recorded script from matching the expected interaction.
Failures triggered notifications to developers and engineers. They investigated the problem together, recorded the affected SAP steps again, and updated the corresponding templates. The normal path no longer required a chain of people, but the exception path still brought the right people back into the workflow.
That is a healthier definition of unattended automation. It does not mean that nobody owns the process. It means the system performs the repeatable path and asks for human judgment when reality no longer matches its assumptions.
Interface automation carries a maintenance cost because it is coupled to visible application behavior. A stable, supported API will usually be a better boundary when it is available and appropriate. When it is not, GUI automation can still create substantial value if changes are detectable, failures leave useful evidence, and responsibility for repair is clear.
Security belongs to that ownership model as well. SAP’s scripting security guidance explains that scripts operate with the permissions of the user who launches them and can execute interactions rapidly and without continuous supervision. A current implementation should therefore use controlled access, appropriate permissions, trusted scripts, and deliberate handling of credentials. See the SAP GUI Scripting Security Guide.
What made the project valuable
The visible outcome was dramatic: a reporting cycle that crossed an entire working week became an on-demand process completed in about 30 minutes. Four underlying changes made that outcome possible.
Procedure became configuration
The repeated knowledge needed to operate the workflow moved out of individual actions and into templates, stored settings, and orchestration. Operators supplied only the choices that genuinely changed between runs.
Handoffs moved out of the normal path
People no longer had to pass every successful run through the same sequence of stages. Human collaboration remained available for exceptions, where investigation and judgment were actually useful.
Existing outputs remained available
The project added web dashboards without discarding Excel exports. Users gained a faster path without being forced to abandon every surrounding practice at once.
Failure became an explicit workflow
An interface change could still break the automation, but failure was not treated as an unexpected end state. Notifications and a known update process connected the technical fault to the people able to resolve it.
Together, these changes turned automation from a collection of scripts into an internal system people could operate and maintain.
A practical framework for evaluating workflow automation
When I evaluate a repetitive business process, I now look beyond the most visible manual task. Five questions reveal whether automation can improve the complete workflow.
1. What decision is waiting for the result?
Name the useful output and who needs it. A report is not valuable because it exists; it is valuable because someone can use it to plan, approve, reconcile, schedule, or respond.
2. Where does the time accumulate?
Trace the path from request to usable result. Include manual work, queues, handoffs, repeated setup, rework, and exceptions. The best automation target may be the coordination between tasks rather than the longest individual task.
3. What knowledge is stable, and what changes per run?
Stable settings and repeatable procedures belong in configuration and code. The interface should ask the operator only for information that requires a current business choice.
4. Which constraints shape the viable solution?
APIs, permissions, licensing, data access, platform limitations, and ownership all affect the design. A good solution makes those constraints explicit, isolates their effects, and avoids spreading a fragile integration across the whole system.
5. What happens when an assumption breaks?
Define how the system detects failure, what evidence it retains, who receives the notification, and how the workflow returns to a working state. Recovery should be designed alongside successful execution.
These questions keep the project focused on operational value. They also make it easier to reject automation that looks interesting technically but merely relocates effort or creates an unsupported dependency.
The best automation changes the normal path
The VBS-based integration belongs to the project’s 2016 context; it is not a prescription for building the same system today. SAP’s current documentation recommends JScript rather than VBScript for new recordings because of Microsoft’s VBScript deprecation. See SAP GUI Script Recording and Playback.
The more durable lesson is about the shape of the work. A chain that depended on repeated actions and serial handoffs became a system that stored its configuration, accepted a small set of inputs, ran on demand, produced familiar outputs, and escalated exceptions.
That is what valuable automation changes. It does not remove people from the system. It removes people from the parts that no longer need their attention and makes their involvement more useful when judgment is required.
If a workflow is consuming days, map the complete path before choosing a technology. The most valuable improvement may be waiting between the steps rather than any one step itself.