Ser un comprador de soluciones

Este artículo forma parte de nuestra colección "From the Trenches". Describe cómo los posibles compradores de software pueden hacer que las interacciones con los proveedores de software sean más eficaces mediante la aplicación de métodos de análisis empresariales fáciles de entender. Le guiará a través de un ejercicio que puede ayudar a crear criterios de evaluación de software mediante la determinación eficaz de los problemas que debe abordar la solución de software.

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

Ser comprador de soluciones

Con demasiada frecuencia, una compra de software se basa en una lista de características, una campaña publicitaria o la recomendación de un amigo. En este artículo se describe cómo los posibles compradores de software pueden hacer que las interacciones con los proveedores de software sean más eficaces mediante la aplicación de métodos de análisis empresariales fáciles de entender.

Seguro que no es como antes. El hecho de que el software funcione en una configuración empresarial ya no se conoce como instalación. Hoy en día, los términos implementación o implementación describen mejor lo que se necesita para poner en funcionamiento un nuevo paquete.

Cada vez más proveedores de software hablan de lo que venden como soluciones, y no es de extrañar. Cuando pensamos en implementar un sistema empresarial como Microsoft Project Server o Microsoft CRM, primero tenemos que pensar en las distintas capas de tecnología que se van a implicar y, antes de llegar a eso, tenemos que pensar en el impacto en nuestro negocio en general.

Con las soluciones para vender viene, por supuesto, las ventas de soluciones. Si ha seguido esto en absoluto, sabe que casi todas las organizaciones de alta tecnología del planeta destinadas a organizaciones de mediana a gran tamaño están trabajando para volver a crearse como un entregador de ventas de soluciones. Microsoft está ciertamente entre estas organizaciones. Microsoft ha trabajado extensamente en los últimos años para establecer soluciones de venta como un principio rector en sus fuerzas de implementación y ventas en el campo.

¿Qué es un vendedor de soluciones? Es cierto que siguen siendo vendedores. Sin embargo, los vendedores de soluciones tienen como objetivo no solo mover una caja de software, sino crear algo que ayude al cliente a mejorar su situación.

Suena genial hasta ahora; un Nirvana de vendedores todos buscando mejorar su lote en la vida. Pero esto viene con un desafío, y abordar ese desafío es algo en lo que usted (el cliente potencial) puede participar.

Centrarse en el problema

El desafío al que se enfrentan la mayoría de los vendedores de soluciones cuando llegan al mercado es nuestra preconcepción sobre el aspecto que debe tener una solución. Estamos tan acostumbrados a centrarse en funciones y características de software, cuando hablamos con un vendedor de software, la conversación conduce casi inevitablemente directamente a: "¿Puede su software hacer esto? ¿Puede el software hacer eso?" Los vendedores de software experimentados, y esos son los tipos que se trasladan a las posiciones de venta de soluciones, están tan acostumbrados a vender funciones y características que a menudo se olvidan de formular la pregunta más básica de todos: "¿Cuál es el problema?"

Ahora esto puede sonar tonto, pero si piensa en sus últimas conversaciones con vendedores de software, es posible que se sorprenda de la rara vez que surge esta pregunta. Los proveedores como Microsoft y sus asociados reciben muchas solicitudes de propuestas cada año. He visto cientos de ellos a lo largo de los años, y una cosa que casi siempre está presente es una larga cuadrícula de funciones que se espera que el proveedor rellene. Esta hoja de cálculo grande suele ser el núcleo de la respuesta al cliente.

Lo que rara vez está presente es una descripción de las necesidades empresariales que abordará cada una de estas funciones. Es tan fácil quedar atrapado en una característica con la que estamos familiarizados con un producto anterior o que hemos visto promocionado en algún lugar que se necesita una verdadera disciplina para centrarse en lo que nos interesó en este nuevo producto en primer lugar. Esto puede ser especialmente así en una configuración empresarial en la que hay mucha entrada en el tipo de solución que se busca. Es mucho más fácil enviar una solicitud que pide a los usuarios que enumere todas las funciones que les gustaría en un nuevo sistema de software que hablar de sus necesidades empresariales concretas.

