Delivery Roadmap v4 (ES)

La compañía de software de agilidad operacional
Blue Prism
Hoja de ruta de entrega
info@blueprism.com • +44 (0)870 879 3000 • Centrix House, Crow Lane East, Newton-le-Willows, WA12 9UY
Información comercial confidencial

La información contenida en este documento es propiedad e información confidencial de Blue Prism

Limited y no debe divulgarse a terceros sin el consentimiento por escrito de un representante autorizado
de Blue Prism. Ninguna parte de este documento puede ser reproducida o transmitida de ninguna forma o
de ningún modo, electrónico o mecánico, que incluye realizar fotocopias, sin el permiso por escrito de Blue
Prism Limited.
© Blue Prism Limited
Todas las marcas registradas se aceptan y se usan para el beneficio de sus respectivos dueños.
Publicado por:
Blue Prism Limited

Centrix House
Crow Lane East
Newton-le-Willows
WA12 9UY, Reino Unido
Registrado en Inglaterra, n.° reg. 4260035
www.blueprism.com
Tel.: 0870 879 3000

1 Resumen
Este documento describe en un alto nivel de detalle los diferentes pasos necesarios para llevar a
producción una solución de proceso de Blue Prism. Está respaldado por una solución de Blue
Prism completa con documentación de entrega. La documentación de entrega utiliza siete
plantillas de Blue Prism. Estas plantillas no son obligatorias en todas las implementaciones del
proceso. Simplemente ilustran los diversos contenidos y detalles que se requieren en cada fase de
la entrega. Un marco local de Blue Prism de la empresa determinará la documentación de entrega.
Se estima que este contenido reflejará lo que se describe en la hoja de ruta, aunque su
orquestación puede ser diferente. Por ejemplo, algunos clientes de Blue Prism usan su propia
documentación de proceso en lugar de PDD, mientras que otras resumen el contenido de OID y
FRQ dentro de PDD.
En la solución de ejemplo se utiliza como aplicación objetivo un sitio web ficticio denominado BP
Travel, al que se accede a través de blueprism.com. Todo el material de asistencia está disponible
para descargar en el portal de Blue Prism e incluye:
• Solución Blue Prism: procesos, objetos, colas de trabajo, variables de entorno y plantillas
de informes.
• Análisis del proceso inicial (IPA)
• Documento de definición del proceso (PDD)
• Cuestionario de requisitos funcionales (FRQ)
• Documento de diseño de solución (SDD)
• Documento de impacto operacional (OID)
• Instrucciones para el diseño del proceso (Process Design Instruction, PDI)
• Instrucción del diseño del objeto (ODI)
1.1 Referencias
Este documento hará referencia al siguiente material, que puede descargarse del portal de Blue
Prism:
Plantillas
IPA: descargue el material en el portal: Methodology – Templates – Process Management

(Metodología - Plantillas - Gestión de proceso)
PDD, FRQ, SDD, OID, PDI, ODI: descargue el material en el portal: Methodology – Templates –
Delivery Methodology(Metodología - Plantillas - Metodología de entrega)
Documentos de ejemplo
Descargue los documentos en el portal: Learning – Lifecycle Documentation – Delivery

Documentation (Aprendizaje - Documentación de ciclo de vida - Documentación de entrega)

1.2 Marco
El marco de Blue Prism es una combinación de la infraestructura técnica (lo que incluye seguridad
y dirección) y el modelo operativo (lo que incluye gestión de procesos, gestión de entrega y
asistencia operativa).
La infraestructura técnica brinda un entorno técnico estructurado y escalable para la entrega de

procesos de conformidad con la política de seguridad corporativa. El modelo operativo brinda un
modelo controlado, estructurado y que puede usarse de forma repetida para identificar, priorizar,
entregar y asistir la entrega de procesos, además de sostener y mejorar permanentemente los
procesos automatizados en el entorno operativo.
Esta hoja de ruta de entrega atraviesa las siguientes etapas:
• Gestión de proceso
• Definición
• Diseño
• Desarrollo
• Evaluación

2 Gestión de proceso
2.1 Análisis del proceso inicial

Durante la evaluación de oportunidad, surgirá una lista de candidatos que, tras un ejercicio de
priorización, requerirá un análisis del proceso inicial (Initial Process Analysis, IPA) para poder ser
considerados para su implementación.
Un IPA es una forma de enmarcar la información disponible en la primera etapa de un proyecto en

