La première mise en application de cette application développée avec les outils Hummingbird, s’effectue sur le site de Sarreguemines, usine de 100 000 m² dont la production de pneumatiques s’élève à 28 000 pneus par jour (soit 9 millions par an), pour un chiffre d’affaires de 265 millions d’euros. Le site compte 1 200 collaborateurs dont les ¾ travaillent à la production.
Le projet de mettre en place une application d’aide à la décision, fait suite à un important projet d’intégration des applications de production en place : C.I.M. (Computer Integrated Manufacturing). Les reporting existants développés par le service informatique, présentaient alors de nombreux points de rigidité. Les rapports à disposition des différents pôles de production font l’objet de ressaisies dans Excel, afin d’obtenir une meilleure visibilité, plus graphique notamment, sur les tendances et identifier les éventuelles dérives plus facilement. « Au-delà de la perte de temps engendrée par ce procédé nous étions confrontés aux risques imputables à la multiplication des verrues applicatives sous Excel, si nécessaires soient-elles, mais aussi aux erreurs de saisie et finalement à des échanges cacophoniques, personne ne partant tout à fait des mêmes informations », explique Luc Vaucelle, chef de projet chez Continental France.
Le projet de mettre en place une application d’aide à la décision, fait suite à un important projet d’intégration des applications de production en place : C.I.M. (Computer Integrated Manufacturing). Les reporting existants développés par le service informatique, présentaient alors de nombreux points de rigidité. Les rapports à disposition des différents pôles de production font l’objet de ressaisies dans Excel, afin d’obtenir une meilleure visibilité, plus graphique notamment, sur les tendances et identifier les éventuelles dérives plus facilement. « Au-delà de la perte de temps engendrée par ce procédé nous étions confrontés aux risques imputables à la multiplication des verrues applicatives sous Excel, si nécessaires soient-elles, mais aussi aux erreurs de saisie et finalement à des échanges cacophoniques, personne ne partant tout à fait des mêmes informations », explique Luc Vaucelle, chef de projet chez Continental France.
Parcours de pilotage
Le besoin de disposer d’un outil de pilotage de l’activité, d’une représentation graphique via des courbes d’évolution par exemple, se fait plus pressant. La décision de mettre en place un outil de requêtes et de reporting est prise pour rapidement combler ce manque de visibilité exprimé par les ingénieurs et les techniciens. Le cahier des charges est transmis aux principaux éditeurs de solution de reporting et de pilotage. Parmi les solutions disponibles, deux outils sont retenus pour une étude d’adéquation plus poussée : Forest & Trees de Computer Associates et BI Query de Hummingbird. « Chacun d’eux a reçu une réplique de la base de données ainsi qu’un jeu de requêtes identiques à des fins de prototypage. Suite à la présentation des maquettes, Hummingbird s’est véritablement détaché, notamment par sa facilité d’utilisation. Ils ont parfaitement su répondre à toutes nos questions. Un autre critère qui a joué en faveur d’Hummingbird reposait sur la pérennité de son application BI Query » précise notre interlocuteur. Les requêtes transmises concernaient notamment le rendement ou l’efficience d’un groupe de machines ou d’une section ; l’efficience correspondant au ratio production/réalisé sur engagement de la machine.
Charge et répartition
Les cartes de pointage alimentent l’application propriétaire de saisie des temps, associée à une base de données Sybase. Cette dernière documente une base dite « historique » avec une profondeur invariable de 18 mois, « au-delà, les résultats ont été analysés et il n’y aurait aucune pertinence à pousser plus loin l’historique », précise Luc Vaucelle.
Cinq mélangeurs sont connectés à la base IBM DB2 de la salle des mélanges vers laquelle sont également remontés des paramètres de processus qui permettent à l’entreprise de suivre des temps de cycle, des poids moyens, des températures, entre autres informations. Une autre base DB2 regroupe les données issues des six machines de la section préparation. La saisie d’informations, fédère une vingtaine de sections, auxquelles s’ajoute une quarantaine de machines attachées à la confection. « Nous avons pour objectif de procéder à l’identique pour la vulcanisation et de remonter les données issues de notre parc de presses afin de suivre leur taux de rendement synthétique » expose Luc Vaucelle.
Depuis leurs pupitres les opérateurs de la salle de mélanges et des lignes d’extrusion renseignent une base DB2, via d’autres systèmes, sur les temps ou la situation machine : panne et quel type de panne, changement de production, en cours de nettoyage ou de maintenance, etc.
Contrairement à la base de saisie des temps, les base de production sont la cible directe des requêtes « nous avions peur que cette prise directe n’occasionne des ralentissement ou des pertes de performances, mais ce cas de figure est jusqu’ici sans conséquence » poursuit-il. D’autres types de données, également destinée à la paie, viennent compléter l’ensemble.
DB2 et Sybase sont restées sur le mode transactionnel et un modèle de données a été construit. « Nous ne sommes pas sur un usage multidimensionnel, les indicateurs gérés ne nécessitent pas plusieurs dimensions d’analyse ou de créer un cube virtuel. Toutefois, nous disposons d’une licence Hummingbird, afin de pouvoir créer un cube si nécessaire, mais nous ne l’avons pas encore mis en œuvre. Aujourd’hui, le système mis en place nous déjà fournit énormément d’informations. Maintenons les indicateurs, gérons le volume d’information mis à notre disposition avant de pousser plus loin la recherche d’information et finalement de risquer de se perdre par excès d’informations ».
Dans un premier temps, la base historique est mise en place, les interfaces sont réalisées (mode batch) et dix rapports prédéfinis sont construits. « Aujourd’hui, ces derniers sont passés au nombre de cent cinquante, toutes sections confondues, chacun étant bien entendu destinataire des rapports qui le concerne. Techniquement, la solution BI Query s’organise entre une partie administration et une partie utilisateurs. Nos utilisateurs pourraient parfaitement créer leurs propres rapports, mais c’est un choix que nous n’avons pas fait, préférant maintenir leur élaboration au niveau de l’informatique. Quant aux difficultés, il n’y en pas véritablement. Si la base a été bien construite, le modèle est alors facile à réaliser. Je crois vraiment que le reporting exige de comprendre le fonctionnement d’une base de données, notamment au niveau des jointures qui imposent un minimum de connaissance. Le risque est avant tout technique, avec des ralentissements et des problèmes au niveau de l’optimisation des requêtes. Il faut vraiment savoir où aller chercher les éléments » conseille Luc Vaucelle.
BI Query répond à 100 % aux attentes exprimées dans le cahier des charges initial et va même au-delà comme l’exprime notre interlocuteur, « nous sommes pleinement satisfaits du produit d’autant qu’il nous a permis de dépasser notre objectif premier. La récupération des données issues des bases DB2 n’avait même pas été envisagée à l’origine du projet. Certaines de nos applications qui tournent en VB imposaient un développement pour chaque rapport, avec pour effet l’intervention d’un prestataire extérieur. Par l’intermédiaire de l’outil d’Hummingbird nous sommes parvenus à remplir cette tâche par nous-même et ce, dans des délais particulièrement rapides. Par ailleurs, l’outil s’est naturellement imposé comme le référentiel de tous les décideurs de l’entreprise. Les « business scorecards » établis chaque mois par le comité de direction, sont basés sur les chiffres issus de ce référentiel, nous disposons d’un socle commun d’information ».
Au quotidien, BI Query est disponible dans chaque service sur des postes référents, une quinzaine toutes sections confondues, depuis lesquels les ingénieurs, les techniciens et bientôt les chefs de poste viennent éditer les chiffres nécessaires à piloter leur activité.
Si ce projet n’est pas accompagné d’un plan de retour sur investissement, notre interlocuteur exprime un gain de productivité de 3,5 à 4 % (année 2002 comparée à 2001), sur les segments de productions couverts, « il est devenu possible d’identifier les disfonctionnements et d’y apporter le correctif adéquat ». Des gains qui expliquent un déploiement toujours plus tourné vers les opérationnels avec l’ouverture aux chefs de postes, mais également l’extension de BI Query au site de Clairoix (Compiègne) et une présentation prochainement prévue auprès de la direction de l’entreprise.
Cinq mélangeurs sont connectés à la base IBM DB2 de la salle des mélanges vers laquelle sont également remontés des paramètres de processus qui permettent à l’entreprise de suivre des temps de cycle, des poids moyens, des températures, entre autres informations. Une autre base DB2 regroupe les données issues des six machines de la section préparation. La saisie d’informations, fédère une vingtaine de sections, auxquelles s’ajoute une quarantaine de machines attachées à la confection. « Nous avons pour objectif de procéder à l’identique pour la vulcanisation et de remonter les données issues de notre parc de presses afin de suivre leur taux de rendement synthétique » expose Luc Vaucelle.
Depuis leurs pupitres les opérateurs de la salle de mélanges et des lignes d’extrusion renseignent une base DB2, via d’autres systèmes, sur les temps ou la situation machine : panne et quel type de panne, changement de production, en cours de nettoyage ou de maintenance, etc.
Contrairement à la base de saisie des temps, les base de production sont la cible directe des requêtes « nous avions peur que cette prise directe n’occasionne des ralentissement ou des pertes de performances, mais ce cas de figure est jusqu’ici sans conséquence » poursuit-il. D’autres types de données, également destinée à la paie, viennent compléter l’ensemble.
DB2 et Sybase sont restées sur le mode transactionnel et un modèle de données a été construit. « Nous ne sommes pas sur un usage multidimensionnel, les indicateurs gérés ne nécessitent pas plusieurs dimensions d’analyse ou de créer un cube virtuel. Toutefois, nous disposons d’une licence Hummingbird, afin de pouvoir créer un cube si nécessaire, mais nous ne l’avons pas encore mis en œuvre. Aujourd’hui, le système mis en place nous déjà fournit énormément d’informations. Maintenons les indicateurs, gérons le volume d’information mis à notre disposition avant de pousser plus loin la recherche d’information et finalement de risquer de se perdre par excès d’informations ».
Dans un premier temps, la base historique est mise en place, les interfaces sont réalisées (mode batch) et dix rapports prédéfinis sont construits. « Aujourd’hui, ces derniers sont passés au nombre de cent cinquante, toutes sections confondues, chacun étant bien entendu destinataire des rapports qui le concerne. Techniquement, la solution BI Query s’organise entre une partie administration et une partie utilisateurs. Nos utilisateurs pourraient parfaitement créer leurs propres rapports, mais c’est un choix que nous n’avons pas fait, préférant maintenir leur élaboration au niveau de l’informatique. Quant aux difficultés, il n’y en pas véritablement. Si la base a été bien construite, le modèle est alors facile à réaliser. Je crois vraiment que le reporting exige de comprendre le fonctionnement d’une base de données, notamment au niveau des jointures qui imposent un minimum de connaissance. Le risque est avant tout technique, avec des ralentissements et des problèmes au niveau de l’optimisation des requêtes. Il faut vraiment savoir où aller chercher les éléments » conseille Luc Vaucelle.
BI Query répond à 100 % aux attentes exprimées dans le cahier des charges initial et va même au-delà comme l’exprime notre interlocuteur, « nous sommes pleinement satisfaits du produit d’autant qu’il nous a permis de dépasser notre objectif premier. La récupération des données issues des bases DB2 n’avait même pas été envisagée à l’origine du projet. Certaines de nos applications qui tournent en VB imposaient un développement pour chaque rapport, avec pour effet l’intervention d’un prestataire extérieur. Par l’intermédiaire de l’outil d’Hummingbird nous sommes parvenus à remplir cette tâche par nous-même et ce, dans des délais particulièrement rapides. Par ailleurs, l’outil s’est naturellement imposé comme le référentiel de tous les décideurs de l’entreprise. Les « business scorecards » établis chaque mois par le comité de direction, sont basés sur les chiffres issus de ce référentiel, nous disposons d’un socle commun d’information ».
Au quotidien, BI Query est disponible dans chaque service sur des postes référents, une quinzaine toutes sections confondues, depuis lesquels les ingénieurs, les techniciens et bientôt les chefs de poste viennent éditer les chiffres nécessaires à piloter leur activité.
Si ce projet n’est pas accompagné d’un plan de retour sur investissement, notre interlocuteur exprime un gain de productivité de 3,5 à 4 % (année 2002 comparée à 2001), sur les segments de productions couverts, « il est devenu possible d’identifier les disfonctionnements et d’y apporter le correctif adéquat ». Des gains qui expliquent un déploiement toujours plus tourné vers les opérationnels avec l’ouverture aux chefs de postes, mais également l’extension de BI Query au site de Clairoix (Compiègne) et une présentation prochainement prévue auprès de la direction de l’entreprise.
