1. CAPITULO 3
DISEÑO DE PROCESOS DE NEGOCIOS
Los procesos de negocios de una organización son las cadenas de actividades interrelacionadas
que existen para que ella cumpla su fin: generar productos y servicios para clientes internos o
externos. Estas cadenas cortan horizontalmente las áreas funcionales tradicionales y exigen un
diseño que asegure un funcionamiento coordinado y eficiente del conjunto de actividades que las
componen.
Los procesos, apoyados por Tecnologías de Información hardware, software y redes de
comunicación, hacen fluir los documentos, facilitan la coordinación y apoyan la realización de las
actividades. Los procesos existen en las empresas, pero su funcionamiento ha sido fruto de la
historia y la experiencia. Dada la naturaleza burocrático-funcional de las organizaciones, ha habido
cambios y mejoras puntuales en ellos, pero rara vez sistémicas y orientadas al cumplimiento de los
objetivos globales de los mismos, por lo que son –en general– extremadamente ineficientes. El
enfoque de proceso consiste en que las actividades, en diferentes áreas funcionales que
componen una cadena asociada a la generación de algún bien o servicio.
El enfoque de proceso es potencialmente revolucionario, por cuanto permitiría romper las
barreras funcionales que hay típicamente dentro de una organización, haciendo posible una
coordinación explícita entre áreas que, dentro de un esquema tradicional burocrático-funcional, se
manejan en forma relativamente independiente.La disponibilidad de cada vez más potentes y
económicas Tecnologías de la Información (TI) hace que el manejo organizacional sea más
susceptible de ser apoyado computacionalmente.
La literatura de reingeniería y rediseño de procesos y la de mejores prácticas reconocen varios
procesos que nosotros consideramos parte de este macroproceso; por ejemplo, capturar
información de mercado, selección de mercados, diseño e ingeniería del producto, mantención del
producto, entender el mercado, entender las necesidades y deseos de los clientes y segmentar
clientes. Además en ella se entregan recomendaciones acerca de cómo llevar a cabo estos
procesos y de cómo involucrar a los clientes y proveedores en el desarrollo de nuevos productos y
servicios.
Las interrelaciones entre los macroprocesos se dan por medio de flujos. Éstos representan cómo
un macroproceso requiere y se alimenta de los productos o servicios de otros. Los flujos pueden
ser físicos en cuanto a representar cosas materiales o información en cuanto a ser abstracciones
de cosas materiales.

2. Al intentar el diseño o rediseño de procesos, enfrentamos la necesidad de contar con
herramientas similares a las que han usado por mucho tiempo las ingenierías tradicionales que
realizan diseño en variados contextos: obras civiles, maquinarias, procesos minero-metalúrgicos,
procesos de manufactura, redes eléctricas, etc. Al nivel más básico se requieren representaciones
de procesos que sean equivalentes a los planos de tales ingenierías, los cuales entregan una visión
estática de los componentes de un diseño y sus interrelaciones. En un nivel más avanzado
requerimos –al estilo de los productos CAD/CAM, de simulación de procesos productivos y de
cálculo computarizado– una capacidad de “hacer funcionar” un proceso en forma simulada para
poder evaluar su comportamiento y desempeño dinámico.
El modelo presentado es una arquitectura genérica, a partir de la cual se pueden diseñar
instancias que representan situaciones o procesos específicos. Como arquitectura provee,
entonces, un espacio de posibilidades, en cuanto a que las funciones y flujos presentados pueden
dar origen a muchas instancias diferentes. Sin embargo, cualquier instancia debe respetar la
“filosofía” del modelo que indica claramente cómo debe derivarse; en particular, debe respetarse
la estructura de componentes y relaciones.
La tecnología Internet reduce los costos de transacción y promueve la aparición de agentes
intermediarios que facilitan el uso del mercado, como mercados electrónicos, sindicalizadores y
servicios Web. Por lo tanto, los e-Business tienen facilidades para externalizar todo que no es
parte del corazón del negocio. Casos de esta tendencia son: la externalización del transporte a
especialistas en logística, como FedEx la fabricación de componentes estandarizados de producto.
Las empresas que ofrecen productos de información puros –como Google, Britannica, etc., no
tienen problemas de logística, por lo cual el diseño de su estructura organizacional se simplifica
enormemente. El caso más interesante es el de empresas que ofrecen una combinación de
productos físicos e información. Aquí la tendencia parece ser de convergencia de las empresas que
ofrecen productos físicos y las que ofrecen productos de información a un modelo único. En
efecto, empresas como Amazon.com están evolucionando desde empresas fundamentalmente
distribuidoras e-Tailing– a plataformas de negocios, en las que lo que vale y se vende es el acceso
a la atención de una enorme cantidad de potenciales compradores. En este modelo, al cliente se le
ofrece una gran cantidad de opciones de productos en forma consolidada y mecanismos para
buscar y comparar. Obviamente se desincentiva la parte logística, la cual se delega a las empresas
que venden sus productos a través del sitio en cuestión.
La generación de versiones está íntimamente relacionada con el diseño de líneas de productos. La
idea fundamental es generar versiones para diferentes segmentos de mercado, adaptando cada
una de ellas a las necesidades de éstos. La personalización de productos físicos es posible en
Internet, debido a la gran cantidad de información que se puede generar acerca de los
consumidores para los productos de información, la cual permite entregar información en línea
útil para apoyar la compra y realizar ofertas en forma proactiva.
La especialización de un modelo a un subdominio implica mayor precisión en términos de cómo
deben realizarse las actividades y flujos del mismo, con la posible especificación de prácticas
concretas de trabajo, reglas y algoritmos de toma de decisiones, flujos detallados de información
de estado que apoyan a las actividades, actualizaciones específicas de Mantención estado,
mecanismos específicos de comunicación y coordinación entre actividades, etc. La fuente para
estos detalles de especialización esel conocimiento y experiencia acumulados con casos que

