comp logica 2

7/31/2019 Comp Logica 2

1/33

COMPONENTES DE LOGICA DEL NEGOCIODESARROLLADOS A PARTIR DE PATRONES DE PROCESOS

OSCARBARROSV.

SERIE GESTION N34Marzo, 2002

Centro Gestin (CEGES)Departamento de Ingeniera Industrial

Facultad de Ciencias Fsicas y Matemticas

Universidad de Chile


2/33

Componentes de Lgica del Negocio desarrollados a partir de Patrones de Procesos Oscar Barros

1

COMPONENTES DE LOGICA DEL NEGOCIODESARROLLADOS A PARTIR DE PATRONES DE PROCESOS

1. La Necesidad

Para satisfacer las necesidades de apoyo con Tecnologas de la Informacin a los div

procesos de negocios que se ejecutan en las empresas, stas han recurrido, bsicamente,

enfoques. El primero es el desarrollo de soluciones a la medida, el cual implica, si es hech

manera correcta, redisear los procesos de negocios y, a partir de stos, disear y constr

apoyos computacionales que permitan ejecutar tales procesos mejorados [3]. El segundo c

en usar software empaquetado del tipo ERP, CRM o paquetes ms primarios, los cuales pr

algunas funcionalidades que contienen implcitamente ciertas prcticas de negocios.

deberan dar lugar a un cambio en los procesos de negocios, pero habitualmente s

implementa el software. Los paquetes de mayor nivel, que son tambin los ms caros, faci

adopcin o adaptacin de ciertas prcticas negocios, por medio de las llamadas parametriza

las cuales permiten un cierto grado de flexibilidad [3]. Con esto es posible redisear los pr

en alguna medida, lo cual se hace en escasas oportunidades, dado lo complejo y caro

parametrizaciones y el riesgo de tener que rehacer el trabajo cuando hay cambio de versi

software.

En resumen, la tendencia actual, al usar software empaquetado, es hacer adaptac

mnimas del mismo a los procesos de negocios de la empresa y ojal usarlo tal como es

acelerar y disminuir el costo de las implementaciones. Esto es evidentemente verdader


3/33


2

mayor razn, cuando se utilizan paquetes econmicos que son esencialmente rgidos- en la

PYMES.

Presentamos aqu un enfoque original que trata de incorporar las mejores caractersti

los enfoques anteriormente bosquejados: la flexibilidad del desarrollo a la medida que permite

mejorar los procesos de negocios por medio de un rediseo y tener software perfecta

adaptado al mismo- y la rapidez y potencial ms bajo costo de una solucin de sof

preconstruida, lista para usar, que provee el segundo enfoque.

Nuestra propuesta se basa en dos ideas fundamentales: el rediseo de los proces

negocios a base de patrones preestablecidos [3] y el uso de componentes de sof

preconstruidos, los cuales estn desarrollados a partir de los patrones.

La estrategia que proponemos consiste, entonces, en comenzar con un rediseo

proceso de negocio de una empresa, a partir de un patrn que establece cmo debera funcio

proceso en un cierto dominio, de acuerdo a las mejores prcticas conocidas [3]. Al hacer e

toman en cuenta las condiciones existentes en la empresa donde existe el proceso, para facti

las mejoras. Una vez establecido un rediseo, se recurre a los componentes de sof

previamente desarrollados a partir de los mismos patrones que apoyan el rediseo-, los cuale

especializan, usando tecnologa de orientacin a objetos, al caso particular, para conform

solucin de software especfica para el proceso en cuestin.


4/33


3

En este documento mostramos cmo, utilizando una metodologa original y herram

de punta para diseo e implementacin de software orientado a objetos, es posible g

componentes genricos de software, a partir de patrones de procesos que incluyen mprcticas. El centro de atencin est en procesos que tengan una alta componente de lg

negocio y que involucren decisiones importantes en relacin a cmo satisfacer los requerim

de los clientes y tender a un uso ptimo de los recursos de la empresa. Adems, mostramo

los componentes de software genricos pueden internalizar la lgica del negocio de una m

flexible, la cual permite a una empresa optar por diferentes posibilidades de manejo d

decisiones del proceso y complementarla si fuese necesario. Para lograr esto desarrolla

concepto de lgica de negocio incremental.

Por ltimo, estableceremos un procedimiento de especializacin de los componente

rediseo particular para la conformacin de una solucin de software al proceso en cuestin

Por ser las PYMES las posibles mayores beneficiadas con un enfoque como el prop

dada la imposibilidad que tienen de contratar asesora cara para mejorar sus proce

desarrollar software a la medida, o comprar software empaquetado de clase mundial-, restri

nuestro planteamiento a lgica del negocio simple, pero rigurosa, adecuada para este t

empresas. Esto no implica que el enfoque no sea generalizable a soluciones con mayor gr

sofisticacin para grandes empresas.

Creemos que el enfoque propuesto define una nueva manera de hacer software de ap

procesos, que puede originar la creacin de una industria de software proveedora de compo


5/33


4

orientados al negocio, lo cual permitira soluciones ms flexibles y econmicas, particular

