Collaborative Supply Chain

The performance of your supply chain depends on its integration with your suppliers, customers, transporters, etc. Keeping your partners in the dark is a recipe for poor quality of service, limited agility, and higher operational costs. Sharing actionable information with your trusted partners is one of the cornerstones of a collaborative supply chain. Through the Lokad platform, your company can safely and reliably share data packages, precisely tailored to the specific needs of each of your partners.

1. Collaborative Supply Chain Example

Contoso, a large retail group, wants to share key operational data with Fabrikam, its FMCG supplier. Contoso hopes to streamline its supply chain collaboration with Fabrikam. Specifically, Contoso needs to provide:

Daily Sales Data for each Fabrikam product across every Contoso store.
Stock Levels from all Contoso stores and warehouses.
Market Share insights for Fabrikam’s product segments, at monthly intervals and per store.

Crucially, Contoso also shares aggregated market data with Fabrikam’s competitors (who are also Contoso suppliers) in a similar manner, ensuring a fair and confidential approach for all parties involved.

By leveraging the Lokad platform, Contoso can automatically assemble the exact subset of data for Fabrikam—line by line, field by field—while preserving confidentiality and ensuring no performance impact on Contoso’s own operations. Through atomic updates, Fabrikam always sees a consistent snapshot of shared data, even when massive datasets are involved.

Once Fabrikam receives these data feeds:

Daily Sales Data helps them to forecast and plan upcoming Contoso orders more accurately.
Stock Levels highlight inventory already in the pipeline, mitigating bullwhip effects.
Market Share statistics let Fabrikam measure the impact of its promotions and regional advertising efforts.

Fabrikam can then perform additional analytics and reporting within its own Lokad account, combining Contoso’s shared data with Fabrikam’s own internal figures. Crucially, no separate IT infrastructure is required for this step.

This seamless and secure data sharing ensures that both companies can focus on optimizing their collaboration rather than wrestling with complex integrations or clunky forecast-sharing processes.

2. Obstacles to Collaborative Supply Chain

At the tactical level, supply chain collaboration requires a constant exchange of information about the “state of flow” between partners, e.g., sales data, stock levels, ETAs, etc. Though many might think that the internet age has solved this issue, in reality that is simply not the case. There is more than meets the eye when it comes to easily, reliably, and securely sharing the data required for a fruitful tactical supply chain collaboration.

The Lokad platform addresses this challenge in ways that alternative solutions do not, such as that described in 1. Example Use Case

2.1 Security

For every partner (e.g., suppliers), the Lokad platform gives you the possibility to delineate the exact data perimeter to be shared.

For example, if a client wishes to share a table with a supplier, Lokad offers the ability to share exactly what the client wishes (line by line, if so desired). For any field to be shared, Lokad can reveal or conceal (line by line, if so desired) the content.

Moreover, the platform guarantees that the client will experience zero performance degradation when trusted partners (such as suppliers) access the approved portion of shared data.

2.2 Expressiveness

The data to be shared with trusted partners can benefit from preprocessing performed on the Lokad platform. Our platform even makes it possible to share anonymized statistics with the trusted partner on his own biggest segment.

For example, the original business data might originate from multiple systems that should be consolidated prior to being shared. The data may also include accidental artifacts or errors that would just confuse the partner, which the Lokad platform can tidy up before sharing.

2.3 Integrity

The entire dataset shared with the partner is shared through atomic updates by the Lokad platform. This means that the partner cannot be confused by partial updates of the shared data—even if giganormous datasets are involved. The partner either sees the “old” snapshot or the “new” one.

This property is fundamental to eliminating entire classes of errors and problems for the trusted partner.

2.4 Exploitability

Analytics, data visualization, and data post-processing can be performed by the trusted partner on the shared data (within the Lokad platform). All of those operations can even be done by leveraging additional data provided by the trusted partner to the Lokad platform. These capabilities ensure that the data being shared can be put to practical use by the trusted partner—without them needing to involve their own IT infrastructure.

