Subgerencia Operaciones Informática

 El término negocio deriva de las palabras latinas nec y otium, es

decir, lo que no es ocio.
 Para los romanos otium era lo que se hacía en el tiempo libre, sin
ninguna recompensa; entonces negocio para ellos era lo que se
hacía por dinero.
 Es una ocupación lucrativa que cuando tiene un cierto volumen,
estabilidad y organización se llama empresa
 Actividad, sistema, método o forma de obtener dinero, a cambio de
ofrecer alguna forma de beneficio a otras personas.
 Entidad creada o constituida con la finalidad de obtener dinero a
cambio de realizar actividades de producción, comercialización o
prestación de servicios , que beneficien a otras personas.
 Actividad comercial o social que se ha pensado y que se desea
desarrollar.
 Herramienta que nos permite organizar y planificar las actividades
que debemos realizar para lograr las metas de nuestra empresa
cooperativa.
UN MODELO DE NEGOCIO DESCRIBE LA MANERA Y DA
FORMA LOGICA A COMO UNA ORGANIZACIÓN
INTENTA GANAR DINERO A TRAVES DE CREAR,
DISTRIBUIR y CREAR VALOR
 Davenport dice, que es un conjunto estructurado, medible de actividades
diseñadas para producir un producto especificado, para un cliente o mercado
específico. Implica un fuerte énfasis en CÓMO se ejecuta el trabajo dentro de la
organización, en contraste con el énfasis en el QUÉ, característico de la
focalización en el producto.
 Hammer establece la diferencia sustancial entre un proceso y una tarea,
señalando que una tarea corresponde a una actividad conducida por una
persona o un grupo de personas, mientras que un proceso de negocio
corresponde a un conjunto de actividades que, como un todo, crean valor para
el cliente externo. Al hacer esta comparación, Hammer hace la analogía con la
diferencia que existe entre las partes y el todo.
 Ould lista una serie de características que deben cumplir los procesos de
negocio y que refuerzan la posición de Hammer; según este autor, un proceso
de negocio contiene actividades con propósito, es ejecutado colaborativamente
por un grupo de trabajadores de distintas especialidades, con frecuencia cruza
las fronteras de un área funcional, e invariablemente es detonado por agentes
externos o clientes de dicho proceso.
 Visión funcional:
◦ descansa en el organigrama de la empresa como modelo fundamental del negocio; las
actividades que debe ejecutar la organización, para cumplir con su misión, se estructuran en
conjuntos de funciones relativamente homogéneas
◦ los recursos pertenecen a los departamentos y la especialización funcional y el expertizaje,
son las principales consideraciones a la hora de formar los departamentos, los cuales se
relacionan a través de una jerarquía de estructuras de autoridad.
 Visión de proceso:
◦ se orienta al trabajo mismo que se debe desarrollar en la organización, para que el negocio
funcione y entregue un producto o servicio, por el cual un cliente externo está dispuesto a
pagar.
◦ la vista de procesos es una manera tan poderosa de visualizar y analizar un negocio, porque
provee de la lógica con la cual los clientes lo miran; los clientes interactúan con la empresa, a
través de los procesos del negocio, contratando un servicio, recibiendo dicho servicio,
pagándolo y recibiendo atención de post venta.

Cuando se entiende el negocio desde la perspectiva

de procesos, es posible evaluar, medir y mejorar.
 Conjunto de tareas relacionadas lógicamente llevadas a cabo para
lograr un resultado de negocio definido.
 Cada proceso de negocio tiene sus entradas, funciones y salidas.
 Las entradas son requisitos que deben tenerse antes de que una
función pueda ser aplicada. Cuando una función es aplicada a las
entradas de un método, tendremos ciertas salidas resultantes.
 Colección de actividades estructurales relacionadas que producen un
valor para la organización, sus inversores o sus clientes
 Proceso a través del que una organización ofrece sus servicios a sus
clientes.
 Puede ser parte de un proceso mayor que lo abarque o bien puede
incluir otros procesos de negocio que deban ser incluidos en su
función.
 Puede ser visto a varios niveles de granularidad.
 El enlace entre procesos de negocio y generación de valor lleva a
algunos practicantes a ver los procesos de negocio como los flujos de
trabajo que efectúan las tareas de una organización.
 Poseen las siguientes características:
◦ Pueden ser medidos y están orientados al rendimiento
◦ Tienen resultados específicos
◦ Entregan resultados a clientes o “stakeholders”
◦ Responden a alguna acción o evento específico
◦ Las actividades deben agregar valor a las entradas del proceso.
 Hay tres tipos de procesos de negocio:
◦ Procesos estratégicos - Estos procesos dan orientación al negocio.
Por ejemplo, "Planificar estrategia", "Establecer objetivos y metas".
◦ Procesos sustantivos o centrales– Estos procesos dan el valor al
cliente, son la parte principal del negocio. Por ejemplo, “Logistica”
◦ Procesos de apoyo o soporte vertical o horizontal – Estos
procesos dan soporte a los procesos centrales. Por ejemplo, “Dar
Soporte/Servicio técnico”.
 Gestión de procesos de negocio (Business Process
Management o BPM en inglés) es una metodología empresarial
cuyo objetivo es mejorar la eficiencia a través de la gestión
sistemática de los procesos de negocio, que se deben modelar,
automatizar, integrar, monitorizar y optimizar de forma continua.
 A través del modelado de las actividades y procesos puede lograrse
un mejor entendimiento del negocio y muchas veces esto presenta
la oportunidad de mejorarlos.
 La automatización de los procesos reduce errores, asegurando que
los mismos se comporten siempre de la misma manera y dando
elementos que permitan visualizar el estado de los mismos.
 Permite asegurar que los procesos se ejecuten eficientemente, y la
obtención de información que luego puede ser usada para
mejorarlos.
 Para soportar esta estrategia es necesario contar con un conjunto
de herramientas que den el soporte necesario para cumplir con el
ciclo de vida de BPM.
 Este conjunto de herramientas son llamadas Business Process
Management System y con ellas se construyen aplicaciones BPM.
 Existen diversos motivos que mueven la gestión de Procesos de
Negocio, entre los cuales se encuentran:
 Extensión del programa institucional de calidad
 Cumplimiento de legislaciones
 Crear nuevos y mejores procesos
 Entender qué se está haciendo bien o mal a través de la comprensión de los
procesos
 Documentar procesos para subcontratación y definición del SLA
 Automatización de procesos
 Crear y mantener la cadena de valor
 Describen las políticas, normas, operaciones, definiciones y
restricciones presentes en una organización y que son de vital
importancia para alcanzar los objetivos misionales.
 Ejemplos de reglas de negocio: "Un cliente al que compra más de
$1.000.000 al año es un cliente de tipo A y a estos se les aplica un
descuento”.
 Las organizaciones funcionan siguiendo múltiples reglas de
negocio, explícitas o tácitas, que están embebidas en procesos,
aplicaciones informáticas, documentos, etc.
 Se debe gestionar de forma sistemática y centralizada las reglas de
negocio, de modo que sea fácil y sencillo consultarlas, entenderlas,
utilizarlas, cambiarlas, etc.
 Para ello se puede utilizar un motor de reglas de negocio.
 El motor de reglas de negocio es un sistema que se configura para
dar servicio a las necesidades de negocio a través de la definición
de objetos y reglas de negocio.
 Se rige por flujos que derivan responsabilidades a los distintos
cargos de la empresa repartiendo así el trabajo equitativamente y
cuantitativamente, cuando, quien y donde tiene que desempeñar la
tarea asignada.
 Son un medio por el cual la estrategia es implementada, especifican
- en un nivel adecuado de detalle - lo que una organización debe
hacer.
 Características
 Las reglas de negocio deben ser:
◦ Declarativas.
◦ Atómicas.
◦ Independientes y distintos.
◦ Expresadas en lenguaje natural.
◦ Orientadas al negocio.
 Especificación Formal
◦ Las reglas del negocio pueden ser expresadas en un lenguaje
formal de acuerdo a la naturaleza de la organización.
◦ Los lenguajes más ampliamente utilizados incluyen UML,,
Business Process Modeling Notation (BPMN)
 Lenguaje Unificado de Modelado: Lenguaje para especificar,
visualizar y documentar los artefactos de los sistemas

 Es una familia de notaciones gráficas, útil para diseñar

sistemas de software, particularmente sistemas que habrán de
desarrollarse en términos de OO.

 Desde su establecimiento, ha desplazado a una multitud de

