Gestión de pedidos, un nuevo paradigma. 1ª Parte

Claves en gestión eficaz de pedidos: DATO y responsable ÚNICO, conducidos por reglas, ecuaciones y procesos organizados desde la concepción del producto. #AutomatizaciónProcesos

Un nuevo paradigma en la gestión de pedidos

El artículo forma parte de la serie Una visión panorámica de la automatización :

  • Core del negocio
  • Digitalización
  • Diferenciación vs Commodity
    1. Un nuevo paradigma en la gestión de pedidos
    2. La aversión al cambio
    3. La competencia ya está en ello
    4. Sectores industriales donde es una ventaja competitiva
  • Punta de lanza: nuevos métodos en la innovación
  • Implantación de proyectos
  • Softwares asociados a la automatización
  • Futuro de la automatización

 

Gestión actual de un pedido en la empresa, tanto estándar como especializado

¿Cómo trabajamos antes? O mejor dicho, ¿cómo estamos trabajando ahora? ¿Cómo obtenemos y gestionamos un pedido en la empresa? Estas preguntas en general, me gustaría responderlas en base a la experiencia que tenemos continuamente con empresas a las que hemos ayudado a cambiar este paradigma y nos han contado su problemática.

El proceso era, es, asombrosamente semejante entre estas empresas a pesar de pertenecer a sectores muy diferentes, que no tienen nada que ver unos con otros. Como suelo decir muchas veces: «si me dieran 10 euros cada vez que me han descrito esta sistemática de trabajo, ¡no tendría que desarrollar ninguna implantación!».
Bien, suelo oir repetidamente esta sistemática de trabajo para gestionar los pedidos, ya me dirán ustedes si se sienten identificados o no. Reproducimos aquí una típica conversación que he mantenido durante muchos años con gente muy diversa:

Cliente: Los pedidos los recogemos vía web o por correo electrónico, generalmente un PDF rellenado por parte de cliente con una plantilla fija que le proporcionamos.
Yo: ¿Y ahí está reflejado, en sus respuestas, todo el producto que necesita?
Cliente: Sí, claro,… [pausa de 2 segundos] Bueno, a ver, no. Hay un campo de observaciones donde el cliente anota sus requerimientos especiales
Yo: Aha, hmmm, ¿puedo ver ese PDF? … Gracias. A ver sí, sí, ya veo… el campo de observaciones es bastante amplio, ¿no?
Cliente: Sí, cierto, siempre hemos querido acotarlo pero no encontramos el momento para hacerlo, ni la manera
Yo: Y lo usan mucho imagino, ¿verdad?
Cliente: Sí, sí,… demasiado
Yo: Aha, hmmm, pero todo esto no se lo inventa el cliente, sabrá qué hacen ustedes y qué pueden hacer, ¿no?
Cliente: Sí, cierto, desde luego, claro, claro. Conocen nuestros productos muy bien, ¡son personalizados!
Yo: Entonces, quizás sería interesante estandarizar los modelos que ofrecen al cliente y…
Cliente: Ufff, eso lo hemos intentado muchas veces y no hay manera, además, luego cada uno de nosotros lo trata de forma diferente y no avanzamos en ello.
Yo: Vale, de acuerdo, otra cuestión. Estos datos del PDF, ¿quién los introduce en el sistema, en el ERP, en la oficina técnica,…?
Cliente: Depende.
Yo: Aha, hmmm… ¿Y puede ser que distintas personas usen el mismo dato y lo introduzcan varias veces?
Cliente: Pues sí, la verdad, ¿ves allí? La cota de altura del cajón principal la usa el ingeniero de oficina técnica y el diseñador de armarios.
Yo: Pero, el ingeniero y el diseñador, ¿sabrán lo que hacen uno y el otro o no están coordinados?
Cliente: Depende. Si el ingeniero cambia alguna regla de la estructura general, debe avisar al diseñador, sino, no hace falta
Yo: Aha, hmmm… O sea, que hay una gran comunicación entre ambas secciones, entiendo.
Cliente: Supongo. Sino, nos enteramos en fábrica porque no coinciden el diseño del armario con el espacio que debería ocupar. La verdad, ahora que lo pienso es una incidencia bastante frecuente. ¡Mira que lo hemos hablado en las reuniones técnicas de los lunes, joer!
Yo: Aha, hmmm… Veo que hay bastante libertad desde la concepción del producto en sí hasta la definición de un pedido concreto.
Cliente: Así es, es que nuestros equipos son muy especiales, somos los únicos que nos ajustamos a las demandas del cliente y claro, eso nos atasca toda la oficina técnica… En fin, que para eso te hemos llamado.

¿Qué hacer? ¿Por dónde empezar? Aunque he resumido y usado muchos tópicos no estoy muy lejos de lo que podría ser una conversación habitual con un cliente con problemas de gestión de pedidos tanto estándares como especializados. Así que . En adelanto:

Gestión eficaz de un pedido en la empresa

Vamos a plantear y definir cuáles serían las claves de una gestión eficaz de un pedido en la empresa, independiente mente del sector en el que nos encontremos. Estos son los puntos clave de este nuevo paradigma de gestión:

  • Dato único en la gestión de un producto, lo vemos a continuación
  • Decisiones y datos conducidos por reglas y ecuaciones (siguientes entregas)
  • Procesos organizados y reglados desde la concepción del producto (siguientes entregas)

agent agreement boss brainstorming business businessman 1459021

El dato único en la gestión de un pedido