relevantes para PYMES, como ya se indic.

2. Patrones de Procesos de Negocios

2.1. Planteamiento general

La idea de patrones de procesos se encuentra detallada en un libro [3],

publicaciones [2] y el sitio web del autor (obarros.cl ). Por lo tanto, damos aqu un muy

breve resumen de sus ideas fundamentales.

Los procesos existen en las empresas, pero su funcionamiento ha sido el fruto

historia y la experiencia. Dada la naturaleza funcional de las organizaciones, los cam

y mejoras han sido puntuales, en las actividades bajo una gerencia de rea, pero rar

sistmicos y orientados al funcionamiento y al cumplimiento de los objetivos de

empresa en su conjunto, lo cual hace que, en general, los procesos de negocios

extremadamente ineficientes. De aqu se origin la idea de rediseo de procesos

consiste en tomar las actividades de un proceso en su totalidad y someterlas a un ca

fundamental el cual habitualmente implica un uso intensivo de Tecnologas de

Informacin que garantice un desempeo claramente mejorado del mismo. Por ejem

en el caso de crdito hipotecario, a base de un flujo electrnico (workflow ) de los

documentos, eliminando pasos y autorizaciones innecesarias, conseguir una reduc

significativa del tiempo de curse de una operacin.


6/33


5

La experiencia muestra que el rediseo de procesos lleva a soluciones similar

procesos del mismo tipo. Por esto, no hay razn alguna para pensar que un red

optimizado del proceso de crdito hipotecario debiera ser muy diferente de un baotro. Asimismo, el proceso de satisfaccin de pedidos rediseado en una empre

distribucin no tiene que tener diferencias fundamentales de otra del mismo rubro

proceso de atencin de urgencias rediseado en un hospital pblico no debera dife

de otro.

La idea de procesos comunes a muchas empresas puede desarrollarse observ

que, en cualquier organizacin, hay un nmero pequeo de procesos entre 7 y 15 y que

cada uno de ellos, adems de tener una arquitectura o estructura comn que compar

los otros, es muy parecido en su esencia en diferentes contextos [1]. As, este au

demostrado que los procesos de crdito hipotecario en un banco, la satisfaccin de pe

en una empresa manufacturera, la atencin de urgencia en un hospital y muchos

corresponden a instancias de una estructura comn con actividades y relaciones del

mismo tipo de un proceso que ocurre en todas las organizaciones y que gener

producto o servicio que los clientes externos demandan. A esta estructura com

llamamos patrn de proceso [3].

La consecuencia de definir patrones de procesos en detalle que toman la forma de

modelos grficos de fcil comprensin reside en que en ellos se pueden internalizar l

mejores prcticas desarrolladas en muy diferentes contextos, conformando

acumulacin de conocimiento normativo respecto a cmo debe ejecutarse un determ


7/33


6

tipo de proceso y, en consecuencia, de cmo debe realizarse la gestin. Ahora, si

patrones son pblicos y muchas empresas pueden cooperar en su desarrollo y usufr

de ellos, se tiene un instrumento muy poderoso y estructurado para compconocimiento de gestin. Esto permitira que numerosas organizaciones median

pequeas pudieran mejorar sus procesos, sin tener que empezar desde cero, lo cual

obvias implicancias en cuanto a aumento de productividad. Esta idea la

implementando el autor por medio de publicar los patrones que ha desarrollado en s

webobarros.cl

2.2. Un patrn de proceso particular

Para ilustrar en ms detalle un proceso especfico y, en particular, cmo

especifica la lgica del negocio en forma genrica, presentamos algunas p

seleccionadas del patrn Macro1 [3]. Este patrn cubre el dominio de aplicacin

empresas que venden y satisfacen requerimientos de productos y/o servicios de cua

tipo. Para poder ser ms precisos -dada la generalidad de este patrn- especializa

Macro1 al dominio de empresas PYMES que venden productos o servicios fabrica

generados en sus propias instalaciones; por ejemplo, hemos tomado como

especficos, para definir esta especializacin, una elaboradora de quesos, una fbrica

una imprenta, una empresa de capacitacin que ofrece cursos y los ejecuta en

instalaciones, un hospital de una asociacin de seguridad que ofrece servicio

tratamiento de lesiones causadas por accidentes y varios otros con caractersticas sim


8/33


7

El primer nivel de detalle de Macro1 se muestra en la Figura 1. De este mo

detallamos la actividad Administracin relacin con el cliente en la Figura 2. De aqu

tomamos Decidir satisfaccin requerimientos para especificarla ms an. Esta incluye elconjunto de actividades que permiten decidir, en este caso, si satisfacer o no un pedid

productos o servicios realizado por un cliente particular. Aqu nos centramos

especificacin de la lgica de negocio que debe ejecutarse para tomar esta decisin

acuerdo al objetivo de los patrones y de este trabajo, intentamos sintetizar una l

genrica aplicable a muchas empresas dentro del dominio, a partir de las mejores pr

conocidas y la experiencia de varias empresas. Por tratarse de empresas PYME, tra