un documento conciso que ilustra los puntos salientes.
Autor: un analista o desarrollador de Blue Prism

Revisión: patrocinador del cliente
Aprobación: no requiere aprobación específica
El objetivo del IPA es brindar un análisis de alto nivel de la solución del proceso, la eficiencia de la
automatización (la cantidad de trabajo que puede ser realizado por un robot) y los esfuerzos
involucrados en la entrega y el soporte de una solución. Solo se requiere una perspectiva de alto
nivel del proceso comercial. De forma similar, solo se necesita una descripción básica de la
solución propuesta.
El análisis debe tener en cuenta:
• La solución propuesta
• Métricas del proceso
• Requisitos previos de desarrollo
• Esfuerzos de entrega
• Tasas de derivaciones y excepciones
• Requisitos del entorno de producción
• Requisitos y esfuerzos de asistencia para una situación normal
El IPA también destacará los lugares en los que falta información detallada, en tanto la evaluación
de factor clave identificará las áreas de riesgo y los lugares en los que se requiere un análisis de
proceso refinado (RPA).
Referencia
• En el portal de Blue Prism se encuentra disponible una plantilla de IPA.

• En el portal también se ofrece un IPA de ejemplo basado en el proceso de BP Travel.

3 Definición
3.1 Documento de definición del proceso

El principal propósito de un documento de definición del proceso (Process Definition Document,
PDD) es describir el proceso manual que debe automatizarse. El PDD solo debe crearse si no hay
documentación sobre un proceso ya existente o está suficientemente detallada.
Creación: experto del cliente y/o analista de Blue Prism

Revisión: experto del cliente, analista de Blue Prism, desarrollador de Blue Prism
Aprobación: área de operaciones del cliente, experto del cliente.
Detalles del proceso
Un robot no puede pensar por sí mismo y solo puede seguir un conjunto de pasos lógicos
predefinidos. Por lo tanto, un PDD debe ir más allá del nivel de detalle que habitualmente se brinda
a un ser humano y especificar exactamente cómo debe llevarse adelante el proceso. Debe
incluirse un diagrama con descripciones de cada etapa.
La documentación de un proceso ya existente no puede escribirse desde el punto de vista de un

robot. Esta documentación puede contener decisiones subjetivas que parecen simples para el
lector, pero que un robot tendrá dificultades para interpretar. Tales ambigüedades deben
resolverse en el PDD.
El diseño de una solución de Blue Prism estará basado en el PDD. Por lo tanto, cuanto más
explícito sea este documento, mayor será la probabilidad de lograr una entrega exitosa.
Detalles de la aplicación
Deben suministrarse capturas de pantallas de la aplicación y descripciones de cada paso, con

anotaciones aplicadas a las imágenes de ser necesario. También deben explicarse los mensajes
emergentes o de advertencia del sistema que puede aparecer.
No hay que suponer que el desarrollador del proceso automatizado tiene conocimientos previos
sobre las aplicaciones involucradas. Por ende, cuanto mayor sea el nivel de detalle en cuanto al
comportamiento de las aplicaciones mejor.
Referencia
En el portal de Blue Prism se ofrece un tutorial sobre cómo crear un PDD.

En el portal también están disponibles un PDD de ejemplo y una plantilla de PDD
En el portal de Blue Prism también se ofrece un PDD de ejemplo basado en el proceso de BP Travel.

