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

P { margin-bottom: 0.08in; }H2 { margin-bottom: 0.08in; }H2.western { font-family: “Arial”,sans-serif; font-size: 14pt; font-style: italic; }H2.cjk { font-family: “WenQuanYi Micro Hei”; font-size: 14pt; font-style: italic; }H2.ctl { font-family: “Lohit Hindi”; font-size: 14pt; font-style: italic; }

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í:

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

P { margin-bottom: 0.08in; }H2 { margin-bottom: 0.08in; }H2.western { font-family: “Arial”,sans-serif; font-size: 14pt; font-style: italic; }H2.cjk { font-family: “WenQuanYi Micro Hei”; font-size: 14pt; font-style: italic; }H2.ctl { font-family: “Lohit Hindi”; font-size: 14pt; font-style: italic; }

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í:

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

P { margin-bottom: 0.08in; }H1 { margin-bottom: 0.08in; }H1.western { font-family: “Arial”,sans-serif; font-size: 16pt; }H1.cjk { font-family: “WenQuanYi Micro Hei”; font-size: 16pt; }H1.ctl { font-family: “Lohit Hindi”; font-size: 16pt; }H2 { margin-bottom: 0.08in; }H2.western { font-family: “Arial”,sans-serif; font-size: 14pt; font-style: italic; }H2.cjk { font-family: “WenQuanYi Micro Hei”; font-size: 14pt; font-style: italic; }H2.ctl { font-family: “Lohit Hindi”; font-size: 14pt; font-style: italic; }

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 presentedocumentoes 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 desiertopara 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:

La importancia de disponer de un adecuado inventario de hardware

(este post no es original. Fue publicado aquí mismo el 19/09/08- Lo publico de nuevo con fines técnicos)

A lo largo de las últimas semanas he estado (y sigo) involucrado, junto a varios técnicos, en la consecución de inventarios de hardware de las máquinas que se pretende migrar a software libre. La mayor parte de las Administraciones Públicas y empresas (éstas en menor medida) en las que he trabajado, tanto en Canarias, como ahora en Andalucía y Extremadura no disponen de un inventario exhaustivo. Hay dos motivos básicos por los que es un punto crítico a la hora de migrar a software libre:

  • Es necesario conocer el hardware con detalle para saber qué módulos deben incluirse en la distribución linux a implantar.
  • Es necesario predecir el rendimiento que de la máquina con el nuevo software.

Asimismo, es necesario conocer con mucho detalle los periféricos que utilizan los usuarios. A menudo son tan importantes como el propio equipo. Conocer qué drivers deben estar disponibles en la nueva versión es relevante.

Las actualizaciones de sistema operativo que se desarrollaban en el pasado con sistemas de Microsoft (cambios de plataforma diría yo en algunos casos) implicaban por lo general cambios de equipos. En pocos casos, añadir memoria solía resolver el problema de falta de rendimiento salvo en los casos (como ahora el Vista) en los que los drivers para el nuevo sistema no existe.

Se me ocurre esta realidad como causa principal para una carencia tan flagrante. Quienes nos movemos en el mundo del software libre siempre tenemos el hardware en mente porque, hasta hace poco, era un punto que requería toda nuestra atención. Aunque cada vez estamos más relajados en este sentido, ocasionalmente nos encontramos con casos no resueltos o difícilmente resolubles. Para nosotros el inventario es un requerimiento natural. No ha sido así durante muchos años con los sistemas de Microsoft. Los fabricantes se ocupaban de esto por nosotros. Los responsables técnicos de la mayor parte de las administraciones hace mucho que no se enfrentan de un modo global a esta necesidad.

Los costes de realizar inventarios son altos porque la mayor parte de las soluciones requieren instalación. Además, esa instalación debe realizarse en la plataforma a extinguir, por tanto, se puede añadir a la ecuación un coste de licencia no esperado. La mano de obra a invertir en esta tarea no es despreciable que digamos. Si la administración en cuestión dispone de varias sedes o su red no está en buenas condiciones, el problema se acentúa.

