Was this a Beabstracto engagement?

No. The work was done while Thiago Andrade was part of the industrial engineering department at Siemens as an application engineer in permanent employment. What Beabstracto takes from it is the way of working: as-is analysis at the workplace, core problems validated with users, functional concept, prototype in the existing tools, and a rollout the key users carry.

Can Beabstracto repeat this for our SAP or MES processes?

The approach yes, the code no; that belongs to the former employer. We map the workflow in production planning, production control or maintenance, find the places where engineers lose days, develop the functional concept with the key users and test a prototype with real bills of materials before development or customising starts. We do not replace SAP consultants; we make sure that what they build gets used.

Where does the 80 % figure come from?

From the project records: before the rollout, documentation took one to two days per bill of materials, afterwards hours, in simple cases minutes. The quantities per turbine are approximations from the as-is analysis. Where no measurement exists, we do not quote a number.

Do we need a new system for this?

In this case, no. The solution ran in Excel and SAP, tools the engineers already used daily and IT had already approved. Whether that is enough for you or a Fiori, MES or web front end is needed is something we settle in the as-is analysis, not before.

Do the screens show the original software?

The screens come from the portfolio case and show the solution with fictitious data; names, project numbers and KPIs are placeholders. Internal Siemens data, drawings or process content are not published.

Which role and which keywords fit for recruiters?

Back then application engineer in industrial engineering, today UX designer and business analyst with a UX focus for specialist systems in industry. Relevant terms from this case: SAP, routing, bill of materials, production planning, shop floor, process mapping, as-is analysis, functional concept, prototype, key user, Excel/VBA, SAP scripting.

Industry · SAP · 2016–2021

Manufacturing processes for steam turbines: from one to two days per bill of materials to hours.

Five industrial engineers in a Siemens steam-turbine factory created their manufacturing processes in SAP from printed bills of materials, highlighter pens and copied legacy texts. Thiago Andrade, then an application engineer in permanent employment, worked the process on the shop floor for months, validated the core problems with the team and built a solution from Excel automation, a template library and an SAP link. According to the project records, lead time fell by 80 %.

Book an initial call How we went about it

Mobile view of the solution with a “Search fabrication process” field and a list of processes with status indicators; content blurred, data fictitious

Client: Siemens (employer, permanent position)
Industry: Power generation · steam-turbine manufacturing
Role: Application engineer in the industrial engineering department: as-is analysis, functional concept, prototype, implementation
Period: 2016–2021 (employment)
Systems: SAP (manufacturing processes/routings), Excel with VBA macros, SAP scripting, AutoCAD
Team: 5 industrial engineers as users and co-designers, management as approval body

In short

In a steam-turbine factory in Brazil, Siemens builds custom machines for power plants and industrial sites. Five industrial engineers define the manufacturing processes there, routings in SAP terms, that the shop floor follows to machine and assemble every part. The way to get there ran through printed bills of materials, highlighter pens and copying old SAP texts. As an employed application engineer, Thiago Andrade mapped the workflow, validated the core problems with the team and implemented a solution made of Excel automation, a template library and an SAP link. The result, according to the project records: 80 % less lead time, from one to two days per bill of materials to hours.

For Beabstracto this is the origin case. It is where the way of working we now bring to industrial and banking projects took shape: first understand the workflow at the workplace, then the functional concept, then a prototype in the tools people already use. In this text, “we” means Thiago and the industrial engineering team; it was not a Beabstracto engagement.

Numbers

All values come from the project records; the quantities per turbine are approximations.

80 %
less lead time for manufacturing documentation per bill of materials: 1–2 days → hours
time per bill of materials before and after, sometimes minutes: 0 min
manual sorting of purchased parts per list after go-live: 34 × ~500
main bills of materials per turbine × items per list, of which 8–30 need manufacturing

Starting point

What was the starting point? A factory that builds custom machines, and five engineers who started every new project with a stack of paper and a highlighter.

A steam turbine takes eight months to a year to manufacture and another year to install and commission; depending on the project, costs range from one to fifty million euros. Thousands of people work in the factory, in engineering, assembly, purchasing and sales, so that in the end a power plant or an industrial site, mostly in South America and the United States, generates electricity.