3.2 Recorrido del proceso
Participantes: experto del cliente, analista de Blue Prism, desarrollador de Blue Prism (opcional)
Una vez que se ha definido un proceso, la calidad del PDD puede medirse mediante un manual de
instrucciones paso a paso. Un PDD perfecto debe permitir que un novato sin conocimientos
previos de un proceso comercial pueda trabajar en los casos correctamente.
Durante el recorrido, se trabajan varios ejemplos aleatorios de casos siguiendo de forma precisa el
flujo y las reglas que se definen en el PDD. Esto permite detectar cualquier finalidad faltante,
ambigüedades o flujos incorrectos.
Si el recorrido revela brechas en la definición del proceso, el PDD puede modificarse para agregar
detalles adicionales. Es posible que se requiera un nuevo recorrido, según la magnitud de los
cambios.
3.3 Cuestionario de requisitos funcionales
Participantes: experto del cliente, analista de Blue Prism
El PDD capturará los pasos del proceso y todo lo relacionado con la funcionalidad para permitir
que la solución del proceso se ejecute sin supervisión y a la vez satisfaga las exigencias de la
empresa que deben definirse. El cuestionario de requisitos funcionales (FRQ) ofrece una lista de
control rápida acerca de los detalles requeridos y las áreas a considerar.
• Carga de trabajo
• Requisitos del recurso
• Acuerdos a nivel del servicio
• Horas de funcionamiento
• Generación de alertas
• Gestión de datos
• Reenvío de excepciones
• Información gerencial y otros informes
• Conservación de datos
• Continuidad comercial
Estos requisitos funcionales, junto con el PDD, se incorporan al diseño de la solución.
Referencia
En el portal de Blue Prism se encuentra disponible una plantilla de FRQ.

En el portal de Blue Prism también se ofrece un FRQ a modo de ejemplo basado en el proceso
de BP Travel.

4 Diseño
4.1 Documento de diseño de solución

La finalidad del documento de diseño de la solución (Solution Design Document, SDD) es describir
la forma en que Blue Prism automatizará el proceso descrito en el PDD.
Creación: desarrollador de Blue Prism

Revisión: área de operaciones del cliente, TI
Aprobación: área de operaciones del cliente, TI
El SDD está diseñado para brindar a la empresa y al área de TI suficiente información detallada
acerca del proceso automatizado para que se comprenda y en última instancia se apruebe la
solución propuesta. Es fundamental que este documento no se explaye en los detalles de menor
nivel sobre cómo se desarrollarán los procesos y objetos comerciales de Blue Prism, pues esto
puede impedir que el cliente apruebe el diseño con confianza. Estos detalles se reservan para las
instrucciones para el diseño del proceso y el objeto de Blue Prism.
Además de describir la solución automatizada, el SDD debe incluir detalles de todos los productos
finales a entregar, como los servicios web, las tablas de bases de datos, los archivos de entrada,
las carpetas de red, etc. También deben mencionarse otros derivados tales como requisitos de
seguridad, generación de alertas, información gerencial y manejo de excepciones.
El SDD incluye una descripción de
• Resumen de la solución de extremo a extremo

• Modelo del objeto
• Control operacional y generación de alertas
• Seguridad de datos y credenciales
• Premisas comerciales y técnicas
Referencia
En el portal de Blue Prism se encuentra disponible una plantilla de SDD.

En el portal de Blue Prism también se ofrece un SDD a modo de ejemplo basado en el proceso
de BP Travel.
4.2 Documento de impacto operacional

El documento de impacto operacional (Operational Impact Document, OID) se requiere para
informar al equipo de operaciones del cliente de sus responsabilidades cuando se establece la
solución automatizada. Se trata de una descripción acerca de los cambios que los afectarán una
vez que la solución se haya implementado correctamente.

El OID solo se requiere si el PDD no define explícitamente el impacto posoperacional en la

empresa.
Creación: analista de Blue Prism

Revisión: área de operaciones del cliente, controlador de Blue Prism
Aprobación: área de operaciones del cliente
Puede haber un efecto en áreas de la empresa incluidas en el flujo de trabajo de la solución

automatizada, como por ejemplo las áreas que tratan con casos de excepción. De forma similar,
también puede ser necesario hacer modificaciones en niveles superiores a la solución
automatizada, como por ejemplo en la forma en que las tareas se ingresan en Blue Prism. El OID
explica los requisitos operativos, de recursos y de TI de la empresa que utilizará la solución
automatizada.
Una vez que el documento de diseño de la solución y el documento de impacto operacional se

hayan aprobado, puede iniciarse el diseño más detallado y de menor nivel.
Referencia
En el portal de Blue Prism se ofrece un OID a modo de ejemplo basado en el proceso de BP

Travel.
4.3 Recorrido de la solución
Taller
Participantes: experto del cliente, área de operaciones del cliente, analista de Blue Prism,
desarrollador de Blue Prism
Así como es necesario interpretar el PDD, también debe llevarse a cabo un taller para recorrer el
SDD y el OID a fin de verificar la solución automatizada propuesta y sus efectos en toda la
empresa.
Al igual que con el recorrido por PDD, la prueba puede revelar deficiencias en la solución que
requerirán un nuevo análisis y un cambio en el diseño.
4.4 Instrucciones para el diseño del proceso

