Kaizen suggestion system: statuses, roles and effect calculation

Why Kaizen ideas often get “stuck"

Usually it starts energetically: employees submit suggestions, a manager asks to “collect ideas”, and a table or chat appears. After a month there are dozens of entries but almost no implementations. People stop proposing because they don’t see any reaction or results.

The main reason is that initiatives don’t have a clear path. If it’s not defined who decides, who does the work and by what date, the idea becomes a “wish”. Even strong suggestions drown among minor ones: they aren’t sorted, prioritized or taken to pilot.

The process is clearly stalled if:

• more than half of ideas get no response for longer than 1–2 weeks;
• the same problems repeat, but solutions never reach testing;
• there are no short reports “what was implemented and what effect was achieved”;
• authors learn about status only when they follow up themselves;
• people argue about the effect after implementation, not before.

A common trap is to count only monetary savings as “effect”. In practice it’s helpful to agree in advance on four result groups: money (costs, output), time (operation speed, downtime), quality (defects, rework, complaints) and safety (risks, injuries, violations). If you don’t agree on what counts as effect and how to confirm it, the idea easily stalls with “not clear what it will give”.

Simple example: an employee suggests changing kit order to reduce time spent searching for parts. Without a status, an owner and a deadline, this stays a note. If you immediately assign a process owner, a deadline for evaluation and a calculation rule (minutes per operation before/after, how many operations per shift), the initiative moves faster from idea to verifiable result.

What the suggestion system should deliver

The Kaizen suggestion system is not a “idea bank” but a clear exit: decision made, implementation done, effect confirmed. If that exit isn’t described, initiatives live in “under review” and gradually disappear.

A good system gives three results:

• speed — a short route from idea to verdict (yes, no, revise) with clear deadlines;
• decision quality — decisions based on data, not opinions;
• transparency — anyone can see who is responsible for the next step and where it stalled.

Measure success not by the number of entries, but by what actually changes. Usually four indicators are enough:

• share of implemented initiatives and average time from submission to implementation;
• confirmed effect (savings, increased output, reduced defects);
• engagement (how many people submitted at least one idea per quarter);
• flow quality (how many ideas reached verification without “manual rescue”).

A working principle is simple: one idea — one owner — one outcome. The owner is responsible for status movement and the final result, even if another department performs the implementation.

To avoid bureaucracy, the idea card should be short: problem, location/area, the proposal, expected effect and how it’s measured, owner, and the next decision deadline. For example, in PC and server manufacturing, an initiative “reduce setup time on the test bench by 10 minutes” should immediately have an owner and a measurement method (time before/after). Then it’s a manageable task, not a promise.

Roles and responsibilities: who does what

Initiatives “die” not because of bad ideas but because roles are unclear. If it’s unclear who must answer, provide resources and confirm the effect, the card hangs.

Define a minimal set of roles even in a small company. Critically, each initiative should have:

• one person responsible for decision and implementation;
• one person responsible for confirming the effect.

Who participates

Initiator (author) describes the problem in simple words, proposes a solution and gives an initial estimate: what will change, where, by what means and an order‑of‑magnitude number.

Process owner accepts or rejects the idea, appoints an executor, allocates people’s time and removes organizational barriers.

Subject experts check assumptions: technology (is it feasible), IT security (any risk?), occupational safety (is it safe), finance (is the calculation correct). Their role is not to block but to provide conditions under which implementation is acceptable.

A Kaizen coordinator manages the queue, monitors statuses and deadlines, reminds participants and records decisions. This dispatcher role prevents losses.

Controlling (and, if needed, accounting) confirm calculations and the fact of savings after implementation: what exactly to count, which sources and which period.

How not to blur responsibility

Useful rule: one owner for the decision and one owner for the numbers. For example, the process owner handles implementation, while controlling verifies savings using an agreed method and observation period (before/after).

If an idea touches several departments (common in production and IT, e.g., workplace or server upgrades), the coordinator gathers a short pre‑approval from experts and records “what is needed to start”. This reduces endless clarifications.

Initiative statuses: a short scheme that works

A status scheme removes gray zones and defines the next step. Each status needs a clear entry, exit and responsible person.

New. Initiative is registered and the wording is clear: what to change, where and for whom. Minimum: problem, location (area/process) and expected result.

Under clarification. Data are missing, and that’s fine. Don’t hang: record the list of questions and a deadline for answers (e.g., how many times the operation is done per day, materials used, safety constraints).

Under evaluation. Calculate effect and risks, check conflicts with regulations and current projects. Also agree on the baseline: how it’s measured now and for which period.

Approved. A decision is made (do now, don’t do, later) and a work plan exists: steps, deadlines, resources, responsible people. If “later”, record the reason and review date; otherwise it’s a hidden rejection.

In progress. Implementation is underway in steps. Record progress briefly: what’s done, what blocks, what is needed from leadership. This status mustn’t last months.

Implemented. Changes are made but the effect is still being checked. Assign an observation period and a verification method (time measurement, consumption comparison before/after, defect report) so success isn’t reduced to just completed work.

Basic discipline rule: a card cannot stay in one status longer than the agreed limit (e.g., 5–10 business days) without a comment and a new deadline.