de que la lgica sea lo ms simple posible, pero suficiente para una buena dec

Adems, hacemos una serie de simplificaciones adicionales, en la lgica misma,

facilitar su entendimiento. Sin embargo, ella puede complementarse para incluir tod

aspectos no considerados.

De las mejores prcticas y la experiencia con este tipo de empresas, existen

aspectos de la lgica que son vlidos para todas las empresas de este dominio y qu

separables. El primero es la verificacin de la factibilidad de proveer el produ

servicio y el segundo, de la confiabilidad del cliente. La primera lgica es muy sim

incluye: verificacin de si existe disponibilidad o capacidad para proveer el produ

servicio; reserva de disponibilidad o capacidad en caso positivo; y generacin de a

solucin o alternativa en caso negativo.


9/33


8

Figura 1. Macro1


10/33


9

La lgica de evaluacin del cliente para darle el crdito normal de pago diferi

facturas (30 das o ms) o de otro tipo, es ms elaborada y ofrece mltiples posibilid

las cuales entregamos, a continuacin, en orden de complejidad:

Figura 2. Descomposicin de Administracin relacin con el cliente


11/33


10

a) Lgica primaria de clasificacin, la cual se basa en la idea de clasificar los cli

de acuerdo al comportamiento histrico de ventas o actividades realizadas

ellos. Suponiendo que los clientes son empresas, las variables de evaluacinVentas anuales efectuadas a una empresa; Impagos, que son las facturas a la

empresa declaradas incobrables; y Atrasos, el cual es un contador que establece

cuntas veces en la historia de la relacin con la empresa, sta se ha atrasado

pago de las facturas. Con estas variables se puede formalizar la lgica de la F

3 que asigna una empresa a una categora entre cinco. Obviamente, la lgica

simplificada: se podra jugar ms con las combinaciones de variables e intro

variables adicionales como DICOM.

Figura 3. Lgica de Clasificacin Primaria

//Calcular clasificacin primariaSi (Ventas anuales A y Impagos = 0)

Clasificacin primaria = 5

SinoSi (Ventas anuales B y Impagos = 0 y Atrasos = 0)Clasificacin primaria = 4 Sino

Si (ventas anuales C y Impagos = 0 y Atrasos = 0) Clasificacin primaria = 3

SinoSi ( Impagos = 0 y Atrasos > 0)

Clasificacin primaria = 2Sino

Clasificacin primaria = 1


12/33


11

b) Lgica secundaria de clasificacin, que tiene como fundamento evalua

solvencia financiera del cliente a partir de su balance. Esto puede hacerse

ndices estndares derivados del mismo, como el test cido de liquidez. Entola lgica de negocio consiste en asignar los clientes a varias categoras de acue

que los diferentes ndices o combinaciones de ellos cumplan con cie

condiciones, la cual no detallaremos aqu.

c) La lgica primaria de aprobacin de crdito por un producto o servicio se basa

clasificacin primaria y se bosqueja en la Figura 4.

d) La lgica secundaria de aprobacin sera similar a (c), pero basada e

clasificacin secundaria.

Evidentemente, se podran definir lgicas incrementales ternarias, cuaterna

etc., agregando nuevos niveles de complejidad a los previamente establecidos.

lgicas incrementales contienen opciones que un diseador de procesos podra utiliz

un caso particular; por ejemplo, podra elegir slo la lgica primaria o la prima

secundaria, etc., para, a partir de ellas, elaborar un rediseo especfico.

Figura 4. Lgica primaria de aprobacin crdito

//Lgica primaria de aprobacin crditoSi Clasificacin primaria = 5

Aprobacin crdito = s Sino

Si Clasificacin primaria = 4 3SiSaldo cuenta corriente + Monto pedido Lmite crdito Aprobacin crdito = s Sino Aprobacin crdito = no

SinoAprobacin crdito = no


13/33


12

Consideremos, ahora, la actividad del proceso Macro1 de Gestin produccin y

entrega, cuyo detalle se encuentra en la Figura 5. Concentrmonos en la activid

Planificacin y control produccin y veamos la lgica de negocio de ella. Para precisar,sigamos en el mismo dominio de PYMES que tienen actividades de fabricaci

productos o generacin de servicios que se satisfacen por medio de sus instalaci

Supongamos que hay una cierta rutina que no especificaremos- que gener

requerimientos por productos o servicios, que llamaremos, en general, Tareas, las c

deben ejecutarse de acuerdo a una cierta prioridad. Por ejemplo, pueden ser Orden

Trabajo (O/T), rdenes de tratamiento de pacientes, rdenes de ejecucin de curs

capacitacin, etc.

Las Tareas pueden ejecutarse en varios recursos opcionales, pero utilizan slo u

ellos; por ejemplo, lneas de envasado de bebidas, yoghurt, queso y otros prod

alimenticios, mquinas impresoras de distinta capacidad, equipos de rayos X, pabe

de operacin, salas de clases, etc.

La lgica primaria es, en este caso, simple y consiste en la programacin d

Tareas para satisfacer las siguientes condiciones:

i) Un Recurso programado con una Tarea debe tener la funcionalidad requerida por

ii) Un mdulo horario disponible de un Recurso debe asignarse a una sola Tarea.

iii) Las Tareas deben programarse en orden de prioridad; por defecto es FIFO.

iv) Tratar de maximizar el uso de Recursos en el tiempo.


14/33


13

v) Los Recursos deben usarse en forma equilibrada: todos deben tener una carga sim

Por supuesto, hay simplificaciones implcitas, como que el orden de las Tarea

importa, lo cual s es relevante en casos en que los tiempos de preparacin entre T

sean significativos y dependan del orden en que se ejecutan las mismas; por ejem

lneas de produccin que hay limpiar despus de fabricar un producto, donde el orde de

menos contaminante a ms contaminante- puede influir en los tiempos de lavado.

Figura 5. Detalle de Gestin produccin y entrega


15/33


14

Un segundo nivel incremental de complejidad para la lgica, en este caso l

secundaria, obva el problema anterior. Esto se puede hacer definiendo grupos de T

que deberan, dentro de lo posible, programarse en forma secuencial. Adicionalmendefine un factor de calidad de un Recurso para ejecutar una determinada Tarea; o

algunos Recursos son ms apropiados que otros. Por lo tanto, la lgica secun

reordenara las asignaciones de Tareas a Recursos, respetando los siguientes crit

adicionales a los de la lgica primaria:

i) Las Tareas correspondientes a un grupo deben dentro de lo posible- asignarse

secuencialmente en las lneas de tiempo de un Recurso.

ii) Los grupos deben asignarse al mejor Recurso disponible.

iii) Hay que respetar, dentro de cada grupo y a nivel global, las priorida

particularmente si stas estn relacionadas con fechas requeridas de trmino

Tarea.

Se puede definir un tercer nivel de complejidad para situaciones en las cu

participa ms de una lnea o mquina en el procesamiento de una Tarea, de manera s

a lo ya explicado, lo cual omitimos en este documento.

La idea de lgica incremental que hemos propuesto puede funcionar bien en mu

casos. De hecho existen precedentes de buenas heursticas que utilizan esta estrategi

ejemplo, en ruteo de vehculos para distribuir pedidos a mltiples ubicaciones,

propuesto asignar primero los pedidos a los vehculos y despus determinar las rut


16/33


15

stos (6). Sin embargo, en algunos casos, puede haber demasiada interrelacin entr

lgica primaria y otra secundaria, lo cual hace necesario refundirlas en una s

proveerla como otra lgica alternativa. En tal caso, un diseador tendra como opcuna lgica primaria, una primaria seguida de una secundaria o una alternativa que re

a las anteriores. La racionalidad que est detrs de estas opciones es que un dise

pueda elegir el nivel estrictamente necesario de complejidad de lgica para su

particular. El uso de esta idea se facilita con la tecnologa de orientacin a objetos, y

como lo veremos ms adelante, estas opciones se pueden empaquetar en componen

software de entre los cuales se puede seleccionar en forma eficiente.

Las lgicas presentadas para las dos actividades de Macro1 son, evidentem

parciales, y sirven slo para ilustrar el enfoque propuesto. En forma similar se po

completar tales lgicas y desarrollar lgica adicional para otras actividades de Ma

como gestin de stock bajo Administracin relacin con proveedores y gestin logstica

bajoDecidir entrega producto o servicio.

2.3. Aplicacin a un caso particular

Ilustramos cmo se aplica un patrn general como el del Punto 2.2, y

correspondiente lgica genrica, a un caso particular, considerando el caso de una f

que confecciona productos para stock y vende slo a empresas.

A nivel de representacin del proceso no hay cambio alguno; lo que se espec

es la lgica de negocio, de la siguiente manera:


17/33


16

a) La verificacin de la factibilidad de proveer los productos solicitados consis

determinar su disponibilidad en stock; reserva de stock en caso positivo y ofer

entrega parcial en caso parcialmente positivo; y verificacin de productofabricacin para ofrecer entrega futura.

b) La lgica primaria de clasificacin aplica sin cambio alguno.

c) La lgica secundaria de clasificacin podra obviarse en este caso, dado qu

empresas manufactureras PYME tienen pocas posibilidades de obtener los balanc

sus clientes.

d) La lgica de evaluacin de pedido aplica tambin sin cambio, restringindose al u

la lgica primaria.

e) La lgica primaria de programacin de las Tareas se convierte en la asignaci

Ordenes de Trabajo (O/T) que se generan para reposicin de stock- a lneas

produccin o mquinas, siendo los criterios de la misma directamente aplicable

este caso.

f) La lgica secundaria de programacin de Tareas no es aplicable, ya que e

fabricacin considerada no existen tiempos de preparacin significativos.

g) Una posible lgica de programacin terciaria sera relevante silas O/Ts requirieran un

procesamiento en ms de una mquina. Aqu la opcin simple es determinar el c

de botella de la fabricacin si es que existe- y aplicar (e) y (f) al mismo.


18/33


17

3. Componentes genricos para implementar lgica del negocio