Revisión: desarrolladores de Blue Prism
Aprobación: revisión de pares

Las instrucciones para el diseño del proceso (PDI) representan un modelo para desarrollar un
proceso. La información de menor nivel que no incluye en el SDD por cuestiones de claridad debe
incluirse en el PDI.
Si bien el PDD puede describir un proceso comercial, en pos de la eficiencia y la escalabilidad

puede requerir más de un proceso de Blue Prism. Debe crearse un PDI para todos los procesos de
Blue Prism a crear. El PDI debe describir detalladamente el proceso de Blue Prism y todos los
elementos (componentes, objetos comerciales, colas de trabajo, bloqueos de entorno, variables de
entorno, etc.) que admite. También debe incluirse la lógica para trabajar cada tipo de caso, junto
con instrucciones sobre la forma de manejar diferentes tipos de excepciones.
Un PDI completo formará una tarea de trabajo para el desarrollador.
Referencia
En el portal de Blue Prism se ofrece una plantilla de un PDI.

En el portal de Blue Prism también se ofrece un PDI a modo de ejemplo basado en el proceso de
BP Travel.
4.5 Instrucciones del diseño del objeto

Al igual que el PDI, las instrucciones de diseño del objeto (ODI) se crean a manera de modelo para
desarrollar objetos comerciales. Las instrucciones de diseño del objeto describen cada objeto a
construir. Para cada acción incluida en ese objeto, se enumeran los parámetros de entrada y
salida y las pantallas de inicio y fin.

Revisión: desarrolladores de Blue Prism
Aprobación: revisión de pares
Referencia
En el portal de Blue Prism se encuentra disponible una plantilla de ODI.

En el portal de Blue Prism también se ofrece un ODI a modo de ejemplo basado en el proceso de
BP Travel.

5 Creación
El alcance de este documento no incluye instrucciones para desarrollar una solución de Blue
Prism. Las guías para la creación de procesos y objetos están disponibles en otras secciones del
portal de Blue Prism.
Los objetos del documento ODI deben desarrollarse primero, y luego los procesos. Dado que
habitualmente hay múltiples objetos, pueden participar múltiples desarrolladores en el desarrollo
de objetos. No obstante, en un proceso solo puede trabajar un desarrollador a la vez.
Al crear procesos de Blue Prism deben usarse las plantillas de proceso de Blue Prism.
Durante la implementación del marco de Blue Prism, se acordará una autoridad de diseño local
que estará a cargo del control del diseño y las mejores prácticas de desarrollo. La revisión por
parte de los pares y colegas es esencial en etapas periódicas de la fase de desarrollo para
garantizar la calidad.
Al finalizar el desarrollo de cada objeto y proceso, la prueba de configuración o unidad de tarea es

llevada a cabo por el desarrollador.
Referencia
En el portal de Blue Prism se encuentra disponible para descargar una edición de Blue Prism de
una solución completa con procesos, objetos, colas de trabajo, variables de entorno y plantillas
de informes.

