MySales modules

MySales ImplementationCapabilities

The MySales implementation process can be technically divided into the following steps:

94%
Forecast Accuracy

Established product accuracy at Drogas

15-20%
Revenue Growth

Turnover increase at Chudo Market after deployment

40%
Waste Reduction

Fresh write-off reduction at Blyzenko

AI Platform

One AI platform connects forecasting, replenishment, pricing, and promos - signals flow automatically between modules, so orders, prices, and campaigns stay in sync.

Module overview

Overview

Storage and historical data preparation Uploading historical promo data Promo training Forecasts testing and verification Configuring ongoing integration Setting up and running auto-order for a pilot group Deploying auto-order to all other groups The time frame for implementation depends very much on the specifics of the client needs and the amount of work that is planned.

So, if only the basic module is implemented, it can be done in a month, but if you connect all the other modules, then the approximate estimation of implementation time is calculated for each client individually.

This introductory manual describes all the stages of MySales implementation if all modules are connected.

If the client connects only part of the modules, the implementation process will differ only in execution time and fewer necessary operations.

The logic will remain the same. Below we consider in more detail all the stages of the MySales system implementation process.

Data preparation is the first and probably the most important stage in the implementation process.

At this stage, client prepares all the necessary historical data, prepares the server and database, and provides them to the MySales implementation team for validation.

Typically, the data is prepared by the client's IT team, according to the specification provided by MySales.

For this, a data storage in the customer's DBMS is created, where implementation team creates the necessary table structure.

Hardware/cloud resource is allocated for the DBMS, and a hardware/cloud server is allocated for installing MySales software.

Technical requirements for the server and the database are determined during the coordination of the project and may differ depending on the modules installed and the amount of data (number of SKU/store combinations).

Further, the customer's IT team uploads data to this database according to the specification.

Data is downloaded from the customer's existing system or several systems where such information is stored.

As part of this phase, the following data is prepared Directory of products and product groups Directory of stores and regions History of sales in volume and value, stocks, arrivals and write-offs, by week for the last 3 years History of sales in volume and value, stocks, arrivals and write-offs, by day for the last year Retail prices history Last purchase prices, if you plan to use the functionality of the pricing module Products bar-codes, if you plan to use the functionality of the pricing module All the necessary data preparation information for these two modules is provided in a specially created MySales file.

There are descriptions of all the tables that need to be created in the prepared database, a detailed description of each field, the necessary frequency for updating this data, as well as requests for updating the database created for MySales to simplify the work of the customer's IT team.

Since the data must be constantly updated, it is advisable for the client's IT team to set up their automatic update for the tables specified in the file already at the stage of uploading data to the MySales database.

For the most efficient operation of the system, we recommend uploading sales data for the last three years.

The specification file for data preparation can be found at the [link ]( https://mysales-labs.atlassian.net/wiki/spaces/MYP/pages/12222596/Table- impl+ru.xlsx).

All prepared data must be tested and validated by the MySales team.

As part of this phase, the customer prepares historical promo data for uploading to MySales.

At least it is recommended to upload the promo history for the last year, but 2-3 years is still more preferable.

The following information should be prepared: Promo start date and end date The list of promo positions The list of promo stores Promo type (TPR - temporary price reduction, MMK - discount provided at the checkout) Mechanics type for promos with MMK type (1+1=3, buy 1 get a discount on the second, etc.) Discount size for the whole promotion in percentage, or an individual discount for each item It is also recommended to indicate a regular retail price, however, if this information can be filled in automatically, based on history, this can be omitted.

All the necessary information on data preparation for the Promo module is provided in a specially created MySales file.

Unlike the base module, in the case of a promo, the customer only prepares historical promo data in excel file format.

Setting up the database and loading the necessary promotional data into the system is done by the MySales implementation team.

The specification file for promo data preparation can be found at the [link ]( https://mysales- labs.atlassian.net/wiki/spaces/MYP/pages/12288180/Table+impl+promo+ru.xlsx).

After filling in all the tables that are described in the file with data, MySales team proceeds to verify the received data, if errors are found, the implementation team informs the client about it and asks to fix it.

The key goal of this stage is to perform the most optimal system settings for predicting promos, as well as recalculating all promos in history and training the algorithm for predicting promo growth.

As a rule, this process is iterative in nature, which begins after all historical promos are loaded into the system: Setting system parameters for promo forecasting Recalculation of all promos in history Training the algorithm Testing forecasts and analyzing the accuracy of promo forecasts Repeating the previous iterations for better forecasting

Business impact

Impact We Deliver

To start using the system, usually 3 iterations are enough, however, more detailed and fine-tuning can be done later.

Forecasts testing and verification is a process of continuous improvement.

As part of the project, it is always recommended to test both regular and promotional forecasts.

It is recommended to test forecasts at the SKU-all stores-week level, in order to reduce the amount of labor that grows many times if you go down to the SKU-store-week level.

For maximum transparency during implementation, we check the quality of forecasts that were built by our client, and forecasts built using MySales.

In general, the methodology for comparing forecasts is as follows: This stage is very important for the stable operation of MySales in conjunction with the customer's system in the future.

When setting up continuous integration, it is worth highlighting 2 main blocks: Integration of the base module includes regular updating and addition of the following data: Integration of auto-order includes regular updates and additions of the following data: After all previous steps are completed, the next step is to configure the diagrams for the pilot group of products and order them using MySales auto- order.

It is important that the transition is carried out precisely group by group for all stores, and not store after store for a wide range of product groups.

Because we need to check the order parameters, including package quantities, minimum order quantities, presentation stock, as well as links to suppliers/contracts.

In order to start ordering the first group using MySales auto-order, you must also schedule the launch of batch processing for recounting orders.

After these steps are completed, you need to check the correctness of automatic orders upload from MySales to the customer's system, as well as if they were sent by email/EDI.

It is also important to verify that arrivals are correctly loaded in MySales.

At first, it is recommended to check all orders for the pilot group, and, if there are any remarks, adjust the parameters of the diagrams.

It is also important to analyze the safety stock and manage safety stock coefficients at the SKU-all stores level and add analogues for new positions and new stores After the pilot group has been successfully tested and the automatic order process has been debugged, all that remains is to connect more and more groups to MySales automatic order.

To do this, you just need to set up new diagrams and check orders created for the first time, in order to adjust the diagram parameters and safety stock coefficients.

And also, do not forget to indicate analogues for new stores/products.

  • The client prepares his forecasts at the SKU-all stores-week level, for the next week or more and uploads them to a file

  • MySales also builds forecasts for a similar period of time and uploads the same level forecasts to a file

  • Client and MySales exchange archives protected by the password which contain the results of forecasts

  • Over time, passwords are opened and we analyze the accuracy of the forecast by comparing it with real sales

  • Integration for the base module

  • Integration for the auto-order

  • Directory of products and product groups

  • Directory of stores and regions

  • History of sales in volume and value, stocks, arrivals and write-offs, by week for the last 3 years

  • History of sales in volume and value, stocks, arrivals and write-offs, by day for the last year

  • Retail prices history

  • Last purchase prices, if you plan to use the functionality of the pricing module

  • Products bar-codes, if you plan to use the functionality of the pricing module

  • Directory of suppliers and contracts

  • Presentation stock

  • The package quantities for stores and warehouses, the minimum order (possible as an transfer option from MySales to customer system, as well as from the customer system to MySales)

  • Order source bindings for each combination of SKU/store and SKU/warehouse linked to supplier and contract

  • The last stocks for the store and the warehouse

  • Arrivals of products on orders from stores and warehouses