Vulcan ERP
Designing One Connected System for a Manufacturer That Ran on Paper
Intro
Vulcan is a manufacturing ERP I designed for a transformer production company that managed its order-to-dispatch process on paper.
As the sole product designer, I mapped how work and information moved across the business, then designed seven connected modules around a single work order. The goal was to carry information from one department to the next without repeated entry or forcing teams to abandon the processes they already understood.
Role
Sole Product Designer
May 2024 to Mar 2025
Type
0->1
B2B ERP
Status
Partially Developed
Problem
Seven departments relied on paper handoffs to move an order from sales to dispatch. Teams repeatedly entered the same information, had little visibility outside their own stage, and manually created documents using data the business already had.
Decisions
I mapped the complete order process before designing, then built seven connected modules around a single work order. I also designed separate production interfaces for managers and floor workers because their responsibilities, devices, and information needs were fundamentally different.
Outcomes
All seven modules were completed at the design stage. Several core workflows, around 20 to 30% of the product, entered development before I left. In the completed design, order information could move from sales to dispatch without being entered again.
DESIGN CHALLENGE
Seven Departments Were Working Without One Shared System
Each department could see only its own part of an order. Work orders travelled as physical documents, inventory was updated manually, and finance re-entered information at dispatch that other teams had already recorded. A missing or delayed update could affect every team waiting downstream.
Digitizing each task separately would have preserved the same gaps on a screen. The real challenge was connecting all seven departments through one flow without forcing people to abandon the processes they relied on to do their jobs.
Who Used the System
Six Roles Worked on Different Stages of the Same Order
Sales Managers
Converted enquiries into work orders and entered the customer and order details every downstream team relied on.
Transformer Designers
Created technical drawings and Bills of Materials that defined what each transformer required.
Inventory Staff
Checked the Bill of Materials, allocated available stock, and flagged missing materials before production.
Production Manager
Scheduled work, tracked progress across seven manufacturing stages, and responded to delays.
Production Workers
Completed each manufacturing stage on the factory floor and recorded progress through QR scans.
Finance Staff
Used completed order information to generate the legal documents required at dispatch.
Process
Issue #1
The Real Workflow Was Spread Across Seven Departments
Before designing the system, I needed to understand what each department received, added, and passed forward. Without that view, I could have digitized individual tasks while preserving the same gaps between them.
I sat with the company owner and mapped the process from the first sales enquiry to final dispatch. We traced the paperwork passed between departments, the information created at each stage, and where existing information had to be entered again.
That mapping changed how I structured Vulcan. Instead of treating the seven modules as separate products, I designed them around one work order that carried information forward as it moved through the business.
Issue #2
The Bill of Materials Was Passed to Departments as an Excel File
For every transformer, the designer created a technical drawing in AutoCAD and a Bill of Materials in Excel. The BOM listed every component required for production, but it was manually passed to inventory as a separate file, disconnected from the work order it belonged to.
Because inventory used the BOM to allocate materials, I made it a structured part of the work order instead of another file that had to be forwarded. The technical drawing and BOM could be managed together, with every material recorded by component type, quantity, and unit.
Transformer BOMs can be long, so I grouped the inputs by component type to follow how designers already organized their lists. Once submitted, the BOM became available to inventory within the same work order, removing the manual file handoff from the designed workflow.
Issue #3
Missing Materials Could Stop Production Without Warning
Inventory needed to allocate materials to each work order, track what production consumed, and identify stock gaps before they delayed the factory floor. With inventory managed manually, there was no reliable early warning when an essential material was running low.
The client identified an opportunity to automate purchase-order creation. I designed the logic and workflow around it. When stock fell below a defined threshold, the system creates an intent (List of items below threshold) and alerts the inventory manager. They could review it, make changes, and send it to the purchase and they send it to supplier rather than discovering the shortage after production needed the material.
I also designed an outbound log that recorded every material release against the work order and production stage that requested it. In the completed design, inventory and production could see what had been allocated, what had been consumed, and what needed to be purchased from the same system.
Fig. Log Screen for Outwards, Inwards and Intent
Issue #4
Production Managers and Floor Workers Needed Completely Different Tools
Production moved through seven stages, but the two primary users interacted with that process at different levels. A production manager needed to monitor every active order, identify delays, and manage deadlines. A floor worker needed to see the current task, record progress, and continue working with minimal interaction.
Trying to serve both roles through one interface would have overloaded workers or limited the information available to managers. The client and I agreed to create two separate experiences using the same underlying work-order data. I designed how each experience would work.
For floor workers, I designed a mobile experience. Workers could see active orders, scan the company’s existing QR codes to move an order to its next stage, and upload the required documentation. I kept the interaction deliberately short: scan, confirm, and continue.
For production managers, I designed a web experience. A Kanban board showed every work order at its current stage, while a timeline view helped managers track progress against deadlines. Documents uploaded from the floor remained attached to the relevant work order.
At the final stage, the production team completed a structured testing report based on the paper form they already used. Both interfaces worked with the same order data, allowing progress recorded on the factory floor to become visible in the manager’s view without separate reporting.
Fig. Kanban & Timeline View of Manager
Issue #5
Finance Re-entered the Same Information to Create Three Dispatch Documents
At dispatch, finance created an e-invoice, an e-way bill, and a delivery challan across separate platforms. Much of the required order, customer, and transport information had already been entered earlier in the process.
The founder suggested connecting Vulcan with Pegasus, a compliance-document tool the company had previously built. I mapped what Pegasus required against the information Vulcan already held, then designed a flow that pre-filled the existing data and asked finance to confirm only the remaining details.
One action could then generate all three documents without finance re-entering information already stored in the work order.
Why the navigation sits at the top
Most Vulcan screens were built around wide data tables. I placed the seven modules in the top navigation to preserve horizontal working space for the information users needed throughout the day.
What Changed
Vulcan was only partially developed when I left Tradais, so I do not have live usage or efficiency metrics to claim.
7 connected modules designed
The complete order journey was covered, from the first sales enquiry to finance and dispatch.
20 to 30% entered development
Several core workflows were being built before I left the company.
One connected work order
In the completed design, information entered at one stage could carry forward to the next instead of being entered again.
The most important design outcome was not an individual feature. It was the chain. For a business that had operated through paper handoffs, connecting that chain was the product.
How I Would Measure It After Launch
Vulcan had not fully launched before I left. These are the metrics I would use to evaluate whether the designed workflows created real operational improvement:
Dispatch efficiency: Time required to generate all three compliance documents and the percentage requiring corrections.
Material availability: Production delays caused by missing stock and the time between a low-stock alert and purchase-order approval.
BOM accuracy: Corrections made after BOM submission and mismatches discovered during inventory allocation.
Production visibility: Percentage of stage transitions recorded through QR scans and the delay before updates appeared in the manager’s view.
What I’d Do Differently
The company owner gave me the complete view of how an order moved through the business, but each department experienced only one part of that process.
If I restarted the project, I would observe people from every department performing their actual work and test each workflow with them before finalising the system. I would also pilot one order from sales to dispatch before scaling the design across all seven modules.
That would expose exceptions the documented process might miss, establish baseline metrics, and validate the connected model before the entire system was built.
Gallery
