Delivery Roadmap (ES)

Machine Translated by Google
La empresa de software de agilidad operativa
prisma azul
Hoja de ruta de entrega
info@blueprism.com • +44 (0)870 879 3000 • Casa Centrix, Crow Lane East, Newton-le-Willows, WA12 9UY
Comercial en confidencia
La información contenida en este documento es propiedad 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
reproducirse ni transmitirse de ninguna forma ni por ningún medio, electrónico o mecánico, incluidas las fotocopias, sin el permiso
por escrito de Blue Prism Limited.
© Blue Prisma Limited
Todas las marcas comerciales se reconocen y se utilizan en beneficio de sus respectivos propietarios.
Publicado por:
Prisma azul limitada

Casa central
Cuervo carril este
Newton-le-Willows
WA12 9UY, Reino Unido
registrado en Inglaterra; registro Nº 4260035
www.blueprism.com
Teléfono: 0870 879 3000
1. Información general
Este documento describe a un alto nivel los diversos pasos para llevar a producción una solución de
proceso de Blue Prism. Está respaldado por una solución Blue Prism completa con documentación de
entrega. La documentación de entrega utiliza siete plantillas de Blue Prism. Estos no son obligatorios en
todas las implementaciones de procesos. Ilustran los diversos contenidos y detalles requeridos en cada
fase de la entrega. El Blue Prism Framework local de una empresa prescribirá la documentación de entrega
real. Se espera que este contenido refleje lo descrito en esta hoja de ruta de entrega, sin embargo, su
orquestación puede ser diferente. Por ejemplo, algunos clientes de Blue Prism usan su propia documentación
de proceso en lugar del PDD y otros envuelven el contenido de OID y FRQ dentro del PDD.
La solución de muestra utiliza como aplicación de destino un sitio web de viajes ficticio llamado BP Travel
al que se accede a través de www.blueprism.com. Todo el material de apoyo está disponible para su
descarga desde 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 de Proceso Inicial (IPA)
• Documento de Definición de Proceso (PDD)
• Cuestionario de Requerimientos Funcionales (FRQ)
• Documento de diseño de solución (SDD)
• Documento de Impacto Operacional (OID)
• Instrucción de Diseño de Procesos (PDI)
• Instrucción de Diseño de Objetos (ODI)
1.1 Referencias
Este documento hará referencia a lo siguiente que se puede descargar del Portal de Blue Prism:
Plantillas
IPA: descarga desde el Portal en Metodología – Plantillas – Gestión de Procesos
PDD, FRQ, SDD, OID, PDI, ODI: descarga desde el Portal en Metodología – Plantillas –
Metodología de entrega
Documentos de muestra
Descargar desde el Portal en Aprendizaje – Documentación del ciclo de vida – Documentación de entrega
1.2 Marco
Blue Prism Framework es una combinación de la infraestructura técnica (que incluye seguridad y
gobierno) y el modelo operativo (que incluye gestión de procesos, gestión de entrega y soporte operativo).
El elemento de infraestructura técnica proporciona un entorno técnico estructurado y escalable para la

entrega de procesos de acuerdo con la política de seguridad corporativa. El modelo operativo proporciona
un modelo repetible, estructurado y controlado para identificar, priorizar, entregar y respaldar la entrega
de procesos, además de mantener y mejorar continuamente los procesos automatizados en el entorno
operativo.
Esta hoja de ruta de entrega navega a través de las siguientes etapas:
• Gestión de Procesos
• Definir
• Diseño
• Desarrollar
• Prueba
2 Gestión de Procesos
2.1 Análisis del proceso inicial

Durante la evaluación de oportunidades, surgirá una lista de procesos candidatos que, luego de un ejercicio de
priorización, requerirán un análisis de proceso inicial (IPA) antes de que puedan ser considerados para su
implementación.
Un IPA es un medio de enmarcar la información disponible en la etapa inicial de un proyecto en un documento

