L'analyse de Silvon Software, un fournisseur de BI Supply Chain

Par Léon Levinas-Ménard
Dernière mise à jour : décembre, 2025

Retourner à Étude de marché

Silvon Software est un fournisseur de longue date spécialisé dans l’analytics pour les fabricants et distributeurs, commercialisé principalement via sa Stratum Analytics Platform : un data-hub + une pile de reporting qui consolide des données opérationnelles (typiquement ERP et systèmes connexes) en une couche analytique sélectionnée, puis expose cette couche via des tableaux de bord web et des workflows centrés sur Excel, avec une planification et un write-back optionnels. La documentation produit publique indique une architecture centrée sur Microsoft SQL Server et les cubes SQL Server Analysis Services (SSAS), avec des composants d’interface web « Viewer » complémentaires, une couche « Connector for Viewer » qui fournit et actualise les modèles SSAS, et un composant « Server » lié à la base de données de stockage de Stratum ; un support hérité pour IBM i / DB2 sur iSeries apparaît également dans les exigences de déploiement. Silvon positionne cette plateforme comme soutenant la prise de décision en ventes, finance, et supply chain (stocks, visibilité de la demande/offre), mais les documents techniques disponibles mettent l’accent sur la mécanique BI/OLAP et la gouvernance plutôt que sur des méthodes d’optimisation innovantes ; lorsqu’il est question de prévisions ou de résultats « prédictifs », les preuves publiques les plus convaincantes pointent vers des workflows pilotés par le planificateur et des mesures basées sur le cube plutôt que vers des pipelines de machine learning clairement spécifiés.

Aperçu

La gamme de produits de Silvon, pertinente pour la supply chain, se comprend au mieux comme BI + data hub + OLAP, avec un module de planning permettant le write-back dans les modèles d’analyse plutôt qu’un moteur d’optimisation dédié de type « APS-style ».

Les exigences de déploiement publiques et la documentation d’aide de Stratum décrivent un système à composants multiples :

  • Stratum.Viewer (interface web) associé à une base de données SQL Server pour les métadonnées.
  • Stratum.Connector for Viewer, avec à la fois une base de données de métadonnées SQL Server et une base de données SSAS (cube) qu’il maintient.
  • Stratum.Server et une base de données de stockage Stratum, qui peut être hébergée sur Windows/SQL Server ou sur IBM i / DB2 (selon les configurations documentées).1

Ce modèle de documentation est cohérent avec une approche d’implémentation où Silvon (ou ses partenaires) livrent un modèle analytique pré-configuré (dimensions/mesures, souvent spécifique à un secteur), intègrent les données du client dans ce modèle, et fournissent une consommation via web/Excel ainsi que des points d’entrée pour la « planification » optionnelle.

Silvon Software vs Lokad

Silvon et Lokad abordent la supply chain à partir de points de départ techniques fondamentalement différents.

Les documents de Stratum de Silvon décrivent une architecture centrée sur Microsoft BI (SQL Server + SSAS + web viewer) où le livrable principal est une couche analytique et des métriques sélectionnées, avec des workflows de planning optionnels qui réécrivent des valeurs dans le modèle d’analyse (c’est-à-dire, le planning en tant que OLAP write-back + gouvernance + reporting).123 Sur cette base, le « moteur » est principalement le schéma du cube/modèle de données et la couche de reporting ; l’automatisation consiste typiquement en des actualisations programmées, des pipelines de données gérés et des KPI standards.

Lokad, par contraste, présente explicitement son livrable principal comme l’optimisation des décisions en situation d’incertitude, en présentant une feuille de route technologique construite autour de la prévision probabiliste (2016) et des paradigmes d’optimisation ultérieurs (par exemple, la descente discrète stochastique, l’optimisation latente).4 La documentation technique de Lokad met l’accent sur une approche programmatique « white-box » (Envision) dans laquelle la logique de prévision/optimisation est exprimée en code et exécutée dans le cadre du workflow de la plateforme, plutôt qu’intégrée dans un schéma de cube fixe.5 En termes de comparaison pratique : le mécanisme documenté publiquement de Silvon se rapproche davantage du BI/OLAP d’entreprise avec des extensions de planning, tandis que le mécanisme documenté de Lokad se rapproche davantage de l’optimisation prédictive basée sur des modèles (des distributions de prévisions alimentant le calcul des décisions).465

Historique de l’entreprise, propriété et signaux d’acquisition

Silvon se présente comme une entreprise de logiciels indépendante de longue date. Ses documents de direction identifient la société comme fondée en 1987, avec Michael Hennel cité en tant que CEO et cofondateur (avec Frank Bunker).7

