¡Vendemos agujeros, no taladros!

Me encontré con una expresión interesante recientemente. Un vendedor de software estaba hablando de entregar toda la solución a su cliente. "No vendemos taladros. Vendemos agujeros", dijo. Es una gran analogía. Muchas personas (yo incluido) han ido a la tienda de hardware y ventana shopped en el departamento de herramientas eléctricas mientras se pregunta qué proyecto podría pensar que podría justificar la compra de esta gran herramienta de energía. Pero la aplicación de esta lógica tiene tanto sentido en el mundo del do-it-yourself como en los sistemas de software empresariales.

Si no tiene un problema, no necesita una solución.

Del mismo modo que nadie debería ir a buscar un simulacro a menos que el problema que les gustaría resolver sea hacer un agujero, nadie debería ir a buscar software empresarial a menos que resuelva algún problema. Ahora, si tiene un problema que solucionará la implementación de software empresarial, lo siguiente que debe asegurarse es que lo que está comprando proporcionará la solución que necesita. Eso suele ser mucho más que comprar el software.

La implementación de un sistema empresarial es un desafío complejo, por lo que la recompensa tiene que merecer la pena. En el mundo actual de los equipos de proyectos globales, una de las cosas más comunes que hay que hacer es dividir el tremendo esfuerzo de implementación de un sistema empresarial. Aunque esto nos puede dar economías de escala en el uso de equipos altamente entrenados en su aspecto del proyecto, también tiene el riesgo de pasar por alto aspectos del proyecto de maneras altamente arriesgadas. Este riesgo se agrava cuanto más física y organizativamente se desconectan los distintos equipos.

Echemos un vistazo a los elementos más comunes de un proyecto de sistemas empresariales.

¿Qué es una empresa?

En primer lugar, ¿a qué me refiero por empresa? Tomaré una definición que debería funcionar para casi todos. "Enterprise", en este contexto, significa cualquier proyecto que afectará al funcionamiento de toda la organización. Diré que esto es cierto para cualquier organización. Las implementaciones que califican como implementaciones empresariales no son solo el número de usuarios, sino la cantidad de impacto que tienen. Por lo tanto, la actualización de nuestro software de detección de virus del proveedor A al proveedor B probablemente no calificaría. La implementación del software de programación de proyectos en el escritorio para un grupo de usuarios probablemente no calificaría. Es probable que la centralización de la administración de proyectos y el uso de un sistema centralizado de administración de proyectos empresariales califiquen.

Bien, así que si se trata de un proyecto empresarial, ¿cuáles son los elementos más comunes de una implementación de un sistema empresarial? En nuestras oficinas, la experiencia más común es implementar sistemas de parte de horas empresariales, como nuestro propio TimeControl, o sistemas de administración de proyectos empresariales, como Microsoft Project Server, pero estos elementos serán comunes a casi cualquier implementación del sistema empresarial.

Bits y bytes

En primer lugar, vamos a abordar los bloques de creación de software más fundamentales: la arquitectura técnica. En estos días tenemos que dividir nuestro pensamiento en función de nuestra decisión de ir con una implementación local o una suscripción en la nube. Dejaré las maravillas de elegir cuál de estas condiciones es la mejor para otro día, pero estos son algunos de los conceptos básicos de lo que tendremos que pensar en cada categoría.

Si vamos con una instalación local, tenemos que pensar en qué hardware usaremos. ¿Cuáles son los requisitos de hardware para memoria y CPU? ¿Usaremos servidores físicos o servidores virtuales? ¿Usaremos servidores dedicados o compartidos? ¿Qué tipos de servidores pueden ser necesarios? ¿Necesitaremos servidores de aplicaciones, servidores de seguridad, servidores de servidores web? ¿Qué ocurre con el equilibrio de carga, la recuperación ante desastres y las copias de seguridad? ¿Necesitaremos servidores de copia de seguridad fríos o calientes? ¡Qué bien! ¡Pero no hemos terminado! ¿Y la base de datos? ¿Cuáles son los requisitos? ¿Qué tal la compatibilidad con nuestras arquitecturas de seguridad, aplicación y base de datos existentes? ¿Qué ocurre con la compatibilidad con exploradores, versiones de explorador y dispositivos móviles? Una vez que hayamos respondido a todas esas preguntas, tenemos que controlar los problemas de los entornos de instalación, prueba y producción y, después, el estado y la supervisión del sistema una vez que el sistema esté en funcionamiento.

Si vamos con una implementación de suscripción en la nube, todavía tenemos preguntas que responder, aunque pueden ser preguntas muy diferentes. ¿Qué servicio en línea usamos? ¿Vamos con una instalación dedicada o un servicio multiinquilino? ¿Y la seguridad? ¿Se puede integrar con nuestra propia autenticación? ¿Cómo se administra la recuperación ante desastres con el servicio de suscripción? ¿Dónde se encuentran físicamente los datos? ¿Esto presenta problemas legales para nosotros? ¿Qué tal la compatibilidad con nuestros exploradores internos y dispositivos móviles? ¿Cómo sacaremos nuestros datos y cómo podemos conectarnos con bases de datos internas u otros servicios SaaS externos (software como servicio) para integrar la funcionalidad?