sucinto que ilustra los puntos más destacados.
Creado por: analista de Blue Prism o desarrollador de Blue Prism
Leído por – Patrocinador del cliente
Aprobado por – No requiere aprobación específica
El objetivo del IPA es proporcionar un análisis de alto nivel de la solución del proceso, la eficiencia de la
automatización (cuánto del trabajo puede realizar un robot) y el esfuerzo involucrado en la entrega y soporte
de la solución. Solo se requiere una descripción general de alto nivel del proceso comercial y, de manera similar,
solo se necesita un esquema básico de la solución propuesta.
El análisis debe considerar:
• La solución propuesta
• Métricas de proceso
• Requisitos para el desarrollo
• Esfuerzo de entrega
• Excepciones y tasas de referencia
• Requisitos del entorno de producción
• Requerimientos y esfuerzo de soporte de BAU
El IPA también resaltará dónde falta la información existente en detalle y la Evaluación de Factores Clave
identificará las áreas de riesgo y dónde se requiere un Análisis de Proceso Refinado.
Referencia
• Hay una plantilla IPA disponible en el Portal de Blue Prism.
• Un ejemplo de IPA, basado en el proceso de viajes de BP, está disponible en el portal de Blue Prism.
3 Definir
3.1 Documento de definición de procesos

El propósito principal de un Documento de Definición de Proceso (PDD) es describir el proceso manual que se va
a automatizar. El PDD solo debe crearse cuando la documentación del proceso existente no existe o no se
proporciona con el detalle requerido.
Creado por – SME cliente y/o analista de Blue Prism
Leído por: pyme cliente, analista de Blue Prism, desarrollador de Blue Prism
Aprobado por – Operación cliente, PYME cliente.
Detalle 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 normalmente se proporciona a un ser humano y
especificar exactamente cómo se llevará a cabo el proceso. Se debe incluir un diagrama y descripciones de cada
etapa del diagrama.
Es posible que la documentación del proceso existente no esté escrita desde la perspectiva de un robot.
Puede contener decisiones subjetivas que parecen simples para el lector, pero que un robot tendrá dificultades
para interpretar tales decisiones. Tales ambigüedades deben ser resueltas en el PDD.
El diseño de una solución de Blue Prism se basará en el PDD, por lo que cuanto más explícito sea el PDD,
mayores serán las posibilidades de una entrega exitosa.
Detalle de la aplicación
Se deben proporcionar capturas de pantalla de la aplicación y descripciones de cada paso, con anotaciones
aplicadas a las imágenes cuando sea necesario. También se debe explicar cualquier mensaje de advertencia
del sistema, mensajes emergentes que puedan aparecer.
No se debe suponer que el desarrollador del proceso automatizado tendrá conocimiento previo de las
aplicaciones involucradas, por lo que cuantos más detalles sobre el comportamiento de las aplicaciones
proporcionadas, mejor.
Referencia
Un tutorial sobre cómo crear un PDD está disponible en el portal de Blue Prism.
Hay una muestra de PDD y una plantilla de PDD disponibles en el portal de Blue Prism
Un PDD de ejemplo, basado en el proceso de viajes de BP, está disponible en el portal de Blue Prism.
3.2 Tutorial del proceso

Participantes: pyme cliente, desarrollador de Blue Prism, analista de Blue Prism (opcional)
Una vez que se ha definido un proceso, se puede medir la calidad del PDD usándolo como un manual de
instrucciones paso a paso. Un PDD perfecto permitiría a un novato sin conocimiento previo de un proceso
comercial trabajar los casos correctamente.
Durante el recorrido se trabaja una muestra aleatoria de casos siguiendo con precisión el flujo y las reglas
definidas en el PDD. Esto expondrá cualquier alcance faltante, ambigüedad o flujo incorrecto.
Si el tutorial revela lagunas en la definición del proceso, el PPD se puede revisar con detalles
adicionales. Es posible que se requiera otro tutorial, según la escala de los cambios.
3.3 Cuestionario de requisitos funcionales

