Description of Concept
The Coolearth Labor Tracking System implements an industrial engineering process management practice by establishing a computing infrastructure and performing data collection and monitoring to calculate the “standard time” in which a given job should be completed within the plant/warehouse given all of the complexities of the work— the layout of the shop floor, doors, shelving and hallways—the location, quantity, weight and makeup of the object being worked upon or moved—and the speed of the tools employed to accomplish the task such as a production line or a fork-lift—and finally the human factors which determine how long a person takes to do a given task taking into account schedules and potential fatigue. This standard is then compared with the actuals, being the measured times that the task did take.
The system must do forecasting to predict what work will be required, since it knows about standards and what staff are available, it can also decide what kind of staff levels are appropriate or what kinds of yields to expect.
The system will also track all of the available work and hand it out in various workflows to workers within the plant. Times are collected at the beginning of each job (the beginning of a job signals the end of the last), until the worker clocks out. An extensive reporting system is also included to evaluate employee adherence to the standards, compute staffing requirements, and produce similar planning documents.
This practice affords considerable initial return since usually those unaware of these techniques typically operate at less than 70% efficiency. This also does not overtax the workforce, since 100% is an average which anyone should be able to meet. With incentives for performance (which can now be exactly measured), work output better than 100% is not unusual.
Ongoing operations within the plant are much more efficient and predictable, allowing much better insight into the true metrics of the facility, allowing much more accurate forecasting, planning and modeling. An operational change can be modeled and implemented with more confidence since staffing needs and expected yields will be more predictable.
New standards are usually developed by the companies Industrial Process Engineer. Coolearth may be able to assist with this effort with the installation of various temporary or permanent devices which can be keep track of the physical location of personnel and equipment in real-time and other hand held, fixed rack, or fork-lift mounted computers which can be used to record and dispense job information.
Click on image to view details.
|
Figure 1 - High Level Conceptual Architecture |
Sources of Job Specifications
The parameters of job specification come from several places – most of these have to do with the physical characteristics of the work itself. How many cases must be made or moved, how big are they, how much do they weight. The ERP system or Whistle will often contain most of these data. For some, they may vary by the items actually being considered (the parameters are dynamic), such as weights for catchweighted items. This can also be affected by the geometry of how pallets are packed, such as how high they are, and how far someone must bend over to pick something up.
Also, the base standards need to be kept for the individual jobs – these are the raw standards which are used to calculate the actual standard for a given situation given all of these variables.
Sources of Physical Geography Information
Once the item to be worked is characterized, where the item is stored (or produced) and where it must be put is calculated. What rack is it on, which forklifts can pull items from those places, what is the optimum path to get from one place to the other (if this is not obvious), and how long, based on the speed of the forklift will it take to put it away.
Geography and routing can be quite complex. Racks and doorways can be in non-optimal places—items may be destined for faraway sites.
It is possible, if the system has computed an optimized path to show that to the operator. Similarly, if the system knows where people are can direct them to work that is closer to where they physically are, shortening the time.
Information about Worksite Tools and their Specifications
Production lines, and fork-lifts, pallet stackers, and many such tools have maximum throughput or speed characteristics. Operators have little control over these aspects of their job. Similarly, equipment failure or temporary breakdown can cause interruptions to plan. The capabilities, schedules, and difficulties encountered with devices must be characterized and logged.
Plant and Personal Schedules
Once the above is known, it is then possible to marshal the total resources of the system to accomplish the workload of the plant. At this point, the desired yield is matched up with available personnel resources to build the work plan.
Sales orders, shipping orders, purchase orders, production orders can all be analyzed to determine what work is needed or scheduled when in order to produce a calendar. This can then be matched up with the shift schedules, and the personnel schedules to determine the workforce needs for a given period. At this point the yield can be forecast to a reasonable accuracy. This kind of work scheduling can be done for some period into the future, but it should also be able to adapt to unexpected conditions (such as a surprise order, a large equipment failure, missed supply delivery or bad weather).
Collection of actuals (times things actually took to accomplish)
Actuals are the inputs from the time clock as a new job is assigned. This can be done from a central terminal, or can be done via a fork-truck mounted computer or a handheld. It is even possible to auto-assign jobs based on inside-warehouse absolute positioning systems which track the location of people or machines like fork-trucks to a high level of accuracy. The system can give the job to the operator who is closest to the work and start the clock automatically and display what is to be done and continuously update status on the fork-lift display. The operator doesn’t need to do anything to facility data collection.
Break times are often automatically entered or are entered by the operator or their supervisor. Downtime caused by equipment breakdown, spills, or other warehouse situations are added to the system by supervisors. It is possible for the operator to use his computer to request such a downtime entry by the supervisor, who signs off and makes comments.
If, during the execution of a job, the operator would normally interact with their computer (logging barcodes, doing move operations, etc), a break in this pattern can also be used by the system to detect that a downtime event is in progress and escalate an action from the supervisor.
The Workload (Jobs/Tasks)
The individual jobs that are in the queue are a function of which parts of the WMS systems control the jobs, such as shipments, replenishments, picking, putaway of received items. There are tasks surrounding the inputs and outputs of the production process – picking for issuing, putaway of produced items. There are also tasks involved in the production lines themselves—some of these are governed by the speeds of the lines, but for some the speed of the line is determined by the speed of the operators, filling orders, boxing and labeling product. There will need to be a module which interacts with each of these types of orders from the ERP system, and there will need to be some manual systems for order types which do not have an analog in the ERP world.
These all get boiled down into individual “jobs”. Some of these jobs have their own operational area and dedicated staff. Some types of operators within the warehouse can take jobs from several different areas, such as using the forklift for issuing, shipping, replenishment, receiving, production putaway, cycle-counting, etc. Certain operators will be specialists, always taking a given set of jobs, and other operators may not be trained in all areas. The system would only assign jobs appropriate for a given operators profile.
Items in the job queue have priorities and status information associated with them – some items may be higher priority than others. Some jobs, such as dealing with items produced to stock, may have a lower priority than items which are ready to be shipped to a customer. A line which is expected to go idle due to a shortage in a WIP item may cause that item to have its priority increased. Trucks coming into the dock will change the priority of orders intended to be shipped on those trucks.
The Standard
Standards for a given job are broken into “elements”. An element is a discrete sub-job, when executed in proper order, complete the job. If element 1 is “load boxes onto pallet” (more likely it would be broken in many small intermediate steps), the count, weight and configuration of the “from” and “to” location will affect the standard time for that operator. In that example, a human operator will be doing the work. Human performance is also affected by fatigue and the need to take breaks during the workday. Other elements of the job may be primarily driven by the performance of machines (and the skill of the operator to control the machine) like “Truck pallet and put in bin X”. This requires the calculation of the optimum routing through the warehouse from the current location to the putaway location. The system would know the geography of the floors, shelves, and the location of all of the bins, dock-doors, etc. It would also know the capabilities of that particular fork-lift, and the fastest safe operating speed for that path (or for general forklifts in that area—everybody must slow to go around this corner to avoid pedestrians). Once all of these elements are computed, it is a reasonably simple matter to compute the standard. The elements are just added together and multiplied by the number of times the process must be repeated.
Routing
Geographic navigation through the facility is a rather large component of the total time calculation. Figuring out the fastest safe way to get from point A to B is rather complex. However, since equipment speeds are mostly constant, the routing can be simplified down to a series of core routes (main corridors) which tend to be very static and can be precalculated and kept in a database for quick lookup. The design and optimization of the routing module will likely be the most technically complex part of the system architecture. These routes can also be tested in real time operation if the equipment has been outfitted with location monitors. If the operator takes another path, this can be noted, but speed assumptions and paths can be tested, verified or modified to fit the reality of the equipment and the space.
When the operator has finished with their previous job, the system will assign them with their next job from the queue. This can be done on a fixed terminal, or on a forklift-mounted terminal or handheld terminal. If they have mobile computer, the system can direct them to the work. They then execute the elements within that job. Often these have computer interactions, like for scanning barcodes for pickup and putaway, so the computer can tell where they’re at in the process. It can then dispatch them to the destination. Often this is iterative – move these 50 pallets for a given outgoing shipment… The system will help them through their workflow, especially if they must produce documents or scan certain items to complete the operation.
Once finished they can then take the next job or clock out for a break or end of day. The user selects a job by picking an order off of a list.
When we do a some gap analysis to discover what systems are needed build a labor tracking system, there are some new data which are required that don’t exist in any of the existing systems. In a few cases, some minor modifications will be required to existing databases.
Time Standards and Element Detail
The time standard is the specification of the time study for a given “job”. The elements are the individual steps which go into a job. Elements can specify other jobs so that common elements of jobs be defined hierarchy, such that only one given task be defined once even if it is done in several different jobs. If there are decision points in the element, there is a way to specify this behavior (if X do A else do B).
Dependencies
For a given job to be executed it must be given to an operator with the proper certifications and skills and with equipment with the proper capabilities. These are called dependencies. If a bin sits on, for example, the third set of shelves in a shelving unit, only forklifts with the ability to reach that high are able to service it. So, that bin would have a “THIRD-LEVEL” dependency—when a putaway is scheduled for that bin, only Forklifts with “THIRD-LEVEL” capability would be scheduled. It is possible too, that the operator must have a “THIRD-LEVEL” certification. All of these would go together to determine how jobs are scheduled.
Equipment Characteristics
Different equipment has different kinds of characteristics. A forklift for example will have a maximum speed, a maximum lift capability, or a maximum reachable height. Some things interact, like the maximum safe speed when carrying a given load with forks lifted to a certain height. This affects how you would calculate elements regarding motion when doing standards. There is another aspect to this, which is the ability to monitor safe operations practices, which can added to the labor tracking and reporting. Devices can be attached with capabilities which fulfill the above job dependencies.
Job Source Module Rulebases
There are many sources of work that exist within the ERP system such as a Sales Order, a Production Order or such. Whistle too, will generate work, the output of production and palletization will generate an implied putaway job, for example. This rulebase will configure the different job source modules (code to import and interpret the job information from these various sources). This would setup which records to process, when, and how queue entries would be created and what attributes and priorities they’d be given.
Job Database and Queue
Once jobs emerge from their source modules above, they are scheduled and placed in the job database. This database is a queue, which is sorted in various ways, typically by priority and then by age. Jobs are only eligible to run if all of their dependencies can be met. Otherwise these jobs wait. Jobs are then handed out in order. The last few jobs to be handed might also be further sorted to hand them to operators physically closest to them. Jobs can be rearranged, reprioritized, put on hold, or have their dependencies modified. Jobs can also be modified or pulled by the ERP system when their underlying controlling document is modified –changing lines on a sales order, or having an order cancelled. Jobs can be broken into sets, each managed by a different operator, or all done by one operator. One operator can be tasked to do all 50 pallets for a given shipment, or this can be assigned to 2 operators.
Actuals Collection
Actuals collection is a reasonably easy process. Typically there is a time clock which is continually running. Once the next job in a sequence begins, the previous job ends. It is possible to record interim times/throughput along with physical location. Actuals collection is mostly passive, getting timestamps from activities that are normally done during pickup/putaway in the WMS system. In a fully wireless system (typical), the next job can be picked from the screen. It is then possible to send the operator to the nearest work.
Breaks and Downtime
Operators will have standard breaks during their workday. They may also be granted breaks by their supervisor. Standard breaks they can request on their systems and have them automatically granted. Supervisor breaks are entered by the supervisor. Normal operations can also be interrupted by many types of downtime during the course of the day: breakdown of equipment, accidents/spills, production line delays, computer problems, late trucks or supply shipments—any of a host of things. The supervisor can tag these as downtimes on the operator’s time for a job. They can give the event a description, and can tag safety violations (like for an accident).
Warehouse Topology/Geography
To route the operator from one point to another in the warehouse and figure the optimum safe travel time, the system must know where everything is. It must know where the bins are, the doors, the dock-doors, and it must know where all of the passageways through the warehouse are. It is possible to pre-calculate a great number of the optimum paths beforehand (if the speed is constant). Other paths it must calculate on the fly. It should be possible to graphically show the operator the path it is expecting the operator to take.
Bins
Extended Attributes for Bins
Bins have an input and an output area (which are usually the same). These need to be characterized in 3d, recording the 3d location of the lower points of the entrance (the left and right bottom), and the height, resulting in a rectangular plane.
Some of the following attributes might also be useful to help picking (most bins won’t need all of these—depends on how the warehouse has been designed):
Some warehouses practice arbitrary stacking, where heavy duty creates/pallets are simply stacked arbitrarily in the warehouse. Tracking some additional information would make it easier to inventory this kind of data. Usually, you want to make is so that product is not blockaded (made unreachable by product in front of it) – but sometimes the opposite is entirely the point – some warehouses (usually freezers) are simply stocked tight to the brim when flood a product comes in during harvest or some similar burst of production, so that the space is maximally utilized. Having better bin tracking – possibly with the ability to track the physical position of the boxes – would be useful (though not so much if product is homogenous).
Generic Bins
The use of the traditional generic bins such as SHIPSTAGE, RECSTAGE, PRODSTAGE etc, might need to be refined. If these logical areas correspond well with a single physical space, it should be characterized physically (given 3d attributes) so that the routing system can plan for them. If not, then it might be necessary to do essentially a double-putaway (in the warehouse management system), moving them into a more physical bin after receipt or production, such as a DOCKDOOR3STAGE or PRODPACKOFF3STAGE. These are then picked and moved to their ultimate location via the enhanced labor-tracked extensions in the WMS. The WMS can also be enhanced to simply receive and produce to more explicit bins depending on configuration and location information.
Before labor tracking it was not really interesting to know the intermediate bin locations to this detail, but having them will greatly assist in better calculation of an accurate standard.
Future Bin Functionality
Creating and configuring bin will become more difficult since they must now have 3d coordinates attached to them. This might be able to be made easier by the addition of a new idea called the metabin. The metabins are a handful of automated bin generators which can handle different types of real-world warehouse configurations, like:
We can add metabins for other arrangements of bins as they are characterized.
Operator Profiles (Jobs assigned to which Operators)
The system must know the schedules of each operator and their certifications and what jobs they are going to be assigned to (just because an operator has a given certification doesn’t mean that their supervisor wants them to work those jobs) – the supervisor can micromanage this during the day, or let the automation deal with it. Operators can be assigned to work particular types of jobs, particular dependences, or within particular zones of the warehouse. Or, the supervisor can specifically task the operator with a specific job or set of jobs.
Daily and Summary Rollup Reports
Figures 2-4 show some of the potential reporting which can be done inside a labor tracking system.
Figure 2 shows the detailed breakdown of daily tasks and their ratings to standard for a given operator. The details include normal elements such as clock-in, breaks, and the various labor jobs which have been assigned during the day. It also shows the standards which have been calculated and how the operator’s performance on that job compares to the standard. It then rolls up all of the values into a grand total section along with some category totals.
Figure 3 shows a rollup of the above detail report by operator by day—showing activity for a given period (week, bi-weekly, or monthly). This permits supervisors to evaluate performance and determine if counseling is required or incentives might be awarded (this can also be built into the report if standardized levels of performance are determined).
Query Screens
There are also several other reports (or data query screens) which we might generate:
Forecasting
Figure 4 is a forecast of what level of work is expected to clear a given load (typically the number of outstanding sales or ship orders). It can be based on different expectations of the average performance of staff (this example includes a pessimistic estimate of 85% and a normally optimistic estimate of 100%)—sort of a worst-case/best-case forecast. These kinds of forecasts can then be loaded with staff (or call for staff to be brought in) to meet scheduling requirements and allow managers to control the yield.
Forecasting is based on the current orders which are in the system. It is possible to generate hypothetical future forecasts as well. A given period can be analyzed to generate a benchmark period. The forecast can then be run against this data. Additional functionality would also permit simulated trends to be added to the benchmark, such as the expectation of a given order on a given future date, or an increased run on the processing of given items. These data are overlaid on the benchmark to form a simulated dataset which can be reported against.
There is another type of forecast which may be done. This is to plot the rate of consumption against rate of production to detect when an out of stock might occur, or simply when standard picking areas should be replenished from other parts of the warehouse, or when things might need to be reordered.
Click on image to view details.
|
|
Figure 2 - Detail Summary for the Work Day |
Figure 3 - Daily Rollup for the Work week |
|
Figure 4 - Work Forecast at Two Expected Ratings (85% & 100%) |
The system should have the ability to exchange data with third party timekeeping systems such as Kronos. Being able to import clock in/out events might be useful and can be used to clock in and out of the labor tracking system. Also, the ability to export job begin/end timestamps into the timekeeping system might also permit that system to generate other reports where the timekeeping system has been used to build an extended job tracking facility.
There are a few pieces of functionality that can be added to the system that are not really related to Labor Tracking itself, but can be facilitated by the same system.
Compliance/Accuracy/Quality
Unfortunately, the downside of a time/performance based system can be lack of accuracy and so compromised quality. It may necessary to verify the items that have been picked or shipped. Errors of this type should be caught before they get to the customer.
There are some potential methods to maintain accuracy:
If this gets to be a severe problem, a feedback system can be used to place records onto the operators’ performance log to be considered along with regular standards compliance (this can include missed ship events, which comes after an error is discovered by the customer).
Safety
Speed is also the enemy of safety. The system might be extended to detect and log safety incidents. With some physical location monitoring, it may also be able to log avoidance of floor safety rules, such as door protocols (proper procedures for opening/closing doors), or speeding (the forklift can go faster than is safe in certain areas), or even driving in areas where the lifts shouldn’t be (pedestrian areas). Of course, this can go both ways, safety is not just the responsibility of the fork-lift operators.
Initially, the Labor Tracking system can handle normal warehouse/forklift operations such as putaway and picking. We would like to extend these to as many areas of operations and production as is practical.