Couvertures de camion DiamondBack

Défis à relever

DiamondBack Truck Covers fabrique et vend des housses de lit de camionnette à coque rigide directement à
les clients. Les couvertures rigides aident les propriétaires de camions de divers modèles à protéger et à verrouiller les articles dans le
lit de camion. La société vend également une couverture robuste qui peut contenir quelque 1 600 livres.

Le co-fondateur Matt Chverchko a conçu la première couverture de la société lorsque lui et Ethan Wendle
étaient des étudiants en génie de Penn State dans le cadre d’un projet de classe. La réalisation de la taille de l'
marché potentiel, le duo a lancé la société en 2003 à Philipsburg, PA.

Les propriétaires de camions ont adoré le produit, et bientôt, la société bootstrapapped a décollé. Pour le passé
cinq ans, DiamondBack Covers a affiché une croissance à deux chiffres et compte maintenant plus de 35 $
millions de ventes annuelles. Cette croissance a aidé l’entreprise à atterrir sur les 5000 à la croissance la plus rapide d’Inc.
les entreprises s’insétent chaque année. DiamondBack emploie maintenant 140 personnes dans son usine de fabrication de pointe de 40 000 pieds carrés, un centre de distribution situé à un mile de la fabrication et un bureau de marketing et de vente situé à deux heures de distance à Harrisburg, en Pennsylvanie.

L’entreprise est un employeur important dans la petite ville de moins de 3 000 habitants.

Initialement, l’entreprise a vendu ses housses de lit de camion et ses accessoires par l’intermédiaire d’un concessionnaire automobile
, une vente qui obligeait les clients à visiter un concessionnaire physiquement. En 2010, ils ont abandonné cela
et a commencé à vendre directement aux consommateurs, une vente faite en appelant DiamondBack et en commandant
par téléphone. Sept ans plus tard, la société a lancé un site Web de commerce en utilisant Shopify.

« Traiter directement avec un fabricant à l’époque était vraiment du jamais vu », dit Kirk Davis,
Directeur des opérations. « Cela nous a vraiment distingués et nous a permis de mieux prendre soin de nos
et améliorer la qualité de nos produits.

DiamondBack Truck Covers a fonctionné sur QuickBooks et utilisé Shopify, Freightview, Salesforce,
et Shoptech E2, un système de gestion d’atelier de travail pour ses opérations de fabrication. Aucun des
les applications étaient connectées de manière fiable, ce qui a causé de multiples problèmes et beaucoup de gaspillage
le temps de coordination et de transfert des données.

« En tant que startup il y a 20 ans, nous avons créé des systèmes basés sur ce qui était disponible sur une base rentable à l’époque », explique Davis. « Nous avons fini par avoir beaucoup de systèmes différents qui
ont été boulonnés ensemble. Cela a fonctionné pendant un certain temps, mais ne nous a pas très bien servis. Le patchwork de
les systèmes étaient lents, maladroits et difficiles à naviguer, dit-il. De plus, ils ont dû ajouter des postes
pour gérer les données manuellement à mesure que le volume des transactions augmentait.

« Nous avions trois systèmes différents essayant d’alimenter QuickBooks liés à nos non gagnés
et les paiements anticipés », a déclaré Lori Murawski, directrice de la comptabilité. « Beaucoup d’information
provenait de Shopify, Salesforce et notre système E2 pour les retours. Cela a pris au moins deux heures
une journée pour qu’un employé traite toutes les commandes qui sont entrées.

Assembler et consolider les données pour clôturer un mois signifiait garder les livres ouverts pour
au moins 30 jours après la fin du mois pour s’assurer que les données de fret et les renseignements sur les cartes de crédit étaient
inclus. Les deux systèmes étaient autonomes. Il a fallu encore plus de temps pour recueillir des données à mettre à jour
les cadres supérieurs. « Nous avions de la difficulté à faire rapport en 20 jours », dit Murawski.
D’autres opérations ont également souffert du manque d’intégration des applications, explique Scott Stilson,
Gestionnaire des systèmes d’information. « Cela commençait vraiment à nous ralentir beaucoup », dit-il.

E2 fonctionnait sur une base de données SQL locale qui pourrait avoir été créée à la fin des années 1980,
il estime. « C’était très maladroit, et trois parties de notre flux de travail de devis en espèces étaient très
manuel, que nous avons dû jeter de la main-d’œuvre à gérer.