La transaction d’entreprise la plus clairement documentée, issue de sources tierces publiques, date de 1998 : MKS a acquis l’unité Software Distribution Management (SDM) de Silvon, décrite à l’époque comme une unité opérationnelle plutôt que comme une acquisition de Silvon dans son ensemble.8 Une note commerciale tierce subséquente en 1999 fait référence à la version DataTracker 3.0 de Silvon, positionnée autour d’améliorations de la gestion/performance et de la mesure.9 Au-delà de cette cession de SDM, aucun document public de haute confiance (dans des sources largement accessibles) n’a été trouvé indiquant que Silvon ait été acquis ou ait réalisé des acquisitions majeures ; étant donné le statut privé de Silvon, l’absence de preuves n’est pas une preuve d’absence, mais l’empreinte décelable est limitée.

Produit et architecture

Schéma architectural de base : SQL Server + SSAS + interfaces web/Excel

Un élément clé de preuve non-marketing est la documentation des exigences de Stratum.Viewer/Connector de Silvon (v6.2), qui expose plusieurs topologies de serveur (mono-serveur, application/stockage séparés, multi-application + stockage) et nomme explicitement :

  • bases de données SQL Server pour les métadonnées de Viewer et Connector
  • une base de données SSAS pour le Connector
  • base de données de stockage Stratum
  • Stratum.Server en tant que composant requis dans le système global1

Cela importe car cela contraint ce que le système est susceptible de faire techniquement : le « cerveau analytique » est principalement le schéma du cube (dimensions/mesures) et le processus ETL/refresh qui le maintient synchronisé avec les sources opérationnelles. Dans le même document d’exigences, Silvon documente également des scénarios où le stockage Stratum réside sur IBM i / DB2 et énumère les fournisseurs côté client (IBM i Access for Windows, Microsoft OLE DB Provider for DB2) requis pour ces déploiements, indiquant une présence dans des environnements informatiques de fabrication/distribution centrés sur IBM i.1

Module de planning : write-back dans le modèle SSAS (et non un solveur d’optimisation démontré)

Les documents relatifs au module de planning de Stratum.Viewer de Silvon décrivent la fonctionnalité de planning comme un module complémentaire à l’environnement Viewer.2 De plus, la documentation d’aide de Silvon pour le module de planning de Viewer décrit un comportement opérationnel cohérent avec le cube write-back : activation du write-back sur une partition de cube, traitement des dimensions et gestion de la table de write-back dans le cadre du workflow.10 Cela suggère fortement que le « planning » est implémenté comme une saisie de données contrôlée et une gouvernance au-dessus du modèle OLAP (souvent utile), mais ce n’est pas, en soi, une preuve d’optimisation algorithmique.

Méthodologie de déploiement et de mise en service

Silvon publie une approche de déploiement BI en « 8 étapes » sous forme de PDF autonome. Celle-ci décrit une méthode de projet structurée (livraison par phases) plutôt qu’un modèle d’intégration produit en self-service.11 Dans le même ordre d’idées, la documentation « Data Import – Installation Steps » de Stratum de Silvon (révisée aussi récemment qu’en 2024) indique un maintien continu des directives de type installation/runbook et soutient l’interprétation selon laquelle les déploiements sont axés sur l’intégration et prescrivent opérationnellement (cartographie des données, planification des actualisations, configuration de l’environnement).3

Pris ensemble, ces éléments soutiennent un modèle de mise en service où la réalisation de la valeur dépend fortement de :

  • la structuration et la validation du modèle analytique par rapport aux données clients,
  • la mise en place de l’infrastructure SQL Server/SSAS (ou équivalents compatibles),
  • la création d’actualisations répétables et de contrôles de qualité des données,
  • et la formation des utilisateurs aux workflows Viewer/Excel.

Machine learning, AI, et optimisation : ce qui est (et n’est pas) démontré

Le marketing et le leadership éclairé de Silvon font fréquemment référence aux prévisions et aux résultats supply chain, mais la documentation technique publique examinée pour Stratum (exigences, module de planning et aide opérationnelle) concerne largement la modélisation des données, OLAP et le write-back gouverné plutôt que des modèles prédictifs entraînés ou des algorithmes d’optimisation reproductibles.

Concrètement :

  • La preuve la plus marquante du « fonctionnement » du planning fait référence aux mécaniques de SSAS write-back.10
  • La preuve la plus convaincante du « mode de déploiement » fait référence aux mécaniques traditionnelles d’implémentation BI d’entreprise (serveurs, bases de données, SSAS, étapes de déploiement structurées).1311

