Organización y procesos de Negocios

Organización
Conjunto de personas reguladas por un conjunto de normas en función de determinados
fines (DRAE).

Es un sistema compuesto por un conjunto de personas, actividades y recursos, distribuidas

de alguna forma con arreglo a ciertas reglas de división del trabajo y comunicación que
interactúan para producir bienes o servicios.

Las actividades se pueden organizar de dos formas: Estructura funcional (vertical)

estructura por procesos (horizontal). Para poder establecer una estructura de procesos es
necesario conocer las actividades de la organización.

Enfoque funcional
Cada función busca optimizar sus propias actividades, incluso a costa del rendimiento
global de la organización.

Su foco de análisis es la tarea o función, su objetivo es la optimización de las tareas

Se orienta al interior de la organización

Tiene una visión fragmentada.

Básicamente se centran en su área y se separan de los demás.

Enfoque de procesos

Se rompen las barreras funcionales por medio de las cuales se producen los productos y/o
servicios.

Se busca satisfacer al cliente

Su foco de análisis es el proceso, su objetivo es la mejora de los procesos.

Se orienta esencialmente al cliente

Tiene una visión global.

La idea es mejorar los procesos de negocio de la empresa como ingenieros de sistemas.

Generalmente se establecen, en los libros, los niveles en una organización como una
pirámide. Los niveles de mayor a menor serían: nivel estratégico (director); administrativo
(gerentes de nivel medio); conocimiento (trabajadores del conocimiento); operativo
(gerentes operativos).

El nivel operativo se encarga de hacer que la organización funcione. Los trabajadores del
conocimiento son los que tienen que tomar decisiones en ya si ocurren problemas en el
área operativa. Los administradores son los que tienen que tomar decisiones a mediano
plazo de cómo se trabaja en su área/proceso. Los directores son los que toman las
decisiones a largo plazo de toda la compañía.

¿Que es un proceso de Negocio?

Tenemos dos definiciones básicas:

● Un proceso es un orden específico a actividades a través del tiempo y lugar, con un

comienzo y fin, estradas y salidas: una estructura para la acción.
● Un proceso de negocio es un conjunto de actividades que toman uno o más tipos de
inputs y crean un output que es un valor para un cliente.

Ejemplo: UN proceso de atención de un pedido:

Ventas recibe el pedido e inicia el trámite, contabilidad verifica el crédito y se factura el

pedido, manufactura produce el pedido y lo envía.

Podemos concluir que un proceso de negocios es un conjunto de acciones/actividades que

se rigen bajo unas reglas para transformar una entrada para crear una salida de valor para
el cliente.

Es conveniente conocer los tipos de procesos de negocio. Los libros indican que
generalmente en una organización hay 3 procesos de negocio.
● Procesos principales: generan las salidas de valor para el cliente.
● Procesos de soporte: Ayudan a optimizar los procesos principales. Nunca hay
clientes.
● Procesos de gestión: Se hacen actividades gerenciales que mantienen la empresa.

Procesos Principales
Los procesos principales o sustantivos son aquellos que están ligados directamente con la
realización del producto y/o la prestación del servicio al cliente.

Son los procesos de la línea, hacen realidad la misión de la organización.

Proceso de Soporte
Los procesos de soporte son aquellos que proporcionan apoyo a los procesos principales o
sustantivos. Usualmente están relacionados con la gestión de recursos.
Procesos de Gestión
Los procesos de gestión son aquellos que están vinculados al ámbito de las
responsabilidades de la dirección. Se relacionan con actividades de planificación y control.

¿Cómo se describen los procesos de negocio?

Es más fácil establecer estos procesos de manera visible con un diagrama de actividades
que con todas las reglas escritas. Algunas actividades se pueden hacer en paralelo a otras
actividades.

Gracias a los nuevos paradigmas que se presentan en las empresas gracias al paso del
tiempo es lo que provoca que el esquema funcional deje de ser completamente útil y es
necesario cambiar el enfoque.

Por lo que se considera el uso del enfoque por procesos que permite una comunicación con
todos los departamentos para poder llevar a cabo los objetivos, lo que nos permite una
orientación hacia los resultados.