3. pertenezcan al subdominio, o a casos del dominio u otros dominios, cuyas prácticas sean
extrapolables a aquél.Los patrones se pueden aplicar a casos específicos partiendo de un dominio
o subdominio que incluya el caso en cuestión. Obviamente, si se parte de un subdominio, por ser
éste más específico, el trabajo será más directo.
Cada una de las actividades del patrón debe caracterizarse por medio de entregar la práctica
específica de trabajo que se propone para realizarla. Dependiendo del caso, esto puede ir desde
una regla o algoritmo totalmente estructurado –implementado parcial o totalmente con apoyo
computacional– hasta sólo una descripción general de lo que se espera de la actividad, quedando
los detalles al criterio de la persona que la ejecuta.
CAPITULO 4
DISEÑO DE LA ARQUITECTURA DE UN E-BUSINESS
A partir de un cierto modelo de negocio, que requiere un conjunto complejo de actividades
interrelacionadas asociadas a la generación y entrega de un producto o servicio, se determinan los
procesos que deberán diseñarse.
El diseño de la arquitectura de un e-Business, que une el diseño del negocio expresado por medio
de un diseño de sus procesos y el diseño del apoyo computacional detallado al mismo, basado en
tecnología Internet de n capas, puede considerarse como una adaptación y extensión de la
metodología.
La arquitectura de un e-Business la caracterizaremos partiendo de un diseño de los procesos del
negocio. Este diseño detalla las actividades humanas y computacionales que interactúan en un
proceso por medio de flujos de información en papel o digitales. Tal detalle nos permite
descomponer la arquitectura en subprocesos que se pueden considerar en forma relativamente
independiente –aunque persisten interacciones a través de flujos y Mantención de Estado–, para
efectos de especificarla en detalle.
La especificación de la arquitectura para cada subproceso la haremos de la Siguiente manera:
i) Identificación de los requerimientos de apoyo tecnológico requerido, los cuales se desprenden
en forma obvia del diseño del proceso.
ii) Modelamiento del apoyo tecnológico a base de la arquitectura tecnológica.
iii) Especificación de la lógica del negocio que se ejecuta en las diferentes actividades del proceso;
en particular, para las actividades que serán automatizadas, la lógica se dará en un lenguaje o
esquema formal que permita su programación computacional.
iv) Afinamiento de los flujos –de papeles y, especialmente, los digitales– que permitirán la
interacción entre actividades de acuerdo al diseño del proceso y los detalles establecidos en (ii) y
(iii).
v) Detalle formal de los atributos asociados a los flujos digitales para efecto de posterior diseño de
documentos electrónicos, páginas Web, pantallas y bases de datos necesarias para el apoyo
tecnológico.

4. El caso de venta a personas corresponde a una situación típica de una empresa que vende a
público (por Internet) y que mantiene stock de los productos que distribuye. Una lógica mínima
para tal situación, dividida en verificación cliente, crédito y stock, Evidentemente esta lógica puede
ser mucho más compleja en situaciones donde el riesgo tiene que ser evaluado más finamente
productos financieros.
Los paquetes tipo ERP/ERM tienen las partes más simples y estandarizadas de este tipo de lógica
ya preprogramada, con la posibilidad de uso de parámetros de adaptación. Las partes más
complejas, como el caso del banco, requerirán la programación de la lógica en lenguajes
propietarios. El enfoque que aquí se propone consiste en complementar los ERP/ERM, cuando
ellos existan, implementando la lógica del negocio adicional necesaria en servidores de aplicación.
Los modelos se generan a partir de la Base de Datos de Marketing, que contiene una historia de
múltiples atributos del cliente, tales como los productos que ha tenido y tiene, la evolución de su
nivel de facturación, su desempeño en cuanto a pagos, etc. Para ello como, se desarrollan las
siguientes actividades:
i) Exploración de datos. En esta actividad se evalúan correlaciones estadísticas entre atributos para
determinar relaciones no triviales en los datos. La idea es identificar aquellos campos que son
relevantes para generar algún modelopredictivo.
ii) Adecuación de variables a los modelos de Business Intelligence. Aquí se preparan los datos para
el modelamiento, seleccionando las variables y el tamaño de la muestra a utilizar. En el caso de
que no existan variables importantes, éstas se construyen. Además, se transforman aquellas
variables que no estén normalizadas (como las categóricas).
iii) Ejecución de los modelos. Se ejecutan los modelos y se van calibrando de acuerdo a los
resultados obtenidos. Una vez calibrados, éstos se validan de acuerdo a criterios predefinidos para
encontrar el número óptimo de clusters.
iv) Análisis de resultados y generación de reglas. Se interpretan los resultados y se evalúan usando,
por ejemplo, matrices de confusión o bien realizando análisis de sensibilidad, empleando datos
nuevos y variando parámetros de los actuales. Dado los resultados de estos análisis, se elaboran
los modelos de comportamiento.
La Lógica cálculo de requerimientos del plan de ventas determina período a período por ejemplo,
semanal las cantidades de productos necesarias para cumplir con el plan de ventas de productos
de la empresa. Esto lo hace restando al plan de venta los inventarios existentes y los pedidos en
proceso y agregando un margen de seguridad. Aquí se ha supuesto que la política de la empresa es
de integración con proveedores con contratos de compra y entrega según necesidad de la
empresa en la línea de “justin time”, hecho de acuerdo a los requerimientos.