• ¿Automatización personalizada o productos comerciales?, ¿o quizás ambos?

Default Alternative Text

Durante la última década, el negocio de integración de sistemas se ha visto empujado hacia un enfoque partidario de soluciones genéricas. Los clientes buscan hoy en día una solución única que sirva para todas las situaciones y que sea fácil: fácil de comprar, fácil de instalar y fácil de mantener. Los productos disponibles comercialmente han perpetuado la idea de una solución única para satisfacer todas las necesidades. Los productos comerciales aseguran poder satisfacer fácilmente en una sola compra todas las características requeridas por el cliente.

Por desgracia, eso no puede conseguirse solo con un planteamiento genérico o con productos comerciales. Excepto en los proyectos simples de integración de sistemas, este método a menudo no resulta viable y puede llevar a tomar malas decisiones en aras de la generalización. Por lo general, lo que lleva a tomar estas decisiones es no entender donde reside el éxito de un proyecto de integración de sistemas.

Como resultado de eso, la palabra “personalización” ha adquirido mala reputación en el sector. Muchos clientes huyen de cualquier cosa hecha a medida por varias razones, muchas de las cuales carecen de fundamento. Este artículo examina estas razones, trata de demostrar que todos los proyectos de integración de sistemas requieren de un cierto nivel de personalización, y que los productos y los esfuerzos personalizados son una opción necesaria para lograr el éxito.

¿Cómo hemos llegado hasta aquí?

Si observamos la historia reciente de la automatización industrial, la tendencia actual hacia lo genérico puede entenderse como una respuesta a condiciones de mercado ya pasadas. En los años 1980 y 1990, el mercado se llenó de softwares y hardwares propietarios que obligaron a los clientes a tomar ciertas decisiones sin más alternativa. Los clientes debían elegir una plataforma en particular y aferrarse a ella, porque no existía interoperabilidad entre competidores. Si la función que un cliente requería no estaba disponible en la línea de productos que había elegido, mala suerte. Y era demasiado caro cambiar a un producto de la competencia porque la infraestructura básica ya estaba instalada y no era compatible con una plataforma diferente.

Estas condiciones llevaron a una reacción de los clientes que cambió las estrategias de comercialización del sector. Los clientes requerían interoperabilidad entre productos de empresas competidoras. Los proveedores establecieron y adoptaron protocolos comunes y abiertos para potenciar ese esfuerzo. A finales de 1990, el desarrollo de OPC (vinculación e incrustación de objetos para el control de procesos) creó una opción relativamente económica para permitir la comunicación entre dos o más sistemas propietarios.

Los clientes podían ahora elegir el producto idóneo para un trabajo concreto y estar seguros de que el nuevo producto podría comunicarse con el resto de la infraestructura, así como con cualquier otra inversión anterior. Por desgracia, esta apertura condujo a efectos secundarios no deseados e imprevistos.

En primer lugar, los clientes podían elegir cualquier producto que satisficiera sus necesidades. Y así lo hicieron. Ahora bien, una instalación puede tener una docena o más de plataformas de productos que requieran soporte de diferentes herramientas. Esta situación imponía una gran carga sobre los departamentos de operaciones y mantenimiento. 

Los proyectos de integración de sistemas de mayor éxito utilizan tanto productos comerciales como enfoques personalizados para adaptarse mejor a las necesidades inmediatas de los clientes y a sus necesidades futuras.

En segundo lugar, los clientes podían escribir su propio software para comunicarse con cualquier producto de control de procesos. Y así lo hicieron. Empezaron a desarrollar software de forma interna o a comprar software de desarrolladores no cualificados que no podían recibir soporte o mantenimiento.

Alrededor de 2005, la balanza empezó a inclinarse hacia el otro lado. Muchos clientes corrigieron esos errores manteniéndose en una sola plataforma que pudiera ser mantenida por personal interno y comprando únicamente productos comerciales que funcionasen en esa plataforma. Y lo hicieron sin importarles si aquellos productos podían o no satisfacer las necesidades funcionales de las aplicaciones afectadas. Era más importante mantener una visión “genérica” de la sostenibilidad.

Conceptos erróneos en torno a la personalización

Estos avatares de la industria han llevado al planteamiento centrado en lo genérico que prima hoy en día. Sin embargo, no se ha entendido bien por qué “genérico” es diferente de “personalizado” o incluso qué significan ambos términos. A continuación, algunos conceptos erróneos sobre los productos comerciales y la personalización.

