Following the work

The director of an industrial maintenance company asked me to reduce the time spent preparing client reports. Two coordinators were gathering technicians’ notes, photographs and parts requirements, then entering information into spreadsheets.

The report was the visible task. Before deciding what to automate, I needed to understand how its information reached the coordinators. I started following the work backwards, from the finished report to the maintenance visit and the records used to prepare it.

Before there was a report#

I spoke with the director, the two coordinators, IT and two technicians. I reviewed report templates, documents and spreadsheet copies, then checked my understanding with staff. I reconstructed the process from those accounts; I did not accompany a team on a maintenance visit.

Work began with either scheduled maintenance or a client calling about a problem. Every morning, coordinators checked schedules across the client list and assigned teams of two to five technicians.

Before each visit, they retrieved client and equipment records and printed machine-specific checklists. Technicians returned with notes, photographs and parts requirements. Only then could coordinators assemble the report.

By the time a coordinator began writing, the information had already passed through several hands. Preparing the report depended on bringing those pieces back together and connecting them to the right client and machines.

Where the information came apart#

The company kept client and equipment records in its ERP, the existing business management software. A previous mobile application had failed to stay in sync with it. New clients still had to be added manually to separate spreadsheets when coordinators discovered they were missing.

Staff reported equipment assigned to the wrong client in reports and mistyped part numbers. They also described how poor photographs and tiring, repetitive data entry led coordinators to mistype equipment serial numbers.

When replacement parts were needed, a mistyped serial number could point to a different machine or match no equipment at all. Technicians had to return to the client’s site to get the correct number. Sometimes the wrong part had already been ordered and had to be returned, delaying completion of the job for many days.

The staff accounts changed how I understood the request. Automating report assembly could bring the material together faster, but coordinators would still be working with incorrect numbers and unusable photographs.

I needed to understand where information entered the process and how it stayed connected to the right machine. That led me back to the company’s existing records.

The records were already there#

The ERP held the client and equipment information the workflow needed, but it had no API: no defined way for another application to retrieve that information. IT supplied a database copy with non-sensitive data for my prototype so I could investigate the structure.

Client details could be missing from client records yet appear in machine records, and values could disagree. Retrieving a record would solve only part of the problem. To prepare a job or order a part, staff needed reliable information about the client and machine involved. Access to the database would not, by itself, resolve those inconsistencies.

The ERP depended heavily on that structure. Rebuilding it would substantially widen the project. Any application I proposed would have to account for those inconsistencies while working alongside the system the company already used.

A clearer problem to solve#

The investigation gave me three requirements for the proposal:

• Access to existing records, so staff could use the client and equipment information they already maintained without recreating it in separate spreadsheets.

• A connected job record, keeping the client, machines, checklists, photographs and parts requirements together as work moved between people.

• Review at the right points, so coordinators could check completed work and the report before it reached the client.

The coordinators’ decisions remained part of that workflow. Team availability and contract coverage still had to be checked before accepting a client request. Automating preparation and assembly needed to support those responsibilities.

What came next#

Building that workflow meant working with an ERP that had no API and records that could disagree. In the follow-up, I’ll explain how I connected those records to the maintenance application and carried a job through to a reviewed report, then what I had to revise when technicians began using it.