Tabla de Contenidos

Los proyectos generalmente pueden fracasar por multitud de factores, y los de Office 365 no son una excepción.
A veces, la parte técnica del proyecto se desarrolla a la perfección, y sin embargo el proyecto ser un fracaso.

 

¿Por qué?

 

Intentaremos ver en este post los problemas principales a los que nos enfrentamos.

 

En nuestra experiencia estos son los principales motivos:

 

No conocer bien las fortalezas y debilidades del producto

Estamos saturados de información sobre las bondades de la nube, y cómo aporta muchas ventajas a las empresas. Siendo eso cierto, se presta poca atención a las limitaciones que tiene un modelo en el que trabajamos sobre recursos compartidos con otros clientes y que por tanto nos ofrece un grado de libertad menor que si fuera nuestra propia infraestructura. También asumimos que podemos trasladar nuestro conocimiento de los productos “en local” a la nube.
Al fin y al cabo, Exchange Online será como mi Exchange actual, ¿no?

 

Pues no.

 

Pensamos que la plataforma se va a comportar de una manera cuando lo cierto es que tiene condiciones y limitaciones muy claramente detalladas. Suelen afectar sólo a una minoría de clientes con necesidades muy concretas, pero ahí están, esperando a que estemos en mitad del proyecto para dar la cara.

 

Por ejemplo, ¿qué pasa si el cliente necesita poder enviar adjuntos de tamaño superior a lo permitido por Office 365, o por temas legales necesita tener un backup anual del correo de los últimos cinco años?

 

En el mejor de los casos, tendrá que recurrir a sistemas de terceros que encarecerán la solución. En el peor, no podrá hacerse.

 

El mejor remedio para evitar estos problemas es revisar detalladamente la documentación de Microsoft al respecto, para asegurarnos que lo que estamos adquiriendo se ajusta a nuestras necesidades.

 

No haber valorado en detalle los requisitos y la infraestructura necesaria

Otro problema habitual es no revisar exhaustivamente los requisitos para que todo funcione perfectamente con Office 365. El caso más típico es el un ancho de banda insuficiente, asumiendo que hay de sobra sin tener en cuenta los nuevos patrones de consumo que imponen mover la carga del correo a la nube o las videoconferencias online.

 

Otros casos típicos son versiones de Office incompatibles, limitaciones de sistema operativo, de navegador, de plugins de Outlook, de dispositivos móviles… Además, siempre es recomendable evitar quedarnos en el límite de lo soportado por Microsoft.

 

Por ejemplo, usar Office 2007 contra el Office 365 actual es muy poco recomendable. En nuestra experiencia, no siempre lo soportado funciona bien, y el soporte ofrecido en estas versiones suele ser muy limitado y con letra pequeña.

 

Otro ejemplo es querer tener sincronización de directorios y no tener ni hardware ni licencias previstas para el servidor que se encargará de esa función.

 

Para evitar esto, es fundamental que en el proyecto hayamos tenido en cuenta todos los factores, y no asumir que algo funcionará a menos que podamos confirmarlo. Si estamos contratando el proyecto externamente, recomendamos rechazar toda oferta en la que no se especifique todo esto.

 

No tener bien documentada la infraestructura actual

Es muy habitual encontrarse sorpresas en mitad de migración:

 

(Antes de empezar el proyecto)
– ¿Tenéis aplicaciones o dispositivos que envíen correo a través del servidor actual?
– No. Ninguna, confirmado.

 

(dos meses después)
– ¡Emergencia! Cuando habéis desconectado el Exchange antiguo, resulta que ha dejado de funcionar la aplicación de pedidos, que es crítica. Parece que sí, que al final el departamento de desarrollo nos dice que usaba el Exchange. ¡Pronto, haced algo, que cada minuto que no funciona perdemos dinero y me juego el puesto!

 

Preguntar mucho nos va a hacer poco populares en el cliente si somos una empresa externa, porque le estamos obligando a un trabajo importante de recopilación de información. Y a veces incluso te pueden decir que “ninguna de las otras empresas a las que les hemos pedido oferta nos ha pedido esos datos”.

 

Pero nosotros no somos “otras empresas” y queremos que nuestro proyecto salga bien, ¿no? Insistid, que el cliente al final os lo agradecerá.

 

Y si sois el propio cliente que está pidiendo oferta para proyectos de migración, desconfiad de quienes no pregunten mucho.

 

Así pues, para evitar sorpresas es imprescindible tener perfectamente documentado el entorno de origen.

 

No tener en cuenta los costes de migración

Éste es otro de los clásicos. El mensaje comercial se centra en lo barato que es Office 365 para las grandes funcionalidades que te ofrece. Pero no se suele mencionar que para llegar a ese nirvana nebuloso necesitamos hacer un proyecto de migración, más o menos complejo, que alguien tiene que hacer.

 

