Bringing time and motion studies up to speed
ISE Magazine Volume : 50 Number: 6
By Karen Craig
Work measurement should not be the least efficient process for driving efficiency
The time and motion study is one the most essential industrial engineering tools. These studies are what bring to light the inefficiencies in a given process, yet most companies are inefficient with how they deploy a time and motion study. It’s time to change that.
Where it started
The traditional method for the time study was first established by industrial engineers Frederick Taylor, Frank Gilbreth and Lillian Gilbreth in the late 1800s and early 1900s, and it is still taught in colleges today. The traditional method includes thinking through what needs to be studied, separating out the process into tasks that are measurable, writing them out on paper and then measuring using simple devices like stopwatches and counters.
The traditional method of paper and pen, stopwatches and counters is far outdated. First, there are often data integrity concerns while collecting data. The data cannot be exact because the analysts spend time looking at the stopwatch, writing down the exact time (typically to the milli-second) and then looking up again to capture the next data point on time.
With new technology, IEs began to push the envelope for time and motion studies: Studies became mobile. Film and video cameras were invented, allowing observations to be made from a distance. It took out some of the bias and pressure created from having someone stand next to subjects while the workers were performing tasks.
Palm pilots and other early hand-held devices provided an opportunity to track steps in the process and take notes without having to write on a piece of paper. Many types of studies benefited from hand-held devices, including psychological research studies. In addition, the smaller hand-held devices were often seen by the study candidates as less alarming, less of a reminder that they were being studied. It is common that the hand-held device would be transparent to the study candidate, which reduced the Hawthorne effect along with promoting a friendlier relationship with the IE and study candidates.
GPS allowed for studies that involve tracking space with time. Small GPS devices could be added to any mobile item that needed to be tracked, including a person. It cut out lengthy measurements and estimations and replaced them with quick and accurate recordings.
Example: Palm Pilot time savings. One of the popular boardwalk-style outdoor shopping malls wanted a better understanding of traffic flow through the mall. The project needed observers to be placed at every entrance and exit through the mall to track traffic flow in and out. Additional key observers were placed at more popular stores and dining areas, as well as turnarounds and large seating areas.
The standard study tools of pen, paper, clickers and stopwatches for this study were not ideal, as traffic flowed quickly. What the researchers really needed was a way to click on a device continually as traffic moved across a common point, while the device captured the time stamp and count. This was done by programming a Palm Pilot.
The interface was very basic – just a few buttons for ins and outs and a location field for where the observer was standing. The back end was programmed to grab the time stamp and count each time a button was clicked. Someone knowing the Palm Pilot language could update a script like this within minutes, but someone who has never programmed before might take an hour to do this type of work. More than 30 observers used these Palm Pilots, and data was downloaded within a few minutes per device. Data was more reliable than what would have been written down on pen and paper. A few hours of programming on the front end took out the hours of time typing up data from handwritten papers, and significantly more data were captured than what had been captured in similar studies.
Rapid application development platforms
Recently, many rapid application development platforms have entered the market. The idea is to provide a platform for a user to build an app rapidly, usually through drag-and-drop features, and deploy it rapidly. The drag-and-drop style eliminates the need to understand code, so really anyone can build simple apps quickly.
There are several platforms that require absolutely no coding experience – “no code.” But most of the platforms require a little coding to add complexity to the app – “low code.” For a generic time study, any of the platforms can produce a custom app quickly.
For an industrial engineer, the feature to consider with these platforms is online/offline data storage capability. Many of the platforms build apps that have to be deployed using a web browser or require Wi-Fi to store the data in a cloud system. Time studies taking place outdoors without Wi-Fi or in a manufacturing plant that might not have Wi-Fi would need to develop apps using a platform that has offline data storage capability.
Why it’s worth learning
Learning how to build apps in a rapid application development environment will prove worth it in the long run and lead to faster and more complex data collection that is reliable. Again, it does not require programming knowledge.
Opening the door to building apps can open the door to collecting data that previously seemed impossible. Many of these platforms allow for barcode scanning, which allows for quick data scans through a process without typing any data. Many platforms include the ability to take pictures or video and save them instantly. Some platforms also include GPS tracking, so it does not have to be done separately. More advanced platforms even integrate with beacon technology.
Using a hand-held device with a custom app can lead to improved data integrity. These development platforms include complexity to limit how data is entered.
For example, rules can limit when data fields are available for data entry to prevent a data collector from moving out of order in a process. Rules can also limit fields to certain data types. For example, a field that should have data will not allow for counts or time stamps to be entered instead.
Using an app limits data entry errors. The data is exported and identical to what was recorded. There could still be data entry concerns to consider, but the computer entry errors will be eliminated. Think about the time spent manually entering data or manipulating it while compiling. That time can now be spent on different studies or on more samples of the study on hand.
One of the most appealing aspects of time study is that it can be conducted anywhere. An observer is no longer limited to hoping the environment is controlled with their clipboard, pen, paper, stopwatch and counter ready. The observer has to merely pull out his or her phone when the factors line up and collect the sample.
Example: FileMaker – data calculations. An entertainment-based service industry wanted to understand how long some of its lines were taking. The corporation did not have time to do continual time studies by using a stopwatch, recording data, analyzing the information and determining the result hours later. Pre-built applications found in the Apple Store allowed for time stamps to be collected and a calculation per record to see how long its customers had spent waiting. However, there was no way to average multiple records together to get a meaningful sample.
The research group found FileMaker and quickly built a solution to collect, record and calculate fields with running averages. The drag-and-drop features allowed the analysts to build an app that would deploy on their iPhones and capture time stamps of guests. A calculation was created by making a function similar to an Excel function to subtract one time stamp from the other.
To take it a step further, the researchers created a running calculation, similar to a summation in Excel, that allowed multiple records to be averaged to give an average wait time for the guests. To make the app really intuitive, a hidden condition was put on the second time stamp to allow it only to show if a start time had been selected. This function was native, or built in to FileMaker, and required no scripting from the analysts’ team.
They also added warnings to the app. If a time was lower than a typical wait time or twice as long as the typical average, a flag would appear to suggest that the data was incorrect. The record could either be deleted or saved. If the wait time was truly much longer than expected, the operators had an immediate warning that they needed to change something to help the wait time. The data entry was quick and reliable, and the calculations were instantaneous, allowing the operation to conduct its own time studies and act on the results.