Si estás empezando a pensar que quizás te has perdido algo obvio, no estás solo. Esta condición es tan frecuente en el sector del software en el momento en que se ha surgido una nueva categoría de consultor llamada Analista de negocios. Estas personas están entrenadas para establecer la conexión de la necesidad empresarial a la funcionalidad de software. Vamos a tardar unos minutos en ver cómo puede aplicar los conceptos básicos (de la forma en que los aplicaría un analista de negocios) en las evaluaciones de software de nivel empresarial.

Identificación de la necesidad empresarial

Lo primero que hay que pensar es qué necesidad empresarial le ha llevado a buscar un nuevo sistema de software en primer lugar. Nuestra propia organización suele consultar a las empresas sobre la implementación de software de administración de proyectos empresariales. Cuando llego a una organización como consultor, mucho antes de hablar sobre si comprar software, pregunto cómo la organización está haciendo la administración de proyectos en este momento.

Cuando terminan su respuesta, siempre hago esta pregunta de seguimiento: "¿Ese método funciona para usted?" Sorprendentemente, el cliente suele responder que lo es. Para mí, la conversación de implementación tiene que detenerse allí. "Si no hay ningún problema", le explico, "no hay manera de crear una solución!" A menudo, esta respuesta hace que las personas se pausen. "¿Por qué nos llamaron?" Se lo pediré. Las respuestas pueden variar mucho, y no es raro que la gente mire alrededor de la sala dándose cuenta de que hay varias agendas en curso que se deben conciliar, y nuestra conversación tiene menos de cinco minutos de antigüedad.

Por lo tanto, preguntar "¿Cuál es nuestra necesidad empresarial?" es un excelente lugar para empezar. Casi siempre hay un objetivo general que responde a esta pregunta, un objetivo que ha iniciado la iniciativa en primer lugar.

Realización de un ejercicio de visión

A continuación, tendrá que profundizar un poco más en lo que esto significa en términos de funcionalidad de software. Cuando implementamos software de administración de proyectos empresariales como Microsoft Project Server en una organización, siempre comenzamos con un ejercicio de visión que implica al personal clave (aquellos que están evaluando el software) y a la administración sénior, los que patrocinan el ejercicio. No basta con hacer este ejercicio solo con personal técnico, ya que el objetivo de este ejercicio es conectar los objetivos empresariales con las funciones técnicas.

Esta es una manera eficaz de hacerlo: Coloque el personal clave en una sala con una gran pizarra. Dividir la pizarra en 4 columnas: comience con un encabezado solo en la columna de la derecha. Llámalo "Decisión empresarial".

Pizarra con cuatro columnas, incluida una columna Decisión empresarial.

En la columna correcta, va a enumerar las decisiones empresariales que espera tomar mediante el nuevo sistema que está considerando. Cuando hacemos esto con un cliente, lo primero que la gente quiere hacer es enumerar muchas características, por lo que tendrá que insistir en que las respuestas que son importantes son las decisiones empresariales. Por ejemplo, un participante puede decir inmediatamente: "Necesito una lista de todos los recursos y su carga de trabajo". Eso puede ser cierto, por supuesto, pero lo que necesita saber es qué decisión empresarial tomarán con esa lista.

Algunos ejemplos de decisiones empresariales pueden ser:

  • Contratación o despido en un departamento determinado

  • Tomar una decisión de ir o no ir en un proyecto

Pizarra con columna Decisión empresarial y una lista de decisiones empresariales.

Una vez que tenga una lista decente de decisiones empresariales, haga una pausa. Ahora es un buen momento para revisar la lista de decisiones empresariales e identificar las decisiones de prioridad máxima. Tal vez quieran formularse esta pregunta: Si solo pudieran obtener respuestas para una de estas decisiones empresariales, ¿cuál sería la que más valor aportaría a la organización? Elegir las tres primeras decisiones siempre es más fácil en este momento del proceso.

Si ha llegado tan lejos, ya ha logrado más que la mayoría de las organizaciones que buscan software de administración de proyectos empresariales. Ser capaz de proporcionar una lista priorizada de las decisiones empresariales más importantes para los proveedores de sistemas es un gran paso adelante para todo el proceso. Cuando puede indicar a los proveedores del sistema qué decisiones empresariales debe tomar, se les permite ir más allá de hablar de funcionalidad sencilla para hablar sobre cómo hacer que la organización sea más eficaz.

