Los retos de seleccionar software empresarial: notas del producto

Estas notas del producto forman parte de nuestra colección "Desde las trincheras". En ellas se describe cómo tienen que poder adaptarse y evolucionar las implementaciones del sistema empresarial para tener éxito.

Para descargar la versión de Word de estas notas del producto, consulte Retos de la selección del software empresarial.

Para ver más notas del producto, consulte las notas del producto "Desde las trincheras".

Retos de la selección del software empresarial

Ocurre en todo momento. Un cliente envía una "Solicitud de propuesta" (RFP) a la oficina con instrucciones para completar una respuesta en unos días o semanas y enviarla de vuelta para que nuestro sistema empresarial considere su compra. Casi todas las RFP tiene el mismo aspecto. Por lo general, hay una breve introducción, instrucciones de lo que hay que hacer para que se considere su respuesta, incluido cuál tiene que ser su formato y cuándo enviarla, etc. Luego hay una larga cuadrícula de características obligatorias y varias preguntas de ensayo adicionales donde escribir respuestas.

El reto con las RFP es que no estaban adaptadas idealmente para seleccionar software empresarial y lo que se produce cuando se sigue un proceso de RFP no garantiza las mejores decisiones para la organización. La comunidad de compras diseñó las RFP como una manera de obtener los mejores productos al mejor precio y todavía desempeñan un gran papel. Cuando las ofertas son comparables, los procesos de toma de decisiones pueden centrarse en el mejor precio con tan solo enfrentar una o dos variables adicionales (como las fechas de envío). Cuando las posibles soluciones están en la misma categoría general, pero no son comparables en absoluto (como es el caso del software empresarial), el número de variables que deben considerar los compradores es enorme y el proceso de RFP no agrega valor a la selección. Cómo seleccionan la mayoría de las empresas el software empresarial. Empezaremos observando el proceso que ocurre en todo momento en cualquier proveedor o proveedor de soluciones de software empresarial. Hablaré sobre el software de administración de proyectos empresarial o el software de partes de horas empresarial que es lo que mi empresa proporciona, pero el paradigma es el mismo para prácticamente cualquier sistema de selección empresarial.

Cómo seleccionan la mayoría de las empresas el software empresarial

Empezaremos observando el proceso que ocurre en todo momento en cualquier proveedor o proveedor de soluciones de software empresarial. Hablaré sobre el software de administración de proyectos empresarial o el software de partes de horas empresarial que es lo que mi empresa proporciona, pero el paradigma es el mismo para prácticamente cualquier sistema de selección empresarial.

En la mayoría de organizaciones, el impulso de buscar software empresarial viene de algún problema. Quizás el personal de campo es el que expone el problema. Tal vez, alguien de la administración sénior es quien identifica el problema. Cuando esto ocurre, la iniciativa debe obtener el soporte técnico de alguien perteneciente a la administración sénior. La selección de un sistema base que afectará a toda la empresa es una fantasía incluso en las organizaciones más progresivas. Por eso, un administrador sénior decide, "necesitamos este tipo de sistema de empresa".

El proceso de selección típico del software empresarial es el siguiente:

  1. La administración declara que necesitamos un nuevo sistema empresarial

  2. Se selecciona al gestor del proyecto

  3. Solicitar peticiones de todos los departamentos implicados

  4. Combinar todas las solicitudes en una gran hoja de cálculo

  5. Enviar la cuadrícula de requisitos a un buen número de proveedores

  6. Obtener una gran cantidad de respuestas

  7. Lista corta

  8. Ver demostraciones

  9. Negociar

  10. Obtener la aceptación de administración

  11. Hacer que la administración decidida alguna otra cosa

Un gestor de proyectos se ofrece voluntario para realizar la selección. Él o ella hace lo que todos nosotros: va a Internet, carga un motor de búsqueda y escribe "Software EPM" (o cualquier otro sistema empresarial deseado). Inmediatamente aparecen medio millón de entradas. Quizás, el diligente gestor de proyectos navegue por la primera docena de opciones para saber qué tipo de sistemas podría estar disponible antes de continuar. Está claro que nadie tiene tiempo para navegar a través de medio millón o más de entradas para comprobar si, quizás la última, es el sistema ideal para la organización.

