Digital Obeya Platform
Connect strategy and execution across all Obeya rooms
By Industry
Resources By IndustryResourcesDownside of a physical Obeya? A physical Obeya works for the people standing in it and everyone else gets a photograph of the wall and retold story of what was decided. iObeya holds the plan, the KPIs, the risks and the open decisions in one connected room, so the people who own the work are in the review whether or not they are in the building; thanks to having all digital Obeya rooms in one connected system on the Digital Obeya Platform™.
Head of Lean Agile Transformation Center of Excellence, Capgemini
Displayed side by side, so nobody has to hold the connection in their head. You can visually see relationships and trends. And the actions are tracked inside the same view.
Program and project teams, plant and area management, operational excellence groups, and the leadership reviews are all running on large touchscreens where the team stands, and from any desk if they are not right there right now.
Reporting shows the milestone slipped; the digital Obeya is where someone picks it up and the whole team can keep track of it.
The physical Obeya room is rarely the problem. Most sites already have the meeting, the wall, and the people participating in it. What breaks is that the wall stops being true the moment the meeting ends, and the information doesn’t travel to the next room and the next meeting. So the next review spends its first ten minutes establishing whether the picture is current.
In iObeya the boards and rooms are connected and up-to-date all the time.
Link a production room to the site-level room in iObeya and an issue raised at shop floor level arrives at the next tier with its context attached: the metric it came from, what has already been tried, and who owns it now.
The site review opens on what the shop floor actually raised, so its first job is deciding rather than reconstructing the issue.
In a physical Obeya the summary somebody rebuilds between meetings loses the details, the reason a problem mattered arrives as a line item and the next tier has to ask for it again.
The same board opens on the touchscreen where the team meets, on a laptop at another site, and on a tablet out on the floor. All able to access it at the same time and with the same rights to view and update.
A site leader three time zones away contributes to the review instead of receiving a version of it later.
Each metric on the wall in iObeya holds its current figure, its target, and the deviations opened against it, so a number going red is a starting point with something attached rather than a color.
The meeting spends its time on the two measures that moved instead of walking the whole wall to find and confirm they are accurate.
When a deviation is raised in iObeya it becomes an issue card with an owner and a date, sitting beside the metric it came from, and becomes an action card once the work to correct it has been agreed.
Nothing raised in the room leaves the room without a name assigned to it.
The parking lot at the bottom of the whiteboard did the opposite. An action written there stayed there, until somebody remembered to ask about it; sometimes months later.
At each interval checkpoint in iObeya the room reviews one interval and not the running day: what that hour was meant to produce, what it actually produced, and whether the gap needs an answer before the next hour starts. The interval is the unit of review, so an hour that fall short is visible while it can still be recovered.
Corrections happen inside the shift that needs them, and the daily review above inherits a much shorter list of things nobody could fix locally.
Without that, the shift is judged at the end of it. What went wrong at 9:00 in the morning surfaces at 14:00 in the afternoon, by which time the line has run five more hours against the same failing constraint.
Make a change an obeya board in iObeya and it updates for everyone at once, because what the team is looking at is the live object rather than an export of one. Someone standing at the screen moves a card, writes on it, redraws a lane, and the room watches it happen. Nobody takes an action to update the board later.
A workspace built for documenting a meeting can be beautiful and still be untouchable during one, because the cost of changing something in front of fifteen people is too high. iObeya is built to be handled live, at wall scale, by people who are not going to open a settings panel to do it.
Most obeya software stops at the edge of a single room: a good board for one team, with nothing carrying past its own walls. In iObeya, rooms connect, so an issue raised in a programme review moves to the level that can actually clear it, arriving with its context rather than as a line in somebody's summary.
The escalation logic is part of the model, not a convention the team is asked to remember. Which means the review does not open with a reconstruction of what happened before it, and the team reporting the original issue can see what became of the thing they raised.
A virtual obeya that carries a site's weekly decisions has the same standing as any other system the business cannot run without, and it should be handled that way. Deployment model, access control, single sign-on, governance of who can change a board structure, support that answers when a review is due in twenty minutes.
This is the part that separates a rollout from a pilot. A tool that is delightful for one enthusiastic team and undeployable across forty sites has not solved the problem; it has moved it to whoever is asked to scale it. Enterprise readiness is a product decision made years earlier.
iObeya x Vaillant-Belper Plant-CustomerTestimonial
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.