Skip to Content

Gemba in a Virtual World

Gemba is a Japanese term that means “the actual place” or “the real  place”.  Gemba is very familiar to Lean Practitioners as the tool to use when you want to study how a real user is engaged in an  activity and uncover where the opportunities are for adding value, or  removing waste, from his/her job. 

Just go to where they work and  watch what they do.

But what exactly does that  mean if you are a Software-as-a-Service (SaaS) provider like b2b2dot0  and your users are all over the world?

Recently, the value of Gemba hit me in between the eyes during a site  visit to one of our client’s customers in Richmond, VA… which  inspired today’s post.

First a bit of background.

b2b2dot0’s  business model is somewhat complicated by the fact that while I do  visit each and every one of our clients, they aren’t the ultimate users  of our service.  Their customers are.  To be sure, while our clients  (and their SAP systems) set the policies for, and the scope of, what their  customers will be able to do on our website, our clients aren’t the ultimate users of our  service.  So in true Agile spirit, we really need to get our client’s  customer’s feedback on the value of our service to them!

We’ve  settled on a variety of ways to gain insight into our client’s  customers use of the b2b2dot0 service…none of which included Gemba  until a few weeks ago!

  1. Customer Focus Groups – I wrote about our love affair with Customer Focus Groups earlier this year.  We run  these during our implementation projects as well as during the  introduction of new capabilities to our service.
  2. Online Customer Surveys -We host customized (SurveyMonkey)  surveys for each of our clients and get several responses per week. 
  3. Online Issue Logs – Every page on our website is linked to  our Central  Desktop collaboration portal’s issue log.  We normally get quite a  few submissions via this route during our implementations, less so once  we’re in production.
  4. Application Logs – Our application logs capture every user  transaction and we get emailed when abnormal conditions exist.  I wrote  about one such example in a previous blog posting entitled “Two mouse clicks in Shanghai…”
  5. Google Analytics – We get a huge amount of customer  intelligence from Google (probably too much).  You can learn a little  more about how we use it here.
  6. Customer Advisory Board – With their blessing, I’m beginning  to establish a direct relationship with some of our client’s customers.   I hope the number of people that I can personally reach out to, and get  direct feedback on our current performance as well as on our ideas and  plans, will grow in the coming months.

Which leads me to my Gemba experience in Richmond.

We were all  wrestling with a customer requirement called “Back Order Report”.  It  seemingly was a simple requirement.  Provide a report to our client’s  customers that showed all orders that had been placed but not received.   This way, our client’s customers would know where to go in order to  troubleshoot a late shipment. 

  • If it was truly on “back order” (ie, no scheduled delivery date)  than they could call our client and ask them what the story was.
  • If the order had a delivery date (but not shipped yet) and they were  happy with that date, than they knew they just needed to be a little  more patient.
  • If the order was shipped, and hadn’t arrived yet, they could inquire  as to the status of the shipment from the carrier (through our website). 
  • If it shipped, and the carrier shows that someone in our client’s  customer’s organization signed for it, they could start their  investigation in their own backyard. 

The complexity of the solution all revolved around presentation  of the data.  Technically, SAP has all of this information and we  already retrieve it in one way or another throughout our application.   The question was: what’s the most useful way to present the data?

Therein  lied our #1 challenge.  We really didn’t know what problem the user was  really trying to solve!  We knew that they were asking for a  “backlog report”.  That’s what they told us in our Focus Groups and  subsequent phone conversations.  But did they really need what  they were asking for, or was there something else going on here?

Enter  Gemba. 

I took the two hour drive from Raleigh to Richmond on a  Friday morning and spent 3 hours with the customer in their  facility…and boy did I learn a lot!

  • I learned that they were having usability issues with our  application because they set their screen resolution to the “over 40”  setting which is 800×600 as opposed to our recommended 1280×1024 (I  could have learned that from Google if I had known to ask the question)
  • I learned that the response time on accessing one type of report was  so bad that they hated using it.
  • I (re)learned that the challenges of introducing a new process  aren’t as much about learning the new process as they are about letting  go of the old ones.
  • I also learned that they weren’t interested in “backorders”.  What  they were really interested in is getting an answer to the following  question:
“When can I expect to get Part # XYZ?”


Hearing that question made all  of the difference in the world, and it wasn’t until I watched them in  action that we uncovered the real scenario.  Our client’s customer had  one of their customers on the phone who was asking about the  status of a specific Part# XYZ, that they (our client’s customer’s  customer) had ordered.  

Now, with the right question  in hand, we’re able to come up with a slick solution to the problem,  and  have it ready to roll out into production in days.

That’s  the power of Gemba!

The moral of the story is simple:

“just because we can live in a virtual  world, doesn’t mean that we should” 🙂


You must be Logged on to comment or reply to a post.
  • We can learn other things from lean also. Engineers are good at building stuff, if only we know what our customer wants. Our customers are pretty happy to tell us, but the communication is usually missing some critical information.

    When the customer asks for the back order report, I would look for two additional pieces of information from them.
    –     What value they get from the back log report.
    –     How they would measure success when this requirement was fulfilled.

    It may be necessary to go-and-see to get these questions answered, but you may find that much of the time you can communicate a little more virtually and get the same information.

    Over time you may find that the requirements you get from your clients will change. They will be less specific with respect to how you need to do things and they will articulate value in broader terms. You will gain the flexibility to innovate in ways your customer never imagined and deliver value to them faster and at a lower cost.

    • Hi Russ,

      Thanks for your comments.  Unfortunately, the epilogue to this story isn’t a happy one from a Lean perspective.  While our client and their customer were both adamant about wanting this backlog report in order to become more efficient handling customer inquiries…and to replace existing spreadsheets…neither were willing to change their behavior once the feature was made available.

      It’s almost as if we should have written a “contract” that said, “if we develop this capability that you are asking for, you will no longer be able to do it the old way.  If you don’t sign this contract, we won’t make the investment.”

      Sometimes people say things that they think they really mean at the time, but it turns out that they really didn’t.


      • Ouch, that is a shame. I feel your pain having been in that position too many times in my past. I wonder if things would have been different if the customer had been challenged to articulate where they get value from the new requirement. It could have died on the vine (if there was no real value as may be the case) or they may have been compelled to move forward based on their own value proposition.