Customer Story | Proceso preciso de NASA JPL para la evaluación y selección de una herramienta ESM

[0:05] Lynn: Frank es un profesional de las tecnologías de la información del Laboratorio de Propulsión a Chorro de la NASA, donde se encarga del diseño de procesos empresariales, la programación web, el diseño y desarrollo de bases de datos, la programación SQL, la ingeniería de sistemas, la recopilación de requisitos y los proyectos de TI. Su carrera comenzó hace unos treinta años como operador de ordenadores centrales; a partir de ahí, ascendió a jefe de proyectos técnicos, cargo en el que creó bases de datos de préstamos interbibliotecarios. Unos años más tarde, se incorporó al JPL como responsable de tecnologías de la información. Así que, antes de que me vaya por las ramas, le voy a ceder la palabra a Frank. Adelante.

[0:51] Frank: Pues muchas gracias y bienvenidos a todos los que estáis aquí para el seminario web. Estoy muy emocionado por poder presentaros esta información. Espero que os resulte tan interesante como a mí, así que vamos a empezar ya mismo, ¿vale? Bien, mi presentación va a ser un resumen informal del proceso que seguimos para buscar, encontrar y evaluar productos de utilización, y os la voy a explicar tal y como sucedió cuando lo hicimos nosotros mismos.os voy a mostrar cómo llevé a cabo el estudio de evaluación, en el orden en que lo hice, y os voy a enseñar algunos de los documentos que elaboré como parte de la elaboración del informe final. Por eso, debo informaros de que el JPL tiene una política según la cual no promocionamos productos específicos; por lo tanto, cuando presente información sobre los proveedores que evaluamos, no utilizaré sus nombres. Así quehablemos del orden del día del seminario web de hoy: os voy a explicar los objetivos que teníamos cuando iniciamos el estudio para encontrar un producto de utilización; os voy a hablar de los proveedores que seleccionamos y de lo que aprendimos sobre ellos al llevar a cabo el estudio; os voy a explicar cómo realizamos la puntuación, que está relacionada con cómo llevamos a cabo la evaluación real de los proveedores seleccionados;os voy a mostrar cómo presentamos los resultados de nuestras puntuaciones, que incluirán el rendimiento de cada uno de los proveedores; os hablaré de los resultados del estudio, incluyendo en qué punto del proceso nos encontramos ahora mismo; y, al final, dedicaremos un rato a responder algunas preguntas. Debo avisaros de que el proceso de divulgación de información del JPL es estricto, por lo quetendré que limitar las preguntas a aquellas relacionadas con el seminario web que estamos celebrando ahora mismo. Así pues, cuando hable de los productos y los proveedores de este estudio que hemos realizado, cuando me refiera a un proveedor, me refiero a las empresas que proporcionan soluciones de utilización, y cuando hable de un producto, me refiero al software que gestionamos, mantenemos y entregamos a nuestros clientes; por lo tanto, los productos que ustedes gestionan, mantienen y entregan a sus clientesinterna, nosotros utilizamos esos términos indistintamente; por lo tanto, haré todo lo posible durante el seminario por ceñirme a esos términos exactos y, si cometo algún error, me corregiré.

[3:58] Vale, empecemos con lo esencial de la presentación; hablemos de los objetivos del estudio. El primer objetivo que teníamos era aumentar la calidad… perdón, la cantidad de nuestros datos de utilización. Verás, habíamos descubierto que, en la herramienta interna que habíamos creado para gestionar nuestra utilización, muchos de los productos que tenemos generan datos de registro, y estábamos utilizando esos datos para recopilar la información de utilización, gestionarla y, a continuación, presentarla en nuestraherramienta interna para generar nuestros gráficos, y nos dimos cuenta de que el uso de esos datos de registro resultaba realmente problemático: a veces los registros fallaban cuando los proveedores no vaciaban los datos de su búfer en el registro, y nos veíamos obligados a volver atrás y volver a procesar esos datos, lo que generaba problemas en nuestros informes de utilización que teníamos que corregir con frecuencia. Debido a esto, las partes interesadas internas empezaron a perder confianza en los datos, ya que cuandoteníamos que volver atrás y volver a procesarlos, les parecía que la estabilidad de nuestro sistema de recogida de datos no era tan sólida como podría ser; así que esa fue también una de las razones por las que realizamos este estudio: para determinar cómo podíamos mejorar esa calidad y reforzar esa confianza. Ahora bien, descubrimos que los datos no eran tan malos como las partes interesadas habían percibido, pero esa percepción era, sin duda, algo que también teníamos que gestionar.