3.1. Derivacin de un framework

A partir de las lgicas de negocios asociadas a los patrones desarrolladas en elPunto 2.2-, es posible definir en forma directa clases de objetos genricas o compo

que conforman un framework, el cual puede ser aplicado, como punto de partida, pa

desarrollar una solucin de software para apoyar un proceso particular. Los framework

que presentaremos se distinguen de los habitualmente descritos en la literatura [11] e

contienen lgica del negocio, en vez de lgica computacional conformando verdaderos

objetos del negocio (business objects ) ; son modelados utilizando UML especializado

aplicaciones que sern implementadas en una plataforma Internet [8], en la cual exist

lo menos, tres capas: un cliente con browser, un servidor de aplicaciones y un servid

datos [4]; y que permiten un uso opcional e incremental, idea no desarrollada hasta

en la literatura. Asimismo, aclaramos que el nfasis de los framework estar en la lgica, y

slo se incluirn los datos estrictamente necesarios. Una metodologa de cmo ge

modelos genricos ms orientados a los datos se da en [3].

El primer framework que desarrollamos es el correspondiente al apoyo a Decidir

satisfaccin requerimientos. A partir de la lgica definida en el Punto 2.2, se deduce e

framework que se presenta en la Figura 6. En ste hay clases tradicionales que manti

y manipulan datos y clases que manejan slo lgica. La idea detrs de esta separ

-habitual en aplicaciones en Internet [8] es que los datos van a residir en servidores d

datos y la lgica, en servidores de aplicaciones; adems tener la lgica aislada posibi

especializacin del framework a casos particulares, agregando lgica especial de st


19/33


18

Ello es facilitado por la divisin de la lgica en niveles de complejidad increm

primario, secundario, etc. , que pueden ser utilizados parcial o totalmente, de la man

que explicaremos ms adelante.

Las lgicas (mtodos) que contienen las clases respectivas son, evidentement

ya definidas en el Punto 2.2.

La manera en que estas clases colaboran para procesar pedidos en lnea d

clientes se muestra, por medio de un diagrama de secuencia UML, en la Figura 7,

nivel conceptual. Este requiere, obviamente, de una serie de detalles adicionales los que

se proveeran por especializacin- para ser realizable y ejecutable en un caso particul

De la misma manera, se puede desarrollar un framework para apoyo a la actividad

Planificacin y control de produccin de Macro1. De la lgica incremental presentada

en el Punto 3.2, se deduce el framework de la Figura 8. La idea que implementa est

framework es que una empresa podra elegir utilizar slo la parte central del mis

usando slo la lgica primaria y otros complementos particulares del caso,

especializacin. Esto llevara a una programacin de las Tareas en los Recursos.

Complementariamente o incrementalmente, otra empresa podra decidir us

framework completo con la lgica primaria y secundaria. En tal caso, sobre

programacin de la primera se ejecuta la agrupacin que produce la segu

reprogramando el comienzo de cada Tarea y cambiando el estado de cada Recurso.


20/33


19

Figura 6.Framework de lgica satisfaccin requerimientos

PEDIDO

-N pedido - Fecha - Aprobacin

producto - Aprobacin crdito - Monto pedido

// Ingresar pedido

LINEA PEDIDO

- Cantidad

// Crear lnea

PRODUCTO OSERVICIO APROBAR

// Lgica factibilidad de proveer producto o servicio

APROBAR CRDITOPRIMARIO

// Lgica primaria aprobacin crdito producto o servicio

CLASIFICACION PRIMARIA

// Calcular clasificacin primaria

EMPRESA CLIENTE CLASIFICACION SECUNDARIA - Indice financiero

balance - Clasificacin

secundaria

CLASIFICACION SECUNDARIA

// Calcular clasificacin secundaria

EMPRESA CLIENTE

- RUT - Nombre

//Crear empresa

*

*1

EMPRESA CLIENTE CLASIFICACION

PRIMARIA - Ventas anuales - Impagos - Atrasos - Clasificacin

primaria - Lmite crdito - Saldo cuenta

corriente

APROBAR CRDITOSECUNDARIO

// Lgica secundaria aprobacin crdito producto o servicio

1

1 0 .. *

N producto oservicio Disponibilidad

//Crear producto


21/33


20

Asimismo, alternativamente, se podra tener un componente adicional que refundi

lgica primaria y secundaria, para casos en que la separacin no produce bu

resultados.

Presentamos, a continuacin, una aplicacin diferente de las dadas anteriorm

para mostrar el uso del framework anterior y la versatilidad del enfoque.

Consideremos una empresa de capacitacin cuyas Tareas son Cursos que debe

programadas en los Recursos, que son Salas. La especializacin del framework de la

Figura 8 a este caso se muestra en la Figura 9, considerando que es relevante slo el

primario. Si hubiera que asignar, adems, profesores, se podra aplicar separadame

mismo framework para ello, con los cambios obvios. Pero, para la asignacin

profesores, podra haber la necesidad del uso de lgica secundaria de agrupacin, y

