Búsqueda


14 de abril de 2008

Integrar las herramientas

Como veíamos en el artículo anterior de esta serie, hay una serie de condiciones que pueden justificar la unificación de herramientas:

  • Actividades externalizadas "autocontenidas"
  • Equipos de trabajo monocliente
  • Posición de fuerza de negociación con los proveedores

Pero hay muchos casos en los que no se dan las condiciones necesarias como para poder unificar las herramientas: los proveedores de servicios utilizan las economías de escala para reducir sus costes y obtener los beneficios que justifican estas líneas de negocio, y eso en el sector servicios se consigue garantizando la ocupación del 100% de la carga de trabajo en actividades que reporten beneficios a la compañía.

Esta situación nos lleva directamente a que, para hacer rentable un equipo de trabajo, el outsourcer tiene principalmente dos opciones:

  • Conseguir un contrato que le permita facturar el 100% de la ocupación del personal al mismo cliente (lo que nos lleva a la situación de equipos monocliente)
  • Conseguir múltiples contratos con diferentes clientes y ocupar al equipo en actividades multicliente.

Esta segunda opción es la que nos encontraremos en la gran mayoría de situaciones, donde un grupo de trabajo (operadores, administradores, desarrolladores, etc) dedica su actividad a diferentes clientes, aprovechando de esta manera "los tiempos muertos" y permitiendo hacer una aproximación al mercado de menor coste (por cliente) pero de mayor beneficio (global).

Así, rompemos la premisa que nos permite unificar herramientas y vemos que la aproximación de integración de herramientas comienza a cobrar fuerza, pero es una vía llena de obstáculos y dificultades.

Para poder llevar con éxito un proceso de integración de este estilo, es recomendable seguir una aproximación más o menos metodológica al proyecto:

  1. Definir lo más detalladamente posible los resultados esperados de la integración.
  2. Diseñar / Modificar el modelo de procesos (integrados) para asegurar que pueda producir el conjunto de resultados esperados.
  3. Construir el meta-modelo de datos, sabiendo qué datos deben fluir, cuándo y con qué mapeos de información.
  4. Escoger la herramienta que nos permitirá hacer todo esto.
  5. Implementar una maqueta / piloto que nos permita refinar todo lo diseñado en los pasos anteriores
  6. Implementar la integración
  7. Diseñar / Modificar los procedimientos operativos, para asegurar que permiten generar los resultados esperados y que se adaptan a los nuevos requerimientos generados por el proceso de integración.
  8. Paso a Producción
  9. Matenimiento in-eternum de la integración

Si llegas con éxito al punto 8, las cosas habrán cambiado de una forma drástica en la forma de trabajar. A partir de ese momento, ocurre que la integración comienza a desvelar toda una serie de situaciones que antes no se notaban: las <n> compañías ahora están atadas por un vínculo que no tiene sentido común ni creatividad y que "canta" los errores que se producen.

quantum-marker-art-bgAsí, cualquier variación en los datos que están incluidos en el meta-modelo significa que se debe adaptar la integración (por ejemplo, una modificación en las categorías de la organización 1 implica que se debe decidir a nivel de integración qué queremos hacer con esa categoría en la organización 2); otro ejemplo es que algunos de los cambios que se produzcan en las operativas de cualquiera de estas organizaciones puede afectar seriamente a la integración (ya que tenemos definido en qué momento se traspasa la información, sea por el mecanismo que sea).

En este momento, es muy fácil que la integración se vea como un obstáculo a la evolución de todas las organizaciones participantes del sistema: pero en realidad lo que ocurre es que antes de la integración cada entidad iba por libre, con intercambios de información nulos o mínimos, en un conjunto de sistemas independientes que evolucionaban cada uno como quería y, desde el momento en que los hemos unido con una cuerda, los sistemas ya no son independientes y deben "tenerse en cuenta" unos a otros.

Por lo tanto, hay un par de factores que son especialmente sensibles y que deben ser analizados con cuidado antes de lanzarse a una aventura como esta:

  1. ¿Vale la pena? Es decir, los beneficios que vamos a obtener una vez analizado el punto (1) de nuestra aproximación metodológica son superiores al esfuerzo y costes que vamos a incurrir? Quizás no es únicamente una cuestión de coste/beneficio sino de necesidad / ley /cumplimiento.
  2. ¿Tengo un circuito de cambios maduro, que me garantice que no vamos a romper la integración continuamente por modificaciones no controladas?
  3. Para garantizar la agilidad, ¿la herramienta escogida me acompaña?

Por último, y como consejo aprendido en las trincheras, a polvo, sudor y hierro (como el Cid): KISS Hazlo simple, no compliques en exceso el nivel de detalle con el que quieres intercambiar información porque en el extremo de esa complicación está el modelo de herramientas unificadas. Todo en su justa medida.

No hay comentarios: