domingo, 11 de mayo de 2014

Aspectos estratégicos y operativos que deben ser considerados en el proceso de cambio hacia el software libre (III)


Punto de llegada


El conjunto de los diferentes escenarios de migración nos aportará la fotografía buscada. El estado del arte puede representarse, por tanto, en un puzle donde cada escenario de migración representa una pieza. Cada pieza requerirá acciones específicas para llevar a cabo la migración que se contemplarán en el Plan De Acción (Migración).

En la práctica, los escenarios de migración estarán relacionados luego su compartimentación resultará compleja. No obstante, este ejercicio es fundamental para poder acometer un proceso a gran escala en un espacio de tiempo finito. Este es un requerimiento importante a la hora de trabajar con proveedores externos, expertos en la materia.

Dicho de otro modo, aproximaciones a los procesos de migración basados únicamente en aspectos operativos o funcionales arruinarán el proceso. Migrar “por departamento” o “por servicio (de IT)” es el reflejo de una incorrecta ejecución de esta fase del proceso de migración.

Esta fase del proyecto los entregables deben incluir:
  • La definición de las diferentes personas/perfiles (canónicos) y qué usuarios/unidades corresponden a cada uno de ellos.
  • Individualización de los perfiles correspondientes a cada usuario. Recordar que los perfiles son abstracciones.
  • El estudio de las diferentes interacciones entre personas que afectan al proceso de migración.
  • Los escenarios de migración.

Mi recomendación es que se realicen varios entregable. Con el fin de motivar a los diferentes perfiles de usuario, es conveniente elaborar diferentes documentos, orientados a audiencias diferentes como:
  • Responsables tecnológicos.
  • Responsables técnicos.
  • Usuarios (power users/prescriptores y usuarios de a pie)

Se debe acompañar el entregable de los resultados parciales de las diferentes acciones realizadas así como de la información complementaria utilizada, como por ejemplo:
  • Inventario de hardware y sistemas/servicios
  • Resultados de las entrevistas.
  • Información aportada por la propia AA.PP.
  • Referencias externas utilizadas.
  • Informe ejecutivo.
  • Informe de costes.
  • Otros

Este documento servirá de base para acciones que pueden tener lugar e un amplio periodo de tiempo. Es necesario incluir toda la información con el fin de que sea accesible en un futuro por nuevos proveedores y trabajadores.

Conclusiones


La definición del Estado del Arte es una acción del propio proceso de migración, que toma como referencia datos correspondientes a un estudio habitual de inventariado así como de procesos de negocio, servicio y calidad. Pero no se trata de un proceso aséptico. Posee un propósito específico: servir como base del diseño del Plan de Migración.

Esta etapa del proceso de migración es un ejercicio down-top-down donde:
  1. Se analiza la información disponible.
  2. Se recojen datos relevantes.
  3. Se analiza la información disponible y esos datos en conjunto con el fin de definir perfiles.
  4. Se definen los perfiles/personas y se particularizan a cada participante.
  5. Se estudian sus interacciones.
  6. Se redefininen las personas.
  7. Se introduce como input información adicional
  8. Se definen los escenarios.
  9. Se elaboran los entregables que sirven de base al diseño del Plan de Migración en sí.

Un Plan de Migración eficaz requiere de una correcta definición del Estado del Arte. Del mismo modo, un compromiso por parte de los participantes en el proceso require que se les haga partícipes también en este punto del proceso, independientemente de que la ejecución la realicen proveedores externos o miembros de la casa.

Fin del guión 

Este es el tercero de una serie de tres post. Accede a los dos anteriores aquí:

viernes, 9 de mayo de 2014

Aspectos estratégicos y operativos que deben ser considerados en el proceso de cambio hacia el software libre (II)


Punto de partida


El punto de partida de cualquier proceso de análisis previo a una migración tiene como principales fuentes de conocimiento:
  1. Los objetivos y motivaciones de los responsables político/tecnológicos de la AA.PP.
  2. La documentación existente sobre procedimientos, herramientas, infraestructura, recursos, descripción y relación con proveedores, perfiles, servicios que se prestan, tanto internos como externos...
  3. La "realidad" de
    1. Los responsables técnicos de la AA.PP.
    2. Los "power users" o prescriptores.
    3. El usuario no técnico.
    4. El servicio que se presta.
  4. Experiencias previas en transformaciones tecnológicas si la hubiere.

