AcumatiCares
Desafíos
DiamondBack Truck Covers fabrica y vende fundas rígidas para camionetas directamente a los clientes.
clientes. Las cubiertas duras ayudan a los propietarios de camionetas de varios modelos a proteger y bloquear los artículos en la
de la camioneta. La empresa también vende una cubierta de alta resistencia que puede soportar unas 1.600 libras.
El cofundador Matt Chverchko diseñó la primera cubierta de la empresa cuando él y Ethan Wendle
eran estudiantes de ingeniería en Penn State como parte de un proyecto de clase. Al darse cuenta del
mercado potencial, el dúo lanzó la empresa en 2003 en Philipsburg, Pensilvania.
A los propietarios de camiones les encantó el producto y pronto la empresa, que había empezado a funcionar sin ayuda de nadie, despegó. En los últimos
últimos cinco años, DiamondBack Covers registró un crecimiento de dos dígitos y ahora cuenta con más de 35 millones de dólares en ventas anuales.
millones de dólares en ventas anuales. Este crecimiento ha ayudado a la empresa a entrar en la lista anual de las 5000 empresas de más rápido crecimiento de Inc.
de Inc. En la actualidad, DiamondBack cuenta con 140 empleados en sus modernas instalaciones de fabricación de 40.000 pies cuadrados, un centro de distribución situado a un kilómetro y medio de la fábrica y una oficina de marketing y ventas a dos horas de distancia, en Harrisburg (Pensilvania).
La empresa es uno de los principales empleadores de esta pequeña ciudad de menos de 3.000 habitantes.
Inicialmente, la empresa vendía sus cubiertas y accesorios para camas de camiones a través de distribuidores de automóviles, una venta que requería que los clientes visitaran físicamente un concesionario.
distribuidores de automóviles, una venta que requería que los clientes visitaran físicamente un concesionario. En 2010, abandonaron esa
estrategia y comenzó a vender directamente a los consumidores, una venta que se realiza llamando a DiamondBack y haciendo el pedido por teléfono.
por teléfono. Siete años más tarde, la empresa lanzó un sitio web de comercio utilizando Shopify.
"Tratar directamente con un fabricante en aquella época era algo realmente inaudito", afirma Kirk Davis,
Director de Operaciones. "Realmente nos diferenció y nos permitió atender mejor a nuestros
clientes y mejorar la calidad de nuestros productos".
DiamondBack Truck Covers funcionaba con QuickBooks y utilizaba Shopify, Freightview, Salesforce,
y Shoptech E2, un sistema de gestión de talleres para sus operaciones de fabricación. Ninguna de
aplicaciones estaba conectada de forma fiable, lo que provocaba múltiples problemas y una gran pérdida de tiempo en la coordinación y transferencia de datos.
tiempo perdido coordinando y transfiriendo datos.
"Cuando empezamos hace 20 años, creamos sistemas basados en lo que había disponible en ese momento de forma rentable", dice Davis. "Acabamos teniendo montones de sistemas diferentes que
atornillados entre sí. Eso funcionó durante un tiempo, pero no nos sirvió de mucho". El mosaico de
El mosaico de sistemas era lento, tosco y difícil de manejar, afirma. Además, tenían que añadir puestos
para manejar los datos manualmente a medida que crecía el volumen de transacciones.
"Teníamos tres sistemas diferentes que intentaban alimentar QuickBooks en relación con nuestros ingresos no devengados y pagos anticipados", explica Lori Murawski, Directora de Contabilidad.
no devengados y los pagos anticipados", explica Lori Murawski, Directora de Contabilidad. "Mucha información
provenía de Shopify, Salesforce y nuestro sistema E2 para devoluciones. Un empleado tardaba al menos dos horas
al día para que un empleado procesara todos los pedidos que llegaban".
Reunir y consolidar datos para cerrar un mes significaba mantener los libros abiertos durante
al menos 30 días después del final del mes para garantizar que se incluían los datos de flete y la información de las tarjetas de crédito.
de crédito. Ambos sistemas eran independientes. Llevaba aún más tiempo recopilar datos para poner al día a los ejecutivos.
actualizar a los ejecutivos. "Teníamos problemas para elaborar informes en 20 días", afirma Murawski.
Otras operaciones también sufrían la falta de integración de las aplicaciones, dice Scott Stilson,
Director de Sistemas de Información. "Realmente empezaba a ralentizarnos mucho", afirma.
E2 funcionaba con una base de datos SQL local que podría haberse construido a finales de los años ochenta,
estima. Era muy torpe, y tres partes de nuestro flujo de trabajo del presupuesto al cobro eran muy manuales, por lo que teníamos que emplear mano de obra para gestionarlas".
manual, que teníamos que gestionar con mano de obra".
Cuidando el E2 Import
Uno de esos trabajos manuales era introducir los pedidos de ventas en E2. "Era todo el trabajo de alguien
importación porque a veces arrojaba mensajes de error, que a menudo eran intrascendentes.
pero la importación no continuaba a menos que se pulsara OK", explica.
Por desgracia, la tarea recaía en el responsable de envíos, que era el encargado de alimentar
producción. Stilson calcula que cuidar del sistema le ocupaba el 80% de su tiempo, lo que le dejaba sólo una pizca de tiempo para dedicarse a la producción.
tiempo para gestionar los envíos, lo que provocaba frecuentes cuellos de botella.
La importación de E2 se estrellaba a menudo. "Era angustioso y perdíamos la contabilidad de días enteros porque a menudo se corrompía en QuickBooks.
días de contabilidad porque a menudo se corrompía QuickBooks. Era terrible, y
duró casi un año. Todo el mundo estaba en vilo por si la información llegaría de E2 a QuickBooks.
de E2 a QuickBooks".
Procesos de envío manuales
DiamondBack tuvo que contratar a más personas para gestionar los procesos manuales de envío a medida que crecía. "El
problema era que no había nada que pasara el número de seguimiento, el transportista, o el coste del transportista
a QuickBooks u otros sistemas de Freightview", afirma Stilson. "Estaban copiando y pegando
copiaban y pegaban manualmente el número de seguimiento, el nombre del transportista y los costes en Salesforce, que utilizábamos para la compensación de pedidos de venta.
que utilizábamos para la compensación de pedidos de ventas".
El servicio de atención al cliente tenía que entrar en Salesforce si un cliente llamaba en busca de información.
La información de envío en Salesforce "también servía como punto de referencia para el
equipo de contabilidad cuando necesitaban cotejar las facturas de flete con lo que registrábamos", añade Stilson.
añade. "Así que, de nuevo, cuando el volumen aumentaba, literalmente contratábamos a más gente".
Juego de correspondencia de pagos
Una vez que la información de pedidos y envíos se transfería a Salesforce, era necesario importarla de nuevo a E2 para poder incluirla en otra sincronización con QuickBooks.
de nuevo a E2, para poder incluirla en otra sincronización con QuickBooks. Y lo que es más importante,
Estas importaciones sincronizaban la información de los clientes, pero QuickBooks creaba nuevas cuentas de clientes si algo no coincidía exactamente.
cuentas de clientes si algo no coincidía exactamente, dice Stilson.
"Mientras tanto, hemos utilizado Authorize.net como nuestro procesador de pagos, y su sincronización está escribiendo cosas
a QuickBooks también, y esta sincronización tiene problemas de fragilidad también. Parte uno de lo que llamamos
el juego de coincidencia de pagos era tomar el cliente identificado en Authorize.net y compararlo
con el registro de pago en QuickBooks. Esa información luego tenía que ser emparejado con el
factura, que no aparece hasta que se envía el producto y aparece en la sincronización E2".
Pero la factura no se vincula automáticamente a ningún registro de cliente, explica.
simplemente. "La segunda parte del juego de la correspondencia de pagos consiste en hacer corresponder el cliente y el pago con la factura.
cliente y el pago con la factura, y esto era básicamente todo lo que hacía nuestra especialista en AR porque era todo para lo que tenía tiempo".
tiempo".
Procesos de producción ineficaces
DiamondBack no confiaba en los datos de E2 para tomar decisiones de compra porque el momento de
cuando el material se asignaba a las órdenes de producción no servía para su estrategia de compras justo a tiempo.
justo a tiempo. En su lugar, se basaban en sistemas físicos de reposición de pedidos y tarjetas Kanban para saber cuándo
reordenar un componente. Además, esa falta de confianza provocaba grandes reservas de inventario
conciliadas durante el recuento anual del inventario físico.
"Hemos crecido una media de más del 20% anual, lo que es bastante grande para una
empresa de fabricación como nosotros", dice Davis. "Cuando teníamos una gran cartera de pedidos, teníamos muchas unidades vendidas pero no enviadas.
muchas unidades vendidas pero no enviadas. Todos esos datos estarían en el sistema y sería un
un caos apestoso. Cuantos más datos había en el sistema, más lento funcionaba. Era muy doloroso".
La combinación de todos los sistemas dispares, la lenta confusión de datos y la desconfianza en los números "nos hizo muy rígidos", dice Davis.
desconfianza en los números "nos hizo realmente rígidos", dice Davis. "Nos sentíamos como si estuviéramos
en la Edad de Piedra para atender a nuestros clientes. Tenemos muchas SKU y tenemos que ser capaces de
pivotar rápidamente para servir a nuestros clientes. El sistema anterior no lo permitía".
