Requerimientos del proceso de automatización

La automatización de procesos simula la inteligencia humana, por lo que las

automatizaciones son utilizadas para controlar y monitorear procesos, las máquinas o
los dispositivos que cumplen con tareas o funciones repetitivas. Se caracterizan por su
forma de operar automáticamente, reduciendo y mejorando el trabajo humano en las
industrias.

Introducción
Ver video
Ubicación: D:\Aduy\SENA\Formación Complementaria\AUTOMATIZACION DE
PROCESOS PARA LA EFICIENCIA ORGANIZACIONAL\Componente Formativo
Video: 000 - 01 - Requerimientos del proceso de automatización

1. Requerimientos

Los requerimientos son las peticiones o solicitudes que se consideran necesarias o

importantes para satisfacer una o varias necesidades, ante un problema o mejora de un
proceso.

Es decir, son las condiciones o capacidades que deben tener los sistemas, productos o
servicios para lograr satisfacer un contrato, estándar o algunas otras especificaciones o
documentos que se hayan establecido formalmente.

Los requerimientos no indican el diseño que debe tener el producto, indican las
funciones y contenidos que se espera que tenga y la manera cómo los usuarios
interactúan con él; los requerimientos varían con el tiempo, puesto que, con la puesta
en marcha del producto, se podrán generar nuevos requerimientos (diferentes o
complementarios a los iniciales).

El propósito principal de los requerimientos es asegurar la satisfacción de las

expectativas de los clientes y sus interesados (stakeholders), internos y externos,
relacionando de manera eficiente, los vínculos que esperan los clientes y usuarios, y lo
que el grupo del proyecto tiende a desarrollar.

Ahora bien, los requerimientos son adaptados a todo tipo de proyectos, así, se trata de
garantizar el óptimo funcionamiento de los procesos, sirviendo de referencia para el
aseguramiento y control de los cambios que se pueden presentar en el proyecto
(trazabilidad).

Control de cambios
Durante la ejecución del proyecto se encuentran muchas situaciones, en las que se
identifican nuevas necesidades, las cuales ni siquiera se habían pensado, pero se hace
necesario anexarlas a la aplicación.

Estos cambios imprevistos, hacen que se replanteen nuevos requerimientos e incluso

requerimientos ya documentados.

Se debe definir desde un principio la forma en que se gestionarán dichos cambios,

debido a que pueden generar retrocesos en el desarrollo y en la planeación.

Se deben incluir cláusulas contractuales claras para que las partes a intervenir lo
tengan en cuenta, y no se tenga que retroceder en lo que se ha desarrollado.

Técnicas en el levantamiento de requerimientos

La etapa fundamental para la creación de un sistema, dentro de un proyecto

informático, es la identificación y documentación de los requerimientos del sistema al
iniciar el proyecto, puesto que en muchas situaciones se plantean ideas y se ayudan a
prevenir ciertos errores que se puedan presentar, evitando así el fracaso del mismo.

El levantamiento de requerimientos hace referencia a la identificación y documentación

del sistema, partiendo de usuarios, clientes o interesados; también se le llama
recopilación de requerimientos.

A continuación, se muestran algunas técnicas para obtener requerimientos en los

proyectos de software:

a. Análisis de documentación

 Es donde se obtiene la información sobre los requerimientos funcionales y

requerimientos no funcionales partiendo de documentos ya elaborados.

 Se utiliza cuando los expertos en el desarrollo no están disponibles para ser

interrogados o ya no forman parte del proceso o la empresa.

 Evitar riesgos al no tener documentación. En el momento de necesitarla, se

tendrá que hacer en el momento menos oportuno y sin recordar nada, perdiendo
información valiosa y tiempo, buscando las soluciones.

b. Observación

 Siempre será necesario analizar el entorno de trabajo de los usuarios, clientes e

interesados en el proyecto (stakeholders).
 Esta técnica es muy útil al documentar la situación actual del proceso de
negocio.

 Puede ser activa o pasiva.

 En la observación pasiva el observador no hace preguntas, solo se limita a

tomar notas y no interfiere en el desempeño de las operaciones.

 En la observación activa, el observador habla con los usuarios.

c. Entrevistas

 Se realiza con los directos interesados o usuarios clave.

 Direccionan a los usuarios hacia aspectos específicos a tener en cuenta.

 Son demasiado útiles para obtener y documentar datos o información sobre los