A continuación, examine cada decisión y pregunte: "Para tomar esa decisión empresarial, ¿qué informe requeriría?" Prácticamente todas las decisiones se realizan después de examinar uno o varios informes. Etiquete la tercera columna "Informe". Para cada una de las tres decisiones principales, enumere en esa columna los informes necesarios para la decisión correspondiente.

Por ejemplo, podríamos decir que para determinar si se va a contratar o despedir personal para un departamento determinado, se necesita un informe por departamento que muestre los datos de planeamiento de capacidad de recursos. Esto incluye una previsión directa de la carga de trabajo esperada, la disponibilidad de recursos esperada y la programación. Si es una empresa mediana, el flujo de efectivo también puede ser una preocupación. Por ejemplo, es posible que necesite personal adicional, pero no pueda encontrar el efectivo para contratarlos. El informe de flujo de caja incluiría ingresos estimados y salidas de dinero con un saldo corriente.

Pizarra con una columna Informe y Decisión empresarial.

Si rellenamos la columna Informe para cada una de las decisiones que hemos identificado como prioridades, la forma de lo que necesitaremos ya empieza a quedar clara. Una vez que haya terminado, tiene una lista de la salida física que necesita de su sistema potencial.

Vuelva a hacer una pausa aquí para averiguar si ya hay informes del tipo que ya ha identificado en uso en la organización. Lo más probable es que estos informes existan, pero en numerosos formatos y posiblemente con datos incompletos o con un esfuerzo excesivo necesario para generarlos. Si encuentra formatos de informes que han funcionado en la organización, puede agregarlos a la lista de requisitos de sistemas. Ahora puede proporcionar aún más información a los proveedores del sistema.

Con los informes clave ahora identificados, podemos pasar a los elementos de un sistema necesario para generar esos informes. Agregue el encabezado "Análisis" a la segunda columna del gráfico. Para cada informe, identifique los análisis o algoritmos necesarios para generar el informe. Por ejemplo, para un informe de planeamiento de capacidad de recursos, es posible que necesitemos una programación de ruta de acceso crítica del sistema de administración de proyectos y un análisis de nivelación de recursos.

Pizarra con columnas Análisis, Informe y Decisión Empresarial.

Estos análisis a menudo serán comercializados por los proveedores sobre la base de la infinidad de características que cada uno incluye. (Sí, la venta de características por características sigue activa y bien) Lo que debe ser capaz de determinar es la funcionalidad mínima que proporcionará los informes que necesita con los que puede tomar o mejorar la decisión empresarial que ha identificado. Es posible que se sorprenda de lo básico que es la funcionalidad que necesita para cumplir los requisitos empresariales reales. En algunos informes, no se requerirá ningún análisis o cálculo; los informes solo deben ser agregados simples que se pueden generar directamente desde los datos del nuevo sistema.

Por último, llegamos a la primera columna del gráfico. Una vez que haya identificado los análisis necesarios, puede pasar a determinar qué elementos de datos son necesarios para alimentar los análisis.

Agregue el encabezado "Entrada" a la primera columna del gráfico.

En el ejemplo que hemos usado, es posible que necesitemos una lista completa de tareas para cada proyecto implicado en el trabajo del departamento. Esto podría ser muy bien todos los proyectos de la organización. También necesitaremos un perfil completo de la disponibilidad de cada recurso junto con la carga de trabajo definida en cada tarea de modo que, cuando la tarea se mueva en el análisis de programación, la carga de trabajo se mueva en el análisis de nivelación de recursos. Además, ¿recuerdas cómo comenzamos con la decisión de contratar o despedir en un departamento determinado? También es necesario poder identificar los recursos por departamento.

Pizarra con columnas Input, Analysis, Report y Business Decision.

Podemos pasar así de las salidas de la derecha a las entradas de la izquierda hasta que hayamos identificado todo lo que necesitaremos en nuestro nuevo sistema empresarial.

Evaluación de riesgos