[5:36] Como parte de este proceso, nos dimos cuenta de que queríamos mejorar la usabilidad de nuestra herramienta interna; queríamos convertirla en una herramienta basada en una arquitectura orientada a servicios, en la que los usuarios dependieran menos de mí y del resto de desarrolladores para programar informes a partir de los datos de utilización del back-end, y pudieran acceder a la herramienta y obtener ellos mismos más de esos informes. Así que, dado que ya contábamos con unaherramienta interna que nos funcionaba bien como parte de este estudio, queríamos asegurarnos de que esa era la herramienta que queríamos utilizar y con la que queríamos seguir. Cuando creamos inicialmente nuestra herramienta interna, no existía en el sector ninguna herramienta adecuada que pudiéramos utilizar para obtener los datos de utilización que necesitábamos, por lo que creamos la nuestra propia. La parte más importante de este estudio consistió entonces en elaborar lo que denominamos un informe de «crear frente a comprar», es decir, un análisis para determinar si nuestray nuestros recursos internos serían una mejor solución o si algo ya existente y disponible en el mercado sería más adecuado para satisfacer las necesidades de nuestro estudio y nuestras necesidades internas.

[7:15] Bien, vamos a hacer un breve repaso de todo lo que hicimos para llevar a cabo el estudio. Lo primero que hicimos fue evaluar cuáles eran nuestras necesidades en materia de informes de utilización, y nos pusimos manos a la obra para recopilar nuestros requisitos. Lo importante aquí es recordar que no recopilamos los requisitos basándonos en nuestra herramienta interna actual, ya que, de ser así, esta habría cumplido todos los requisitos; sino que partimos de cero, de la nada, y nos preguntamos: «Bien, si tuviéramos todo lo que quisiéramos, ¿qué sería? ¿Qué es lo que realmente buscamos? ¿Cuáles son las necesidades que no cubre nuestra herramienta actual y que debemos abordar para satisfacer nuestras necesidades de informes internos?». A continuación, me puse a buscar en Internet y me sorprendió descubrir que ahora hay bastantes proveedores que ofrecen informes de utilización, así que identificamos a esos proveedores, consultamos sus páginas web y leímos toda su documentación en línea; nos hicimos una buena idea de los proveedores solo a partir de su presencia pública y, a partir de ahí, seleccionamos a algunos de ellos que nos parecieron candidatos para el tipo de informes que queríamos; les enviamos una solicitud de información que incluía nuestros requisitos y lo importante de todo ello fue que, cuando por fin nos reunimos con cada uno de los proveedores y hablamos con su personal comercial y técnico, ya les habíamos enviado nuestros requisitos y habíamos mantenido las reuniones iniciales; fue estupendo porque estábamos realmente centrados en cuáles eran nuestras preguntas específicas, pudimos ir directamente a las preguntas y requisitos concretos, por lo que las presentaciones de cada uno de los proveedores consistieron en una solicitud para que respondieran a todos los conjuntos de requisitos y nos explicaran cómo cada uno de ellos cumplía o no cumplía esos conjuntos de requisitos.