Cela n’implique pas que Silvon ne puisse pas apporter une valeur prédictive en pratique (par exemple, via des mesures définies par le client, des prévisions statistiques intégrées dans des outils en amont, ou des modules complémentaires de partenaires), mais cela signifie que la validation technique publiquement vérifiable de ML/optimisation de pointe est limitée par rapport aux fournisseurs qui publient des classes de modèles, des régimes d’évaluation ou des architectures de solveurs.

Maturité commerciale et présence sur le marché

Les documents « À propos » de Silvon revendiquent une échelle d’opérations (y compris une taille de personnel professionnel indiquée) et positionnent le produit comme établi dans des contextes de fabrication/distribution.12 Cependant, aucune histoire de levée de fonds pouvant être vérifiée de manière indépendante n’a été trouvée dans les sources publiques accessibles examinées pour cette page ; Silvon semble opérer en tant qu’entreprise privée sans une empreinte manifeste de financement par capital-risque dans la presse ou les dossiers facilement accessibles.

Références clients publiques

Silvon maintient une page client publique « Company We Keep » avec des logos/références nommés.13 D’un point de vue de la qualité des preuves, cela est rédigé par le fournisseur et doit être traité comme une revendication à moins qu’elle ne soit corroborée. Une référence client historique notable corroborée de manière externe est HarperCollins, apparaissant dans une étude de cas Microsoft qui décrit HarperCollins utilisant Silvon DataTracker (une ancienne gamme de produits Silvon) sur Microsoft SQL Server pour le reporting d’aide à la décision.14 Au-delà de cela, une corroboration client supplémentaire nécessiterait soit des références rédigées par le client, des études de cas rédigées par des partenaires, ou des reportages indépendants.

Conclusion

L’offre relevante pour la supply chain de Silvon Software, comme le démontre sa documentation technique disponible publiquement, est mieux caractérisée comme une plateforme BI/analytics d’entreprise adaptée aux fabricants et distributeurs : elle consolide les données dans des magasins supportés par SQL Server et des cubes SSAS, expose des KPI via le web et Excel, et permet optionnellement un planning contrôlé grâce au cube write-back. La documentation est relativement concrète sur l’infrastructure, les composants, et les étapes opérationnelles, ce qui renforce la crédibilité des aspects BI/gouvernance. En revanche, les preuves publiques d’une prévision ML de pointe ou d’optimisation sont faibles : les mécanismes « planning » les plus explicites documentés s’alignent avec le OLAP write-back et le contrôle de workflow plutôt qu’avec un solveur démontré ou une architecture moderne de modélisation probabiliste. Commercialement, Silvon se présente comme un fournisseur de niche établi avec une longue histoire opérationnelle, mais avec une divulgation limitée par des tiers accessible publiquement concernant le financement et les transactions d’entreprise au-delà d’une cession documentée d’une unité SDM à la fin des années 1990.

Sources

  1. Stratum.Viewer & Stratum.Connector for Viewer 6.2 Requirements — “Last updated: September 2012” — accessed 2025-12-22 ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  2. Stratum.Viewer Planning Module — “Last revised: December 2012” — accessed 2025-12-22 ↩︎ ↩︎

  3. Data Import – Installation Steps — “Last revised: October 2024” — accessed 2025-12-22 ↩︎ ↩︎ ↩︎

  4. Forecasting and Optimization technologies — accessed 2025-12-22 ↩︎ ↩︎

  5. Envision Reference — Lokad Technical Documentation — accessed 2025-12-22 ↩︎ ↩︎

  6. Probabilistic Forecasts (2016) — accessed 2025-12-22 ↩︎

  7. Leadership — Silvon Software — accessed 2025-12-22 ↩︎

  8. MKS Acquires Silvon’s SDM Unit — Enterprise Systems — 1998-08-17 ↩︎

  9. Silvon DataTracker 3.0 Aims to Boost Performance Management — Enterprise Systems — 1999-05-03 ↩︎

  10. How To Setup Planning For Your Cube — Silvon Help Center — accessed 2025-12-22 ↩︎ ↩︎

  11. Strategic 8-Step Approach to BI Deployment — “Copyright 2010” — accessed 2025-12-22 ↩︎ ↩︎

  12. About Us — Silvon Software — accessed 2025-12-22 ↩︎

  13. The Company We Keep — Silvon Customer References — accessed 2025-12-22 ↩︎

  14. HarperCollins Improves Customer Service and Supply Chain Operations with the Microsoft Platform (featuring Silvon DataTracker) — Microsoft case study — accessed 2025-12-22 ↩︎