Con el fin de abaratar costes, servidor y la gente con la que trabajo estuvimos varios días desarrollando y probando un sistema para realizar inventarios. Lo denominamos Inventory Libre y estamos poniéndolo en producción en varios ayuntamientos de La Axarquía de Málaga y en la Junta de Extremadura con notable éxito. Lo liberaremos en breve. No es una solución redonda ni elegante, entre otras cosas, porque nada relacionado con hardware lo es. Pero sí que es tremendamente eficaz para inventarios a gran escala.

En cualquier caso, la mejor solución sigue siendo conservar las características técnicas de los dispositivos tras la adquisición, actualizar los datos, etiquetar equipos y periféricos y mantener toda la información en un soporte digital fácilmente manejable.

Si está pensando en migrar a software libre o a Vista, no sería descabellado comenzar a desarrollar estas tareas con el fin de facilitar ese cambio y, de paso, ahorrar unos euros si puede realizarse con personal propio. Si no es así, debe incluirse el inventario entre las tareas que forman parte del proyecto de migración, con su correspondiente coste económico y necesidades de recursos. Otro día trataré de hablar del inventario de software.

Estandarización de procesos de migración

Los procesos de migración pueden abordarse de diferentes maneras en función de diferentes parámetros. Las grandes empresas, en especial IBM, han diseñado procedimientos y herramientas orientados a procesos de migración basados en perfiles de usuario relacionados con las actividades que desarrollan con su equipo. Estos perfiles, por tanto, vienen determinados por las aplicaciones instaladas en el pc.

Este enfoque es perfectamente válido pero genera una fotografía del proceso de migración incompleta. Existen otros factores que deben ser considerados a la hora de establecer procesos de migración que son igualmente relevantes. Algunos de ellos son:

  • Parque de hardware
  • Red
  • Servicios de red LAN y WAN disponibles
  • Nivel de conocimientos de los usuarios
  • Actividad de la empresa u organismo
  • Relación entre usuarios a nivel de información y procedimientos
  • Demandas futuras de servicio
  • Personal técnico a disponible
  • Presupuesto en materia tecnológica

Cada uno de estos factores afecta de manera más o menos relevante, según el caso, a los perfiles de usuario basados únicamente en las aplicaciones que usa el usuario y su pericia que se establezcan. Más aún, pueden llegar a alterarlos tanto que es necesario establecer nuevos perfiles en base a ellos. Por otro lado, al migración está asociada tanto al propio usuario como a la máquina, la información y los servicios, por tanto, del mismo modo que establecemos perfiles para aquellos, debemos hacer lo propio con éstos.

Este razonamiento desemboca en una idea nada nueva en otros campos pero sí en este: el establecimiento de escenarios de migración compuesto por intersecciones de perfiles basados en diferentes parámetros.

Un escenario está determinado por un conjunto de perfiles que definen una realidad presente y un conjunto de actuaciones futuras resultantes de la intersección de los diferentes perfiles obtenidos del análisis de los distintos factores antes mencionados. Esta metodología Up-Down es alcanzada tras un análisis Down-Up de la situación en cada uno de los apartados descritos. Del análisis de la situación previa a la migración de cada parámetro, deben ser determinados los perfiles de migración asociados a cada concepto. Posteriormente debe adherirse cada una de las máquinas, servicios, información y usuarios a cada perfil para, en función de sus intersecciones, establecer escenarios que sirvan de punto de partida para la ejecución de la migración. Lógicamente, cada escenario está sujeto a pequeñas personalizaciones imposibles de evitar, pero que nunca deben ser tan drásticas como para desnaturalizar el modelo. Si es así, es probable que existan errores en el análisis, en la captación de datos o en la definición de los datos que deben ser objeto de estudio (el peor de los casos).

Este proceso resulta particularmente largo y costoso. El análisis de datos, el establecimiento de perfiles, el análisis de los mismos y la consecuente determinación de escenarios para cada proyecto de migración genera unos costes en tiempo y recursos que hacen inviable en muchos casos la posterior ejecución del proceso, o peor aún, invitan a comenzar ese proceso de ejecución sin disponer de la fotografía previa necesaria, poniendo en serio riesgo todo el proceso.

