dijous, 9 de desembre de 2010

Com migrar de MSOffice a OpenOffice.org

La utilització de programari lliure proporciona avantatges evidents. Sens dubte que la més llaminera és la de no haver de pagar per obtenir les llicències per ús.

Parlo de llicències d’ús i no de preu de les aplicacions perquè, de fet, no es compren les aplicacions, sinó llicències per a fer-les servir.

Les llicències d’ús no són pas pocs diners. És un esforç que cal amortitzar. Això porta a que quan es fa una despesa en ofimática, o en aplicacions informàtiques en general, aquell software haurà de ser utilitzat durant un periode de temps prou gran que, al menys, permeti considerar que ha retornat la inversió.

N’hi ha prou amb fer la despesa inicial? No. És necessari un manteniment. En el millor dels casos, amb la llicència també s’obté el dret a actualitzacions automàtiques.

Ara bé, el mecanisme d’actualitzacions automàtiques pot no estar sempre present. Pot ser també que la llicència d’ús adquirida no es correspongui amb la utilització que es doni a l’aplicació i que, per tant, no es pugui actualitzar tot el programari. En el límit, es pot estar usant l’aplicació sense llicència; pot ser també que el suport a l’aplicació quedi discontinuat. En definitiva, no és impensable que abans d’hora calgui fer una despesa adicional per a obtenir llicències per a una nova versió i per al seu manteniment.

El programari lliure senzillament no pateix la servitud de les llicències. En patirà d’altres, per descomptat, i potser la més greu és la dificultat de trobar bons serveis tècnics de manteniment especialitzats en el programari lliure. Tanmateix, aquesta dificultat també es dona amb el programari privatiu.

Una aposta empresarial intel·ligent és la de tractar de reduir la despesa en llicències i manteniment, pel que té de despesa fixa, però també pel risc que representa de despesa imprevista davant la necessitat de renovar el programari instal·lat.

Aquesta aposta implicarà en la majoria d’ocasions una migració. De forma general será migrar des d’una plataforma o des d’aplicacions de pagament a una plataforma o aplicacions de programari lliure.

Aquesta migració total o parcial del sistema d’informació corporatiu és un projecte estratègic en si mateix, i crític degut a que representa canvis en les eines que processen els fluxos de treball i de documents. És necessari garantir que aquests fluxos, si més no, es mantenen i, opcionalment, s'optimitzen. Cal preparar els usuaris per a les noves eines. Cal adaptar la documentació existent als nous formats o assegurar que els formats existents són reconeguts i són útils amb el nou programari.

La migració completa del sistema d’informació corporatiu a programari lliure es pot plantejar com un projecte per fases. Un enfocament posible és plantejar projectes de migració específics per als diferents servidors i aplicacions corporatius: d’intranet, de base de dades, d’ERP, de CRM, d’Intel·ligència de Negoci. I també dels clients d’aquests servidors: l’escriptori dels usuaris, o l’ofimàtica corporativa.

Em concentraré en aquest últim punt: la migració de l’ofimàtica corporativa.

L’ofimàtica corporativa basada en programari lliure té un nom estrella: OpenOffice.org (en endavant OOo). Al seu torn, l’ofimàtica corporativa de pagament té un nom indiscutible: Microsoft Office (en endavant MSO).

Hi han altres opcions d’ofimàtica lliure, en escriptoris Linux basats en KDE es pot trobar el KOffice. En escriptoris del tipus Gnome, es diposa del Gnome Office que és un mix de diverses aplicacions com Abiword (processador de textos), GNUMeric (full de càlcul), Thunderbird (client de correu)…

Però OOo és una opció molt interessant perquè és una suite ofimática completa que és disponible tant en plataformes Windows com en Linux. La migració de MSO a OOo és posible, doncs, sense necessitat de canviar de sistema operatiu. La tria de OOo permet fer un canvi gradual i introduir el programari lliure en un lloc tan visible, i a l’hora, tan crític, com és l’escriptori dels usuaris. La introducció del programari i formats lliures en l’escriptori facilitaran el canvi a la implantació de sistemes operatius lliures en els clients.

L’escenari que es planteja és, doncs la migració de l’ofimàtica del client de MSO a OOo.

