Linear Programming for Sewing Line Balancing

Your line chief has just handed you a new style: 42 operations, a target of 480 pieces an hour, two hours before the line starts, a stopwatch, and a whiteboard. By 2 p.m. the line is at 78 percent efficiency, three stations are starving while WIP piles up in front of one bottleneck operator, and the floor manager wants to know why the "balanced" line isn't balanced.

This is a line balancing problem (which operation goes on which machine, in which order), and eyeballing it against a whiteboard is a bad way to solve one with 42 items and dozens of valid orderings. Line balancing linear programming solves that search the way a spreadsheet solver finds the cheapest shipping route: define the variables, write the constraints, let the solver find the assignment.

This article gives you the formulation, in notation you can type into Excel Solver or a short Python script, a worked example you can follow by hand, and where the math stops matching your floor.

The Decision You're Actually Making

There are two versions of the problem, and mixing them up is the single most common reason a "linear programming" line balancing exercise produces a number nobody can use.

Type 1 fixes your cycle time and asks: what is the minimum number of stations needed to hit it? This is the version taught in most operations research courses. Type 2 fixes your number of stations, because you have already hired 36 operators, and asks: what is the minimum cycle time achievable with that headcount? This is the version factories actually want, since manpower is a sunk cost by the time balancing happens. Decide which one you're solving before you write a single constraint, much as a two-machine job shop needs to settle its objective before applying something like Johnson's rule for sequencing jobs across two stages.

The Line Balancing LP Formulation

No proofs, no summation notation you need a textbook to parse: just the variables, the objective, and the four constraint families that do the actual work.

Decision variables: x[i,k] = 1 if operation i is assigned to station k, otherwise 0. C = cycle time in minutes per piece, the value being minimised.

Minimise  C

Constraint 1 (Completeness): every operation assigned to exactly one station
For every operation i:  sum over all k of x[i,k]  =  1

Constraint 2 (Capacity): no station's workload exceeds the cycle time
For every station k:  sum over all i of ( t[i] × x[i,k] )  ≤  C

Constraint 3 (Precedence): if a must happen before b, a's station ≤ b's station
sum over k of ( k × x[a,k] )  ≤  sum over k of ( k × x[b,k] )

Constraint 4 (Bounds):  x[i,k] ∈ {0,1}     C ≥ 0

Here t[i] is the SMV of operation i, drawn from a properly run standard minute value calculation, not a figure estimated for this exercise. That's the whole model: four constraint families, two variable types, one objective. It fits in an Excel Solver sheet with operations as rows and stations as columns, or in PuLP, Python's open-source LP library, in under 40 lines. For Type 1, flip the objective to minimising stations used, and Constraint 2 becomes a hard cap against the cycle time you were handed.

The Constraints Nobody Writes Down

Three more constraints need to go in before a solved solution survives the floor. Machine compatibility: an overlock operation cannot land on a flatlock station, so hard-fix x[i,k] = 0 for every incompatible pair before you solve. Skill matrix: a helper cannot be handed a precision topstitch on a customer-facing panel, so build a reusable skill matrix and zero out the same way. Zoning: a matching pair of topstitch passes shouldn't split across two stations because it doubles handling and creates a defect point, so enforce with x[i,k] = x[j,k]. Add these three and you remove most "the model is wrong" objections from the floor.

A Worked Example: Ten Operations, One Cycle Time

Full 42-operation models are hard to follow by hand, so here is a slice you can check with a calculator: the collar-and-neckline sub-assembly of a basic polo shirt, ten operations, real standard minute values. Precedence is a single chain, except 4 and 5, which can go in either order but must both finish before 6 begins.

Total content: 3.52 minutes. Target: 480 pieces in an 8-hour shift, so required cycle time = 480 ÷ 480 = 1.00 minute/piece. Minimum stations: 3.52 ÷ 1.00 = 3.67, rounded up to 4. Solving the model against the precedence chain above gives this assignment:

Line efficiency = total content ÷ (stations × cycle time) = 3.52 ÷ (4 × 1.00) = 88.0 percent. Balance loss is the remaining 12 percent, concentrated on stations 1 and 4, the mathematical floor for this SMV distribution and station count, not a rounding error or a supervisor's failure. Whether that idle time justifies adding a fifth station is a separate capital question, better answered with decision tree analysis for capacity investment decisions run against demand uncertainty than by re-solving this LP.

Reading the Balance Loss Number

On a full 42-operation polo shirt line with 36 stations and 18.6 minutes of total standard content, the theoretical minimum cycle time works out to roughly 0.517 minutes, a ceiling of about 116 pieces per hour. Solved against real precedence and machine constraints, the achievable cycle time lands closer to 0.55–0.58 minutes: 103 to 109 pieces per hour, a balance loss in the 7–10 percent range.

A well-constrained model should land inside that 7–10 percent band; if yours reports under 2 percent, distrust it before you celebrate it: that almost always means a precedence or machine-compatibility constraint was left out, not that you found a genuinely tighter line.

Field note: A denim-shirt line I audited in Chattogram showed a solver output of 96.4 percent efficiency, suspiciously high for 38 operations. The model had no zoning constraint, so it had split a matching double-topstitch pass across two stations to shave 0.02 minutes off cycle time. On the floor that created a bundle-move delay between stations. Actual output ran 11 percent below the model's prediction until we added the zoning rule and re-solved.

If predicted and actual output diverge by more than that band, the gap is rarely the balancing itself, but usually absenteeism, an unbalanced feed rate out of cutting (often solved with a kanban pull system linking cutting and sewing), or quality rework pulling pieces back into the line. Check those before re-running the solver.

Where Pure LP Breaks Down on the Shop Floor

High operator variability: above roughly 0.25 operator time coefficient of variation (common with mixed tenure and skill grades), the model gets optimistic, assuming every operator hits the average every cycle. Mixed-model lines: if two or three styles run through the same stations in one shift, a single-style LP is answering the wrong question. Machine changeover and absenteeism: the LP assumes every station is always staffed and ready, with no concept of a helper out sick or a changeover eating the first twenty minutes. No amount of extra constraints turns a static LP into a live simulation.

What Practitioners Actually Do Instead

The honest answer is not "abandon the LP." It's: use it to find the mathematical floor, then adjust by hand for what the model can't see.

• Solve the LP first, with machine compatibility, skill matrix and zoning included: this gives the best-case assignment and the honest balance-loss number to expect.

• Overlay a heuristic pass, most commonly the largest-candidate-rule: assign the longest remaining operation to the station with the most idle time first, respecting precedence. When the two roughly agree, trust the model; when they diverge sharply, a constraint is usually missing.

• Rebalance on the worst-performing style, not the best, which flatters your method and hides where the line struggles.

• Re-solve weekly for the first two weeks of a new style, then monthly once stable, since early learning curves shift real SMVs enough to change the optimal assignment.

• Treat every solved model as a starting position for the supervisor, and track the resulting efficiency alongside your other floor metrics rather than as a one-off exercise.

Line Balancing LP: Setup Checklist

Final Word

Linear programming will not balance your line for you. It will tell you, precisely and honestly, the best that an assignment of operations to stations can do, worth having because it replaces a whiteboard guess with a defensible target. The gap between that number and what your line actually runs is where the real management work starts, and no solver closes it for you.