No podemos avanzar muy lejos si no tenemos claro que el dato es sagrado y por tanto, no puede ser manoseado (perdón por la palabra) por cualquier colaborador en una empresa, solo debería hacerse responsable de cada dato la persona íntimamente ligada al mismo: nos referimos a su introducción y ediciones, por supuesto; la consulta del dato es otro tema diferente.

El ejemplo anterior me ha servido para presentar la problemática con los datos que introduce el cliente para obtener un pedido, pero en la gestión de un pedido hay datos de muy diversa índole. Sostenemos que los responsables de los siguientes datos deben ser quienes lo introduzcan en este ciclo:

  • Datos del cliente: únicamente, el cliente; o en su defecto, el equipo técnico que realice la preventa o venta del producto o servicio
  • Datos que definen un producto: el departamento de ingeniería, I+D, Especiales, Desarrollos, etc.
  • Datos relativos a costes, compras: el responsable de compras
  • Datos comerciales: descuentos, rápeles, y todo lo relacionado con la facturación de clientes, el director comercial o su personal de confianza
  • Datos…. y así con todos los que componente un producto, un pedido, un servicio.
Un corolario o lema, podría ser: «Un dato, un responsable, una sola vez introducido«, y a continuación definimos, como, a nuestro entender, debe ser el ciclo de vida de cualquier dato.

La naturaleza de los datos

Es preciso reconocer que los datos tienen diferentes naturalezas y qué mejor que una clasificación sencilla para explicar mejor nuestras ideas:

  1. Datos externos del producto: es aquel dato que tiene que definir un cliente que desea obtener un producto concreto. La longitud de una nave industrial, la carga máxima de una grúa o el color de las puerta de un armario de cocina. El cliente debe dar forma al producto que desea.
  2. Dato internos del producto: son aquellos que lo definen como tal, las variables o constantes que, según unas determinadas reglas, conforman el comportamiento del producto en sí. Son datos con una fuerte ligazón entre sí, el alma del producto y por tanto, deben permanecer ocultos en la mayor parte del ciclo de vida de un pedido, ¡o en todo el!
  3. Datos de gestión del producto: son datos necesarios para la gestión del proyecto o pedido, pero que no definen al producto en sí mismo aunque son indispensables para su gestión interna y poder organizar su entrega final al cliente y la relación con nuestros proveedores. Por ejemplo, el descuento a un determinado cliente o el código para su gestión interna. Son datos «commodity», inherentes a la forma de como queremos gestionar el producto, nuestra empresa tiene unos en concreto, pero que otra empresa podría tenerlos diferentes para un idéntico producto.

Nota: los datos de producción suelen, dependiendo de la naturaleza del producto y la empresa, clasificarse en datos internos o datos de gestión.

Tratamiento de datos externos del producto

Para que un cliente o una persona de la organización pueda ordenar un pedido y tenga claro qué datos debe introducir debemos guiarlo en el proceso y debemos proporcionarle un medio inequívoco de uso que le ofrezca un resultado final viable. Para ello, es preciso el uso de configuradores comerciales y que la interfaz del configurador sea exquisita, con una gran usabilidad, sobre todo, si queremos colocarlo de una web.

Tratamiento de datos internos del producto

En cambio, los datos internos y gestión deben llevar otro tratamiento, que, obviamente, nos llevarían varios capítulos poder definir la forma de hacerlo, y que probablemente hagamos en alguna otra serie; basten estas premisas meramente orientativas:

  1. Confeccionar un protocolo de diseño y gestión de los datos donde se indique su naturaleza, responsable, edición, etc.
  2. Disponer de un gestor documental donde almacenar los datos: puede ser cualquier BBDD ad hoc o herramientas especializadas.

Observamos que los datos internos y los procesos que los manejan merecen una implementación seria y bien establecida. Como hemos comentado hace referencia a como los departamentos técnicos, ingeniería o I+D trabajan y éstos deben ser sumamente competitivos aunque en muchas ocasiones, la mayor parte de su tiempo o de sus recursos se dedican, precisamente a la gestión de estos datos/procesos lo cual podríamos decir que supone una pérdida de tiempo que recursos tan valiosos empleen sus esfuerzos en procesos de apoyo (commodities) que no aportan ni valor ni competitividad al producto, ni a la empresa.

Datos de gestión del producto

Como podemos entender, este tipo de datos no supone, refiriéndonos a su tratamiento, una ventaja competitiva en sí, no vamos a lograr desbancar a un competidor porque gestionemos mejor pero, probablemente, si que perderemos capacidad competitiva si no tenemos una gestión ordenada.

Para ello, hay procedimientos y modelos de trabajar que seguramente conoceremos todos: CRM, ERP, MRP, y otras siglas que describen softwares específicos para la gestión del entorno de la empresa (y del producto) y del que no vamos a hacer más hincapié.

La novedad que queremos aportar en este apartado se basa en que todos los datos de las distintas naturalezas deben estar integrados y no considerarse en módulos estancos: en este punto si que podemos encontrar una diferenciación tremenda con los competidores adoptando integración de procesos y logrando que el ciclo de vida de un pedido sea compartido y completamente automatizado.

technology web internet macro blue electricity 1089512

Edición

Para no alargar mucho más el artículo, sobre la edición de los datos, nos redirigimos al inicio del capítulo: cada responsable debe gestionar y estar al cargo de la edición, evolución y vida de sus datos. De otro modo, sería ingobernable y caótico el mantenimiento del sistema en sí.

En próximas entregas veremos como todos estos datos se conducen, se relacionan entre sí, qué procesos son necesarios para automatizar el ciclo de vida de un pedido desde el origen del propio producto en los departamentos técnicos.

 

Compartir

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *


DirveWokrs Pro Software
Digipara Liftdesigner Software
SolidWorks Software
ANSYS Software