Sun (actualment propietat d’Oracle) ha elaborat diversos White Papers (en endavant WP) en el que proposa una metodologia i diferents escenaris per a projectes de migració de MSO a OOo (o a Oracle OpenOffice, l'antic StarOffice, la versió de pagamanet d’OOo propietat de Sun; i cal pensar que el model que plantegen també servirá per al IBM Lotus Symphony, la suite ofimática basada en l’OOo realitzada per IBM i que recupera el nom d’una suite ofimàtica per MSDOS que va ser  popular als 80).

A continuació em referiré a la metodología descrita en aquests WP.

Com ja he dit abans, l’ofimàtica de l’usuari és una part fonamental i integrada en els fluxos de treball corporatius de cada dia de la majoria dels treballadors. Per tant, és crític planificar i executar la migració de forma rigurosa.

El WP de SUN proposa sis fases per a la migració:

1. Implementació d’una fase pilot

2. Elaboració d’un catàleg de les eines i solucions que depenen del MSO

3. Identificació dels documents i les macros d'MSO que s’estiguin utilitzant

4. Organització de l’equip de migració

5. Conversió de macros, plantilles i documents crítics dels fluxos de treball

6. Formació i suport post-migració


1. Implementació d’una fase pilot

L’objectiu d’aquesta fase és identificar els problemes que podrien afectar a la migració i que es comprenen els fluxos de treball i els intercanvis de documents.

Per a aquesta fase és necessària la participación d’empleats que siguin representatius funcionalment, amb la preparació adequada per a les tasques i que permetin abastar la major part o, millor, a tots els fluxos de treball.

Aquests usuaris hauran de tenir formació en l’OpenOffice.org o, si més no, disposar del suport de companys formats o d’un helpdesk.

Pot ser interessant comptar amb la col·laboració estratégica d’un “Migration Partner” per a prestar aquest support.

El HelpDesk haurà de prestar suport en qüestions del tipus “Com es fa?”. Cal reportar el errors i els problemes per a poder analitzar-los posteriorment.

Una segona aproximació és prestar aquest suport via correu electrònic.

Per a grans corporacions es pot aprofitar el pilot per a implementar una eina de gestió de HelpDesk, obviament de programari lliure i, preferiblement, amb interfase web, de forma que els mateixos usuaris puguin crear des dels seus navegadors els tickets de les incidències. Aquesta mena d’eines permeten fer un seguiment de la resolució de les incidències trobades i se’n poden obtenir informes i estadístiques.

2. Elaboració d’un catàleg de les eines i solucions que depenen del MSO
Hi han diversos tipus d'aplicacions ERP, CRM i d'altres que depenen o proporcionen interfícies amb l'MSO. Aquestes aplicacions han de ser identificades aviat perquè cal preveure que serà on caldrà posar més esforç per a fer-les treballar amb l'OpenOffice.org.

Els caps d'equip i els gestors de la informàtica corporativa necessiten disposar d'aquesta informació, per tant, és una bona idea demanar-se-la mitjançant qüestionaris. Els qüestionaris poden proporcionar una bona explicació sobre com estan interaccionant aquestes aplicacions personalitzades amb l'MSO.

3. Identificació dels documents i les macros d'MSO que s’estiguin utilitzant
Cal demanar als usuaris que, per una banda, identifiquin els arxius que són importants per al seu treball i, per l'altra, que identifiquin els arxius que ja no es fan servir.

Cal assegurar que tothom fa servir els mateixos criteris per distingir el que es fa servir del que no es fa servir, per això caldrà proporcionar aquests criteris als usuaris:

Arxius que es fan servir: són aquells documents o plantilles que es modifiquen o s'apliquen almenys un cop al mes.
Arxius que no es fan servir: els arxius, documents o plantilles que no es fan servir aleshores es poden classificar com arxivat definitiu, que serien tots aquells que ni es fan servir ni es faran servir en el futur; o com històric que serien aquells fitxers que ocasionalment es poden haver d'imprimir o consultar.
Una solució per a aquests fitxers és algun sistema d'emmagatzematge massiu extern (per distingir-lo de l'emmagatzematge online que seria tenir-los al disc dur.) com podria ser DVD. També es pot plantejar una sol·lució d'escanejat a PDF per a poder-los guardar en un format accessible en el futur.

Els documents que més probablement caldrà arxivar seran la correspondència, factures, calendaris i planificacions, informes de diferents tipus i documents legals. Els documents que tinguin validesa legal no han de ser convertits, doncs, en principi, perdrien la seva validesa si es canvia el seu format.
En l'emmagatzematge de la informació històrica, si s'escau caldrà tenir en compte a Llei Orgànica de Protecció de Dades (LORTAD) .

A més caldrà identificar aquells arxius que es comparteixen entre departaments dins de l'empresa o amb empreses externes que també facin servir l'MSO. Els fitxers compartits que incloguin macros hauran de ser rigorosament monitoritzats per tal de controlar-ne els canvis  que pateixin a mida que es van movent entre  els diferents ambients del negoci.

4. Organització de l’equip de migració
La dimensió i perfils de l'equip de migració variaran depenent de la mida i estructura de l'organització a migrar. El rol principal és el del gestor de projecte, que preferiblement hauria de ser un perfil sènior del departament d'informàtica.