los cursos asignados a un profesor deberan ser, deseablemente, contiguos para -

contratados para hacer clases por horas- hacer ms eficiente el uso de su tiempo.

Es evidente que las lgicas incrementales que hemos propuesto, particularmen

el caso de la asignacin de Tareas, son una muy gruesa aproximacin a lo que ser

solucin rigurosa del problema de optimizacin subyacente. Sin embargo, la idea

es que en las PYMES se requieren, en muchos casos, soluciones factibles y que gara

condiciones mnimas, como orden en el uso de recursos y cumplimiento de plazos, l

-comparado con la ausencia absoluta de mecanismos formales de evaluacin de clie

asignacin de recursos que actualmente se da- puede significar beneficios considerab


22/33


process

process


23/33

* Pueden ser varias; relacin recursiva

TAREASECUNDARIA

- Tareasrelacionadas* (grupo)

- Funcionalidadpreferida

FUNCIONALIDADSECUNDARIA

- Calidadfuncionalidad

ASIGNAR TAREAPRIMARIA

//Lgica primaria

programacin

ASIGNAR TAREASECUNDARIA

//Lgica secundariaprogramacin(Agrupar)

TAREA

- Cdigo tarea- Tiempo ejecucin (enmdulos)- Funcionalidad requerida- Prioridad

FUNCIONALIDAD

- CdigoFuncionalidad

TAREAASIGNADA

- Cdigo asignacinhorario

- Mdulo horariocomienzo programado

RECURSO

- Cdigo recurso- Mdulo horario- Estado

0.. * requiere

1.. *

1.. * 0.. *

provee

0..* asi nada

1

1..*


24/33


23

Figura 8.Framework para programacin de Tareas

Por lo tanto, la ausencia de optimizacin que sera bastante ms cara de alcanzar- pued

que no signifique una prdida demasiado significativa de beneficios netos.

De manera parecida a lo explicado, se podran desarrollar lgicas del nego

framework para otras actividades del patrn Macro1, como Administracin relacin con

el proveedor, en particular gestin de stock de productos terminados y de materias

primas; y Decidir entrega producto o servicio, por ejemplo, para el armado de cargas

para vehculos y ruteo de la distribucin.

3.2. Uso de un framework

Como ya se ha bosquejado, un framework, como los descritos en el punto anterior

es el punto de partida para desarrollar una solucin de software de apoyo a un pro

Para que esto ocurra, el proceso tiene que haber sido rediseado a partir del patr

proceso que origin el framework, como se muestra en la Figura 10. Entonces, a partir

rediseo y el framework se genera una especializacin de este ltimo, la cual incluye

seleccin del nivel de lgica incremental con el cual se trabajar y la complementaci

mismo con lgica adicional y datos necesarios. A partir de este framework especializado y

el rediseo del proceso se puede, entonces, construir el software definitivo de apoyo

desarrollando una serie de elementos complementarios, como interfaces con los usu

integracin de datos utilizados en diferentes framework, programas para incluir lgica y

datos adicionales en el framework , programas que implementen la colaboracin ent


25/33


24

clases, de acuerdo a una especificacin como la presentada en la Figura 8, y otras

similares.

1

ASIGNAR CURSO

//Lgica primariaprogramacin cursos

CURSO

- Cdigo curso/seccin- Mdulos semanales- Prioridad

TIPO SALA

Cdigo tipo Tipo

CURSO ASIGNADO

- Cdigo mdulo curso- Horario mdulo curso

SALA

- Cdigo sala- Mdulo horario- Estado

requiere0.. *

1..*0.. *

1..*

0..*

provee

asignado

1

1..*


26/33


25

Figura 9. Aplicacin framework programacin Tareas a asignacin de cursos

El esquema presentado de generacin y utilizacin de un framework ha sido

validado a base de programar las lgicas de satisfaccin de requerimientos de la Figu

de asignacin de tareas de la Figura 8, para utilizarlas en la generacin de software

casos particulares(*). Para ello se us una base de datos relacional para implementar

clases que manejan datos, Java para programar las clases de lgica y JDBC para acc

datos desde la lgica.

La idea de uso incremental de la lgica de los framework se prob factible en la

prctica, al construir aplicaciones especficas tomando parte de las clases de un framework

y programando especializaciones y complementos a ellas para construir una sol

particular.

4. Consecuencias y extensiones

Este trabajo ha mostrado la factibilidad preliminar de un enfoque que per

desarrollar apoyos de software a un proceso rediseado, a partir de compon

preconstruidos. Estos estn centrados en la lgica del negocio y permiten su uso pa

flexible, a partir de las ideas de lgica incremental y lgica alternativa. Si bien

autores han propuesto ideas en la misma direccin de este documento para

verdaderos objetos del negocio [5, 7, 9 y 10], las publicaciones y oferta comercial ex

* El autor agradece el trabajo de Jaime Contesse en la realizacin de esta validacin.


27/33


26

de acuerdo al conocimiento del autor- no han logrado el grado de integracin en

diseo del negocio y los componentes genricos de software de apoyo aqu desarrolla

