- Many steps will unambiguously create value (VA).
- Many steps will create no value but are unavoidable (NNVA).
- Additional steps will be found to create no value and are immediately avoidable (NVA).
In this example, which is fairly typical of a traditional BI project, the most obvious area of waste is the time spent waiting. Approximately 31 percent of the total project time was time spent waiting for both signoff and resource availability. BI teams also should question the time spent during the detailed design phase. How much of that time is for creating documentation for the developers versus documentation for the customer and/or BI team? They should really question all the steps along the value chain to determine whether they add value and where they can be improved. In the short term, improvement may be achieved via rapid iterations, integrated testing, prototyping, and other agile practices. In the longer term, the implementation of development standards, common processes and procedures, feedback loops and business driven metadata repositories will likely lead to a reduction in waste and greater value.
2. See the Whole Picture
Learn to see beyond each individual architectural decision, organizational issue or technical problem by considering how they relate in a wider context. When business users make decisions and solve problems, they often only consider the immediate symptom rather than the root cause issue. For example, when a BI analysis uncovers rising call wait times in customer service, the answer is often to increase the number of agents rather than investigating the underlying cause for this increase. Consider how others may be affected by the decision, whether it be within our own department or cross-functionally. The cause of the increased wait times may be due to poor product quality from the introduction of a new supplier.
For example, consider this discovery at a recent consulting engagement. Based on the result of a BI analysis, the purchasing department decided that in order to save time entering purchase orders they would create blanket orders that started with a quantity of 10,000 and receive a portion of the total order for each delivery. Unfortunately, the system did not allow the purchasing agents to schedule parts of the order or the ability to update the price after the order was opened. The result was that while it saved time for the purchasing group, it created much more time to resolve receiving issues and led to a tenfold increase in pricing discrepancies. In addition, they were unable to rate the performance of their suppliers, ultimately causing on-time delivery issues to the customer. In this case, BI was used to optimize a local process at the expense of the broader organization.
This is also a challenge on the technical side of BI. For example, the same data integration jobs fail consistently and the response is usually to simply restart the job rather than determining why the job failed. It could be that the backup job of an upstream system is running into the load window, in which case it’s likely that the number of failures will increase over time. In addition, architectural decisions that focus on solving immediate issues, such as poor query performance or long data load times, often lead to larger problems over time. For example, changing the network backplane between database nodes might solve throughput between servers but end up creating greater processor and memory bottlenecks. When we fail to consider issues in a wider context we tend to optimize only the local problem at hand at the expense of the larger system and often don’t address the root cause of the issue.
3. Iterate Quickly
It is often the case that by the time a project is implemented, the requirements have changed and part of what is implemented is not required anymore or is no longer a priority. When features, reports and data elements are implemented that aren’t utilized, it is considered waste. There are two main levers to iterating quickly: increasing flow and reducing the scope of each iteration.
There are many steps to creating flow, such as incorporating the business into the development and design process, implementing test-driven development, creating level demand and developing multifaceted BI resources. The key is to not only reduce the amount scope and minimize manual processes per iteration, but also reduce the number of handoffs throughout the process. The more handoffs and interruptions that are created, the more time that is spent by resources simply trying to get up to speed on what’s been done in the previous step or steps. It also tends to be more difficult to control quality the more people that are involved in the process. In the most extreme example, if you have one person that performs all tasks in a project then you know which resource created the quality issue and you can help that resource improve the area where the issue was created either through additional training or a change in the process. While it’s improbable to train all of your resources to fill every role, having resources that can fill more than one role helps to reduce handoff, reduce errors and even can lead to a more satisfied staff.
When the scope is reduced, it doesn’t necessarily mean that you need to reduce the scope of the entire project, just each iteration. BI teams can work with users to help identify the minimum number of features and capabilities that will meet the initial requirements. This is referred to by the Lean community as the minimum marketable feature set (MMF). Once the first iteration is delivered, the business users will be able to make more precise requests about what additional functions are needed in the next release cycle. This is continued, ultimately culminating in the broader solution. Communicating this to users helps to ease their concerns that their project is being curtailed.
Be the first to comment on this post using the section below.