Herramientas de apoyo para la gestión del RBS en

proyectos
Greivin Arguedas Rodríguez José Leonhardes Gómez Yunen Ramos Ramírez
Escuela de ingeniería en ciencias de la Escuela de ingeniería en ciencias de la Escuela de ingeniería en ciencias de la
computación computación computación
Universidad Fidélitas Universidad Fidélitas Universidad Fidélitas
San José, Costa Rica San José, Costa Rica San José, Costa Rica
garguedas40967@ufide.ac.cr jleonhardes10435@ufide.ac.cr yramos60613@ufide.ac.cr

Abstract— This document contains information on the
definition, objectives and importance of a breakdown of the
risk structure, as well as an analysis of some tools for its
construction and the comparison of said tools to try to
determine a good choice according to the needs of the reader.
Keywords— análisis, estructura, gestión, RBS, riesgos
I. INTRODUCCIÓN
Para iniciar un punto clave que se debe definir es el
concepto de la gestión de riesgos, la gestión del riesgo
comprende un proceso de identificación, análisis y respuesta
ante la materialización de un riesgo.
De igual forma es necesario tener claridad de lo que es un
riesgo en su definición desde la gestión del riesgo. Un riesgo
se define como la incertidumbre sobre los objetivos [1].
Definidos los conceptos anteriores se posee una base para
poder entender que sígnifica una estructura de desglose de
riesgos o RSB por sus siglas en inglés: Risk Breakdown
Structure.
Un RSB y un EDT son estructuras distintas, el RSB es
una estructura jerárquica que idéntica, desglosa y organiza
los riesgos, su objetivo es identificar y evaluar los riesgos
para poderlos entender y gestionar de forma eficiente.
Mientras que una estructura de desglose de trabajo (EDT) se
enfoca en desglosar los objetivos propuestos para el proyecto
[2].
Cuándo se comprende que un proyecto puede ser
afectado por eventos externos o internos se plantea la duda:
¿Cómo se pueden identificar y evaluar los riesgos de forma
eficiente? En este documento podrás entender cómo lograrlo
y qué opciones existen de herramientas para este proceso.
II. ELABORACIÓN DE UN RBS
Una estructura de gestión de riesgos es una herramienta
indispensable que apoya a tener una representación más
exacta sobre todas aquellas adversidades internas o externas
que pueden afectar los objetivos propuestos es por este
motivo que su implementación en los proyectos es en las
etapas iniciales del mismo.
Es importante indicar que el RBS debe ser flexible esto
quiere decir que debe poder adaptarse a las necesidades de
cualquier análisis de gestión de riesgos que se esté tratando,
por ejemplo: debe poder adaptarse a un análisis integral de
riesgos o riesgos a un proyecto.
Una de las principales tareas a realizar es identificar los
múltiples riesgos existentes ya sean factores internos o
externos.
Es posible identificar factores externos como los
siguientes: políticos, legales, competencia, desastres
naturales, entre otros.
Adicionalmente también se pueden identificar factores
internos como los siguientes: financieros, operacionales,
tecnológicos, entre otros.
Es importante que la organización tenga un compromiso
alto con el propósito de realizar este ejercicio y obtener los
insumos necesarios, generalmente una buena idea es reunirse
para tener una lluvia de ideas cuando tal vez no existe un
grado de madurez considerable para un ejercicio como este.
Otra técnica que es utilizada para la identificación de los
factores de riesgo es realizar un análisis FODA en donde las
debilidades y las amenazas serán revisadas y utilizadas como
insumos para realizar la identificación de los riegos.
Fig. 1. Ejemplo de RBS [3].
En la figura anterior se observan cada uno de los tipos de
riesgos identificados y de forma paralela hacia estos se
desglosan cada uno de los posibles riesgos que pueden
realizar alguna afectación en el ejemplo dado, que este caso
sería un proyecto.
III. COMPARATIVA DE PROGRAMAS WORK BREAKDOWN
SOFTWARE (WBS)
Existen diversidad de herramientas para la gestión de
riesgos, sin embargo, dentro de este documento se estarán
analizando dos soluciones de software Work Breakdown
Software que son Asana y Wrike.
Ambas fueron seleccionadas por su impacto y uso en el
mercado además de ser herramientas creadas en idioma
español lo cual facilita su entendimiento y evita
ambigüedades interpretativas en sus funcionalidades. Con
esta comparativa se ofrecen recomendaciones para considerar
los distintos factores que influyen en la selección de un
producto de software y facilita el análisis.
Para el análisis de estos programas se utilizan diferentes
características y funcionalidades del software el cual los hace
únicos en varios aspectos y sirven de fundamento para la
toma de decisiones.
 Funcionalidades: El producto debe tener, al menos,
