TMS : vers un processus massivement collaboratif

L'utilisation des TMS chez les chargeurs et prestataires logistiques (pilotes de transport) est en pleine croissance.
La nécessité d'optimiser le maillon "Transport" de la chaîne logistique porte ce marché.
Leurs fonctionnalités ont pour objectif d'automatiser et d'optimiser (avec plus ou moins de bonheur ...) tout ou partie du process transport :

• réception des commandes, 
• constitution / optimisation des chargements / des tournées, 
• rendez-vous / planning sur les différents points de chargement / de livraison (usines, entrepôts, magasins), 
• retours de tournée / gestion des litiges, 
• gestion des emballages / palettes, 
• pré-facturation / facturation, 
• ... ... 

Les fonctions d'optimisation brillent souvent par leur absence et nécessitent dans ce cas d'acquérir un logiciel dédié et de l'interfacer tant bien que mal avec le TMS.
Quant aux outils d'aide à la décision, ils se résument la plupart du temps à des rapports prédéfinis ou dans le meilleur des cas à des outils de requêtage.

Au delà de ces fonctions de gestion que la plupart des TMS savent fournir, les fonctions collaboratives manquent cruellement, dans un process où les acteurs sont multiples et éclatés géographiquement :

• partage des données des commandes entre les acteurs concernés 
• prises de rdv 
• retours de tournée / litiges 
• suivi des transports : évènements, retards, impacts sur l'heure d'arrivée prévue 
• ... ... 

De la même manière, les échanges EDI, avec le coût qui y est associé (développement et transport des messages), doivent devenir collaboratifs.
On peut faire l'analogie avec l'envoi de mails : un utilisateur envoie un mail avec 1 ou 2 fichiers en pièce jointe à 3 collègues, qui chacun le transfère à 2 ou 3 membres de son équipe, qui le renvoient complété, ...
On s'aperçoit vite de l'inefficacité du process et du coût associé.
Il est évident qu'une solution collaborative est préférable (cf. Google Apps) :

• les documents ne sont stockés qu'une seule fois : soit chez l'émetteur du document, soit à un endroit commun à tous les acteurs 
• on envoie par mail uniquement le lien vers le document 
• si quelqu'un doit le modifier (s'il en a le droit), il le fait sur le document original, et tous les acteurs en sont informés automatiquement 

Adapté au métier de la supply chain, ce principe est tout aussi probant :

• le donneur d'ordre met ses commandes à disposition de ses partenaires / prestataires / clients / ... 
• les expéditeurs, destinataires gèrent leur planning de RDV, les transporteurs prennent RDV 
• les destinataires et/ou les transporteurs effectuent le retour de tournée et indiquent les litiges éventuels 

Toutes ces actions / ces évènements agissent en temps réel sur le système d'information du donneur d'ordre, des prestataires, des destinataires, ...
Le mode de communication à privilégier n'est plus l'envoi de messages mais l'accès direct à l'information par l'intermédiaire des web services.
Les données sont stockées dans le système d'information du donneur d'ordre ou sur celui d'un prestataire (mode Saas).
Les outils supportant ce process sont bien sûr sur le web.

Rêvons un peu : imaginons un réseau collaboratif rassemblant la majorité des acteurs de la supply chain, se partageant les données nécessaires à leurs métiers.

• Le logiciel est hébergé sur une plate-forme "Cloud" (ou SaaS : le logiciel n'est plus installé sur les machines de chaque entreprise mais sur des machines gérées par de gros prestataires, comme le sont aujourd'hui les sites web ou les messageries par exemple). 
• Les entreprises n'ont plus la charge de mettre en place et maintenir l'infrastructure nécessaire (matériel, logiciel, sécurité, sauvegarde, licences, ...).
• Les coûts associés à l'EDI disparaissent. 
• Les clients, prestataires, usines, entrepôts, magasins, ... suivent en temps réel l'acheminement de leurs commandes / produits. 
• La constitution d'un vaste réseau des acteurs de la supply chain et de leurs données associées permettrait également, à terme, d'optimiser globalement le remplissage des camions et la consommation de CO2 par ces camions : une bourse d'échanges globalisée permettrait à tous les acteurs, grâce à un moteur de recherche performant, de trouver du frêt pour remplir l'espace vide dans leurs camions. 

Il reste donc un fort potentiel d'imagination et de développement pour les éditeurs du secteur ....
Le modèle à suivre me semble être celui de Google et de ses google Apps, tant du point de vue technique que du point de vue ergonomique (simple et efficace).

Qu'en pensez vous ?

La gratuité comme modèle économique ?

Le modèle économique traditionnel d'un éditeur de logiciels a toujours été la vente de licences, la vente de maintenance sur ces licences et accessoirement du service autour du logiciel installé chez le client.
Le service pouvant être technique (installation, paramétrage des serveurs, ...) ou fonctionnel (étude des besoins, définition des écarts entre les besoins du client et les fonctionnalités du logiciel, "paramétrage" du logiciel pour le mettre en adéquation avec les besoins du client, formation, ...).

