One of the challenges when designing reports and benchmarks is how best to factor in location as one of the criteria. Very few reports, metrics, or benchmarks that relate to resourcing can be considered to be completely meaningful without taking location into account. For clarity I’m going to use the term ‘benchmarks’, but the principles are the same for reports, metrics, benchmarks, and other related objectives. Because of the need to reference location, it is important to decide on a suitable location strategy.
There are a number of different approaches to referencing locations in benchmarks and I wanted to share a perspective on the two main ones.
- Hierarchy– When location data is captured in most VMS, ATS, CRM, and other systems, it is frequently recorded as flat data fields (Country, Region/County/State, City/Town, Street, Property Name/Number). Sometimes, aspects of these flat data files will be hierarchical; that is, the user can only pick a region within a chosen country, a city within a chosen region, etc. From a usability perspective, this structure is very logical and gives the option to analyse data at a country or collection of countries level, at a region level, at a city level, etc. The challenge with this approach is that it doesn’t recognise the relative geographic positions of cities within the hierarchy. In the UK, Plymouth, Bath, and Hull are close to county borders; in the US, Jersey City is in the state of New Jersey, but is just a river crossing from New York City and certainly has a stronger relationship and influence there than it does with Atlantic City, which is also in New Jersey. Perhaps a benchmark shouldn’t be looked at in isolation within that county. Certainly the catchment area for staffing role falls across county and state boundaries.
- Geo– A complementary option to Hierarchy above, therefore, might be to look at the relative geographic position of data points independently of notional country, region or city borders. In the past this has been hugely expensive with geo data based upon post codes/zip codes being priced at a premium. However, these days geo data is much more readily available, even open source in some cases, and being able to calculate data points within a defined radii of a given location becomes a more affordable option. It remains something that requires some innovation and skill to achieve and it is certainly beyond the capabilities of many reporting engines that are the standard offerings of core technology platforms. So whilst Geo-based benchmarks may be an aspirational goal to truly best reflect the relationship between data points, the business need for the benchmark may not justify the effort involved in achieving that goal.
Both of the above approaches are valid when including location in benchmarks. The best approach will be defined by a combination of practicality and the nature of what is trying to be measured. For example, a job role may be associated with a specific location, whereas candidates may be associated with a catchment area around a specific location. The important point is to consider options when designing a solution that is both practical to achieve and best reflects the nature of the benchmark being created.