Case study: Implementation of assembly line business processes, illustrated by the example of DIY computer service at Ultra Electronics.

In the golden age of the company, no one even heard of tablets, smartphones were exotic things for geeks, while the word "computer" always implied a desktop.
Which was either assembled by the customer from hardware components, or this service was ordered at a computer store (that sold those parts).

It’s the latter case we’d like to talk about.
 

1. Building & ordering a customized PC

A prospective happy owner of the PC goes online to the web configurator and selects components:

(the same functionality is available in the salesperson’s interface, if the customer orders his computer in-store).

dia$par has built-in filters that cut off most errors related to the components incompatibility.
The filters are based on the data from standardized product descriptions:

Since there’s no immediate order dispatch when assembling is ordered — for the obvious reasons — dia$par allows using stock at remote warehouses.
The list of available warehouses is configured randomly:

If a delivery from remote warehouses is required, dia$par automatically recalculates the expected production lead time, taking into account the time needed to deliver the components.

2. The order is completed.

After the "OK" button is clicked in the configurator on the website or in the salesperson interface, the work order is sent to the assembly.
Internal delivery notes to bring components from remote warehouses are created automatically.
 

After all the components become available at the local warehouse, dia$par sends an order to transfer them to the production warehouse, and a new order is added to the assembly department’s job queue:

3. Operation at the warehouse.

Due to a large volume of custom orders, employees of the local warehouse do not dispatch components to the assembly for every single order, but rather in batches — at a certain frequency (usually, every hour; the task launches generation of release notes for internal transfer according to a schedule).

The release note for internal transfer "local warehouse → production warehouse" contains all the components on all the orders that have accumulated since the last transfer up to now

When items are transferred, their barcodes are recorded in the database.
If all the components for a certain order have been transferred to the assembly warehouse, the order status (document type) is changed to "In assembly".

4. Pure assembling.

dia$par automatically selects an assembler (there’s an adjustable set of criteria; the basic criterion is the minimum order completion time; labor skills, etc., may also be taken into consideration).
The assembler receives notification about a new order and collects components from his warehouse. He puts together, configures, tests the computer and does all other trivial actions.
Barcodes of every component installed into the product are scanned and stored in the database.

As a result, dia$par stores complete information on every final product — all components along with their serial numbers, the supplier and the delivery date for each component, the exact time (down to seconds) — when components were transferred to the assembly, of the assembling itself, when the final product was transferred to the warehouse and dispatched to the customer.

5. The assembler attaches a barcode (the serial number for the assembled computer), printed out from dia$par, onto the assembled, configured and tested computer:

Then he scans it with his barcode scanner, the meta-system labels the work order as completed and transfers the finished computer to the assembly warehouse.

6. The same as in step 3, but in the opposite direction: once an hour, the task generates a release note for internal transfer "production warehouse → local warehouse" for items produced up to that moment.

7. In order not to expand the internal product classification with unique products on every custom order, assembled products are recorded by both the product code and the serial number (barcode).
Ultra Electronics used 4 CPU type based products for custom configurations (13165 "Intel Pentium based PC", 13166 "AMD Athlon based PC", ...).
This is what the addressing in documents looked like: 13165 "Intel Pentium based PC s/n 13817869". The number of "root" products used can be anything, from one to indefinite.

8. The FIFO production cost for made-to-order products is calculated by dia$par automatically; for each "product code / serial number" pair individually.

9. When a finished product arrives at the local warehouse, dia$par automatically notifies the salesperson (if he took part in the process) and the customer.
And then it’s dispatched as usual.

In 2005, Ultra Electronics manufactured and dispatched 47,000 custom-built computers using the above-described scheme.
Glitches encountered were within the range of standard deviation.

P.S. Assembly of serially produced items (as opposed to custom-built, as discussed above) is implemented in a similar way. That’s why we decided not to make it a separate case.
Except, instead of the work order document, a process diagram? is used, and the production cost is calculated for the production batch in general.

dia$par supports the process flow for both job production (one product assembler per item from beginning to end) and the assembly line scheme, where people specialize in certain operations.

Following dia$par scheme for flow production, in 2006 Ultra Electronics manufactured 83,000 PC system units, while Ulmart — 52,000 pieces in 2014 respectively.