Los clientes son importantes para las organizaciones, no se puede sobrevivir sin clientes,
por lo que si lo tratamos de colocar en el enfoque funcional no es muy fácil saber donde
colocarlo. Por lo que con el enfoque de procesos nos permite colocarlo al inicio de la
comunicación horizontal de los departamentos, logrando una orientación hacia los
clientes.

Apuntes de video

El desarrollo en una organización si o si será hecha por personas que sepan tomar
decisiones. Y estas personas pueden ir aprendiendo, innovando y mejorando
continuamente el proceso. Por lo que si tratamos de tener estos puntos en el enfoque
funcional, esto sera mas dificil puesto que se tienen que seguir las directivas de los puestos
más altos en la jerarquía y no permite la innovación por parte de los puestos más bajos que
son los que estan al dia a dia con el área operativa y el cliente, aprendiendo sobre ella y
puede que incluso innovando soluciones. Esto permite una autonomía por parte de las
personas.

Las actividades que realiza cada departamento deben de apuntar a agregar valor al
producto final. Entonces podemos incluso agrupar actividades y llamarlas un proceso de
negocio principal, incluso podríamos tener varios procesos en paralelo.

Existen varios procesos que no agregan valor al producto pero son importantes para la
empresa, como lo vimos en apuntes anteriores.

Ahora, un proceso está constituido por entradas, salidas, objetivos, un encargado de que se
cumplan los objetivos, y un procedimiento que puede incluir subprocesos.

La gestión de procesos se define en 4 puntos:

 1. Definir el mapa de procesos existentes y relaciones entre ellos, esto tiene que ser de
manera general.
2. Establecer el proceso piloto, es preferible ser un proceso operativo, que afecta
directamente al producto. El encargado de gestionar el proceso debe ser uno de los
administrativos que tenga más interacción con el proceso.
3. Identificar misión y objetivos, entradas (proveedores) y salidas (clientes),
procedimientos y actividades; y definir la sistemática de gestión seguimiento y
mejora (personas, reuniones, indicadores, etc). Esto tiene que ser de manera
general.
4. Aplicar la gestión del proceso y revisar que lo que establecimos en el paso tres se
vaya cumpliendo.

Modelado de Negocio
Es una técnica para representar procesos del negocio.
Permite asegurar que se construirá el sistema en el contexto de las necesidades de la
empresa.
El contexto está dado por:
● El ambiente en el que el sistema trabajara.
● Los roles y responsabilidades de los empleados que usarán el sistema.
● Las cosas que son manejadas en el negocio.

Este modelo tiene dos perspectivas, el modelo de los casos de Uso del Negocio
(perspectiva externa) y el modelo de análisis del negocio (perspectiva interna).

En los casos de uso del negocio se establecen cuáles serán esos procesos que se
realizarán en la organización, pero su descripción se hace en el modelo de análisis del
negocio. Por lo que podemos indicar que primero se hacen los casos de uso y después el
análisis.

Modelos de casos de uso del negocio (CUN)

Es una representación de la forma en que la empresa interactúa con su entorno, provee una
visión general.

Provee una visión general de lo que la empresa hace con sus clientes y participantes, este
proceso solo los usaremos de manera muy superficial para poder diseñar el sistema.

Incluye metas del negocio además de actores (generalmente clientes) y casos de uso del
negocio (generalmente procesos).

Los elementos del CUN son:

● Actores del negocio: Representa un rol que desempeña alguien o algo en la relación
del negocio.
 ● Caso de uso del negocio: Conjunto de secuencias de acciones que un negocio
realiza para producir un resultado observable para un actor del negocio (pueden
considerarse como los procesos de negocio (recordar que hay varios)).
● Meta del negocio: Describe el valor deseado en una medida particular que puede ser
usada para planificar y administrar las actividades del negocio.
● Diagrama CUN: Muestra la relación de los elementos anteriores.

Actor de negocio
Para establecerlo es necesario revisar que el individuo, grupo, organización, empresa o
máquina sea externo al negocio que interactúa con ella.

Generalmente son: clientes, socios, proveedores o autoridades; entidades legales y

reguladoras; sucursales; Dueños o inversionistas; sistemas informáticos fuera del negocio
con los que se interactúa; o incluso si el negocio que se va a modelar es parte de una gran
empresa, estas categorías también pueden contener actores de negocios, tales como: otras
parte de la empresa y papeles individuales en el marco de otros departamentos.