Participantes: pyme cliente, analista de Blue Prism
El PDD capturará los pasos del proceso, pero será necesario definir toda la funcionalidad integral para
permitir que la solución del proceso se ejecute sin supervisión mientras cumple con las demandas del
negocio. El Cuestionario de requisitos funcionales (FRQ) proporciona una lista de verificación rápida de los
detalles requeridos y las áreas a considerar.
• Carga de trabajo
• Requerimiento de recursos
• Acuerdos de nivel de servicio
• Horario de atención
• Alertar
• Gestión de datos
• Reenvío de excepciones
• Información de gestión y otros informes

• Conservación de datos
• Continuidad del Negocio

Estos requisitos funcionales junto con el PDD se incorporarán al diseño de la solución.
Referencia
Una plantilla FRQ está disponible en el Portal de Blue Prism.

Un FRQ de ejemplo, basado en el proceso de viajes de BP, está disponible en el portal de Blue Prism.
4 diseño
4.1 Documento de diseño de la solución

El propósito del Documento de diseño de la solución (SDD) es describir cómo Blue Prism automatizará el
proceso descrito en el PDD.
Creado por: desarrollador de Blue Prism
Leído por: operaciones del cliente, TI
Aprobado por: operaciones del cliente, TI
El SDD tiene como objetivo transmitir a la empresa y a TI suficientes detalles del proceso automatizado para
que comprendan y, en última instancia, aprueben la solución propuesta. Fundamentalmente, no debe entrar
en detalles de bajo nivel sobre cómo se desarrollarán los procesos y objetos comerciales de Blue Prism, ya que es
probable que esto nuble la capacidad del cliente para aprobar el diseño con confianza.
Este detalle está reservado para la Instrucción de diseño de procesos y la Instrucción de diseño de objetos
de Blue Prism.
Además de describir la solución automatizada, el SDD debe incluir detalles de cualquier otra
entregables que se requieren, como servicios web, tablas de bases de datos, archivos de entrada, carpetas de
red, etc. También se deben mencionar otros derivados, como requisitos de seguridad, programación, alertas,
información de gestión y procedimientos de manejo de excepciones.
El SDD incluye una descripción de
• Descripción general de la solución de extremo a extremo
• Modelo de objetos
• Control operativo y alertas
• Seguridad de datos y credenciales
• Supuestos comerciales y técnicos
Referencia
Hay una plantilla de SDD disponible en el Portal de Blue Prism.
Un SDD de ejemplo, basado en el proceso de viajes de BP, está disponible en el portal de Blue Prism.
4.2 Documento de Impacto Operacional

Se requiere el Documento de Impacto Operacional (OID) para informar al equipo de operaciones del cliente sobre
sus responsabilidades una vez que se implemente la solución automatizada. Es una descripción del cambio que les
afectará una vez que la solución se haya implementado con éxito.
El OID solo se requiere si el PDD no describe explícitamente el impacto posterior a la operación en el negocio.
Creado por – Analista de Blue Prism
Lectura por: operación del cliente, controlador Blue Prism
Aprobado por – Operación del cliente
Puede haber un efecto en áreas del negocio aguas abajo de la solución automatizada, por ejemplo, en el tratamiento
de casos excepcionales. Del mismo modo, es posible que deba cambiar la forma en que el negocio funciona antes de
la solución automatizada, por ejemplo, en la forma en que se ingresa el trabajo en Blue Prism. El OID explica los
requerimientos operativos, de recursos y de TI que la solución automatizada hará del Negocio.
Una vez que se han aprobado el Documento de diseño de la solución y el Documento de impacto operativo, puede
comenzar el diseño de nivel inferior más detallado.
Referencia
Un OID de ejemplo, basado en el proceso de viajes de BP, está disponible en el portal de Blue Prism.
4.3 Tutorial de la solución
Taller
Participantes: PYME cliente, operación del cliente, analista de Blue Prism, desarrollador de Blue Prism
De la misma manera que se debe jugar el PDD, se debe realizar un taller para recorrer el SDD y el OID para verificar
la solución automatizada propuesta y su efecto en el negocio en general.
Al igual que con el tutorial de PDD, este juego de roles puede revelar deficiencias en la solución que provocan un
replanteamiento y un cambio en el diseño.
4.4 Instrucción de diseño de procesos
Leído por: desarrolladores de Blue Prism
Aprobado por – Revisión por pares
Una instrucción de diseño de procesos (PDI) pretende ser un modelo a partir del cual se puede desarrollar un proceso.
La información de bajo nivel excluida del SDD en aras de la claridad debe incluirse en el PDI.
Si bien el PDD puede describir un proceso de negocios, por motivos de eficiencia y escalabilidad, esto puede
requerir más de un proceso de Blue Prism. Se debe crear un PDI para todos los procesos de Blue Prism que se
crearán y debe describir en detalle el proceso de Blue Prism, junto con todos los elementos (componentes, objetos
comerciales, colas de trabajo, bloqueos de entorno, variables de entorno, etc.) que admiten eso. También se debe
incluir la lógica para trabajar cada tipo de caso, junto con instrucciones sobre cómo manejar diferentes tipos de
excepción.
Un PDI completo formará una tarea de trabajo para un desarrollador.
Referencia
Una plantilla para un PDI de Blue Prism está disponible en el portal de Blue Prism.
Un PDI de ejemplo, basado en el proceso de viajes de BP, está disponible en el portal de Blue Prism.
4.5 Instrucción de diseño de objetos

