Value Stream Mapping SIPOC

I was this week in a workshop where we were introduced to a nice set of lean tools. 5 x why, fishbone and kano model were visited briefly, but most of the time we concentrated on value stream mapping. To share the knowledge I will tell you about it in more detail.

We used SIPOC model. The abbreviation comes from the words

• Suppliers
• Inputs
• Process
• Outputs
• Customer

In this example we were creating a breakfast toast for one of our family members. So customers in this case were husband/wife or child.

Outputs can differ if the different customers (or customer segments) have different needs. In our case the child wanted a toast with jam and special attention that the toast isn't burnt. Spouse wanted a cheese sandwich and all the facilities need to be cleaned. No crumbs.

Inputs are all the things we need in the beginning. In the toast example we need a plate, knife, jam, cheese, butter, bread (two different types) and heat.

All the inputs have a supplier. In this case we were thinking where in our kitchen they are located. Not really who made the knife. But the knife is in drawer, butter and jam in the fridge. Heat is provided by the toaster and plate in the cupboard.

Finally, when these pretty evident things are covered we can start to think about the process. WHAT activities are needed in order to create the desired outcomes? We first make a line of post-it notes that define the activities. We can label the different activities with different colors. In our case we used green for processing, yellow for transportation, blue for storage and red for inspection.

Each WHAT phase is broken down into HOW parts. For example toasting phase can be broken down into activities of setting the temperature, putting the bread into the toaster, setting the toaster on and the bread being heated.

We used heart shaped post-its to mark all the value adding phases. In any process there are activities that add value, activities that are necessary but not value adding and thirdly activities that are waste. By identifying these we can measure how much of our activities actually are value adding compared to the whole time used. This performance indicator is known as Value Added Ratio (VAR) or Process Cycle Efficiency (PCE).

PCE = Customer Value added time / Process Cycle Time

As in our example the spouse explicitly wanted to have no crumbs, we tracked all the parts where crumbs could be produced. These phases were connected with a string. This way we can only concentrate on improving those parts to minimize the amount of crumbs.

Finally it makes sense to identify your customer touchpoints. You can goof off in many parts (well, better not to too much..) but you should make sure that you handle the customer touchpoints with care. Think about what happens before, during and after the touchpoint. How does the customer feel?

There you go. A crash course to value stream mapping using SIPOC method. If you want to learn more, I encourage you to find a lean consultant or simply try it out. I know I will.

Walking Through a Process

I've recently started working part-time as an internal tutor in my organization. I could best characterize the tutor pool as having internal (agile) coaches available for different continuous improvement activities. Main focus is on process improvement and facilitation.

I think the tools and techniques are quite sophisticated. If you are familiar with Lean, you probably know the fishbone and 5 times why. This time me and my colleague facilitated a process walkthrough using the OPERA technique. We scheduled a three hour time slot for the event.

Fishbone

As we are both really new tutors, we went through the exercise before with our mentors. The person responsible for the development of the particular process was also involved in the preparations. The ultimate goal was to update the whole process. But for our session at hand we set our goal on better understanding the current status.

My colleague had done a very good script for the session with timings. We started with a short introduction (15 minutes). The participants also listed their expectations for the meeting. All the expectations were surprisingly well aligned: more understanding about the current status.

In OPERA technique people first write down their own ideas (O) on post-its. Everyone was instructed to write 3-5 things that currently work and similarly topics that could be improved. For this we gave them 10 minutes.

Time-Timer

Next, the participants paired up (P) and discussed their ideas with their pair. For this we gave them 15 minutes. If you visualize the passage of time, people can self manage their timing and you don't need to hurry them. If you can get your hands to a Time-Timer, that's great, but if you don't have one available, you can use for example Online Stopwatch. The countdown works well and you have an alarm in the end.

After the pair work, we collected the ideas on the whiteboard and the pairs explained (E) their findings to the others. For this phase we had reserved 35 minutes. In addition to positive findings and improvement topics we also had a category for ideas.

After collecting the ideas on board we discussed possible themes that could be identified. In 'by the book' OPERA we would have had ranking (R) and arrangement and actions (A), but in our case we pretty much skipped those.

Opera, not OPERA

From the results we crafted a sort of hypothesis for what the current status was. To test this hypothesis, we needed to go check things in practice. In Lean, you would use the principle Genchi Genbutsu or do a Gemba walk. In our case we will examine the current status by interviewing the process actors.

We had done a lot of ground work with the interview questions, so this part didn't take long. But if you start from scratch, be prepared to spend considerable amount of time on this. With a predefined set of questions you get better data can identify patterns from the answers.

The interviews will take a lot of time, but during the meeting we decided who were going to be interviewed and the team split into pairs. Scheduling the interviews were left as an action point and we only agreed on the deadline date. We will have another workshop session when the interviews are done and we can look at the results together.

Photo by Artur Rutkowski on Unsplash

Proper Technique

Again, I'd like to share some real life experiences and thoughts they have provoked. I learned how to swim at the age of seven. Since then I have been able to float on the water and transfer myself from one place to another. But I have never been very fast. And some of my friends have politely described my swimming style either as resembling a beater or that I'm "trying to crush the water".

This week I attended my first swimming technique course. We were swimming just freestyle and practicing the breathing technique. We were in the pool and the instructor told us what we could improve. I'm not sure the results were tremendous right away, but with every pool length something was improved. Towards the end of the session, I felt like I had learned to swim in a new way. (Interesting fact: only 10 % of the propulsion is produced by legs. And for amateurs not even that much.)

There are some important lessons to draw from this. Coaching, mentoring and teaching are efficient ways to share knowledge. If you don't know the techniques, you could seek guidance from a master. It's not embarrassing, it's wise. The second thing to note is that you will easily become blind to your own performance. An outside observer with a fresh pair of eyes can help you notice new things. And finally: only practice makes perfect. Now, after the teaching, I have a faint idea of what the proper technique is, but without practice I will just regress back to my old style. 

And the same applies also to Agile software development. Get your team a Scrum Master or an Agile Coach. Or if you are such person, consider seeking guidance from a more experienced practitioner. Mastery is an asymptote which you can never reach. But you can always get better. 

Perfect road is always ahead