6 Evaluación
Dado que la terminología utilizada para describir las fases de prueba y evaluación puede diferir
entre los clientes, en este documento se usarán términos genéricos en un intento por evitar
cualquier posible confusión acerca de términos como “validación”, “verificación”, “pruebas en vivo”
y “UAT”. Las siguientes fases forman el punto de inicio a partir del cual se acuerda un enfoque de
prueba local durante la implementación del marco de Blue Prism. La agilidad de la plataforma Blue
Prism permite que las pruebas se realicen durante el desarrollo. Los desarrolladores solo dejan de
estar involucrados al llegar a la fase de prueba 3.
Fase 1
Ejecución: desarrollador de Blue Prism, evaluador de Blue Prism y experto del cliente (opcional)
Modo de ejecución de Blue Prism: Process Studio y sala de control
Entorno de Blue Prism: desarrollo
Entorno de sistema objetivo: prueba
Criterio de aceptación: script de prueba
En esta fase, el evaluador/experto y el desarrollador trabajan juntos para demostrar que la solución
cumple con la definición de proceso capturada (PDD).
El evaluador crea escenarios en el entorno de prueba que validan el proceso a lo largo de las
diferentes rutas de proceso. Comenzando en Process Studio de Blue Prism, los casos se recorren
y, a medida que crece la confianza en la solución, puede aumentarse la velocidad del proceso
hasta que finalmente se ejecute a máxima velocidad. En este punto pueden brindarse
estimaciones acerca del tiempo de procesamiento de los casos.
Esta es la etapa en la que se vislumbra la calidad del documento PDD. Tanto el script de prueba
del experto como el trabajo del desarrollador se basan en la definición del proceso original. Si esa
definición es precisa y abarcativa, esta fase de evaluación debe ejecutarse sin problemas.
Sin embargo, en esta etapa pueden encontrarse nuevos escenarios no mencionados en el PDD. Si
esto ocurre, es posible que la evaluación deba detenerse mientras se identifica una resolución
para el escenario, se modifica el desarrollo y se actualiza la documentación.
Una vez que el evaluador esté satisfecho con los scripts aprobados, la evaluación puede avanzar
a la siguiente fase.
Fase 2
Ejecución: desarrollador de Blue Prism, evaluador de Blue Prism y experto del cliente
Modo de ejecución de Blue Prism: Process Studio y sala de control
Entorno de Blue Prism: desarrollo
Entorno de sistema objetivo: en vivo
Criterio de aceptación: script de prueba

Esta fase de evaluación es básicamente la repetición de la última fase, pero con una diferencia
sustancial. Donde antes se usaron sistemas de prueba, ahora las evaluaciones se realizarán con
datos en vivo. La presencia de un experto es obligatoria para confirmar el procesamiento, pues los
datos están vinculados con el sistema.
La evaluación se realiza mayormente en Process Studio y, a diferencia de la fase anterior en la

que los escenarios estaban hechos para permitir que el evaluador probara la solución en
comparación con el PDD, ahora los casos se seleccionan de forma aleatoria. Los scripts de prueba
enumeran todos los escenarios diferentes que deben evaluarse con datos en vivo, y esto puede
verificarse a medida que el proceso trabaja con los casos en vivo.
Solo los procesos más básicos capturados en un PDD serán completamente abarcativos. Debe
partirse de la premisa de que hay escenarios y respuestas del sistema que se desconocen y que
solo quedarán expuestos con datos en vivo. A medida que avanza esta fase de evaluación, será
posible capturarlos, corregirlos y volver a evaluarlos.
Esta fase puede evolucionar hasta convertirse en un ciclo de evaluación y corrección a medida
que el evaluador, el experto y el desarrollador encuentran y aplican correcciones a la solución. En
teoría, se trata de cambios menores que pueden aplicarse de forma segura en esta fase de
evaluación. Sin embargo, si se identifican brechas de importancia en el alcance y se requiere una
revisión extensa, la entrega deberá regresar temporalmente a la fase de desarrollo.
Una vez que los scripts de prueba hayan sido probados con los datos en vivo, la solución puede
implementarse en el entorno de evaluación y la evaluación puede avanzar a la fase siguiente.
Fase 3
Ejecución: evaluador de Blue Prism y experto del cliente

Modo de ejecución de Blue Prism: solo sala de control
Entorno de Blue Prism: evaluación
Entorno de sistema objetivo: en vivo
Criterios de aceptación: metas de calidad, volumen y funcionamiento
En esa fase, la solución del proceso se implementa en el entorno de evaluación para la prueba de
aceptación final.
Esta fase consiste básicamente en comprobar que la solución pueda manejar un aumento de
volumen y en agregar mayores volúmenes al proceso para dejar expuestos los defectos o
problemas de entorno o funcionamiento que puedan persistir. A esta altura, la evaluación debe
haber demostrado que la solución es sólida y que no es probable que se necesiten más
correcciones. En el entorno de evaluación no pueden hacerse cambios en la solución. Todos los
defectos deben informarse, y las correcciones deben aplicarse y evaluarse en el entorno de
desarrollo. Para las correcciones menores, es posible omitir la fase 2 y migrar una nueva versión al
entorno de evaluación.
El proceso se ejecuta solo en la sala de control de Blue Prism. Durante esta fase, es imperativo
manejar de forma estricta los volúmenes de casos y controlar la calidad. Pueden introducirse
múltiples fases secundarias. Cada fase secundaria tendrá sus propios criterios de calidad y
aceptación, como por ejemplo al trabajar con 100 casos con 100% de control de calidad sin
encontrar defectos. A medida que la fase de evaluación demuestra la calidad de la solución, los

