SlideShare una empresa de Scribd logo
La migración a software libre: el puesto de
trabajo sostenible (I)
Por JJ Velasco | 5 de julio de 2011, 19:32




Ahora que el soporte de Windows XP está, prácticamente, muerto, muchas empresas se están
planteando la migración de los equipos de sus puestos de trabajo a Windows 7. Pasar desde Windows
XP a Windows 7 podría ser la evolución natural y, quizás, la más lógica; sin embargo, existe un
modelo alternativo que las empresas deberían plantearse: el software libre. En estos tiempos de
crisis y de búsqueda de la eficiencia en el gasto, la adopción de software libre en el puesto de trabajo
puede suponer, a medio plazo, un importante ahorro de costes y, sobre todo, una gran paso hacia la
independencia tecnológica.
Migrar los puestos de trabajo hacia un sistema operativo basado en GNU/Linux no es una decisión a
tomar a la ligera, bajo mi punto de vista, necesita de cierta preparación y, sobre todo, el tratamiento de
un proyecto interno al que hay que dedicar recursos.
A través de varios posts vamos a ir analizando qué pasos deberíamos dar si queremos plantearnos la
migración a software libre de los puestos de trabajo de una organización.
Para empezar, es fundamental el compromiso de la Dirección de la compañía, sin el respaldo de la
Dirección la oposición al cambio puede ser mucho mayor y, en casos extremos, dar al traste con todo el
proyecto. Un proyecto de este calibre no es, únicamente, la adopción de una solución tecnológica que
nos va a hacer ganar dinero, también nos va a redundar en un aumento de la seguridad de nuestros
puestos de trabajo y, sobre todo, es un cambio de filosofía de la empresa, que apuesta por un modelo
sostenible e independiente tecnológicamente. Por tanto, ante tanto cambio que debemos gestionar, no
nos viene mal analizar el proceso y plantearnos algunas fases con las que llevar a cabo este proyecto.

1. Contexto económico
Aunque los que conocemos el mundo del software libre pensemos que es una gran opción, quizás
nuestros jefes no tengan esta misma visión y, posiblemente, se hayan acostumbrado al uso de Windows,
por ejemplo, y por comodidad no quieran cambiar. Esto es algo que puede pasar y será la primera
batalla que tengamos que librar si queremos arrancar este tipo de proyecto.
¿Y cómo convencer a nuestros jefes? Cambiar la filosofía de trabajo de una compañía no es fácil, al fin
y al cabo, forma parte de la propia cultura de la empresa y cualquier cambio cultural debe gestionarse
adecuadamente. Teniendo en cuenta la coyuntura económica, un modelo basado en costes podría ser
un interesante punto de partida para justificar la necesidad de la migración.
Hay que tener en cuenta que el uso de software con licencia responde a un modelo cíclico, es decir,
adquirimos una licencia, la usamos y, una vez amortizada, pasamos a adquirir licencias de la siguiente
versión (en el caso de licencias que no tengan caducidad) o, por el contrario, vamos renovando con la
periodicidad que sea las licencias adquiridas. Este modelo cíclico afectará, prácticamente, a todas las
licencias que hayamos adquirido (Sistema operativo, Microsoft Office, Antivirus, etc), simplemente
variará el período de duración de la licencia (en el caso que caduquen) o el tiempo que reste para su
amortización. Además, a este modelo cíclico de adquisición de activos (las licencias) hay que sumar
otros costes, los costes de operación, es decir, los costes en los que incurrimos para solventar las
incidencias de nuestros usuarios, instalar software en los equipos, etc.
Bajo un entorno basado en software libre, este modelo de costes se simplifica mucho, en algunos
casos se puede llegar a reducir únicamente a los costes de operación (en un entorno ideal) pero,
básicamente, los costes relacionados con licencias de ofimática y alguna que otra aplicación
desaparecen, por tanto, se eliminan esos desembolsos cíclicos debido a la obsolescencia o caducidad de
las licencias de software adquiridas.
¿Y cómo plantear esto? Lo más sencillo es plantear los costes en los que incurrimos durante cinco años,
una ventana de tiempo a medio plazo y que puede ser significativa como para evaluar los gastos en los
que incurrimos adquiriendo licencias (o equipos que ya las tienen instaladas) y renovándolas.

2. Contexto temporal
Tras estudiar lo que nos gastamos en adquisiciones, debemos estudiar cuándo es el mejor momento
para realizar la migración. Hoy en día, el cierre del soporte de Windows XP puede ser un muy buen
motivo para migrar, sin embargo, el factor tiempo es muy significativo (desde el punto de vista
económico) y, por tanto, elegir una fecha sin estudiar el contexto nos podría hacer que incurriésemos en
pérdidas.
En algunas metodologías consideran que si hay convencimiento por parte de la empresa por migrar,
debería ser suficiente. Yo creo que es necesario pero no es el único factor a tener en cuenta, sobre todo,
si queremos dar unas cifras cercanas a la realidad. Cualquier aplicación que compremos tiene una vida
útil (un año, cuatro, etc) y, por tanto, si decidimos migrar sin agotar dicha vida útil, no habremos
amortizado por completo esa inversión (que se estará malgastando).
Con esto quiero decir que si acabamos de adquirir licencias de Microsoft Office para toda la empresa,
quizás haya que comparar cuánto nos va a costar migrar a Windows 7, compararlo con los costes de la
migración a software libre y si la diferencia resulta mayor al coste de las licencias de Microsoft Office,
podremos contrarrestar las pérdidas pero si nos resultan iguales o menores, entonces quizás no sea el
mejor momento para migrar.
El momento ideal es aquel en el que hemos agotado la vida útil de nuestras licencias, una situación
ideal que rara vez ocurre, puesto que no todas se han comprado a la vez, ni tampoco tienen la misma
vida útil. Por tanto, tendremos que seleccionar aquella fecha que minimice nuestras pérdidas
(entendidas como licencias que no hemos amortizado).

3. Reajustando el modelo de costes
Tras realizar el análisis temporal parece claro que tenemos que volver a nuestro modelo económico y
reajustarlo, añadiendo las pérdidas que hemos detectado (por licencias no amortizadas). También será
el momento de añadir otros costes asociados a la migración que tendremos que tener cuenta y que,
posteriormente, iremos desarrollando:
    • Consultoría: en el caso de la migración a software libre, vamos a plantear un cambio en el
      modelo de gestión de la compañía, además de un cambio tecnológico. Por tanto, ya sea con
      recursos propios o externos, vamos a tener que dedicar cierto tiempo (y recursos) a realizar una
      consultoría para sentar las bases técnicas y metodológicas para llevar a cabo el proceso de
      migración de los puestos de trabajo.
    • Migración: lógicamente, el proceso de migración tiene un coste asociado. Son recursos que,
      tanto en un entorno en software libre como en uno propietario, son necesarios para migrar los
      datos de los usuarios, actualizar o cambiar el sistema operativo, restaurar datos, aplicaciones,
      etc.
    • Formación a usuarios: si optamos por el cambio, no debemos abandonar a nuestros usuarios a
      su suerte, es decir, necesitarán que les guiemos por el nuevo entorno y ponérselo algo fácil. La
      profundidad de esta formación dependerá del grado de madurez de nuestra organización, sus
      conocimientos sobre el entorno y su grado de resistencia al cambio.
    • Soporte: nuestro equipo de soporte también necesita actualizarse, tanto en conocimientos como
      en herramientas. Quizás sea buen momento para analizar las herramientas que utilizan, buscar
      alternativas y, sobre todo, mejorar los procedimientos de actuación.
• Islas residuales: es posible que la consultoría nos arroje, dentro de sus conclusiones, que en
      nuestra organización tengamos algunos puestos que no puedan ser migrados a software libre o
      bien tengamos que buscar alguna solución que posibilite el uso de una solución propietaria bajo
      un escritorio libre. Tendremos que convivir con estas “islas residuales” y tratarlas de manera
      especial.
Una vez analizados estos aspectos, con sus correspondientes valoraciones económicas, habremos
completado nuestro modelo económico que, previsiblemente, arroje que migrar a software libre sea
más caro que migrar a Windows 7, pero claro, ese es el dato a corto plazo pero que, al eliminar de la
ecuación gran parte de los desembolsos económicos en renovación de licencias, comenzará a ser
rentable a medio plazo (a partir del segundo o tercer año) y, desde ahí en adelante, todo serán
beneficios.
En el siguiente post veremos cómo llevar a cabo el proceso, una vez que tengamos luz verde por
parte de la Dirección de nuestra compañía.