lenguajes gráficos de modelado OO.
 7 Elementos Estructurales
◦ Clases, Interfaces, Colaboraciones, Casos de uso, Clases
activas, Componentes, Nodos
 2 Elementos de Comportamiento
◦ Interacciones (mensajes, secuencias & enlaces), máquinas de
estado
 1 elemento de agrupación: paquetes
 1 elemento de anotación
 4 Relaciones
◦ Dependencia, asociación, generalización, realización
 9 Diagramas
 Estáticos:
◦ Diagramas de clases
◦ Diagramas de objetos
◦ Diagramas de componentes
◦ Diagramas de despliegue
 Dinámicos:
◦ Diagramas de casos de uso
◦ Diagramas de secuencia
◦ Diagramas de colaboración
◦ Diagramas de estados
◦ Diagramas de actividades
 Definición Definición Definición
Definición
del modelo de diagramas de diagramas de
de casos de uso
del dominio de interacción clases diseño

• Casos de uso: Análisis de requerimientos

• Modelo de dominio: Conceptos, atributos y asociaciones
• Diagramas de interacción: Flujo de mensajes (invocación
de métodos)
• Diagramas de clases: Métodos requeridos por los mensajes
 En UP los requerimientos se clasifican conforme al modelo
FURPS+ [Grady92]:
◦ Funcional [Casos de uso]
◦ Usabilidad: Factor humano, documentación
◦ Fiabilidad (Reliability)
◦ Performance
◦ Soporte: Mantenimiento, configurabilidad...
◦ +: Adicionales (packaging, legales...)
 Los casos de uso son requerimientos, pero no todos los
requerimientos
 Son documentos de texto, no diagramas (aunque en UML hay
diagramas de casos de uso)
 No están ligados a OOD u OOP
 Se recomienda no usar diagramas, sino escribir texto
 Se recomienda que sean de caja negra: qué (análisis), pero no
cómo (diseño)
 Diagramas de casos de uso:
◦ Casos de uso
◦ Actores
◦ Relaciones de dependencia, generalización y asociación
 Actores:
◦ Se representan mediante monigotes
◦ Se pueden definir categorías generales (Cliente) y especializarlas
a través de relaciones de generalización
◦ Un Actor sólo se puede conectar a un caso de uso mediante una
asociación
 Modelan la vista de diseño estática de un sistema
 La vista estática soporta los requisitos funcionales
 Son los más utilizados en el modelado de sistemas orientados a
objeto
 Muestra un conjunto de clases, interfaces y colaboraciones
 Son importantes para construir sistemas ejecutables, aplicando
ingeniería directa e inversa
 Contienen clases, interfaces, colaboraciones, relaciones de
dependencia, generalización y asociación
 Pueden contener también paquetes o subsistemas para
agrupar otros elementos del modelo
 El mayor peligro de los diagramas de clases es que uno se
puede concentrar en la estructura y olvidar la conducta .
 Recomendación: No diagramar todo, sino aspectos importantes
 Modelan las instancias de los elementos contenidos en los
diagramas de clases
 Muestran un conjunto de objetos y sus relaciones en un momento
concreto (vista estática, como una instantánea)
 Consisten en los objetos que colaboran, pero sin especificar los
mensajes
 Contienen objetos y enlaces
 Pueden contener paquetes o subsistemas
 Se puede hacer ingeniería directa, pero en la práctica esto tiene
un valor limitado
 Las instancias son creadas en tiempo de ejecución
 Hacer ingeniería inversa es más razonable y se hace
continuamente.
 Tener en cuenta:
◦ No es posible capturar todos los objetos potenciales de un
sistema o sus relaciones
◦ Se usan para capturar algún aspecto específico del sistema
en un momento dado
 Modelan aspectos físicos del sistema
 Ejecutables, bibliotecas, tablas, archivos, documentos
 Representan el empaquetamiento físico de elementos lógicos tales
como clases, interfaces y colaboraciones
 Definen abstracciones con interfaces bien definidas
 La notación canónica permite visualizar un componente con
independencia de sistema operativo o lenguaje de programación
 Con los mecanismos de extensión (estereotipos) se puede
particularizar la notación
 Contienen componentes, interfaces y relaciones de dependencia,