volúmenes pueden aumentarse gradualmente y se podrá controlar la calidad mediante

inspecciones aleatorias hasta que finalmente se satisfagan los criterios de aceptación.
Una vez que todos los criterios de aceptación se hayan cumplido, se presenta un informe de
evaluación completo al área de operaciones del cliente para su aprobación antes de que el
proceso pueda implementarse en la etapa de producción.
6.1 Resumen de las fases de creación y evaluación
7 Hoja de ruta

Delivery Roadmap v4 (ES)

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Delivery Roadmap v4 (ES)

Cargado por

Copyright:

Formatos disponibles

La compañía de software de agilidad operacional

Información comercial confidencial

La información contenida en este documento es propiedad e información confidencial de Blue Prism

Blue Prism Limited

Información comercial confidencial

IPA: descargue el material en el portal: Methodology – Templates – Process Management

Descargue los documentos en el portal: Learning – Lifecycle Documentation – Delivery

Información comercial confidencial

La infraestructura técnica brinda un entorno técnico estructurado y escalable para la entrega de

Esta hoja de ruta de entrega atraviesa las siguientes etapas:

Información comercial confidencial

2.1 Análisis del proceso inicial

Un IPA es una forma de enmarcar la información disponible en la primera etapa de un proyecto en

Autor: un analista o desarrollador de Blue Prism

El análisis debe tener en cuenta:

• En el portal de Blue Prism se encuentra disponible una plantilla de IPA.

Información comercial confidencial

3.1 Documento de definición del proceso

Creación: experto del cliente y/o analista de Blue Prism

Detalles del proceso

La documentación de un proceso ya existente no puede escribirse desde el punto de vista de un

Deben suministrarse capturas de pantallas de la aplicación y descripciones de cada paso, con

En el portal de Blue Prism se ofrece un tutorial sobre cómo crear un PDD.

Información comercial confidencial

3.2 Recorrido del proceso

3.3 Cuestionario de requisitos funcionales

Participantes: experto del cliente, analista de Blue Prism

En el portal de Blue Prism se encuentra disponible una plantilla de FRQ.

Información comercial confidencial

4.1 Documento de diseño de solución

Creación: desarrollador de Blue Prism

El SDD incluye una descripción de

• Resumen de la solución de extremo a extremo

En el portal de Blue Prism se encuentra disponible una plantilla de SDD.

4.2 Documento de impacto operacional

Información comercial confidencial

El OID solo se requiere si el PDD no define explícitamente el impacto posoperacional en la

Creación: analista de Blue Prism

Puede haber un efecto en áreas de la empresa incluidas en el flujo de trabajo de la solución

Una vez que el documento de diseño de la solución y el documento de impacto operacional se

En el portal de Blue Prism se ofrece un OID a modo de ejemplo basado en el proceso de BP

4.3 Recorrido de la solución

4.4 Instrucciones para el diseño del proceso

Creación: desarrollador de Blue Prism

Información comercial confidencial

Si bien el PDD puede describir un proceso comercial, en pos de la eficiencia y la escalabilidad

Un PDI completo formará una tarea de trabajo para el desarrollador.

En el portal de Blue Prism se ofrece una plantilla de un PDI.

4.5 Instrucciones del diseño del objeto

Creación: desarrollador de Blue Prism

En el portal de Blue Prism se encuentra disponible una plantilla de ODI.

Información comercial confidencial

Al finalizar el desarrollo de cada objeto y proceso, la prueba de configuración o unidad de tarea es

Información comercial confidencial

Información comercial confidencial

La evaluación se realiza mayormente en Process Studio y, a diferencia de la fase anterior en la

Ejecución: evaluador de Blue Prism y experto del cliente

Información comercial confidencial

volúmenes pueden aumentarse gradualmente y se podrá controlar la calidad mediante

6.1 Resumen de las fases de creación y evaluación

Información comercial confidencial

También podría gustarte