Conectores Exitosos: Mejores Prácticas y Estrategias de Implementación

La mejor práctica con los conectores siempre es forzar un enfoque basado en reglas y abordar cualquier excepción como una consecuencia o agotamiento basado en reglas en lugar de comenzar con un enfoque basado en excepciones.

El enfoque basado en excepciones es tentador y atractivo porque valora la elección humana y la preservación de la estructura actual del proceso. Pero traza un vector hacia un lugar que no ofrecerá buenas alternativas para escalar y mantener procesos saludables a largo plazo. En ese sentido, comenzar pensando en las excepciones en lugar de las reglas es un error que evitamos a toda costa.

Ganancia a corto plazo para dolor a largo plazo en pocas palabras. La mayoría de las organizaciones con las que trabajamos comparten esto en común: buscan preservar los procesos actuales. Cuando se busca tecnología, se pretende abrazar el proceso actual en lugar de ubicar un punto intermedio entre las limitaciones del proceso y la eficiencia.

Nuestros conectores son una forma de enlazar el flujo de contenido desde un repositorio hacia BWX y luego de regreso. Si bien entendemos la necesidad ocasional de seleccionar archivos o cualquier otro elemento para un trabajo basado en conectores, la mejor práctica para los conectores es seguir un enfoque basado en reglas en lugar de uno manual.

‍Se explica la tentación del enfoque manual

‍Los enfoques manuales son tentadores porque no requieren ningún cambio en el proceso. Las personas pueden explorar el archivo exacto que desean traducir y comenzar un proyecto de traducción utilizando el conector. El problema con el enfoque manual es que no es escalable, sostenible y predecible (difícil de mejorar).

Es por eso que exploramos el enfoque manual solo después de haber agotado todas las posibilidades de ajustar el comportamiento del conector al comportamiento basado en reglas. Es necesario lidiar con excepciones, pero no se puede diseñar por excepción.

Un producto exitoso y su respectiva implementación se basan en reglas que cubren el mayor porcentaje posible de casos de uso. Los casos de uso que quedan sin cubrir deben ser evaluados cuidadosamente para explorar soluciones y alternativas con el fin de incorporarlos dentro de los paradigmas propuestos.

Aquí hay un ejemplo: el cliente A tiene un conector que funciona según un horario, pero ocasionalmente tienen proyectos que requieren una ejecución fuera de horario. Aquí hay algunas opciones diferentes sobre cómo abordar esto:

1. Solicitar manualmente una ejecución fuera de horario a nuestro equipo de soporte
2. Utilice nuestra CLI para solicitar una ejecución fuera de horario
3. Crear una sucursal/directorio fuera de ciclo que se consulte con más frecuencia que el horario típico para recoger trabajos urgentes.

Aquí hay otro ejemplo: el cliente B se utiliza para seleccionar archivos y comenzar el proceso de localización. En lugar de perpetuar el enfoque manual, la mayoría de los procesos de selección siguen un comportamiento que se puede revertir ingeniería inversa.

Siempre vale la pena esforzarse al máximo en este ingenio en reversa. Si comienzas con un enfoque manual o te centras en cubrir las excepciones de manera correcta desde el principio a través de la interfaz de usuario, eso se convertirá en una muleta debilitante en lugar de un acelerador del programa. Cuando pensamos en un conector, siempre pensamos en la automatización.

Esa es la verdadera eficiencia del proceso impulsada por un conector. Exportar e importar proyectos es una pequeña ganancia cuando se trata de conectores. La verdadera ganancia gira en torno a las reglas de negocio y la previsibilidad y gobernanza que generan.

El problema es que si diseñamos e implementamos por excepción, la automatización nunca se convierte realmente en una opción. La automatización, por definición, requiere algún grado de cambio de proceso y si no presionamos por esta adaptación entre proceso y software, no lograremos superar las expectativas y nos convertiremos en vendedores de la digitalización del caos.

Esto no es lo que buscamos y no lo aceptaremos. Los conectores a pequeña escala deben seguir los mismos diseños y principios que los conectores a gran escala para que puedan escalar y crecer eficientemente. La mayoría de los programas de localización solicitan soluciones basadas en casos de uso actuales (que en realidad son del pasado) en lugar de casos de uso orientados hacia el futuro que proyecten más archivos, más cadencia, más ubicaciones, menos tiempo de comercialización, menos costos y más personas trabajando juntas.

Si no te embarcas en el curso correcto desde el principio, la corrección posterior será costosa y muy desafiante porque perderás la ventana de cambio introducida por una nueva implementación. Todos nuestros conectores, grandes o pequeños, se basan en reglas y parámetros.

Están gobernados por los mismos principios de diseño y ninguno de ellos requiere una interfaz de usuario para funcionar correctamente. La interfaz de usuario puede ser un complemento interesante para un conector maduro, pero principalmente para cambiar fácilmente las configuraciones del conector en lugar de iniciar proyectos manualmente.

No podemos promover el éxito a largo plazo si somos cómplices de la aceleración de los procesos analógicos existentes.  

En cambio, nuestro objetivo es traducir los procesos analógicos en pensamiento digital para que se vuelvan verdaderamente compatibles con el software, permitiendo la automatización orientada a los datos. Estamos acostumbrados a gestionar conectores que procesan miles de archivos al día en casi cien ubicaciones diferentes.

A lo largo de los años, hemos aprendido que los mismos ingredientes que hacen que un conector a gran escala sea exitoso deben ser respetados también para los conectores a pequeña escala, para adherirse a los principios básicos de diseño de escalabilidad y sostenibilidad.