Simple is not easy

Cases

Reworked the IT architecture and built a transformation roadmap for the music retailer Muztorg

How PIM system integration helps a music retailer manage a catalog of 126,000 products and automate eCommerce processes

Key takeaways

  • Muztorg: case study describes business context, KT.Team delivery approach and measurable value for enterprise teams.
  • Delivered by KT.Team. The CIS source page carries the full project story, metrics and interface screenshots.

Client

Muztorg is a leader among retail chains selling musical instruments and music equipment in CIS. The company owns the country's largest retail network of 50 music stores, as well as muztorg.ru, the No. 1 online store in its segment of Runet.

Muztorg has been operating for more than 20 years. It was the first company in the CIS musical instruments market to implement an omnichannel approach: pricing, assortment, and service information is synchronized between the website and retail stores.

Challenge

Conduct a pre-project assessment and conceptual design of the corporate data management system.

In mid-2021, Muztorg faced an important task: to transform its IT architecture. Through this transformation, the company aimed to achieve:

It was necessary to propose the optimal technical solution for integrating both Muztorg's internal information systems and external services, including B2B functions.

Another objective of the study was to create a roadmap, a high-level plan, and a budget estimate for the future MDM and ESB implementation project.

  • reducing the cost of maintaining the IT landscape, as well as minimizing the risks of data loss and delayed delivery;
  • achieving a scalable management architecture;
  • rapid scaling by increasing the throughput of information systems and quickly connecting new information systems.

Solution

The KT.Team team carried out a pre-project assessment to:

Based on the pre-project assessment, we proposed a target architecture and information model for the corporate data management system as part of the company's digital transformation. For the next stage of transformation, we defined requirements for the future corporate data management platform in terms of the integration model and master data management model.

  • analysis of the current IT architecture, interactions between information systems, and product information models;
  • conducting an audit of current services, identifying weaknesses and data conflicts.

As-is to to-be business process modeling

When working on the project, we relied on as-is business process modeling (the relationship structure identified during the pre-project assessment) and to-be modeling (the design of the new architecture prepared for implementation).

Modeling the existing architecture allowed the project team, together with the client's representatives, to identify bottlenecks: points that were slowing the architecture at the time of the study or had the potential to do so.

We paid special attention to these processes and integrations during the to-be stage so that the new architecture would not inherit the bottlenecks of the previous one and would be more flexible and scalable.

We'll curate materials for your task

We'll reply within 30 minutes and send relevant cases, diagrams, or analyses tailored to your context.

As-is model

To fully understand the as-is model for this project, we interviewed employees from 11 company departments involved in item master data business processes: warehouse, retail, marketing, IT, and others. In parallel, we collected and reviewed documentation: instructions, requirements, and regulations.

During the pre-project assessment:

In simplified schematic form, the as-is architecture looked as follows.

  • the project architecture, product information models, and interaction mechanisms between organizational units were analyzed;
  • the effectiveness of system interactions was assessed;
  • weaknesses in business process elements were identified;
  • directions for further development and to-be model design were identified.

To-be model and design of the new information layer

Based on the pre-project assessment data, we created a map of information flows between subsystems and visualized it, accompanied by detailed explanations of what information should pass from which system through the ESB to other systems.

Muztorg: case study
Managing item master records with fabric variation attributes

Project implementation roadmap

We prepared a roadmap for transforming Muztorg's IT architecture both as a Gantt chart and as a structured diagram with the project implementation phases marked.

Muztorg: case study
Managing item master records with fabric variation attributes
Muztorg: case study
Managing item master records with fabric variation attributes

Selection of specific IT solutions

In addition to the architecture design and implementation roadmap, we prepared an analytical comparison of ESB and MDM solutions.

Thus, the Mule, Talend, and WSO2 ESB systems were compared across 70 parameters, including:

The effectiveness of using the ESB for each subsystem was analyzed separately.

The detailed analysis enabled Muztorg to make an informed choice of an ESB solution that met its needs.

The goals of introducing the MDM system into Muztorg's architecture were:

Based on the analysis performed, interview results, and Muztorg's requirements, we defined:

Using these criteria, we conducted a detailed comparison of the Pimcore, Riversand, and 1C MDM systems and provided the client with a detailed report. We also analyzed the budgets the company would need for implementation and maintenance, and reviewed options for storing reference data and its attributes in the MDM system.

To ensure the security and control of the data being entered, we built a role matrix with access levels for specific data.

  • implementation speed and accessibility;
  • the systems' technical characteristics;
  • scalability opportunities;
  • supportability opportunities;
  • the cost of specialists working with these systems and their availability in CIS.
  • support for maintaining auxiliary and cross-domain reference data to sustain core processes;
  • provision of unified identifiers for reference data elements to analytics systems;
  • integration of unified reference data into the company's processes, including support for both current and future processes.
  • functional requirements for the MDM system (25 key points, including tools for creating, maintaining, and deleting master data; importing reference data values from files, as well as support for upload via API; configurable data validation rules; etc.);
  • requirements for ensuring data integrity;
  • requirements for controlling the quality of entered data.

Contacts

Let's Discuss Your Project

Leave your current contact details and describe your task. We will come back with clarifying questions and a proposal for the next step.