La sistematización de buena parte de las tareas es un elemento fundamental para que empresas, profesionales y organismos públicos puedan abordar con costes asumibles estos procesos tremendamente complejos. Si queremos que el software libre se generalice, debemos abordar con energía la necesidad de disponer de procedimientos estandarizados de análisis y actuación en procesos de migración.

Hasta ahora, son muchos los intentos publicados de realizar procesos de migración, pero pocos los que han entendido esta necesidad de sistematización. La gran mayoría de aquellos a los que he tenido acceso están completamente influenciados desde el inicio por las particularidades de la empresa o administración migrante. Es normal. Son las grandes compañías o Administraciones responsables de otras Administraciones las que pueden visualizar este problema y aportar soluciones a gran escala.

Una vez descubierta la necesidad y establecido el modelo, aparecen las siguientes preguntas:

  • ¿Qué perfiles deben ser determinados?
  • ¿Qué datos hacen falta para el establecimiento de los diferentes perfiles?
  • ¿Qué metodología debe seguirse para su captación?
  • ¿Que variables debemos analizar para alcanzar perfiles fiables?¿Qué es un perfil fiable?
  • Una vez analizados los datos, ¿cómo establecemos esos perfiles?
  • ¿Cómo determinar si los perfiles se ajustan a la realidad?
  • Una vez determinados los perfiles, ¿cómo determinamos los escenarios?
  • ¿Cómo saber si los escenarios se ajustan a la realidad y, más importante aún, a las necesidades?
  • ¿Cómo abordar la ejecución una vez determinados los escenarios?
  • ¿Cómo tratar e introducir las particularidades en el modelo?
  • ¿Cómo analizar su impacto?

Estas y otras preguntas están sin respuesta o disponemos sólo de algunos casos parciales que nos llevan a intuir posibles soluciones. Sobre este tema existe mucha literatura pero poca demostración empírica. Es un apartado relativamente nuevo, a pesar del tiempo que lleva el software libre en el mercado. No hay consenso y buena parte del que existe está basado en la intuición más que en la praxis.

En la actualidad me encuentro inmerso en la demostración práctica de las primeras preguntas planteadas, relacionadas con la determinación de los datos que deben ser captados, la metodología y herramientas de captación de los mismos, la determinación de la metodología y herramientas de análisis y el diseño de diferentes perfiles que desemboquen en una fotografía teórica de escenarios de migración aplicables a grandes corporaciones. Más adelante llegará la ejecución de esos escenarios y, por tanto, la validación (o no) de buena parte del trabajo realizado. Será, en todo caso, un primer intento de sistematización, lleno de errores y fallos de diseño. No obstante, espero que sea un punto de partida válido para posteriores trabajos propios y ajenos. El reto es difícil pero atractivo: La estandarización de procesos de migración

Lo principal, no obstante, es determinar que existe esta necesidad de sistematización. Si es así, deben ser varios los intentos, metodologías y herramientas a establecer antes de alcanzar un modelo válido. Bajo mi punto de vista, una de las razones últimas que justifican la necesidad de sistematizar estos procesos, es la necesidad de evaluarlos. Sin sistematización no existe evaluación objetiva.

Este modelo, además, debe ser útil, no sólo para migraciones de plataformas propietarias como Microsoft a GNU/Linux, debe ser válida para cambios de cualquier plataforma. Esto requiere que sea, en buena medida, independiente de la tecnología a implantar. Debe cimentarse, no obstante, en los estándares abiertos y el software libre. Sin embargo, si queremos que sea realmente útil, debe ser ajeno a nombres y apellidos. En la actualidad, este es uno de los principales elementos que frenan los procesos de migración. Pondré un ejemplo. Muchos de los informes y experiencias que he leído basan los perfiles en las funcionalidades que ofrecía OpenOffice o Firefox en el momento de su redacción. Hoy son absolutamente obsoletos. Además, está por ver que el cambio de Office a OpenOffice sea la mejor opción en todos los casos. Este es otro punto de debate muy interesante. Tal vez en otro post….