La migración a software libre: el puesto de
trabajo sostenible (II)
Por JJ Velasco | 8 de julio de 2011, 14:27




En el post anterior estuvimos analizando la idoneidad de migrar los puestos de trabajo a software libre,
tanto desde un punto de vista cualitativo como desde un contexto económico. En esta ocasión nos toca
profundizar en el proceso de migración en sí, es decir, en la transformación de un entorno corporativo
con puestos de trabajo basados en soluciones propietarias a un entorno que funciona, casi en su
totalidad, con herramientas basadas en software libre.

4. Estudiar a la organización y entender sus procesos y su funcionamiento
Tras las hojas de cálculo y los estudios de costes nos toca entrar, por fin, en contacto con el usuario e
intentar entender cómo trabajan, qué aplicaciones suelen utilizar y, en definitiva, entender cuáles
son sus necesidades actuales y a medio plazo. Lo recomendable es articular esta fase en torno a una
ronda de entrevistas (con los responsables de cada equipo y con sus miembros) para conocer qué
herramientas utilizan, qué necesidades tienen y qué función cumplen en la organización.
Para comprender el funcionamiento de una organización es importante observar cómo trabaja, es
decir, sentarnos con cada uno de los trabajadores, ver cómo se manejan en su entorno de escritorio, qué
usan y para qué. De esa forma podremos ir viendo qué alternativas tendremos que buscar (para
satisfacer las necesidades de los usuarios y la organización) y qué cosas, irremediablemente, tendremos
que mantener porque no existe solución técnica en software libre que cubra la mayor parte de
necesidades.

5. Aportando soluciones
Tras estudiar a nuestra organización llega el momento de plantear las soluciones que vamos a adoptar.
Abrir la tapa del “gran arcón” del software libre y ponernos a coger lo primero que veamos, está claro
que no es el camino a seguir. Es recomendable realizar esta prospectiva tecnológica en paralelo al
estudio de la organización porque así iremos adelantando trabajo e iremos buscando posibles
soluciones conforme vayamos capturando los requisitos y necesidades de nuestros usuarios.
¿Y qué soluciones tendremos que buscar? Existen muchas soluciones empresariales basadas en
software libre con los que poder dar soporte a la mayor parte de procesos empresariales: gestores
documentales, compartir ficheros, gestión de agenda; sin embargo, esta migración se centra en el
escritorio y, como tal, también tendremos que buscar soluciones en este entorno. Básicamente nos
referimos a cambiar Outlook por Thunderbird, Microsoft Office por LibreOffice, OneNote por Tomboy
o Evernote (si queremos usar la nube, aunque esto no sea libre), Microsoft Project por alguna
herramienta colaborativa online u OpenProj, Dia en vez de Microsoft Visio, etc.




Sin embargo, es muy posible que existan aplicaciones que no tengan equivalente en Linux y para las
que tengamos que pensar en alguna solución de compromiso (ya sea montando un servidor Windows al
que se conecten en remoto los usuarios y ejecuten ahí las aplicaciones o bien usando Wine o máquinas
virtuales).
6. La migración
El proceso de migración es el punto más crítico del proceso, puesto que debe ser lo más transparente
posible al usuario y, además, debe impactar lo mínimo posible en la productividad de éste (tiempo en el
que no podrá usar su equipo). Para llevarlo a cabo deberíamos haber diseñado un plan que abarque los
siguientes aspectos:
    • Maqueta a utilizar, es decir, partir de una distribución Linux, personalizarla (configuración,
      aplicaciones, etc) y, a partir de ahí, sacar un máster (o más, dependiendo del número de
      configuraciones distintas que necesitemos) que será el que instalaremos en los equipos de los
      usuarios.
    • Plan de intervención que establecerá un calendario con las actuaciones a acometer y las
      actuaciones previas necesarias antes de migrar (backups).
    • Plan de contingencia o dicho de otra forma, cómo volver atrás si algo sale mal o si surge
      alguna emergencia o imprevisto.
Antes de arrancar el proceso, sería conveniente comunicar lo que vamos a hacer a los usuarios o, al
menos, a sus responsables para que la información fluya y nadie se sienta excluido (y pueda oponer
algo más de resistencia al cambio).

7. Gestionar los cambios
La expresión “gestión del cambio” se usa mucho en cualquier proceso de cambio de modelo de gestión.
Esta disciplina se ocupa de minimizar el impacto que pueden provocar los cambios en procesos ya
arraigados (y cambiar el entorno de trabajo es un salto que debe gestionarse adecuadamente). Dicen los
expertos que cuando el usuario se siente partícipe del cambio, es mucho más fácil que lo entienda e,
incluso, se alinee con ellos, colaborando de forma activa y no entorpeciendo el proceso.
¿Y cómo hacer al usuario partícipe del cambio? Básicamente con dos líneas de actuación: la
comunicación y la formación.
Una comunicación fluida a los usuarios que les informe de los pasos que se dan, un proceso que cuente
con sus opiniones, un equipo les pregunte y, en definitiva, converse con ellos, es un buen caballo de
batalla que nos puede allanar mucho el camino a recorrer. El desconocimiento y, por tanto, el miedo al
cambio son las barreras a vencer y si somos muy opacos durante este proceso, el usuario se resistirá al
cambio y, en casos extremos, puede llegar a boicotearlo.
Por otro lado, dependiendo del nivel de conocimientos que tenga la organización, necesitaremos
organizar diversas acciones formativas que ayuden al usuario a adaptarse al nuevo entorno de
funcionamiento, a usar las nuevas aplicaciones y, en definitiva, enseñarles dónde están las herramientas
con las que podrán desempeñar sus funciones habituales.
8. Análisis del proceso
Tras finalizar el proceso de migración, nos encontramos ante un punto de inflexión en la manera de
gestionar el parque informático de nuestra compañía. Además de analizar los errores o fallos que nos
hemos ido encontrando, es el momento de volcar todo el conocimiento adquirido en algún gestor que
permita a todo nuestro equipo de soporte compartir lo aprendido (y lo que llegará), de manera que
todos los implicados vayan creciendo y adquiriendo más experiencia en el soporte al usuario.

Conclusiones
Un proyecto de este tipo, además de ser una apuesta por una tecnología sostenible y, lógicamente,
libre, es todo un reto tecnológico que necesita su tiempo para ser llevado a cabo correctamente. Es
una apuesta y como tal, debe contar con el compromiso de la dirección, sin ese apoyo, mejor no
embarcarse porque nadie se sentirá identificado con la migración y puede que no nos encontremos
muchos apoyos.
Gestionar la comunicación y hacer partícipe al usuario es una de las claves para que este proyecto sea
un éxito, además de nuestra pericia en la realización de la prospectiva (para buscar aplicaciones) y en
nuestro análisis de requisitos.
Para todo aquel que quiera profundizar más en el tema, el CENATIC (Centro Nacional de Referencia
de Aplicación de las TIC basadas en fuentes abiertas) trabaja en un modelo de migración para grandes
organizaciones que, aunque está en desarrollo, ofrece algunas interesantes herramientas con las que dar
soporte a este proceso.