La disponibilidad de una documentación veraz y actualizada constituye un factor determinante en cualquier proceso de migración. No sólo facilita la definición del Estado del Arte, ahorrando costes y acelerando el proceso en sí, sino que establece un punto de referencia sobre el que basar cualquier análisis objetivo posterior. Por tanto, representa el principal punto de apoyo del cliente (la AA.PP.) frente al proveedor de servicio, al menos en este punto.

Así pues, el principal esfuerzo de los técnicos y responsables tecnológicos de la propia AA.PP. en este punto inicial debe ser:
  • Actualizar y, si es posible, ampliar la información existente sobre los sistemas de información y su uso por parte de trabajadores públicos y cuidadanos.
  • Recopilar información relacionada con procesos de transformación tecnológica experimentados con anterioridad.
  • Recopilar información sobre la relación de la AA.PP. con proveedores de servicios que puedan ser afectados por la migración de manera directa o indirecta.
  • Recopilar información orientada a facilitar el proceso de toma de datos.

Si la documentación disponible no es completa o se encuentra desactualizada, mi recomendación es que se separe la generación/actualización de esta información del propio proceso de identificación del Estado del Arte. Deben ser fases diferentes del proyecto o incluso proyectos diferentes. Uno alimenta el otro.

Proceso a seguir para el establecimiento del Estado del Arte


La fotografía a tomar tendrá como referencia el concepto de perfiles/personas. Definir esos perfiles debe ser el primer objetivo de esta fase del proyecto. Una vez descritos, se particularizarán para cada usuario. A partir de esos perfiles y teniendo en cuenta información adicional relevante, se establecerán los diferentes escenarios de migración.

Así pues, el Estado del Arte se define en base a escenarios de migración.

Para definir los perfiles/personas, es necesario entender qué inputs son necesarios. En general son los siguientes:
  • Puesto/servicio que presta (procesos)
  • Conocimientos técnicos
  • Interacción con aplicaciones y servicios
  • Equipamiento que utiliza
  • Datos

Para cada usuario, debe obtenerse información correspondiente a cada una de estas áreas. La información obtenida necesita ser procesada para que sea manejable. Tras un proceso de abstracción (análisis), se podrán definir las personas/perfiles significativos.

Esta abstracción/generalización nos permitirá escalar el diseño del proceso de migración e ir adelantando algunas otras fases del proyecto, como la identificación de herramientas libres candidatas, planes de comunicación o formación...

Con el fin de definir los escenarios de migración, es importante definir primero las interacciones intra/inter personas/perfiles. Es decir, cómo interactúan a través de los sistemas de información.

Este estudio debe llevarnos a un proceso de ajuste o redefinición de los perfiles/personas (personas canónicas). Una vez hemos los hemos definido de manera definitiva, debemos individualizarlos, es decir, asegurarnos de que ajustamos los perfiles a cada uno de los participantes en el proceso (humanización de los perfiles).

Tomando en consideración datos adicionales como la infraestructura disponible, los servicios que se prestan, la estructura organizativa de la propia AA.PP., aspectos logísticos etc., se definirán los escenarios de migración. Idealmente, cada escenario de migración deber estar definido como una unidad independiente desde el punto de vista del proceso de migración.

Los escenarios de migración, por tanto, están basados en:
  • La obtención de los diferentes perfiles/personas.
  • El estudio de las interacciones entre los diferentes perfiles/personas.
  • Recursos (sistemas de información).
  • Servicios que se prestan en el momento previo a la migración.
  • Prioridades estratégicas y operativas.
     
    Este post es el segundo de una serie de tres. Puedes acceder a los demás aquí:

jueves, 8 de mayo de 2014

Aspectos estratégicos y operativos que deben ser considerados en el proceso de cambio hacia el software libre (I)


Actualización de los Sistemas Informáticos utilizando Software Libre.

Aspectos estratégicos y operativos que deben ser considerados en el proceso de cambio hacia el software libre