Sin desanimarse, el gestor del proyecto reúne a una comisión de selección de entre los que se verán afectados por la implementación de este nuevo sistema de empresa. Algunos de los que forman la comisión pueden ser miembros del personal de campo que identificó la necesidad de la organización en primer lugar. Puede que otros no. Es posible que la comisión de selección esté formada por una mezcla de personas que tengan diversos intereses en el tipo de sistema que se va a seleccionar.

El desventurado gestor del proyecto solicita a cada miembro de la comisión que sondee al grupo que representa en lo relativo a lo que necesita en el nuevo sistema empresarial. ¿Cómo hace esto cada representante de la comisión? En primer lugar, no todos hacen el mismo esfuerzo, pero aquéllos que hacen su tarea, piden a su personal que le envíe una lista de características que consideran importantes. A continuación, entran en Internet y navegan por algunos sitios web de proveedores. Pueden copiar y pegar características que ven en los folletos de estos sitios ya que cada sitio les dará nuevas ideas de los tipos de solicitudes que pueden pedirle a un nuevo sistema.

Ahora, la comisión se vuelva a reunir y la gran hoja de cálculo de cada miembro de la comisión se combina con las demás en una hoja de cálculo inmensa. La megahoja de cálculo de requisitos se clasifica, pero existen retos. En primer lugar, las diversas necesidades de la comisión se hacen ahora cada vez más evidentes ya que se solicitaron características desde una amplia variedad de perspectivas. Es posible que los miembros de la comisión pertenezcan a distintos departamentos e incluso que también estén en diferentes países o divisiones. Siempre hay una solicitud que está en conflicto con otra de la misma lista (p. ej., el sistema debería ser muy fácil, no tener muchos mensajes y ser muy flexible con un gran número de opciones para cada usuario).

Por último, la hoja de cálculo combinada que verán los proveedores está completa. Tiene cientos de solicitudes de características y, para cada una, se espera que el proveedor diga "Sí", "No" o "Sí, con algo de esfuerzo". También puede adjuntarse un sistema de ponderación para decir si esta característica es "Indispensable", "Importante" o "Deseable".

Fragmento de la característica de selección de hojas de cálculo

La RFP está casi lista para empezar. Habrá unas preguntas de ensayo, por lo general sobre la arquitectura técnica de la selección, y, dependiendo del número de personas sondeadas sobre estos requisitos, la solicitudes de arquitectura puede estar en conflicto igualmente (por ejemplo, el sistema debe tener todos los datos almacenados de forma centralizada en la base de datos de SQL Server y el sistema debe permitir que los datos se almacenen localmente en el equipo del usuario).

En realidad, suena muy bien hasta el momento, ¿no cree? Después de todo, vamos a recibir muchas respuestas de proveedores que mostrarán quién puede ofrecer todas las características que se van a necesitar. En realidad, suena muy bien hasta el momento, ¿no cree? Después de todo, vamos a recibir muchas respuestas de proveedores que mostrarán quién puede ofrecer todas las características que se van a necesitar.

Sin embargo, existe en realidad un problema fundamental en lo que he descrito hasta ahora: un problema que no se produce cuando usamos el proceso de RFP de un producto en lugar de un sistema empresarial. Es decir, un sistema empresarial es una solución a algo. Pero hasta ahora no hemos mencionado el problema. Es una ocurrencia común que la industria tecnológica ha llegado a aceptar como normal y aceptable.

¿Por qué seleccionar software empresarial que no funciona de este modo?

Los compradores han estado usando este método durante décadas sin cuestionarlo, pero las personas que se encuentren en el negocio del software empresarial saben que hay un problema fundamental con el método clásico de RFP de selección de software empresarial.

En primer lugar, simplemente porque tiene una lista enorme de características, lo que no significa necesariamente que esté más cerca de resolver un problema de la empresa. De hecho, si no ha articulado qué problemas empresariales concretos está intentando solucionar, es probable que haga las cosas más complejas y finalmente sea peor, en lugar de mejor. El proceso de RFP se diseñó para comprar productos. Cuando tenemos productos homogéneos como zapatos, patatas o azúcar, la compra de estos productos puede obtener como resultado el menor coste y la mejor selección de entre los posibles proveedores. Las respuestas a una RFP de un producto similar facilita la comparación de posibles proveedores. Cuando las variables en la combinación de cada producto son infinitas (como sucede con el software empresarial), las respuestas a la RFP también tiene un número infinito de variables y el proceso genera resultados que tienen poco valor.