Though it is tempting to share forecasts, Lokad strongly discourages this practice. In theory, clients often believe a highly accurate demand forecast should help the supplier achieve high “On Time In Full” (OTIF) scores or high service levels. However, sharing forecasts usually means sharing time-series forecasts, which lack the necessary information to contribute meaningfully to business decisions that should account for the future uncertainty.

For example, time-series forecasts (or “point forecasts”) say nothing about returns, promotions, shelf-life, write-offs, or any of the other specifics that truly matter in your vertical. For this reason, Lokad recommends focusing on sharing facts (for example, data on sales, stock levels, and returns) with suppliers. These are the data that help to generate better decisions, which is why Lokad focuses on sharing this information.

4. Comparing Lokad and Alternative Technologies

There are a large number of alternative technologies for sharing business data. Below find a brief comparison of several of the most popular options.

For the sake of clarity, we have assumed that the data to be shared originates from an ERP, and that the company in question wants to share (with each supplier) its daily sales data (restricted to the products that originate from each supplier).

4.1 SQL/ETL

The company can share its data using an ETL operating on top of a transactional database.
SQL does not support granting “row-level” permissions that would be required to share data with a partner.
Dedicated tables, for the partner, would have to be created. Also, those tables would have to be created in an isolated database, as the trusted partner accessing its own data could degrade the performance of the whole system.
Point 3 (above) implies creating and maintaining one isolated database instance per partner.
Moreover, any visualization of the shared data requires a separate system, to be managed by the IT department of the trusted partner.

4.2 BI (Business Intelligence)

The company can share its data using a BI tool and can restrict the trusted partner to customized views (tailored for each partner).
Unfortunately, through this arrangement, the trusted partner lacks the ability to compose their own analytics or post-processing on the shared data.
Moreover, the shared data can’t easily be exported as flat files for further use within the IT systems of the trusted partner.
Finally, this approach represents a computational workload which may negatively impact the BI instance of the company, if there are numerous suppliers.

4.3 FTP

The company can share its data through flat files shared via FTP (the FTP server being either managed or self-hosted).
This arrangement, however, lacks all the preprocessing, post-processing and data visualization capabilities provided by the Lokad platform.
This means that both the company and its trusted partner have to operate scripts (Python, or something equivalent) to pre- or post-process the data.
Moreover, a separate system is required to visualize the data.

4.4 Blob Storage (e.g., S3)

The company can share its data through flat files shared via a blob storage.
This option is virtually identical to FTP.
Though the blob storage is typically cheaper and more reliable than FTP, it remains a fragment of the solution, requiring two IT departments to get involved (the company and the trusted partner).

5. Technical fine print

Each client account with the Lokad platform has its own filesystem. Each filesystem behaves like a Git repository, meaning all changes are versioned and atomic. When files are modified, the filesystem ensures that the change is applied atomically (much like a standard “commit” in Git). The client (in this case, a user or process) of the filesystem (a can either see the previous version or the old version (there is nothing “in between” these two states). The Lokad filesystem can also be accessed by FTP (SFTP or FTPS).

Step 1: A member of the client company can make a folder “shareable” if they have sufficient access rights within their Lokad account (source). This is done through the web interface.

Step 2: The web interface issues a token that this user sends to their trusted partner (using the web interface).

Step 3: The trusted partner, who has also a Lokad account (destination), claims this token (using the web interface).

Step 4: Once the above steps are completed, a new folder appears in the account of the trusted partner. This new folder is a perfect replica of the folder shared by the original user.

Note 1: Any changes made to the source folder (client) is mirrored in the destination folder (trusted partner). The target replication latency for changes is under one (1) minute.

Note 2: The replica folder in the destination account is read-only. It cannot be modified.

5.2 Using Envision

Typically, the source account will get its original data through FTP, mirroring the data exactly as it is found in the business systems. Then, Envision (the programming language of the Lokad platform) is used to populate the source folder with any arbitrary set of flat files representing the (relational) data subset that will be safely shared with the trusted partner.

Envision is also used by the trusted partner to visualize or post-process this data from the destination account. Finally, FTP is also available for the trusted partner, if there is a need to re-integrate this data into their own business systems.