We are very honored to publish another case-study on the successful use of SwiftKanban for improvement of Procurement Process for the Brazilian organization Poiesis. The presentation shared in this post was prepared and presented by Clarinha Prado, a consultant with Gigante Consultoria, Brazil. Clarinha has over 20 years of Business Analysis and IT consulting experience in a variety of fields, especially the financial sector. Thank you, Clarinha, for this excellent presentation!
Usually, Kanban writing lives inside software teams. Sprints, engineering flow, dev boards, the usual. Which means most people assume Kanban only works where the “work” is code moving through a pipeline.
It doesn’t. Kanban works anywhere work has a queue.
Procurement has a queue. So does HR. So does legal review, IT ticketing, finance close, marketing production, and a dozen other service functions running most enterprises today. And in every one of them, the same symptoms show up: nobody can see the queue, everyone chases status, and the rules that govern decisions are somewhere between “in someone’s head” and “in an email from 2019.”
This is a story about a Brazilian NGO that ran into exactly those symptoms in its procurement function — and used Kanban, first physically and then digitally in SwiftKanban, to fix them. The case was originally shared with us in 2014 by Clarinha Prado, a Business Analyst and IT consultant at Gigante Consultoria with 20+ years of experience across business analysis and IT (deep in the financial-services sector).
We’re retelling it here because the pattern still works — and, in a 2026 environment full of AI tooling and rush-to-digital reflexes, the lessons about how to sequence the change might matter more than they did a decade ago.
About Poiesis
Poiesis is a non-governmental organization in São Paulo, Brazil which promotes socio-cultural and educational development, focused on project management in cultural spaces. They were running project management inside cultural spaces (museums, libraries, cultural centres).
It’s a more complex operating environment than it sounds: multiple cultural projects running in parallel, funding cycles mixing public and private sources, and a procurement function that has to keep everything supplied — from publishing runs to event production to facility upgrades.
Whatever the mission looks like publicly, internally it looks like a queue of procurement requests moving through the same handful of stages, day after day.
The procurement problem
Poiesis’ procurement process faced challenges such as lack of transparency, delays in the procurement process, lack of understanding of business rules, among others. They engaged Gigante Consultoria, where Clarinha works, to help make improvements to its Procurement Process.
Before the Kanban work, Poiesis’s procurement process had three structural issues. None of them were unique to Poiesis — every service function anywhere in the world has some version of these.
One: no visibility.
Nobody outside procurement could see where a request was in the queue. Requestors chased updates over email. Procurement spent more time answering “where is my request?” than actually moving requests along. The most valuable people in the process were burning cycles on status calls.
Two: unclear where the delays actually happened.
Requests sat for days or weeks at bottlenecks nobody could name. Without a visible queue, nobody could distinguish a structural delay (“this stage is always slow”) from a situational one (“that specific person is out this week”). Every conversation about slowness turned into a debate instead of a diagnosis.
Three: rules that lived in people’s heads.
The business rules governing procurement decisions — what needs which approval, what thresholds trigger what path, what documents are required — weren’t visible anywhere. Different requests got different treatment depending on who was processing them. On top of the delays, this created a layer of perceived unfairness that made the whole thing worse.
In short: a process running on tribal knowledge, no shared view, no flow data. If you’ve worked in any large service function, you’ve seen this.
After an initial analysis of the challenges faced, Gigante decided on the use of Kanban to help them improve the overall procurement process. In Phase 1, they implemented a physical Kanban system; in Phase 2, after an exhaustive comparison of several electronic Kanban tools, they selected SwiftKanban to automate the Kanban system.
The presentation below outlines their journey:
Kanban for Procurement – A SwiftKanban Customer Case Study from Mahesh Singh
Phase 1 — Physical Kanban, deliberately
Gigante and Poiesis’s first move was the right one, and it’s the one most modern teams skip in 2026: physical Kanban board first, electronic later.
The reasoning is simple. Tooling without behavioural change is an expensive process. If a team doesn’t understand why they’re limiting WIP, or why they’re making policies explicit, or why they’re visualising the queue — putting a tool in front of them just gives them a nicer place to be confused. Get the discipline running on a physical board first, where the constraints are obvious and the team internalises the practice; then move to electronic once they’ve earned the tool.
Three things changed within weeks of putting up the board:
- The queue became visible to procurement, requestors, and managers for the first time. Nobody had to ask “where is my request?” — they could just look.
- Bottlenecks became specific. The team could point at the column where work piled up, which was rarely where anyone had assumed. That specificity turned arguments into fixes.
- The rules became explicit — because someone had to write them on the board. Sticky notes forced the shared vocabulary that tribal knowledge had been resisting.
Not one of those changes required software. All three required the discipline to work with a visual system every day.
Phase 2 — Moving to SwiftKanban
Once the physical board had done the cultural work, the team was ready for the electronic version. Gigante did an exhaustive comparison of electronic Kanban tools and picked SwiftKanban to automate what Poiesis had already built manually.
The move to digital unlocked things a physical board couldn’t:
- Distributed access. Managers and remote requestors could see and interact with the board without being in the same building.
- Analytics on flow. Actual cycle time data, throughput trends, aging cards. The physical board could show you where work was stuck; the digital tool told you how long it had been stuck and whether that was normal.
- Audit trail. For an organisation with public funding and procurement accountability, the audit trail wasn’t a nice-to-have. Every card carries its own history.
- Workflow rules baked into the tool. The explicit policies from the physical board now lived in the system — WIP limits enforced, transitions gated, approvals routed automatically.
The transition itself was smooth precisely because the physical phase had done the cultural work first. Teams that skip that phase usually spend the first six months of their SwiftKanban implementation trying to force a change in behaviour they should have made before the tool showed up.
What changed for Poiesis
Three qualitative outcomes, in order of impact:
Transparency was restored. Requestors could see status without asking. Procurement stopped fielding chase emails. Time freed up for actual work.
Cycles got shorter. Once bottlenecks were visible and named, they got addressed. Whether the fix was a policy change, a re-sequenced approval, or a resourcing decision, the team could see what to attack first — instead of guessing.
Business rules became consistent. Policies were explicit, written, and applied the same way regardless of who was processing a request. The perceived-unfairness problem dissolved with the visibility.
Specific cycle-time numbers were shared in Clarinha’s original conference presentation but aren’t reproducible here. If you’d like the underlying metrics, they’re available on request from Gigante Consultoria.
Why this story is worth retelling in 2026
Three reasons.
First — Kanban isn’t used efficiently for procurement
Twelve years after Poiesis’s implementation, most procurement teams still run on tickets, spreadsheets, and tribal knowledge. Every symptom Poiesis had is visible in enterprise procurement teams today. The pattern hasn’t propagated because most Kanban writing still lives inside software teams. This is one of the highest-leverage applications of Kanban that nobody’s talking about.
Second — the physical-first pattern is under threat.
The temptation in an AI-tooling-rich 2026 is to skip straight to digital and let the tool “handle it.” Don’t. AI can generate a workflow diagram in 30 seconds; it can’t build the shared team language that came out of Poiesis’s physical-board phase. The sequencing — behaviour first, tool second — still matters, arguably more than it did in 2014.
Related reading: Why Kanban matters more in the AI era
Third — Kanban’s principles work in any service function.
Visualise the work. Limit WIP. Make policies explicit. Manage flow. Improve collaboratively. These are as true in a procurement team as they are in an engineering team. Kanban in procurement is one of the cleanest examples of Kanban outside software. But the same lift applies to HR ticketing, legal review, IT operations, finance close, and any service function where work moves through defined stages.
How to apply this to your own service function
If any of the symptoms in the “procurement problem” section above sound familiar, the play is roughly:
- Map the current flow on paper first. Not in a tool. Write the columns (request states) that work actually moves through — not the ones the process document says it moves through.
- Put it on a physical board where the team can see it every day. Sticky notes, index cards, whatever. Update it in a daily 10-minute standup.
- Watch where cards pile up for two weeks. That’s your bottleneck. Not opinions — evidence.
- Make one policy explicit at a time. Not all of them at once. Start with the highest-friction rule.
- Only move to digital tooling once the discipline is running. Then a tool like SwiftKanban gives you distributed access, analytics, audit trail, and enforced workflow — without the “we bought a tool and nothing changed” pattern that kills most implementations.
That’s the shortest version of the Poiesis playbook, applicable to almost any service function.
In case you have any questions, you can write to us for Clarinha’s contact information at sales@digite.com! Thank you, Clarinha for an excellent presentation. If you are interested in hearing the story directly from Clarinha, please let join us for an interactive webinar with Clarinha that we plan to do shortly. Do let us know.
FAQ
Can Kanban be applied to procurement teams?
Yes. Procurement is a flow problem — requests moving through stages from initiation to fulfilment — which is exactly what Kanban is designed for. Poiesis is one example; the same principles work in HR, legal review, IT operations, and any service function with a queue.
Should we start with a physical Kanban board or go straight to digital tooling?
Start physical. Move to digital once the discipline is established. Tooling without behavioural change is expensive process theatre — you’ll spend six months trying to force adoption of a practice you should have built first without the tool.
What are the main symptoms that a service function needs Kanban?
Nobody outside the team can see request status; delays are debated instead of diagnosed; and the rules governing decisions live in people’s heads instead of in shared, visible policies. If two of those are true, Kanban is a high-leverage move.
Is SwiftKanban suitable for non-software teams like procurement, HR, or operations?
Yes. SwiftKanban is designed for visual work management across any function with a queue. Poiesis used it in procurement. Other customers use it in Product Management, IT Operations, PMO, and Marketing.
How do AI and modern tooling change this pattern?
They don’t change the sequencing — behaviour first, tool second — but they do raise the cost of skipping the behaviour phase. AI-generated workflows are easy; shared team language is not. Teams that lean on AI to compress the discipline-building phase usually pay for it during rollout.