requerimientos y sus niveles de importancia.

 Deben ser entrevistas formales e informales para recolectar mucha más

información.

 Se deben enfocar los objetivos de la entrevista.

 Las preguntas cerradas son útiles y ayudan a confirmar y validar información.

 Las preguntas abiertas son útiles y ayudan a identificar información faltante.

 El éxito de las entrevistas depende del grado de conocimiento del entrevistador y

el entrevistado. El entrevistado debe tener muy buena disposición, suministrar
toda la información, de igual forma debe existir un muy buen registro de la
documentación de la discusión y una excelente relación entre las partes
involucradas.

d. Encuestas o cuestionarios

 Técnica útil para recolectar requerimientos eficientes y necesarios de muchas

personas.

 Deben tener identificado el propósito y la audiencia, definir fechas precisas,

preguntas claras y precisas.

 Enfocarse en los objetivos de negocio necesarios a identificar.

 Apoyarse en entrevistas de seguimiento e individualizar usuarios.

 En su contenido debe haber preguntas abiertas y cerradas.

e. Mesas de trabajo (workshops)

 Técnica efectiva para analizar información rápida de varias personas.

 Es necesario agendarse en tareas predefinidas y preseleccionar participantes,

ajustando buenas prácticas y mejoras continuas de los procesos.

 Es conveniente utilizar un facilitador y un transcriptor.

 Se pueden analizar los resultados en diagramas o flujogramas, en reuniones.

f. Lluvia de ideas

 Sesión de trabajo estructurada encaminada a obtener una cantidad de ideas

posibles.

 Es ideal limitarlas en tiempo y utilizar ayudas visuales con un facilitador.

 Definir reglas de participación, criterios para evaluar ideas, asignarles un

puntaje, no permitir críticas y con límite de tiempo de discusión.

 Identificar la mayor cantidad de ideas y evaluarlas, considerar todas las ideas y

respetar las de los demás.

g. Historias de usuario

 Son simples conversaciones con los usuarios pero muy importantes para
levantar requerimientos.

 Es recomendable que sean escritas por los mismos usuarios o interesados,

enfatizando en lo que el sistema debe realizar.

 Al momento de redactar una historia deben tenerse en cuenta los roles o cargos
de los usuarios, las funcionalidades y los resultados esperados de la aplicación.

 Las historias de usuario son una de las técnicas más importantes al momento de
levantar requerimientos.
Los requerimientos:

 Son las condiciones o capacidades que debe conservar un sistema, producto,

servicio o componente para satisfacer las necesidades mediante un contrato,
cumplir con estándares, especificaciones y demás documentos de manera
formal.

 También se definen como las capacidades necesarias para que un cliente o

usuario solucione un problema u objetivo ya preestablecido.

 Así mismo, se pueden relacionar los requisitos como las restricciones impuestas
a un usuario por algunos interesados, definiendo objetivos precisos de un
proyecto.

Las restricciones siempre serán necesarias para lograr manipular o editar el manejo de
la aplicación de manera controlada, efectiva y funcional, para que se lleven a cabo los
procesos de manera eficaz en la operación de las tareas.

Restricciones

Hacen énfasis, por ejemplo, en los permisos de accesos a usuarios en el sistema.

Todos los usuarios del sistema lo podrán operar, pero no todos tienen los mismos
derechos en la aplicación.

Así como existen operadores de la aplicación, habrá usuarios con permisos de

administradores que podrán manipular más a fondo la aplicación.

1.1. Características de requerimientos

Los requerimientos deben cumplir con cierto tipo de características y criterios:

Verificable: El requisito debe tener una implementación precisa y comprobada, la

prueba de consulta debe ser correcto o incorrecto.

Único: Debe ser interpretado de manera exclusiva, de una sola manera.

Claro: Los requerimientos deben ser precisos, sin más terminologías, de forma clara y
simple.
Viable: El objetivo de los requerimientos es que sea realizable según restricciones de
tiempo, dinero, recursos y demás elementos a tener en cuenta.

Necesario: Si al omitirlo no se tiene ningún efecto, entonces no será necesario.

Independiente: Para comprender los requerimientos no deben ser necesarios el

conocimiento de otros.

Consistente: No deben existir conflicto entre ellos.

Redundancia: Deben ser formulados una sola vez, y no sobreponerse o relacionarse

de la misma forma con otro requerimiento.

