Data is the future of the loss prevention and asset protection industry. A single, data-friendly LP professional can both identify and address leading indicators of loss for a significant grouping of stores, with no need for airfare, travel, or company car. Identification and correction of these leading indicators driven by this single analyst could rival the internal and external apprehension total for a comparably sized span of control with a full staff of loss prevention associates.
The pyramid image shows a matrix that, when understood in its entirety, can provide a foundation for being successful in data analytics. This is the P³ Pyramid. It is broken down into three pillars of understanding, each of equal importance: process, protocol, and platform.
The platform piece refers to the technical or systemic limitations available in any system or operation. It is imperative that all AP professionals become experts in the full abilities and limitations for every system or operation in the store. As an example, let’s discuss the point-of-sale (POS) system and possible issues surrounding POS features.
Most of us have been through some level of cashier training to understand basic POS features. This taught us the protocols that our companies have adopted as best practices at the register. However, did this training expose us to the full capabilities of the register? Did it provide a complete understanding of how an untrained or dishonest cashier might push a few buttons that may have significant impact on shrink or margin? More than likely, it did not.
So how do you go about building this understanding of platform limitations? One good method is through a comprehensive audit process of POS features and usage. This audit is conducted by recreating the full range of transactions (where the system allows), documenting any roadblocks put up by the system, and seeing how this translates to the data contained in your end-of-day reporting and electronic journal and exception-based reporting analysis. You want to know exactly what happened in each transaction and then gain an understanding of exactly how (or if) each action from the transaction is represented within your data and reporting.
Identifying Limitations of POS Features
Conducting the audit is relatively easy if you commit to the process. The information you derive will be invaluable for you and your entire team. First, you will want to determine the size and scope of the project. It is important to determine each type and version of POS system that your company uses, along with the department-specific functionalities, such as service desk, restaurant, electronics, and pharmacy, and how much visibility your organization or team has to the related data on the back end. This last piece is especially important as the exercise is essentially pointless if the activities are invisible to you.
Next, you will want to develop a comprehensive list of all transactions that need to be tested and understood. This list would include legitimate transactions, high-risk transactions, and any activities that may drive a high-amount lock out (HALO) or low-amount lock out (LALO) action. HALO and LALO actions are driven by amounts that, once reached during an item or transaction-level occurrence, will “lock out” the cashier from performing the function without some type of manager intervention.
The list below shows some examples of transactions you could run to understand platform limitations. These examples are strictly related to refunds and not the entire scope of the project:
- Refund with a receipt
- Refund without a receipt
- Return on cash, check, credit card, gift cards, or merchandise credit due bill (When looking at refund to credit card, consider both manual entry and swiped.)
- Refund on employee purchase
- Refund of bottle return
- Refund of a sale item, BOGO, coupon, or markdown
- Refund of money order
- Refund of warranty or long-term service agreement
- Refund card or merchandise credit (Can it be re-charged? HALO or LALO?)
- Change refunded item to “damaged” in controller
- Attempt to ring up a negative sale
- Attempt all of the above in training mode (Is there a flag or differentiator?)
- Complete a non-scanned refund with item not on file
- Try to circumvent the online refund procedures
- Refund on same day, same store
- Refund on same day, different store
- Refund on fraudulent item not purchased (directly off shelf)
- Refund on different day, different store
This list is fairly robust but nowhere near complete. The list should include all types of transactions, including basic sales, line item voids, post voids, coupons, discounts, damages, suspended transactions, and so forth. There should be special considerations given to satellite registers or POS systems in the specialty departments mentioned earlier.
Going Beyond POS Features
Learning the limitations of each data-generating system within the store is necessary to learn where your company may be missing stopgaps or countermeasures. As an example, what is the dollar threshold at which a cashier can process a price override without the need for management approval? Most of you probably thought of a dollar amount as you read this. But are you sure? Just because the standard operating procedure or cashier training manual both say the amount is $10, for example, this doesn’t mean that the system isn’t set at a different level. And it’s our responsibility to understand what that level is.
In a perfect world, we would compile results data and create a value proposition. This could be leveraged to encourage our partners in IT, systems, or operations to correct the issue and to ensure that our platforms limitations always match our protocols. In the real world, however, this is not always possible. But as long as we are aware of the inconsistency between platform and protocol, we can build reporting to monitor for deviant behavior.
To learn about the other two pillars of understanding—process and protocol—check out “Data Analytics Pyramid,” which was originally published in 2016. This excerpt was updated February 21, 2018.