FALSO: “Comercial” significa “no personalizado”. Esta es probablemente una de las mayores falacias de la integración de sistemas. Muchos clientes creen que comprando un producto comercial ya no debe realizarse ningún trabajo de personalización. Esto rara vez es cierto, incluso en proyectos sencillos.

Ningún producto comercial funciona directamente al instalarlo sin ningún tipo de personalización. Los proveedores suelen utilizar la palabra “configurar” en lugar de “personalizar” para paliar el miedo asociado a la personalización. Sin embargo, una configuración no deja de ser una actividad de personalización realizada específicamente para un cliente. En casos sencillos, el trabajo de personalización puede incluir la modificación de algunos parámetros del producto. Para usos más complejos, habitualmente el proceso es mucho más elaborado. Puede implicar tener que escribir secuencias de comandos para el software de control de supervisión y adquisición de datos, desarrollar lógicas para un controlador lógico programable, o escribir componentes de comunicación personalizada para enlazar sistemas.

La personalización de los productos comerciales es, pues, claramente necesaria, basándose en las ofertas de los distribuidores. Casi todos los principales distribuidores de productos comerciales mantienen un grupo de integración de sistemas cuyo único propósito es personalizar el producto para satisfacer los requisitos de integración.

FALSO: “Comercial” significa estándar y con soporte. Casi todos los clientes podrán recordar algún caso en el que un empleado motivado haya generado un software “personalizado” que aportó un valor inmenso, pero que no se pudo mantener o actualizar sin el programador original. Eso produce un colapso operativo inevitable si el programador no está disponible o no se puede contactar con él para que dé asistencia al software.

El miedo a este tipo de situaciones a menudo lleva a los clientes a utilizar productos comerciales con la creencia de que el producto por si solo proporcionará estandarización y soporte. Desafortunadamente, esto no es verdad: los productos comerciales son altamente personalizables y pueden conducir al mismo problema que hemos descrito.

Un simple ejemplo de ello es Microsoft Word, uno de los productos comerciales más utilizados. Sin un usuario que introduzca la información, el programa no puede hacer nada. Para crear un documento de valor, debe haber un usuario que personalice los parámetros de salida. Los ejemplos 1 y 2 son el mismo texto.

Microsoft Word es uno de los productos comerciales más utilizados. Sin embargo, para crear un documento de valor, debe haber un usuario que personalice los parámetros de salida. Los ejemplos 1 y 2 son el mismo texto, y sin embargo difieren notablemente. El ejemplo 1 utiliza una plantilla estándar

El primer ejemplo muestra un formato estándar de documento. El segundo muestra un documento escrito sin estándares. ¿Qué parte de Word prohíbe a un usuario generar cualquiera de estos documentos? Absolutamente ninguna. Esto demuestra que un producto comercial como Microsoft Word no puede realmente ofrecer estandarización ni soporte.

RTEmagicC_ctl1309-f4-when2automate-SAIC-

De hecho, la estandarización y el soporte dependen mucho más de una función de procesos y procedimientos que del producto en el que se realiza el desarrollo. Lo que ofrece realmente estandarización y soporte es el uso de una plantilla estándar, una formación de guía específica para realizar documentos y un proceso de revisión, no el producto comercial en sí.

Una organización necesita contar con los procesos y procedimientos adecuados para dar soporte a cualquier intento de integración de sistemas. Y esto es aplicable tanto a aplicaciones de software desarrolladas a medida como a los productos comerciales.

FALSO: “Personalizado” significa “propietario”. La única expresión a la que los clientes temen más que “personalizado” es “propietario”. Y muchas veces se da por hecho que una cosa y otra están inextricablemente vinculadas. Puede que esto fuera así antes, porque la capacidad de proporcionar soluciones personalizadas mediante una comunicación abierta y estándar era difícil. Pero desde la adopción de protocolos abiertos y la OPC, es raro encontrar una solución a medida que se construya sobre una base propietaria.

La clave es asegurar que los productos no propietarios son los mismos para el software personalizado que para los productos comerciales. Y los clientes deben asegurarse de que esa sea una de sus necesidades, tanto a la hora de conseguir un desarrollo como de comprar un producto.

Los sistemas propietarios dan miedo principalmente porque un cliente puede quedar bloqueado en un producto específico sin posibilidad de cambiar a un producto de la competencia. En el pasado, esta restricción estaba relacionada con la tecnología. Hoy en día, los contratos tienen un papel crucial a la hora de restringir la capacidad de un cliente para cambiar sus plataformas o aumentar un sistema. En la mayoría de los casos, es más difícil entender estos aspectos en un producto comercial que en soluciones personalizadas. El cliente debe valorar sus contratos de concesión de licencias y soporte para asegurarse de que el uso de un producto comercial no prohíbe la extensión del sistema o plataforma.