Completo: También debe ser específico, se deben tener en cuenta todas las
condiciones que se pueden llegar a presentar.

Estructura de los requerimientos: Los requisitos se pueden dividir, según su origen y

características, se pueden representar mediante una gráfica, situando las necesidades
de los stakeholders como se muestra en la siguiente imagen:

Para estos tipos de necesidades dependerá mucho del analista de negocio decidir cuál
será el nivel de detalle de cada nivel, aunque es adecuado, en algunos casos, detallar
con más precisión algunos requerimientos en el nivel de las necesidades.

¿Qué es la trazabilidad?
Es la documentación de la vida de cada uno de los requerimientos, permitiendo el
historial de su formulación original hasta el documento final.

Se debe documentar cada paso de manera estricta para conseguir la trazabilidad.

Los requerimientos y necesidades surgen de diversas fuentes, como el cliente, el

manager, los usuarios, etc., todos y cada uno comprenden de diferentes formas los
requerimientos, y es en este momento, donde los requerimientos se deben precisar
para poder planear y llevarlo a la ejecución.

Utilizando la trazabilidad se sigue el historial de cada característica implementada hasta

las personas o grupos que solicitaron la generación de los requerimientos, de esta
manera, se permite un análisis más rápido en cada fase del proyecto.

Tipos de requerimientos

Los requerimientos se clasifican en:

 Requerimientos funcionales

Son las declaraciones de los servicios que prestará el sistema, es la forma como
reacciona a determinadas funciones. Del mismo modo, podrían ser la manera de
interactuar con otros sistemas, el tipo de respuestas automáticas y los procesos
predefinidos. En otros casos también los requisitos funcionales establecen de manera
precisa lo que el sistema no debe hacer, es decir también puede ser una declaración
negativa.

De igual forma, los requerimientos funcionales también son las características que
tendrá el sistema o aplicación, son las funciones que actúan directamente con los
usuarios, por ejemplo, las pantallas que permiten utilizar dicha aplicación, lo que se
puede visualizar, como Facebook, Instagram, etc., sus menús, diseños, botones,
colores y demás funcionalidades que hacen muy amigable la interacción con el usuario.

Por otra parte, los mayores problemas se encuentran cuando existen especificaciones
de requisitos inexactas o incoherentes. Si un analista de los requerimientos del sistema
toma suposiciones como conocimientos universales, podría conllevar un riesgo para el
sistema, es mejor siempre ser preciso y definirlo. Estos problemas se pueden encontrar
en las funciones comunes relacionadas con las experiencias de usuario.

El analista es el responsable de la documentación, por lo tanto, él mismo deberá

tratar de asegurarse que no hay lagunas de comprensión, por eso es importante
tener en cuenta las historias de usuario, asegurándose de que todo el equipo
está sincronizado respecto a los requisitos, objetivos e implementación.

Algunos ejemplos de requerimientos funcionales con características que permiten

utilizar la aplicación de manera cómoda y visual, ya sea en el diseño, menú, botones,
entre otros, son:

Interfaz de captura

Incluye:

 Las funciones que actúan directamente con el usuario.

 Las pantallas y opciones que permiten utilizar la aplicación.

Requerimientos no funcionales

Son los requerimientos que no interfieren con las funciones específicas que entrega el
sistema, asegurando la fiabilidad, tiempos de respuesta y capacidad de
almacenamiento. En otras palabras, no habla de lo que hace el sistema, sino de cómo
lo hace, define restricciones de entrada y salida, representando datos utilizados en las
interfaces del sistema.

Puede ser con lenguaje de programación Java, con alta velocidad de procesamiento de
datos, para un óptimo funcionamiento de la aplicación, disponibilidad, entre otros. Son
los requisitos que debe tener la aplicación para que funcione adecuadamente, se
encargan de que la aplicación cumpla con lo que tiene que hacer.

“Los requerimientos no funcionales son los requisitos que debe tener la aplicación
para que funcione adecuadamente; estos se encargan de que la aplicación cumpla con
lo que se quiere hacer, por otro lado, los requerimientos funcionales son todo lo que el
usuario ve y manipula.”

A continuación, se muestran ejemplos de requisitos no funcionales dentro de una

aplicación para pedir un taxi:

Ejemplo 1:

Operación 7x24: La aplicación debe operar las 24 horas del día durante todo el año.
Hace referencia a la disponibilidad, nunca debe fallar y estar siempre disponible.

