ANLY482 AY1516 G1 Team Skulptors - Methodology
 HOME
|
 ABOUT US
|
 PROJECT OVERVIEW
|
 DATA ANALYSIS new!
|
 PROJECT MANAGEMENT
|
 DOCUMENTATION
|
| Summary | Description | Warehouse Tour | Methodology new! | Technology new! | Limitations & ROInew! |
Before – Usage of Pie Charts for Data Visualization
Pie chart was initially opted as one of the visualization graph to be used on the dashboard. However, due to nature of it, the team decided to not use pie chart in the dashboard. This is due to the following reasons.
- Space consuming
- The space consumed by each slice to form a pie is much more compared to a bar graph. As there is space constraint in the dashboard, Prof did not recommend the usage of it.
- Rigidity in color
- Unlike in a bar chart where all individual bars can show the same color, in a pie chart, each slice of the pie has to be represented in a unique color or it would not be easy to see. Hence, in this scenario where the team wanted to use a pie chart to show 20 top moving SKUs, it can be really and this can be very distracting (as shown below).
- Misleading and not explicit
- The data visualization of data is based on a pie hence, it is easily misinterpreted wrongly as it seems less accountant compared to bar graphs. They are thus, often a wrong way to represent subtle but important differences. It is hard to point out which segment is the biggest or smallest, just by looking at the pie chart itself.
- The initial pie chart was coded in a way to be sort the largest slice to the smallest slice in a clockwise direction. This however, was explicit enough to be picked out by the sponsors.
After – Usage of Bar Charts for Data Visualization
Hence, based on the context of this project, the team switched from pie charts to bar charts as it will provide a better summary of a large data set in visual form.
With the usage of the bar chart now, this will better allow sponsors to do the following:
- Clarification of trends
- Compared to a pie chart, the bar chart provides a quick visualization and impression of the trend of data. By incorporating a sort feature, this will also allow users to not misinterpret data easily.
- Timeline visualization
- In a warehouse data analyzation, it is important for sponsors to track the changes of inbound and outbound frequency of SKUs over time. Hence, the usage of bar charts instead of pie charts is preferred in this scenario, as pie charts are unable to track changes over time.
- In a warehouse data analyzation, it is important for sponsors to track the changes of inbound and outbound frequency of SKUs over time. Hence, the usage of bar charts instead of pie charts is preferred in this scenario, as pie charts are unable to track changes over time.
Before – Inadequate Information on Inbound Control Chart
The initial inbound control chart only showed the quantity of incoming SKU by month, throughout the year of 2015. The purpose of this graph was to allow sponsors to have a visual sense of how the warehouse inbound pattern was like throughout each quarter of the year.
After discussion with the sponsors, the group understood that in the logistic industry, the company follows an 80/20 rule in the control chart. Hence, the 80% upper quartile, 20% lower quartile and the mean of the inbound quantity were added into the control chart to suit the sponsor’s needs. This will allow sponsors to be able to easily identify the time periods where inbound warehouse were beyond or beneath the upper and lower quartile, and adjust their inbound rate accordingly.
To allow sponsors to interact and find out the exact quantity for each individual month, mouse over tool tip feature were added onto the inbound control chart. This will allow the clients to be able to find out the month and inbound detail easily.
After – More Informative and Interactive Inbound Control Chart
Initially, the team used row count to count the quantity for the control chart. However, this was subsequently changed as the team realized that it was incorrect to do so. This is because a single transaction row can be translated into many pallets (i.e. takes up a lot more warehouse space). Similarly, a single transaction row can also be translated into less than 1 pallet (i.e. takes up a small warehouse space).
To further improve the chart, the team also decided to develop input fields of lower and upper limit. The rationale for doing so, is to provide clients with the flexibility of changing the lower and upper bound limit in the future. In addition, instead of display just figures in the tool tip mouse over feature, the team added in a bar chart visualization. This visualization will allow clients to further find out the top 10 particular SKUs which are contributing to the inbound, and their extent of contribution.
Before – Misleading Pie Chart
The pie chart graph was initially used to depict the Top 20 fastest moving outbound SKUs. However, as show in the above figure, it was relatively space consuming and requires the use of scroll bars in order to view the entire pie. Moreover, it was also hard to tell which pie slice was bigger when they look similar to each other. Furthermore, the coloring of the pie tends to be distracting as it is too colorful (Mollot, 2015).
Under the advice of Prof, the group switched to a horizontal bar graph with a single color for a cleaner design. This allows users to quickly spot which SKU has the most / least outbound rate at glance, as shown in the above figure. Nonetheless, it was a static graph and not interactive.
After – More Informative and Interactive Top 20 Bar Chart
To improve interactivity, the group introduced the used of mouse over tool tip features. In above figure, the mouse over displayed the SKU ID and its frequency. This reduces the time needed for users to find out the details of each unique bar.
Upon the advice of Prof, the group changed the mouse over tool tip feature to display an additional more meaningful detail – The unique line chart for each of the specified SKU bar. This line chart will be used to show the unique trend across the entire year, for the particular SKU. However, this led to a bug where the tool tip’s content exceeded the canvas as shown in Figure 4. This meant that scrolling was required again.
To solve the problem, the group implemented a condition to limit the tool tip’s control chart content, by fixing it within the specified page’s axis position. This thus, reduces the need for scrolling.
In the above version of the bar chart, the team realized that as each SKU has a different minimum quantity at the y-axis, it can be rather confusing and misleading for the clients when they are viewing the line chart.
Citing the above problem that the team faced, the team decided to tag the line chart’s y-axis minimum value, to the lowest quantity value of the top 20 SKUs. This thus, provides a more representative and accurate visualization for the clients.
After much consideration, the team decided to include a date start and end field. This input field will come into use when clients wish to shortlist the Top 20 SKUs and their frequency of an input time period. This allows and promotes interactivity as clients are given the flexibility to play around with the time period and not be constrained to a specified time frame.
Before – Input Fields with 3 Result Columns
The ABC sorting sort was designed accordingly to the client’s needs. This is to allow them to input the respective criteria for each classification, in a specified time frame. Based on the constraints, the dashboard will generate out SKUs in each of the three classifications. The results displayed in each of the classification can be validated through the following logic. Transaction amount in this case is by the number of rows in the dataset. Assuming the input for classification A, B and C are 20%, 30% and 50% respectively, the highest outbound transaction (in this scenario), will be SKU “3617858” with an outbound transaction of “1111”. Hence, since classification A is the top 20% transaction, any SKU that has the transaction count of 888.8 (1111 * 0.8) will fall into this classification. Similarly, for classification B, it is the 30% SKU that follow suits. In this case, classification B's SKU will have transaction count of minimum 555.5 (1111 * 0.5) until 888.8. And the remaining SKU will fall into classification C. Since all the classification only have SKUs with outbound transactions as listed and explained above, we can validate that the result output in the following three columns are right.
After – Input Fields with 3 Result Columns & Tree Map
After realizing that a tree map can be used to display the same classification in a more easily and explicit way, the group sought approval on the use of tree map from the clients. Although the clients were initially not receptive to it as it seemed confusing, they readily agreed after the group explained the usage of the tree map to them. Nonetheless, the clients had still requested for the 3 result columns to stay. This is because it is still easier for employees to understand it although they have no knowledge of tree map. However, with the inclusion of the tree map, the scroll bar has to be included as the content of the site exceeded the space limit.
In this version, the group added in a search query feature to allow clients to search for a particular SKU which they might be interested in, to find out its classification. The group also included validations to handle possible input mistakes by clients.
To eliminate the usage of the scroll bar, the group heeded Prof’s advice to hide the input fields and classification column. This will allow clients to easily have a sense of the amount of SKUs which are in the various classifications with the tree map, without the need for scrolling. Nonetheless, should the client wish to perform a search or change the criteria of each specification, they can easily do so by clicking on the “unhide” button.
Before – No Inbound Summary Landing Page
Initially, there was no landing page to show the overall summary of inbound transactions that was happening in the warehouse. There was however, 3 separate tabs for clients to view the inbound analysis respectively. They were the control chart (landing page), time series and transcode tabs. During the client meeting, the team received feedback that the clients found it troublesome to be constantly clicking on each tabs to gain a rough summary of the overview of the inbound movement.
After – Addition of Inbound Summary Landing Page
Heeding the feedback of the client, the team decided to develop an additional inbound visualization summary, on top of the initial 3 tabs. This summary page will double up as the landing page for the inbound category. The objective of it is to provide clients with an overview of the inbound transactions before they zoom into the more detailed analysis of each inbound sub-categories.
Before – Warehouse Utilization (Putaway & Pick) on Tableau
The initial warehouse utilization was done on Tableau. However, as we can see from the figure above, the “heatmap” within the warehouse layout, stretches across a very long scroll bar. This is due to the inclusion of the "location" variable. As the team felt that it was rather not user-friendly since the clients have to scroll through the entire list, the team decided to make further changes to it.
After – Customized Coded Warehouse Utilization (Putaway & Pick)
To alleviate the problem above, the team coded out the row and column of the warehouse layout, without the inclusion of the “location variable”. The location will instead now be displayed after the client clicks on a particular box on the heat map. Not only did this change minimized the scrolling required by users, it also showcases interactivity within the dashboard warehouse utilization site.
Before – Drag and Drop Into Specified Path Directory Folder
Initially, the “uploading” of data into the dashboard will require the clients to drag and drop the data which they wish to analyze, into a specified folder in a path directory provided by the team. Although this method works, the team felt that it would sooner or later become a hassle for clients since they have to consistently navigate through the folders to place the data into the fie directory. Multiple clicks of the mouse is needed to complete this simple task too.
After – File Upload Feature
To reduce the number of clicks to accomplish this task, the team decided to implement a file upload feature, integrated onto the dashboard itself. This feature proved to be well-liked by the clients as it automatically ports the data file to the path directory folder destination. Not only was it straight forward and intuitive, the process of manually dragging and dropping the data files through folders was also eliminated.
Before – Manual Execution
Previously, after the data file has been placed into the path directory folder destination, the clients will have to start up 3 different cmds. This is to load the data from the data file into the dashboard. The first cmd has to be opened to start the MongoDB server. MonogoDB is a cross-platform document oriented database which the team had selected for usage since it was free and easy to use. The second cmd is subsequently started to import the medical brand data into the MongoDB’s database, while the last cmd is used to run the node package manger. Although this way of execution may seem easy, it can be tedious for the clients. This is especially so when they are not familiar with the cmd.
After – Automated Execution
To ease the numerous steps, the team created a bat file script to execute the above three tasks. This meant that the clients will now only need to double click on the bat file once to port in the data into the dashboard. Our client can also click on the bat file to start up the web page. This thus, makes the dashboard more user-friendly and easy to use as they will not need to remember the commands to start the application.
For the list of methodology & technology proposed during the proposal stage, please refer to: Team Skulptors - Methodology & Technology