The users are the industrial engineers: a team of five, mostly mechanical engineers with further specialisation as welding experts, Six Sigma black belts, experienced assemblers or CNC machinists. Their actual job is to improve processes, reduce manufacturing waste and use their expertise to cut costs. On top of that, they have to define the manufacturing processes for every machine. The project persona is Carlos, 32: AutoCAD, Excel, SAP and a radio, often right on the shop floor, overtime at every bottleneck, several projects in parallel under tight deadlines.

A manufacturing process is essentially a recipe: a document stored in SAP that the shop-floor staff open and that describes step by step how a specific part is machined or assembled, with heat-treatment specifications, machining parameters, durations and references to drawings. Anyone who knows SAP would call it a routing.

This is how the work ran before the project: order management buys the parts and prints the bills of materials. The industrial engineer receives a stack of paper per main assembly and strikes out the purchased parts item by item: bolts, nuts, washers that arrive ready-made. What remains is marked with a highlighter and put into the queue. Per turbine that is around 34 main bills of materials with roughly 500 items each, of which 8 to 30 need a manufacturing process. For every marked part the engineer then searches SAP for a similar part from an old project, a guessing game with project codes, copies the text and changes every project-specific detail in a very long document.

What was at stake? Steam turbines are custom machines: the main components are always similar but never identical. The knowledge of which variant fits when lived in the heads of the five engineers and in old PDFs. And because every disruption on the line takes immediate priority, there was hardly any time left for what the department is actually there for: process improvement.

Flow diagram of the as-is process: order management buys and prints the bill of materials, industrial engineering analyses it, queues the items that need manufacturing and copies process content for similar parts from old SAP projects — The as-is process from the workflow mapping: from the printed bill of materials to the copied SAP text.

The problem

What was the problem? Not a single bottleneck, but a chain of manual steps that started over with every project.

Highlighting bills of materials on paper
Hundreds of items per list, a handful of them relevant. The engineer read every line, recognised purchased parts by name and experience, and highlighted the rest. Hours per list before a single process existed.
Similar SAP texts rewritten every time
Because the parts resemble each other, the engineers copied old processes. To do so they had to guess the project code of the right old project, open the text in SAP and change every project-specific entry by hand in a very long document. Every change was a source of error, and there was no versioning.
No standardisation for custom machines
A rotor is always a rotor, but never the same rotor. Without templates with variables there were only two options: write everything from scratch or copy blindly. Neither scaled, and both produced inconsistent processes.
Knowledge stays in heads
Heat-treatment specifications, cutting speeds, proven sequences: all of that sat in old PDFs or nowhere. Every engineer solved the same problem again, and newcomers had nothing to hold on to.
Line disruptions eat the planning
Anyone who writes documentation and fixes emergencies on the line at the same time always prioritises the emergency. The strategic work of improving processes and cutting costs regularly fell by the wayside; the team called that not a complaint but the normal state.

How we went about it

How did we go about it? Not with a workshop day, but over months on the shop floor. As an employed application engineer, Thiago was part of the industrial engineering department and wrote manufacturing processes himself before he changed them.

1
As-is analysis on the shop floor
Before the problem was defined came observation: a turbine's path from pre-sales to delivery, and as the entry point the industrial engineer's first touchpoint, the bill of materials. Thiago created processes himself, juggled line demands and emergencies, and captured the workflow as a diagram, including the quantities. Interviews with the engineers added what observation did not show.
2
Validating core problems and the problem statement
Observation produced a list of eight core problems that Thiago validated with the end users through feedback; that took months, not days. From it came the persona Carlos, the problem statement (“As an industrial engineer, I want to create manufacturing documents faster so that I can focus on process improvement, cost reduction and standardisation”) and four project goals: digitalisation, performance, standardisation, automation.
3
How-might-we in four problem areas
With validated problems, ideation began. The “how might we” questions clustered into four areas: automate and reuse documentation, identify components intelligently, standardise flexibly, reduce overload. Around thirty solution ideas emerged, from a template library in SAP to a dynamic bill-of-materials viewer in Excel and a kanban inbox for open processes.
4
Prioritising by impact and effort
Honestly, there was no big workshop where engineers, developers and product owners came together. There was Thiago pitching one idea after another, building small MVPs and showing them until something validatable emerged. Eight ideas made it into implementation, from the Excel-to-SAP uploader through the process library, the bill-of-materials viewer with automatic filtering and the SAP script automation to the progress tracker. Together with the industrial engineers, the concept went to management.
5
Building the prototype in the users' tools
The solution was not set up as a new system on the side but built in Excel and SAP, with VBA macros and SAP scripting, and implemented by Thiago himself. The bill of materials comes in as XLSX, purchased parts are filtered out automatically, the relevant items land in a queue. For each part the engineer picks a template such as “Standard rotor assembly” or “Blade manufacturing”, adjusts steps, durations and parameters, checks the preview and technical data, and hands the process to SAP with one click.
6
Templates, building blocks and visibility in the team
With the template library and modular process blocks, the engineers stopped reinventing the wheel. Recurring blocks such as material inspection, roughing, finishing or heat treatment are described cleanly once and adapted per project instead of rewritten. A dashboard shows which processes are open, in progress and completed, so that urgency alone no longer decides what happens next.