asociación y realización
 También pueden contener paquetes, subsistemas e instancias
 Es habitual hacer ingeniería directa e inversa
 Cada diagrama representa un aspecto; el conjunto de todos
representa una vista estática completa del sistema
 Muestra eventos de entrada y salida relacionados con el sistema
 UML incluye notación para representar los eventos que parten de
los actores externos hacia el sistema
 Un DSS es un dibujo que muestra, para un escenario de casos de
uso, los eventos generados por los actores, el orden y los eventos
entre sistemas
 El orden de los eventos debe seguir el orden en el caso de uso
 Forman parte del Modelo de los Casos de Uso
 No se mencionan en la especificación de UP
 Se suelen crear en la elaboración, no en la incepción
 No es necesario crear DSS para todos los escenarios de todos los
casos de uso
 Son buenos para comprender la conducta de varios objetos en un
solo caso de uso
 Sirven para mostrar colaboración entre objetos; no lo son para
modelar la conducta
 Si se quiere ver la conducta de un solo objeto a través de varios
casos de uso, usar un diagrama de estados
 Muchos threads a través de muchos casos, un diagrama de
actividad
 Statecharts: Muestran una máquina de estados
 Un diagrama de actividad es una clase especial de diagrama de
estados que muestra el flujo de control entre actividades
 Un diagrama de estados muestra el flujo de control entre estados
 Especifica la secuencia de estados por la que pasa un objeto en
respuesta a eventos, junto con sus respuestas a esos eventos
 Son útiles para modelar comportamiento regido por eventos
 Usualmente se modela la vida de un objeto, comenzando por su
creación, sus estados estables y su destrucción
 Una máquina de estados cuyas acciones están asociadas a
transiciones se llama máquina de Mealy
 Una máquina de estados cuyas acciones están asociadas a
estados se llama máquina de Moore
 En la práctica se suelen mezclar ambos tipos de máquinas
 La ingeniería directa es usual
 La ingeniería inversa es teóricamente posible pero no es útil
◦ Las herramientas de ingeniería inversa no tienen capacidad de
abstracción y no pueden producir diagramas de estado
significativos
◦ Puede resultar más útil alguna herramienta de animación
 Equivalente de un workflow, pero con soporte de paralelismo
 Describen lógica de procedimiento, lógica de negocios y workflow
 Se llamaban Diagramas de Colaboración.
 Enfatiza los vínculos de datos entre los participantes de una
interacción
 Utilizan numeración para mostrar la secuencia de un mensaje
 Usualmente su usa numeración común, plana; pero la legal
(“Kosher”) debería ser decimal 1.1, etc
 …
 Modelan la vista de despliegue estática, equivalente a la topología
del sistema
◦ Para modelar hardware, se recomiendan lenguajes específicos,
como VHDL
 No sólo modelan el despliegue, sino que pueden gestionarlo a
través de ingeniería directa o inversa
 Contienen nodos y relaciones de dependencia y asociación
 Pueden contener paquetes, subsistemas, componentes e instancias
 Se puede hacer alguna ingeniería directa, mayormente para
visualizar
 La ingeniería inversa es de mayor valor
 Un paquete es una parte de un modelo
 Cada parte de un modelo debe pertenecer a un paquete
 Los paquetes contienen elementos en el más alto nivel
 Clases y relaciones, máquinas de estado, diagramas de casos de
uso, interacciones y colaboraciones
 Cualquier elemento que no esté contenido en otro paquete
 Si se ilgen bien los paquetes, representan la arquitectura de alto
nivel del sistema
 Business Process Management Initiative (BPMI) desarrollo este
estándar para la notación de Procesos de Negocios(BPMN).
 La versión de BPMN 1.0 fue liberada en Mayo 2004 y representa un
esfuerzo de más de 2 años de BPMI Notation Working Group.
 La primera meta de este esfuerzo fue proveer una notación
entendible por todos los usuarios del negocio, desde los analistas
de negocio que crean los primeros borradores, los desarrolladores
técnicos, responsables de implementar la tecnología, y las
personas del negocio quienes gestionan y monitorean estos
procesos.
 BPMN también esta soportado con un modelo interno para habilitar
la generación de ejecutables BPEL4WS.
 BPMN crea un puente estandarizado, para la brecha entre el diseño