Ejemplo 2:
Registro de usuario: Para su uso se requieren datos de registro. Esta opción de
seguridad es un requisito que no se puede ver, pero es necesario para que la
aplicación funcione; es un requisito no funcional.

Los requerimientos no funcionales no se pueden ver ni tocar, porque están

“detrás” de la aplicación, para que funcione de manera rápida, segura y en cualquier
momento.

1.2. Documentación de requerimientos

El documento de requerimientos es el lugar donde se describen las

características y requisitos de un software, programa, conjunto de programas o
productos. Son expresados en lenguaje natural, sin términos técnicos ni
consideraciones.

La especificación de los requisitos es el resultado del levantamiento de información,

junto con el cliente y/o usuario de los productos. Es el método de comunicación más
precisa y clara entre los que se encargan de desarrollar el software y los clientes o
usuarios finales que utilizarán el mismo.

Llamado a la acción

Se comparte una plantilla para la descripción de los requerimientos. Esta plantilla sigue
los requerimientos establecidos en el estándar IEEE 830, (Instituto de Ingenieros
Eléctricos y Electrónicos), es la sociedad técnica profesional más grande y prestigiosa
del mundo. Del mismo modo, se menciona que la especificación de requisitos debe
contener la descripción de las funcionalidades de la aplicación, relacionamiento con los
sistemas externos y requerimientos no funcionales, de rendimiento, disponibilidad,
tiempos de respuesta y mantenibilidad.

Ubicación de la plantilla
D:\Aduy\SENA\Formación Complementaria\AUTOMATIZACION DE PROCESOS
PARA LA EFICIENCIA ORGANIZACIONAL\Componente Formativo
Nombre Archivo: 000 - 02 - CF001_Anexo2_Plantilla_requerimientos_de_software

Es importante mencionar que, de acuerdo con las necesidades de cada proyecto,

podría ser necesario incluir elementos o información complementaria a este
documento. A continuación, se comparte un esquema descriptivo de una plantilla de
documento de requerimientos de software:
Propósito: Nombre o título del software que está especificado en el documento,
incluyendo su número de versión o release. También se describen cuáles componentes
o partes del alcance del producto están incluidas en el documento, estableciendo si
cubre la totalidad del software, solo una parte del sistema, subsistema o subgrupo de
procesos.

Alcance: Descripción corta del alcance del software que se está especificando,
incluyendo: propósito u objetivo general, beneficios que brinda al área de negocio y
organización, relación de los objetivos del software con los objetivos corporativos y
estrategias de negocio. Se puede hacer referencia a otros documentos.
Referencias: Aquí se puede incluir otros documentos impresos, documentos o
direcciones electrónicas que complementen la documentación de requerimientos de
software.

Funcionalidades: Lista de las funcionalidades del software que se está especificando

en el documento de requerimientos. Cada funcionalidad puede estar compuesta por
uno o varios requerimientos funcionales de software. Solo se incluye una lista
numerada de las principales funcionalidades.

Clases y características de usuarios

Se clasifican los usuarios que utilizaran el producto. La clasificación puede ser en

función a la frecuencia de uso, grupo de funcionalidades utilizadas, privilegios de
seguridad, nivel de experiencia y otros parámetros.

Entorno Operativo: Se describe el entorno operativo en el que se desenvolverá el

sistema, software, módulo o grupo de funcionalidades, mencionando aspectos como la
plataforma de hardware, versiones de sistema operativo y otros sistemas o
componentes con los que debe coexistir

Requerimientos no funcionales: Los requerimientos no funcionales son los que

especifican criterios para evaluar la operación de un servicio de tecnología de
información, en contraste con los requerimientos funcionales que especifican los
comportamientos específicos.

Requerimientos interfaces externas: Describe las características y atributos de las

interfaces con el usuario (GUI), interfaces con el hardware, interfaces con otros
sistemas de las interfaces de comunicaciones.

Reglas de negocio: Listado de reglas y principios que aplican a todo el conjunto de

requerimientos de software contenidos en el documento. Un ejemplo es cuáles
individuos o roles pueden desempeñar cierta función bajo ciertas circunstancias.

Requerimientos funcionales: En esta sección de la plantilla, se ilustra cómo organizar

los requerimientos funcionales de software por funcionalidad de producto o sistema.
Aquí se listan las funcionalidades para cada una y a su vez se listan los requerimientos
funcionales. Los requerimientos funcionales también se pueden documentar en una
matriz de trazabilidad de requerimientos.

