Défis
DiamondBack Truck Covers fabrique et vend directement aux clients des couvertures de caisse de pick-up à coque dure.
clients. Les housses rigides aident les propriétaires de camions de différents modèles à protéger et à verrouiller les objets se trouvant dans la caisse du camion.
dans la caisse du camion. L'entreprise vend également une housse résistante qui peut supporter un poids de 1 600 livres.
Le cofondateur Matt Chverchko a conçu la première couverture de l'entreprise alors qu'Ethan Wendle et lui-même étaient étudiants en ingénierie à Penn State, dans le cadre d'un projet de classe.
étaient étudiants en ingénierie à Penn State, dans le cadre d'un projet de classe. Réalisant la taille du marché potentiel, le duo a lancé la société en 2003 à Philipsburg, en Pennsylvanie.
marché potentiel, le duo a lancé l'entreprise en 2003 à Philipsburg, en Pennsylvanie.
Les propriétaires de camions ont adoré le produit et l'entreprise a rapidement pris son envol. Au cours des cinq dernières années, DiamondBack Covers a connu une croissance à deux chiffres.
cinq ans, DiamondBack Covers a affiché une croissance à deux chiffres et affiche aujourd'hui un chiffre d'affaires annuel de plus de 35 millions de dollars.
millions de dollars de chiffre d'affaires annuel. Cette croissance a permis à l'entreprise de figurer sur la liste des 5000 entreprises à la croissance la plus rapide de l'Inc.
d'Inc.. DiamondBack emploie aujourd'hui 140 personnes dans son usine de fabrication ultramoderne de 40 000 pieds carrés, dans son centre de traitement des commandes situé à un kilomètre de l'usine et dans son bureau de marketing et de vente situé à deux heures de route, à Harrisburg, en Pennsylvanie.
L'entreprise est un employeur important dans cette petite ville de moins de 3 000 habitants.
À l'origine, l'entreprise vendait ses housses et accessoires pour camions par l'intermédiaire de distributeurs automobiles, ce qui obligeait les clients à se rendre physiquement chez les concessionnaires.
automobiles, ce qui obligeait les clients à se rendre physiquement chez un concessionnaire. En 2010, elle a abandonné cette
stratégie et a commencé à vendre directement aux consommateurs, en appelant DiamondBack et en commandant par téléphone.
par téléphone. Sept ans plus tard, l'entreprise a lancé un site web commercial en utilisant Shopify.
"À l'époque, traiter directement avec un fabricant était vraiment inédit", explique Kirk Davis,
directeur des opérations. "Cela nous a vraiment distingués et nous a permis de mieux nous occuper de nos clients et d'améliorer la qualité de nos produits.
clients et d'améliorer la qualité de nos produits".
DiamondBack Truck Covers fonctionne avec QuickBooks et utilise Shopify, Freightview, Salesforce,
et Shoptech E2, un système de gestion d'atelier pour ses opérations de fabrication. Aucune des
applications n'était connectée de manière fiable, ce qui entraînait de nombreux problèmes et beaucoup de temps perdu à coordonner et à transférer les données.
temps perdu à coordonner et à transférer des données.
"En tant que start-up il y a 20 ans, nous avons créé des systèmes sur la base de ce qui était disponible à l'époque à un coût raisonnable", explique M. Davis. "Nous avons fini par avoir beaucoup de systèmes différents qui ont été boulonnés ensemble.
différents boulonnés les uns aux autres. Cela a fonctionné pendant un certain temps, mais ne nous a pas servi à grand-chose". La mosaïque de systèmes
Le patchwork de systèmes était lent, encombrant et difficile à utiliser, dit-il. En outre, l'entreprise a dû ajouter des postes
pour traiter les données manuellement à mesure que le volume des transactions augmentait.
Nous avions trois systèmes différents qui essayaient d'alimenter QuickBooks en ce qui concerne nos recettes non acquises et nos paiements anticipés", explique Lori Murawski, directrice de la comptabilité.
et les paiements anticipés", explique Lori Murawski, directrice de la comptabilité. "Beaucoup d'informations
de Shopify, de Salesforce et de notre système E2 pour les retours. Il fallait au moins deux heures
Il fallait au moins deux heures par jour à un employé pour traiter toutes les commandes qui nous parvenaient."
L'assemblage et la consolidation des données pour clôturer un mois impliquaient de garder les livres ouverts pendant
au moins 30 jours après la fin du mois pour s'assurer que les données relatives au fret et les informations sur les cartes de crédit étaient incluses.
cartes de crédit. Les deux systèmes étaient autonomes. Il fallait encore plus de temps pour rassembler les données afin d'informer les dirigeants.
pour mettre à jour les cadres de l'entreprise. "Nous avions du mal à produire des rapports en 20 jours", explique M. Murawski.
D'autres opérations ont également souffert du manque d'intégration des applications, explique Scott Stilson,
responsable des systèmes d'information. "Cela commençait vraiment à nous ralentir", déclare-t-il.
E2 fonctionnait sur une base de données SQL sur site qui pourrait avoir été construite à la fin des années 1980,
estime-t-il. "C'était très lourd, et trois parties de notre flux de travail du devis à l'encaissement étaient très manuelles, et nous devions y consacrer du personnel pour les gérer.
manuelles, pour lesquelles nous devions mobiliser de la main d'œuvre".
Garder l'importation E2
L'une de ces tâches manuelles consistait à importer les commandes clients dans E2. "C'était le travail de quelqu'un de garder l'importation parce qu'il y avait parfois des messages d'erreur.
de surveiller l'importation, car elle générait parfois des messages d'erreur - souvent sans conséquence - mais l'importation ne se poursuivait pas tant que l'on ne cliquait pas sur OK", explique-t-il.
d'erreur - souvent sans conséquence - mais l'importation ne se poursuivait pas tant que l'on ne cliquait pas sur OK", explique-t-il.
Malheureusement, cette tâche incombait au responsable des expéditions, qui était chargé d'alimenter la production.
production. Mme Stilson estime que le gardiennage du système lui prenait environ 80 % de son temps, ce qui ne lui laissait qu'une infime partie du temps nécessaire à la gestion de l'entreprise.
de temps pour gérer les expéditions, ce qui entraînait de fréquents goulets d'étranglement.
L'importation E2 tombait souvent en panne. "C'était pénible et nous perdions des jours entiers de comptabilité car cela entraînait souvent une corruption dans QuickBooks.
jours entiers de comptabilité, car cela entraînait souvent une corruption dans QuickBooks. C'était tout simplement terrible, et cela a duré près d'un an.
et cela a duré près d'un an. Tout le monde était toujours inquiet de savoir si les informations allaient passer de E2 à QuickBooks.
E2 à QuickBooks".
Processus d'expédition manuels
DiamondBack a dû embaucher davantage de personnes pour gérer les processus d'expédition manuels au fur et à mesure de sa croissance. "Le problème
Le problème était qu'il n'y avait rien pour transmettre le numéro de suivi, le transporteur ou le coût du transporteur à QuickBooks ou à d'autres systèmes de Freightview", explique M. Stilson.
dans QuickBooks ou dans d'autres systèmes de Freightview", explique M. Stilson. "Ils copiaient et collaient manuellement le numéro de suivi, le transporteur ou le coût du transporteur.
Ils copiaient et collaient manuellement le numéro de suivi, le nom du transporteur et les coûts dans Salesforce, que nous utilisions pour la compensation des commandes.
que nous utilisions pour la compensation des commandes".
Le service clientèle devait alors se connecter à Salesforce si un client appelait pour obtenir des informations.
Les informations d'expédition dans Salesforce "servaient également de point de référence à l'équipe comptable lorsqu'elle devait comparer les factures de fret à ce que nous avions enregistré".
l'équipe comptable lorsqu'elle devait comparer les factures de fret à ce que nous avions enregistré", ajoute M. Stilson.
ajoute M. Stilson. "Là encore, lorsque le volume augmentait, nous devions littéralement embaucher plus de personnel.
Jeu de correspondance des paiements
Une fois les informations de commande et d'expédition transférées dans Salesforce, elles devaient être réimportées dans E2, afin d'être incluses dans une autre synchronisation avec QuickBooks.
dans E2, afin qu'elles puissent être incluses dans une autre synchronisation avec QuickBooks. Le plus important est que
ces importations synchronisent les informations sur les clients, mais QuickBooks crée de nouveaux
clients si quelque chose ne correspondait pas exactement, explique Stilson.
"Entre-temps, nous avons utilisé Authorize.net comme processeur de paiement, et leur synchronisation écrit également des choses dans QuickBooks.
à QuickBooks, et cette synchronisation a également des problèmes de fragilité. La première partie de ce que nous appelons
le jeu de correspondance des paiements consistait à prendre le client identifié dans Authorize.net et à le faire correspondre à l'enregistrement du paiement dans QuickBooks.
avec l'enregistrement du paiement dans QuickBooks. Ces informations devaient ensuite être mises en correspondance avec la facture, qui ne s'affiche pas dans la base de données.
facture, qui n'apparaît pas tant que le produit n'est pas expédié, et qui apparaît dans la synchronisation E2".
Mais la facture n'est pas automatiquement liée à un dossier client, explique-t-il.
elle ne fait que traîner. "La deuxième partie du jeu de correspondance des paiements consiste donc à faire correspondre le client et le paiement à la facture.
client et le paiement à la facture, et c'est à peu près tout ce que faisait notre spécialiste AR, car c'est tout ce qu'elle avait le temps de faire.
Elle n'avait pas le temps de s'en occuper.
Processus de production inefficaces
DiamondBack ne faisait pas confiance aux données E2 pour prendre ses décisions d'achat, car le moment où le matériel était affecté aux commandes de production ne correspondait pas à ses besoins en matière d'achats juste à temps.
l'affectation des matériaux aux commandes de production ne correspondait pas à leur stratégie d'achat en flux tendu.
juste à temps. Au lieu de cela, elle s'appuyait sur des systèmes de réapprovisionnement physiques et des cartes Kanban pour savoir quand réapprovisionner un composant.
pour savoir quand commander à nouveau un composant. En outre, ce manque de confiance s'est traduit par d'importantes réserves de stock
réconciliées lors de l'inventaire physique annuel.
Nous avons connu une croissance moyenne de plus de 20 % par an, ce qui n'est pas négligeable pour une entreprise manufacturière comme la nôtre", explique M. Davis.
pour une entreprise manufacturière comme la nôtre", explique M. Davis. "Lorsque nous avions un carnet de commandes important, nous avions beaucoup d'unités vendues mais non expédiées.
beaucoup d'unités vendues mais non expédiées. Toutes ces données se trouvaient dans le système et c'était un véritable gâchis.
un véritable gâchis. Plus il y avait de données dans le système, plus il fonctionnait lentement. C'était vraiment pénible".
La combinaison de tous les systèmes disparates, des mélanges de données qui prennent du temps et de la méfiance à l'égard des chiffres "nous a rendus très rigides", explique M. Davis.
La combinaison de tous les systèmes disparates, des mélanges de données qui prennent du temps et de la méfiance à l'égard des chiffres "nous a rendus très rigides", explique M. Davis. "Nous avions l'impression d'être à l'âge de pierre en ce qui concerne notre capacité à servir nos clients.
Nous avions l'impression d'être à l'âge de pierre en ce qui concerne notre capacité à servir nos clients. Nous avons beaucoup d'UGS et nous devons être capables de pivoter rapidement pour servir nos clients.
rapidement pour servir nos clients. Le système précédent ne nous permettait tout simplement pas de le faire".