Persona photo for Carlos, the industrial engineer: smiling man with a beard and tied-back hair against a dark background (stock photo) — Persona Carlos, 32: AutoCAD, Excel, SAP, radio; on the line, under deadline pressure, with knowledge that is hard to share.

“Component Lists” screen with an upload area for Excel files and a table of uploaded bills of materials with status and progress; data fictitious — Bill-of-materials import: upload the XLSX, purchased parts are filtered out, the rest waits in the list.

“Template” dropdown with templates such as Standard Rotor Assembly, Turbine Blade Manufacturing, Casing Fabrication, Quick Prototype Process, Bearing Housing Assembly — Template selection: recurring assemblies as a starting point instead of a blank page.

Artefacts

“Fabrication Manager” dashboard with tiles for completed processes, hours saved, active projects and efficiency rate, quick actions and progress bars of running processes; data fictitious — Dashboard: quick actions (upload bill of materials, create new process, generate document) and the status of running processes in one place.

Process editor with available step types on the left (CNC machining, welding, assembly, quality check, heat treatment), step list in the middle and preview on the right; data fictitious — Process editor: assemble steps from building blocks, maintain duration and parameters per step.

Full-screen view of the process editor with form fields for step name, type, duration, description and parameters such as speed, feed rate and tool, plus a live preview of the work instruction; data fictitious — Full-screen editor with live preview: speed, feed rate, tool and duration turn directly into the work instruction.

Library of process templates with categories such as CNC, welding and assembly; data fictitious — Template library: recurring processes such as rotor assembly or blade manufacturing as editable templates.

“Smart Data” view with technical details on drawings, parameters and tolerances before export; data fictitious — Smart data view: check drawings, parameters and tolerances before hand-over instead of correcting them in SAP later.

“Process Preview” dialog for a rotor shaft with numbered work steps from material inspection through turning and boring to heat treatment, each with a duration, and the buttons “Edit Process” and “Approve and Send to SAP”; data fictitious — Process preview: read the finished work instruction, edit it, or approve it and send it to SAP.

Progress indicator of the hand-over to SAP with a percentage value — Hand-over to SAP with visible progress and feedback, instead of manual entry with no feedback.

Schematic graphic: three connected nodes, in the middle a shield with a checkmark as a symbol for verified, standardised building blocks — Standardisation as a goal: verified building blocks that can be adapted per project.

Result

What is the result? A day-long task per bill of materials became a matter of hours, and the knowledge behind it no longer lives only in heads.

Aspect	Before	After
Checking the bill of materials	Paper stack, highlighter, item by item	XLSX import, purchased parts filtered out automatically
Creating the process	Guess the old project, copy the SAP text, adjust line by line	Pick a template, adjust steps and parameters, check the preview
Hand-over to SAP	Manual entry, errors only visible in the system	One click, checked beforehand in the smart data view
Time per bill of materials	One to two days	Hours, sometimes minutes (80 % less according to project records)
Knowledge	In heads, old PDFs and project codes	Templates and building blocks, versioned and searchable
Overview	None; urgency decides	Status and progress visible per process