[9:36] En el caso de aquellos proveedores con los que decidimos ejecutar versiones piloto de esos programas informáticos —porque lo que queríamos era ver no solo las demostraciones que nos ofrecían el personal de ventas y el equipo técnico, sino también cómo se comportaban estos productos con nuestros datos—, eso también me permitió generar informes específicos en cada uno de los productos; así, como parte de todo ese proceso, pudimos evaluar a cada uno de los proveedores con nuestros propios datos y puntuarlos nosotros mismos en función de nuestros requisitos y, por último, la parte final del estudio consistió en presentar a nuestras partes interesadas todas estas evaluaciones y, a continuación, los resultados finales de nuestro estudio sobre si era mejor desarrollar o adquirir la solución.

[10:39] Como parte de esto, también llevé a cabo mi proceso de ingeniería de sistemas, lo que incluyó la elaboración de documentos comunes de requisitos de ingeniería de sistemas, como los documentos de requisitos, el documento de contexto y los resultados de los estudios; a continuación, reuní todo ello y lo entregué en un único informe exhaustivo a la dirección. Una cosa que quiero destacar es que nos resultó increíblemente valioso cuandorecogíamos nuestros requisitos, nos resultó increíblemente valioso hablar con todos los miembros del equipo; lo hicimos: hablamos con la alta dirección, con el personal de gestión de licencias —los que gestionan los cambios en los archivos de licencia y la prestación de esos servicios—, con nuestros responsables de producto —que son las personas que dan soporte específico a los productos individuales que ofrecemos a nuestra base de clientes— y, por último, con nuestros responsables de disciplina; para nosotros, la disciplina es nuestro grupo de partes interesadas, que son los equipos de gestión de nuestras herramientas mecánicas, los ingenieros mecánicos y nuestras herramientas eléctricas, para los ingenieros eléctricos, y nuestras herramientas de sistemas de software. Así que recopilamos toda su información yveréis, al igual que nosotros, que cada uno buscaba un dato ligeramente diferente. Un ejemplo podría ser que los directivos buscaban más información sobre la utilización a lo largo del tiempo: ¿cómo se estaban utilizando nuestras licencias?, ¿tenemos suficientes licencias?; los responsables de soporte de producto estaban más interesados en saber cuántos rechazos se producían, quiénes los recibían y a qué se debían; y eso determinó nuestros requisitos dentro de la propia herramienta. Por eso os recomiendo que recabéis vuestros requisitos de todas las personas que tienen interés en lo que informes de utilización les revelen.

[12:56] Así que, una vez recopilados los requisitos, empezamos a poner en marcha los proyectos piloto. El estudio reveló que, para el producto que eligiéramos, debíamos asegurarnos de que fuera compatible con un número significativo de productos, lo cual nos llevaba de vuelta al problema que teníamos: nuestra herramientaherramienta interna no era compatible con el software de gestión de licencias a través de los registros, y queríamos que cualquier producto que eligiéramos para sustituir al actual, si así lo decidíamos, fuera compatible con más productos. Aprendimos que, independientemente del proveedor que seleccionáramos, debíamos asegurarnos de que pudiera importar losno compatibles, y la importancia de esto radica en que queríamos asegurarnos de que, para cualquiera de los productos que proporcionáramos a nuestra base de clientes, dispusiéramos de una forma de introducir los datos de utilización en la herramienta del proveedor; no podíamos afirmar que, para un producto específico que estuviéramos proporcionando, no hubiera forma de introducir los datos de utilización en el producto del proveedor, a menos que el producto que estuviéramos proporcionando no generara registros.

[14:32] Nos dimos cuenta de que necesitábamos muchos informes personalizados, lo cual se refleja en el hecho de que contamos con tantos interesados que analizan los datos de tantas formas diferentes que debíamos asegurarnos de que la herramienta fuera lo suficientemente robusta como para satisfacer todas sus necesidades. También nos dimos cuenta de que nuestros interesadosno querían tener que acceder siempre a la herramienta para iniciar sesión y generar un informe; querían que los datos les llegaran directamente, así que queríamos que, al llegar por la mañana, recibieran por correo electrónico el informe programado; podía tratarse de un informe diario, aunque algunos de ellos prefieren informes semanales, por lo que esa fue una de nuestras necesidades más importantes.