El gestor de projecte ha de preveure l'entorn post-migració, incloent les adaptacions que calguin per a estabilitzar el funcionament global, tenint en compte  als objectius de la corporació, les necessitats dels empleats i la disponibilitat de recursos.

La substitució de  l'MSO per l'OOo no és directa, perquè es tracta d'eines diferents. Cal preveure que hi hauran fluxos de treball que caldrà modificar, compensar o adaptar a la nova eina.
El gestor de projecte també determinarà l'abast de la migració a partir de la informació sobre els entorns i els documents  recopilada pel seu equip.

A partir d'aquesta informació, el gestor de projecte determinarà un marc temporal (una planificació d'alt nivell) per a la conversió dels documents i solucions personalitzades i una data límit de finalització de l'utilització de l'MSO en la companyia.

L'equip de migració podria incloure també administradors de sistemes i altres personal com facilitadors, desenvolupadors o administratius.

Els administradors de sistemes haurien de ser els responsables de configurar i fer el manteniment dels esquemes  de configuració de l'OOo en l'escenari post-migració.

Els tècnics informàtics, adequadament formats, serien els responsables de prestar el suport als usuaris després de la migració. És importants, doncs caldrà prestar algun suport als usuaris per a que esdevinguin productius ràpidament.

Els caps de projecte hauran de gestionar les tasques de migració en els nivells de departaments corporatius. Aquestes tasques de migració inclouen la documentació dels sistemes informàtics departamentals, la identificació de l'efecte de la migració en els workflows d'usuari i de negoci, com impacta la migració en arxius  i en dades, i la comunicació i coordinació amb les diferents parts interessades en el procés de migració.

5. Conversió de macros, plantilles i documents crítics dels fluxos de treball
La forma més senzilla de convertir els fitxers Word, Excel i PowerPoint a fitxers en format OpenDocument és fer servir el mateix OOo per obrir-los i desar-los en el nou format.

Una opció és desenvolupar macros que facin això mateix: obrir (importar) successivament els fitxers d'una carpeta i anar-los desant en el format OpenDocumet corresponent.

Per descomptat que s'imposa una revisió manual per part dels propietaris dels fitxers per tal de verificar-ne la validesa de la transformació.

Les macros de MSO no es poden executar directament en OOo perquè els models d'objectes dels documents són del tot diferents. Cal preveure, doncs una tasca de transformació manual de les macros.
Aquesta tasca pot ser una bona oportunitat per a millorar l'eficiència dels processos que les involucren. POt ser un bon moment per a determinar, per exemple, quines són les macros que encara són necessàries i descartar-ne les que ja no ho siguin. També pot ser el moment per a fer una re-enginyeria de les macros existents per a reconvertir-les en objectes de negoci Java o C++ implementats com components UNO (Universal Network Objects, la tecnologia de components subjacent a OOo). Els nous components seran més eficients que les macros en Visual Basic.

Una altre aproximació possible seria reconvertir-les per usar aplicacions basades en web i en java de servidor. Els components de servidor proporcionaran més seguretat en temps d'execució i millor gestió d'errors que les corresponents macros originals en Visual Basic.

6. Formació i suport post-migració
Els usuaris es trobaran amb una experiència d'usuari diferent a la que estaven acostumats. Trobaran els documents transformats i macros diferents. Per tot això, el pla de migració necessàriament a d'incloure un període de formació que ajudi als usuaris a sentir-se còmodes amb la seva nova suite ofimàtica.
Per exemple, es podria mostrar als usuaris la forma de solucionar problemes típics després d'haver convertit un document al nou format OpenDocument.

La formació ha de familiaritzar als usuaris amb la nova interfície d'usuari  i  seran capaços de dominar ràpidament  la seva nova eina.

per tal de minimitzar el nombre peticions de suport i maximitzar la productivitat des d'un bon començament, és recomanable preparar un "Welcome Pack" pels usuaris amb informació sobre el nou entorn d'escriptori. Aquest "Welcome Pack" podria incloure una guia ràpida d'usuari que destaqui les semblances i les diferències entre MSO i OOo. També es podria incloure un manual de programació del llenguatge Basic de l'OpenOffice.org que estaria destinat als usuaris que vulguin crear les seves pròpies macros.

A més, pot ser adequat fer una formació de més alt nivell per a usuaris avançats.

De cara facilitar aquesta etapa de la migració caldria determinar prèviament el nivell dels usuaris (basic, mig,  avançat...)  aleshores es pot  fer una llista dels empleats amb més nivell que poden prestar suport als usuaris menys avançats que requereixin suport.

Finalment, una darrera opció és fer una formació online. La formació online, amb una etapa tutoritzada i suport per xat, pot significar una reducció del cost de formació al no requerir desplaçaments de persones ni sales de formació condicionades i és més flexible per a l'usuari que pot realitzar els cursos en els horaris que més li convinguin.



