01 · Purpose and boundaries
Purpose and boundaries
Conceiving solutions bridges analysis and implementation. The output is a set of credible ways to change the mechanism producing the problem, rather than a list of attractive technologies. Start from a defined customer requirement and evidence about causes. If late dispatch is caused by orders waiting for a missing verification, buying a faster conveyor addresses a different mechanism.
Separate the required function from its present implementation. A requirement might be “confirm the parcel and carrier service before loading”; it does not necessarily require a particular screen, signature, or inspection station. This separation creates space for alternatives while retaining quality and compliance requirements. Involve operators, maintenance, information technology, safety, and the downstream customer where their knowledge affects feasibility. A solution concept is provisional: it describes an intervention, a causal explanation, operating assumptions, and a way to judge the result.
02 · How the method works
How the method works
Restate the problem using its baseline and boundary. Then connect each confirmed cause to a design requirement. Translate “operators look for carrier labels” into “the correct approved label must be available at the point of packing.” This prevents vague aims such as better communication from becoming untestable recommendations.
Generate several mechanisms before comparing them. Eliminate the need for a label search; provide labels at point of use; standardize a search location; or automate label selection. These concepts differ in complexity and failure modes. Develop each far enough to describe the normal sequence and the exception sequence. Reject concepts that require prohibited actions, but postpone preference ranking until the range is visible.
Use must-pass requirements before weighted preferences. Safety, mandatory traceability, physical capacity, and customer requirements are gates; a high cost score cannot compensate for failing one. Compare survivors on service effect, total work, maintainability, implementation effort, reversibility, and uncertainty. Scores support discussion but do not manufacture facts. Finally, define a pilot that tests the causal mechanism, including the circumstances in which it could fail.
03 · Worked logistics example
Worked logistics example
Fictional HarborGate Fulfilment ships 600 parcels per day. Forty-eight miss the planned loading window. Observation identifies 30 late parcels waiting for approved carrier labels, 12 waiting for export data, and six affected by unrelated disruptions. Label waiting is therefore a bounded opportunity, not the entire dispatch problem.
Three concepts emerge. A dedicated label printer at every bench removes walking but costs more and requires printer support. A shared printer with ordered trays reduces search but retains transport. Printing a verified label as the order reaches packing changes both timing and information flow. The team rejects preprinting every forecast order because cancellations would create loose, misleading labels.
A two-bench pilot covers 120 parcels per day. The baseline has six label-related late parcels per day at these benches. Over five comparable days, verified printing on arrival yields five such late parcels across 600 parcels, compared with 30 expected at the baseline rate. Export-data delays persist. The pilot also records two printer outages; the approved fallback restores service without bypassing parcel verification.
04 · Interpretation and decisions
Interpretation and decisions
The observed label-delay rate falls from 5% to about 0.83% in the pilot. This supports the mechanism but does not justify claiming that all 48 daily late parcels will disappear. Applying the same effect to 600 parcels suggests roughly five label-related late parcels instead of 30, provided the workload, equipment, and availability remain comparable. The other 18 baseline delays require different action.
Choose the arrival-printing concept only after checking its compatibility with the warehouse management system and the fallback workload. The dedicated-printer alternative may be preferable where network reliability is poor. Record why the chosen concept meets the requirements and what evidence would trigger reconsideration. This is a decision under uncertainty, not a contest to produce the highest numerical score.
05 · Common misapplications
Common misapplications
A common failure is disguising a favored purchase as the only solution. Another is generating dozens of slogans without describing how work changes. “Use AI” and “improve training” are categories, not implementable concepts. Require the affected action, responsible role, trigger, and abnormal-condition response.
Do not treat correlation from analysis as proof of cause. If label waiting coincides with late orders because both occur during unusually complex exports, the concept needs a more careful test. Avoid averaging away a disqualifying risk or letting seniority substitute for evidence. Include downstream work: a solution that creates duplicate labels or reconciliation tasks may relocate the defect rather than remove it.
06 · Advanced adaptation
Advanced adaptation
For complex systems, decompose the solution into interacting functions: authorize the order, select the carrier, print identification, confirm application, and release loading. Develop alternative mechanisms for each function, then combine compatible choices. Check interfaces explicitly; two individually useful components can produce contradictory statuses together.
When uncertainty is high, choose a sequence of small experiments rather than a single irreversible rollout. Test information accuracy before automating physical release. Use robust criteria across several plausible demand scenarios rather than optimizing one average day. Maintain a concept log so rejected approaches can be reconsidered when constraints change. This approach keeps creativity connected to operational evidence without prematurely freezing the final design.
07 · Implementing and sustaining the change
Implementing and sustaining the change
Introduce conceive solutions within a clearly named operating boundary. Identify the product family, shift, equipment, and handoffs affected; record what happens immediately before and after that boundary. A change that improves one task while exporting its delay to another department has not established an improvement. Agree who can stop the trial, who handles exceptions, and which customer commitment takes priority when the normal rule cannot be followed.
Establish a baseline from actual work rather than a single demonstration. Include normal variation in order mix, replenishment timing, staffing, and workload. Keep the denominator visible: minutes per order, defects per shipment, or completed lines per available hour answer different questions. Record the workload and conditions alongside each observation so that a quiet trial period cannot masquerade as better performance. Observe the process with the people who do it; their explanation of interruptions often changes the proposed design.
Start with a reversible pilot large enough to expose handoff problems. Explain the expected mechanism before launch: which action changes, which delay or failure it removes, and which result should respond. Train all affected shifts and support roles using the same operating definition. During the pilot, capture exceptions as information about the design. Do not conceal them through unofficial stock, unrecorded overtime, or a specialist who quietly repairs every failure.
Review customer service, safety, quality, work content, and inventory together. A faster average with more severe late orders may be unacceptable; a lower inventory level with repeated emergency deliveries may have displaced the cost. Investigate variation before declaring success. If the expected mechanism does not appear, revise the design or return to the baseline rather than defending the idea. A promising observation is a reason to test more conditions, not proof that every operating context will behave identically.
After a successful trial, make the new rule part of daily work. Give an accountable owner responsibility for the operating standard, change control, training, and periodic review. Specify the abnormal condition that requires escalation and the person who responds. Check whether the improvement remains effective when a trained colleague is absent or demand changes. Sustain the mechanism through routine management and learning; documentation is useful only when it describes the process people actually follow.
Connections
Related methods and phase use
Placed under Improve because of the outcome it supports. Use the method in other phases when its purpose and assumptions fit the work; the phase list is a guide to selection, not a compulsory sequence.
Sources
Professional foundations and further reading
The explanation and fictional teaching examples are written for LeanTrainingLab. Linked primary sources provide professional foundations; example values and local conventions are stated in the guide. The accepted toolset draws on Six Sigma+Lean Toolset, second edition (Lunau, editor; Springer, 2013). No book text or examples are reproduced here.