Al igual que un PDI, la instrucción de diseño de objetos (ODI) se crea como un modelo a partir del cual se pueden
desarrollar objetos comerciales. La instrucción de diseño de objetos describe cada objeto que se construirá y para cada
acción dentro de ese objeto enumera los parámetros de entrada y salida y el inicio y el final.
pantallas
Leído por: desarrolladores de Blue Prism
Aprobado por – Revisión por pares
Referencia
Una plantilla para el ODI está disponible en el portal de Blue Prism.
Un ejemplo de ODI, basado en el proceso de viajes de BP, está disponible en el portal de Blue Prism.
5 construir
El alcance de este documento no incluye instrucciones sobre cómo desarrollar una solución de
Blue Prism, las guías para crear procesos y objetos están disponibles en otras partes del portal de Blue
Prism.
Primero se deben desarrollar los objetos del ODI y luego los procesos. Como normalmente hay varios
objetos, varios desarrolladores pueden participar en el desarrollo de objetos. Sin embargo, solo un
desarrollador a la vez puede trabajar en un proceso.
Las plantillas de proceso de Blue Prism deben usarse al crear procesos de Blue Prism.
Durante la implementación de Blue Prism Framework, se acordará una autoridad de diseño local que
regirá el control del diseño y las mejores prácticas de desarrollo. La revisión por pares es esencial en las
etapas regulares de la fase de desarrollo para garantizar la calidad del desarrollo.
Al final de cada unidad de tareas de desarrollo de objetos y procesos, el desarrollador realiza