Babysitting l’importation E2
L’un de ces travaux manuels consistait à obtenir des commandes client dans E2. « C’était l’intégralité de quelqu’un
travail pour garder l’importation parce qu’il serait parfois jeter des messages d’erreur - que souvent
étaient sans conséquence - mais l’importation ne continuerait pas à moins que vous ne cliquiez sur OK », dit-il.
Malheureusement, la tâche incombait au gestionnaire des expéditions qui était responsable de l’alimentation
la production. Stilson estime que garder le système a pris environ 80 pour cent de son temps, quittant
seulement un peu de temps pour la gestion de l’expédition, conduisant à des goulots d’étranglement fréquents.

L’importation E2 s’est souvent écrasée. « C’était déchirant et nous perdions l’équivalent de jours entiers de
comptabilité parce que cela conduirait souvent à la corruption dans QuickBooks. C’était tout simplement terrible, et
a duré près d’un an. Tout le monde était toujours sur le qui-vive quant à savoir si l’information le ferait
faire son chemin de e2 à QuickBooks.

Processus d’expédition manuels
DiamondBack a dû embaucher plus de personnes pour gérer les processus d’expédition manuelle au fur et à mesure de sa croissance. « L'
le problème était qu’il n’y avait rien qui passait le numéro de suivi, le transporteur ou le coût du transporteur
de retour dans QuickBooks ou d’autres systèmes de Freightview », explique Stilson. « Ils étaient manuels
copier et coller le numéro de suivi, le nom de l’opérateur et les coûts dans Salesforce, qui
nous avons utilisé pour la compensation des commandes client.

Le service client devait ensuite 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 pour le
l’équipe de comptabilité lorsqu’elle avait besoin de faire correspondre les factures de fret à ce que nous avons enregistré », Stilson
ajoute. « Donc, encore une fois, lorsque le volume augmenterait, nous embauchions littéralement plus de gens. »

Jeu de correspondance de paiement
Une fois que les informations de commande et d’expédition ont été transférées à Salesforce, elles devaient être importées
retour dans E2, de sorte qu’il pourrait être inclus dans une autre synchronisation avec QuickBooks. Plus important encore,
ces importations synchronisées informations client, mais QuickBooks créerait un nouveau client
si quelque chose ne correspondait pas exactement, dit Stilson.

« Pendant ce temps, nous avons utilisé Authorize.net comme processeur de paiement, et leur synchronisation est d’écrire des trucs
à QuickBooks aussi, et cette synchronisation a des problèmes de fragilité ainsi. Première partie de ce que nous avons appelé
le jeu de correspondance de paiement consistait à prendre le client identifié dans Authorize.net et à le faire correspondre
avec l’enregistrement de paiement dans QuickBooks. Cette information devait ensuite être appariée à l'
facture, qui n’apparaît pas tant que le produit n’est pas expédié, et apparaît dans la synchronisation E2.

Mais la facture n’est pas automatiquement mariée à un dossier client, explique-t-il ; il pend juste
à l’extérieur. « Ainsi, la deuxième partie du jeu de correspondance de paiement est de faire correspondre le client et
le paiement de la facture, et c’est essentiellement tout ce que notre spécialiste en RA a fait parce que c’est tout
elle avait le temps pour.

Processus de production inefficaces
DiamondBack n’a pas fait confiance aux données E2 pour prendre des décisions d’achat en raison du calendrier de
lorsque le matériel a été alloué aux ordres de fabrication n’a pas servi leur achat juste-à-temps
stratégie. Au lieu de cela, ils se sont appuyés sur des systèmes de réapprovisionnement physique et des cartes Kanban pour savoir quand
pour réorganiser un composant. En outre, ce manque de confiance s’est traduit par d’importantes réserves d’inventaire
rapprochés lors du dénombrement annuel de l’inventaire physique.

« Nous avons connu une croissance moyenne de plus de 20% par an, ce qui est assez important pour un
entreprise de fabrication comme nous », dit Davis. « Lorsque nous aurions un gros arriéré, nous aurions
beaucoup d’unités vendues mais non expédiées. Toutes ces données se trouvent dans le système et il s’agirait d’un
gâchis puant. Plus il y avait de données dans le système, plus il fonctionnait lentement. C’était tellement douloureux.

La combinaison de tous les systèmes disparates, les remaniements de données qui prennent beaucoup de temps et le
la méfiance à l’égard des chiffres « nous a simplement rendus très rigides », dit Davis. « Nous avions l’impression d’être dans le
âges de pierre d’être en mesure de servir nos clients. Nous avons beaucoup de SKU et devons être en mesure de
pivoter rapidement pour servir nos clients. L’ancien système ne le prévoyait tout simplement pas.