Caso de Uso del Negocio

Los casos de uso del negocio son los procesos del negocio. Pueden ser de tres categorías:
Principales, Soporte, Gestión.

Las metas del negocio pueden ser minimizar tiempo, mejorar el servicio y confiabilidad y
seguridad.

Después solo se hace el modelo dibujado y listo.

Modelo de Análisis de Negocio

Describe la realización de los casos de uso del Negocio mediante la interacción de los
trabajadores del negocio y las entidades del negocio.

Los elementos del análisis del negocio son:

● Trabajador del negocio: Es una abstracción de una persona o sistema de software

que representa un rol que se ejecuta dentro de la realización de un CUN
● Realización de caso de uso del negocio: Describe cómo los trabajadores, entidades
y eventos del negocio colaboran para desarrollar un caso de uso del negocio. Se
usan los diagramas de clases y de actividades para describirlos.
● Entidad del negocio: Representa una pieza de información significativa y persistente
que es manipulada por los actores y trabajadores del negocio. Pueden estar dentro y
fuera del negocio.
● Reglas de Negocio: Es una declaración de políticas o condiciones que deben de ser
satisfechas.
Introducción a los sistemas de información
Datos: Los datos son registros de hechos/eventos no procesados. Los datos no tienen
ningún significado en particular.

Información: es un conjunto de datos para algún propósito en particular. Como ya están

procesados ya tienen significado (Generalmente guardada en un Data Warehouse en una
DB).

Conocimiento: Es la información conectada a decisiones y acciones capaces de aplicar esa

información.

La información debe de tener los siguientes atributos:

● Correcta (Sin errores)
● Oportuna (Debe de estar siempre a tiempo)
● Disponible (se accede a ella siempre)
● Concisa (Tamaño y longitud delimitado)
● Relevante (Destacar siempre lo esencial)
● Completa (posibilidad de complementar, ampliar o hacer trazabilidad)

Un sistema de información es un conjunto de componentes (Usuarios y Especialistas,

hardware, software, datos/info, procedimientos) interrelacionados que permiten recopilar,
procesar, almacenar y distribuir la información necesaria para apoyar la toma de decisiones,
la coordinación y el control de una organización.

Funciones de un sistema de información:

● Capturar
● Procesar
● Generar
● Almacenar
● Recuperar
● Transmitir

Beneficios:
● Reducir y/o remplazar trabajo humano
● Procesar modelos complejos de análisis
● Comunicación a larga distancia
● Interconectar las partes de un proceso

Todo Sistema de información va a cumplir objetivos. Para ello se necesitan los

procedimientos y prácticas de trabajo que usarán información, personal y equipo (no solo de
TI).
Existen diferentes sistemas de información y estos están basados en la pirámide
administrativa de la jerarquía en una organización:
● Operativo
● Conocimiento
● Administrativo
● Estratégico
La función de estos sistemas es apoyar a las actividades de las jerarquías.

hay otra forma de clasificar los sistemas de información y es según la función que
desempeñan:
● Sistemas de procesamiento de transacciones
● Sistemas de información general
● Sistemas de soporte de decisiones
● Sistemas de información ejecutiva
● Sistemas de automatización de oficinas
● Sistemas Expertos
● ERP

Estos sistemas fueron apareciendo de manera cronológica en las empresas.

Proceso y Ciclo de vida del software

Proceso de software
Es un marco de trabajo que define las tareas a realizar para desarrollar software.

Una visión genérica de estas fases de un proceso de software son: Definición, desarrollo y
evolución.

Definición:
● Análisis de sistema: Define el papel de cada elemento del sistema de información,
asignando finalmente al software el papel que va a desempeñar.
● Requerimientos: Es lo que el usuario necesita que el proyecto realice.
● Planificación: cuánto, cómo y cuándo va a estar el proyecto software.
Se deben de identificar la información que se debe proporcionar, funcionalidad y
rendimiento deseado, interfaces a establecerse, restricciones de diseño y criterios de
validación necesarios para definir que el sistema sea correcto.

Desarrollo:
● Diseño: Definición de estructuras, pantallas, funciones, etc.; respecto a los
requerimientos.
● Codificación: Traducción del diseño a un producto/prototipo
● Pruebas: Realizar Pruebas
Se deben decidir cómo se van a diseñar las estructuras de datos y la arquitectura del
software, la traducción del diseño a un lenguaje de programación y a un producto/ prototipo
y las pruebas que se le realizarán.

