Driving Operational Excellence with Real-time Data Operations in Retail

Before we start, what do we mean by ‘realtime data operations’ in retail supply chain?

Retail supply chains are typically very complex networks of many people, businesses, products, and both physical and mobile infrastructure. A kink in any part of that chain can lead to supply shortages, product defects, unhappy customers, frustrated employees, missed targets, and ultimately sacrificed margin.

When each component of the supply chain plays its role in the overall process, it generates data in a number of IT systems: product data, delivery data, stock data, location data, third party data, and customer data – data that triggers automated processes; data that drives fundamental business reporting; and data that helps operational functions assess and control the business.

It is also data that becomes an integral part of the functioning of the supply chain itself – where, for example, physical distribution processes are dependent on digital packing data, or physical fulfillment processes are dependent on digital customer order data.

But this is all data that no single person or team has an end-to-end view of. And it is data that often, itself, goes wrong – when integrations don’t work properly, when system updates don’t reconcile properly, or when certain data formats cause system errors. And, given the interdependencies between this data and the physical operation of the supply chain itself, data issues go on to cause major disruptions.

But the flow of this data, and the dependencies between different data tables, as well as system owners and data stakeholders, could all be viewed together in one holistic, connected data map or network. With that sort of end-to-end visibility, it becomes possible to analyze and understand exactly what is happening – or what will happen, should a change or problem occur anywhere in the data landscape. 

When we say ‘realtime data operations,’ that is exactly what we mean – the visibility into your data landscape that enables you to predict or rapidly analyze issues that may otherwise cause serious disruption to your real-world supply chain operations.

We will walk through three scenarios where TigerGraph can drive operational excellence in retail supply chains: 

• Inventory Update Error
• Dependency Impact Assessment
• Risk Analysis

Scenario 1: Inventory Update Error

Let’s imagine a basic supply chain that involves international suppliers delivering teabags to a couple of local depots.

• A major shipment of teabags arrived at two main depots yesterday.
• At 7am, Mark sees an automatically generated notification that states that teabag stock levels are already too low in his depot for the dispatches expected to fulfillment centers today. He calls his colleague Beth at the other depot to confirm whether she is experiencing the same issue.
• Beth confirms to Mark that the shipment was received, scanned, and shelves were stocked with the volumes expected because she had a text from her unpacking team already. She’s unsure why the inventory processing system doesn’t reflect that – she assumes there is just a lag in the system update.

Mark wants to understand why the inventory processing system doesn’t seem to be updating – and now that he doesn’t trust what the system is telling him, he is also going to need to double-check with his team that the items did also arrive into his depot.

How might Mark’s actions be facilitated by TigerGraph?

TigerGraph becomes a digital replica of the systems and data integrations that support Mark’s work. It would model how the inventory processing system should receive any updates made to inventory. It would then enable Mark to explore exactly what has gone wrong – and to see specifically that the error has occurred in propagating some data updates into inventory processing.

The result: Mark is able to identify within minutes how best to proceed, saving time for himself, for his unpacking team, and for his colleague Beth at the other depot. IT is also empowered to start work on fixing the issue as soon as it arises – as opposed to waiting for Mark to file the report, and then having to manually tie together clues as to what has gone wrong.

This reduces the time to resolution along with any costs associated with the issue.

Scenario 2: Impact Assessment

Let’s imagine a firm is looking to update its stock tracking software at a retail supermarket store, with ideally no impact on any upstream or downstream systems and processes.

• A decision has been made to replace the stock tracking system at a retail store, and the project manager is looking to ensure that all data flows both upstream and downstream have been considered in the build of the new system before the switchover can be signed off for execution.
• Direct integrations with the online store and the transport network inventory system have been built already, and point-to-point tests have been run and completed succesfully.

The project manager and implementation team for the new stock tracking software are confident that systems and processes that are immediately upstream and downstream will not be affected because those direct integrations have been thoroughly tested. 

But they remain worried that there are many more systems and processes further upstream, connected effectively through many indirect integrations, that may or may not experience errors when they execute the system switch. They just don’t know what these systems are, or what the potential issues might be – because there is no visibility.

How might TigerGraph change the way the implementation team is able to analyze dependency risks?

TigerGraph would hold a digital model of how all systems across the end-to-end supply chain are connected together – and which data travels upstream and downstream, with which triggers, as well as with which interested owners and stakeholders.

The implementation team would be able to scan all end-to-end dependencies, drilling down on anything that may be of concern – and understanding who the right person to contact might be for any dependency, to agree on how to mitigate the risk.

The result: the implementation team can identify the right system owners, have the right conversations, and ultimately have confidence that they have assessed every possible risk of system error across the supply chain. They can also make the decision to execute the switchover at the most effective time.

Ultimately, time is saved for the implementation team and all system owners, and the risk of potential system failure is reduced for the whole business – avoiding unnecessary cost or lost revenue, as well as protecting margins.

Scenario 3: Risk Analysis