Figura 10. Diagrama de flujo para utilizacin de patrones y framework

PATRONES DEPROCESOSPARA UN CIERTO DOMINIO

LGICA DELNEGOCIO

GENRICA PARAACTIVIDADES DELPROCESO

F RAMEWORK PARA APOYO

A ACTIVIDADES DELPROCESO

CONSTRUCCIN DESOFTWARE A PARTIR DEL

FRAMEWORK

ESPECIALIZACIN DELFRAMEWORK AL CASO

PARTICULAR

ESPECIALIZACIN DELPATRN Y LGICAGENRICA PARA EL

REDISEO DE UN CASO


28/33


27

se han quedado en planteamientos generales que no son operacionalizables. Lodistingue nuestro enfoque y lo hace factible es su slido fundamento en pat

prediseados de procesos de negocios. Esta idea es nica y no ha sido propues

ninguno de los otros trabajos conocidos.

Creemos que el enfoque tiene un buen potencial para realizar rediseo de pro

y construir soluciones adaptadas de apoyo a los mismos en las empresas. Esto deb

que la existencia de patrones de procesos de negocios prediseados, adaptados a un

dominio y lgica de negocio con diversas opciones, hace factible que comunidad

empresas usuarias y desarrolladores de software se coordinen en la construcci

componentes genricos a partir de los framework - adaptables a situaciones particulares

Evidentemente, esto requiere un acuerdo dentro de un grupo de empresas, lo cual se

conseguir de varias maneras.

En el caso de una organizacin que incluye muchas instancias del mismo tip

negocio estructuradas por regiones, por ejemplo-, como el caso de cadenas comerc

holding de empresas productivas, sistemas hospitalarios pblicos y privados, ser

pblicos del estado y empresas financieras, la decisin de usar un enfoque com

propuesto es una poltica corporativa. De hecho, el autor ha estado trabajando c

grupo del sector telecomunicaciones y otro de empresas industriales en la implemen

del enfoque y est elaborando un proyecto para servicios pblicos.


29/33


28

Pero el autor ve mayor potencialidad y necesidad de un enfoque con el propues

las empresas PYMES, que, como ya se ha dicho, no tienen otra alternativa de caaceptable. Para stas el problema de acuerdo y coordinacin es ms difcil, pe

insuperable, ya que hay presiones competitivas que hacen necesaria una m

tecnologizacin y eficiencia de tales empresas. Adems, el Gobierno ha reconoc

problema y apoya varias iniciativas al respecto. Por lo tanto, aparece como factibl

empresas PYMES en sectores particulares -exportadores, por ejemplo- para aplic

enfoque como el propuesto.

Alternativamente a lo anterior, el autor est desarrollando una oferta de patr

para empresas PYMES que estarn pblicamente disponibles a travs de un sitio web

partir de la experiencia de muchas empresas de este tipo con las cuales se han rea

proyectos de rediseo de procesos. De aqu se derivar una primera generaci

framework y componentes preconstruidos que se ofrecer a tales empresas. Con st

harn aplicaciones en empresas especficas para mostrar la viabilidad del enfoque.

Es claro que lo que existe como posibilidad de resultar el enfoque en la prctic

para empresas PYMES- es la creacin de una industria original de software para

empresas, con buenas posibilidades de exportacin, ya que no hay una buena so

disponible a nivel internacional para ellas, particularmente si se consideran los aspec

mejora de procesos del negocio. Al respecto, la experiencia con el software chileno

generacin anterior para empresas PYMES es alentadora, ya que con una sol


30/33


29

absolutamente tradicional, los desarrolladores nacionales lograron un

posicionamiento a nivel latinoamericano.

REFERENCIAS

1. Barros, O. Reingeniera de Procesos de Negocios: Un Enfoque Metodolgico . Dolmen,2 edicin, 1995.

2. Barros, O. Patrones de Procesos de Gestin: Compartiendo Conocimiento paAumentar la Productividad. Documento de Trabajo N 10, CEGES, Depto. dIngeniera Industrial, U. de Chile, 1999.

3. Barros, O. Rediseo de Procesos de Negocios Mediante el Uso de Patrones ,Dolmen, 2000.

4. Barros, O. Arquitectura de Aplicaciones en e-Business. Documento de Trabajo N26, CEGES, Depto. de Ingeniera Industrial, U. de Chile, 2001.

5. Bohrer, K., V. Johnson, A. Nilsson y B. Rubin. Business Process Components fDistributed Object Applications.Communications of the ACM , Vol 41, N6, pp. 43-49, 1998.

6. Caldentey, E. DSLOG, Software de ruteo de camiones, Versin Beta 1.0, 2001.

7. Cline, M. y M. Girou. Enduring Business Themes.Communications of the ACM , Vol43. N 5, pp. 101-106, 2000.

8. Conallen, J. Modeling Web Application Architectures with UML.Communications of the ACM , Vol. 42, N 10, pp. 63-70, 1999.

9. Fan, M., J. Stallaert y A.B. Whinston. The Adoption and Design Methodologies of Component-Based Enterprise Systems. European Journal of Information Systems , N9,pp.25-35, 2000.

