9 hours 3 minutes
Hi, guys. Welcome to measure phase. Designing a data collection system. I'm Catherine Mc Iver. And today you'll be able to understand the components of a data collection system and have the ability to design your own data collection system.
So this is one of my favorite quotes from one of my favorite management gurus, Mark Twain.
There are three types of lies. Lies, *** lies and statistics. If you guys think back to our previous module when we're talking about the differences between categorical and numerical data and specifically discrete and continuous and that we prefer our continuous data because of the statistical element of it,
that's part of the reason why I have always enjoyed this quote.
All right, so when we're developing a data collection system, the first thing that we want to do is we want to state our data collection gold. So why are we collecting this data? What are are expected outcomes. What do we want to learn from this?
And to get this information, we're gonna want to look back to our project Charter
S O. R. Problems statement and our objective statement. So what do we think needs to be improved and How much are we going to improve it by If you have a time bound problem statements such as a cycle, time and the time bound objective statement, it's a really good assumption that your
data collection goals are going to be some measure of time.
The other thing to keep in mind when you're looking at your data collection goals is how do you integrate the voice of the customer in this? So, um, categorical data, orginal and nominal when we're talking about customer satisfaction, very straightforward and integrating the voice of the customer. But when we're starting to look at things like cycle time,
production rates, defects, rate,
how do you represent your customers S O? Keep these in mind as you move into the next step of collecting of designing your data collection process, which is your operational definitions. So
this is where your knowledge of the type of data is going to be important. So what type of daughter you working with and what do you want from it and be as explicit as possible? We're looking for customer complaints that relate to the weekend shift for our flagship pizza store. We don't want to look at
all of our customer complaints were only looking at this subset.
The next question you're gonna ask yourself is how much and when we say how much we're looking at the volume of data collected. So every time you make a decision about the volume, you have to weigh your pros and cons. So one you can certainly get lots and lots of data. Um,
which takes time it takes effort, and you may were, may not see added value from that. Or you can work with
what's the minimum amount of data that I need to make a reasonably informed decision? I think that the middle ground is best, especially as you're starting to really try and tie your problem. Statements in your objective statements and your data collection together. Aim for a medium amount. And when I say a medium amount,
if you're working with continuous data,
so measurements anything that's on a spectrum, anything that can be expressed as a fraction you're going to need a minimum of 20 data points to develop a distribution curve. So, um, preferably more is better than once you start getting higher and higher. You start seeing some
very interesting patterns from your data. From a statistical standpoint,
more is better. But try to keep that one that rule of thumb of 20 data points in mind. The other thing you want to think about is how often so think back to your problem. Statement.
The one that I used, for example, was weekend shifts, which means that we wanna measure data that are weakened shifts. But we may also wanna measure data that are weak day shifts to provide us a comparison. So what type of dad are you looking for? How what's the volume of data you need to collect and how often do you need to collect it?
The volume of data and how often are generally interrelated. So if you want to have
100 data points and you only get to data points a day, you know that you're going to have to run a data collection of at least six weeks, if not a full month. So consider those sorts of things. That's a little bit of a trade off, which will go into planning your data collection methodology. So now that you have decided,
what are the up the outcomes
from the static collection. So what are your goals? What type of dad are you looking for? Are you doing customer complaints and satisfaction scores? Are you just looking at customer complaints? Are you doing satisfaction scores and cycle time? So you knew what type in with volume you need. Now you're gonna ask yourselves, how are we going to measure it? So
you're going to create your
measurement system, How you think it's going to be measured and then you're gonna want to test it during this phase is when we're going to go to our next module, which is validating our measurement system. So how do we know that the measurement system we've created is effective is repeatable and reproducible, which is
one of the foundational requirements for knowing that you're
data is stable.
Um, now that you have stated your collection goals, you know what your operational definitions are. You've planned how you're going to gather this data and your methodology. Now you can start beginning the data collection,
and I have a little bit of a soapbox here on this, because frequently organism project teams are really excited to do data collection. It's super cool. You finally get to dig into your your project. You really? This is one of those major tangibles where, like you can see it coming up.
You know that you're working on it. You've designed something for
possibly the first time in your project. If you more part of the charter construction, this is super cool. The thing is, is if you jump right into data collection without answering some of the foundational questions like what exactly are you looking for? How do you know you've gotten it? How are you going to collect it? Did you test that collection system?
You may find yourself in a rework cycle where you end up actually having to go backwards
and recollect data because the data that you collected didn't meet. Generally, it's the collection methodology requirements for the repeat herbal and reproducible. So now you have begun your data collection and now we're gonna move towards monitoring and improving your data collection.
So when we see monitoring improved, this isn't like a I made you
and let's carry on and go forth and take over the world. What you want to do is you want to continue thio, pay attention. So you want to audit the data that's being collected. You wanna look at it and make sure before you've invested that six weeks, two months for your 100 points of data that does this
actually answered the questions that are being posed
in your problem statement in your objective statement. So the last thing is to monitor improve your data collection. This can also be a cyclical process. So as you are monitoring it and you're looking at what types of data you're receiving, maybe they're not the right tapes of data. So going back to your operational definition or perhaps
Yeah, the data that your collecting does not necessarily answer the questions posed in your problem statement, In which case you need to go back to your data collection goals So
high level summary of how to design a data collection process my
tips and tricks on this wood to be creative and innovative. And just remember that you do want to validate your system, which is our next module. But when you're designing your data collection plan or your data collection system, the most important thing to keep do is to keep your goal in mind
and from data collection your goal is what questions am I trying to answer? What do I need to learn about this process so that I can analyze it and start teasing out the gaps and improvement opportunities?
Um, data collection summary? Or that a collection
plans are another area where you want to go slow to gill fast. So make sure that you would invest as much time as possible during your goals, operational definitions and methodology things because that will prevent you from having to do rework or defects in the future.
So I look forward to seeing you in our next model,
which is validating our data collection system. Thanks, guys.