La migración a software libre: el puesto de
trabajo sostenible (III)
Por JJ Velasco | 1 de agosto de 2011, 14:28
Hace aproximadamente un mes, estuvimos analizando en un par de notas cómo podría llevarse a cabo
la migración de los puestos de trabajo de una empresa a escritorios basados totalmente en software
libre. Primero estuvimos estudiando el contexto económico y temporal, es decir, una justificación
económica que sustentase la decisión de migrar y, posteriormente, la pautas que podríamos seguir para
poner en práctica el proyecto de migración. Lo ideal sería que pudiésemos migrar toda nuestra
empresa, bueno, si así lo deseamos y, además, los datos económicos lo apoyan; sin embargo, no en
todos los casos sería posible hacerlo y, posiblemente, tengamos que vivir en entornos mixtos.
Otro escenario posible, y tampoco sería muy descabellado, podría ser un entorno en el que se decide
aplicar una transición mucho más suave, es decir, ir eliminando aplicaciones propietarias
paulatinamente y, una vez se han eliminado en gran parte, proceder a la migración del sistema
operativo hacia alguna distribución Linux con entorno de escritorio. Esta opción, sobre todo en
entornos que tienen algunas dudas, puede ser la más interesante puesto que no supone un cambio
radical y, desde el primer momento, se puede palpar el ahorro y estudiar la evolución y adaptación de
los empleados a las nuevas herramientas.
Abordar un proceso de migración suave, lógicamente, supone que el plazo de realización aumente y,
además, se tengan que definir más puntos de control. En estos casos, al igual que en la migración total,
también tenemos que dedicar un tiempo a estudiar el funcionamiento de nuestra organización, entender
los procesos y conocer las aplicaciones que los soportan. Para conocer cómo funciona nuestra empresa,
además de observar a nuestros compañeros de trabajo, avanzaremos mucho si nos sentamos con ellos y
les preguntamos por cómo trabajan en su día a día. Muchas veces, la gente que trabaja en el área de IT,
tenemos una imagen preconcebida de lo que hacen nuestros compañeros y, seguramente, se nos pasen
algunos detalles que, aunque no les demos importancia, para ellos son importantes. Una ronda de
entrevistas, además de la observación, es lo mejor para abordar esta fase.
Teniendo en cuenta que vamos a aplicar un proceso gradual, en la fase de prospectiva tecnológica
tendremos que buscar aplicaciones que sustituyan al software propietario (al menos todo el que se
pueda) pero con dos condicionantes: deben existir tanto en Linux como en Windows o, al menos,
deben ser aplicaciones web. Quizás esté acotando demasiado el campo de búsqueda pero, por
experiencia personal, creo que es mejor huir de la emulación en Wine porque, a veces, no funciona todo
lo bien que quisiésemos y el usuario se termina enfadando. Es muy importante que el usuario vea
cubiertas todas sus necesidades o, al menos, la gran mayoría de ellas porque, teniendo en cuenta que
seguimos en un entorno Windows, en caso de no cumplirlas podrían pedir volver al estado anterior.
Lógicamente, en esta migración suave, el compromiso de la Dirección es importante y, en época de
crisis, ahorrar es importante; sin embargo, si el personal no está contento y, aunque sea exagerado,
atisban cierto riesgo de bajada de la productividad, podrían cancelar esta transición.
Por tanto, si recordamos los pasos que fuimos comentando en los dos artículos pasados, el proceso de
migración no partirá de la elaboración de una maqueta, sino que instalaremos aplicaciones libres
que sustituyan a las propietarias, migraremos los datos e iremos desinstalando el software privativo.
Este proceso será iterativo y gradual, es decir, lo recomendable es ir cambiando aplicaciones poco a
poco (conforme se vayan amortizando las licencias) y apoyar el cambio mediante la formación
necesaria a los usuarios.
Llegará un momento en el que, tras la última iteración, hayamos migrado todas las aplicaciones de
nuestros usuarios a soluciones totalmente libres. ¿Qué haremos entonces? Lo ideal sería sustituir el
sistema operativo propietario y apostar por uno libre y, por tanto, elaborar una maqueta con todas las
aplicaciones que hemos ido instalando. Pero, si por el motivo que fuese no pudiésemos dar este último
gran paso, al menos estaríamos ahorrando un importante capital gracias al uso de aplicaciones libres y,
desde luego, será algo que se note en los costes operacionales de la compañía.
C


La migración a software libre: el puesto de
trabajo sostenible (IV)
by sobajar on Aug 06, 2011




Para finalizar esta serie sobre las migración de los puestos de trabajo de una empresa a software libre,
vamos a hacer una reflexión que nos ayude a afrontar este tipo de proyectos y, sobre todo, nos aporte
una serie de ideas con las que poder argumentar la necesidad de aplicar este tipo de cambios a una
organización. Después de revisar cómo hacer un modelo económico, cómo planificar el proceso de
migración total o plantearnos una transición gradual, es el momento de revisar algunos motivos por
los cuales una migración a software libre podría beneficiar a nuestra empresa.

¿Por qué migrar?
Bueno, esa esta es la pregunta clave porque algún motivo debemos dar para iniciar este cambio en
nuestra empresa. Para empezar, a medio plazo, vamos a obtener un importante ahorro económico en el
coste de licencias (aplicaciones y sistema operativo), eso sí, es un ahorro a medio plazo puesto que el
proceso de migración conllevará esfuerzos (internos o externos) y, por tanto, tendrá asociado un coste
(aunque no será cíclico).
Por otro lado, podemos obtener un importante ahorro en hardware puesto que, dado que los requisitos
son algo menores, podremos ampliar la vida útil de nuestros ordenadores y, por tanto, alargar su
amortización. No tener que renovar el parque informático de la empresa con tanta asiduidad y que,
simplemente, con aumentar la memoria RAM podamos alargar su vida en un par de años, es un motivo
de bastante peso.
Además, gracias al acceso al código fuente, podemos tanto auditar el código de las aplicaciones,
mejorarlas y personalizarlas, adaptándolas a las necesidades de nuestro negocio. De hecho, muchas de
estas personalizaciones se ponen a disposición de la comunidad, haciendo que todos los usuarios se
vean beneficiados.
Desde el punto de vista de la gestión, la utilización de soluciones abiertas garantiza nuestra
independencia tecnológica (puesto que no estamos sujetos a una solución de un fabricante concreto) y
nos abre el horizonte a que nos puedan prestar servicios múltiples empresas. Pero quizás, una de las
garantías más importantes que nos brinda este modelo es el de la interoperabilidad que, gracias a que
el software libre se fundamenta en estándares abiertos, nos garantiza con otros sistemas o componentes.
La interoperabilidad es muy importante, tanto en el ámbito privado como en el público (por ejemplo, en
España hay una norma que lo regula en el ámbito de las Administraciones Públicas)

¿Qué problemas nos vamos a encontrar?
La principal barrera que nos vamos a encontrar es el cambio de mentalidad necesario para
abordar este proyecto con éxito. Decíamos en la segunda entrega de esta serie que había que gestionar
adecuadamente el cambio organizacional y, para ello, tendremos que formar adecuadamente a nuestros
empleados (en las nuevas aplicaciones y en el nuevo entorno, si también cambiamos el sistema
operativo) y, además, desmitificar algunos de los prejuicios que hay alrededor del mundo del software
libre.




La resistencia al cambio es algo intrínseco al ser humano, si alguien está acostumbrado a trabajar de
una manera determinada y, además, le va medianamente bien, no va a querer cambiar, menos aún, si el
cambio viene obligado. El primer mito a derribar es el de la complejidad, es decir, la creencia de que
las aplicaciones libres son complicadas, algo que no tiene por qué ser así sino que, simplemente, hay
que aprender a manejarse en un entorno nuevo (lo cual no implica mayor complejidad).
Otro mito a derribar es el de la falta de soporte y asistencia técnica, algo que no es cierto y que,
además, gracias a la adopción del software libre en algunas Administraciones Públicas, ha posibilitado
la creación de un tejido empresarial potente.
Dependiendo de la especialización de nuestros empleados y de nuestra empresa, quizás nos
encontremos ante aplicaciones que no van a poder ser migradas. Estas situaciones habrán de ser
tratadas con especial cuidado porque, mal llevadas, podrían suponer la cancelación de la migración y la
pérdida de confianza en este modelo. Bien llevadas, simplemente, nos llevarán, en el peor de los casos,
a mantener pequeñas islas con software privativo.
Conclusiones
Después de estos cuatro artículos dedicados a la migración al software libre, creo que podemos sacar
algunas conclusiones que nos pueden ser útiles a la hora de enfrentarnos a este tipo de proyectos:
    • Beneficios económicos, a medio plazo y largo plazo gracias al ahorro en licencias puesto que,
      en un corto plazo, el hecho de realizar la migración nos hará incurrir en un coste (consultoría,
      migración, etc) que podría equipararse a la renovación de licencias.
    • Es un proyecto que requiere una correcta planificación y gestión del proceso, en el que
      debemos valorar, correctamente, todos los factores que influyen en él: procesos de la empresa,
      aplicaciones que se utilizan, conocimientos del personal, formación necesaria, etc.
    • Este tipo de proyectos, al suponer un cambio importante en la cultura de la organización,
      necesita el apoyo firme y decidido de la Dirección. Si no confían en este proceso, al mínimo
      escollo, podrían cancelarlo. La resistencia al cambio que podemos encontrar va a ser fuerte, por
      tanto, los empleados necesitan ver que la Dirección apoya y promueve este cambio.

Más contenido relacionado

La actualidad más candente

