Render Data

This is data from a company's defect chart. A defect chart is used in supply chain management for quality control. In my Supply Chain Management class, we're learning about the stages and factors that influence supply chain management, covering topics such as inventory, planning, accounting, human resources, and quality control. A defect chart depicts the defects reported in a manufacturing context at each hour of operations. There are three different ways to visualize this data, each highlighting different aspects of quality control. It is the responsibility of the operations manager, or whoever is in charge, to discern which visualization method is most relevant for showing these effects.

The three main ways to visualize this data are through a histogram, a Pareto chart, and a bar graph, each serving a specific purpose in quality control.

Paetro chart: Useful for identifying the "vital few" factors, by frequency.

Histogram: Histograms are commonly used for process control to understand variation in measurements and identify patterns in data distribution, like skewness or outliers.

Bar Graph: Useful for comparing different categories, like defect types, department performance, or product variations.

Citation: According to Dr.Robert Buckham the data is actually from an actual project he worked on years ago.

Attached to this blog post is a link to an excel sheet with the defects calculated and the three visualizations designed by us students in class.

Attachment: 
data-analysis.xls


Reflection 

- I think my rendering skills are limited, and the designs of the charts are very basic and somewhat outdated. I’m one of those people who believes that the way data is represented adds to the ethos of the data. Having a more visually engaging presentation could help make patterns more intuitive and spark curiosity for further analysis.

- One thing I realized while doing this is that this method of quantifying data doesn’t apply to much of product development. This approach only works for a manufacturer producing a homogenous product; applying it to a software company that follows an iterative process for problem-solving wouldn’t make sense. I also realize that it assumes a lot of things remain constant (employee satisfaction, raw material quality, quality of assets and machinery, defects in production, training time, etc.). It ignores a lot of nuances and really just gives a false sense of quality control. I’m realizing these things as I write, and I find that I really dislike how this data is represented. I don’t understand why people thought this was a good way to tackle problems in the final stages of production. I’ll discuss this with my professor.

Comments

Popular posts from this blog

Bad Data

Digital Humanities: Week 1 Reflection

Good Data