1. INGENIERÍA PARA NEGOCIOS E-BUSSINESS
CAPITULO 3
DISEÑO DE PROCESOS DE NEGOCIOS
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.
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.

2. 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 es el
conocimiento y experiencia acumulados con casos que 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.

3. 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.
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.

4. 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 “just in time”, hecho
de acuerdo a los requerimientos.