10. Fowler, M. Analysis Patterns: Reusable Object Models . Addison-Wesley, 1996.

11. Pree, W. Design Patterns for Object-Oriented Software Development . ACMPress Books/Addison-Wesley, 1994.


31/33


30

Centro de Gestin (CEGES)

Departamento de Ingeniera IndustrialUniversidad de Chile

Serie Gestin

Nota : Copias individuales pueden pedirse a Ana Mara Valenzuela, Av. Repblica 701, Santiago, ChiFono: +562/678 4045, Fax: +562/689 7895, email: [email protected]

Note : Working papers are available to be request with Ana Mara Valenzuela, Av. Repblica 70

Santiago, Chile, Phone: +562/678 4045, Fax: +562/689 7895, email: [email protected]

1996 1. Managing Supply and Demand in the Service Industries.

Gabriel R. Bitran y Susana V. Mondschein.

2. Zen en el Arte de Innovar : Hacia un nuevo Paradigma de la Innovacin Empresarial.Carlos Vignolo F.

19973. Characterizing and edge-colouring split-comparability graphs.Carmen Ortiz Z. Y Mnica Villanueva I.

4. Split-permutation graphs have threshold dimension at most two.Carmen Ortiz Z. y Mnica Villanueva I.

19985. Modelamiento Unificado de Negocios y Tecnologas de la Informacin: Ingeniera de Negocios

Oscar Barros.

6. Pricing Policies for a Family of Perishable Products with Demand Correlation.Hernn Awad, Gabriel Bitran y Susana Mondschein.

7. Nuevos paradigmas en Management: Una aproximacin desde la experiencia de modernizacinlos sistemas pblicos de salud en Chile.Carlos Vignolo F.

8. Globalizacin y Cambios de Paradigmas en Educacin y Desarrollo de Carrera.Carlos Vignolo F.
mailto:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]


32/33


31

19999. Patrones de Procesos de Gestin: Compartiendo Conocimiento para aumentar la ProductividadOscar Barros

10. On Optimal Constraint Management in Distributed Databases.Alexander Brodsky, Larry Kerschberg y Samuel Varas

11. Costo Social del Capital en Chile.Hctor Avils y Eduardo Contreras

12. Telecentros Comunitarios: una propuesta de desarrollo para zonas rurales.Eduardo Contreras, Daniel Hojman y Samuel Varas

13. Reemplazo de Equipos en un Sistema Productivo ComplejoMximo Bosch y Samuel Varas

200014. La Nueva Gestin de la Empresa Chilena.

Jos Alvarez M. y Jess Tovar M.

15. La Necesidad de una Ingeniera E-Business.Oscar Barros

16. Teora de Opciones: Una Sntesis.Viviana Fernndez

17. Patrn del ProcesoVenta y Distribucin de Stock.Oscar Barros

18. Forescating Home Appliances Sales: Incorporating Adoption and Replacement. Viviana Fernndez (Publicado enThe Journal of International Consumer Marketing , Vol. 12(2),1999, pages 39-61)

19. La Industria Farmacutica Chilena, las Estrategias de Negocios y la Regulacin del Sector.Enrique Jofr y Gerardo Daz

20. Repensando el Pensar: Hacia un Paradigma Chileno para el Desarrollo Chileno. Carlos Vignolo F.

21. Experiencias de Administracin por Categoras en Chile. Mximo Bosch, Cristian Espinoza, Andrs Musalem, Martn Vega y Cristian Paz

22. Conversando sobre Educacin.


33/33


Humberto Maturana y Carlos Vignolo

2001 23. Observable and Unobservable Determinants of Replacement of Home Appliances

(Por aparecer en Energy Economics )Viviana Fernndez

24. What Drives Replacement of Durable Goods at the Micro Level?Viviana Fernndez

25. Evaluacin de Inversiones Pblicas: Enfoques alternativos y su aplicabilidad para Chile.Eduardo Contreras

26. Arquitectura de Aplicaciones en un e-Business (Versin Preliminar)Oscar Barros

27. Diseo de la Arquitectura de un e-Business (Versin Preliminar)Oscar Barros V.

28. Diseo de los Componentes de un e-Business (Versin preliminar)Oscar Barros V.

29. Modelos de Negocios en Internet (Versin Preliminar)Oscar Barros V.

30. Sociotecnologa: Construccin de Capital Social para el Tercer MilenioCarlos Vignolo F.

31. Capital Social, Cultura Organizativa y Transversalidad en la Gestin PblicaKoldo Echebarria Ariznabarreta

32. Reforma del Estado, Modernizacin de la Gestin Pblica y Construccin de Capital Social:Caso Chileno (1994-2000)lvaro V. Ramrez Alujas

33. Volver a los 17: Los Desafos de la Gestin Poltica (Liderazgo, Capital Social y Creacin deValor Pblico: Conjeturas desde Chile)Sergio Spoerer H.

200234. Componentes de Lgica del Negocio Desarrollados a partir de Patrones de Procesos

Oscar Barros V.

comp logica 2

Documents