El presente documento es un resumen de mi intervención en el mencionado curso, como parte del segundo bloque del mismo. Dicha intervención introduce el tema a tratar, de modo que aporto una visión global, reforzada con ejemplos concretos de los conceptos más importantes. Dichos ejemplos y anécdotas de interés, no figuran en este resumen.

Datos sobre el curso:
  • Director del curso: Ramón Ramón Sánchez (Perfil Linkedin)
  • Fecha de mi intervención: 23 de Abril de 2014
  • Contenido: Bloque 2.- Definición del Estado del Arte. Evaluación previa.
  • Duración: 90 min. aprox.
  • Audiencia: técnicos y responsables tecnológicos de AA.PP. del Gobierno de Costa Rica.

Introducción y enfoque


Todo proceso de migración comienza con una misión. Esta misión debe estar claramente reflejada en el proyecto estratégico. Basándonos en esa misión, se establecen los objetivos principales de la migración. Siempre existe un objetivo prioritario y otros secundarios.

Los objetivos estratégicos más comunes son:
  • Independencia tecnológica
  • Ahorro de costes:
    • A corto plazo
    • A medio y largo plazo
  • Creación de polo tecnológico local
  • Aumento de rendimiento/eficiencia
  • Mejora de la interoperabilidad
  • Política

Cualquier proceso de migración tecnológica ideal consiste en definir una el cuadro/fotografía actual de los sistemas de información, así como de su uso, y replicarla, usando, no sólo herramientas diferentes, sino en este caso, un paradigma diferente. Sin embargo, el proceso de transición es costoso. Debemos asumir que cada uno de los participantes, require de un fuerte grado de motivación para adoptar una posición constructiva frente al proceso. La motivación, en forma de mejoras/beneficios futuros, debe generalizarse en la medida de lo posible, no restringiéndose al ámbito técnico y/o económico directo y a corto plazo.

El Software Libre propone beneficios suficientes como para generar esa motivación en diversos ámbitos. Así, la definición del Estado del Arte, la captura de esa fotografía, no es ni debe ser objetiva:
  1. Debe responder al objetivo principal del proyecto.
  2. Debe identificar las fortalezas del actual entorno y usarlos como base de la del resultado obtenido.
  3. Debe identificar posibles mejoras que permitan diseñar y desarrollar acciones orientadas a potenciar esa motivación.

Una correcta definición del estado del arte se convierte así en un ejercicio cruel de identificación de una realidad que, no por supuesta, puede resultar menos desalentadora en muchos casos. Además, el proceso de migración no permite rectificaciones basadas en el antiguo modelo. Peor aún, propone una travesía del desierto para alcanzar un oasis de herramientas, protocolos, principios... que no dominan.

Es por tanto necesario establecer contramedidas que permitan a esos profesionales afectados digerir y asumir esa fotografía con el convencimiento de que, tras el proceso, estarán en mejor disposición de mejorarla.

La mejor forma de que esta fotografía sirva de estímulo es hecerles copartícipes de su realización, animándoles a aportar sus experiencias y visión. Debe ser también su fotografía. Asimismo, recomiendo comunicar claramente que el fin de la acción que no es evaluar el grado de eficiencia o eficacia del trabajador en el desempeño de sus tareas. Un proceso de migración no es una evaluación de rendimiento.

Dichas experiencias deben ser procesadas y documentadas con el fin de introducirlas en la base común de conocimiento, favoreciendo un aprendizaje colectivo a partir de ellas. Muchas de las experiencias que afectan o permiten entender la fotografía obtenida, no tienen que ver de manera directa con aspectos tecnológicos, luego existe el riesgo de que tengan impacto en el proceso de migración.

Los sistemas/servicios informáticos en Administraciones Públicas suelen tener un menor grado de control que en otros entornos. Tampoco es posible entender la fotografía resultante sin asumir que ella es producto de una evolución que, a menudo, los profesionales involucrados no han podido controlar totalmente por razones:
  • Técnicas: los sistemas no permiten de un modo simple la realización o control de determinadas prácticas.
  • De conocimiento: Los profesionales responsables de las infraestructuras tecnológicas o los usuarios no conocen en detalle las herramientas que utilizan (son privativas).
  • De mercado: existen limitaciones impuestas por los fabricantes, integradores o implantadores a los sistemas tecnológicos utilizados.
  • Necesidades de producción.
  • Limitaciones dependientes del propio entorno laboral: existen limitaciones en la capacidad de decisión y/o ejecución de aquellos llamados a diseñar e implementar los sistemas tecnológicos dentro de una AA.PP.
  • Otras razones.