80 % less lead time
What used to take one to two days per bill of materials now takes hours with automation, reusable templates and the Excel-to-SAP link, and minutes in simple cases. The figure comes from the project records; where no measurement exists, we do not quote one.
Zero minutes for sorting
Printed bills of materials, highlighters and manual filtering have been replaced by a searchable interface. The system makes the distinction between purchased part and manufactured part; the engineer starts directly with the process.
Reuse instead of rewriting
With the template library and modular process blocks, processes for similar parts are built from verified blocks. Project specifics get adjusted, the rest stays consistent, and the error source “change long texts by hand” disappears.
Scalable knowledge
Heat-treatment specifications, machining speeds and proven sequences are stored, versioned and searchable across projects: the basis for onboarding and for standardisation beyond the five heads.
Time for the actual job
The department exists to improve processes and cut costs. Less time for documentation means more time for that, and the dashboard shows what is open before it becomes urgent.

What we learned

01
Work alongside first, then design
The core problems were not settled after one interview but after months in which Thiago wrote manufacturing processes himself and lived through emergencies on the line. Paper stacks and highlighters were symptoms, not misconduct. For industrial clients this means: process mapping means walking along and lending a hand, not just asking questions.
02
The solution belongs in the tools that are already there
Excel and SAP were available, familiar and approved. Building the solution into them instead of placing a new system next to them is what made adoption possible in the first place. In SAP and MES initiatives we therefore first check what the existing stack can do before anyone orders a new interface.
03
Standardising means allowing variants
Custom machines cannot be forced into rigid templates. What worked were building blocks with variables: the same rotor assembly, but different quantities, sequences and parameters. Templates that fix everything get bypassed; templates that provide the scaffold and leave the details open get used.
04
No pitch, no adoption
There was no ideal workshop with everyone involved. There were many small demos, MVPs and setbacks until the engineers made the concept their own and went to management with it. That alliance with the future key users decides in every rollout whether a tool merely exists or gets used.
05
Numbers come from the workflow, not from the survey
The time per bill of materials, the number of lists per turbine and the share of items needing manufacturing were collected during the as-is analysis. That made the improvement measurable later without estimating after the fact. Count before the project and you can prove it after.

What we delivered

As-is analysis and flow diagram from the printed bill of materials to the routing in SAP
Quantity structure per turbine: bills of materials, items, share needing manufacturing
Persona, problem statement and four project goals
Eight core problems, validated with the team
How-might-we questions in four problem areas, around thirty solution ideas
Prioritisation by impact and effort
Excel-based bill-of-materials import with automatic filtering of purchased parts
Template library and modular process blocks with variables
Process editor with steps, durations, parameters and preview
SAP link via SAP scripting with one-click hand-over and progress indicator
Dashboard with status and progress of running processes
Concept pitch to management, together with the industrial engineers

Frequently asked questions

Was this a Beabstracto engagement?: No. The work was done while Thiago Andrade was part of the industrial engineering department at Siemens as an application engineer in permanent employment. What Beabstracto takes from it is the way of working: as-is analysis at the workplace, core problems validated with users, functional concept, prototype in the existing tools, and a rollout the key users carry.
Can Beabstracto repeat this for our SAP or MES processes?: The approach yes, the code no; that belongs to the former employer. We map the workflow in production planning, production control or maintenance, find the places where engineers lose days, develop the functional concept with the key users and test a prototype with real bills of materials before development or customising starts. We do not replace SAP consultants; we make sure that what they build gets used.
Where does the 80 % figure come from?: From the project records: before the rollout, documentation took one to two days per bill of materials, afterwards hours, in simple cases minutes. The quantities per turbine are approximations from the as-is analysis. Where no measurement exists, we do not quote a number.
Do we need a new system for this?: In this case, no. The solution ran in Excel and SAP, tools the engineers already used daily and IT had already approved. Whether that is enough for you or a Fiori, MES or web front end is needed is something we settle in the as-is analysis, not before.
Do the screens show the original software?: The screens come from the portfolio case and show the solution with fictitious data; names, project numbers and KPIs are placeholders. Internal Siemens data, drawings or process content are not published.
Which role and which keywords fit for recruiters?: Back then application engineer in industrial engineering, today UX designer and business analyst with a UX focus for specialist systems in industry. Relevant terms from this case: SAP, routing, bill of materials, production planning, shop floor, process mapping, as-is analysis, functional concept, prototype, key user, Excel/VBA, SAP scripting.