Nuevos entornos de trabajo corporativo
Nuevos entornos de trabajo corporativoNuevos entornos de trabajo corporativo
Nuevos entornos de trabajo corporativo
IVREO
 
Introducción al proyecto
Introducción al proyectoIntroducción al proyecto
Introducción al proyecto
Pablo Macon
 
Dsdm_f
Dsdm_fDsdm_f
Trabajo gestor de proyectos
Trabajo gestor de proyectosTrabajo gestor de proyectos
Trabajo gestor de proyectos
longojose
 
Metodos agiles 3
Metodos agiles 3Metodos agiles 3
Metodos agiles 3
Diego Hernández Maya
 
Public3
Public3Public3
Elmanifiestoylosprincipiosgiles 131007145716-phpapp01
Elmanifiestoylosprincipiosgiles 131007145716-phpapp01Elmanifiestoylosprincipiosgiles 131007145716-phpapp01
Elmanifiestoylosprincipiosgiles 131007145716-phpapp01
esgar1989
 
Metodologías ágiles, Scrum, Kanban y eXtreme Programming
Metodologías ágiles, Scrum, Kanban y eXtreme ProgrammingMetodologías ágiles, Scrum, Kanban y eXtreme Programming
Metodologías ágiles, Scrum, Kanban y eXtreme Programming
Emergya
 

La actualidad más candente (8)

Nuevos entornos de trabajo corporativo
Nuevos entornos de trabajo corporativoNuevos entornos de trabajo corporativo
Nuevos entornos de trabajo corporativo
 
Introducción al proyecto
Introducción al proyectoIntroducción al proyecto
Introducción al proyecto
 
Dsdm_f
Dsdm_fDsdm_f
Dsdm_f
 
Trabajo gestor de proyectos
Trabajo gestor de proyectosTrabajo gestor de proyectos
Trabajo gestor de proyectos
 
Metodos agiles 3
Metodos agiles 3Metodos agiles 3
Metodos agiles 3
 
Public3
Public3Public3
Public3
 
Elmanifiestoylosprincipiosgiles 131007145716-phpapp01
Elmanifiestoylosprincipiosgiles 131007145716-phpapp01Elmanifiestoylosprincipiosgiles 131007145716-phpapp01
Elmanifiestoylosprincipiosgiles 131007145716-phpapp01
 
Metodologías ágiles, Scrum, Kanban y eXtreme Programming
Metodologías ágiles, Scrum, Kanban y eXtreme ProgrammingMetodologías ágiles, Scrum, Kanban y eXtreme Programming
Metodologías ágiles, Scrum, Kanban y eXtreme Programming
 

Similar a Migrar cuatro pasos

Actividad 3 Hardware
Actividad 3 HardwareActividad 3 Hardware
Actividad 3 Hardware
Jazmin Sandoval
 
Software Libre. Beneficios en la PYME. Camara de comercio de Badajoz
Software Libre. Beneficios en la PYME. Camara de comercio de BadajozSoftware Libre. Beneficios en la PYME. Camara de comercio de Badajoz
Software Libre. Beneficios en la PYME. Camara de comercio de Badajoz
Pedro Francisco Vidal López
 
Revista Mundo Contact Agosto 2015
Revista Mundo Contact Agosto 2015Revista Mundo Contact Agosto 2015
Revista Mundo Contact Agosto 2015
Mundo Contact
 
DevOps Finetuning Additional Considerations, Concepts, and Practices
DevOps Finetuning Additional Considerations, Concepts, and Practices DevOps Finetuning Additional Considerations, Concepts, and Practices
DevOps Finetuning Additional Considerations, Concepts, and Practices
Octavio Velez Gaviria
 
Como Migrar a la Nube AWS
Como Migrar a la Nube AWSComo Migrar a la Nube AWS
Como Migrar a la Nube AWS
Mauricio Ferreyra
 
Software enlatado o a medida: Cual es mejor para mi empresa
Software enlatado o a medida: Cual es mejor para mi empresaSoftware enlatado o a medida: Cual es mejor para mi empresa
Software enlatado o a medida: Cual es mejor para mi empresa
Grupo VisualCont
 
Costos de mantenimiento de los erp
Costos de mantenimiento de los erpCostos de mantenimiento de los erp
Costos de mantenimiento de los erp
EvaluandoSoftware
 
Costosdemantenimientodeloserp 120824134652-phpapp01
Costosdemantenimientodeloserp 120824134652-phpapp01Costosdemantenimientodeloserp 120824134652-phpapp01
Costosdemantenimientodeloserp 120824134652-phpapp01
Julio Carreto
 
Whitepaper: Checklist de migración al Cloud
Whitepaper: Checklist de migración al CloudWhitepaper: Checklist de migración al Cloud
Whitepaper: Checklist de migración al Cloud
Arsys
 
1 Avance Del Proyecto 6
1 Avance Del Proyecto 61 Avance Del Proyecto 6
1 Avance Del Proyecto 6
guestde29b5
 
Por qué Cloud Computing le interesa a finanzas
Por qué Cloud Computing le interesa a finanzasPor qué Cloud Computing le interesa a finanzas
Por qué Cloud Computing le interesa a finanzas
EvaluandoSoftware
 
Dev ops una perspectiva ágil más allá del código.
Dev ops  una perspectiva ágil más allá del código.Dev ops  una perspectiva ágil más allá del código.
Dev ops una perspectiva ágil más allá del código.
Zaira Bermúdez
 
Dev ops una perspectiva ágil más allá del código.
Dev ops  una perspectiva ágil más allá del código.Dev ops  una perspectiva ágil más allá del código.
Dev ops una perspectiva ágil más allá del código.
Zaira Bermúdez
 
Unidad iii tema 06 - equipo dcs - implementación de las erp
Unidad iii   tema 06 - equipo dcs - implementación de las erpUnidad iii   tema 06 - equipo dcs - implementación de las erp
Unidad iii tema 06 - equipo dcs - implementación de las erp
acpicegudomonagas
 
Futuro del Software: Impacto en las organizaciones y en los profesionales
Futuro del Software:  Impacto en las organizaciones  y en los profesionalesFuturo del Software:  Impacto en las organizaciones  y en los profesionales
Futuro del Software: Impacto en las organizaciones y en los profesionales
AISTI
 
Unidad 1.2 B Metodos Agiles 1
Unidad 1.2 B Metodos Agiles  1Unidad 1.2 B Metodos Agiles  1
Unidad 1.2 B Metodos Agiles 1
Sergio Sanchez
 
Articulo tecnológico
Articulo tecnológicoArticulo tecnológico
Articulo tecnológico
bmkd
 
Articulo tecnológico
Articulo tecnológicoArticulo tecnológico
Articulo tecnológico
bmkd
 
Desarrollode software (1)
Desarrollode software (1)Desarrollode software (1)
Desarrollode software (1)
turlahackers
 
Cómo convencer a tu jefe de implementar o cambiar el ERP
Cómo convencer a tu jefe de implementar o cambiar el ERPCómo convencer a tu jefe de implementar o cambiar el ERP
Cómo convencer a tu jefe de implementar o cambiar el ERP
EvaluandoSoftware
 

Similar a Migrar cuatro pasos (20)

Actividad 3 Hardware
Actividad 3 HardwareActividad 3 Hardware
Actividad 3 Hardware
 
Software Libre. Beneficios en la PYME. Camara de comercio de Badajoz
Software Libre. Beneficios en la PYME. Camara de comercio de BadajozSoftware Libre. Beneficios en la PYME. Camara de comercio de Badajoz
Software Libre. Beneficios en la PYME. Camara de comercio de Badajoz
 
Revista Mundo Contact Agosto 2015
Revista Mundo Contact Agosto 2015Revista Mundo Contact Agosto 2015
Revista Mundo Contact Agosto 2015
 
DevOps Finetuning Additional Considerations, Concepts, and Practices
DevOps Finetuning Additional Considerations, Concepts, and Practices DevOps Finetuning Additional Considerations, Concepts, and Practices
DevOps Finetuning Additional Considerations, Concepts, and Practices
 
Como Migrar a la Nube AWS
Como Migrar a la Nube AWSComo Migrar a la Nube AWS
Como Migrar a la Nube AWS
 
Software enlatado o a medida: Cual es mejor para mi empresa
Software enlatado o a medida: Cual es mejor para mi empresaSoftware enlatado o a medida: Cual es mejor para mi empresa
Software enlatado o a medida: Cual es mejor para mi empresa
 
