Lessons Learned from Bhutan and Nepal: Part 2 – Process Thoughts about Digital Transformation
In this age of digital transformations and the digital BA, data matters.
Without data there would be no big data, no data mining, no machine learning or predictive analytics. No AI. Nothing digital to transform. So yes, we have to focus on data. But what about poor process, once the king of projects, now often relegated to an afterthought? We commonly use to data improve processes. With better data, many cumbersome processes can be automated and improved beyond recognition. But process in and of itself still matters.
The importance of good processes was highlighted for us on a recent trip to Nepal and Bhutan. Getting into Nepal was beyond difficult and frustrating. To enter Nepal from the US you need a visa. Many countries require visas, and the processes to obtain those visas vary in the degree of difficulty. But Nepal was unique. We applied for the visa online, so they had our data. But there was no process for doing anything with that data. When we arrived, the fact that we had applied was irrelevant. We waited for nearly 2 hours in the same lines as everyone else. Once we got in, we really enjoyed our visit to Nepal. But the entry process was pretty awful. Bhutan, on the other hand, was a breeze. So here are 5 process lessons learned from this trip that apply universally.
Lesson #1: Before we can improve a process, we need to understand how it works today.
As much as we’d like to jump in and make a process better, we need to understand the current way things are done. It sure would be tempting to send some business analysts to “fix” Nepal’s visa problem, but there’s way too much we don’t know about why things are done the way they are. We need to understand how process works, as well as workarounds, exceptions, and little tidbits that make the process better for the people doing the process, if not for the customers and the entire organization. We also need to be aware of the personal, practical, and political reasons things are done as they are. We suspect the immigration officers in Nepal were as tired of the long lines as we were. We suspect that they would have loved to double the number of agents and to have better automation. We have no idea of the constraints and pressures they felt, and without that understanding, the process cannot be improved.
Lesson #2: A process map helps.
The second part of the trip was Bhutan, and one of the Bhutan activities was a hike to a monastery called the Tiger’s Nest. We posted a photo in Part 1 of this article. It sits perched on a ledge in the middle of a mountain and requires a 3,000 ft fairly vertical climb to 10,000 ft. Given the altitude and the age of everyone in our group (over 50), it caused a certain amount of anxiety, even though we were all physically fit. Some of us watched YouTube videos of the hike, but those hikers were all much younger than everyone in our group.
The night before the hike, our Bhutanese guide called a meeting to prep us for the next day’s hike. To our delight, he brought out a flip chart and drew a graphical depiction of our hike—a kind of process map! Palee explained the different levels, where we could get tea, where we could take the most scenic photos, where there was a dirt path and where there were steps, and importantly, where the few restrooms were located. We still had some trepidation but felt much better prepared.
Lesson #3: Process maps are usually incomplete.
But even the best of process maps doesn’t prepare us for all the exceptions. There are often unexpected forks in the path and choices that have to be made. It would be great to learn a process by reading existing documentation, but it may not be up-to-date. It probably won’t have all the exception paths. It certainly won’t have the workarounds that experienced staff know and love. If we rely on documentation alone, we might go astray. As helpful as our guide’s process map was, it did not prepare us for how we would react to altitude, for the numerous forks in the path, for how to share the path with horses, nor the hordes of hikers on the same hike.
Advertisement
Lesson #4: A guide makes a process easier.
The first decision point was whether to hike or to ride a horse to the first level. Since one person chose the horse, our guide was unavailable to steer the rest of us through the other exception paths. As we wrote in Part 1, three of us in our group of eight were ahead of the others when we came to our first fork in the road. Which way to go? Go with the flow of course and the flow of hikers in front of us chose the right-hand path. It turns out it was a big mistake. It was a terribly steep and difficult path. We were about a quarter of the way up when one of the hikers shouted down to a friend—“take the right-hand path. It’s shorter. Much steeper, but shorter.” The path was so steep that we didn’t want to turn around, hike back down, and take the other path. We came across many other forks in the road, but our guide was always there to show us the way, which made our hike far easier.
Lesson #5: The shortest path is not necessarily the fastest.
When we finally joined the other path, the rest of our group was actually ahead of us. They had taken the longer, less difficult path and they were farther along. And were far less out of breath. There are times when shortcuts make sense. When we blindly follow processes just because “we have always done it this way,” we take a giant step towards bureaucracy. However, our shortcuts need to be well-conceived, and we need to understand the consequences of taking a shorter, less-known path. If that shortcut is tested and well-understood, we need to recommend that it replace the existing process.
By the way, everyone in our group made it to the top—and it took us about two hours less than our guide originally estimated. We have our wonderful guide Palee to thank–he was a great PM, BA, knowledgeable SME, and overall great guy.
Written by: Richard Larson and Elizabeth Larson