Una vez completado este ejercicio, merece la pena volver a cada una de las entradas y determinar la disponibilidad de estos elementos de datos. Es posible que encuentre, como a menudo, que algunos de estos elementos ni siquiera existen. Por ejemplo, algunas organizaciones no mantienen una lista completa de disponibilidad de recursos. También puede encontrar que no todos los proyectos tienen una programación cargada de recursos que muestra la carga de recursos generada por ese proyecto. En muchas organizaciones, ciertos tipos de proyectos no se colocan en un sistema de ningún tipo. El trabajo de emergencia, el trabajo de soporte técnico o el trabajo de mantenimiento normal son algunos ejemplos comunes.

Si no tiene acceso a los datos fundamentales que necesitará para entregar el valor empresarial, debe considerar ese elemento del sistema como de alto riesgo. Por ejemplo, si observamos que podemos identificar programaciones cargadas de recursos para el 80 % de los proyectos de la organización, ¿podemos esperar razonablemente mejorar nuestra decisión empresarial de aumentar o reducir el personal? La respuesta es probable, "No". ¿Por qué? Porque quizás el 20 % de los proyectos que no están en el sistema podría representar el 80 % de la carga de trabajo para un departamento determinado. Si no tiene todos los datos, nunca sabrá si el informe final es preciso.

Hay maneras de solucionar este tipo de problemas, por supuesto. Un método consiste en aislar todos los procesos empresariales de esos aspectos de la organización en los que no se puede obtener acceso a los elementos de datos. Una división cuyos proyectos podrían no estar en el sistema tampoco tendría sus recursos enumerados. Esto no se puede hacer simplemente en todos los casos; tendrá que buscar elemento a elemento para averiguar cuánto riesgo suponen esos procesos empresariales y decisiones empresariales para la implementación. No es raro en este momento en el proceso volver a priorizar las decisiones empresariales finales que espera mejorar. Es posible que tenga una decisión que es muy deseable, pero resulta ser un riesgo muy alto y, por lo tanto, no merece la pena seguir adelante en las primeras fases de la implementación.

Documentar lo que ha hecho

Cuando lleve a cabo este tipo de reunión, asigne un escriba, alguien cuyo trabajo será registrar notas y comentarios durante todo el proceso. Las razones por las que una decisión empresarial en particular se clasificó como de prioridad alta o baja o por qué se consideró un riesgo alto se olvidarán rápidamente si no tiene notas buenas a las que volver a hacer referencia.

Es muy importante grabar:

  • Lo que ha escrito en la pizarra

  • Quién participó en el proceso

  • ¿Quién es el propietario de cada decisión empresarial final?

Si te sientes abrumado en este momento, no temas. Todo este ejercicio se puede realizar muy rápidamente, incluso en las organizaciones más grandes. No es raro poder completar todo el proceso en un día o quizás dos. La clave para tener éxito es obtener el nivel adecuado de administración en la sala. Además, este tipo de reunión es mejor facilitado por alguien de fuera de la organización que no está predispuesto a hacer las cosas de la manera en que siempre se han hecho.

El conocimiento es el poder

Si está examinando los sistemas de administración de proyectos empresariales(de hecho, en sistemas empresariales de cualquier tipo), completar este ejercicio le proporciona una gran cantidad de energía al interactuar con los proveedores de sistemas de software. Puede distinguir inmediatamente entre los elementos de un sistema que son importantes para usted y los que no lo son. Los proveedores de software se pueden proporcionar con la lista de informes y decisiones que desea tomar.

Es posible que se sorprenda de algunas de las respuestas que le llegan de los proveedores. Liberados para responder de una manera distinta a la característica por característica(es decir, tratando de ajustar una función cuadrada a un requisito de ronda), los mejores proveedores podrán mostrarle cómo puede responder a sus desafíos empresariales usando sus sistemas para su mejor ventaja.

Esta es la mayor ventaja de llevar a cabo este ejercicio: ha creado criterios de evaluación listos para realizar. Ahora, durante la fase de prueba de concepto, puede centrarse inmediatamente en si el sistema proporciona la información que necesita para mejorar las decisiones empresariales que debe tomar.

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).