El miedo puede llevar a tomar malas decisiones

Estas falacias pueden hacer que un cliente tome decisiones de negocio erróneas basándose solo en el miedo a lo personalizado, y que se deje seducir por las promesas de los productos comerciales. Los proyectos basados en productos comerciales fracasan por dos razones principales. En primer lugar, el cliente no entiende las limitaciones de los productos comerciales o bien está dispuesto a aceptar esas limitaciones para no salirse de la idea de las soluciones genéricas. Los clientes a menudo consideran el relativamente pequeño despliegue inicial como un éxito, pero luego les resulta difícil ampliar el sistema a otras áreas funcionales o instalaciones con necesidades diferentes.

Un integrador de sistemas debería evaluar las necesidades de la organización y proporcionar la mejor solución basándose en estos requisitos, no en los productos que vende.

En segundo lugar, el cliente no planifica adecuadamente el mantenimiento y el soporte que necesita el producto comercial. Una vez más, este problema no es fácilmente visible en el primer despliegue. Sin embargo, a medida que el sistema crece y es necesario modificar y gestionar la configuración de algunas partes personalizadas del producto comercial, los clientes empiezan a detectar problemas en el control y soporte de las versiones.

Aprovechar los productos comerciales y los personalizados

Los proyectos de integración de sistemas de mayor éxito utilizan tanto productos comerciales como enfoques personalizados para adaptarse mejor a las necesidades inmediatas de los clientes y a sus necesidades futuras. Para asegurar el éxito en la integración de sistemas, los clientes y sus asesores deben:

  • Entender que tanto los productos comerciales como los personalizados son opciones viables y necesarias. No limitar los proyectos de integración de sistemas a los productos comerciales sin entender las necesidades inmediatas y futuras de la organización. Asegurarse de reconocer cómo se va a personalizar un despliegue de productos comerciales para esas necesidades, así como los requisitos de soporte asociados a todas las facetas del producto. Si las necesidades son especiales, como lo son la mayoría, evaluar las ventajas de usar una solución personalizada.
  • Decidir qué debe ser genérico y, por otro lado, qué debe ser personalizable. Cada sistema debe tener un conjunto de características que todo el mundo entienda y un conjunto de expectativas que cada implementación debe cumplir. Definir ambas cosas por adelantado según los requerimientos del negocio. A continuación, decidir qué características pueden ser diferentes entre cada área funcional y cada instalación. Permitir que las características estándar sean compatibles con las características “personalizadas” que se necesitan en las diferentes áreas.
  • Encontrar un asesor técnico. Al buscar un integrador de sistemas para ayudar en la implementación y programación de la solución, hay que asegurarse de encontrar a un asesor técnico y no a un distribuidor del producto. Un integrador de sistemas debería evaluar las necesidades de la organización y proporcionar la mejor solución basándose en estos requisitos, no en los productos que vende.

Si ven la personalización como una opción viable en lugar de como una palabra temida, los clientes podrán tomar mejores decisiones respecto a la integración de sistemas. Entendiendo la personalización como una herramienta y como una parte necesaria de un proyecto, ya sea con productos comerciales u otros, el cliente puede sopesar los beneficios de combinar productos comerciales con soluciones personalizadas, en lugar de restringir su visión a una dicotomía entre ambas soluciones.

Conceptos destacados

  • A veces se descarta inmediatamente la personalización, cuando podría ser la mejor solución.
  • Simplemente porque un producto sea comercial no significa que se pueda utilizar sin necesidad de una configuración personalizada.
  • No hay que limitar los proyectos de integración de sistemas a los productos comerciales sin entender las necesidades inmediatas y futuras de la organización.

Cosas a tener en cuenta

  • Si se requiere algún tipo de personalización para obtener un 20 % más de producción durante el ciclo de vida de un sistema de automatización, ¿no valdría la pena realizar una inversión adicional?

El enfoque principal de Corey A. Stefanczak es ayudar a los clientes a unificar su infraestructura de automatización y sus sistemas de información dentro de grandes entornos distribuidos. Stefanczak aprovecha sus 16 años de experiencia en integración para ayudar a sus clientes a triunfar encontrando el equilibrio adecuado entre las soluciones comerciales y el desarrollo personalizado. Editado por Mark T. Hoske, gestor de contenidos de Ingeniería de Control e Ingeniería de Plantas, e ingeniero de asesoría específica de CFE Media

CTLx_LOGO_Color_ID
Powered by ContentStream®