Migració de solucions basades en MSO
Una suite ofimàtica sovint agrega informació provinent de fons diverses. Aquestes fonts són, en la majoria d'ocasions,  altres aplicacions que proporcionen dades que s'afegeixen als documents. MSO proporciona un conjunt de protocols de comunicació per al diàleg amb aquestes aplicacions externes. OOo, per la seva banda, suporta aquests  protocols de comunicació, però la diferència entre els models d'objectes de documentes de MSO i OOo fan que la comunicació entre OOo i les aplicacions externes, a priori, no sigui compatible amb la de MSO.

El primer pas és determinar com les diferents aplicacions externes intercanvien la informació amb MSO. Hi han tres mètodes principals:

El més senzill, fent servir fitxers i documents. Aquesta solució crea documents o fitxers de MSO que poden ser carregats per l'MSO. En principi, això ha de continuar funcionant correctament un cop migrat a OOo, perquè OOo és capaç d'importar els formats de MSO.

El segon mètode és fer servir el porta papers per a intercanviar informació entre l'aplicació externa i MSO. Aquesta opció també hauria de funcionar correctament amb l'OOo.

El tercer mètode és quan l'aplicació externa invoca directament el model d'objectes de l'OpenOffice (el mecanisme d'automatització de MSO). Això ni funciona amb OOo.

Tanmateix encara es pot fer alguna cosa. Cal distingir entre interfases fetes a ma entre les aplicacions externes i l'MSO i les aplicacions que "out of the box" ja proporcionen la interfase amb MSO.

En el cas de les aplicacions amb interfase MSO "out of the box" les opcions de migració depenen de la compatibilitat de la solució amb OOo.

En cas de no disposar d'aquesta compatibilitat cal considerar la realització d'un desenvolupament a mida. Ara bé, és millor no reinventar la roda:

Primer de tot, cal demanar al proveïdor de l'aplicació si tenen prevista una versió compatible amb OOo, o si en podria desenvolupar una per al nostre cas. Suposant que el proveïdor ens respon afirmativament a alguna de les qüestions, cal preveure que la versió compatible no serà immediata i que caldrà proporcionar una solució de contingència: per exemple, pot caldre disposar d'una o més instàncies de MSO fins que la versió compatible amb OOo estigui disponible.

Pot resultar que el proveidor no estigui disposat a col·laborar i aleshores serà necessari trobar solucions alternatives. Les solucions alternatives  podrien ser desenvolupar una solució  a mida des de zero, o canviar l'aplicació externa per una de competidora que sí que sigui compatible amb OOo.


Migració de bases de dades Access
OOo Base és l'aplicació de base de dades de la suite ofimàtica OOo . OOoBase proporciona assistents per a la creació de taules, consultes, formularis i informes.
BAse treballa amb un motor java de base de dades del tipys HyperSonic DataBase Engine, ara bé, OOoBase és capaç de llegir i escriure dades des de MySQL, base de dades JDBC, connexions ODBC (a UNIX també fent servir ODBCUnix), MSAccess, fitxers de text csv, llegeix fulls de càlcul excel, dBase...)
Ara bé, OOo Base no és capaç de reconèixer  els formularis, informes i consultes de MSAccess.
La migració d'aplicacions basades en formularis, informes i consultes de MSAccess és també un bon moment per a la reenginyeria  i decidir si es migra cap a una solució basada en OOoBase i components UNO, o bé si es marxa cap a una solució basada en web.


Migració de l'Outlook
OOo reconeix l'Outlook com a client de correu per defecte. En general, per tant, no caldrà migrar de client de correu. Tanmateix pot ser interessant migrar d'Outlook a un altre client de correu basat en programari lliure perquè, per exemple, es vol canviar el  sistema operatiu d'escriptori de Windows a Linux. I no es disposa d'Outlook a Linux.

En aquest cas, una bona opció es migrar a Mozilla Thunderbird. Mozilla Thunderbird és el client de correu de programari lliure més popular i està basat en el mateix framework del navegador Firefox. Existeixen versions en plataformes Windows i Linux i està disponible en molts llenguatges, en particular, també en català.

Thunderbird diposa d'un assistent d'importació de comptes des d'outlook express que pot fer senzilla la migració. Migrar Thunderbird de Windows a Linux és tan senzill com copiar la carpeta de configuració de l'usuari, que conté les definicions dels comptes, les carpetes i  las mailboxes amb els correus enviats i rebuts.

Finalment, Mozilla Lightning és una extensió de Mozilla Thunderbird que li afegeix calendari amb vista diària, setmanal i mensual. Lightning també és programari lliure.

Cap comentari:

Publica un comentari a l'entrada