Lo que nos dice la CRM es que no se realice la PLM de la misma forma

Introducción ¿Qué tiene que ver la CRM con la PLM?

La gestión del ciclo de vida de los productos (PLM) no funciona, pero debería. Básicamente, la idea de que se pueden diseñar mejores productos y traerlos al mercado más rápido al mejorar el conocimiento y la experiencia desde nuestra propia cadena de valor y desde nuestros clientes y proveedores no suena mal.

Es sólo que el hecho de comprar una PLM no siempre hace que esto funcione. Desde mi punto de vista, el acercamiento general de la industria y la actitud hacia la PLM los primeros días de la adopción de la gestión de las relaciones con los clientes (CRM), y las lecciones de tal experiencia debería ayudarle a abordar el “si…” y el “cómo” de la inversión en PLM.

De lo que la CRM realmente se trata se puede resumir en cuatro puntos:

• Recolectar todos los datos concernientes al cliente para habilitar y autorizar a los individuos, las llamadas "vistas únicas de los clientes”.
  
  
• Presentar los datos de tal forma que sea significativa para distintos usuarios.
  
  
• Entregar una funcionalidad específica de “cuidado al cliente”, como gestión de ventas, soporte y gestión de llamadas.
  
  
• Utilizar la información recolectada para ajustar los procesos y las ofertas del producto para entregarle al cliente un valor mayor.

Esta bien, ahora hay que lidiar con ello. Encontrar una definición inteligente e inteligible para PLM no es tan sencillo como parece a pesar de ser “lo último” en fabricación y en ingeniería; a continuación se intentará definir:

La gestión del ciclo de vida de los productos se lleva a cabo cuando la compañía controla el diseño y la entrega del producto desde que se crea hasta que se entrega; reduce los costos del producto y de los procesos a través de una colaboración interna efectiva y con la cadena de suministro; y puede aprender de las experiencias.

…lo cual es bastante para un solo bocado. Al ver la definición por puntos, PLM se trata de:

• Recolectar todos los datos concernientes al producto para habilitar y autorizar a los individuos, esto se puede llamar “la vista única del producto”.
  
  
• Presentar los datos de tal forma que sea significativa para distintos usuarios del producto, y permitir la colaboración y la contribución con terceros.
  
  
• Entregar una funcionalidad específica de gestión de diseño, como la gestión de revisión del flujo de trabajo del los modelos (en especial en los sistemas paramétricos tridimensionales (3D) donde los diseños de los componentes se vuelven a utilizar, por lo que es muy importante entender las referencias cruzadas) para manejar los procesos.
  
  
• Utilizar la información recolectada para ajustar los procesos y las ofertas del producto para entregarle al cliente un valor mayor.

Ahora empieza a ver hacia dónde vamos. . . PLM es a los productos como CRM es a los clientes.

Así que ¿qué es lo que se puede aprender acerca de CRM para que funcione PLM?

Reto 1: Entender la importancia de integración

En primer lugar, CRM es un asunto de integración. Para presentar sólo una vista del cliente, se tienen que cotejar todos los datos electrónicos relevantes de los sistemas existentes, y poner en orden los procesos y procedimientos para recolectar los datos que no existen en ningún sistema formal.

Entonces, lo que primero necesita CRM es la existencia de una solución de planificación de los recursos de la empresa (ERP), o por lo menos algunas aplicaciones unidas, posiblemente con la ayuda de un middleware extra para la integración de los sistemas y para poder alimentarlo.

Algo parecido es cierto para PLM, excepto que está en medio de dos piezas muy diferentes y muy importantes de la arquitectura: el sistema de diseño asistido por computadora (CAD) y el sistema de ERP. Por lo tanto, no es una simple interfase sencilla, por lo menos son dos. El flujo de datos es iterativo y bidireccional. La integración necesita representar datos estructurados (como la nomenclatura y los datos de las partes), los datos no estructurados (incluyendo descripciones, narraciones y multimedia), y el flujo de trabajo.

Por extraño que parezca, integrar el flujo de trabajo es el reto más grande. El flujo de trabajo es benéfico en especial para controlar procesos interdepartamentales, sin embargo, cada uno de los sistemas CRM y ERP tienen máquinas de flujo de trabajo. Por lo general, el sistema PLM lo añadirá a su propio sistema. El problema es cuál se debe utilizar, o cómo hacer para que se comuniquen. (Más adelante se volverá a hablar acerca del flujo de trabajo)

Reto 2: escoger entre el vendedor de CAD y el de ERP

Tanto los vendedores de CAD como los de ERP intentarán venderle PLM (la “pieza del medio” entre CAD y ERP), utilizando argumentos similares de duda, incertidumbre y miedo.

Los vendedores de ERP argumentan que debe elegir su PLM ya que su ERP controla los datos comerciales, y es el sistema el que también tiene la población más grande de usuarios; usuarios que van a proporcionar una valiosa retroalimentación y arranque para el proceso de diseño.

