Integrating Data to Maximize LP Effectiveness

Which areas in your company have the greatest shrinkage reduction opportunities?

Is there data that loss prevention can use to help determine the root causes of shrinkage in these areas?

Are there new ways of identifying losses that can be uncovered by comparing information between different systems?

At Nordstrom, we addressed these questions and are now able to better answer them through integrating and managing our loss prevention data effectively.

One of the biggest obstacles faced when managing loss prevention data is that it often resides in different systems. Most of those systems were likely purchased from different vendors or developed by various IT teams in your company. These factors result in decentralized data, making it difficult to integrate and use the information effectively. However, a tremendous amount of insight can be generated from comparing the information in these systems.

This article will discuss the steps we took at Nordstrom to manage our LP data more effectively and describe some of the benefits that can be realized from this process.

That Was Then…

Just a few years ago, it was not uncommon to walk into the loss prevention office of one of our stores and see stacks of paperwork. Large training binders bursting with photocopied sign-in sheets filled the bookshelves. Paperwork was being generated for audits, investigations, and arrest files. Unlabeled video tapes were as ubiquitous as pictures of unidentified shoplifting suspects. Our store LP managers were preoccupied with the task of compiling month-end summary reports so productivity could be measured.

At the corporate level, we managed an antiquated incident tracking system, a stand-alone civil collections application, a separate exception-reporting system, and a steady stream ofpaperwork continuously pouring out of the fax machine. Collecting information from the stores was a tedious task and on-site program audits were essential toinspect all the paperwork. We managed a lot of systems and a lot of paper.

Two revelations occurred that spurred change. First, we needed to communicate information back and fourth to the stores more effectively. Second, we needed to integrate our paperwork and data stored in different systems and combine this information to help us make better business decisions.

From there, our data management strategy evolved rapidly. We began by classifying all the types of data we had. Then we weighed our options. Lastly, we implemented new systems that would integrate all our data categories and allow us to use it effectively.

Data Classification

After inspecting our information, we classified the data into one of five categories.

1. Static
2. Manually generated by LP
3. POS
4. Digital video
5. Maintained outside of LP

Static Data. Static information changes infrequently. This is usually the information that the front line is able to reference so they can operate within clear boundaries. Examples of this information include:

• Policies and procedures,
• Training modules,
• Emergency response guidelines,
• Standardized forms, and
• Miscellaneous reference material.

The issue we had with static information was that current material was hard to locate because different versions of forms were located on various network folders throughout the company. In addition, a direct communication channel to the front line did not exist because email correspondences can be overwhelming. (Does anyone feel they get too few emails?)

Manually Generated LP Data. Anything documented by loss prevention for the multitude of things we handle is all manually generated. Examples of this information include:

• Arrests,
• Investigations,
• Fraud incidents,
• Recoveries,
• Audits,
• Training records, and
• Alarm breaks.

Our incident-tracking system was antiquated and had not been updated since its inception in the late 1980s. The system just collected information and didn’t give it back to the  tores in a practical manner that would help them  manage their workload. In addition, we had no visibility into trends that the front line was experiencing, which inhibited our ability to support them.

POS Data. Our exception-reporting application was good, but not great. As we grew in our skill at mining POS data for fraud patterns, we found that our exception-reporting system was not robust enough to meet our complex query needs. We had a long-term vision for the capabilities we wanted from it and realized that it was not going to meet our requirements for the future.

Data Maintained Outside of LP. I doubt anyone surpasses loss prevention in their use of data that is maintained and owned by another part of a retail organization. Examples of the data we go after include:

• HR, including timekeeping,
• Accounts payable,
• Shrinkage, and
• Unit variance and adjustments.

The salient issue with data maintained outside of LP is just that—it’s not ours. If we were going to be able to integrate information, we had to make sure we developed  partnerships with the appropriate departments inside the company to make the process easier and for them to understand the positive impact sharing the information would have to the company.

Shrinkage is one of our most-used types of data in this category. I think it’s important to note the paradoxical nature of shrinkage information. It is the fundamental metric of the effectiveness of loss prevention, yet understanding the components of shrinkage is often difficult.

At Nordstrom, our ability to dissect shrinkage and identify underlying trends was inhibited by the inflexible nature of our shrinkage reports. We had many reports, each summarizing shrinkage for a different level of management. Drilling into shrinkage to determine what areas were the main contributors required  tediously referencing multiple reports. In addition, we had no granular visibility into the individual products within a store department that accounted for shrinkage.

System Solutions

After classifying our data, we scrutinized our existing systems to determine if we could grow with them. We decided that new systems were needed in order to manage LP data in the future. In this planning phase, we surveyed the stores for feedback and considered the following issues:

• Will multiple systems be compatible with each other and share data?
• Will the security of information be effective yet flexible to allow for functionality based on LP positions?
• Will the systems be scaleable as the company grows?

We determined that we needed to create a loss prevention website for housing static information, implement a new case management system for collecting manually generatedinformation, and implement a robust exception-reporting system capable of integrating manually generated, POS, non-LP, and digital video information.

LP Website. The first system solution that we implemented was a loss prevention website on our intranet. This site solved our issues with static information by having one single source for the stores to always know where to get current information on a variety of reference material. We wanted the website to be a ”one-stop shop” for the stores, so we designed the site to act as a portal. Users can access the case management system and other relevant links directly from the LP web site.

We have remedied the old issues of decentralized master files by maintaining all the content on the website. It also houses all of our training modules and information relating to current initiatives on the site. The site includes a knowledge base that organizes reference material for every possible topic loss prevention is interested in. As the website has grown, we have also been able to incorporate a section with interactive graphs for analyzing shrinkage information.