[15:24] También queríamos asegurarnos de que los informes generados por la herramienta del proveedor incluyeran nuestra información de recursos humanos, y lo importante al respecto es que nos dimos cuenta de que los informes que queríamos generar incluían analizar los datos desde la perspectiva de, por ejemplo, qué grupos de nuestros recursos humanos y de nuestra estructura departamental utilizan las herramientas de forma específica; y los datos de utilización, tal y como se reciben en bruto,no incluye esa información, por lo que teníamos que asegurarnos de que la herramienta del proveedor combinara esos datos para que pudiéramos elaborar consultas e informes desde el punto de vista institucional.

[16:13] Queríamos asegurarnos de que contáramos con unos informes de denegaciones realmente buenos, y estos informes debían estar bien enfocados para que, como ya sabéis, al analizar las denegaciones, dependiendo del producto y de la forma en que este registre dichas denegaciones, a veces un producto puede registrar denegaciones antes de pasar a la concesión de una licencia, y queríamos asegurarnos de que los informes de denegaciones dentro del producto del proveedor pudieran gestionar los diferentes tipos de denegaciones que se producen; además, una de nuestras partes interesadas estaba muy interesada en obtener información en tiempo realen tiempo real sobre lo que está ocurriendo en ese preciso momento en el sistema —quién está conectado— y luego cruzar esa información con los datos de RR. HH. para saber a qué grupo o sección pertenecen.

[17:18] Bien, pues en esta fase del estudio ya hemos recopilado nuestros requisitos, hemos hablado con los proveedores, hemos seleccionado a los proveedores para las pruebas piloto, tenemos nuestros propios datos en el sistema ylo cual nos ha proporcionado una primera serie de datos sobre lo que vamos a necesitar en una herramienta de utilización; por eso quiero comentaros muy brevemente algunas de las cosas que hemos aprendido sobre los proveedores que llevaban a cabo las pruebas piloto. El proveedor A tenía una interfaz muy limpia y moderna; no voy a repasar cada uno de estos aspectos, pero lo importante es que contaban con una interfaz limpia y moderna. Este producto no nos permitía realizar una prueba piloto in situ, pero sí disponía de unadiseñada en la que había muchos datos con los que podíamos generar informes. Lo que aprendimos sobre el proveedor A y que nos pareció importante es el último punto: que su presentación de datos se hacía desde el punto de vista del servidor, y lo relevante de ello es que, para nuestros sistemas de tríadas, no se podía generar un informe de las tres tríadas simultáneamente, por lo que había una limitación en esa perspectiva de los informes. Este proveedor también tenía un problema con la capacidad de filtrar sus denegaciones.

[18:58] Y eso resultaba problemático. En cuanto al proveedor B, esto es lo que aprendimos y lo que nos pareció importante de él: el producto del proveedor B: su producto era muy sencillo y limpio, no tenía mucho JavaScript, las imágenes que generaba eran muy simples, pero nos ofrecía todo lo que necesitábamos; todo estaba ahí y, en comparación con el proveedor A, tenía la capacidad de filtrar los rechazos, lo que nos permitía limitar los informes; sin embargo, lo interesante del proveedor B es que, precisamente por ser tan sencillo, nos llevó a tener que evaluar si sería capaz de cumplir con el requisito del estudio de poder aumentar el volumen de nuestros informes.