del proceso de negocio y su implementación.
 BPMN define un Business Process Diagram (BPD), es cual se
basa en un el diseño de un flujo para crear modelos graficos de las
operación de un proceso de negocio.
 Un modelo de proceso de negocio es un red de graficos de objetos,
las cuales son actividades, y el flujo de control define el orden de
ejecución.
 Un BPD esta hecho sobre un set de elementos gráficos.
 Estos elementos facilitan el desarrollo de diagramas simples.
 Fueron elegidos para ser distiingible uno de otro y utiliza figuras que
son familiares para otros modeladores.
 Uno de objetivos de BPMN es crear modelos de procesos de
negocios simples, pero que pueden reflejar la complejidad inherente
de los mismos.
 Las cuatro categorías de estos elemtos son:
 • Flow Objects (objetos de flujo)
 • Connecting Objects (objetos de conexión)
 • Swimlanes (calles)
 • Artifacts (Artefactos)
 Flow Objects
◦ Un BPD tiene un pequeño set de elementos principales, que son
los objetos del flujo, por lo tanto los modeladores no deben
aprender y reconocer una gran numero de elementos. Estos son:
◦ Eventos
 Un evento, es algo que pasa durante el curso del procesos,
afectan el flujo y usualmente tienen una causa (trigger) y un
impacto (resultado).
 Se diagraman con circulos con centro abierto, que permiten
marcas internas para diferenciar el tipo de evento.
 Existe tres tipos basados en cuando afectan al flujo:
 Start (inicio), Intermediate (intermedio), and End (final).
◦ Actividad
 Una actividad es representado por un rectangulo de puntas
redondeadas y es un termino generico para un trabajo
ejecutado en la compañía.
 Una actividad puede ser atomico o no atomico(compuesto).
 Los tipo de actividad son:
 Task(Tarea) y Sub-Process (Subproceso, distigible por un signo +
en el centro de la figura).
◦ Gateway (Compuerta)
 Un Gateway se representa por un rombo y es usado para en
control de divergencia y convergencia.
 Esto determina las decisiones tradicionales, tales como división
(forking), mezcla (merging) y unión (joining) de flujos.
 Marcas internas indican el tipo de comportamiento.
 Connecting Objects
◦ Los Objetos de flujo son conectados en diagrama creando el
esqueleto basico de un proceso de negocio.
◦ Existen tres objetos de conección :
◦ Sequence Flow (secuencia)
 Un Sequence Flow es representado por una linea solida con
una flecha solida y es usada para mostrar el orden (secuencia)
que las actividades deben tener en el proceso.
◦ Message Flow (flujo de mensajes)
 Un Message Flow es representado por una linea discontinua
con una flecha abierta y es usada para mostrar el flujo de
mensajes entre dos participantes separados en el proceso
(entidad de negocio o rol de negocio).
◦ Association (asociación)
 Una asociación es representada por una línea punteada y una
flecha lineal.
 Es utilizada para asociar datos, textos y otros artefactos con los
objetos de flujo.
 Además son usadas para mostrar las entradas y salidas de las
actividades.
 Swimlanes
◦ Muchas metodologías de modelamientos de procesos utilizan el
concepto de swimlanes o calles como un mecanismo para
organizar las actividades para separar visualmente las categorias
en orden de ilustrar las diferentes funcionalidades o
reponsabilidades.
◦ Los dos tipos son:
 Pool
 Un Pool representa un participante en un proceso, también
actua como un contenedor grafico para particionar una serie
de actividades de otros Pools.
 Lane
 Un Lane es una subparticón dentro de un Pool y se
extendera a lo largo del, ya sea vertical o horizontalmente.
 Artifacts
◦ BPMN fue diseñado para permitir a modeladores y herramientas
de modelado, alguna flexibilidad extendiendo la notación básica
y entregando la habilidad de adicionar context apropiado a una
situación especifica de modelado.
◦ Se pueden agregar un sinnúmero de Artefactos, apropiado al
contexto.
◦ La actual versión predefine sólo tres tipos:
 Data Object
 Data Objects son mecanismos para mostrar como los datos
son requeridos o producidos por actividades.
 Group
 Puede ser usado para propositos de documentación o
análisis, pero no afectan al flujo.
 Annotation
 Son mecanismos para que los modeladores provean
información adicional para la lectura del BPD