las funcionalidades básicas necesarias requeridas por
la organización.
 Costos: Es importante considerar todos los costos
relacionados a una determinada solución, sea libre o
propietaria.
 Popularidad: Es importante conocer casos de éxito
que estén vinculados al tipo de organización o a la
aplicación que se esté buscando.
 Soporte: El soporte técnico es, en general, un buen
indicador, ya que implica que el producto tiene una
viabilidad a largo plazo. Otra forma de identificar
productos con una comunidad de soporte es evaluar la
disponibilidad de cursos, conferencias, libros y
revistas especializadas.
 Mantenimiento: Los cambios son necesarios, las
necesidades se van modificando y ningún programa
es completamente perfecto. El mantenimiento de un
software es importante y está muy vinculado al punto
anterior: “Soporte”
 Dependencia: Hace referencia al grado de
dependencia que tiene una organización respecto del
software o hardware ofrecido por un proveedor.
 Confiabilidad: La confiabilidad mide qué tanto una
aplicación funciona y produce el resultado esperado.
 Performance: Es importante saber que el producto a
utilizar tendrá una performance aceptable para el uso
que queremos darle, que los recursos necesarios de
infraestructura son razonables y que disponemos de
ellos.
 Escalabilidad: La escalabilidad en este contexto se
refiere a la capacidad de la aplicación de manejar un
cierto tamaño de problema o de cantidad de datos.
 Usabilidad: La usabilidad mide la calidad de la
interfaz aplicación-usuario. Una aplicación con buena
usabilidad permite aprender a usarla en forma rápida
y natural.
 Seguridad: Evaluar la seguridad de un producto no es
nada sencillo, en gran medida, porque muchas veces
depende del uso, del ambiente donde se implementa y
de los requerimientos necesarios para asegurar el
nivel de seguridad buscado.
 Flexibilidad: La flexibilidad del producto se refiere a
su capacidad de adaptarse o ser adaptado a
requerimientos que hoy no son contemplados, pero
que puede ser necesario incorporar en el futuro.
 Interoperabilidad: Es importante prever que la
aplicación pueda, al menos, interoperar con otros
sistemas que estén actualmente relacionados.
 Tipos de licencia y aspectos legales: Los aspectos
legales de un producto de software son importantes y
deben considerase en una comparación. Es
recomendable que antes de incorporar un producto, se
lean las condiciones legales, generalmente, definidas
en la licencia.
Teniendo presente todas las posibles características que
existen se procede a realizar una comparativa entre ambas
herramientas realizando el análisis como una organización
que desea adquirir un software que cumpla los siguientes
criterios:
 Poseer distintos planes de pago, mínimo dos que
son el pago mensual o que sea posible ajustarlo al
presupuesto.
 Tener distintos canales de soporte (correo, en línea,
otros)
 Ofrecer diversidad de licencias con el fin de tener
en cuenta el crecimiento a futuro de la organización
 Ser un software fácil de usar, que el tiempo de
capacitación a los colaboradores no sea superior a
dos días
 Permitir la integración de software externo como