[20:01] Esto es lo que descubrimos sobre el proveedor C: contaban con una interfaz de usuario muy bien diseñada. Lo que realmente nos pareció importante del proveedor C fue que los datos LDAP se almacenaban localmente; lo relevante de esto es que así se liberaban algunos de los recursos de nuestro sistema LDAP institucional, de modo que el proveedortenía que acceder constantemente a nuestro sistema LDAP para recopilar información. Además, el proveedor almacenaba esa información de RR. HH. y sus cambios a lo largo del tiempo, de modo que, si por ejemplo cambiaba el número de personas de un grupo, esa información también se actualizaba; esto es importante para poder ver cómo evolucionan las tendencias a partir de los cambios en la información del grupo. El proveedor C también era compatible con un gran número de servidores de licencias en comparación con los demás proveedores: admitía 25 proveedores de licencias diferentes; además, el proveedor C contaba con una funcionalidad que también teníamos en nuestraherramienta interna y que también nos gustaba: la creación de «pseudo-proveedores». Lo que queremos decir con esto es que, para aquellos de vosotros que os dedicáis a la gestión de licencias, sabéis que algunos proveedores de productos os envían un archivo de licencias y agrupan sus productos en un único archivo; es necesario poder extraer esos datos y representar esa utilización como productos independientes que ofrecéis a vuestra base de clientes, y el proveedor C tenía la capacidad de hacerlo, por lo que lo valoramos mucho.

[21:46] Así que hemos evaluado a nuestros proveedores, que han estado recopilando nuestros datos, y cuando consideramos que estábamos en condiciones de comparar adecuadamente las capacidades de los proveedores con nuestras necesidades y requisitos, llevamos a cabo un proceso de puntuación, y asíasí es como se desarrolló: lo primero que hicimos fue asignar una ponderación a cada uno de los requisitos, escalada en una escala del 2 al 10 —en lugar de una del 1 al 5—, y lo hice personalmente porque quería asegurarme de que, si se cumplían los requisitos de nivel 8 y 10, estos tuvieran un mayor peso en la escala para esos elementos importantes, y de que los requisitos de menor importancia —los de nivel 2 y los fcuatro, si no se cumplían, que eso hiciera bajar la puntuación. Creo que ese fue mi primer objetivo; mi segundo objetivo era que, de este modo, se obtuviera una puntuación final más significativa para la alta dirección y las partes interesadas. Para cada uno de esos requisitos ponderados, evaluamos a los proveedores y les asignamos una puntuación por cada uno de ellos; a continuación, multiplicamos esa puntuación por la ponderación, y ese fue el resultado final de cada proveedor para cada uno de esos requisitos.

[23:41] A continuación, os muestro un ejemplo: lo que estamos viendo aquí es uno de los documentos que elaboré como parte de mi informe general. Se trata del requisito número 36; TUR son las siglas de «tool utilization reporting» (informes de utilización de herramientas) y, en este requisito, nos referimos a la capacidad del producto de ese proveedor para generar un informe personalizado. Nuestra herramienta interna cumplía ese requisito y eso se debía a que, como yo mismo diseñé el sistema desde el principio-end y las tablas de la base de datos, sabía cómo escribir mis propias sentencias SQL para mi sistema, así que cumplí ese requisito. El proveedor A dijo que no cumplía ese requisito, pero, de hecho, les subí la puntuación porque, durante la evaluación, descubrí que tenían una interfaz gráfica de usuario web para generar sentencias SQL que luego podían insertarse en el sistema, así que les di una puntuación más alta. Hice lo mismo con el proveedor B, otorgándoles una puntuación que indicaba que cumplían parcialmente el requisito, ya que pude acceder a suy examinar su esquema de base de datos, y me pareció que no era demasiado complicado, por lo que consideré que podríamos familiarizarnos con esa tabla de la base de datos y escribir nuestras propias sentencias SQL sobre los datos sin procesar. El proveedor C también cumplía ese requisito y contaba con un sólido sistema de informes ya integrados en el sistema; echando la vista atrás, probablemente debería haber puntuado al proveedor C como si superara ese requisito, pero acabó con un 12, aunque no pasa nada.

[25:44] Aquí tenéis un ejemplo de otro informe que he generado; esta es mi representación visual de la puntuación, y la he hecho para que podáis tener una visión general rápida y sencilla de la puntuación de cada uno de los proveedores. Fijaos en que se trata de puntuaciones de diez; observad que solo muestro el resumen, no el requisito real —en la práctica, no se redactaría un requisito con ese tipo de lenguaje—, pero podéis ver que los proveedores A y B no han cumplido algunos de esos requisitos y, aunque figuran entre nuestros requisitos imprescindibles, las partes interesadas seguirán analizando esto y se preguntarán si se trata de requisitos de los que podrán prescindir en caso de que elijamos esa herramienta.