Case Management. An effective case management system is the foundation for collecting information from loss prevention. However, we wanted a system that went beyond collecting information. We wanted a system that would provide the following capabilities:

• Allow the front line to be able to manage and measure their workload more effectively.
• Hold all of the information that we previously stored on paper.
• Uncover non-obvious relationships such as individuals who are associated with others based on sharing the same address, phone number, vehicle, or personal information.
• Provide insight into locations and merchandise categories that are involved in a disproportionate number of LP incidents.

We selected RuMe Interactive’s Asset Protection Information System (APIS) to handle our LP-generated data. The system allows our stores to document any type of event they handle and house all of the electronic files that we generate, such as narratives, spreadsheets, photos, and digital video. Having all of our LP-generated data stored in one placeprovides organization and security for our information as well as compliance with our document and data-retention requirements.

The system also allows our loss prevention managers to more effectively manage their workload. They can see incidents that occur in the stores, inspect open investigations, and review closed cases. Other features include managing the approval of information as well as assignment of records to individuals for follow up work.

Lastly, our issue of having a standalone civil collection system was solved by utilizing the recovery module in APIS. Now all of our information regarding shoplift apprehensions was stored in the same location.

Exception Reporting. We innovated new ways outside of our existing exception-reporting application for detecting fraud by joining POS data with other data sources, such as  employee information, timekeeping, register cash counts, and shrinkage. We needed to find a new exception-reporting application that could easily integrate with data fromother systems and allow for complex queries to be created from the data.

We found our answer in Datavantage’s XBR Store Analytics application. XBR gave us the ability to integrate multiple categories of data in complex queries and completely customize how we report their results. Furthermore, we are able to link reports and their data so that users can drill through information in a manner that complements our fraud-detection techniques.

Examples of the benefits of integrating POS information with other data include:

• Charge-backs to identifying fraud patterns and training issues.
• Timekeeping to identify fraud refunds rung using cashier numbers from employees that are not working.
• Case management to identify if shoplifters are involved in refund activity.
• Unit variance and adjustments to identify refunds associated with shrinkage units (internal refund fraud and refunds of stolen merchandise).
• Register cash counts to identify correlations with suspicious transactions.

We found XBR to be such a powerful reporting tool that it serves as the backbone of almost our entire LP reporting needs. We integrated our APIS data into XBR so that we can build customized reporting that goes beyond what is offered in APIS. We integrated data from several other systems into XBR so that their information could be combined in reports as well.

To accomplish this integration, we invested in skill sets in our corporate LP department that include knowledge of databases and structured query language (SQL), the data model of our LP applications, and an understanding of how XBR’s query generator functions.

As an aside, if your department does not have these skills, other options exist for integrating your data. Your IT department may already support an enterprise reporting application that they can point at the data in your LP systems. Also, you may try bringing your system developers or vendors together and outline your vision for informationsharing. Outsourcing this work will be an initial expense, but the ultimate ROI will likely justify the cost.

XBR is also packaged with another program called Table Editor that we found to be useful. Table Editor allows us to create forms for our users so that they can directly update the system with information. Prior to Table Editor, it was a tedious exercise to collect information from all of the stores. Now the stores simply fill in the form and it directly updates a table in XBR. We can even create a system alert or email to automatically send reminders that certain information needs to be updated.

We also have begun to use Table Editor to collect information from employees outside of LP. For example, we operate a reverse logistics return processing center that often discovers suspicious merchandise. These employees are able to access to just the Table Editor application so that they can record information on suspicious merchandise. This information has been integrated into XBR so that we can reference the corresponding return transaction and identify fraud patterns.

Digital Video. Like many retailers, we have moved from VCRs to digital video. Our desire was to connect the digital video recorders (DVR’s) to our network so that we could retrieve video remotely as well as integrate the video with our POS data. Although there were technological obstacles for implementation, the benefits of having remote visibility into our stores exceeded just fraud detection. Putting digital video on our network required a partnership with IT similar to what we had done with other departments.

Working with our IT department and the vendor, we were able to regulate the bandwidth usage of the DVRs and develop a standard Windows operating system for the units that allowed us to install virus protection software and, just as important, to remotely push out regular updates and patches.

Furthermore we are able to automatically sync the DVRs time clock with our POS operating system. If we experience drive failure, we now have the option of having drives replaced by our own IT technicians at a considerable cost savings over using third-party maintenance. We are moving towards having complete video coverage of all of our registers for the same time duration as we use for analyzing POS transactions. In the meantime, we have placed a field on our exception reports specifying if video coverage is available for the transaction. Should the stores move any of thecameras, they simply update a form in Table Editor and XBR is automatically updated with the correct DVR and camera for each register.

Shrinkage Analysis. Shrinkage is an aggregate metric and can sometimes mask trends that lie within its summary data. Therefore, it is important to have the ability to have flexible reporting so that you can drill into shrinkage data and fully understand its elements.

At Nordstrom, we extract shrinkage data from our semi-annual inventory counts from our Retek Merchandising System and integrate it into XBR. We have built several custom reports that allow us to identify loss trends “slicing and dicing” the data anyway imaginable within our store location and merchandise department hierarchies.

Once we have identified where to target our shrinkage reduction efforts, the next step is to identify exactly what merchandise is missing. To that end, we have also integrated unit variance and unit adjustment data into XBR so that we can link directly to this information from the shrinkage reports.

…This Is Now

We have successfully streamlined our systems so that loss prevention now uses just the three channels for our data needs—our web site, XBR, and APIS. In the process, we have integrated our information to provide us with more insight and consequently answered the questions asked at the beginning of this article.