Suggestion card: required fields

The card is not for reporting but so an idea can be quickly understood, evaluated and brought to result. If cards are filled out “for the form”, initiatives usually stall: the problem, change and comparison are unclear.

Minimum fields

A good card usually fits one page:

• the problem in one paragraph: what happens now and why it’s a problem;
• where and when it appears: area, operation, workstation, system, shift;
• essence of the proposal: what exactly changes;
• expected change and how we’ll measure it (time, defects, downtime, number of requests);
• what’s needed for implementation: people’s time, materials, IT changes, training;
• risks and constraints: safety, quality, regulatory or internal standard requirements.

This is enough so the responsible person doesn’t have to guess or return the initiative for rework.

Fields that speed decisions

Two clarifications often save weeks.

First — who benefits: a specific area, department, internal customers (warehouse, accounting), external customers, IT. It’s easier to pick an owner and agree on priority.

Second — the baseline: one verifiable fact to confirm later. For example: “setup takes 18 minutes measured over 3 shifts” or “operators make 12 manual records per shift”. Without a baseline, effects are argued by feeling.

Small example: if the proposal is to move the container of fasteners closer to the workstation, the card should include a photo of the current layout, a measurement of extra steps or time, estimated costs (moving, marking) and safety constraints.

Process from idea to implementation: step by step

To avoid turning the Kaizen suggestion system into a graveyard, it needs a short predictable route. It’s important to know what happens in the first 48 hours, who is responsible and what result appears at each step.

1. Accept the idea and quickly check for duplicates — not only by title but by location and essence.

2. Assign an initiative owner and a deadline for clarification. The owner isn’t required to do everything but must gather missing data and return the card clearly.

3. Do a quick effect calculation and feasibility check. Record the baseline “before changes”, otherwise there’s nothing to compare later.

4. Make a decision. Usually four options suffice:

• do now;
• defer (with reason and review date);
• merge with another initiative;
• reject (with a short respectful explanation).

If the decision is “do”, create a short implementation plan with 3–7 tasks: what changes (1–2 sentences), tasks with owners, start and end dates, resources/approvals, and the metric after.

The last step is to record proof of change: photos/act, updated instruction, checklist note, or a journal entry. Without a trace, improvements quickly roll back.

Effect calculation method: simple rules

To avoid initiatives becoming “nice ideas without numbers”, agree in advance on calculation rules. Two principles matter most: separate facts from assumptions and account for implementation costs.

One‑time effects and recurring effects are different. One‑time (e.g., sale of surplus equipment) is recorded once. Recurring (e.g., reduced defects) is measured over a period: month, quarter or year. The comparison period should be the same for all initiatives.

Most often it’s convenient to calculate effect by categories:

• cost savings: materials, energy, transport, downtime, defects, rework;
• revenue growth — only when confirmed and clearly linked to the improvement;
• freed time — either converted into money (overtime, hiring) or into increased capacity (output with the same resources).

Always deduct implementation costs. Separate CAPEX (equipment) and OPEX (consumables, maintenance), add training, IT changes, contractors. If improvement requires staff time, agree in advance when that counts as a cost and when it’s part of normal work.

Practical calculation rule:

1. Take the baseline (before) and the comparison period.
2. Calculate “after” on the same volume and similar conditions.
3. Effect = (before − after) * volume − implementation costs.
4. For estimates, take the lower bound of savings and the upper bound of costs.

Example: reduced defects from 3% to 2% on a batch of 50,000 units with unit cost 800 KZT. Savings = (0.03 − 0.02) * 50,000 * 800 = 400,000 KZT. If retooling and training cost 120,000 KZT, net effect for the period = 280,000 KZT. For recurring effects, record how many months it holds and revise numbers when the process changes.

Verifying savings: how to prove the effect is real

It’s easy to draw an economic effect on paper and just as easy to lose it in reality. Verification should be a separate stage with deadlines, rules and responsible people.

First, agree on the comparison baseline. The clearest option is before/after with a control period: e.g., 4 weeks before and 4 weeks after. If the process strongly depends on load, add a control group (area, line, shift) where changes weren’t made, or compare with the same month last year.

Who confirms and when

Confirmation is best done in two steps. The process owner checks that the change works and hasn’t rolled back. Controlling or an economist confirms the calculations. If the effect affects write‑offs, purchases or output, involve accounting.

Evidence should be simple and verifiable:

• time, consumption and defect measurements with dates and a responsible person;
• reports from accounting systems (output, write‑offs, purchases, energy consumption);
• equipment logs, meter readings, photos;
• implementation/test acts and a short protocol of what exactly changed.

How not to be fooled by seasonality and spikes

If a one‑off order, downtime or an “ideal” week without breakdowns follows implementation, the effect is easily overstated. It helps to use medians or averages over several weeks and mark outliers separately.

Another disciplined practice is a repeat spot check after 1–3 months. For example, after a change in the PC assembly template showed fewer defects, six weeks later take the same sample metrics and see if the level held.