Costos de mantenimiento de los erp
Costos de mantenimiento de los erpCostos de mantenimiento de los erp
Costos de mantenimiento de los erp
 
Costosdemantenimientodeloserp 120824134652-phpapp01
Costosdemantenimientodeloserp 120824134652-phpapp01Costosdemantenimientodeloserp 120824134652-phpapp01
Costosdemantenimientodeloserp 120824134652-phpapp01
 
Whitepaper: Checklist de migración al Cloud
Whitepaper: Checklist de migración al CloudWhitepaper: Checklist de migración al Cloud
Whitepaper: Checklist de migración al Cloud
 
1 Avance Del Proyecto 6
1 Avance Del Proyecto 61 Avance Del Proyecto 6
1 Avance Del Proyecto 6
 
Por qué Cloud Computing le interesa a finanzas
Por qué Cloud Computing le interesa a finanzasPor qué Cloud Computing le interesa a finanzas
Por qué Cloud Computing le interesa a finanzas
 
Dev ops una perspectiva ágil más allá del código.
Dev ops  una perspectiva ágil más allá del código.Dev ops  una perspectiva ágil más allá del código.
Dev ops una perspectiva ágil más allá del código.
 
Dev ops una perspectiva ágil más allá del código.
Dev ops  una perspectiva ágil más allá del código.Dev ops  una perspectiva ágil más allá del código.
Dev ops una perspectiva ágil más allá del código.
 
Unidad iii tema 06 - equipo dcs - implementación de las erp
Unidad iii   tema 06 - equipo dcs - implementación de las erpUnidad iii   tema 06 - equipo dcs - implementación de las erp
Unidad iii tema 06 - equipo dcs - implementación de las erp
 
Futuro del Software: Impacto en las organizaciones y en los profesionales
Futuro del Software:  Impacto en las organizaciones  y en los profesionalesFuturo del Software:  Impacto en las organizaciones  y en los profesionales
Futuro del Software: Impacto en las organizaciones y en los profesionales
 
Unidad 1.2 B Metodos Agiles 1
Unidad 1.2 B Metodos Agiles  1Unidad 1.2 B Metodos Agiles  1
Unidad 1.2 B Metodos Agiles 1
 
Articulo tecnológico
Articulo tecnológicoArticulo tecnológico
Articulo tecnológico
 
Articulo tecnológico
Articulo tecnológicoArticulo tecnológico
Articulo tecnológico
 
Desarrollode software (1)
Desarrollode software (1)Desarrollode software (1)
Desarrollode software (1)
 
Cómo convencer a tu jefe de implementar o cambiar el ERP
Cómo convencer a tu jefe de implementar o cambiar el ERPCómo convencer a tu jefe de implementar o cambiar el ERP
Cómo convencer a tu jefe de implementar o cambiar el ERP
 

Más de BartOc3

Migraciones empresariales a software libre #eDays2014
Migraciones empresariales a software libre #eDays2014Migraciones empresariales a software libre #eDays2014
Migraciones empresariales a software libre #eDays2014
BartOc3
 
Instalación de Firmware AlterMesh de router TP-Link #RedesLibres
Instalación de Firmware AlterMesh de router TP-Link #RedesLibresInstalación de Firmware AlterMesh de router TP-Link #RedesLibres
Instalación de Firmware AlterMesh de router TP-Link #RedesLibres
BartOc3
 
Plan de Migración e Implantación de Software Libre en el Ayuntamiento de Pale...
Plan de Migración e Implantación de Software Libre en el Ayuntamiento de Pale...Plan de Migración e Implantación de Software Libre en el Ayuntamiento de Pale...
Plan de Migración e Implantación de Software Libre en el Ayuntamiento de Pale...
BartOc3
 
Manual de Libre Office Calc
Manual de Libre Office CalcManual de Libre Office Calc
Manual de Libre Office Calc
BartOc3
 
Caso confiar
Caso confiarCaso confiar
Caso confiar
BartOc3
 
Estandares abiertos-odf
Estandares abiertos-odfEstandares abiertos-odf
Estandares abiertos-odf
BartOc3
 
Y de open office.org que
Y de open office.org queY de open office.org que
Y de open office.org que
BartOc3
 
Sensibilizacion y otros_temas_de_open_source
Sensibilizacion y  otros_temas_de_open_sourceSensibilizacion y  otros_temas_de_open_source
Sensibilizacion y otros_temas_de_open_source
BartOc3
 
O oo ms office
O oo ms officeO oo ms office
O oo ms office
BartOc3
 
Migrar vba
Migrar vbaMigrar vba
Migrar vba
BartOc3
 
Crear índices de contenido en Libre Office/OpenOffice Writer
Crear índices de contenido en Libre Office/OpenOffice  WriterCrear índices de contenido en Libre Office/OpenOffice  Writer
Crear índices de contenido en Libre Office/OpenOffice Writer
BartOc3
 
Future of work
Future of workFuture of work
Future of work
BartOc3
 
Estrategia exitosa migracion o oo (2)
Estrategia exitosa migracion o oo (2)Estrategia exitosa migracion o oo (2)
Estrategia exitosa migracion o oo (2)
BartOc3
 
Migrar cuatro pasos
Migrar cuatro pasosMigrar cuatro pasos
Migrar cuatro pasos
BartOc3
 
Comparacion migracion aoo_libo
Comparacion migracion aoo_liboComparacion migracion aoo_libo
Comparacion migracion aoo_libo
BartOc3
 
Ayuda migracion
Ayuda migracion Ayuda migracion
Ayuda migracion
BartOc3
 
Asegurando el exito de migrar a open office.org
Asegurando el exito de migrar a open office.orgAsegurando el exito de migrar a open office.org
Asegurando el exito de migrar a open office.org
BartOc3
 
Aprendamos de novell
Aprendamos de novellAprendamos de novell
Aprendamos de novell
BartOc3
 
Aprendamos de novell
Aprendamos de novellAprendamos de novell
Aprendamos de novell
BartOc3
 
Aplicaciones en excel
Aplicaciones en excelAplicaciones en excel
Aplicaciones en excel
BartOc3
 

Más de BartOc3 (20)

Migraciones empresariales a software libre #eDays2014
Migraciones empresariales a software libre #eDays2014Migraciones empresariales a software libre #eDays2014
Migraciones empresariales a software libre #eDays2014
 
Instalación de Firmware AlterMesh de router TP-Link #RedesLibres
Instalación de Firmware AlterMesh de router TP-Link #RedesLibresInstalación de Firmware AlterMesh de router TP-Link #RedesLibres
Instalación de Firmware AlterMesh de router TP-Link #RedesLibres
 
Plan de Migración e Implantación de Software Libre en el Ayuntamiento de Pale...
Plan de Migración e Implantación de Software Libre en el Ayuntamiento de Pale...Plan de Migración e Implantación de Software Libre en el Ayuntamiento de Pale...
Plan de Migración e Implantación de Software Libre en el Ayuntamiento de Pale...
 
Manual de Libre Office Calc
Manual de Libre Office CalcManual de Libre Office Calc
Manual de Libre Office Calc
 
Caso confiar
Caso confiarCaso confiar
Caso confiar
 
Estandares abiertos-odf
Estandares abiertos-odfEstandares abiertos-odf
Estandares abiertos-odf
 
Y de open office.org que
Y de open office.org queY de open office.org que
Y de open office.org que
 
Sensibilizacion y otros_temas_de_open_source
Sensibilizacion y  otros_temas_de_open_sourceSensibilizacion y  otros_temas_de_open_source
Sensibilizacion y otros_temas_de_open_source
 
O oo ms office
O oo ms officeO oo ms office
O oo ms office
 
Migrar vba
Migrar vbaMigrar vba
Migrar vba
 
Crear índices de contenido en Libre Office/OpenOffice Writer
Crear índices de contenido en Libre Office/OpenOffice  WriterCrear índices de contenido en Libre Office/OpenOffice  Writer
Crear índices de contenido en Libre Office/OpenOffice Writer
 
Future of work
Future of workFuture of work
Future of work
 
Estrategia exitosa migracion o oo (2)
Estrategia exitosa migracion o oo (2)Estrategia exitosa migracion o oo (2)
Estrategia exitosa migracion o oo (2)
 
Migrar cuatro pasos
Migrar cuatro pasosMigrar cuatro pasos
Migrar cuatro pasos
 