Ce modèle a évolué depuis 6 ou 7 ans avec l'arrivée des logiciels/éditeurs open source.
Je parle ici des vrais éditeurs open source, qui publient l'ensemble de leurs développements dans un référentiel libre, dans un modèle de licence adapté, et qui participent le plus souvent à l'évolution/la correction des composants utilisés dans leur solution.
Je ne parle pas des éditeurs qui fournissent une version/une partie de leurs outils gratuitement et le reste de leur offre (dont du service) dans un modèle bien connu de licences payantes.
Les entreprises ayant les moyens d'investir dans une équipe de développement pour développer/maintenir les outils qui manquent à la solution profitent (au bon sens du terme) de ce modèle. Reste à vérifier si le coût des équipes n'est pas plus important que ce que représenterait l'achat de licences et de maintenance.
Par contre, la majorité des PME qui pourraient être attirées par le faible coût apparent de ces solutions sont obligées au final de recourir à la version payante de la solution s'ils veulent en tirer profit.

Pour revenir aux "vrais" éditeurs open-source, ils distribuent donc leur logiciel de manière totalement ouverte et gratuite, libre aux "clients" de cette solution de se débrouiller avec (en faisant notamment appel aux communautés plus ou moins actives sur le Net) ou de faire appel aux services de l'éditeur pour les aider à implémenter la solution.
Les revenus des ces éditeurs proviennent en général d'une "redevance" annuelle que les "clients" acceptent de verser à l'éditeur et qui leur garantit la mise à disposition par l'éditeur de toutes les évolutions qui pourraient être développées spécifiquement pour d'autres clients.
On assiste donc à la constitution d'une communauté privée, constituée de l'éditeur et de tous ses clients. Un processus vertueux est mis en place au sein de cette communauté :

• les clients demandent des évolutions et les financent (quelquefois de manière collégiale, afin de partager les coûts de développement),
• une fois l'évolution terminée, elle est mise à disposition de la communaté de clients : tous les clients, y compris ceux qui ne l'ont pas payée, profitent de cette évolution,
• le logiciel évolue donc en fonction des besoins des clients et n'est pas imposé par l'éditeur,
• les clients participent financièrement à son évolution et se sentent donc plus impliqués.

Ce modèle s'oppose au modèle traditionnel où l'éditeur développe de plus en plus de fonctionnalités, assez souvent inutiles à la majorité des clients, et les impose à ses clients. Le coût des licences est également imposé à l'ensemble des utilisateurs, y compris ceux qui n'utilisent que 10 % des fonctionnalités du logiciel.

Une deuxième tendance, liée à l'émergence du logiciel "gratuit" et open source, est la fourniture d'applications, gratuites pour une majorité de clients, sur le web. Apparue il y a qq années, elle a été popularisée par Google via les Google Apps. De nombreux éditeurs essaient de suivre ce modèle, parmi lesquels Microsoft et IBM.
Hormis le prix, les points forts de ces applications sont nombreux :

• Aucune administration des postes de travail et/ou des serveurs, les applications étant hébergées chez l'éditeur
• Pas d'achat de serveur
• Pas de souci de sauvegarde : elle est assurée par l'éditeur
• Disponibilité des applications quelque soit le poste de travail (PC, portable, smartphone, tablette, ...) et le lieu d'utilisation (Bureau, domicile, aéroport, ...)
• Pas de souci de migration de versions : les applications sont toujours à jour, sur l'ensemble des postes

Parallèlement à la gratuité pour les "petits" consommateurs, une version "pro" est fournie, en général tarifée par utilisateur nommé. Le Coût Total de Possession (TCO) est bien inférieur à une solution classique : cf. le petit comparatif avec MS Exchange, certes réalisé par Google mais qui donne une idée : http://www.google.com/apps/intl/fr/business/messaging_value.html

Ce modèle devrait je pense être appliqué à d'autres domaines, non critiques, que la bureautique. On peut citer notamment les applications de gestion clients (CRM) mais aussi toutes les applications métier collaboratives, faisant intervenir de nombreux acteurs (clients, prestataires, partenaires, ...) : c'est pour ce type d'applications que ce modèle est le plus approprié, notamment dans le domaine de la Supply Chain, et plus particulièrement sur les outils de gestion des transports : Prise de RDV, Retours de tournée, Géolocalisation/Suivi des transports, ... des dizaines de milliers d'acteurs dans ce domaine.
La décennie qui commence devrait voir l'avènement de ce type d'applications.
Mais les éditeurs actuels, s'ils essaient de développer une couche Web au dessus de leur logiciel, ne l'ont pas toutjours conçu à l'origine pour être déployé massivement sur le Web. S'ils veulent rester dans la course, ils devront à plus ou moins long terme revoir l'architecture de leur logiciel. Comme à chaque nouvelle période architecturale, les nouveaux entrants sur ce marché auront une longueur d'avance.