Tamro Baltics (Tamro) is the largest pharmaceuticals distributor in the Baltic region holding a leading position in both wholesale and retail segments of the supply chain. This case study presents an inspirational business case that supplements Tamro’s core business and was realized through then new and exciting technology – Microsoft Fabric back in Q2 2024.

In addition to its core business, Tamro has been offering its suppliers access to their sales and stock data through several supplier-centric dashboards for time-trend analysis as well as day-to-day risk and inventory management. Suppliers can access data related to their stock items, available inventory (wholesale and retail) as well as out-of-stock and lost sales overviews.  

The access is structured in several pricing tiers, with basic information being free of charge and more comprehensive analytics placed behind a paywall. It’s a win-win situation, as suppliers gain a needed, fresh perspective on the performance of their items at Tamro, while Tamro monetizes the business data that it possesses.  

Although Tamro had implemented this solution for some time, it still had shortcomings. The legacy supplier dashboards were only available in two out of the three Baltic countries. In addition, the data models were dependent on on-premises architectures, fragmented and differed between countries. The dashboarding and end-user experience could also be improved through a unified design approach across countries and supplier report pricing tiers. This is where our cooperation with Tamro began on this project.  

Under the condition that the project should be realized within Microsoft cloud-based architecture and that reports should be embeddable within Tarmo’s Supplier portal – the choice essentially was between Power BI Embedded licensed separately, Power BI Premium per Capacity (now discontinued and merged with Fabric) or Microsoft Fabric.

In essence, the choice in favor of Microsoft Fabric came down to cost and long-term perspective-related arguments.  In terms of cost, all options for the required capacity are relatively evenly priced if we only considered the BI component (PowerBI with embedding capabilities). Microsoft Fabric, unlike other options, includes DWH platform functionalities at no extra cost, thus providing overall cost savings from a total budget perspective. Even though Microsoft Fabric was a relatively new product, its Lakehouse foundation aligned with the future-looking concepts of data analytics. This foundation supports scalable data operations, suitable for both external reporting (the project’s primary goal) and potential internal data needs in the future. Also, since Microsoft’s CEO has called it the most important data offering from Microsoft since SQL Server, it has continued improving since the project implementation in Q2 2024 and is likely to receive significant investments in product development going forward.  

With the decision regarding the data platform made, the implementation could start. The project team consisted of a balanced mix of colleagues with complementary skills, allowing for timely implementation through parallel tracks for technical and analytical tasks. This meant that while the initial technical set-up and configuration of the platform components took place, we were simultaneously analyzing the existing solution, compiling requirements, and creating data model specifications, aiming to transform the existing fragmented solution into a best-practice data model combined with improved and unified dashboard design.  

The Outcome: Technical overview

In terms of the technical architecture, we combined the Lakehouse and Warehouse components within Fabric. Since both are optimized for different workloads, we used the Lakehouse component for the staging area and Warehouse component for transformations and the relational data model. Regarding other tools, an Azure Gateway was needed as we were dealing with on-premises sources. We used notebooks for data staging, stored procedures for transformations, and pipelines to orchestrate the entire ELT process. An Import mode semantic model was implemented to enable embedding in Supplier portal via RestAPIs, facilitated through an App registration.

The Outcome: Dashboarding

We had two main goals with regards to dashboarding: to create a unified set of dashboards for all three Baltic countries, and to improve the user experience through better design and usability. Achieving these goals took several rounds of workshops with key stakeholders and several iterations, but we succeeded in meeting both objectives! As mentioned, Tarmo offers these dashboards in several pricing tiers to its suppliers. From our side, equal attention to detail – both in terms of content and visual appearance – was given to all dashboards, regardless of whether they were behind a paywall.

Example: Free of charge

Example: Behind a paywall

Key Take-Aways

1. Fabric worked when we implemented the project in Q2 2024 but has improved significantly since: Even though Microsoft Fabric was a new technology during project implementation we did not encounter any major technological obstacles that would hinder the project’s success. However, as with most new technologies in their early stages, there were some quirks that required workarounds. For example, deployment and CI/CD processes were not yet fully stable during implementation and required workarounds but have improved considerably since. Also, there are plenty of new Fabric features that were not yet available but could have been useful – e.g. at the time of the project Direct Lake Semantic models did not yet support report embedding or Mirroring for SQL Server in Fabric is just recently in general availability. ‍
2. It’s fast: Fabric demonstrated impressive speed, especially regarding transformations. For reference, daily incremental staging takes 55 minutes, while all transformations in full (non-incremental mode) take only 15 minutes (for approx. 25GB of Warehouse data).  ‍
3. A specialized tool for data transformation could make the implementation smoother: Tamro opted not to introduce an external tool for transformations in the architecture. Although we managed to create the DWH relational layer with pipelines and stored procedures, this approach required us to manually create object dependencies, lineage and uniqueness checks – all features, which tools like DBT would typically provide with less effort.  ‍
4. Adhering to best practices is still important: The familiar ELT process with naming standards and a best-practice relational data model, remains a must within Microsoft Fabric. This ensures not only the maintainability of the solution but will also be paramount for extending the project to cover other reporting needs.  ‍
5. Report embedding is stretching the definition of “Reporting”: Reporting and Business Intelligence in companies are generally seen as activities for internal stakeholders to provide business insights and support decision making. This project serves as an inspiring example of how a company’s data can be successfully monetized, creating a standalone business product outside of the company’s core business.