Cuando se usa el método de RFP de selección de sistemas empresariales, la mayoría de las RFP tienen todas el mismo aspecto. Esto se debe a que se crean en respuesta al mismo estímulo. El gestor del proyecto solicita una lista de "lo que necesitará en este sistema empresarial" y lo único con lo que tienen que responder la mayoría de gestores intermedios a esa solicitud es con una lista de características. En consecuencia, todas las respuestas a las RFP tienen el mismo aspecto. Son una lista de comprobación de todas las características disponibles como parte del sistema o como parte del sistema con algún esfuerzo.

Lo más normal para los equipos de selección es que recibirán un número de respuestas a sus RFP, que les mostrarán cientos de páginas y, cuando hayan terminado, no se sentirán más cerca de una solución que cuando empezaron. Esto es muy frustrante para los compradores que dedican un gran esfuerzo a la hora de crear lo que debería ser una solicitud de propuesta justa y a evaluar las respuestas solo para descubrir que el ejercicio no ha servido para nada.

Lo peor de todo es que todos los vendedores empresariales con experiencia saben que el proceso en el que trabajan generará resultados frustrantes desde el momento en que fueron conscientes de que se crearía una RFP. No están trabajando en la respuesta de la RFP. Eso no es relevante. En su lugar, están trabajando en dos o tres niveles más altos en la estructura de administración, buscando el impulso original que obtuvo la RFP iniciada. Buscan al ejecutivo sénior que articuló algunos retos empresariales y puso en marcha los engranajes para que los compradores y otro personal intermedio de administración crearan en última instancia la RFP y la enviaran a los proveedores.

Cuando las respuestas de la RFP acaban sin una respuesta clara a los problemas empresariales que casi nunca se articularon dentro del proceso de compra, el vendedor de la empresa está preparado para entrar en acción, hacer que un ejecutivo sénior omita completamente el proceso y seleccione un sistema basado en su propia relación personal con el vendedor sénior de la empresa.

Si cree que esto suena aburrido, está equivocado. De hecho, puede conseguir mejores resultados si selecciona software mediante las relaciones personales en el ámbito ejecutivo que si compra a través del proceso de RFP.

Pero, ¿qué sucede con una prueba de concepto o piloto?

Sabemos que el clásico proceso de compra es defectuoso cuando lo aplicamos a la compra de software empresarial. En ese caso, ¿deberíamos elegir el software empresarial como un sistema de administración de proyectos empresarial? Un método muy conocido consiste en usar el método de prueba de concepto o fase piloto.

Estos dos términos se suelen usar como sinónimos, de modo que empecemos hablando de lo que es una prueba de concepto o una implementación piloto.

Prueba de concepto   . En una prueba de concepto, la organización potencial implementa el software empresarial de forma limitada para probar que puede lograr un reto técnico donde hay algún problema como la solución a la capacidad de superar ese reto. Un ejemplo podría ser el volumen de datos. "Nos preocupa que el producto no pueda controlar tantas tareas como tenemos por proyecto. Nos gustaría que viniera con el software, utilizara dos o tres proyectos de ejemplo con 500 tareas cada uno y nos mostrara cómo se pueden cargar en el software y que el software todavía pueda realizar sus funciones básicas con este volumen".

Fase piloto   . Una fase piloto es una instalación del software empresarial, pero con un ámbito limitado. Se podría realizar una implementación piloto para un subconjunto de usuarios; por ejemplo, en la que solo 10 de cada 1 000 personas usaran el software durante cuatro semanas. O bien, podría utilizarse una subsección de la funcionalidad o un subconjunto del volumen de datos; por ejemplo, solo cargar 10 de 500 proyectos.

¿Cómo se usa la prueba de concepto o la fase piloto?    El problema que a menudo se observa es cómo se aplica la fase piloto o la prueba de concepto. Es bastante raro que una potencial organización nos llame y nos pida una propuesta de prueba de concepto y también que pueda identificar qué concepto técnico deba probarse. "¿Qué espera probar y cómo podemos medir lo que hemos probado?", preguntamos.

