This guide has attempted to unravel the complexities surrounding BSM all the while illustrating to you the value proposition associated with its implementation. As we've learned, BSM is a platform upon which various classes of monitoring data can reside. As we've learned, BSM is effectively a mechanism by which the goals of business are applied to the technology of IT. With BSM, IT data and metrics are ingested from numerous sources, including BSM's own internal monitoring instrumentation, and used to calculate metrics that determine the overall health of a business service.
The intent for this chapter is to provide you with a sort of crib sheet for the concepts and major topics we've discussed throughout each of the previous chapters. As a Definitive Guide, this book is intended to be fully comprehensive in the story it attempts to tell. But sometimes what you really need is a down-and-dirty explanation with plenty of useful images to be used in helping others understand the utility and value associated with BSM. That being said, this chapter intends to wrap up our conversation on this topic as well as reiterate the critical concepts and takeaways discussed in each of the earlier chapters.
Throughout this guide, we've started each chapter with a story. That story has told the tale of John Brown and Dan Bishop's iterative embrace of BSM as a solution for quantitatively illustrating the quality of their online B2B Web service. The story started out in Chapter 1 with what appears at the outset to be a common problem in any IT environment. There, what was originally believed to be a "minor IT system" went down one night. But that system was quite a bit more important to the functionality of FCG's entire Web system. Its outage resulted in a 6hour loss of order state information for special orders placed through the Web service.
During that 6-hour outage, every order placed ended up in an incomplete state. Neither the individual placing the order nor FCG itself knew the status of the order. As a result, FCG's ordering department was forced to go through a highly time-consuming and costly reconciliation process to determine the state of each order and work with its owner to resolution. This added activity was expensive enough to significantly affect FCG's quarterly numbers. What we learned over the course of each chapter's example story was how an iterative approach to a BSM implementation in the end significantly benefitted FCG's ability to make better business decisions as well as track and resolve problems as they occur.
A critical issue throughout the storyline in each of the early chapters was a dissonance in language and priorities between the IT department and the rest of the business. This "chasm" between IT and the business occurs in organizations even today. IT has a tradition in viewing the computing environment from a device-centric perspective:
But there's a problem intrinsic to this device-centric approach to IT operations: It doesn't mesh well with the goals of the business as a whole. Businesses continue to operate because they successfully complete transactions with their customers. Those transactions can be services provided by the business or inventory sold to customers. IT systems in these sorts of businesses are responsible for the processing of those transactions, and it is the individual transactions that are ultimately most important to the processing. Without those transactions, the business cannot meet its goals.
As we'll discuss a little later in this chapter, this "chasm" between IT and the business occurs due to issues with the level of IT maturity. This descriptor doesn't necessarily attempt to explain the behaviors of IT individuals; rather, it discusses the level of repeatability, automation, and proactive capability of IT to support the needs of the business. When IT can fully support those needs in a proactive and measured way, we can think of IT as being mature. BSM is one solution that assists with the process of maturing IT to align with those business goals.
One critical requirement for a BSM installation is the need to tie BSM to those business goals. To that end, it is important to consider the services enabled by IT. As part of that consideration, BSM is designed to work best when aligned with what we consider business services. As Chapter 1 describes, "a business service at its most basic form is one whose operation can be quantified in terms of dollars and cents."
Thus, typical IT infrastructure elements are not the main focus of BSM. Instead, those services that ultimately drive income to the business and can be measured in whole dollars are critical success points for a BSM installation. We say this because one key component of BSM is in identifying the dollar profit or loss associated with the quality of service processing. When a service is of high quality, that service is able to meet the needs of its customers. It is able to fully accomplish its intended task, and it contributes positively to the bottom line of the business. From Chapter 1:
BSM is effectively a mechanism by which the goals of business are applied to the technology of IT. With BSM, IT goes about a reconfiguration of the way it considers technology—adding to the traditional device-based approach it begins embracing a service-based approach to monitoring. This embrace of technology in terms of business services means that individual outages are treated as profit-and-loss events for the business. A loss in a subsystem to a business service feeds into the total quality of that service. A reduction in the performance of a system reduces its quality. And, most importantly, a decrease in response time for a customer-facing system reduces its service quality.
By layering a BSM installation over the top of existing IT monitoring solutions we can begin proper monitoring of that quality metric across a spectrum of interfaces, metrics, and types of instrumentation, and begin to see business service views. We also gain the ability to break down the very large concept of the "business service" itself into its individual components. This granular representation of the overall business service creates what we call the service model. This service model along with its interconnections is used by BSM to identify how the various elements of the service work together. BSM then becomes a type of calculations engine that melds this performance data, compares it against preconfigured limits and thresholds, and develops conclusions about the ultimate health of the service.
Figure 10.1 shows an example of how this works. Here, we see the completed service model for a "Mission Critical B2B Web System" not unlike the system discussed in our chapter examples. In this image, we also see how a decrease in transactions per second below a stated threshold for the Inventory Database element causes an upstream delay in the Inventory Processing System and the Order Processing System elements. The ultimate result of this seemingly small problem is that customers grow unhappy with the performance of the site.
As you should immediately see in this representation, when the level of instrumentation grows beyond simple device monitoring and towards transaction-level monitoring, the visibility into root causes of customer dissatisfaction grows significantly more powerful. This power enables businesses to make better decisions about how IT-based services are positioned to the customer. It also provides a quantitative measurement by which IT can perform better planning activities towards system augmentations or additional services.
Figure 10.1: What appears to be a simple problem with an Inventory Database can quickly impact the entire system as a whole, ultimately causing user dissatisfaction.
Being able to capture and calculate all this data is all fine and well, but without a way to display this data in a form that is useful for its consumer, this data is effectively useless. Thus, the end result of any BSM installation is the preparation and rendering of comprehensive dashboards that illuminate the health and quality of the underlying business service. This third component is illustrated in Figure 10.2, where we see how raw data is brought into the BSM system, calculated and compared against preconfigured conditions, and ultimately reported on through visualizations.
Figure 10.2: BSM is involved with three components: raw data input, calculations, and visualizations.
At this point, you may be thinking, "But any IT monitoring product can display images associated with system behavior." This is in some ways true. Most traditional IT monitoring products have the ability to alert and notify through some form of visualization. But a BSM solution is different in that one of its central tenets is associated with the digestibility of the data being presented to its consumers:
Each of these groups is incentivized to pay attention to different parts of the business, and because of this incentivization, each needs to see different types of data. The biggest benefit of a BSM solution is that its internal calculations along with its rich visualizations engine can provide the data needed by each of these groups of people. Also from Chapter 1:
If the BSM system can provide information related only to downed server names and log data surrounding an event, an executive is not likely to pay attention to that system. If the system can provide digestible information to the executive—the name of the business service affected, the number of whole dollars associated with the reduction in QoS, and how that service's outage affects other services—the executive will be empowered to make educated decisions.
If this chapter is your first reading into the story, you should now immediately see where BSM can be very powerful within a business. For most of the history of computing, IT has traditionally used comprehensive alerting mechanisms to notify IT when problems occur with their systems. These systems can send notifications to mobile devices while updating graphical interfaces with information about the health and quality of systems under management. Yet these same capabilities have only recently made their way out of the Help desk and into the boardroom. Figure 10.3 represents an example of how this might look for an executive.
Figure 10.3: An example dashboard for an executive audience, showing data that would be interesting and useful for their job role.
The same data that is gathered by the BSM system for use by IT can be reformatted for consumption by business executives such as what is shown in this example. Here, BSM is monitoring transaction information to provide data about the health of the business itself. Rather than seeing information about IT devices that are functioning or non-functioning, the business executive using this view gains a single-glimpse view into the status of business-centric metrics such as rate of approvals, technical services, call center metrics, and the like.
Using BSM's unique calculations engine along with its ability to turn data into useful graphical representations, non-technical executives for the first time can see into the systems they are charged with managing for the business. They can easily obtain the kinds of information they need to make educated decisions about the positioning of products and services within IT-based systems. They can predict and plan for augmentations as necessary, and all the while make better decisions about running their business. All this is gathered through the same BSM solution that can assist IT with its own monitoring needs.
Now that we're reviewed the basic elements associated with BSM and what it can enable for the business, let's take the rest of this chapter to look back through each of the major topics discussed in this guide. As you can see in Figure 10.4, this guide is intended to take you through the introduction to BSM and its genesis, why it exists in the form it does today, and through its implementation phases. We finish out the second half of the guide with a comprehensive discussion on value to management, operations, and IT before a talk on BSM's integration with common IT process frameworks like ITIL and Six Sigma. In the next few sections, we'll review each of the topics discussed in their relevant chapters, starting with a conversation about the alignment problem that plagues IT organizations that exist lower on the IT maturity curve.
Figure 10.4: The building blocks that guide the conversation towards a holistic picture of BSM.
A major problem with the traditional role of IT within business has to do with its relative insulation from the majority of business processes. IT in many organizations is seen as a group of people who appear when problems occur or when computers break, only to return back to their hiding places once the situation has returned to normal.
In the old days, this way of dealing with IT worked well enough. Businesses hadn't yet come to rely on IT systems for critical processing of core business functions. The business used IT technologies for limited needs through the normal course of business, but the heavy lifting remained with handshakes and non-technical means.
Today's business has changed significantly, bringing IT to the forefront as a critical component to the functioning of the business and the continued recognition of profit and loss. But with this increased responsibility has not come a linear increase in visibility for many environments. What must happen is a change in mentality away from IT as a break-fix entity to a co-equal partner in the goals of business. From Chapter 2:
The change in mentality associated with greater "building" and less "fixing" also tends to drive a change in how IT sees the employees who use the network. At some point, the IT department begins to see the users of its network less as "the people causing the problems" and more as "the people using the services." The negative connotation of "users" disappears, and the network residents become in effect the "customers" of IT.
Along with this change in how IT is viewed by the business needs to come an advancement in how IT sees and manages its own services. Gartner identifies a five-stage model associated with this maturity process, as Figure 10.5 shows. These five stages and the identifiers used to represent each stage are used to show the current positioning of IT in terms of automation, resiliency, and ability to support the needs of business. It also serves as a set of guideposts to assist with graduating an IT organization from one stage to the next.
Figure 10.5: Gartner's IT maturity model identifies five stages to characterize IT's level of organizational maturity.
We focus specifically on this model because an IT organization's capability to embrace BSM's concepts relates directly to the stage in which it currently resides. IT organizations in the Chaotic stage tend not to have the infrastructure and procedural elements in place to make an easy jump towards BSM. Moving an IT organization to the right on the model tends to involve greater capability for documentation, metrics gathering and analysis, automated processes, and most importantly an organizational culture that is willing to accept the level of formality brought about by a BSM implementation
It's important at this point to say that an organization at the leftmost stages of the maturity model needn't completely avoid BSM. The processes required to successfully build and implement BSM will very quickly move that organization to the right. But that same implementation will take longer and be less effective until it does.
Chapter 2 goes into specific detail about each of the stages along with the areas of impact that BSM is likely to provide within each. Without repeating the deep explanation of those guideposts that identify each stage, let's take a quick look at the impact of each stage and the level of BSM embracement an organization can expect to obtain.
Table 10.1 is reproduced here from Chapter 2 as it is an easy-to-understand element that provides an excellent rundown of the recognizable BSM benefits potentially gained by IT in each maturity stage. As you'll see in the table, as organizations move to the right, they grow more capable of dealing with and incorporating BSM's higher-level concepts.
Key Steps Toward BSM
Table 10.1: At each level along the maturity model, an organization can move towards IT and business alignment.
This role of IT maturity in the embrace of BSM is critical, but it's only part of the story. To understand the BSM of today, what is also needed is a discussion on where it started.
Understanding BSM's roots goes far into understanding why it has developed over time and how BSM specifically provides value over each of its ancestor technologies.
Chapter 3 talks about this evolution in substantial detail. BSM's discussion of service quality began in traditional device monitoring technologies. Chapter 3 explains:
Since the beginning of modern computing, there has been an ever-growing need for systems management and monitoring. As the number of computers that make up a network has increased, the number of configurations and manageable endpoints has geometrically increased as well. Adding even a few more systems into a network means adding dozens or hundreds of additional management touch points to that network environment.
Over time, the process of managing those touch points has evolved, starting with the early attempts at network management, through proprietary agent-based tools, resting now for many organizations with a new focus on agentless management and end user experience monitoring. What we anticipate to see in the future as we continue down this timeline is a refocusing on value in the near-term future by organizations that have progressed up the maturity curve.
What we learn through the history of IT monitoring technologies is a movement away from the traditional device-centric approaches of yesteryear. Those approaches are still relevant today for certain consumers, such as IT administrators, but an additional look into the value of IT systems and how that value impacts business agility and the corporate bottom line is what is absolutely critical in today's environments where business and IT are inexorably linked.
Our discussion into BSM's roots also goes into detail regarding the targeting of monitoring data and how that targeting has evolved over time (see Figure 10.6). In the beginning, data monitoring was highly focused on network availability and utilization. This was predominantly the case because of a basic inability to visualize activity and behavior at the wire level on a network. You just can't see the bits flowing across the wire, so visualization systems were put into place. Over time, those performance measurement systems moved into server performance, but initially at the level of the entire server itself.
Figure 10.6: Over time, traditional monitoring has evolved to discover the needs being met by BSM.
The problem with entire-server metrics is that they don't capture the true behavior of onboard services in many situations. As an example, when a service sits in a wait state, waiting on a transaction to be transferred from another system in the chain, this behavior doesn't manifest into whole-server metrics. So, IT using only these tools never sees a problem with the system.
These missing links helped evolve entire-server performance metrics into more troubleshooting and predictive analysis tools and later into the End-User Experience (EUE) monitoring tools we discuss in Chapter 5. All of these feed into the business' need to understand and manage its level of IT service and ultimately how those services tie into the business' bottom line. Each of these stages along the way is explained in great detail in Chapter 4.
The implementation of a BSM solution will for many environments be a non-trivial task. The formal identification and documentation processes required to build the service model involve a lot of work and analysis by implementation teams. Integrating that service model, once built, into the monitoring toolsets needed to gather necessary data is yet another complex task. Thus, Chapter 4 discusses the seven phases typically associated with a BSM implementation. Figure 10.7 shows those seven phases.
Figure 10.7: The seven phases of a BSM implementation.
This activity tends to be more or less trivial based on the maturity level of the IT organization. BSM's calculations engine as well as its monitoring instrumentation requires a highly formalized look at the business services in an environment as well as their interconnections. When those interconnections are not already well-understood or well-documented by the business or IT, this tends to simultaneously convert a BSM implementation into an environment documentation activity as well.
Without repeating too much from Chapter 4, the general processes associated with each of these phases resembles the following:
One component that we're glossing over in our discussion thus far is involved with exactly those transactions that are of interest to the BSM solution. We talked already about how entire-server metrics are not enough to fully understand the goings-on deep within the systems we're attempting to monitor. Because those metrics are simply not enough, we need another way of looking at the entire service model from a bottom-up approach—one that analyses the systems' behavior at an exceptionally low level. That monitoring approach is based on individual transactions and how they navigate throughout the IT elements that make up the service model. We call this approach End-User Experience (EUE) monitoring.
EUE takes a two-pronged approach to look at these transactions as they move through the disparate elements of the business service. These transactions may start at a Web server and may later be transferred to one or more database servers; this transfer may be routed over any number of network connections, all the while being modified by mid-tier or business logic systems in the middle. This complex path for each piece of useful data is impossible for traditional monitoring tools to capture.
EUE takes a different approach than does traditional monitoring through the incorporation of two different and simultaneous mechanisms for watching these transactions. The first is agent-based monitoring with agents that are installed to servers within and outside the systems that make up the business service. Chapter 5 includes a good explanation of agent-based monitoring:
First, by installing agents onto individual servers that make up a business service, the agents can look deeply into the processes and activities that make up that service. The agent can analyze behaviors within the server to look for individual transactions, the success or failure of those transactions, and the quantity of time elapsed to complete those transactions. Because the agent is installed directly to the specific server of interest, that agent can be configured with relatively unrestricted access to gather and report on the information it needs from within the server.
Second, agents can also be installed onto clients throughout the network. The agents on these clients are then programmed to emulate an end-user performing key business transactions throughout the day…By installing these agents on systems across the network, the EUE system can compare the results of each transaction with those of other agents to see where individual sites may be experiencing problems. In many ways, the idea with agent-based solutions is to determine the total time necessary to complete a transaction from multiple locations to help identify the characteristics and locations where poor application performance is experience.
Agent-based monitoring provides a mechanism by which the performance of individual transaction processing can be viewed from multiple points on the network. The comparison of the metrics gained at each point is then calculated to determine the service quality at each point. But in the process of capturing this information, there can also be other on-network situations such as large file transfers, backup jobs, or other network congestion. These transient situations can impact transaction performance but are not likely to be measured by EUE agents. By nature, agents simply aren't aware of transient network situations. Thus, we need another simultaneous type of monitoring to gauge the overall environment conditions. That other type is agentless monitoring. Chapter 5 continues with an explanation:
Much different than agent-based monitoring is the concept of agentless monitoring. Here, code is not installed to the individual servers that make up the business service nor are any transactions synthetically generated to the systems under management. Instead, we leverage a central solution that is configured to watch for all the traffic across the network.
This agentless solution will determine the business impact associated with any transactions that did not complete properly or within a proper amount of time.
Obviously, in order for this system to do its job, it has to understand the traffic it is receiving. If a Web server is communicating with a Web browser client, that traffic needs to be understood as a Web request followed by a Web server response. It can also be a series of requests and responses that make up a complete business transaction. This type of communication is programmatically easy to understand. Where mature EUE systems provide extra added value is when those systems can additionally translate non-Web application traffic.
Though we discuss here that EUE monitoring includes both agent-based and agentless monitoring, it is possible to install only one of these two types on monitoring mechanisms into an environment. Often, this is the case in highly secure environments where there is a security concern regarding large-scale network data collection. This being said, the quality of data received will not be as high when only one mechanism is used.
One goal with this dual approach to transaction-level monitoring is to identify where in the thread across client, networking, and servers is delay occurring. Finding those areas of delay goes far into discovering the root causes of problems with the business service. This "Client, Network, Server (CNS) Spread" provides a spectrum, as Figure 10.8 shows, between the time the transaction spends bring processed at the client, over the network, and on the server.
Figure 10.8: The "CNS Spread" isolates transaction timing into client, network, and server components.
The end result with all this monitoring is a deep understanding of the quality of the service being monitored. Transaction performance information is calculated through the BSM calculations engine to provide a metric that defines and sets thresholds for the appropriate level of quality. At the same time, when quality metrics go beyond preconfigured thresholds, administrators can be notified. This allows administrators to begin researching problems before their level of impact grows problematic for the business.
Our discussion of the basics of BSM dovetails well into a three-chapter analysis of BSM's value to management, business operations, and IT organizations. In the first of these three chapters, we take a look at the management value associated with a BSM implementation from the perspective of its intrinsic ROI as well five classes of dashboards and dashboard consumers:
Chapter 6 includes a number of example dashboards that relate to these consumers. Rather than reprinting those dashboards associated here, consider turning back to Chapter 6 to see the examples designed specifically for each consumer class.
We also take a look in this chapter at the tangible and intangible benefits associated with a BSM implementation from all perspectives. Tangible benefits here are associated with the improved capability and speed in seeing and resolving problem areas within the business service. The improved ability to determine the desires of service end users and modify those services to suit user needs is a major component of intangible benefit. Chapter 6 includes a table that breaks down these concepts by category. That table is reproduced here as Table 10.2.
| || |
| || |
Table 10.2: A non-exhaustive list of value gained by an organization through the implementation of BSM. That value is broken down into various categories.
The ROI associated with BSM is also compelling when the one-time costs associated with its implementation are merged with the recurring benefits gained. A BSM installation tends to include benefits from direct cost savings as well as revenue benefits. Chapter 6 looks at a few of those benefits in detail. First, the direct cost savings associated with its implementation:
It then also looks at revenue-driving benefits based on the metrics capable of being captured:
All of these benefits are those that the business stands to gain on a recurring basis. For example, when a business can increase their average revenue per successful transaction metric—and when they can quantitatively measure that increase—they immediately gain through the direct linkage between metrics and service changes.
The added situational awareness as a part of BSM's real-time and historical data visualizations provides analysts and executives alike with an enhanced vision into the efficacy of their decisions. It enables them to directly see the effect of their decisions on the service as a whole. Figure 10.9 is an example of this. By seeing real-time response values along with deviations from accepted norms across a spectrum of business services, the managers of these services can immediately recognize through this quantitative interface how their decisions impact business operations.
Figure 10.9: Well-designed dashboards with proper metrics enable decision-makers to see the efficacy of their decisions.
One advantage to how BSM is implemented in an environment relates to how it layers atop existing management and monitoring solutions. BSM needn't involve a complete "rip-andreplace" of existing solutions but instead works better when leveraging their already in-place monitoring instrumentation. Thus, a BSM implementation is often a very low-risk addition to an environment.
Figure 10.10 shows an example of this, depicting how the same instrumentation data currently being collected through existing systems management, systems monitoring, application monitoring, CMDB, and service desk systems can be flowed through the BSM solution. This tiein to existing instrumentation data only enhances the level of situational awareness possible through BSM's visualizations.
Figure 10.10: Existing systems needn't be removed to make way for BSM. Rather, BSM can make use of their instrumentation data for its own purposes.
Further, to show the value gained by operations when considering a BSM implementation, one must look at the types of information that can be provided. We've already talked about the central BSM tenet of digestibility. But this concept comes into full focus when considered in relation to the classes of data consumers that stand to gain through visualization data. From the perspective of the kinds of metrics capable of being generated, three classes of users gain realtime access to very useful metrics. These metrics assist in making good decisions about their area of focus. From Chapter 7, management and executives gain in three areas:
IT cares about a different set of information entirely. Even mature IT organizations still require the ability to see how their actions affect IT technology. Some metrics discussed in Chapter 7 that aid IT decision-making and troubleshooting activities include:
Lastly, the end users of the system stand to gain through an added vision into the health of the system from their perspective. When users attempt to use a "broken" system, they may waste time and resources attempting to perform their own sort of troubleshooting. All end users recognize that services go down from time to time. But what end users desire is proactive notification that tells them about system status and when they can expect the system to return to service. Chapter 7 includes metrics of value here as well:
The information discussed in Chapter 7 on operations then threads into Chapter 8's specific focus on the value to IT. In Chapter 8, we start with a discussion of how five sources of IT data assist in feeding information to BSM's calculations engine with the goal of generating the kinds of metrics discussed earlier. These sources of data include service desk data, configuration data, response time data, infrastructure metrics data, and business data.
In many IT environments, much of this data is already being collected through one of many management and monitoring tools already present within the environment. BSM's instrumentation hooks into these disparate systems to enable the data from theses systems to augment the BSM solution's own internal EUE monitoring.
The combination of these data sources is what ultimately enables IT to use the service model as a troubleshooting tool. Chapter 8 includes two images associated with an example service model and how a problem at the lowest level of that model immediately begins affecting dependent services within the model. IT administrators can make use of flow-down and flow-up analyses of the service model to see directly how a root cause impacts service behavior and performance.
Figure 10.11: With BSM, a larger problem can be drilled down into its disparate components for low-level troubleshooting.
In the example reproduced here as Figure 10.11, you can get an idea how the overall problem associated with Transaction Performance drills down into deeper and deeper levels of information. In this example, when Transaction Performance doesn't meet its desired threshold, the drill-down shows nominal performance directly with both the front-end and database, but a performance problem between these two services. Drilling further into this performance problem, we find that a router has too high of an error rate and thus its performance is too low.
Most specifically, this information is useful because it enables IT to best assign available resources towards the problems with the highest impact. When multiple problems occur—a situation that occurs regularly in IT environments—those that have that highest potential impact to users can be assigned the most attention.
Having a high level of situational awareness of an environment is only useful if that information is used to improve the environment. BSM links specifically into two IT frameworks for processing and decision making: ITIL and Six Sigma.
Chapter 9 includes a short explanation of the five stages of ITIL as well as the 24 activities commonly undertaken within each stage. ITIL is designed to assist with the process of taking a new IT service from its initial strategizing, through design and transition, on to full operations. Wrapping each of these first four stages is a common thread of continual improvement used to identify and fix areas of gap in the design, implementation, and operations processes. BSM's concepts and capabilities are designed to align with only a subset of the activities commonly considered during each of these stages. Figure 10.12 shows an example of the specific activities that can gain assistance through BSM.
Figure 10.12: BSM aligns with a subset of ITIL's activities.
Chapter 9 goes on to explain these areas and the specific tie-in's to a BSM implementation. We learn there how BSM's information assists with the management of these tasks:
Whereas ITIL is intended to be a set of best practices for all phases of a service introduction, delivery, and operations, the Six Sigma framework highlights just the processes associated with continual improvement. Six Sigma utilizes a number of quantitative measurements and tools to assist with identifying processes and the level of error that can or is being experienced during the running of that process. The goal with Six Sigma is to reduce the level of error (or "sigma") to an acceptable level (which can be up to six "sigmas" from the norm).
Where Six Sigma and BSM align well is in Six Sigma's data-driven approach to problem solving. With Six Sigma, numerous visualizations are used as mechanisms for identifying when process errors occur. Those visualizations can be easily generated through BSM's dashboards. Common visualizations include, among others:
In the same way BSM visualizations bring visible guidance to management towards the results of their decisions, these same tools are useful in process improvement activities for helping with structured analysis.
This guide is intended to assist you with gaining an understanding of the inner workings as well as the value of the BSM methodology for management and monitoring of business services. Throughout this guide, we've used examples and imagery to assist with the learning process. But BSM is more than just a methodology or a framework. It also encompasses a software package that enables the concepts we've discussed here.
If you haven't yet implemented BSM in your organization, the process to identify and acquire the BSM software package that best suits you will be your next step. This guide is intended to provide a bar by which effective BSM solutions can be measured as well as assist in guiding you to the solution that works best for you.
Considering the valuation modeling intrinsic to any BSM solution, you're likely upon installation to very quickly start finding places where BSM directly benefits your business' bottom line. BSM is above all a tool used to discover and report on value, which means using it for self-discovery and self-valuation is a simple task. Good luck and best wishes with the infusion of BSM into your corporate culture. As the author of this book, and one of BSM's biggest fans, I hope you find great value and direct benefit out of its inclusion.