Let’s imagine Tina, the Head of Retail, is looking to identify the best way to spend her remaining budget this financial quarter. She wants to fund the system fix or upgrade that will have the best possible impact on the business.

• Head of Retail Tina has enough budget to improve the resilience of one system across the internal supply chain this quarter, but wants to understand which system would generate the best return on her investment.
• The system she wants to select is the one that causes the most trouble overall when it fails – through high numbers of dependencies from other systems or processes.

How might TigerGraph facilitate Tina’s risk analysis in a way she wouldn’t otherwise be empowered to do?

How would TigerGraph help calculate risk score to aid prioritization?

Because TigerGraph models how every system, data table, and data item work together in an inter-dependent network of integrations, it is able to “see” which components of that network hold the highest number of dependencies.

It is also able to compare failure rates if each system or data component holds information on how often errors happen – as well as calculate how much impact each error would have caused upstream and downstream.

The result: Tina is able to identify very quickly where she could have the greatest positive impact by spending her remaining budget – without needing to call around the relevant business and system owners and investigate anecdotally which problem she should solve.

Ultimately, this saves time for Tina, makes her decision more effective, and ensures the greatest positive impact on the efficiency of the business.

Graph Database and Relationship Analytics Combined

So the business value of using TigerGraph is clear, but would introducing TigerGraph to your architecture require decommissioning of, or integration with, anything else?

TigerGraph is additive to your architecture – and is really two technologies for the price of one: a graph database and a relationship analytics engine. Its primary contribution to your business is its unique analytical insight – derived from a combination of its ability to connect your data together and at the same time perform sophisticated analytical queries on that connected data. And you choose whether that insight is visualized or automatically actioned.

TigerGraph runs on top of your strategic cloud provider, compressing the data it stores – meaning lower storage and compute costs than alternative cloud-based approaches. It does not replace your cloud architecture.

It then outputs insight into your strategic AI/ML or data visualization tools – and it can make that insight available to you in whichever format is most appropriate – whether through the native visualization UI or in a machine-readable output such as CSV or JSON. Again, TigerGraph is additive to your data architecture – and is intended to enhance, not replace, your AI or visualization stack.

The Database

• Compatible with and underpinned by any major cloud server (AWS, GCP, Azure), whether private or public – as well as being available on-premises
• Consumes data in multiple input formats – e.g. CSV, JSON – in batch or via real-time API – to suit your data sources
• Scales horizontally, automatically – meaning the user experiences a single database even if underneath it’s spread across multiple servers
• Produces query results in real-time (TigerGraph can query more than the population of Greece every second, per server) to support real-time data operations requirements.

The Analytics Engine on Top of the Database

• Get insight from day one with inbuilt native algorithms such as Community Detection and Classification
• De-duplicate and match data using native identity resolution algorithms even if there is no easy matching ID – enhancing the quality of your data from day one
• Infer information using native algorithms such as Cosine or Jaccard similarity
• Write any query you can possibly think of using our query language, GSQL, which is a fully customizable, Turing-complete query language that is very similar to SQL
• Use queries to print results back into your database – enabling a deep learning, iterative insight mechanism.

All of these features might raise the question “Are there any limits I should be aware of?” 

Types of Data

With TigerGraph, there are no limits to the number of types of data you want to include in the graph – whether it’s customer data, product data, delivery, or location data. All of your data types and how they relate together are mastered in the schema you can create manually within the TigerGraph Graph Studio UI. You can choose to include any new data type at any time by just updating your schema and loading the data.

Scale

TigerGraph is built for scale – and whilst it doesn’t provision cloud servers automatically (because we believe that is a cost and technical design that you should be able to control), it does distribute and partition data across your provisioned servers automatically. This means that the TigerGraph user experience feels like there is only one server – and the user is never asked to do anything more than once, like creating new queries or schema for any additional servers.

Complexity of Analytics

TigerGraph’s analytics engine is built for depth and breadth of query – meaning there is no limit to the number of data types or points you can include in a single query. We know that some of the most important insight comes from combining a significant number of data types and data points together at once – so we built the analytics engine to support you in whatever you need to ask of your data. We also recognize that native algorithms don’t always garner the details of the answer you need – and so we made our query language fully customizable – catering not just to any number of ifs, buts, and whens, but also enabling you to print results back into your database as new or overlaid data to be included in future queries.

Speed

It’s important to note that where other technologies purport to be able to support the flexibility, scale, and analytical power above, usually it is to the detriment of speed. This is because in effect the technology isn’t built natively to operate like that, and instead there are technical workarounds that make it possible if given the time to run.

By contrast, TigerGraph was built natively for all of the above – which means it really does deliver insight in real-time speeds – and this is of paramount importance for analyzing data faults, which can cause significant financial impact if not investigated and addressed rapidly.

Getting Started with TigerGraph

You can download our free product if you’d like to get your hands on it straight away. Or you can reach out directly to our sales team if you’d like to see a demo, and talk about how we could run a proof of concept with you using some of your data.