AcumatiCares
Desafíos
Hasil Karya es una empresa con certificación ISO que cuenta con más de 50 empleados. La empresa importa más de 100 tipos de máquinas de Japón, Taiwán, China, Corea del Sur, Turquía, Italia y otros países. La empresa, con sede en Balakong, apoya la venta de maquinaria con un equipo interno de servicio posventa.
Hasil Karya se fundó cuando el Sr. Tee se dio cuenta de que las empresas artesanales malayas estaban creciendo y transformándose en fabricantes de equipos originales, y comprendió que las empresas del país necesitarían aumentar su productividad. El Sr. Tee empezó a importar máquinas, incluidas marcas chinas, y más tarde amplió el negocio para incluir la reparación y el mantenimiento de maquinaria.
En la actualidad, el Sr. Tee y sus dos hijos están llevando a Hasil Karya al siguiente nivel con una estrategia basada en inversiones de marca a largo plazo, ejecución disciplinada de las ventas, innovación y gestión centrada de los costes.
Durante 13 años, Hasil Karya utilizó un ERP de EE.UU. para gestionar el negocio, pero a medida que la empresa crecía, las cuotas de mantenimiento se hicieron abrumadoras, dice Junior Mr. Tee, director general. El sistema ERP funcionaba in situ, no permitía el acceso móvil del equipo de ventas o de servicios sobre el terreno y no era escalable.
Además, "el proveedor había subcontratado el soporte del ERP a un particular, lo que no era sostenible", afirma Junior Tee.
Cuando Hasil Karya puso en marcha el anterior sistema ERP, la empresa tenía 15 empleados y adquirió 16 licencias de usuario. Hoy, sin embargo, la empresa tiene 53 empleados, incluido un equipo de ingeniería de 22 personas que trabaja sobre el terreno. Los ingenieros no tenían acceso a información crítica mientras estaban en las obras.
"Cuando el negocio creció y añadimos más gente, los procesos se complicaron mucho más", dice el Sr. Tee.
Se necesita un programador dedicado
Para gestionar el equipo de servicio de campo, Hasil Karya necesitaba un coordinador dedicado a programar a los técnicos y repartir manualmente la información. El coordinador imprimía los formularios de trabajo, los entregaba a los técnicos y respondía a las preguntas cuando era necesario. Los ingenieros que se desplazaban a las instalaciones de los clientes a veces llamaban para comprobar la dirección, los clientes preguntaban cuándo llegarían los ingenieros y el coordinador a veces llamaba a los ingenieros para saber cuándo llegarían al trabajo de un cliente.
"No teníamos ninguna transparencia", dice el Sr. Junior Tee. "El proceso era bastante tedioso y molesto. Si un cliente tenía una pregunta, llamaba al vendedor, que tenía que preguntar al coordinador por un ingeniero, lo que significaba que el coordinador tenía que llamar al ingeniero, luego volver al vendedor, que a su vez volvía a llamar al cliente."
Sin acceso remoto desde el campo, Hasil Karya era reacia a adquirir licencias de usuario ERP adicionales. En su lugar, contrató a un desarrollador para que escribiera una aplicación de servicio de campo personalizada. "En aquella época, pensábamos que SAP era lo mejor", afirma Junior Tee. "No investigamos mucho, lo que fue un gran error".
Departamentos desconectados
Hasil Karya se enfrentaba a otros retos con el antiguo sistema ERP. Cuando llegó Covid y se cancelaron las ferias, la empresa recurrió a las redes sociales para encontrar clientes potenciales. Pero no había forma de hacer un seguimiento de los clientes potenciales después del contacto inicial.
Aunque introducían la información en una hoja de cálculo, los clientes potenciales se enviaban por correo electrónico a ventas, que tenía su propio proceso. Los estados de seguimiento no siempre se registraban en la hoja de cálculo original. Los gestores tenían que llamar a cada vendedor para conocer los resultados de un cliente potencial, lo que llevaba mucho tiempo y suponía un reto debido al gran número de clientes potenciales.
Falta de servicios de campo
Los procesos del antiguo sistema ERP no estaban conectados, afirma Junior Mr. Por ejemplo, los pedidos de compra no estaban conectados con los de venta, lo que daba lugar a varios errores. Algunos pedidos de venta no se cumplían porque el departamento de ventas se olvidaba de comunicárselo al equipo de compras, o porque compras se olvidaba de registrar un pedido verbal. O, sin información sobre el inventario, ventas podía aceptar un pedido de un artículo que no estaba en stock.
Localizar artículos concretos del inventario no era suficiente porque la información sobre cada marca y artículo se alojaba en bases de datos distintas, afirma. "Teníamos que desconectarnos y conectarnos a otra base de datos para obtener información, y luego desconectarnos y volver a conectarnos".
Mientras tanto, el desarrollador de la aplicación de servicios de campo a medida no conseguía entregar un producto que funcionara. "Entonces empezamos a investigar y descubrimos que existen módulos completos de servicios de campo y que muchos ERP los tienen", explica el Sr. Tee. "Pusimos fin al proyecto porque nos dimos cuenta de que el alcance era demasiado grande, la empresa de aplicaciones no podía desarrollarlo para nosotros y no funcionaría".