Así, el Estado del Arte debe recoger no sólo la situación previa a la migración sino también aspectos clave que expliquen la evalución que ha tenido como producto semejante resultado.

El Software Libre empodera a responsables tecnológicos y usuarios. Les confiere mayor flexibilidad, es decir, mayor control, luego requiere un mayor grado de responsabilidad. El riesgo de aumentar la entropía tras la migración es significativo. Debe diseñarse y ejecutarse cada paso, incluyendo la fase de análisis, teniendo en cuenta que en un futuro es mejor, en general, aportar mayores grados de libertad a los participantes de manera gradualgradual que restrinjirlos.

La fotografía obtenida debe aportar claves que permitan decidir qué tipo de medidas de control pueden aplicarse con las nuevas herramientas (y procesos), cuyo impacto sea positivo (o neutro) en la productividad de los usuarios, en comparación con las existentes.

El entregable de esta fase del proceso de migración, debe apuntar con claridad los puntos fuertes de la situación previa a la migración, con el fin de reforzarlos o, al menos, mantenerlos. Un proceso de migración exitoso está basado en las fortalezas del modelo anterior, no en sus deficiencias.

Mitigar las deficiencias debe ser, en general, el foco de procesos de mejora post migración. Disponer de una mejor base para ello debe ser el resultado de una correcta migración. La fotografía y posterior evaluación deben establecer la base sobre la que sea posible definir el proceso de migración y, al mismo tiempo, apuntar algunas de las futuras acciones de mejora que se podrán acometer con las nuevas herramientas y procedimientos, basados ahora en Software Libre.

Pero insisto, el objetivo de la migración no es ni debe ser realizar mejoras. Eso debe proponerse como objetivo fundamental tras la migración. De otra manera, desviaremos el foco de atención de lo realmente importante, basar el resultado en las fortalezas actuales.

En resumen:
  1. El Estado del Arte, obtenido como resultado del trabajo de análisis previo a la definición del Plan de Acción, tiene un fin concreto. No es objetivo.
  2. El análisis puede y debe tener impacto en responsables técnicos y usuarios. Debe asegurarse que ese impacto es positivo.
  3. De un modo similar, el Estado del Arte debe describir los grados de libertad con los que cuentan en la actualidad técnicos y usuarios en el uso de la información, aplicaciones y servicios. El objetivo es que el Plan de Acción los tenga en cuenta.
  4. La fotografía punto de partida del proceso de migración, debe apuntar claramente las fortalezas del modelo actual (en uso) con el fin de asegurar que el proceso de migración se basa principalmente en ellos.

    Lee las otras dos partes:

viernes, 25 de octubre de 2013

Abierto el plazo para la presentación de candidaturas para la celebración de la openSUSE Conference 2015.

La comunidad openSUSE celebra cada año un evento en el que los principales contribuidores participan en charlas y talleres junto a interesados y profesionales. Al tratarse de una distribución, la lista de temas que se tocan es muy amplia, desde administración de sistemas hasta aplicaciones web, pasando por empaquetado, marketing, hardware, traducción y, por supuesto, sistemas operativos.

La edición 2013 ha sido la primera celebrada lejos de ciudades donde SUSE tiene oficina. Su organización corrió a cargo de la comunidad salvo en aspectos legales y económicos fundamentalmente. La openSUSE Conference 2013 tuvo lugar en Tesalónica, Grecia, en verano, y participaron unas 300 personas.

La edición 2014 se celebrará en Dubrovnik, Croacia  en Abril. Ya se está preparando la organización del evento. Desde hace unas semanas, se ha abierto el plazo para la presentación de candidaturas a la celebración de openSUSE Conference 2015.

El evento cuenta con el apoyo de SUSE como principal espónsor. Esto da una garantía importante a la hora de poder organizarlo porque algunos de los gastos básicos de este evento de comunidad están cubiertos de antemano. La comunidad openSUSE asume algunas de las tareas más tediosas de la organización de modo que los organizadores locales no tienen que ocuparse de ellos. Los contenidos y el trabajo relacionado con sponsors también viene dado por la comunidad.