pruebas de configuración.
Referencia
Una versión de Blue Prism de una solución completa que contiene procesos, objetos, colas de
trabajo, variables de entorno y plantillas de informes está disponible para descargar desde Blue Prism
Portal
6 prueba
Dado que la terminología utilizada para describir las fases de prueba puede diferir de un cliente a otro, este documento
utilizará términos genéricos en un intento de evitar posibles malentendidos de términos como validación, verificación,
prueba en vivo y UAT. Las siguientes fases forman el punto de partida a partir del cual se acuerda un enfoque de prueba
local durante la implementación de Blue Prism Framework. La agilidad de la plataforma Blue Prism permite realizar pruebas
durante el desarrollo. Solo cuando llegas a la fase 3 de prueba, los desarrolladores ya no están involucrados.
Fase 1
Realizado por: desarrollador de Blue Prism, probador de Blue Prism y pyme cliente (opcional)
Modo de ejecución de Blue Prism: Process Studio y Control Room
Entorno de Blue Prism – Desarrollo
Entorno del sistema de destino: prueba
Criterios de aceptación – Guión de prueba
En esta fase, el probador/SME y el desarrollador trabajan juntos para demostrar que la solución se ajusta a la
definición de proceso capturada (PDD).
El probador crea escenarios en el entorno de prueba que validan el proceso a lo largo de las diversas rutas del proceso.
Comenzando en los casos de estudio de proceso de Blue Prism, se avanza paso a paso y, a medida que aumenta la
confianza en la solución, la velocidad del proceso se puede aumentar hasta que, finalmente, el proceso se ejecute a toda
velocidad. En este punto, se pueden proporcionar estimaciones de tiempo de procesamiento de casos.
Esta es la etapa donde sale a la luz la calidad del PDD. Tanto el script de prueba de SME como el trabajo del
desarrollador se basan en la definición del proceso original, y si esa definición es precisa y completa, esta fase de prueba
debería funcionar sin problemas.
Sin embargo, en esta etapa se pueden encontrar nuevos escenarios no mencionados en el PDD. Si esto sucede, es
posible que las pruebas deban detenerse mientras se identifica una resolución para el escenario, se cambia el desarrollo
y se actualiza la documentación.
Una vez que el probador está satisfecho de que se han aprobado los scripts, la prueba puede pasar a la siguiente fase.
Fase 2
Realizado por: desarrollador de Blue Prism, probador de Blue Prism y pyme cliente
Modo de ejecución de Blue Prism: Process Studio y Control Room
Entorno de Blue Prism – Desarrollo
Entorno del sistema de destino: en vivo
Criterios de aceptación – Guión de prueba
Esta fase de prueba es en gran parte una repetición de la última, pero con una diferencia significativa. Donde
anteriormente se usaban sistemas de prueba, aquí las pruebas se realizarán con datos en vivo. La presencia de
una SME es obligatoria para confirmar el procesamiento ya que los datos están comprometidos con el sistema.
Las pruebas se realizan principalmente en Process Studio y, a diferencia de la fase anterior, en la que se
fabricaban escenarios para permitir que el probador probara la solución contra el PDD, aquí los casos se
seleccionan al azar. Los scripts de prueba enumerarán todos los diferentes escenarios que deben probarse con
datos en vivo y esto se puede verificar a medida que el proceso funciona a través de los casos en vivo.
Solo los procesos más básicos capturados en un PDD serán completamente completos. Debe asumir que hay
escenarios desconocidos y respuestas del sistema que solo se expondrán con datos en vivo y, a medida que
avanza esta fase de prueba, estos pueden detectarse, corregirse y volver a probarse.
Esta fase puede convertirse en un ciclo de pruebas y arreglos a medida que el evaluador, la PYME y el desarrollador
encuentran y aplican correcciones a la solución. Idealmente, estos serán ajustes menores que se pueden aplicar
de manera segura durante esta fase de prueba. Sin embargo, si se identifican brechas significativas en el alcance
y se requiere una reelaboración extensa, la entrega debe regresar temporalmente a la fase de desarrollo.
Una vez que los scripts de prueba se han probado con datos en vivo, la solución se puede implementar en el
entorno de prueba y las pruebas pueden avanzar a la siguiente fase.
Fase 3
Realizado por – Probador de Blue Prism, pyme cliente
Modo de ejecución Blue Prism: solo sala de control