If the effect is lower than expected, don’t ignore it. Recalculate the card, record the actual result and the cause (wrong baseline, partial implementation, resistance, missed costs). An initiative can still be valuable with a smaller number if conclusions are honest.

Common mistakes and traps in the suggestion system

Systems break for two reasons: they are inconvenient to use, and responsibility is blurred. Below are the most frequent errors.

Mistake 1: bureaucracy instead of movement

If an initiative has 10 statuses and 5 approval rounds, submitting ideas becomes paperwork. Fewer statuses with clear transition rules and deadlines are better. If the first decision takes weeks, idea flow dries up.

Mistake 2: “idea is nobody’s”

If no owner is assigned, the idea hangs between departments. The owner doesn’t have to do everything but must organize validation, implementation and effect confirmation.

Mistake 3: effect “by eye”

People often write a nice number but forget the baseline and assumptions: which period, what volume, which rates, what exactly changed. Without that you can’t honestly compare ideas or defend the economic effect.

Mistake 4: confusing savings with cost shifting

Sometimes costs simply move from one line to another (or from one shop to another) without reducing the total. That can be useful for accounting but it’s not savings. The card should state clearly: “reduces total expense” or “reallocates within the budget”.

Mistake 5: closed after implementation and forgotten

Initiatives are closed at launch without waiting for effect confirmation. It’s better to separate “implemented” and “effect confirmed” and verify by agreed data over the observation period.

Mistake 6: rewarding quantity instead of results

Awards for the number of ideas encourage small, safe suggestions and inflated estimates. A better approach combines small recognition for useful ideas and separate rewards only for confirmed effects.

Short checklist before launching an initiative

Before sending an idea to work, spend 10 minutes on this checklist. It protects against two typical problems: “everyone agrees but nobody acts” and “implemented but effect can’t be proven”.

• Owner assigned and next step clear. One responsible person (not a group) and the next step with a deadline: “collect data for 2 weeks” or “test on one area by Friday”.
• Baseline and a simple effect formula exist. Metrics and the “before” period are defined (e.g., last 4 weeks). The calculation formula should fit on one line.
• Costs, constraints and risks considered. One‑time expenses (materials, changes, training) and ongoing costs (maintenance). Separately list risks: line stoppage, quality impact, safety requirements, supplier dependence.
• Short work plan with concrete executors. 3–7 tasks, each with a result and an owner. More tasks mean a mini‑project that needs separate project logic.
• Verification and decision rules set. How to confirm results (ERP, measurements, acts, quality report) and the control date. Fix the outcome immediately: implement, merge or reject with reason.

Mini‑example: if an idea promises “save 2 hours a day”, decide in advance how to measure it. Compare recorded setup times for a month “before” and a month “after”, convert saved time to money using an agreed rate, minus implementation costs.

Example scenario: from proposal to confirmed savings

On a production area they notice rising defects and material overspend. An operator logs the problem: what counts as a defect, on which operation it appears and from which month it worsened.

The initiative receives status “New”, the foreman moves it to “Under evaluation” and assigns an engineer as responsible. The team forms a hypothesis: tweak equipment settings and add a short check before batch start (one measurement step and a journal note).

Calculate before implementation so the debate isn’t by feeling but by numbers. You need three inputs: average defects per month, cost per unit (material + labor + disposal/rework) and expected reduction.

Example: 120 defective units/month at 6,000 KZT each. If defects drop 40% after change, expected saving: 120 x 6,000 x 40% = 288,000 KZT per month.

Then implement: 2 hours of training for the shift, update the instruction and start a 2‑week control period (responsible — foreman, support — engineer).

At verification, controlling compares 2 months before and 2 months after, accounting for output volume. After confirming the numbers, the initiative is closed as “effect confirmed” and the practice is rolled out to the neighboring area with the same instruction and controls.

Next steps: pilot, tool and process support

Start with a pilot in 1–2 departments where losses are clear and leadership is active (e.g., warehouse and production, or IT and accounting). Record a short 1–2 page regulation: statuses, response times, who calculates effect and who confirms savings. In the pilot, discipline matters more than perfect automation.

Minimal agreements that remove disputes:

• response time for initial feedback (e.g., 3–5 business days);
• single effect calculation template (before/after);
• verification rule (who confirms by which data);
• limit for status stagnation (e.g., 30 days without movement);
• weekly short review of the status funnel.

Choose tools according to maturity. At start a spreadsheet with cards and simple notifications is enough. When ideas grow, a portal or corporate service with roles and approval routes is more convenient. In companies where initiatives often require IT or ops tasks, ITSM sometimes fits.

Management usually needs three reports: status funnel (how many ideas are stuck and where), total confirmed effect for the period, and a list of top initiatives with reasons for success or rejection. Show these reports regularly and in a consistent format.

Automate without extra complexity: card templates, roles (author, expert, process owner, finance), deadline reminders and a separate “confirmed” field with date and data source.

When the pilot proves value and scaling is needed (integrations, analytics, unified approval routes), consider involving a system integrator. At GSE.kz (gse.kz) you can discuss support and implementation of such processes as part of system integration — especially if improvements touch IT, workplaces, server or data center infrastructure and it’s important to bring ideas to confirmed effect.