A reader, Dan, asked a great question on the MoveToHealthcare.ning.com site (since closed), re-used here with his permission:
I recently attended a 2-day Lean Healthcare Training and Project Report Out session. When they covered the VSM material, I was surprised at the simplicity. Their VSMs were not VSMs as I had come to know in the mfg environment….detail on times, computer screens req'd, defect rates, etc. Not a bad thing, just surprised me – and perhaps wasn't needed.
There were none of the VSM conventions of customer and suppliers on the maps, no distinction of information vs. pt/material flows. Rather, they were very basic process maps just outlining the steps, sequence and who the person or functional area was for that step, as well as what was VA vs. NVA.
VSMs should alway be developed according to purpose of course. Perhaps there is just so much low hanging fruit that the additional detail was of no interest at that point. It just seemed to me that there was a lot of info that would've been helpful in understanding the performance of the process that no one gathered.
So I wonder, is this typical of hospital process mapping?
By the way, I was very impressed at the speed and breadth of which Lean is being deployed at this facility. They have great Lean leadership and a lot of enthusiasm. It served to reinforce to me that this is what I want to be doing! I was fortunate to have been invited to attend.
Here was my response and you can check back on Ning to see if there are more comments or you can add comments here for the larger blog audience:
Hi Dan — there's probably a ton of variation in how VSM is being used in healthcare and that's probably not completely unlike manufacturing practice.
I've seen cases where hospitals do process maps and call them VSM because that's the trendy term.
To me, to be called a VSM it must:
1) start with a customer request — patient or physician typically. Doesn't need to be the typical factory looking icon
2) have both “material” (or patient) flow AND information flows. Sometimes the “product” is information (such as a referral request), but treat that as the product (creating an appointment) and then also document the information flows involved in creating that information (phone calls, computer systems etc.)
3) focus on both the actual process steps AND the waiting time in between. VSM analysis focuses primarily on the “white space”
4) have some amount of data that comes from real gemba observation AND information systems. Hospitals are often very lacking in real data that you would want for a VSM.
So long story short, I think what you saw was not best practice and also not really typical. But not unheard of.
Also, Cindy Jimmerson has a book coming out from Productivity Press real soon:
Value Stream Mapping for Healthcare Made Easy
She certainly teaches more along the way you and I are suggesting, Dan, with the information flows and data boxes, etc. Her book has A LOT of examples of real value stream maps.
It's also taught that way in the LEI course on Value Stream Mapping for Healthcare:
(FTC blogger conflict of interest disclosure: the book link and others on this blog are Amazon Affiliate program links, for which I receive a commission on purchases. Cindy's book is published by the same publisher as my book. Also, I am an employee of the LEI, the provider of the course).
What do you think? Please scroll down (or click) to post a comment. Or please share the post with your thoughts on LinkedIn – and follow me or connect with me there.
Did you like this post? Make sure you don't miss a post or podcast — Subscribe to get notified about posts via email daily or weekly.
Check out my latest book, The Mistakes That Make Us: Cultivating a Culture of Learning and Innovation:
Unfortunately, too many efforts at value stream mapping and at teaching value stream mapping are designed to minimize the pain and keep it simple. But that's not the goal.
Here's my stated purpose for any mapping: the goal is to develop a COMMON understanding of current reality.
That's it. This is difficult. The map isn't the goal. So many finish the map, unimpressed, and wonder why it was worth it. It probably wasn't if the discussion, debate, and heated arguments about what is really going on and WHY then you really didn't move into a state of common understanding.
Mark lays out well some of the common things people skip over. The one that is really frustrating is not including both physical workstream flow AND information flow. The information flow is often hard. It often includes a combination of technology and personal interaction. Many problems of flow and coordination are more because the information flows are broken, not the work flow. So if we don't look at the information flow because "it's too hard" or "too messy" how will we ever fix it.
In my experience, stay focused on the purpose of a map, not it's technique. If you do that, it will all turn out OK. Maps themselves hardly ever tell you anything. It's the discussion and understanding of the map that reveals the opportunity.
Best wishes,
Jamie Flinchbaugh
twitter.com/flinchbaugh
Not surprising that some (many) find the application of VSM to be frustrating.
I think in many cases VSMapping has been used as an tool for the consultant to get up to speed.
I think some also believe that VS Mapping is special compared to other types of process maps. It isn’t and is often worse. I have seen a consultant lead an ED team that came up with three different value streams in the ED. This doesn’t make sense to me and I think that the three different value streams indicate either the misapplication of the tool or incompetency with the tool.
I am just getting my feet wet in healthcare, coming from manufacturing, so this topic is spot on for me.
I’ve done many VSM’s in manufacturing and have been developing my own concepts for healthcare. I believe the types of waste are the same but have different implications. In manufacturing we buffer waste/NVA with inventory, in healthcare these wastes are buffered with waiting time. So as related to VSM’s, I changed the Inventory between processes with Waiting (triangle with a “W”). I’ve had many discussions having to discuss how Inventory adds to lead time to customer, whereas waiting time for the patient is immediate delay in service delivery to the patient.
I agree with Mark on the necessary content of a VSM.
I also agree with Jamie. VSM’ing is painful for the subject matter expert, as it seems slow and laborious. Through this process though is where the good discussion happens and best ideas for future state are developed. If the current state VSM isn’t complete then its more difficult to identify areas of improvement and even if you do, then its difficult to quantify the improvement.
I somewhat agree with Anonymous… processes in healthcare are less standardized, the doctors, nurses, etc have unique ways of doing things. So it is possible to have different versions of a VSM for non-standardized process flows. This is a real issue in healthcare. I have no issue in mapping out the different “current states” and then the first round future state can be a standardized “current state”.
A “VSA” (Value Stream Analysis) was done on the ED a month or so before I started. The outcome was a bunch of stickies with lines drawn all over the brown paper…there was an attempt at collecting data but only a few peices were filled in. I’ve come to dislike the term “VSA” because the analysis should only be done when the VSM is completed.
I am engaged in these topics, so I appreciate any other feedback or information related to Lean in Healthcare.
Best Regards,
Phil
Phil – good luck on your new adventures in healthcare. Thanks for reading my post and I hope you find more that’s useful on my site.
Mark
A question I received from a reader:
My thoughts:
I think what makes it a process flow analysis vs. a VSM is the level of detail. A value stream map should be very high level. At a high level, there shouldn’t be as much variation in the flow. So, one strategy is mapping at a high level… the other strategy is to map a particular type of patient flow that’s representative of the over all process / value stream.
But, rather than worrying about that or whether there are timeframes or not, I’d think about what problems you’re trying to solve. Is the data helpful? It might not be easy to get timeline data (or it might be highly variable).