Entorno Blue Prism – Prueba
Entorno del sistema de destino: en vivo
Criterios de aceptación: objetivos de volumen, rendimiento y calidad
En esta fase, la solución de proceso se implementa en el entorno de prueba para su aceptación final.
pruebas.
Esta fase se trata principalmente de probar que la solución puede manejar un aumento en el volumen y, al poner
volúmenes más grandes a través del proceso, se exponen los defectos restantes, el rendimiento o los problemas
ambientales. Las pruebas hasta este punto deberían haber demostrado que la solución es sólida y que es poco
probable que se necesiten más correcciones. No se pueden realizar cambios en la solución en el entorno de
prueba. Todos los defectos deben informarse y las correcciones deben aplicarse y probarse en el entorno de
desarrollo. Para arreglos menores, la fase dos se puede omitir y se puede migrar una nueva versión al entorno de
prueba.
El proceso se ejecuta solo en la sala de control de Blue Prism. Durante esta fase, los volúmenes de casos deben
administrarse estrictamente y controlarse la calidad. Pueden introducirse múltiples subfases. Cada subfase
tendrá sus propios criterios de calidad y aceptación, por ejemplo, trabajar 100 casos con un control de calidad del
100 % sin defectos. A medida que la fase de prueba continúa demostrando la calidad de la solución
los volúmenes se pueden aumentar gradualmente y la calidad se puede gestionar mediante controles puntuales hasta que
finalmente se satisfagan los criterios de aceptación finales.
Una vez que se han cumplido todos los criterios de aceptación, se publica un informe de prueba completo en la operación
del cliente para su aprobación antes de que el proceso pueda implementarse en producción.
6.1 Resumen de las fases de construcción y prueba
7 Hoja de ruta

Delivery Roadmap (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 (ES)

Cargado por

Copyright:

Formatos disponibles

Machine Translated by Google

La empresa de software de agilidad operativa

La empresa de software de agilidad operativa

© Blue Prisma Limited

Prisma azul limitada

La empresa de software de agilidad operativa

• Análisis de Proceso Inicial (IPA)

• Documento de Definición de Proceso (PDD)

• Cuestionario de Requerimientos Funcionales (FRQ)

• Documento de diseño de solución (SDD)

• Documento de Impacto Operacional (OID)

• Instrucción de Diseño de Procesos (PDI)

• Instrucción de Diseño de Objetos (ODI)

La empresa de software de agilidad operativa

El elemento de infraestructura técnica proporciona un entorno técnico estructurado y escalable para la

Esta hoja de ruta de entrega navega a través de las siguientes etapas:

La empresa de software de agilidad operativa

2.1 Análisis del proceso inicial

Un IPA es un medio de enmarcar la información disponible en la etapa inicial de un proyecto en un documento

Creado por: analista de Blue Prism o desarrollador de Blue Prism

Leído por – Patrocinador del cliente

Aprobado por – No requiere aprobación específica

El análisis debe considerar:

• Requisitos para el desarrollo

• Excepciones y tasas de referencia

• Requisitos del entorno de producción

• Requerimientos y esfuerzo de soporte de BAU

• Hay una plantilla IPA disponible en el Portal de Blue Prism.

La empresa de software de agilidad operativa

3.1 Documento de definición de procesos

Creado por – SME cliente y/o analista de Blue Prism

Aprobado por – Operación cliente, PYME cliente.

Detalle del proceso

La empresa de software de agilidad operativa

3.2 Tutorial del proceso

3.3 Cuestionario de requisitos funcionales

• Acuerdos de nivel de servicio

• Información de gestión y otros informes

• Continuidad del Negocio

Una plantilla FRQ está disponible en el Portal de Blue Prism.

La empresa de software de agilidad operativa

4.1 Documento de diseño de la solución

Creado por: desarrollador de Blue Prism

Leído por: operaciones del cliente, TI

Aprobado por: operaciones del cliente, TI

El SDD incluye una descripción de

• Descripción general de la solución de extremo a extremo

• Control operativo y alertas

• Seguridad de datos y credenciales

• Supuestos comerciales y técnicos

Hay una plantilla de SDD disponible en el Portal de Blue Prism.

4.2 Documento de Impacto Operacional

La empresa de software de agilidad operativa

Creado por – Analista de Blue Prism

Lectura por: operación del cliente, controlador Blue Prism

Aprobado por – Operación del cliente

4.3 Tutorial de la solución

4.4 Instrucción de diseño de procesos

Creado por: desarrollador de Blue Prism

Leído por: desarrolladores de Blue Prism

Aprobado por – Revisión por pares

La empresa de software de agilidad operativa

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

4.5 Instrucción de diseño de objetos