Jira, Microsoft Teams y otros de importancia para la
organización.
Fig. 2. Comparación entre asana y wrike.
La tabla de comparación presenta de una manera clara y
resumida los resultados para cada uno de los factores de
comparación.
Para este caso se utilizarán las variables “Peso” y
“Puntaje”. Donde “Peso” indica las necesidades de la
empresa para utilizar el producto. Para esto haremos uso de
la siguiente escala 1= Poco necesaria, 2= necesaria, 3= muy
necesaria. Para “Puntaje” se usará una escala del 1 al 10
donde 1 es la valoración más baja y 10 la más alta para
indicar las características que ofrecen ambos softwares.
IV. BENEFICIOS DE APLICAR UN RBS EN EL PROYECTO
El principal beneficio de aplicar un RBS consiste en ser
proactivo a la atención de los riesgos del proyecto, con esto
las personas involucradas procuran disminuir los impactos en
tiempo o costo que pueden tener los mismos si llegarán a
ocurrir.
El proceso de identificación va a ir mejorando de forma
iterativa conforme avanza el proyecto, existentes guías como
la PMBOK que incluso recomiendan personal clave para ser
involucrados en estos procesos como usuarios finales,
clientes, personal del proyecto y el director de este [4]. Es
importante tener presente que esta recomendación puede
variar según el tamaño y tipo de proyecto.
La clasificación de los riesgos irá mejorando de forma
paralela, con esto pueden identificar cuáles objetivos o fases
del proyecto son los que generan más riesgos o incluso las
relaciones de un riesgo con el otro.
Los RBS permiten almacenar información adicional del
riesgo como el origen, la descripción del riesgo e incluso la
forma en que se puede mitigar el mismo de esta forma amplía
la transmisión de conocimiento entre las personas
involucradas en el proyecto según el nivel de accesibilidad
que posean.
Con estos beneficios los directores podrán tener fuentes
de conocimientos anteriores para aplicarlas en nuevos
proyectos y de esta forma buscar una eficiencia superior en
cada nueva experiencia.
V. RESULTADOS
En el mercado existen múltiples herramientas para la
gestión de riesgos en proyectos más allá de las dos que se
analizaron en el documento. Sus funcionalidades y beneficios
pueden ser muy distintos de una versión gratuita a una paga.
Cada proyecto posee sus propias diferencias en temas
como lo son requisitos, presupuestos y alcances que se tienen
de la herramienta a implementar.
Por este motivo, se recomienda analizar un conjunto de
requisitos que deben ser tomados en cuenta antes de tomar la
decisión de implementar alguna herramienta, son los
siguientes:
 Formato del software (Web, aplicación móvil,
aplicación de escritorio): Cada uno de estos
ambientes posee sus ventajas y desventajas, por esto
necesario saber cuál se ajusta mejor al modelo de
negocio.
 Versión de paga o gratuita: Cada herramienta brinda
soluciones a diversas necesidades y varias de sus
acciones pueden estar limitadas a algún tipo de plan.
Es por este motivo que es indispensable tener
identificadas las necesidades actuales existentes del
negocio y esta lista compararla contra las opciones
que nos brindan las herramientas. Para facilidad de
sus clientes empresas como Asana y Wrike facilitan
la opción “Comparar precios” en la cual muestran
todos sus planes, qué ofrecen cada uno, sus
limitaciones y mucho más.
 Escalabilidad: Se debe buscar una herramienta que
se acople al crecimiento de la organización en el
futuro y que su oferta no sobrepase el presupuesto
destinado al mismo.
 Cobertura de la aplicación: Es importante tener
identificado qué se espera de la aplicación en
diversos temas como por ejemplo la seguridad,
diversidad de perfiles, reportes y más.
Tomando en cuenta los requisitos mencionados y con
base en el análisis realizado entre la comparación de ambas
herramientas se recomienda el uso de la herramienta Wrike
para aquellas organizaciones que desean una herramienta que
cumpla con las necesidades esenciales para la gestión de
riesgos, así como también les brinde otros beneficios como el
soporte, diversidad de planes y costos.
REFERENCIAS
[1] IEC 31010, Risk management — Risk assessment techniques
[2] N. Estruga, “Qué es la estructura de desglose de riesgos (RBS) de un
proyecto”, EALDE Business School, 21-sep-2021. [En línea].
Disponible en: https://www.ealde.es/estructura-de-desglose-de-
riesgos-de-un-proyecto/. [Consultado: 30-01-2023].
[3] “Como crear una Efectiva Matriz de Riesgos en tan solo 3 Pasos”,
CEOLEVEL, 08-nov-2016. [En línea]. Disponible en:
https://www.ceolevel.com/como-crear-una-efectiva-matriz-de-riesgos-
en-tan-solo-3-pasos. [Consultado: 10-02-2023].
[4] Project Management Institute, Guia de los Fundamentos de la
Direccion de Proyectos, 3a ed. Project Management Institute, 2005.