[26:36] Aquí tenéis una escala con los resultados de todos nuestros requisitos con ponderación 10; estos son nuestros requisitos imprescindibles, teníamos 15, y creo que, entre los requisitos con ponderación 10, había un conjunto de ellos que eran requisitos que cabría esperar que todos los proveedores del sector fueran capaces de cumplir; por ejemplo, había un requisito que decía «ser capaz de generar un informe de horas extras de utilización» y, desde el punto de vista de la recopilación de requisitos,es un requisito importante que debe cumplirse; pero, precisamente por eso, todos los proveedores van a obtener una puntuación un poco alta en los requisitos con ponderación 10. Sin embargo, se observa que el proveedor A no obtuvo una puntuación tan alta como habría esperado en estos requisitos con ponderación 10 y, al analizar el caso del proveedor A, creo que se debió a que presentaron sus datos desde el punto de vista del servidor, por lo queno podíamos obtener todos los demás informes para el conjunto de nuestros tres sistemas; por ejemplo, nuestra herramienta interna obtuvo una puntuación muy alta y eso se debió a que la desarrollamos nosotros mismos, por lo que, obviamente, cubría todas nuestras necesidades importantes, ya que nuestros requisitos con ponderación 8 —que eran los de mayor importancia, había 14 de ellos—es interesante señalar que, en este punto, el proveedor A se quedó muy atrás en su capacidad para cumplir esos requisitos; estos requisitos iban más allá de lo básico; son aquellos en los que realmente empezamos a añadir usabilidad y a satisfacer las necesidades de nuestra institución más allá de lo básico; son los requisitos en los que empezamos a ver si satisfacen nuestras necesidades empresariales. Se puede observar que, incluso en estas áreas, nuestraherramienta interna no cumplía todos esos requisitos, y eso es precisamente lo que refleja nuestro informe «desarrollar frente a comprar»; en esa parte del estudio se muestra el ámbito en el que tendremos que invertir en nuestra propia herramienta para poder cumplir esos requisitos. Aquí se puede ver que el proveedor C obtuvo unos resultados excelentes e incluso superó a nuestra herramienta interna.

[29:15] Aquí están los resultados de los requisitos con peso 6; en este ámbito, el proveedor B también se quedó bastante rezagado y nuestra herramienta interna tampoco obtuvo muy buenos resultados. Hay un amplio margen aquí en el que deberíamos optar por la solución de desarrollo interno, lo que supondrá una parte significativa de nuestra inversión interna. En cuanto a los requisitos con ponderación 4, el proveedor B volvió a quedarse atrás; el proveedor C obtuvo mejores resultados que nuestra herramienta interna. Hay siete de estos requisitos con ponderación 4, que son bastante importantes, y solo había dos requisitos con ponderación 2, por lo que no he incluido ese gráfico, pero aquí está la puntuación final: se puede ver que el proveedor C obtuvo una puntuación más alta que nuestraherramienta interna; se puede ver aquí que ninguno de los proveedores ni nuestra herramienta interna cumplieron todos nuestros requisitos, por lo que hay un ámbito en el que nuestras partes interesadas tendrán que evaluar cuáles son los requisitos que faltan y determinar el impacto que tendrán en nuestros procesos internos; lo que muestra este gráfico de puntuación final es que, en realidad, la decisión se reducirá a elegir entre nuestra herramienta interna y el proveedor C.