Evolución
● Corrección
● Adaptación
● Mejora
Se debe de centrar en los cambios asociados a: corrección de errores, adaptaciones por
evolución del entorno de software, modificaciones por parte de requisitos nuevos del
usuario, y se repiten las primeras fases del proceso de software pero con lo que ya se tiene.

Requerimientos
De Acuerdo al Standish Group, los proyectos de software fallan un 18%, se desvían un 53%
y se completan exitosamente un 29% en el año 2004.

Un proyecto es exitoso cuando se cumple con tiempo, costo y con todas las características
y funcionalidades especificadas.

Los porcentajes de proyectos cancelados se deben a varios factores. De Acuerdo a

CHAOS, A Standish Group Report (1998), se tiene que son por:
● Falta de soporte (9.3%)
● Falta de recursos (10.6%)
● Requisitos/especificaciones incompletas o cambiantes (21.8%)
● Usuarios no involucrados (12.4%)
● Expectativas no realistas (9.9%)
● No se necesito al final del desarrollo (7.5%)
● Problemas tecnológicos/técnicos varios (porcentaje restante)

Generalmente se tienen errores en la especificación de requerimientos por problemas de

comunicación entre los desarrolladores, clientes y usuarios. Si los errores se descubren
tarde, terminan siendo caros de corregir a posteriori.

Es importante separar el problema de la solución cuando se está analizando el sistema. Un

error es pensar la solución cuando no se ha analizado el problema.

En el espacio del problema se tiene el problema y las necesidades generadas por el

problema. Estas necesidades serán definidas por el modelado del negocio.

En el espacio de la solución, se aplicará ingeniería de requerimientos para obtener

aspectos/características, requisitos de software y al último se realizan los procedimientos de
pruebas, el diseño y la documentación del usuario para generar una solución que en
nuestro caso será software.

Para las necesidades se tendrán los stakeholders (usuarios) que serán los que tengan esas
necesidades, las necesidades (que será una descripción del problema del stakeholder) y la
característica que será una descripción de la función que haga el sistema para darle
solución a la necesidad.

Ahora, pasamos a los requerimientos pero es importante definirlos primero.

Un requerimiento es una condición o capacidad a la que debe ajustarse el sistema que se

construye.
De Acuerdo a la IEEE, un requisito es:
● Una condición o capacidad necesaria para un usuario para resolver un problema o
conseguir un objetivo
● Una condición o capacidad que debe reunir o poseer un sistema o componente de
un sistema para satisfacer un contrato, estándar, especificación, u otro documento
formalmente impuesto.
● Una representación documentada de una condición o capacidad como las definidas
en los puntos anteriores.

Hay varias maneras de clasificar los requerimientos pero la más común está descrita por el
modelo FURPS+:
● Functionality (funcionalidad)
Que debe de hacer el sistema respecto a su entorno
Especifican comportamientos de Entradas y Salidas.
Se captura con los casos de uso.
● Usability (capacidad de uso)
Facilidad o nivel de uso del producto.
Define factores
Humanos
Estética
Consistencia de interfaz
Ayudas en línea
Agentes Wizards
Documentación
● Reliability (fiabilidad)
Capacidad para ejecutar sus funciones requeridas bajo condiciones normales
en un periodo de tiempo específico.
Subcategorías
■ Frecuencia/severidad de errores
■ Capacidad de recuperación
■ capacidad predictiva
■ Exactitud
■ Tiempo promedio entre fallas
● performance (Desempeño)
○ Velocidad
○ Eficiencia
○ Disponibilidad
○ Exactitud
○ Tiempo de respuesta
○ Tiempo de uso de recursos entre fallas
● Supportability (capacidad de Soporte)
○ Pruebas
○ Extensión
○ Adaptación
○ Mantenimiento
○ Compatibilidad
○ Configuración
○ Instalación y localización
 ● +
○ Restricciones de diseño
○ Implementación
○ Interfaz
○ Físicos
○ Etc.

Los requerimientos no funcionales (también conocidos como adicionales) describen

atributos del sistema o del ambiente en donde este se desarrolló (encapsulación de todos
los que vimos que están en el +)