¿Ya no respiraste? Cuando hablamos de un sistema empresarial, estas preguntas y mucho más están en el orden del día. Si trasladamos esta parte de nuestro proyecto a nuestro equipo técnico altamente entrenado, podrían empezar a pensar en esto como el ámbito de todo el proyecto, cuando esto es solo la construcción de nuestra perforación, no todavía la realización del agujero que necesitamos.

¡Configúreme!

Además de poner nuestro sistema en funcionamiento, también hay que aplicar la funcionalidad dentro de ese sistema a nuestros problemas específicos. He visto implementaciones de Project Server en las que el cliente pone en funcionamiento Project Server y, a continuación, se da cuenta de que no ha asignado fondos para crear flujos de trabajo, aprender a priorizar su cartera de proyectos o aprender a crear un único informe. Al igual que Systems Analysis 101 en la universidad, normalmente iniciamos esta parte de la implementación en el extremo derecho de una pizarra blanca, ya que preguntamos a los empresarios que tienen el problema empresarial real qué "salidas" necesitarán. He hablado de esto antes en otros escritos, así que no lo haré aquí, pero los resultados deberían ser finalmente decisiones empresariales. Para tomar esas decisiones, ¿qué informes, análisis y, en última instancia, entradas de datos necesito? Trabajamos desde el lado derecho de la pantalla a la izquierda y terminamos con una lista de todos los bloques de creación que necesitaremos en forma de elementos de datos, cálculos analíticos, exportaciones e informes que tendrán que configurarse en el sistema. Este ejercicio de configuración puede tardar semanas o meses en función de su complejidad.

A menudo, los tipos de recursos que necesitaremos para este aspecto del proyecto son una combinación de analista de negocios y experto en sistemas, y es común que, aunque estas personas puedan ser altamente especializadas en la funcionalidad del sistema que se implementa, no son tan expertos en la arquitectura técnica. Esto hace que tener equipos desconectados para dos elementos críticos del sistema sea bastante común. Cuanto menos se comuniquen estos dos grupos, más probable es que nos enfrentemos a desafíos más adelante.

Es un proceso

Es imposible implementar un nuevo sistema empresarial y no afectar a los procesos de la organización. Incluso si abandona un sistema empresarial centralizado y se mueve a su competidor, los procesos cambiarán. De hecho, si no desea que sus procesos cambien, es totalmente posible que no tenga un problema que necesite resolver, y aquí se encuentra otro desafío. Cuando cambia la rutina diaria de una persona, esto provoca molestias. No me refiero a alguna parte del tiempo. En mi experiencia, la molestia en este momento de cambio es un hecho. Esto es cierto incluso cuando el cambio del proceso dará lugar a un mejor proceso. Por lo tanto, pensar en cómo cambiarán los procesos y trabajar con aquellos que se verán afectados es fundamental para el éxito del proyecto. Sin embargo, los expertos que son fundamentales para diseñar este cambio en el proceso son probablemente las mismas personas que se verán afectadas por ese cambio, por lo que esto puede ser un aspecto desafiante de la implementación. Por lo general, un facilitador cualificado y experimentado trabajará con los expertos internos para guiar el cambio en el proceso que ha sido posible con la implementación del nuevo sistema. En nuestra línea de trabajo, vemos este desafío todo el tiempo. "Pero los administradores del proyecto tienen que hacer primero las aprobaciones del parte de horas", nos dice un nuevo cliente de TimeControl. "Ese es nuestro proceso". Cuando se explica que las aprobaciones de matriz pueden permitir a los administradores de proyectos realizar sus aprobaciones de parte de horas como parte de un proceso más grande y eficaz, nos molestamos; Retroceso. En este punto, tenemos uno de nuestros empleados más experimentados trabajando con las personas afectadas para asegurarse de que sus preocupaciones se atienden, y que son una parte integral de cómo cambiará el proceso.

Por lo tanto, es probable que los usuarios del proceso no sean los usuarios de configuración o los técnicos, pero si no tenemos este equipo planeado, es probable que todo nuestro trabajo duro en la instalación y configuración no se vaya a implementar. Este equipo también debe formar parte de nuestra planificación, incluida en las comunicaciones y decisiones tomadas por los otros dos equipos.

Formación