Dicho de otro modo, entre SUSE y la comunidad openSUSE asumen una parte del trabajo lo que garantiza que la organización del evento sea asumible para un reducido número de voluntarios locales. Depende del país y lugar de celebración, SUSE dispone de soporte local lo que facilita la difusión del evento, entre otras tareas.

En definitiva, si tienes experiencia en la organización de eventos de Software Libre, échale un vistazo a openSUSE Conference y presenta tu candidatura.




martes, 2 de octubre de 2012

Experiencias de venir a trabajar a SUSE

Como muchos ya saben, me he venido a trabajar a SUSE. Como ya escribí en mi blog en inglés, lo he hecho en un buen momento, dada la situación de la empresa. Muchas veces lo difícil no es ir a una empresa concreta, sino caer en un área interesante y en un momento para la empresa adecuado. Tu futuro laboral depende mucho de ello.

SUSE, tras la adquisición de Novell por parte de The Attachment Group se ha convertido en una unidad de negocio independiente, lo que está teniendo un impacto muy importante en la empresa a todos los niveles. Una de las consecuencias es que está creciendo. A día de hoy hay un par de decenas de vacantes en una empresa de 700 personas. El crecimiento, lejos de menguar, se espera que continúe.

Esta es una empresa de Software Libre con 20 años de vida. Sí, 20 años vendiendo y desarrollando FLOSS adaptándose a diferentes modelos de negocio y contribuyendo upstream de manera decidida. Con un proyecto estrella en este área, openSUSE, con infinidad de contribuciones relevantes a diversas tecnologías y productos punteros para grandes clientes.

Yo trabajo en Nuremeberg, donde se encuentra el grueso del área de desarrollo de productos, dentro del departamento de I+D. Mi equipo se denomina openSUSE Team. Aglutina a todas las personas que trabajan a tiempo completo en el proyecto openSUSE.

SUSE dispone de una buena mezcla entre ambiente hacker y orientado a cliente. Aquí hay muchos desarrolladores de primera línea trabajando para proyectos clave, desde kernal a drivers, pasando por virtualización, LibreOffice, etc. Mucho personal senior que lleva muchos años en la empresa trabajando con Software Libre. Se da la circunstancia de que algunos de los programas libres que uso son desarrollados por trabajadores de SUSE. Siempre impacta conocer al desarrollador de tus aplicaciones. Al menos a mi me ocurre. Es algo que no suele pasar usando software privativo.

Emigrar no es una decisión fácil para la mayoría. Yo reconozco que, gracias a experiencias pasadas a edad temprana, le perdí el respeto (como dicen en mi tierra) a salir de mi zona de confort y moverme. Respeto mucho, no obstante, a quienes se quedan, sobre todo en estos momentos, a luchar en condiciones igualmente difíciles. La verdad que no me siento un emigrante. Salir de España fue una decisión meditada y largamente deseada. No ha sido porque no me gustara aquello, sino porque quería vivir algo diferente.

Para mi, el proceso de adaptación va muy bien. Me ayudan bastante en la empresa. Además, cuento con la suerte de disponer de amigos en esta ciudad, tanto españoles, sobre todo venidos de empresas de desarrollo de software para hardware de Málaga, como alemanes (les conocí a través de proyectos de comunidad). Todo es más fácil cuando tienes quien te ayude, especialmente al principio.

Tras cuatro meses aquí, he comenzado mis clases de alemán. Dependiendo de la empresa en la que trabajes, hablar alemán es irrelevante o ayuda bastante. SUSE se encuentra en la primera categoría. De todas formas, quiero intentarlo. Veremos cómo me va.

En cuanto al trabajo, ya creo estar bastante aclimatado a la empresa. Con la comunidad openSUSE es otra historia. Lleva tiempo tomarle el pulso a un grupo tan numeroso y heterogéneo de personas. Espero poder acelerar mucho ese proceso de adaptación y conocimiento en la openSUSE Conference, que estamos coordinando desde mi equipo.

...suficuente por hoy.