[31:11] Aquí tenéis un mapa de calor con todos los requisitos; lo que os muestra es un resumen muy rápido y fácil de leer sobre el rendimiento de cada uno de los proveedores y de nuestra herramienta interna. Una cosa que me ha parecido interesante es que había creado la categoría «supera los requisitos» yno tenía tantos como esperaba; supongo que habrá más casos de «supera los requisitos» y, por supuesto, el verde indica que se cumple el requisito, el amarillo que se cumple en cierta medida y el rojo que no se cumple. Creo que lo importante de este gráfico es también que, al observarlo, se puede ver que, en los requisitos de nivel 4, hay un gran bloque rojo tanto en el proveedor B como en el C, pero también en nuestraherramienta interna, donde no cumplimos los requisitos exigidos; el proveedor del sector A sí cumplió algunos de ellos, pero esa es un área en la que tenemos que volver a examinar esos requisitos y preguntarnos: «¿Son estas realmente preguntas que deberíamos estar planteándonos?», porque estamos observando que las herramientas del sector no están respondiendo a esas preguntas.

[32:39] Bien, pues hemos evaluado los productos, les hemos asignado una puntuación y ahora es el momento de llevar a cabo la parte final del estudio «fabricar o comprar», que consiste en comparar los resultados de la puntuación con el coste de la inversión. Este es el resultado que vemos aquí. La línea del gráfico de compra que ves ahí es relativa a sí misma; nono quiero que podáis fijaros en la puntuación y deducir ningún coste a partir de ella; por eso el coste no aparece explícito, sino que es relativo a la escala, pero se representa con precisión. Al observar esto, podéis haceros una idea real de cuál iba a ser la inversión para cada una de las herramientas y el coste de nuestraherramienta interna representa el coste de lo que esperábamos invertir internamente para cumplir con sus requisitos. También quiero que sepáis que el coste que se muestra aquí no incluye el coste de mano de obra de mantenimiento, ya que esperábamos que fuera un coste fijo y que fuera el mismo para cada una de las herramientas.

[34:13] Bien, en cuanto a la conclusión del estudio, determinamos que el proveedor C, como se puede ver en el gráfico anterior, ofrecía más funcionalidades por cada dólar invertido en ese ámbito; es decir, llegamos a la conclusión de que el proveedor C nos proporcionaría un mejor retorno de la inversión que incluso nuestra propiaherramienta interna. Descubrimos que el proveedor C contaba con capacidades que ni siquiera figuraban en nuestro conjunto inicial de requisitos y, de nuevo, el resultado final fue que no podíamos justificar la diferencia de coste entre invertir en la reconstrucción de nuestra herramienta interna y lo que obtendríamos con la compra. Por lo tanto, la decisión entre «desarrollar» o «comprar» se decantó por la compra, y adquirimos el producto del proveedor C.

[35:17] Y bien, ¿en qué punto nos encontramos ahora mismo? Acabamos de finalizar la primera fase de implementación del proveedor, lo que ha incluido la instalación de todas nuestras licencias compatibles con el producto del proveedor de forma nativa; sorprendentemente, se trata de un número significativo de las herramientas que ofrecemos a nuestra base de clientes. Aunque en estos momentos estamos recopilando datos, estamos utilizando nuestra herramienta interna y la del proveedor C en paralelo y, con el tiempo, iremos retirando progresivamente nuestraa medida que continuamos formando a nuestras partes interesadas internas sobre cómo utilizar la herramienta y cómo encontrar y comprender los informes; además, en estos momentos estamos llevando a cabo el proceso de generación de los informes personalizados que nuestras partes interesadas van a necesitar.

[36:29] El proceso que hemos seguido aquí no es algo que yo haya inventado, sino una práctica estándar de ingeniería de sistemas de software; en este libro se puede encontrar una referencia sobre este proceso, quetrata específicamente en el capítulo 22, por lo que recomiendo que se analice el proceso de evaluación de proveedores en lo que respecta a los requisitos de software. Me resultó increíblemente útil conocer y utilizar un estándar del sector para realizar la evaluación; aumentó mi confianza a la hora de llevarla a cabo y saber que el informe que estaba elaborando para la alta dirección formaba parte de una buena práctica del sector. Quiero dar las gracias a todos por haber venido hoy y por escucharme, y espero que les haya resultado interesante. Espero que se sientan inspirados para probar este tipo de proceso vosotros mismos.