Por otro lado, los vendedores de CAD, argumentarán que ellos controlan la geometría del diseño, las propiedades físicas, las herramientas de análisis y la nomenclatura. Argumentarán (y en lo personal, estoy de acuerdo con esto) que su provisión de enlaces sofisticados entre el sistema CAD y la base de datos de diseño es más importante que los datos de tipo ERP, que es básicamente texto.

El reto entonces es escoger entre ellos, y para tomar una decisión al estilo del rey Salomón los directores de tecnología de la información (IT) deben ser cautelosos.

Reto 3: matar al ganso de oro de la información

Creo que es interesante considerar que tanto CRM como PLM requieren un repositorio (base de datos) extra para toda esa información que se cree que se requiere y se necesita, pero que hasta ahora, dicha información no se ha recolectado.

Los dos sistemas recolectan nuevos datos descriptivos y de clasificación (llamados metadatos). Cuando CRM está en las primeras etapas de presentación inicial, los equipos de implementación pueden dejarse llevar, o sentirse presionados por la administración, y por cuánta información quieren extraer de la gente que maneja los procesos.

Lo mismo pasa con PLM El peligro es que a los ingenieros y en especial a los diseñadores les están dando demasiada administración, que puede ser, o por lo menos es como ellos lo ven, una pérdida de tiempo y de hecho reducir su productividad.

Además, si no compran dentro de los beneficios de los metadatos que el sistema PLM está diseñado a atrapar, pondrán un esfuerzo mínimo o incluso pondrán pura porquería en el sistema, haciéndolo aún más inútil. Esto sucede muy seguido en la transferencia de CRM, de hecho, los datos inservibles es uno de los mayores problemas con CRM. Y como puede ser engañoso, puede ser peor que no tener ningún dato. Con PLM es casi igual

Reto 4: Entender el verbo PLM y el sustantivo PLM

Los primeros adoptadores de CRM creían que con tan sólo comprar un producto CRM sería suficiente para responder a los retos de innovación y de cuidado del cliente, y que como resultado los haría más competitivos. De igual manera, las compañías están comprando PLM, con la esperanza que al hacerlo tendrán todo el conocimiento unificado para manejar los procesos que prometen estas soluciones. Sin embargo, los primeros adoptadores descubrieron que CRM es un acercamiento más comercial que tecnológico; que es un verbo en lugar de un sustantivo. Fue entonces que enfrentaron el mayor problema de todos: cambiar el proceso comercial y la cultura. Es decir, con el CRM los procesos que tienen que ver directo con el cliente deben ser impermeables y estar “más unidos”. Esa es la parte sencilla, lo que es más difícil es analizar los datos recolectados para poder interpretar lo que le están diciendo las acciones del cliente acerca de la dirección del producto o de las oportunidades de mejora.

Si usted ya tiene CRM, a continuación se presentan algunas preguntas abiertas que ilustran lo anterior: ¿El personal de ingeniería y del diseño del producto tiene acceso al sistema CRM y a los datos? ¿De verdad encuentra nuevas oportunidades comerciales a través de minar los datos por tendencia? ¿Está más capacitado el personal que trata directo con los clientes como resultado de utilizar el sistema? ¿Cree que sus clientes realmente saben lo que quieren de usted en un futuro?

Los primeros usuarios de CRM se dieron cuenta de que a pesar de que el sistema se podía instalar de manera muy sencilla, realizar el cambio organizacional y llevar a cabo CRM iba a ser más difícil e iba a costar mucho más de lo que se pensaba. Sin embargo, hay que reconocer que realmente existen los beneficios.

La similitud con la transferencia de PLM es obvia. Antes de que se puedan tener ganancias de la explotación de propiedad intelectual y reutilización del diseño, la organización tiene que pasar mucho tiempo completando la base de datos. El tiempo extra para hacer esto es de hecho un proceso que retrasa el proceso a corto plazo y la administración tiene que estar conciente de ello. Además existe un cambio organizacional enorme que se tiene que llevar a cabo, en donde los diseñadores tienen que ser más abiertos y tratar más con el cliente.

Reto 5: no pregunte si no quiere saber

Algo que se relaciona de cierta forma con lo anterior es, de hecho, el proceso de aprobación de diseños y de los avisos de los cambios de ingeniería (ECN) que puede ser algo enredado cuando PLM permite (algunas veces requiere) que más gente esté involucrada. Las decisiones que solían tomar solamente algunas personas de manera autónoma pueden y deben ser tratados por varias personas como la gente de soporte al cliente, de ingeniería, de fabricación, los clientes y los proveedores.

Sin embargo, una vez que se les motiva a contribuir con el diseño, hay que estar preparados para responder a su retroalimentación. Lo cual hace que sea difícil ignorarlos si no se está de acuerdo, y que sea difícil no tomarlos en cuenta cuando se requiere una decisión rápida.

Reto 6: la sobreposición en las aplicaciones

Existen sobreposiciones entre CRM y ERP, cuando se transfiere PLM, existen aún más sobreposiciones y como resultado hay que tomar más decisiones acerca de la funcionalidad.

Al principio del artículo se mencionaron algunos componentes clave de PLM entre ellos:

• Control de la emisión y revisión de datos
  
  
• Gestión de la base de datos del diseño y de los componentes de referencia cruzada
  
  
• Tecnología de colaboración como portales pare diseminar la información.
  
  
• Flujo de trabajo para manejar (principalmente) los avisos de los cambios de ingeniería
  
  
• Herramientas de entrada, salida e integración para ser capaces de comunicarse con los sistemas descendentes

Los primeros dos, el control de emisión y revisión y la gestión de la base de datos del diseño se tratan con el predecesor de PLM, la gestión de los datos del producto (PDM) (de hecho la mayoría de las soluciones PLM en el mercado son derivados de las antiguas herramientas PDM, o comercializadas por los autores). PDM tiene sentido, tiene un lugar definido en la arquitectura y su papel e interfase son claros.

El resto de los componentes en la lista no son tan sencillas de seccionar, como lo han visto las compañías con CRM. Tomando como ejemplo la colaboración, es casi seguro que el sistema ERP tenga su propio portal y herramientas de e-business, con lo cual se espera que les ayude a las organizaciones a simpatizar con sus clientes y asegurarlos. El sistema CRM tendrá colaboración en el área de ventas y soporte. Aunado a esto, un sistema PLM prospecto tendrá una colaboración centrada en el diseño.

En una firma de ingeniería, es muy difícil separar los asuntos comerciales de los de ingeniería, de hecho éste es el punto de una estrategia PLM. Así que ¿para qué tener soluciones separadas de colaboración, cada una con sus propias identificaciones (ID) de usuario, costos de mantenimiento e interfases de usuario? ¿Aceptarían sus clientes y proveedores todos estos sistemas? y ¿realmente serían útiles?

El flujo de trabajo tiene problemas similares. Cualquier sistema ERP bueno tendrá un sistema de flujo de trabajo para procesar, entre otros, cambios en la ingeniería, aprobaciones de compra y ampliaciones de fabricación. Por lo general las herramientas CRM tienen su propio sistema de flujo de trabajo que también cubren procesos de ventas y de soporte.

Una vez más PLM, como la tercera parte de la arquitectura empresarial, viene a “ensuciar el agua”. Al enfrentarse a diferentes sistemas de flujo de trabajo, uno se debe preguntar ¿qué sistema se debe utilizar para el cambio de ingeniería y la finalización del diseño? ¿Se debe forzar a los diseñadores a trabajar fuera del conjunto de herramientas normal para utilizar el flujo de trabajo de ERP? o ¿el resto de la población usuaria debe utilizar el flujo de trabajo de PLM para retroalimentar los problemas de diseño?

Cualquiera de las dos opciones es un riesgo. Por lo general el flujo de trabajo de ERP está orientado para manejar los datos ERP (y seguramente no está optimizado para manejar datos de diseño). Sin embargo, el flujo de trabajo PLM necesitaría el despliegue de demasiadas licencias y sistemas extraños para la mayoría de la población usuaria.

¿Existe alguna respuesta?

¿Existe alguna respuesta? Creo que sí. Primero, hay que reconocer las limitaciones de la tecnología. Mientras que se necesita un PDM para controlar las revisiones de los modelos CAD, etc., una PLM sólo sucede cuando los sistemas existentes están integradas para entregar procesos cohesivos. Las aplicaciones que prometen “darle” PLM se deben ver con cierto escepticismo.

Escoja bien al vendedor; cualquier vendedor potencial debe demostrar el entendimiento de CAD y ERP (si en algún momento el vendedor utiliza las palabras “PLM” y “listo para utilizarse” se dará cuenta de que no tiene ninguna experiencia que ofrecer).

Dadas las enormes superposiciones potenciales en la funcionalidad entre sistemas (la colaboración y el flujo de trabajo son muy buenos ejemplos), trate de evitar invertir de más en capacidades que ya tiene. En lugar de esto, piense qué es lo que le pide el proceso, haga un inventario de la capacidad que ya tiene con ERP y otras aplicaciones y luego vea como puede cubrir los faltantes.

¡Integración! ¡Integración! ¡Integración! Presione mucho en este problema. PLM se trata de integración (nunca es suficiente el énfasis al respecto). Además la integración no se debe diseñar en cuanto a un sistema en particular, sino que debe ser neutral (también conocido como un “sistema escasamente acoplado”). Presione a los vendedores en cómo deben de lograr la integración y en qué es lo que pasa cuando se cambian, ser reemplazan, o se mejoran las aplicaciones.

Por último, como con cualquier buen plan, sea pragmático.

Acerca del autor

David Smith GDBS BEng (Hons.) MIEE es asesor de in2grate, una compañía que se especializa en ayudar a los clientes a lograr PLM. in2grate tiene una vasta experiencia en implementaciones de 1,000 CAD, 300 ERP y 60 gestiones de almacén.

A Smith se le puede localizar al teléfono (1) (44) 1844-295-245 o al correo electrónico david.smith@in2grate.com.

Consulte http://www.in2grate.com y http://www.anisagroup.com .