"Por lo tanto, ¿necesitaremos entrenamiento?" es, por desgracia, una pregunta que a menudo se hace por última vez. Algunos entrenamientos pueden pasar por los cambios de proceso, ya que esa parte del proyecto requiere una gran cantidad de discusión práctica, pero ¿qué ocurre con la guía real del usuario de cómo funcionará el nuevo sistema de forma más paso a paso? En un momento dado, se consideraba que el entrenamiento era un elemento crítico de las implementaciones de software y se esperaba que los clientes dejara a un lado aproximadamente el 20 % del presupuesto total en él. Pero, con los cambios en los costos de software y la velocidad de instalación, poco a poco ese 20% se convirtió en menos y menos dinero. Si pagamos $20 al mes por usuario por un sistema, ¿debo dejar de lado $4 por usuario para el entrenamiento? No puedo prometer que no irá demasiado lejos. Hay muchas opciones de suscripción en línea para el entrenamiento, pero ninguna de ellas tendrá en cuenta la solución exacta que ha diseñado.

Los instructores pueden provenir del exterior o pueden proceder de las partes de configuración o proceso del proyecto, pero a menudo son personas que son especialistas en lugar de las personas que realmente realizaron el trabajo de implementación. Por lo tanto, incluso si ha reservado fondos para este equipo (y espero que lo haya hecho), todavía tiene que asegurarse de que estas personas sepan en qué sistema están entrenando a la gente está realmente diseñado para hacer. He visto que los instructores llegan a Microsoft Project Server y les han hecho empezar a explicar a los usuarios cómo configurar los campos empresariales y configurar los impulsores empresariales en el análisis de cartera, solo para que los usuarios tengan una mirada en blanco porque sus campos empresariales ya estaban configurados y no van a usar el análisis de cartera en su lanzamiento inicial. ¿Sus instructores saben incluso el problema que se supone que debe resolver esta implementación en particular? Deberían. Pensar en el entrenamiento al principio del proyecto le da la mayor oportunidad de éxito. Los equipos técnicos, de configuración y de proceso pueden dejar de lado los datos críticos a través de sus secciones para el entrenamiento que se entregará en última instancia. Eso significa involucrar al equipo de entrenamiento temprano.

Implementación, aceptación o cambio de referencia cultural

Si estaba pensando y dejando de lado los recursos para iniciar estos equipos y todos ellos han trabajado y se comunican juntos a través del proyecto, es probable que el lanzamiento de su nuevo sistema sea mucho más suave de lo que podría ser de lo contrario, pero no subestime la resistencia al cambio de cultura. Tener evangelistas clave disponibles en el momento adecuado puede ser fundamental. Además, ¿todos estos miembros del equipo se empaquetarán y pasarán a su próximo proyecto? Habrá una gran cantidad de conocimientos del sistema envueltos en estas personas en el momento en que se implemente el proyecto. Me impresionó especialmente uno de nuestros clientes a principios del año pasado. Era el departamento de TI una gran organización financiera. Una de las preocupaciones que mostramos al usuario técnico clave que estaba evaluando el software al principio del proyecto fue "¿quién será el administrador una vez que encapsule el proyecto?". "Lo haré", dijo. Era fiel a su palabra. Sus habilidades y conocimientos evolucionaron a través de la implementación de varios meses, lo que fue un gran éxito, y sigue siendo el administrador clave.

Envolver

Hay otros cientos de cosas en las que pensar en cómo asegurarse de que los equipos se comunican y trabajan como parte de un objetivo mayor, y solo hemos hablado de unos pocos. Esperemos que esto le haga pensar ya en la próxima implementación del sistema empresarial. "¿Qué hay de la documentación?", podría estar pensando. "¿Qué pasa con el soporte técnico?"

Lo importante que hay que recordar es esto: al planear una implementación de sistema empresarial, tiene que ampliar la perspectiva para incluir no solo el esfuerzo de instalación, sino también la entrega de la solución completada. Asegúrese de que el agujero aparece justo donde debería en el tamaño correcto, la profundidad derecha y el ángulo derecho.

Acerca del autor

Chris Vandersluis es el presidente y fundador de Montreal, HMS Software, un asociado certificado de Microsoft con sede en Canadá. Tiene una licenciatura en economía de la Universidad McGill y más de 30 años de experiencia en la automatización de sistemas de control de proyectos. Es un miembro de larga data del Project Management Institute (PMI) y ayudó a encontrar los capítulos de Montreal, Toronto y Quebec del Grupo de Usuarios de Microsoft Project (MPUG). Entre las publicaciones para las que Chris ha escrito se incluyen Fortune, Heavy Construction News, la revista Computing Canada y PMNetwork de PMI, y es columnista regular de Project Times. Enseña administración avanzada de proyectos en la Universidad McGill y a menudo habla en las funciones de asociación de administración de proyectos en Norteamérica y en todo el mundo. HMS Software es el editor del sistema de mantenimiento de tiempo orientado al proyecto TimeControl y ha sido asociado de soluciones de Microsoft Project desde 1995.

Chris Vandersluis puede ser contactado por correo electrónico en: chris.vandersluis@hms.ca

Si desea leer más artículos relacionados con EPM de Chris Vandersluis, consulte el sitio de orientación de EPM de HMS (https://www.epmguidance.com/?page_id=39).