Modelo de casos de uso

El modelo de casos de uso es un modelo que describe los requerimientos funcionales del
sistema en forma de Casos de Uso.

Elementos del modelo:

● Actores
Definir un conjunto coherente de roles que los usuarios del sistema pueden jugar
cuando interactúan con el
Una instancia de actor puede ser un individuo o un sistema externo
Un actor puede interactuar con otro actor
● Casos de uso
Un caso de uso define un conjunto de instancias de casos de uso
Una instancia es una secuencia de acciones e interacciones entre el actor y el
sistema que proporciona valor a un actor particular.
● Descripción del caso de uso
Se usa una plantilla para hacer un registro de manera escrita de la información que
conforma al caso de uso.
Generalmente lleva:
○ Caso de uso:
■ Nombre del caso de uso
○ Actor:
■ Nombre del actor
○ Precondición:
■ Condición que debe ser verdadera para iniciar caso de uso. Estas se
definen respecto al sistema y no al entorno.
○ Poscondición:
■ Condición que debe cumplirse para indicar que el caso de usa ha
terminado con éxito.
○ Flujo de eventos básico:
■ Secuencia de eventos que describen qué hace el actor y el sistema
en el caso de uso para cumplir un objetivo. También se conoce como
flujo normal, pues no incluye variaciones o desviaciones.
○ Flujos de eventos alternativos:
■ Diversas secuencias que reflejan las diferentes situaciones que
provocan una desviación del flujo básico de eventos. Son provocadas
 por condiciones: anormales, extremas, ocasionales, de error o
violacion de las reglas del negocio para el caso de uso.
Generalmente se usa con un formato a dos columnas donde se ve a la par las
acciones del actor y del sistema en el flujo básico del caso de uso.

● Diagrama de casos de uso

○ Muestra la relación entre los casos de uso, actores y sistema de una manera
gráfica.
Los diagramas varían pero nosotros usaremos los de UML los cuales fueron aceptados por
la OMG y se estandarizó en la ISO 19501. Por lo que nos basaremos en esos
(generalmente en internet todos usan los mismos).

Modelo de dominio
Es un modelo conceptual que muestra clases conceptuales significativas en un dominio de
problema.

Las clases conceptuales no muestran componentes de software, ni clases de software, ni

responsabilidades.

La principal tarea del análisis orientado a objetos es identificar diferentes conceptos en el

dominio del problema y documentar el resultado en un modelo de dominio

El modelo de dominio se puede documentar con un diagrama de clases.

Diagrama de clases
Un diagrama de clases es un tipo de diagrama estático, que describe la estructura de un
sistema mostrando sus clases, atributos, operaciones y las relaciones entre ellos.

Los elementos del modelo de dominio son:

● Clases conceptuales
○ Es una idea, cosa u objeto.
○ Puede considerarse como
■ Símbolo
● palabras o imágenes que representan una clase
conceptual.
■ Definición del concepto
■ Extensión:
● Conjunto de objetos que pertenecen a la clase.
● Asociaciones
○ Los objetos/cosas del mundo real se relacionan con otras cosas. Las
relaciones entre objetos son enlaces y las relaciones entre clases se
llaman asociaciones.
● Operaciones
○ Acciones que puede realizar la clase
 ● Atributos
○ Propiedad de una clase y describe un rango de valores que la
propiedad podrá contener en los objetos de la clase.

Especialización/Generalización
Es una relación entre una subclase que hereda los métodos y atributos especificados de
una superclase.

Se llama generalización cuando varias subclases abstraen información más general de la

superclase. Mientras que se llama especialización cuando la subclase tiene características
más particulares. En prácticamente son los mismo y solo cambia el enfoque con lo que lo
veas.

Agregación
Es cuando una superclase tiene como relación muchas subclases que la conforman.
En una agregación la existencia de las partes es independiente de la existencia de la clase
que la conforma (partes de una computadora - computadora). Mientras que una
composición la existencia depende de la existencia de la clase que la conforma (municipios
- estado).

Para Construir un diagrama de clases es necesario:

● Identificar las clases,
● Identificar las Asociaciones
● Identificar los atributos
● Organizar usando herencias
● Verificar el modelo

Matriz de trazabilidad
Revisar PMBOK o artículos relacionados a él.