As I continue to dive into my Six Sigma training, I have found that one of the best things about the training is the exchanging of stories. It seems that almost every time someone wants to make a point with regards to Six Sigma, they share a story. And I have to admit that I enjoy many of the stories, as they usually revolve around what I believe to be a lack of common sense. For example, a plant manager will demand an explanation if the plant output is below average one month, yet averages are determined by numbers that are sometimes above and sometime below. Six Sigma is a way to train that manager to understand how to determine if the numbers presented to him (or her) are signals or noise.
I came across a blog and thanks to my Bat-Google Reader I can keep up with the latest posts as they happen, which is nice. Today I found this one to be interesting, despite not offering a possible solution. I find it interesting to see a handful of examples that describes one or more environments we have all worked in or around. How is Six Sigma supposed to solve this? I have no idea. Why do I care about Six Sigma? Well, to be honest, I see very little use of it in the IT industry. That is not to say it does not exist, just that I have not seen (or heard) about it being used. To drill down even further, I know very few DBAs that employ any type of Six Sigma methodology in their everyday lives.
For me, Six Sigma is all about determining what is a signal versus what is noise, and using that data to help make something more efficient. The best example I can think of right now is the simplest, a database dump job inside of SQL Agent.
Say you have a job that runs weekly to do full dumps of all databases on your server. One week it takes thirty minutes, a week later it takes forty-five, and the third week it takes an hour. Now, as a DBA, would you suspect that there is a problem with the server? After all, the time for the dumps has doubled in less than two weeks. There could be many factors for this, of course, but at what point should you decide to investigate?
What I hope to do is to figure out a ‘best practice’ with regards to time management for such issues. Our time is quite valuable these days, so it is important that we research issues only when the need exists, i.e. we are given a signal. So, perhaps we get alerted that the database dump job is taking too long, so we get notified. But it may be possible that despite the increase, the job is running as expected, and therefore there is nothing for us to investigate, so we would not want to be alerted. Less alerts, less distractions, and more time to spend our energy elsewhere.