Lo que es más común es que alguien de la administración intermedia haya identificado una parte del software empresarial que espera que facilite su vida en la organización. No todos los gestores sénior están implicados y el personal de administración intermedia ni siquiera ha articulado los retos empresariales que intentan superar. Su esperanza es que si la solución se aplicó en el edificio, la próxima vez que alguien de administración vaya por el pasillo, vería "accidentalmente" la solución en funcionamiento y daría al instante su bendición para una implementación empresarial. Citando una frase de la película Campo de sueños: "Si lo construimos, vendrán".

Selección ineficaz de la fase piloto

Muy pocas veces es satisfactorio. El problema con el software empresarial es que necesitamos la implicación de los gestores sénior para hacer que la implementación tenga éxito. Los gestores sénior serán los "clientes" de los informes y los análisis de este sistema empresarial. Los gestores sénior tendrán que invertir personalmente para permitir que un grupo de personas dedique el tiempo necesario a diseñar, configurar y formarse en el software empresarial. Los gestores sénior tendrán que aceptar o incluso ayudar a rediseñar los procesos empresariales que forman parte de cualquier implementación de un sistema empresarial. Si los gestores sénior no dan su bendición y también su ayuda implícita y asistencia directa, ninguna prueba de concepto lo hará.

Esto también se aplica a una fase piloto. Si la empresa no se ha comprometido desde el nivel más alto para resolver algunos problemas a través del uso del software empresarial, la introducción de una fase piloto no será productiva.

Selección eficaz de la fase piloto

Esto no quiere decir que no se realicen las fases piloto de una implementación. La llevan a un punto crítico en una implementación correcta. Ese lugar está inmediatamente después de haber completado la decisión de compra y haber terminado el diseño del sistema empresarial. Una fase piloto supone la oportunidad perfecta para probar el diseño de nuestro sistema empresarial y adecuarlo a la implementación general.

Cuando una fase piloto finaliza con la esperanza de ver el software en acción y la administración lo selecciona, obtenemos un piloto ineficaz y no avanzamos más en el proceso de selección.

¿Cómo deberían las organizaciones seleccionar el software empresarial?

Las organizaciones medianas y grandes compran sistemas empresariales cada día y, aunque el método RFP puede no ser el más eficaz, existen varios métodos de selección del software empresarial que son muy eficaces. He aquí algunas sugerencias para crear su propio proceso de selección empresarial.

  • Articular el problema   . En primer lugar, articule el problema. Esto significa que los gestores sénior deben estar implicados y el problema que se va a articular es un problema empresarial, por lo que debe articularse en términos empresariales. Una buena pregunta es: "¿Qué decisión empresarial no podemos tomar ahora o podemos tomar solo con gran dificultad que podría aliviarse con la implementación de esta solución de sistema empresarial?"

    Es posible que existan una serie de retos empresariales que desea resolver con el uso de este sistema empresarial.

  • Proporcione a algunos proveedores la perspectiva para crear la solución   . Una vez articulado el problema o los problemas empresariales, póngase en contacto con posibles proveedores y asegúrese de que el acceso a los gestores sénior que van a ayudar en el proceso sea transparente. Las reuniones "secretas" del proveedor con los gestores resultan imposibles cuando la administración forma parte del proceso desde el principio. Deje que los proveedores comprendan el problema y proporcióneles cierta perspectiva al responderles. Puede descubrir más cosas sobre su organización al explicar cómo estos retos empresariales le afectan al darse cuenta de ellos y, por supuesto, verá una gama más amplia de posibles soluciones a su problema cuando no intente describir la solución a los posibles proveedores.

    Cuando hable con los posibles proveedores de soluciones, asegúrese de que comprenden que deben hablar de la tecnología y del reto del proceso empresarial. Nunca ha habido una solución del sistema empresarial que no tuviera algún impacto en el proceso de la organización. Si el proveedor de soluciones no puede obtener ayuda sobre cómo le afectará el proceso, es porque solo está buscando una parte de la solución.

  • Reunirse con algunas personas   . Cuando vaya a ver a un par de posibles proveedores de soluciones, solicite hablar con algunos de sus clientes existentes. Aún mejor, consulte si el proveedor le permitirá visitar algunos de sus clientes existentes. Los proveedores de buenas soluciones a menudo tienen clientes que han tenido éxito en sus propias implementaciones y que son lo suficientemente generosos como para dedicar tiempo a satisfacer a clientes potenciales.

    Aprenderá más de la posible solución en un par de horas con un cliente experimentado de lo que alguna vez haya aprendido al leer o ver respuestas de RFP o al buscar en demostraciones de ventas del proveedor. Cuando le pida al proveedor posibles referencias del cliente y visitas a sitios, es posible que piense que la empresa ideal con la que podría reunirse sería una exactamente igual a la suya. No es siempre el caso.

