If you’re familiar with labor standards, you’re also familiar with the term “driver”.  It’s a common workforce management (WFM) term used to refer to any data that impacts workload when applied to a labor standardWhen used correctly, drivers can maximize the efficiency of your labor model and support your labor strategy. 

So how do you know if your current tools are using driver data to their best effect? And which capabilities should you consider when initiating or upgrading your labor standard measurement tool? 

In OpusAxsium’s state-of-the-art work measurement solution, driver data represents measurements, counts, percentages, factors, and volume amounts that are maintained at node level (hierarchical level) and applied to labor standards. This blog post touches on some key ways in which Opus uses drivers to improve overall labor models. 

Let’s start with the three types of drivers used by Opus: static, volume and calculated. 

Static Drivers 

Static drivers have values (e.g., square footage, travel distance, number of checkouts, percentage of credit vs. cash transactions, sales floor size, etc.) that don’t vary much over time but may vary significantly by location. 

  • You can store static driver values at any node level in the hierarchy (e.g., store, district, region, company) and directly apply them as multipliers. 
  • You can assign a static driver value at node level for a specified date range by node. You can also assign multiple static drivers to analyze their impact on customized labor standards. For example, you can dial up or down the number of checkouts at a restaurant during the holiday season or the number of cash vs. electronic transactions at a hotel over Valentine’s Day. 
  • To analyze static data internally, Opus applies the value(s) on applicable days across the effective date range. 
  • Opus applies static driver values internally to calculate hours for standards validation or exports standards to WFM system. 

Volume Drivers 

Volume drivers are typically used to store data that varies significantly over short periods of time, such as customer traffic, item movement or price changes and other dynamic data elements that are forecasted in WFM. 

  • Opus looks at the bottom node for driver values and searches up the hierarchy until it finds a value or returns zero. 
  • To analyze volume data internally, Opus applies the value(s) on applicable days across the effective date range. 
  • Opus links volume driver codes to standards during the standards export process, but their values are not applied internally. 
  • Each volume driver can be assigned a value for a specified date range by node and can be stored at any level in the hierarchy. 
  • It’s a good practice to match Start and End dates for each volume driver value in Opus to your company’s beginning and end of week. 
  • Opus applies volume driver values internally to calculate hours for validation reports. 

Calculated Drivers 

Calculated driver values are generated using a formula which may include static drivers, mathematical operations and numeric constants. 

  • They’re generated dynamically and are not stored in the system. 
  • Calculated drivers are associated with labor standards in a similar manner to static driverand are applied to hierarchy nodes with effective and end datesFor a given hierarchy node, the calculated driver also inherits the effective and end dates of any static drivers in its formula. 
  • The result from the calculated driver is applied as a multiplier to the associated labor standard. 

 Here are some examples of how to apply these three drivers 

Drivers as Frequencies 

One of the key functions of a driver is to act as a frequency for the standard. Let’s say you operate a boutique chain that has a standard for setting up displays. You’ve determined there’s significant enough variation in the number of displays from one location to the next, or one season to the next that they should be tracked in Opus.  To allow the output for that standard to vary based on the number of displays at each location, Opus uses a static driver, links it to the standard, and loads the display driver values for the locations and applicable date ranges.  If the frequency value doesn’t vary significantly, or perhaps it varies but has little impact on labor, the frequency can be built directly into the labor standard foundation iteration without using a driver. 

Drivers as Adjustment Factors 

Static drivers are also commonly used to adjust overall output for a labor standard up or down, based on a factor derived outside of Opus. Often these adjustment factors are used to bring labor standard output into alignment with budget or planning numbers. In these cases, the driver provides a percentage increase in labor when the value amount is greater than one and a decrease when less than one; an adjustment factor of 1.20 would reflect a 20% increase in the labor needed, while a factor of 0.95 would mean a 5% reduction. Combining more than one adjustment driver to a standard will have a multiplicative effect on the overall result and, as with other drivers, these adjustment factors may exist at any level in the hierarchy. 

Drivers as Fixed Hours 

Sometimes static drivers are used to directly specify the hours to be generated by a standard.  In this case, the labor standard value may be set to a constant such as 60 minutes, and the standard is a fixed type. So, if you wanted to assign 120 minutes of labor from the 60-minute standard, you would set the driver value for the location to 2 for the applicable dates, etc. 

Drivers to Split Labor 

Static drivers may be used to apply a percentage breakdown or blend to standards that are shared between multiple jobs or tasks. Let’s say you want to direct 70% of the labor for a standard to one job and 30% to another job and want to customize this mix based on location and date. To do this, you would create two versions of the same standard, giving them unique names in Opus: Standard XYZ assigned to Job A and Standard XYZ assigned to Job B. Then, you would create two static drivers—% Job A and % Job B and link them to their respective standard.  This mix between Job A and Job B can then be applied to locations in Opus using these new drivers. 

Complex Static Drivers 

There are times when you may want to create a formula to derive a driver value that is then applied to the standard. This is where calculated drivers come in. So, if you wanted Opus to calculate the ratio between one static driver and another, you would first create a calculated driver with a formula such as [Stat Driver 1] / [Stat Driver 2].   

The result for this formula is calculated dynamically and applied to the linked standard each time a validation or export is run. Since the Stat Driver 1 and Stat Driver 2 values vary by location and date, so will the calculated driver output and ultimately the standards output. You can also set up more complex formulas involving multiple drivers and math operations. This is often the case when retailers want to convert formulas over from other systems that have a labor standard or driver structure that differs from Opus. 

Drivers are a crucial aspect of creating effective and deployable labor standards and can, when used to their full capabilities, introduce consistency in the way employees work, help reduce wasted time and boost productivity. Opus gives you the ability and flexibility you need to create, maintain and deploy your labor standards to your stores through integration with your WFM system. 

If you need to upgrade your labor standards and improve your operational efficiencystart with your driver data. Contact us today to discuss how best to integrate it into your WFM strategy.