The workshop ends well. The wall is covered in ideas, somebody photographs it, and the room gets booked for something else. A few of the actions land. Six months on, the old way is back, and nobody can say exactly when it returned. iObeya keeps the whole loop on the boards your teams already stand in front of every morning, so what someone noticed on Tuesday is still visible, still owned, and still moving in March.
Supply Chain Director, Chantiers de l’Atlantique
Somebody spots an issue; the team works it back to a root cause, puts the change in and updates the standard. The same cycle turns whether or not anyone has given it a programme name this year.
Operators and team leaders raise and close most of the issues. Improvement managers, coaches and site leaders see the whole picture. It runs on the shop floor, in the office, in engineering, and at several sites at once.
Collecting suggestions is the easiest part of the practice and, on its own, close to worthless. Identifying and resolving the underlying root causes is key.
Improvement work rarely dies in one place. It leaks. The suggestion is in somebody’s notebook, the analysis is in a deck, the workshop output is on a phone, and the standard is behind a login nobody remembers. No one actively decides to stop, and yet it stops. iObeya keeps all of it on the boards where the work is already managed.
Depuis le terrain, un bureau ou même en pleine AIC, chacun peut créer directement dans iObeya une carte pour consigner une idée d’amélioration ou un problème observé. La carte conserve l’auteur du signalement, ce qui a été observé et le lieu où l’observation a été faite. Elle peut être ajoutée aux mêmes panneaux que ceux utilisés par l’équipe pour ses routines et ses réunions quotidiennes.
L’équipe voit ainsi immédiatement ce qui a été signalé et ce qui n’a pas encore été pris en charge. Le sujet reste visible là où l’équipe travaille, sans dépendre de la mémoire de quelqu’un pour le relancer.
When a card needs real analysis, the team works it on the board itself: PDCA cycles or an A3, laid out in sequence with the evidence attached to each step.
Anyone joining halfway can read how the team got there, which makes the analysis reviewable rather than merely presentable.
Without iObeya that reasoning ends up in a slide deck built afterwards, and a deck written backwards from the answer cannot show where the team actually was at step three.
Each event gets its own room or board: the scope, the baseline, the daily output, and the actions that have to survive past the last day.
Follow-up actions stay live once the team goes back to the day job, instead of ageing quietly in a spreadsheet nobody reopens.
Nobody has to reassemble the workshop afterwards from photographs of a paper wall and a facilitator’s memory.
Update the standard on the board the team already works from, and the new method is in front of them the next morning.
Without that quick turnaround in iObeya, the gain drifts back slowly, and the same problem gets solved a second time by a different team.
If the standard lives in a controlled document on another system, the change reaches people through a training session weeks later, if it reaches them at all.
A continuous improvement system that sits beside your operating rhythm will always be the second thing anyone opens on a bad morning, and the first thing that goes stale. In iObeya the improvement sits on the same board as the performance number it came from, in the same room the team meets in every morning.
A deviation that keeps returning on a daily management system board becomes an improvement item without leaving the room where it was raised. No export, no parallel register, and no monthly reconciliation between two systems that are supposed to describe the same factory.
Most continuous improvement tracking software can tell you how many items are open. Fewer can tell you whether any of them have moved this month. Almost none can take you from that count back to the board, the team, and the problem that started it.
A leader opens one view, sees improvement activity across teams and sites, and clicks straight through to the board where the work is happening: the same board the team stood at this morning. The number and the work are one object rather than two systems that have to be made to agree before a review.
Enterprise continuous improvement software has to survive contact with a plant that has done it their own way for twenty years and sees no reason to stop. iObeya carries the improvement model itself as a template: the card types, the problem-solving format, the event structure, the standard-update step, so a new site starts from the model instead of inventing a local one.
What one plant learns stays legible to the others because it was recorded the same way, which is the difference between fifteen sites improving and one company improving. Local teams still adapt what sits on the board. What does not drift is the method underneath it.

Vaillant Group x iObeya Video Testimonial

Sanofi x iObeya Video Testimonial
It is the practice of making small, structured changes to the way work is done, repeatedly, by the people who do the work. Rather than one large project, it is a routine: problems are surfaced where they happen, worked to root cause, and the better method becomes the new standard.
Kaizen is the best-known form of continuous improvement, originating in Japanese manufacturing. In everyday use it means two things: the general mindset of improving a little at a time, and the time-boxed improvement workshop a team runs on a specific problem with a defined scope.
Continuous improvement is the broader practice. Kaizen is the form most companies borrow from, and the word most often used for the focused event inside it. In practical terms, a company runs continuous improvement as a routine and runs kaizen events as part of that routine.
Software that gives the improvement routine a permanent home: somewhere to raise what people notice, work problems through in the open, run events, and hold the standard that results. The point is not storage. It is that the work stays visible after the meeting ends.
A suggestion system collects ideas and routes them for review. That is the easiest part of the practice. The hard parts are working a problem to root cause, running the event, and holding the new standard afterwards, and those are where most improvement effort leaks away.
Usually because the standard was never updated where anyone would see it. The fix lives in a workshop output or a document nobody opens, so the old method returns by default. Updating the standard on the board the team uses daily is what makes a gain durable.
Yes. The card types, the problem-solving format, the event structure and the standard-update step are carried as a template, so a new site starts from the model instead of inventing one. What one plant learns stays legible to the others because it is recorded the same way.
The boards are rarely the gap. Continuity is. A paper board is true at the moment the team stands in front of it and stale by the next shift, and the analysis behind an improvement usually leaves the board entirely once someone writes it up.