Comparacion migracion aoo_libo
Comparacion migracion aoo_liboComparacion migracion aoo_libo
Comparacion migracion aoo_libo
 
Ayuda migracion
Ayuda migracion Ayuda migracion
Ayuda migracion
 
Asegurando el exito de migrar a open office.org
Asegurando el exito de migrar a open office.orgAsegurando el exito de migrar a open office.org
Asegurando el exito de migrar a open office.org
 
Aprendamos de novell
Aprendamos de novellAprendamos de novell
Aprendamos de novell
 
Aprendamos de novell
Aprendamos de novellAprendamos de novell
Aprendamos de novell
 
Aplicaciones en excel
Aplicaciones en excelAplicaciones en excel
Aplicaciones en excel
 

Migrar cuatro pasos

  • 1. La migración a software libre: el puesto de trabajo sostenible (I) Por JJ Velasco | 5 de julio de 2011, 19:32 Ahora que el soporte de Windows XP está, prácticamente, muerto, muchas empresas se están planteando la migración de los equipos de sus puestos de trabajo a Windows 7. Pasar desde Windows XP a Windows 7 podría ser la evolución natural y, quizás, la más lógica; sin embargo, existe un modelo alternativo que las empresas deberían plantearse: el software libre. En estos tiempos de crisis y de búsqueda de la eficiencia en el gasto, la adopción de software libre en el puesto de trabajo puede suponer, a medio plazo, un importante ahorro de costes y, sobre todo, una gran paso hacia la independencia tecnológica. Migrar los puestos de trabajo hacia un sistema operativo basado en GNU/Linux no es una decisión a tomar a la ligera, bajo mi punto de vista, necesita de cierta preparación y, sobre todo, el tratamiento de un proyecto interno al que hay que dedicar recursos. A través de varios posts vamos a ir analizando qué pasos deberíamos dar si queremos plantearnos la migración a software libre de los puestos de trabajo de una organización. Para empezar, es fundamental el compromiso de la Dirección de la compañía, sin el respaldo de la Dirección la oposición al cambio puede ser mucho mayor y, en casos extremos, dar al traste con todo el proyecto. Un proyecto de este calibre no es, únicamente, la adopción de una solución tecnológica que nos va a hacer ganar dinero, también nos va a redundar en un aumento de la seguridad de nuestros puestos de trabajo y, sobre todo, es un cambio de filosofía de la empresa, que apuesta por un modelo sostenible e independiente tecnológicamente. Por tanto, ante tanto cambio que debemos gestionar, no nos viene mal analizar el proceso y plantearnos algunas fases con las que llevar a cabo este proyecto. 1. Contexto económico Aunque los que conocemos el mundo del software libre pensemos que es una gran opción, quizás nuestros jefes no tengan esta misma visión y, posiblemente, se hayan acostumbrado al uso de Windows,
  • 2. por ejemplo, y por comodidad no quieran cambiar. Esto es algo que puede pasar y será la primera batalla que tengamos que librar si queremos arrancar este tipo de proyecto. ¿Y cómo convencer a nuestros jefes? Cambiar la filosofía de trabajo de una compañía no es fácil, al fin y al cabo, forma parte de la propia cultura de la empresa y cualquier cambio cultural debe gestionarse adecuadamente. Teniendo en cuenta la coyuntura económica, un modelo basado en costes podría ser un interesante punto de partida para justificar la necesidad de la migración. Hay que tener en cuenta que el uso de software con licencia responde a un modelo cíclico, es decir, adquirimos una licencia, la usamos y, una vez amortizada, pasamos a adquirir licencias de la siguiente versión (en el caso de licencias que no tengan caducidad) o, por el contrario, vamos renovando con la periodicidad que sea las licencias adquiridas. Este modelo cíclico afectará, prácticamente, a todas las licencias que hayamos adquirido (Sistema operativo, Microsoft Office, Antivirus, etc), simplemente variará el período de duración de la licencia (en el caso que caduquen) o el tiempo que reste para su amortización. Además, a este modelo cíclico de adquisición de activos (las licencias) hay que sumar otros costes, los costes de operación, es decir, los costes en los que incurrimos para solventar las incidencias de nuestros usuarios, instalar software en los equipos, etc. Bajo un entorno basado en software libre, este modelo de costes se simplifica mucho, en algunos casos se puede llegar a reducir únicamente a los costes de operación (en un entorno ideal) pero, básicamente, los costes relacionados con licencias de ofimática y alguna que otra aplicación desaparecen, por tanto, se eliminan esos desembolsos cíclicos debido a la obsolescencia o caducidad de las licencias de software adquiridas. ¿Y cómo plantear esto? Lo más sencillo es plantear los costes en los que incurrimos durante cinco años, una ventana de tiempo a medio plazo y que puede ser significativa como para evaluar los gastos en los que incurrimos adquiriendo licencias (o equipos que ya las tienen instaladas) y renovándolas. 2. Contexto temporal Tras estudiar lo que nos gastamos en adquisiciones, debemos estudiar cuándo es el mejor momento para realizar la migración. Hoy en día, el cierre del soporte de Windows XP puede ser un muy buen motivo para migrar, sin embargo, el factor tiempo es muy significativo (desde el punto de vista económico) y, por tanto, elegir una fecha sin estudiar el contexto nos podría hacer que incurriésemos en pérdidas. En algunas metodologías consideran que si hay convencimiento por parte de la empresa por migrar, debería ser suficiente. Yo creo que es necesario pero no es el único factor a tener en cuenta, sobre todo, si queremos dar unas cifras cercanas a la realidad. Cualquier aplicación que compremos tiene una vida útil (un año, cuatro, etc) y, por tanto, si decidimos migrar sin agotar dicha vida útil, no habremos amortizado por completo esa inversión (que se estará malgastando).
  • 3. Con esto quiero decir que si acabamos de adquirir licencias de Microsoft Office para toda la empresa, quizás haya que comparar cuánto nos va a costar migrar a Windows 7, compararlo con los costes de la migración a software libre y si la diferencia resulta mayor al coste de las licencias de Microsoft Office, podremos contrarrestar las pérdidas pero si nos resultan iguales o menores, entonces quizás no sea el mejor momento para migrar. El momento ideal es aquel en el que hemos agotado la vida útil de nuestras licencias, una situación ideal que rara vez ocurre, puesto que no todas se han comprado a la vez, ni tampoco tienen la misma vida útil. Por tanto, tendremos que seleccionar aquella fecha que minimice nuestras pérdidas (entendidas como licencias que no hemos amortizado). 3. Reajustando el modelo de costes Tras realizar el análisis temporal parece claro que tenemos que volver a nuestro modelo económico y reajustarlo, añadiendo las pérdidas que hemos detectado (por licencias no amortizadas). También será el momento de añadir otros costes asociados a la migración que tendremos que tener cuenta y que, posteriormente, iremos desarrollando: • Consultoría: en el caso de la migración a software libre, vamos a plantear un cambio en el modelo de gestión de la compañía, además de un cambio tecnológico. Por tanto, ya sea con recursos propios o externos, vamos a tener que dedicar cierto tiempo (y recursos) a realizar una consultoría para sentar las bases técnicas y metodológicas para llevar a cabo el proceso de migración de los puestos de trabajo. • Migración: lógicamente, el proceso de migración tiene un coste asociado. Son recursos que, tanto en un entorno en software libre como en uno propietario, son necesarios para migrar los datos de los usuarios, actualizar o cambiar el sistema operativo, restaurar datos, aplicaciones, etc. • Formación a usuarios: si optamos por el cambio, no debemos abandonar a nuestros usuarios a su suerte, es decir, necesitarán que les guiemos por el nuevo entorno y ponérselo algo fácil. La profundidad de esta formación dependerá del grado de madurez de nuestra organización, sus conocimientos sobre el entorno y su grado de resistencia al cambio. • Soporte: nuestro equipo de soporte también necesita actualizarse, tanto en conocimientos como en herramientas. Quizás sea buen momento para analizar las herramientas que utilizan, buscar alternativas y, sobre todo, mejorar los procedimientos de actuación.
  • 4. • Islas residuales: es posible que la consultoría nos arroje, dentro de sus conclusiones, que en nuestra organización tengamos algunos puestos que no puedan ser migrados a software libre o bien tengamos que buscar alguna solución que posibilite el uso de una solución propietaria bajo un escritorio libre. Tendremos que convivir con estas “islas residuales” y tratarlas de manera especial. Una vez analizados estos aspectos, con sus correspondientes valoraciones económicas, habremos completado nuestro modelo económico que, previsiblemente, arroje que migrar a software libre sea más caro que migrar a Windows 7, pero claro, ese es el dato a corto plazo pero que, al eliminar de la ecuación gran parte de los desembolsos económicos en renovación de licencias, comenzará a ser rentable a medio plazo (a partir del segundo o tercer año) y, desde ahí en adelante, todo serán beneficios. En el siguiente post veremos cómo llevar a cabo el proceso, una vez que tengamos luz verde por parte de la Dirección de nuestra compañía. La migración a software libre: el puesto de trabajo sostenible (II) Por JJ Velasco | 8 de julio de 2011, 14:27 En el post anterior estuvimos analizando la idoneidad de migrar los puestos de trabajo a software libre, tanto desde un punto de vista cualitativo como desde un contexto económico. En esta ocasión nos toca profundizar en el proceso de migración en sí, es decir, en la transformación de un entorno corporativo con puestos de trabajo basados en soluciones propietarias a un entorno que funciona, casi en su totalidad, con herramientas basadas en software libre. 4. Estudiar a la organización y entender sus procesos y su funcionamiento Tras las hojas de cálculo y los estudios de costes nos toca entrar, por fin, en contacto con el usuario e intentar entender cómo trabajan, qué aplicaciones suelen utilizar y, en definitiva, entender cuáles son sus necesidades actuales y a medio plazo. Lo recomendable es articular esta fase en torno a una ronda de entrevistas (con los responsables de cada equipo y con sus miembros) para conocer qué
  • 5. herramientas utilizan, qué necesidades tienen y qué función cumplen en la organización. Para comprender el funcionamiento de una organización es importante observar cómo trabaja, es decir, sentarnos con cada uno de los trabajadores, ver cómo se manejan en su entorno de escritorio, qué usan y para qué. De esa forma podremos ir viendo qué alternativas tendremos que buscar (para satisfacer las necesidades de los usuarios y la organización) y qué cosas, irremediablemente, tendremos que mantener porque no existe solución técnica en software libre que cubra la mayor parte de necesidades. 5. Aportando soluciones Tras estudiar a nuestra organización llega el momento de plantear las soluciones que vamos a adoptar. Abrir la tapa del “gran arcón” del software libre y ponernos a coger lo primero que veamos, está claro que no es el camino a seguir. Es recomendable realizar esta prospectiva tecnológica en paralelo al estudio de la organización porque así iremos adelantando trabajo e iremos buscando posibles soluciones conforme vayamos capturando los requisitos y necesidades de nuestros usuarios. ¿Y qué soluciones tendremos que buscar? Existen muchas soluciones empresariales basadas en software libre con los que poder dar soporte a la mayor parte de procesos empresariales: gestores documentales, compartir ficheros, gestión de agenda; sin embargo, esta migración se centra en el escritorio y, como tal, también tendremos que buscar soluciones en este entorno. Básicamente nos referimos a cambiar Outlook por Thunderbird, Microsoft Office por LibreOffice, OneNote por Tomboy o Evernote (si queremos usar la nube, aunque esto no sea libre), Microsoft Project por alguna herramienta colaborativa online u OpenProj, Dia en vez de Microsoft Visio, etc. Sin embargo, es muy posible que existan aplicaciones que no tengan equivalente en Linux y para las que tengamos que pensar en alguna solución de compromiso (ya sea montando un servidor Windows al que se conecten en remoto los usuarios y ejecuten ahí las aplicaciones o bien usando Wine o máquinas virtuales).
  • 6. 6. La migración El proceso de migración es el punto más crítico del proceso, puesto que debe ser lo más transparente posible al usuario y, además, debe impactar lo mínimo posible en la productividad de éste (tiempo en el que no podrá usar su equipo). Para llevarlo a cabo deberíamos haber diseñado un plan que abarque los siguientes aspectos: • Maqueta a utilizar, es decir, partir de una distribución Linux, personalizarla (configuración, aplicaciones, etc) y, a partir de ahí, sacar un máster (o más, dependiendo del número de configuraciones distintas que necesitemos) que será el que instalaremos en los equipos de los usuarios. • Plan de intervención que establecerá un calendario con las actuaciones a acometer y las actuaciones previas necesarias antes de migrar (backups). • Plan de contingencia o dicho de otra forma, cómo volver atrás si algo sale mal o si surge alguna emergencia o imprevisto. Antes de arrancar el proceso, sería conveniente comunicar lo que vamos a hacer a los usuarios o, al menos, a sus responsables para que la información fluya y nadie se sienta excluido (y pueda oponer algo más de resistencia al cambio). 7. Gestionar los cambios La expresión “gestión del cambio” se usa mucho en cualquier proceso de cambio de modelo de gestión. Esta disciplina se ocupa de minimizar el impacto que pueden provocar los cambios en procesos ya arraigados (y cambiar el entorno de trabajo es un salto que debe gestionarse adecuadamente). Dicen los expertos que cuando el usuario se siente partícipe del cambio, es mucho más fácil que lo entienda e, incluso, se alinee con ellos, colaborando de forma activa y no entorpeciendo el proceso. ¿Y cómo hacer al usuario partícipe del cambio? Básicamente con dos líneas de actuación: la comunicación y la formación. Una comunicación fluida a los usuarios que les informe de los pasos que se dan, un proceso que cuente con sus opiniones, un equipo les pregunte y, en definitiva, converse con ellos, es un buen caballo de batalla que nos puede allanar mucho el camino a recorrer. El desconocimiento y, por tanto, el miedo al cambio son las barreras a vencer y si somos muy opacos durante este proceso, el usuario se resistirá al cambio y, en casos extremos, puede llegar a boicotearlo. Por otro lado, dependiendo del nivel de conocimientos que tenga la organización, necesitaremos organizar diversas acciones formativas que ayuden al usuario a adaptarse al nuevo entorno de funcionamiento, a usar las nuevas aplicaciones y, en definitiva, enseñarles dónde están las herramientas con las que podrán desempeñar sus funciones habituales.
  • 7. 8. Análisis del proceso Tras finalizar el proceso de migración, nos encontramos ante un punto de inflexión en la manera de gestionar el parque informático de nuestra compañía. Además de analizar los errores o fallos que nos hemos ido encontrando, es el momento de volcar todo el conocimiento adquirido en algún gestor que permita a todo nuestro equipo de soporte compartir lo aprendido (y lo que llegará), de manera que todos los implicados vayan creciendo y adquiriendo más experiencia en el soporte al usuario. Conclusiones Un proyecto de este tipo, además de ser una apuesta por una tecnología sostenible y, lógicamente, libre, es todo un reto tecnológico que necesita su tiempo para ser llevado a cabo correctamente. Es una apuesta y como tal, debe contar con el compromiso de la dirección, sin ese apoyo, mejor no embarcarse porque nadie se sentirá identificado con la migración y puede que no nos encontremos muchos apoyos. Gestionar la comunicación y hacer partícipe al usuario es una de las claves para que este proyecto sea un éxito, además de nuestra pericia en la realización de la prospectiva (para buscar aplicaciones) y en nuestro análisis de requisitos. Para todo aquel que quiera profundizar más en el tema, el CENATIC (Centro Nacional de Referencia de Aplicación de las TIC basadas en fuentes abiertas) trabaja en un modelo de migración para grandes organizaciones que, aunque está en desarrollo, ofrece algunas interesantes herramientas con las que dar soporte a este proceso. La migración a software libre: el puesto de trabajo sostenible (III) Por JJ Velasco | 1 de agosto de 2011, 14:28
  • 8. Hace aproximadamente un mes, estuvimos analizando en un par de notas cómo podría llevarse a cabo la migración de los puestos de trabajo de una empresa a escritorios basados totalmente en software libre. Primero estuvimos estudiando el contexto económico y temporal, es decir, una justificación económica que sustentase la decisión de migrar y, posteriormente, la pautas que podríamos seguir para poner en práctica el proyecto de migración. Lo ideal sería que pudiésemos migrar toda nuestra empresa, bueno, si así lo deseamos y, además, los datos económicos lo apoyan; sin embargo, no en todos los casos sería posible hacerlo y, posiblemente, tengamos que vivir en entornos mixtos. Otro escenario posible, y tampoco sería muy descabellado, podría ser un entorno en el que se decide aplicar una transición mucho más suave, es decir, ir eliminando aplicaciones propietarias paulatinamente y, una vez se han eliminado en gran parte, proceder a la migración del sistema operativo hacia alguna distribución Linux con entorno de escritorio. Esta opción, sobre todo en entornos que tienen algunas dudas, puede ser la más interesante puesto que no supone un cambio radical y, desde el primer momento, se puede palpar el ahorro y estudiar la evolución y adaptación de los empleados a las nuevas herramientas. Abordar un proceso de migración suave, lógicamente, supone que el plazo de realización aumente y, además, se tengan que definir más puntos de control. En estos casos, al igual que en la migración total, también tenemos que dedicar un tiempo a estudiar el funcionamiento de nuestra organización, entender los procesos y conocer las aplicaciones que los soportan. Para conocer cómo funciona nuestra empresa, además de observar a nuestros compañeros de trabajo, avanzaremos mucho si nos sentamos con ellos y les preguntamos por cómo trabajan en su día a día. Muchas veces, la gente que trabaja en el área de IT, tenemos una imagen preconcebida de lo que hacen nuestros compañeros y, seguramente, se nos pasen algunos detalles que, aunque no les demos importancia, para ellos son importantes. Una ronda de entrevistas, además de la observación, es lo mejor para abordar esta fase.
  • 9. Teniendo en cuenta que vamos a aplicar un proceso gradual, en la fase de prospectiva tecnológica tendremos que buscar aplicaciones que sustituyan al software propietario (al menos todo el que se pueda) pero con dos condicionantes: deben existir tanto en Linux como en Windows o, al menos, deben ser aplicaciones web. Quizás esté acotando demasiado el campo de búsqueda pero, por experiencia personal, creo que es mejor huir de la emulación en Wine porque, a veces, no funciona todo lo bien que quisiésemos y el usuario se termina enfadando. Es muy importante que el usuario vea cubiertas todas sus necesidades o, al menos, la gran mayoría de ellas porque, teniendo en cuenta que seguimos en un entorno Windows, en caso de no cumplirlas podrían pedir volver al estado anterior. Lógicamente, en esta migración suave, el compromiso de la Dirección es importante y, en época de crisis, ahorrar es importante; sin embargo, si el personal no está contento y, aunque sea exagerado, atisban cierto riesgo de bajada de la productividad, podrían cancelar esta transición. Por tanto, si recordamos los pasos que fuimos comentando en los dos artículos pasados, el proceso de migración no partirá de la elaboración de una maqueta, sino que instalaremos aplicaciones libres que sustituyan a las propietarias, migraremos los datos e iremos desinstalando el software privativo. Este proceso será iterativo y gradual, es decir, lo recomendable es ir cambiando aplicaciones poco a poco (conforme se vayan amortizando las licencias) y apoyar el cambio mediante la formación necesaria a los usuarios. Llegará un momento en el que, tras la última iteración, hayamos migrado todas las aplicaciones de nuestros usuarios a soluciones totalmente libres. ¿Qué haremos entonces? Lo ideal sería sustituir el sistema operativo propietario y apostar por uno libre y, por tanto, elaborar una maqueta con todas las aplicaciones que hemos ido instalando. Pero, si por el motivo que fuese no pudiésemos dar este último gran paso, al menos estaríamos ahorrando un importante capital gracias al uso de aplicaciones libres y, desde luego, será algo que se note en los costes operacionales de la compañía.
  • 10. C La migración a software libre: el puesto de trabajo sostenible (IV) by sobajar on Aug 06, 2011 Para finalizar esta serie sobre las migración de los puestos de trabajo de una empresa a software libre, vamos a hacer una reflexión que nos ayude a afrontar este tipo de proyectos y, sobre todo, nos aporte una serie de ideas con las que poder argumentar la necesidad de aplicar este tipo de cambios a una organización. Después de revisar cómo hacer un modelo económico, cómo planificar el proceso de migración total o plantearnos una transición gradual, es el momento de revisar algunos motivos por los cuales una migración a software libre podría beneficiar a nuestra empresa. ¿Por qué migrar? Bueno, esa esta es la pregunta clave porque algún motivo debemos dar para iniciar este cambio en nuestra empresa. Para empezar, a medio plazo, vamos a obtener un importante ahorro económico en el coste de licencias (aplicaciones y sistema operativo), eso sí, es un ahorro a medio plazo puesto que el proceso de migración conllevará esfuerzos (internos o externos) y, por tanto, tendrá asociado un coste (aunque no será cíclico). Por otro lado, podemos obtener un importante ahorro en hardware puesto que, dado que los requisitos son algo menores, podremos ampliar la vida útil de nuestros ordenadores y, por tanto, alargar su amortización. No tener que renovar el parque informático de la empresa con tanta asiduidad y que, simplemente, con aumentar la memoria RAM podamos alargar su vida en un par de años, es un motivo de bastante peso. Además, gracias al acceso al código fuente, podemos tanto auditar el código de las aplicaciones, mejorarlas y personalizarlas, adaptándolas a las necesidades de nuestro negocio. De hecho, muchas de estas personalizaciones se ponen a disposición de la comunidad, haciendo que todos los usuarios se vean beneficiados. Desde el punto de vista de la gestión, la utilización de soluciones abiertas garantiza nuestra independencia tecnológica (puesto que no estamos sujetos a una solución de un fabricante concreto) y nos abre el horizonte a que nos puedan prestar servicios múltiples empresas. Pero quizás, una de las
  • 11. garantías más importantes que nos brinda este modelo es el de la interoperabilidad que, gracias a que el software libre se fundamenta en estándares abiertos, nos garantiza con otros sistemas o componentes. La interoperabilidad es muy importante, tanto en el ámbito privado como en el público (por ejemplo, en España hay una norma que lo regula en el ámbito de las Administraciones Públicas) ¿Qué problemas nos vamos a encontrar? La principal barrera que nos vamos a encontrar es el cambio de mentalidad necesario para abordar este proyecto con éxito. Decíamos en la segunda entrega de esta serie que había que gestionar adecuadamente el cambio organizacional y, para ello, tendremos que formar adecuadamente a nuestros empleados (en las nuevas aplicaciones y en el nuevo entorno, si también cambiamos el sistema operativo) y, además, desmitificar algunos de los prejuicios que hay alrededor del mundo del software libre. La resistencia al cambio es algo intrínseco al ser humano, si alguien está acostumbrado a trabajar de una manera determinada y, además, le va medianamente bien, no va a querer cambiar, menos aún, si el cambio viene obligado. El primer mito a derribar es el de la complejidad, es decir, la creencia de que las aplicaciones libres son complicadas, algo que no tiene por qué ser así sino que, simplemente, hay que aprender a manejarse en un entorno nuevo (lo cual no implica mayor complejidad). Otro mito a derribar es el de la falta de soporte y asistencia técnica, algo que no es cierto y que, además, gracias a la adopción del software libre en algunas Administraciones Públicas, ha posibilitado la creación de un tejido empresarial potente. Dependiendo de la especialización de nuestros empleados y de nuestra empresa, quizás nos encontremos ante aplicaciones que no van a poder ser migradas. Estas situaciones habrán de ser tratadas con especial cuidado porque, mal llevadas, podrían suponer la cancelación de la migración y la pérdida de confianza en este modelo. Bien llevadas, simplemente, nos llevarán, en el peor de los casos, a mantener pequeñas islas con software privativo.
  • 12. Conclusiones Después de estos cuatro artículos dedicados a la migración al software libre, creo que podemos sacar algunas conclusiones que nos pueden ser útiles a la hora de enfrentarnos a este tipo de proyectos: • Beneficios económicos, a medio plazo y largo plazo gracias al ahorro en licencias puesto que, en un corto plazo, el hecho de realizar la migración nos hará incurrir en un coste (consultoría, migración, etc) que podría equipararse a la renovación de licencias. • Es un proyecto que requiere una correcta planificación y gestión del proceso, en el que debemos valorar, correctamente, todos los factores que influyen en él: procesos de la empresa, aplicaciones que se utilizan, conocimientos del personal, formación necesaria, etc. • Este tipo de proyectos, al suponer un cambio importante en la cultura de la organización, necesita el apoyo firme y decidido de la Dirección. Si no confían en este proceso, al mínimo escollo, podrían cancelarlo. La resistencia al cambio que podemos encontrar va a ser fuerte, por tanto, los empleados necesitan ver que la Dirección apoya y promueve este cambio.