2. Notaciones de requerimientos
La notación textual de los requerimientos es necesaria para la relación de la
comunicación efectiva entre clientes, usuarios e interesados, deben lograr interpretar lo
que queda plasmado en figuras.

La notación gráfica que se utiliza en la especificación de los requerimientos por

excelencia es UML (Lenguaje de Modelado Unificado), específicamente en los
diagramas de casos de uso, estados y actividades, que describen en detalles los usos
del sistema.

Como se muestra a continuación, para los diagramas UML existen diferentes versiones
aprobadas por la ISO, cuentan con diferentes tipos, clasificándolos según su estructura
o comportamiento:

Entre los diagramas de estructura se encuentran:

Diagrama de clases

Trazan la estructura de un sistema concreto al modelar sus clases, atributos,

operaciones y relaciones entre objetos.
Diagrama de estructura compuesta

Brinda una vista general lógica en general o en parte de un software. Describe el

interior de un clasificador estructurado determinado definiendo sus clases de
configuración, interfaces, paquetes y relaciones entre ellos.

Diagrama de componentes

Representan las relaciones entre los componentes individuales del sistema por medio
de una vista de diseño estática. Ilustran modelado de aspecto lógico y físico.

Muestra las organizaciones y dependencias entre componentes y artefactos (Digital

Guide, 2020).
Diagrama de despliegue

Llamado también diagrama de implementación, ubicado dentro de los diagramas

estructurales porque describe aspectos del sistema (Lucidchart, 2021b).

Diagrama de objeto

Representa una instancia específica de un diagrama de clases en un momento

determinado en el tiempo, es muy similar al diagrama de clases. Se enfoca en los
atributos de un conjunto de objetos y la relación entre estos objetos.

Los objetos se conectan por medio de una línea que es nombrada, cuando hay una
relación entre objetos o clases, esta debe de mostrarse en ambos diagramas.
Diagrama de paquetes

Se emplean para mostrar la organización y disposición de diversos elementos de un

modelo en forma de paquetes. El paquete es la agrupación de elementos UML
relacionados, como diagramas, clases, documentos, e incluyendo otros paquetes.

Entre los diagramas de comportamiento se tienen:

Diagrama de actividades

Describen lo que debe suceder en el sistema que se está modelando.

Diagrama de interacción o secuencia

Se emplea para captar el comportamiento interactivo de un sistema, describiendo el

flujo de mensajes dentro de un sistema.

Diagrama de caso de uso

Describen o especifican lo que hace el sistema desde un punto de vista externo.

Plantea en su diagrama escenarios lo que sucede cuando alguien interactúa con el
sistema, suministrando un resumen de una determinada tarea u objetivo.

Ejemplo de un caso de uso de un sistema bancario.

Diagrama de máquina de estado

Es también conocido como diagrama de estados, es un tipo de diagrama de

comportamiento en el UML, que muestra transiciones entre diversos objetos.

Ejemplo de diagrama de estado de un aeropuerto.

 2.1. Procesos organizacionales

Hacen referencia al conjunto de pasos para llevar a cabo en una organización, junto
con sus miembros, con el fin de lograr las metas propuestas y los objetivos.

Se ha determinado, a través del tiempo e investigaciones, que lo único constante es el

cambio en las organizaciones.

Del mismo modo, el avance tecnológico que se globaliza en los últimos tiempos obliga
a las empresas a adoptar nuevas herramientas tecnológicas de gestión y capacitación
de los empleados en el uso eficiente de ellas, como única alternativa para sobrevivir y
mantenerse en el mercado. A continuación, se presenta algunos tipos de procesos
dentro de las organizaciones:

Tipos de procesos dentro de las organizaciones

A continuación se invita al aprendiz a consultar el siguiente recurso infográfico donde

se presentan algunos tipos de procesos dentro de las organizaciones.

Ubicación de la plantilla
D:\Aduy\SENA\Formación Complementaria\AUTOMATIZACION DE PROCESOS
PARA LA EFICIENCIA ORGANIZACIONAL\Componente Formativo
Nombre Archivo: 000 - 03 - Procesos_Organizacionales

2.2. Modelado de procesos

 El gran objetivo del modelado es optimizar los procesos.

 Partir los procesos en pedazos para permitir estudiarlo, está conectado con las