En muchas ocasiones, resulta extremadamente valioso reunirse con empresas de otras industrias relacionadas o similares a la suya. También puede aprender mucho de organizaciones más grandes o más pequeñas que la suya. Haga más hincapié en la experiencia que ha tenido la organización con la solución en lugar de analizar qué versión usan, si es del tamaño exacto o si se encuentra en el mismo sector que el suyo.

Si tiene la suerte de poder visitar a un cliente existente, recuerde que no es el proveedor. Sea respetuoso, cortés y agradecido. Ofrezca un pequeño regalo, con frecuencia es muy apreciado el material promocional con el logotipo de la empresa. Cuando esté con la organización o cuando hable por teléfono con los clientes de referencia, algunas preguntas podrían ser:

  1. ¿Qué proceso ha usado para seleccionar esta solución sobre las demás?

  2. ¿Qué impacto ha tenido esta solución en los procesos empresariales?

  3. ¿Cuál ha sido el aspecto más difícil de la implementación?

  4. ¿Cuál ha sido el retorno de la inversión más valioso hasta el momento?

  5. ¿Cómo ve la evolución de la solución desde aquí?

No espere solo respuestas positivas.

Un proveedor que no pueda proporcionar ninguna referencia tiene que ser un poco más sospechoso que el que tiene varios clientes satisfechos.

Finalmente, cuando haya hecho la selección, impleméntela en fases. Puede encontrar otros artículos en esta columna sobre cómo implementar por fases frente al modo big-bang. Esto mitigará los riesgos que existen en cualquier implementación de sistemas empresariales y le ayudará a optimizar el proceso de implementación según evoluciona el sistema.

Recuerde que cualquier implementación de un sistema empresarial es un proceso dinámico. No es una decisión unidireccional con resultados positivos que llegan mes a mes. Las implementaciones empresariales de mayor éxito empiezan con una selección que implica al personal clave que formará parte del proceso de implementación desde los miembros sénior más importantes de la administración al más táctico en el campo, seguido de la evolución del sistema fase a fase.

La selección de un sistema empresarial eficaz solo es la primera fase del proceso.

Acerca del autor

Chris Vandersluis es presidente y fundador de la empresa HMS Software, establecida en Montreal, Canadá, un asociado certificado de Microsoft. Cuenta con unos estudios en Economía en la Universidad McGill y más de 30 años de experiencia en la automatización de sistemas de control de proyectos. Es miembro del Project Management Institute (PMI) y participó en la creación de las secciones de Microsoft Project Users Group (MPUG) en Montreal, Toronto y Quebec. Entre las publicaciones en las que ha escrito Chris se encuentran Fortune, Heavy Construction News, Computing Canada Magazine y PMNetwork de PMI; también es columnista habitual en Project Times. Es profesor de Administración avanzada de proyectos en la Universidad McGill y a menudo es ponente en actos de asociaciones de administración de proyectos de Norteamérica y el resto del mundo. HMS Software es el proveedor del sistema de control para los proyectos de TimeControl y es asociado de la solución Microsoft Project desde 1995.

Puede ponerse en contacto con Chris Vandersluis por correo electrónico: chris.vandersluis@hms.ca

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

Ampliar sus conocimientos de Office
Explorar los cursos
Obtener nuevas características primero
Únase a los participantes de Office Insider

¿Le ha sido útil esta información?

¡Gracias por sus comentarios!

Gracias por sus comentarios. Quizá le interese ponerse en contacto con uno de nuestros agentes de soporte de Office.

×