En los casos más sencillos podemos optar por hacerlo nosotros mismos, y esperamos que futuras entradas en este blog sirvan como introducción al proceso. Pero en casos complejos tendremos que contar con especialistas para que todo vaya sobre ruedas y que impactemos al servicio lo menos posible.

 

Al fin y al cabo, el correo electrónico es de las cosas más críticas para cualquier empresa.

 

Microsoft lleva tiempo haciendo un esfuerzo para solventar este obstáculo.

 

Por un lado, ha puesto en marcha metodologías de “autoservicio”, dando al cliente guías y algo de ayuda para que lo haga él mismo. Por otro, para escenarios más grandes se ofrece a financiar el proceso de migración, pagándole al partner por sus servicios.

 

La primera de estas opciones es de utilidad algo dudosa, pues gran parte de la documentación y ayuda que se da al cliente está en inglés.
La segunda es imposible de rechazar, ya que nos permite contar con ayuda experta sin coste para nosotros, por lo que si está en vigor debemos solicitar esa promoción de inmediato.

Consulta aquí todos los detalles del programa Fastrack de Microsoft para Office 365.

 

No tener en cuenta la resistencia al cambio de los usuarios

Como ocurrió en Vietnam, puede darse el caso de que “ganemos las batallas y perdamos la guerra”.

 

El proyecto puede haberse desarrollado sin incidentes, pero meses después de terminarlo vemos que el cliente no utiliza prácticamente la funcionalidad de Office 365 y sigue usando las herramientas que tenía del mismo modo de siempre.

 

“No tengo tiempo de ponerme a aprender otra cosa, tengo que producir” es una frase muy escuchada entre los usuarios.

 

¿Qué ha pasado?

 

Pues que probablemente hemos planteado el proyecto sin implicar al usuario desde el principio. Seguramente tampoco habremos previsto que a los usuarios les gusta muy poco cambiar, y que el rechazo a lo nuevo siempre está ahí. Y no hemos pensado que para nosotros puede ser muy fácil usar las nuevas herramientas porque somos tecnólogos, pero el usuario necesitará formación y apoyo constante.

 

Es naturaleza humana resistirse a los cambios.

 

¿Por qué debe el usuario aprender a hacer una conferencia con Skype for Business en vez de usar el teléfono como siempre? ¿Qué hay de malo en enviar correos arriba y abajo con los documentos adjuntos para su revisión? ¿Por qué es mejor que guarde sus documentos en Onedrive for Business que en el escritorio, como ha hecho siempre?
Mientras no le convenzamos de lo contrario, seguirá haciendo lo de siempre.

 

Y de poco sirve en la práctica imponer desde arriba una forma de trabajar.

 

Al usuario hay que hacerle partícipe desde el principio, implicarlo en la toma de decisiones de cómo se quiere usar el producto en la empresa para que vea por sí mismo la utilidad y pueda “evangelizar” al resto de los usuarios.

 

Por volver al ejemplo de Vietnam, hay que ganarse “los corazones y las mentes” de los usuarios para que el proyecto sea un éxito.

 

No haber valorado correctamente las implicaciones en la política de renovación tecnológica de la empresa

Esto suele dar la cara pasado un tiempo. Termina el proyecto, todo bien, y el cliente te llama ocho o diez meses después y te pregunta que cómo es eso de que sus equipos con XP, o sus Office, ya no valen y que tiene que actualizarlos si quiere seguir trabajando con Office 365.

 

Seguramente ya no recordará que le advertiste de eso antes de comenzar el proyecto.

 

Porque lo hiciste, ¿verdad?

 

A la hora de subirse al carro del O365 es imprescindible tener claro y dejar claro que te suscribes a una plataforma que está en continua innovación. Con cada nueva revisión al servicio, se irán añadiendo funcionalidades que puede que no sean compatibles con software más antiguo, por lo que tendrás que actualizar tarde o temprano. No puedes controlar el ritmo.

 

Si nuestra empresa tiene la política de sólo actualizar los sistemas cuando no queda más remedio, quizás Office 365 no sea la plataforma adecuada para nosotros, porque seguramente nos va a obligar a movernos más rápido de lo acostumbrado.

 

Además, la opción de dar marcha atrás o irse a otro proveedor no suele ser viable, porque suele ser compleja y tener costes de (des)migración asociados.

 

Recapitulando, acabamos de ver seis de los motivos principales por los que hemos visto naufragar proyectos de Office 365 del mundo real. Conviene que los tengamos presente mientras continuamos la lectura.

 

De esta forma, seamos un cliente final o una empresa consultora, tendremos claras las implicaciones de un proyecto de migración y conseguiremos que nuestros proyectos se lleven a cabo sin sobresaltos y a plena satisfacción de todos los implicados.