pruebas a realizar percibiendo las posibilidades de cada proceso.

 Permite conocer a fondo las pruebas y resultados, creando un buen comienzo

para la optimización de procesos, identificando los obstáculos y puntos nulos.

Las categorías de información para tener en cuenta para el modelado de procesos son:

Insumos: Todo lo que pasa a través de un proceso es un insumo.

Resultados: Surge con la transformación de los insumos.

Facilitadores: Se utilizan en el proceso de transformación de insumos a resultados.

Guías: se usan guías como la información, normas, conocimientos, recibos e informes
que nos ayuden a comprender el cuándo, cómo y porqué se produce un proceso.

Técnicas de modelado de procesos

Es ideal visualizar y crear un diagrama o flujo para notar la descripción de cada

proceso, para lograr ver claramente el proceso, permitiendo identificar lo que se debe
cambiar, mejorar y optimizar, lo cual podrían requerir algunas técnicas. Siempre es
importante contar con un software fiable para realizar el modelado de los procesos.

 Recopilar información a través de entrevistas individuales.

 Sesiones facilitadoras para recopilar datos en reuniones con talento humano de

diferentes áreas o dependiendo del objetivo.

 Enfoque de arriba hacia abajo analizando el proceso del todo en las partes.

 Enfoque de abajo hacia arriba analizando el proceso del nivel de flujo de trabajo,
es más lento, pero se encuentran mayores detalles.

Diagrama de flujo

Es un diagrama que describe un proceso, sistema o algoritmo informático, es usado

ampliamente en muchos campos para documentar, estudiar, mejorar, planificar y
comunicar procesos que suelen ser muy complejos en algunos diagramas claros y
fáciles en su comprensión.

En los diagramas se utilizan rectángulos, óvalos, diamantes y otras figuras más para
definir el tipo de paso, junto a flechas conectoras estableciendo flujos y secuencias.
Varían desde diagramas simples o hechos a mano, hasta los más complejos creados
en computadora, describiendo múltiples pasos y rutas.

Las figuras utilizadas en un diagrama de flujo son:

Los diagramas de flujo a veces los denominan con nombres más especializados, como:

 Mapas de procesos.

 Diagramas de flujo de procesos.

 Diagrama de flujo funcional.

 Mapa de procesos de negocio.

 BPMN, modelado de procesos de negocio.

Se relacionan con otros diagramas populares, como:

Mapa de procesos
Es un diagrama de valor que representa una manera de inventario gráfico de los
procesos de una organización en forma relacionada.

Diagrama de flujo

Es la representación gráfica de cada proceso y sus pasos se representan por un

símbolo diferente que contiene una descripción de la etapa del proceso.
Diagrama de flujo funcional

Es un tipo de diagrama de flujo, que muestra el movimiento entre unidades de trabajo.

Puede utilizar símbolos de los diagramas de flujo estándares (Edukativos, 2013).

Mapas de proceso de negocio

Describen los pasos que una empresa debe realizar para completar un proceso, por
ejemplo, contratar a un empleado, solicitar productos y transportarlos.

Símbolos y notación de diagrama BPMN

El diagrama de modelo y notación de procesos de negocio es también llamado

diagrama BPMN, utilizado para crear diagramas de flujo de modelos de procesos de
negocio, que sean fáciles de leer.

El modelo BPMN

Se denomina así por su sigla en inglés Business Process Modeling Notation, notación
para el modelado de procesos de negocios, es el estándar internacional para modelar
procesos, la notación gráfica que describe la lógica de los pasos de un proceso de
negocio.
Los principales elementos de BPMN son:

 Eventos.
 Actividades.
 Compuertas (control de flujo).

Se representan gráficamente por un círculo y van describiendo algo que sucede, a

diferencia de las actividades que son algo que se realiza o se hace. A continuación, se
muestra su representación gráfica y su definición:

El siguiente es un ejemplo de modelo BPMN:

Para mayor comprensión de los diagramas BPMN y aprender a hacer uno se invita al
aprendiz a ver el Video ayuda para hacer un diagrama BPMN ubicado en la sección de
material complementario.

Ver video:
Ubicación: D:\Aduy\SENA\Formación Complementaria\AUTOMATIZACION DE
PROCESOS PARA LA EFICIENCIA ORGANIZACIONAL\Componente Formativo
Video: 000 - 04 - Tutorial BPMN con Visio
Sintesis: