“DEFINICIÓN DE UNA GUÍA METODOLÓGICA PARA IDENTIFICAR ...
217
“DEFINICIÓN DE UNA GUÍA METODOLÓGICA PARA IDENTIFICAR SOLUCIONES BASADAS EN WEB SERVICES ” CASO DE ESTUDIO SECTOR EDUCACIÓN Hilda Cristina Chaparro López [email protected] Estudiante Francisco Rueda Asesor Universidad de Los Andes Departamento de Ingeniería de Sistemas Magíster en Ingeniería de Sistemas y Computación Julio 2003 Bogotá-Colombia
Transcript of “DEFINICIÓN DE UNA GUÍA METODOLÓGICA PARA IDENTIFICAR ...
“DEFINICIÓN DE UNA GUÍA METODOLÓGICA PARA IDENTIFICAR SOLUCIONES BASADAS EN WEB SERVICES ”
CASO DE ESTUDIO SECTOR EDUCACIÓN
Hilda Cristina Chaparro López [email protected]
Estudiante
Francisco Rueda Asesor
Universidad de Los Andes
Departamento de Ingeniería de Sistemas Magíster en Ingeniería de Sistemas y Computación
Julio 2003 Bogotá-Colombia
MISC-03-1-2
2
CONTENIDO
1 RESUMEN........................................................................................................5
2 OBJETIVOS......................................................................................................6
2.1 OBJETIVO GENERAL......................................................................................... 6
2.2 OBJETIVOS ESPECIFICOS................................................................................. 6
3 INTRODUCCION..............................................................................................7
4 MARCO TEORICO ...........................................................................................9
4.1 CADENA DE VALOR.......................................................................................... 9
4.1.1 GENERALIDADES ...................................................................................... 9
4.1.1.1 ¿QUE ES LA CADENA DE VALOR? ..................................................... 9
4.1.1.2 ANÁLISIS DE LA CADENA DE VALOR ............................................ 11
4.1.2 CADENAS DE VALOR EN LA NUEVA ECONOMÍA DIGITAL .......... 12
4.1.2.1 CADENA DE VALOR VIRTUAL ......................................................... 13
4.2 WEB SERVICES................................................................................................. 16
4.2.1 ¿Qué es un web service? .............................................................................. 17
4.2.2 ¿Qué es el UDDI? ....................................................................................... 18
4.2.3 Web Services Description Language (WSDL) ............................................ 19
4.2.3.1 Modelo de información del WSDL [7] .................................................... 20
4.2.4 Riesgos asociados al uso de Web Services .................................................. 21
5 GUIA METODOLOGICA PARA LA CONSTRUCCION DE CADENAS DE
VALOR GENERICAS.............................................................................................23
5.1 ETAPA 0: CONTEXTUALIZACIÓN ................................................................ 24
5.1.1 DEFINICIÓN DEL EQUIPO DE TRABAJO. ............................................ 25
5.1.2 VISIÓN ........................................................................................................ 26
5.1.3 FACTORES CRITICOS DE EXITO........................................................... 27
5.1.4 MISIÓN ....................................................................................................... 27
MISC-03-1-2
3
5.1.5 OBJETIVOS ESTRATÉGICOS.................................................................. 27
5.1.6 TASCOI ....................................................................................................... 27
5.2 ETAPA 1: SITUACIÓN ACTUAL DEL NEGOCIO - Definición de la Cadena
de valor interna y extendida actual.................................................................................. 28
5.2.1 IDENTIFICACIÓN DE LOS PROCESOS DEL NEGOCIO...................... 29
5.2.2 DEFINICIÓN DEL SISTEMA DE VALOR............................................. 30
5.2.3 DEFINICION DE LAS ACTIVIDADES DE LA ORGANIZACIÓN........ 31
5.2.3.1 ORGANIZACIÓN ORIENTADA A FUNCIONES ............................... 32
5.2.3.2 ORGANIZACIÓN ORIENTADA A PROCESOS.................................. 33
5.2.4 DEFINICIÓN DE LAS ACTIVIDADES PRIMARIAS ............................. 34
5.2.5 DEFINICIÓN DE LAS ACTIVIDADES DE SOPORTE........................... 35
5.2.6 DEFINICIÓN DE LA CADENA DE VALOR EXTENDIDA ................... 36
5.3 ETAPA 2: DEFINICIÓN DE LAS NECESIDADES INFORMÁTICAS........... 38
5.3.1 EVALUACIÓN Y PRIORIZACIÓN DE LAS NECESIDADES
INFORMÁTICAS........................................................................................................ 39
5.4 ETAPA 3: INCORPORACION DE TECNOLOGIAS DE INFORMACION
(WEB SERVICES & OTRAS) ........................................................................................ 41
5.4.1 SELECCIÓN DE LAS TECNOLOGÍAS DE INFORMACIÓN. ............... 42
5.5 TAPA 4: SELECCIÓN DE ESTRATEGIAS DE ADQUISICION, OPERACIÓN
Y MANTENIMIENTO DE LAS TECNOLOGIAS DE INFORMACION .................... 46
6 GUIA METODOLOGICA PARA LA IDENTIFICACION DE WEB SERVICES48
6.1 FASE I: Conocimiento del negocio ..................................................................... 49
6.2 FASE II: Identificar procesos............................................................................... 49
6.3 FASE III: Construir Cadena de Valor.................................................................. 50
6.4 FASE IV: Descubrir posibles Web Services en la cadena de valor.................... 50
6.5 Fase V: Negocios Innovadores haciendo uso de Web Services.......................... 53
6.6 FASE VI: Uso de Patrones de Negocio (B2B) .................................................... 53
Matriz No. 13. Tipo de transacción y seguridad de los Web Services............................. 62
6.7 Fase VII: Diseño, desarrollo e implantación de los Web Services ..................... 62
6.7.1 Retorno a la inversión (ROI) al usar Web Services ..................................... 63
MISC-03-1-2
4
7 VALIDACION DE LA GUIA METODOLOGICA – PRUEBA DE CONCEPTO.68
7.1 CASO DE ESTUDIO: CARRERA DE INGENIERIA DE SISTEMAS DE LA
PONTIFICIA UNIVERSIDAD JAVERIANA................................................................ 68
7.1.1 FASE I: Conocimiento del negocio ............................................................. 68
7.1.1.1 ETAPA 0: CONTEXTUALIZACIÓN .................................................... 69
7.1.2 FASE II: Identificar procesos – Ciclo de vida del negocio.......................... 71
7.1.2.1 ETAPA 1: SITUACIÓN ACTUAL DEL NEGOCIO ............................. 71
7.1.3 FASE III: Construcción de la Cadena de Valor ........................................... 75
7.1.3.1 DEFINICIÓN DE LAS ACTIVIDADES PRIMARIAS ......................... 75
7.1.3.2 DEFINICIÓN DE LAS ACTIVIDADES DE SOPORTE....................... 76
7.1.3.3 DEFINICIÓN DE LA CADENA DE VALOR EXTENDIDA ............... 76
Comentarios generales sobre la identificación de las cadenas de valor con base en
la guía metodológica................................................................................................ 79
7.1.3.4 ETAPA 2: DEFINICIÓN DE LAS NECESIDADES INFORMÁTICAS.
79
7.1.3.5 ETAPA 3: INCORPORACIÓN DE LAS TECNOLOGÍAS DE
INFORMACIÓN (WEB SERVICES & OTRAS)................................................... 80
7.1.3.6 ETAPA 4: SELECCIÓN DE LA ESTRATEGIA DE ADQUISICIÓN.. 81
7.1.4 FASE IV: Descubrir posibles Web Services en la cadena de valor............ 82
7.1.5 FASE V: Negocios Innovadores haciendo uso de Web Services ............... 85
7.1.6 FASE VI: Identificar Patrones de Negocio.................................................. 87
7.1.7 FASE VII: Diseño, desarrollo e implantación de los Web Services........... 90
7.1.7.1 Cálculo del ROI para el caso de estudio .................................................. 93
8 CONCLUSIONES ...........................................................................................98
9 BIBLIOGRAFIA.............................................................................................106
10 ANEXOS ...................................................................................................109
MISC-03-1-2
5
1 RESUMEN
Este documento presenta los resultados del proyecto de grado titulado: “Definición de una guía
metodológica para identificar soluciones basadas en Web Services” Caso de estudio Sector
Educación”.
El desarrollo del proyecto ha generado dos guías metodológicas que pueden ser utilizadas no sólo
para entidades educativas, sino para cualquier tipo de organización que requiera de ellas. Por una
parte, se ha definido una guía para la inclusión de Web Services como solución tecnológica para las
organizaciones (caso de estudio sector educativo), adicionalmente se ha generado una guía
metodológica para la identificación de cadenas de valor, que hace parte de la primera guía ya
mencionada.
Con base en estas dos guías metodológicas una organización puede generar todo un modelo
tecnológico, que parte del conocimiento propio del negocio, el establecimiento de sus necesidades y
las soluciones tecnológicas posibles a las mismas. Al finalizar el uso de la guía para la
identificación y potenciación de soluciones basadas en Web Services, el usuario cuenta con las
alternativas tecnológicas basadas en Web Services, para los procesos de negocio ya existentes, y por
otra parte, tendrá una visión de nuevas oportunidades de negocio usando esta tecnología.
La obtención del portafolio de aplicaciones que hará uso de los Web Services, será producto de dos
fuentes; por una parte se obtendrán los primeros insumos a partir de las cadena de valor del negocio
que se obtendrá haciendo uso de la guía metodológica para la identificación de cadenas de valor.
Una segunda fuente serán los patrones de negocio que permiten ver las alternativas de nuevos
negocios y el uso de Web Services para su construcción.
MISC-03-1-2
6
2 OBJETIVOS
2.1 OBJETIVO GENERAL
Definir una infraestructura (guía metodológica-guía de negocio) conceptual, que permita
identificar soluciones basadas en Web Services partiendo de un análisis del negocio. (caso de
estudio sector académico).
2.2 OBJETIVOS ESPECIFICOS
1. Construir una guía metodológica para identificar cadenas de valor de una empresa o unidad
de negocio. Se tomará como caso de estudio el Sector Educativo
2. Construir un “puente” entre la cadena de valor genérica y los procesos de la entidad, que
permita modelar el negocio y establecer los puntos neurálgicos que generarán ventaja
competitiva haciendo uso de tecnologías de información (Web Services)
3. Identificar los puntos de la cadena de valor dónde se pueda introducir tecnología
informática para apoyar y optimizar los procesos de la cadena.
4. Proponer usos innovadores para la tecnología de Web Services en el ámbito académico.
5. Identificar y explotar las oportunidades que tienen las empresas (caso de estudio el Sector
Educación) para usar el concepto de Web Services.
6. Validar el modelo conceptual definido
MISC-03-1-2
7
3 INTRODUCCION
Las empresas proveedoras de tecnología, hardware y software, tradicionalmente se han dedicado a
vender su producto como “cajas” que sólo comprenden ellos porque son en realidad cajas negras.
Por otra parte, muchos de estos proveedores se olvidan del negocio al momento de su venta, y dejan
de lado el componente de negocio, que es fundamental para comprender las necesidades de la
organización, sus requerimientos y su capacidad económica y de recurso humano para poner en
marcha proyectos de renovación tecnológica.
Los Web Services no son la única opción tecnológica para optimizar procesos ni la cadena de valor
de una organización o unidad de negocio, sin embargo, los estudios realizados por Gartner Group
nos muestran una fuerte tendencia a la integración de sistemas, utilizando para ello tecnologías
estándar que facilitan el proceso hacia adentro y fuera de la organización.
En la siguiente gráfica (figura 1), Gartner Group presenta las tendencias del mercado B2B, y de ella
se genera un interrogante; ¿son los Web Services la tecnología que permitirá la integración del
negocio hacia el año 2005?
MISC-03-1-2
8
1990-19961997 1998 1999 2000 2001 2002 2003 20082007200620052004
Se dispara la tecnología
Picos de grandes expectativas
Valles de las desilusiones.
Pendiente de Recuperación
Estabilidad y utilidad
Fin del e-business.E-business = commodity
Integración
Real-timeEnterprises
El verdadero e-business
emergeInternet
web
Fiebre.com
Punto máximode especulación
Inversionistas quebrados
TENDENCIA DEL MERCADOTENDENCIA DEL MERCADO
¿¿WEBWEB SERVICES?SERVICES?
Figura 1: Tendencias del mercado B2B [19 ]
Para el presente estudio, la tecnología a utilizar es Web Services, por lo cual se formulan una serie
de fases que facilitarán a las organizaciones, y en especial a las del sector educativo, identificar los
puntos de introducción de Web Services como herramienta generadora de ventaja competitiva y
valor.
MISC-03-1-2
9
4 MARCO TEORICO
4.1 CADENA DE VALOR
En 1985 Michael E. Porter de la Escuela de Negocios de Harvard, introdujo el concepto del análisis
de la cadena de valor en su libro Competitive Advantage. Al presentar sus ideas, Porter le dio
crédito al trabajo que Mckinsey & Co. había hecho al comienzo de la década del los 80’s sobre el
concepto de los "sistemas empresariales". Mckinsey consideraba que una empresa era una serie de
funciones (mercadeo, producción, recursos humanos, investigación y desarrollo, etc.) y que la
manera de entenderla era analizando el desempeño de cada una de esas funciones con relación a las
ejecutadas por la competencia. Con relación al trabajo de Mckinsey, la sugerencia de Porter fue que
había que ir más allá del análisis de un nivel funcional tan amplio y que era necesario descomponer
cada función en las actividades individuales que la constituían, como paso clave para distinguir
entre los diferentes tipos de actividades y sus relaciones entre si.
El punto de partida del concepto del análisis de la cadena de valor de Porter se encuentra en su
primer libro Competitive Strategy (Estrategia Competitiva) publicado en 1980, donde identificaba
dos fuentes separadas y fundamentales de ventaja competitiva: el liderazgo en costos bajos y la
diferenciación. Porter enfocó su nuevo concepto, argumentando que el liderazgo en costos bajos o
la diferenciación dependía de todas aquellas actividades discretas que desarrolla una empresa y que
separándolas en grupos estratégicamente relevantes la gerencia podría estar en capacidad de
comprender el comportamiento de los costos, así como también identificar fuentes existentes o
potenciales de diferenciación.
4.1.1 GENERALIDADES
4.1.1.1 ¿QUE ES LA CADENA DE VALOR?
MISC-03-1-2
10
Porter define el valor como “la suma de los beneficios percibidos que el cliente recibe menos los
costos percibidos por él al adquirir y usar un producto o servicio. La cadena de valor es
esencialmente una forma de análisis de la actividad empresarial mediante la cual descomponemos
una empresa en sus partes constitutivas, buscando identificar fuentes de ventaja competitiva en
aquellas actividades generadoras de valor. Esa ventaja competitiva se logra cuando la empresa
desarrolla e integra las actividades de su cadena de valor de forma menos costosa y mejor
diferenciada que sus rivales. Por consiguiente la cadena de valor de una empresa está conformada
por todas sus actividades generadoras de valor agregado y por los márgenes que éstas aportan” [3].
Por otra parte, el doctor en economía Daniel Iglesias, considera la cadena de valor como “la
colaboración estratégica de empresas con el propósito de satisfacer objetivos específicos de
mercado en el largo plazo, y lograr beneficios mutuos para todos los "eslabones" de la cadena. El
término cadena del valor se refiere a una red de alianzas verticales o estratégicas entre varias
empresas de negocios independientes dentro de una cadena de una industria en particular”[16].
Una cadena de valor genérica está constituida por tres elementos básicos[16], como podemos
observar en la Figura 2:
Figura 2. Elementos de la cadena de valor
• Actividades primarias: Son aquellas que tienen que ver con el desarrollo del producto, su
producción, las de logística y comercialización y los servicios de post-venta.
Infraestructura de la organizaciónGestión de Recursos Humanos
Desarrollo de la tecnologíaAprovisionamiento
Actividades Primarias
Actividades de Soporte
Log. Entrada Op. Fabrica Log. afuera Mercadeo Post-Venta
Infraestructura de la organizaciónGestión de Recursos Humanos
Desarrollo de la tecnologíaAprovisionamiento
Actividades Primarias
Actividades de Soporte
Log. Entrada Op. Fabrica Log. afuera Mercadeo Post-Venta Margen
MISC-03-1-2
11
• Actividades de soporte: Brindan soporte a las actividades primarias y corresponden a la
administración de los recursos humanos, las compras de bienes y servicios, el desarrollo
tecnológico (telecomunicaciones, automatización, desarrollo de procesos e ingeniería,
investigación), y las actividades de infraestructura empresarial (finanzas, contabilidad,
gerencia de la calidad, relaciones públicas, asesoría legal, gerencia general).
• Margen, que es la diferencia entre el valor total y los costos totales incurridos por la
empresa para desempeñar las actividades generadoras de valor.
4.1.1.2 ANÁLISIS DE LA CADENA DE VALOR
El análisis de la cadena de valor es una herramienta gerencial para identificar fuentes de ventaja
competitiva. El propósito de analizar la cadena de valor “es identificar aquellas actividades de la
empresa que pudieran aportarle una ventaja competitiva potencial. Poder aprovechar esas
oportunidades dependerá de la capacidad de la empresa para desarrollar a lo largo de la cadena de
valor y mejor que sus competidores, aquellas actividades competitivas cruciales” [16].
Porter resalta tres tipos diferentes de actividad:
• Actividades Directas: Son aquellas directamente comprometidas en la creación de valor
para el comprador. Son muy variadas, dependen del tipo de empresa y son por ejemplo las
operaciones de la fuerza de ventas, el diseño de productos, la publicidad, el ensamblaje de
piezas, entre otros.
• Actividades Indirectas: Son aquellas que le permiten funcionar de manera continua a las
actividades directas, como podrían ser el mantenimiento y la contabilidad.
• Aseguramiento de la calidad: En el desempeño de todas las actividades de la empresa.
Porter fue más allá del concepto de la cadena de valor, extendiéndolo al sistema de valor (o cadena
de valor extendida), el cual considera que “la empresa está inmersa en un conjunto complejo de
actividades-procesos ejecutadas por un gran número de actores diferentes. Este punto de vista nos
MISC-03-1-2
12
lleva a considerar al menos tres cadenas de valor adicionales a la que describimos como genérica”
[16]:
• Cadenas de valor de los proveedores: Crean y le aportan los abastecimientos esenciales a la
propia cadena de valor de la empresa. Los proveedores incurren en costos al producir y
despachar los suministros que requiere la cadena de valor de la empresa. El costo y la
calidad de esos suministros influyen en los costos de la empresa y/o en sus capacidades de
diferenciación.
• Cadenas de valor de los canales: Son los mecanismos de entrega de los productos de la
empresa al usuario final o al cliente. Los costos y los márgenes de los distribuidores son
parte del precio que paga el usuario final. Las actividades desarrolladas por los
distribuidores de los productos o servicios de la empresa afectan la satisfacción del usuario
final.
• Cadenas de valor de los compradores: Son la fuente de diferenciación por excelencia,
puesto que en ellas la función del producto determina las necesidades del cliente.
Dos de los aspectos más relevantes para los cuales es utilizado el concepto de cadena de valor son
los siguientes [16]:
• Análisis estratégico de costos
• Determinación de la base para Diferenciar
4.1.2 CADENAS DE VALOR EN LA NUEVA ECONOMÍA DIGITAL
"Las nuevas fuerzas de la digitalización, de la globalización y de la desregularización están
destruyendo las cadenas de valor de empresas de gran trayectoria. En industrias tan variadas como
la banca, los seguros y las empresas de servicios públicos, la ventaja competitiva está siendo
borrada por nuevos y a veces inesperados competidores, que usan como arma letal las aplicaciones
de la tecnología digital para alterar radicalmente la ecuación. Para responder efectivamente, las
MISC-03-1-2
13
empresas amenazadas deben hoy en día repensar totalmente sus cadenas de valor en vez de
optimizarlas"[9].
Es un hecho que muchas empresas, en forma premonitoria, están destruyendo sus cadenas de valor.
Reconocen que el cambio ya llegó y que hará obsoletas sus infraestructuras, que es el fin del viejo
modelo. Estas empresas están usando la tecnología digital para romper con las normas, implícitas o
explícitas, que decían cómo se compraban o se vendían los bienes y servicios. Están creando nuevas
formas de relacionarse con clientes y competidores mediante la inversión en costosos procesos de
automatización o facilitándoles sus propias herramientas digitales a sus clientes para que las usen,
evolucionando en una forma no usual en su industria.
4.1.2.1 CADENA DE VALOR VIRTUAL
“Cada negocio compite en dos mundos, un mundo de recursos físicos que los gerentes pueden
administrar y pueden observar y tocar, y un mundo virtual hecho de información. Este nuevo
mundo de información se conoce como el marketspace, para distinguirlo del mundo físico del
llamado marketplace[21].
Es importante que los gerentes centren su atención en cómo las compañías pueden crear valor en
ambos mundos, el físico y el virtual. Sin embargo el proceso de crear valor no es el mismo en
ambos mundos. Para entender las diferencias y la interrelación entre el proceso del valor agregado
del mundo físico y aquel del mundo de la información, los gerentes deben de ver más clara y
conjuntamente los asuntos estratégicos que enfrentan sus organizaciones.
“Administrar dos procesos interactivos de valor agregado en dos entornos dependientes, implica la
creación de nuevos conceptos y retos tácticos. Aquellos quienes entiendan cómo dominar a ambos
pueden crear y extraer valor de una manera más eficiente y efectiva” [1].
El modelo de cadena de valor, trata la información como un elemento adicional que apoya los
procesos de valor agregado, y no como una fuente de valor en sí misma. “Para crear el valor con
información, los gerentes deben buscar el marketplace. Si bien, la cadena de valor del mundo
virtual puede proyectar que en el lugar - compradores y vendedores puedan transferir fondos
MISC-03-1-2
14
mediante redes electrónicas exactamente como ellos pueden hacer comercializaciones en efectivo -
las compañías emplean sus procesos de valor agregado para cambiar la ruta de la información hacia
un nuevo mercado de servicios y productos únicos para el mundo de la información, en otras
palabras las etapas del valor agregado son virtuales y ellas están desarrolladas a través de
información”[1].
Crear valor en cualquier etapa de la cadena de valor virtual involucra una secuencia de cinco
actividades: Integrar, Organizar, Seleccionar, Sintetizar , Distribuir información
“Cada actividad es una etapa en la cadena de valor virtual que ocurre a través y con información y
se proyecta en las etapas del mundo físico”[1].
La lógica económica de las dos cadenas es diferente, una comprensión convencional de la economía
de escala y el enfoque, no aplica a la cadena de valor virtual del mismo modo que lo hace en la
cadena de valor física, sin embargo estas dos cadenas deben ser administradas de manera diferente
pero armónicamente.
Como lo sostienen Rayport y Sviokla, “las empresas que adoptan procesos de valor agregado lo
realizan en tres etapas:”[1]
• Visibilidad: Las organizaciones requieren una habilidad para ver sus operaciones físicas de
una manera más eficiente a través de la información. Se utilizan sistemas tecnológicos de
información a gran escala para coordinar actividades en las cadenas de valor físicas y los
procesos que guían la creación de una cadena de valor virtual.
• Proyección de la capacidad: Las organizaciones sustituyen algunas actividades virtuales por
otras físicas; comenzando a crear una cadena de valor paralela en el mercado. Finalmente
los negocios utilizan la información para establecer nuevas relaciones con los
consumidores. Surgen preguntas cómo “¿ Qué estamos haciendo ahora nosotros en el
espacio físico, y que podríamos hacer más eficiente o más efectivamente en el espacio
virtual? ¿Qué etapas del valor agregado actualmente desarrolladas en la cadena de valor
físico pueden ser proyectadas al mundo de la cadena de valor virtual?”[2]
MISC-03-1-2
15
• Matriz de valor: Diseño de un flujo de información en las cadenas de valor virtual para
entregar valor a los consumidores de una nueva manera. Se aplican las actividades
genéricas de valor agregado a la cadena de valor virtual, explotando lo que se conoce como
matriz de valor, a través de la cual se logran identificar más efectivamente los deseos de los
clientes y satisfacerlos más eficientemente.
“Las empresas deben hacer más que crear valor en el espacio, ellas deben sacar valor de él. Una
vez que las compañías llegan a ser expertas en la administración de sus actividades de valor
agregado de un lado a otro de las cadenas de valor paralelas, ellas están realmente desarrollando
estas nuevas relaciones”[1].
Ahora es claro que los gerentes de las diferentes organizaciones deben comprender las diferencias
entre creación y extracción de valor en el marketplace y en el marketspace; deben manejarse ambos
efectiva y armónicamente. Es necesario tener en cuenta premisas más actualizadas, debido a que
muchos de los antiguos axiomas de negocios ya no aplican en el marketspace. Rayport y Sviokla[1]
proponen cinco nuevos principios:
• Regla de los activos digitales: A diferencia de los físicos, los activos digitales no se agotan
al consumirse. Las compañías que crean valor con activos digitales pueden ser capaces de
volver a cosecharlos a través de un número infinito de transacciones potenciales. En verdad
esto cambia la dinámica competitiva de sus industrias.
• Nuevas economías de escala. La cadena de valor virtual redefine economías de escala
permitiendo que pequeñas compañías logren bajos costos unitarios por productos y
servicios en mercados dominados por empresas grandes.
• Nuevos alcances económicos. En el marketspace, los negocios pueden redefinir nuevos
alcances económicos por el diseño o simplemente por agrupar activos digitales que
proporcionan valores a través de muy diferentes y dispares mercados.
• Reducir costos de transacción. Los costos de transacción en la cadena de valor virtual son
más bajos que sus contrapartes en la cadena de valor físico, y ellos continúan declinando
bruscamente tal es el caso de la capacidad de procesamiento por unidad de costo de
microprocesos dobles cada 18 meses.
MISC-03-1-2
16
• Reequilibrar provisión y demanda. Tomando juntos estos cuatro axiomas combinados para
crear un quinto el mundo de los negocios aumenta el reclamo de un cambio de pensamiento
del lado del proveedor para colocarse del lado del demandante. Como las compañías
analizan, organizan, seleccionan, sintetizan, distribuyen información en el marketspace
mientras administran materias primas y manufacturan bienes en el marketplace, ellas tienen
la oportunidad de "sentir y responder" a los deseos de los consumidores de manera más
simple que manufacturar y vender productos y servicios.
“En el mundo actual es fundamental que los gerentes incrementen estrategias del lado de la
demanda. La alta administración debe valorar sus negocios - sus fortalezas y debilidades, sus
oportunidades y riesgos - a lo largo de las cadenas de valor de ambos mundos, el virtual y el físico.
Hoy, eventos en cualquiera de los dos pueden hacer que un negocio prospere o muera”[1].
4.2 WEB SERVICES
Los Web Services no representan un nuevo concepto, pero si una nueva aproximación para abordar
un viejo problema. Los investigadores en tecnologías de información han buscado la forma de hacer
que la gran cantidad de aplicaciones que existen en el mercado se hablen e intercambien
información haciendo uso de estándares de comunicación[12].
Actualmente, la era de la información y servicios propietarios y exclusivos de cada organización
está llegando a su fin, y estamos entrando en una era de servicios compartidos[13]. Las empresas
han visto la necesidad de dedicarse a sus negocios, hacer lo que saben hacer, y buscan alternativas
para aquellos procesos que otras compañías saben hacer mejor. En una corto plazo, las compañías
querrán adquirir sus tecnologías de información y sus servicios por Internet, más que adquirir su
propio Hardware y Software[18], esta es una gran oportunidad de negocio para quienes tengan
visión e inicien la construcción de este tipo de servicios compartidos, dando a los usuarios de los
mismos valor agregado y reconstrucción de su cadena de valor.
MISC-03-1-2
17
4.2.1 ¿Qué es un web service?
Un Web Service es un conjunto de aplicaciones que proporcionan datos y servicios a otras
aplicaciones, sin importar las plataformas en la que están soportadas ni el lenguaje en el cual están
implementadas [21]. En forma general podemos decir que son una colección de funciones
encapsuladas en una sola entidad y que se encuentran en la red de manera que puedan ser usados
por otros programas.
Según IDC [12], los Web Services son servicios máquina-máquina que se basan en tecnologías
sobre Internet. Se apoya en una arquitectura de comunicaciones entre el proveedor del servicio y el
cliente (browser) vía Internet usando XML y mensajes SOAP. Es un componente aplicativo
programable asequible vía protocolos estándares del Web [24].
Visto en forma amplia, un Web Service es una aplicación que se entrega como un servicio y que
puede ser integrada con otros Web Services usando los estándares de Internet. En otras palabras, es
una dirección URL que en forma programática (un llamado interno que funciona por reglas de
software sin necesidad de la intervención humana) retorna información y/o genera transacciones a
los clientes que quieren hacer uso de ella. Una de las características más importantes de los Web
Services, es que los clientes no necesitan conocer cómo se implementó el servicio [17].
Desde una perspectiva técnica, los Web Services no son más que una colección de una o más
operaciones relacionadas, que son accesibles sobre la red y que se describen por medio de una
descripción de servicio [6].
De acuerdo con Cannaby [8] los Web Services pueden hacer lo siguiente:
• Habilitan el desarrollo de aplicaciones parando la preocupación por la infraestructura de los
sistemas y permitiendo el enfoque en la escritura de aplicaciones cooperativas. Esta
característica la habilita el uso de XML para escribir las aplicaciones.
• Ayuda a reducir el desarrollo de las aplicaciones en tiempo y en costo: los desarrollos se
hacen usando módulos de aplicaciones ya existentes más que escribiendo nuevas
aplicaciones de servicio.
MISC-03-1-2
18
• Habilita a los programadores a incrementar dinámicamente los portafolios de aplicaciones.
No sólo crea módulos independientes, sino que crea módulos para construir aplicaciones
compuestas .
• Abre nuevas oportunidades de mercado para las empresas que ya tengan listas sus
aplicaciones. Hay aplicaciones que pueden ser vendidas como módulos Web Services, lo
que se puede convertir en una fuente de ganancia para la empresa.´
• Habilita a las empresas a responder más rápidamente a las condiciones cambiantes del
mercado o ante presiones competitivas.
• Ayuda a los clientes y usuarios de negocio a tener acceso a aplicaciones altamente
personalizadas, que pueden correr en múltiples dispositivos diferentes (PCs smart phones,
etc).
• Resuelve problemas de interoperabilidad de sistemas.
• Incrementa/Mejora la productividad organizacional e individual
4.2.2 ¿Qué es el UDDI?
UDDI (Universal Discovery Description Integration), el cual define el método para descubrir un
Web Service. Este estándar provee el directorio de servicios a los cuales se puede acceder, y que
han sido previamente registrados por los desarrolladores o proveedores del servicio [8].
UDDI es un registro público diseñado para almacenar de forma estructurada información sobre
empresas y los servicios que éstas ofrecen. A través de UDDI, se puede publicar y descubrir
información de una empresa y de sus servicios. Se pueden utilizar sistemas taxonómicos estándar
para clasificar estos datos y poder encontrarlos posteriormente en función de la categorización. Lo
más importante es que UDDI contiene información sobre las interfaces técnicas de los servicios de
una empresa. A través de un conjunto de llamadas a API XML basadas en SOAP, se puede
interactuar con UDDI tanto en tiempo de diseño como de ejecución para descubrir datos técnicos
de los servicios que permitan invocarlos y utilizarlos. De este modo, UDDI sirve como
infraestructura para una elección de software basado en servicios Web [8].
MISC-03-1-2
19
Los UDDI nacen como una necesidad de unificar la información de los servicios que estaban
apareciendo en la red y que ya no correspondían a simples transacciones electrónicas o páginas
Web. En otras palabras, se vio la necesidad de construir un Register o un DNS para estos nuevos
servicios.
Es un estándar creado por la UDDI.org, que unió la opinión de varios de los principales líderes de la
industria del software. El proyecto de estandarización busca incrementar la interoperabilidad y la
adopción de los Web Services. Estos estándares se basan en especificaciones para el servicio, la
descripción y el descubrimiento del mismo [17].
Los UDDI en resumen son registros de los Web Services que ayudan a encontrar el servicio y su
descripción (WSDL). Las búsquedas, como se explicará más adelante, se pueden hacer por negocio
y por tipo de servicio [17].
4.2.3 Web Services Description Language (WSDL)
WSDL (Web Service Description Language), que describe el servicio y como acceder al mismo.
El WSDL es un estándar propuesto para describir la sintaxis de invocación técnica de Web Services
fue desarrollado por el W3C como estandarización de IBM, Microsoft y otros en Septiembre de
2000 [8].
Una descripción de servicio WSDL es un documento XML, no es una descripción completa del
servicio, pero cubre los niveles bajos del services description stack, y es la descripción técnica pura
de la interfaz del servicio.
El WSDL es el IDL para los Web Services. En esencia un WSDL describe tres propiedades
fundamentales de un Web Services:
Qué hace el servicio – las operaciones (métodos) que el servicio provee.
Cómo se accede el servicio – detalles de los formatos de datos y los protocolos necesarios para
acceder a las operaciones del servicio.
Dónde está localizado el servicio – detalles del protocolo, direcciones de red específicas tales como
un URL.
MISC-03-1-2
20
4.2.3.1 Modelo de información del WSDL [7]
El modelo de información del WSDL toma ventaja de la separación entre las especificaciones
abstractas y las implementaciones concretas de estas especificaciones. Esto refleja la división entre
la definición de la interfaz del servicio (interfaz abstracta) y la definición de la implementación del
servicio (punto final concreto).
Una interfaz abstracta puede soportar un gran número de operaciones. Una operación es definida
por el conjunto de mensajes que definen sus patrones de interacción.
Como todas las buenas aplicaciones de XML el esquema WSDL define varios elementos de alto
nivel en el lenguaje:
• PortType: una definición de interfaz abstracta de Web Services donde cada elemento
operación-hijo define una forma del método abstracto.
• Message: define un conjunto de parámetros referenciados por el método u operación.
• Types: define una colección de todos los tipos de datos usados en el Web Service y que son
referenciados por varios elementos que son parte del mensaje (tipos de datos base).
• Binding: contiene los detalles de cómo los elementos en una interfaz abstracta (portType)
son convertidos en una representación concreta, en una combinación particular de formatos
de datos y protocolos (ejemplo: esquema de codificación de SOAP sobre http).
• Port: expresa como un enlace (binding) es desplegado en un punto final particular de la red
(lugar donde se especifica el http URL).
• Service: es un nombre o colección de nombres de puertos (ejemplo: los puertos asociados
con los pasos enana transacción de negocios multipasos). En otras palabras es una colección
de endpoints.
El tipo de puerto portType (con detalles del mensaje y el tipo de elementos) describe el que del Web
Services.
El elemento binding describe el como y los elementos port y service describen el donde del web
service.
MISC-03-1-2
21
4.2.4 Riesgos asociados al uso de Web Services
No se puede implantar esta nueva tecnología, ni ninguna otra sin tener un análisis de riesgos
concienzudo. Aquí se presentan algunos de los puntos críticos de implantar esta nueva tecnología,
estos aspectos deben ser tenidos en cuenta al momento de calcular el retorno a la inversión de un
proyecto que incluya Web Services.
Seguridad
Debido a la tecnología que es usada por los Web Services, y en concreto al uso de SOAP, las
técnicas de seguridad convencionales que se han venido usando en Internet, no son suficientes. Con
SOAP, cada mensaje simple que se intercambia realiza múltiples saltos y es enrutado a través de
numerosos puntos antes de que alcance su destino final. Es por ello que los Web Services necesitan
tecnologías que protejan los mensajes desde el principio hasta el final.
Sin embargo, existen un conjunto de técnicas que se pueden usar para garantizar la seguridad a nivel
de mensaje, sin tener que desistir de usar los Web Services como tecnología integradora.
Desde la perspectiva de XML se pueden utilizar técnicas como: Encripción, Firma Digital,
certificados XML Key Management Specification, por otra parte se cuenta con SAML (Security
Assertion Mark-up Language)
Además, también hay técnicas que permiten mantener la seguridad a otros niveles. La seguridad en
UDDI permite autentificar todas las entidades que toman parte en la publicación de un web service:
proveedor, agente y consumidor del servicio. De este modo, nadie podrá registrar servicios en el
papel de un proveedor o hacer uso de ellos sin contar con los permisos adecuados.
Calidad
Para que un web service se ejecute con corrección y satisfaga las expectativas creadas, aparte del
precio, habrá que tener en cuenta una serie de parámetros como por ejemplo, que los resultados
MISC-03-1-2
22
obtenidos del mismo sean los esperados o que el entorno de uso sea amigable. Otro elemento a tener
en cuenta es la integración. Aunque teóricamente los Web Services proporcionan conectividad con
cualquier software de un modo transparente, cada proveedor de servicios puede adoptar soluciones
diferentes que resultan más o menos adecuadas para el consumidor. Analizando la escalabilidad se
comprobará el grado de modularidad y flexibilidad del servicio.
Por último, también sería interesante analizar las características que ofrece el proveedor de Web
Services. Actualmente no hay definidos estándares sobre este tema, pero la mayoría de las empresas
ya está demandando algún tipo de acuerdo o contrato con los proveedores, de modo que se pueda
garantizar la calidad y la fiabilidad de los servicios por los que se paga.
Estandarización
Los Web Services están basados en el estándar XML, que ha sido universalmente aceptado. Pero la
situación para el resto de protocolos es bien distinta. La mayor parte de ellos se encuentran todavía
en desarrollo y pueden ser objeto de cambios. Esa es la razón por la que la mayoría de las empresas
están esperando a que estos protocolos sean más universales antes de profundizar en esta tecnología.
Actualmente, ni SOAP, ni WSDL, ni UDDI han sido oficialmente reconocidos por ningún
organismo de estandarización. SOAP es el único que en este momento está en consideración por el
World Wide Web Consortium y se encuentra cercano a la estandarización. SOAP y WSDL están
siendo ampliamente usados, pero de momento UDDI no ha tenido el mismo éxito. El principal
motivo es que las técnicas de seguridad son todavía muy inmaduras y las compañías prefieren hacer
uso de registros privados para dar soporte a intercambios privados de Web Services.
Para más información sobre los Web Services, sus componentes y características, se sugiere leer
la Nota Técnica Sobre Web Services [7], que se encuentra en el Anexo 0.
MISC-03-1-2
23
5 GUIA METODOLOGICA PARA LA CONSTRUCCION DE CADENAS DE VALOR
GENERICAS
Michael Porter ha dado los pasos mínimos para la construcción de una cadena de valor, por medio
de los cuales se llega a la obtención de las actividades primarias y de soporte, pero no se da una
guía de cómo obtenerla ni de cómo llegar desde el conocimiento de la organización a obtener la
cadena, entender sus procesos y optimizarla haciendo uso de tecnologías de información.
Esta guía no sólo da los mínimos necesarios para obtener la cadena, sino que ayuda en la
identificación de las necesidades de tecnologías de información y permite identificar qué tipo de
herramientas tecnológicas se adaptan más a las necesidades de la empresa. Se hace énfasis en el uso
de Web Services como herramienta de optimización, sin embargo, se muestra una amplia gama de
tecnologías que permiten mejoras en los procesos. Por último se entrega un esquema para medir y
validar que se ha logrado la generación de valor, por el uso de las tecnologías de información. Para
cada etapa se presentan objetivos y entregables de la misma.
Esta guía ha sido adaptada del documento de tesis de estudiantes de la Carrera de Ingeniería de
Sistemas de la Pontificia Universidad Javeriana, titulado: “Esquema de planeación estratégica de
sistemas de información, incorporando estrategias Business to Business en el sector financiero
colombiano”, elaborada por María Catalina Acero Rozo, Cesar Camilo Monsalvo, Jennifer
Rodriguez Rojas.
La figura 4 muestra las etapas en las cuales se divide la guía:
MISC-03-1-2
24
Figura 3: Etapas de la guía metodológica para la construcción de cadenas de valor genéricas
5.1 ETAPA 0: CONTEXTUALIZACIÓN
Figura 4. Etapa 0: Contextualización
MISC-03-1-2
25
Objetivo : Contextualizar el negocio e identificar la “razón de ser” del mismo.
Productos de la etapa:
Al finalizar la etapa se tendrá claro el negocio, su objeto social, y razón de ser.
En esta fase se inicia con la contextualización del negocio y la identificación de la “razón de ser”
del mismo. Esta etapa es la base para la elaboración de la cadena de valor del negocio.
Para dar inicio a esta fase es importante responderse las siguientes preguntas:
• ¿Para qué existe la organización (o en su defecto el área analizada)?
• ¿Cuál es su prioridad?
• ¿Cuál son sus procesos o labores principales?
• ¿Qué productos o servicios le presta la organización o el área analizada?
Para dar respuesta a estas preguntas se pueden utilizar diversos medios dentro de los cuales se
destacan: misión, visión, objetivos estratégicos de la organización, Factores Críticos de Éxito y
TASCOI.
Antes de dar inicio al proceso de contextualización como tal, es indispensable saber el equipo de
trabajo cómo estará conformado, en especial, cuál será el apoyo de la organización al proceso que
se inicia.
5.1.1 DEFINICIÓN DEL EQUIPO DE TRABAJO.
En este punto se definirán las personas que harán parte del equipo de trabajo, quienes tendrán la
responsabilidad de administrar, controlar y desarrollar el presente esquema. El equipo de trabajo
deberá estar liderado por la alta gerencia de la empresa, puesto que así el proceso de planeación
estratégica tendrá la importancia suficiente, para trascender e influir dentro de la organización. De
esta manera el proceso de planeación podrá contar con el apoyo de las diferentes áreas funcionales
de la organización, y no se verá como un trabajo aislado que se realiza en el área de sistemas.
MISC-03-1-2
26
El equipo de trabajo coordinará y realizará las actividades definidas durante el desarrollo del
esquema teniendo en cuenta los recursos humanos, físicos y tecnológicos necesarios para su
implementación.
Los pasos requeridos para establecer el equipo de trabajo se presentan a continuación:
1. Definir el líder del equipo: Este personaje “debe ser un funcionario con gran credibilidad dentro
de la organización”[10] , proactivo y dinámico, con capacidad de obtener el compromiso tanto de la
Gerencia como de todo el equipo de trabajo.
2. Seleccionar los integrantes del equipo: Estos participantes deben ser los representantes de cada
una de las áreas funcionales de la empresa. O en su defecto serán los responsables de los procesos
de la organización. Es importante tener un equipo multidisciplinario porque cada uno de ellos tiene
un conocimiento claro de las necesidades de su área, y entre todos dan como resultado la
organización como un todo.
Es importante definir dentro de estos participantes, además del líder, como mínimo los siguientes
roles:
• Administrador del Proyecto: Es la persona que reúne los recursos, establece prioridades, define
el plan de métricas, coordina las interacciones con usuarios y clientes, y generalmente mantiene al
equipo dirigido hacia la meta.
• Analista Financiero: Es quien se encarga de administrar y controlar los recursos financieros
asignados al proyecto.
5.1.2 VISIÓN
Es una descripción clara de cuál es el “deber ser”[20], para dónde va la organización. Cada uno de
estos aspectos debe estar acorde con los objetivos estratégicos definidos previamente en el PEC.
MISC-03-1-2
27
5.1.3 FACTORES CRITICOS DE EXITO
Si no se tiene un PEC explícitamente definido, es conveniente utilizar los Factores Claves para el
Éxito (FCE), estos factores son “aquellas pocas áreas que deben funcionar bien, para que la
organización marche bien”[11]. (Ver gráfica 1, Grafica de la Etapa0 con sus elementos).
5.1.4 MISIÓN
Señala cuál es el papel que desempeña la organización dentro de la sociedad o dentro de un sector
particular. Esta definición debe estar orientada a cumplir la visión. Para definir la misión se debe
responder a las siguientes preguntas:
• ¿Para que existe la Organización?
• ¿Cuál es su prioridad?
• ¿Cuál son sus funciones principales?
• ¿Cuáles son sus valores?¿A quién o quienes presta algún servicio?
5.1.5 OBJETIVOS ESTRATÉGICOS.
Los objetivos estratégicos constituyen el “vínculo entre la visión y la misión”[20]. Definen el
camino para llegar a la visión para lo cual es necesario tener en cuenta los Factores Claves de Éxito
definidos en el PEC. Estos objetivos deben cumplir con las siguientes características[10]:
• Medibles
• Sensibles a ser evaluados
• Relacionados con productividad, eficiencia, tecnología y talento humano
• Deben responder a la imagen corporativa
• Guiados a mejorar la calidad de los productos y/o servicios ofrecidos por la Organización .
5.1.6 TASCOI
TASCOI significa que una organización y sus actividades pueden ser definidas en términos de los
siguientes elementos:
MISC-03-1-2
28
Transformación (Transformation): Entrada-Salida
Actores (Actors): que producen la transformación
Proveedores(Supplier): Quienes proveen la entrada
Cliente (Customer): los clientes
Propietario(Owner): Los que poseen la visión de la organización
Interventor (Interveners): Son los entes reguladores provistos por el contexto.
Con lo anterior se logra la definición de la IDENTIDAD de la organización.
No es indispensable hacer uso de las cinco herramientas aquí descritas. Las combinaciones
recomendables son:
• Misión – Visión: entrega una vista completa de la organización desde la perspectiva de sus
creadores y de los directivos de la misma.
• Factores Críticos de Éxito: Muestran a la organización desde sus áreas funcionales, y permiten
la medición del éxito de la misma desde un conjunto de Indicadores Críticos de Éxito. Son una
buena herramienta cuando en la organización no se cuenta con un PEC definido.
• Objetivos Estratégicos: cómo vínculo entre la misión y la visión, ofrecen una perspectiva de la
organización y su razón de ser, sin embargo es necesario contar con los dos elementos para
establecer el vínculo.
5.2 ETAPA 1: SITUACIÓN ACTUAL DEL NEGOCIO - Definición de la Cadena de valor
interna y extendida actual
Figura 5. Etapa 1: Situación Actual del Negocio
MISC-03-1-2
29
Objetivo: Esta etapa tiene como objetivo identificar la situación actual del negocio desde su “razón
de ser” que se puede obtener mediante el TASCOI de la organización, el cual permite identificar la
identidad de la misma.
Por otra parte, se identifican los procesos y/o actividades (dependiendo de la orientación a procesos
o funciones de la organización) y si es necesario, como se verá más adelante, Factores Críticos de
Éxito FCE.
Se define como parte de la situación actual el sistema de valor del negocio, con el fin de identificar
la cadena de valor extendida (proveedores, clientes, aliados de negocio).
Productos de la etapa:
• Identificación de Procesos del negocio
• Identificación de las actividades del negocio
• Definición de la cadena de valor actual de la organización
• Definición del sistema de valor de la organización
• Definición de las necesidades informáticas de la organización
¡IMPORTANTE! En esta definición de procesos y actividades del negocio se está suponiendo
que la organización está orientada a funciones, por lo cual hacer la distinción entre actividades y
procesos es factible, ya que se deduce que las actividades apoyan la ejecución de los procesos o
forman parte de los mismos.
En el caso en que la organización esté orientada a procesos, que se considera como el estado ideal,
el tratamiento es diferente.
5.2.1 IDENTIFICACIÓN DE LOS PROCESOS1 DEL NEGOCIO
Una vez se ha comprendido la “razón de ser” del negocio, se hace la definición de los procesos que
realiza la organización para cumplir con su misión y visión o para lograr la transformación.
1 Un proceso es una cadena de actividades acopladas, dirigidas a producir una salida en particular. Un proceso está constituido por fases consecutivas en la elaboración de un producto.
MISC-03-1-2
30
Estos procesos pueden ser levantados y documentados por medio de metodologías tradicionales de
Ingeniería de Software, o simplemente documentando en detalle las entradas y salidas del proceso y
los actores que participan con la descripción de su función dentro de este proceso.
El esquema recomendado para la presentación de la información de los procesos es el siguiente:
(P#) <NOMBRE DEL PROCESO> OBJETIVO DEL PROCESO Breve descripción de lo que el proceso realiza para la organización. ALCANCE DEL PROCESO ¿Cuál es el alcance o impacto de este proceso? ACTORES ¿Quiénes son los actores del proceso? PRECONDICIÓN ¿Qué debe estar predefinido o listo para que el proceso funcione? POSTCONDICIÓN ¿Qué ocurre una vez el proceso culmina? DESCRIPCIÓN Listado enumerado de los pasos que se siguen para ejecutar el proceso.
De acuerdo con lo anterior, los procesos se componen de :
Límites del proceso: Identificación del punto de inicio y terminal del proceso. Dónde inicia – dónde
termina.
Rango del proceso: La sumatoria de los subprocesos que lo integran, subprocesos de un proceso.
Profundidad del proceso: Nivel de detalle en que se desagregan las actividades.
En conclusión, los procesos son un conjunto de actividades que en su interacción generan valor en
el cliente.
5.2.2 DEFINICIÓN DEL SISTEMA DE VALOR.
Inicialmente deben detectarse las actividades que la organización realiza normalmente, tanto a nivel
interno como externo. Para facilitar esta labor es recomendable resolver las siguientes preguntas:
¿Cual es el core del negocio? (definido en la fase de contextualización)
MISC-03-1-2
31
¿Cuáles son las actividades que generan los mayores ingresos a la empresa?
¿Qué infraestructura se está utilizando para desempeñar las actividades que generan los mayores
ingresos a la compañía?
¿Cuáles son las personas responsables de realizar estas actividades?
5.2.3 DEFINICION DE LAS ACTIVIDADES DE LA ORGANIZACIÓN
Luego de haber resuelto estas preguntas se debe proceder a analizar por cada área de la
organización, cuáles son las actividades que se desempeñan en el interior de éstas. Para organizar y
detectar cuáles son las actividades que desempeña la organización, se debe desarrollar la siguiente
matriz –Definición de las actividades2 de la organización-.
Objetivo: describir cuáles son las actividades que desarrollan cada una de las áreas de la
organización.
Columnas:
• -Área- en esta columna se deben colocar las distintas áreas que comprenden la
organización.
• -No- a cada una de las actividades se les debe asignar un número iniciando en 1 para
poderlas identificar.
• -Actividad- para cada una de las áreas se deben describir cuáles son las actividades que
desempeñan en su interior.
• -Frecuencia- en esta columna se debe describir cuál es la periodicidad con la cual se ejecuta
cada una de las actividades. Para esto se debe tener en cuenta los siguientes aspectos.
o Si la frecuencia es diaria se debe colocar una (X) en la columna –diaria-
o Si la actividad no tiene una frecuencia definida se debe colocar una (X) en la
columna –SF- (sin frecuencia)
o En el caso que exista una actividad con una frecuencia definida, pero que no sea
diaria, se debe marcar una (X) en la columna –otra-.
2 Actividades: es el conjunto de tareas o de operaciones propias de una persona o entidad.
MISC-03-1-2
32
DEFINICIÓN DE LAS ACTIVIDADES DE LA ORGANIZACIÓN
FRECUENCIA AREA No ACTIVIDAD DIARIA SF OTRA A1
....
An AREA 1
… A1 … AREA n An
Matriz No. 1 Definición de las actividades de la organización
5.2.3.1 ORGANIZACIÓN ORIENTADA A FUNCIONES
Objetivo: establecer el impacto de las actividades de la empresa sobre los procesos desarrollados
por la misma.
Columnas:
• Procesos desarrollados por la organización
Filas:
• Actividades desarrolladas por la organización
A cada una de las actividades, se les debe dar un valor de impacto sobre cada uno de los procesos de
la organización. Este valor que se le va a dar al impacto deberá ser calificado de la siguiente forma:
0: Impacto nulo
1: Impacto bajo
3: Impacto medio
5: Impacto alto
IMPACTO DE LAS ACTIVIDADES SOBRE LOS PROCESOS
PROCESOS
ACTIVIDADES
P1 P2 … Pm Sumatoria por actividad
A1 A2
…
An Sumatoria por proceso
Matriz No. 2 Calificación del Impacto generado sobre los procesos por parte de las actividades
MISC-03-1-2
33
5.2.3.2 ORGANIZACIÓN ORIENTADA A PROCESOS
Objetivo: establecer el impacto de los procesos de la empresa sobre los componentes de la misión,
o sobre los objetivos estratégicos. En su defecto, si la organización no tiene una misión establecida,
se extraen los componentes o factores más importantes del TASCOI de la organización.
Columnas:
• Componentes de la misión, objetivos estratégicos o componentes del TASCOI
Filas:
• Procesos desarrollados por la organización
A cada una de las actividades, se les debe dar un valor de impacto sobre cada uno de los
“componentes” de la organización. Este valor que se le va a dar al impacto deberá ser calificado de
la siguiente forma:
0: Impacto nulo
1: Impacto bajo
3: Impacto medio
5: Impacto alto
IMPACTO DE LAS ACTIVIDADES SOBRE LOS COMPONENTES DE LA MISIÓN O LOS OBJETIVOS ESTRATÉGICOS
COMPONENTES MISION
PROCESOS
Cmp 1 Cmp 2 … Cmp m Sumatoria por Procesos
P1
P2
…
Pn
Sumatoria por Componente
Matriz No.3 Impacto de las actividades sobre los componentes de la misión
MISC-03-1-2
34
5.2.4 DEFINICIÓN DE LAS ACTIVIDADES PRIMARIAS
Para seleccionar cuáles son las actividades primarias que están presentes en la organización, se
deben tener en cuenta los siguientes aspectos:
• Todas las actividades que se vayan a seleccionar como primarias deben ser parte del core
del negocio.
• Todas las actividades seleccionadas deberán haber obtenido un valor superior a:
((Valor Impacto Alto * número de componentes m) +1) / 2
Para realizar la clasificación de las actividades primarias con respecto a la función que desempeñe
dentro de la organización se debe utilizar la matriz –Clasificación de las actividades primarias-.
Objetivo: especificar cuál es la función que desempeña cada actividad primaria dentro de la
organización
Columnas.
• -No- en esta columna se colocará el número asignado a cada actividad primaria que va a
estar compuesto de la siguiente manera: APn, donde n es un valor que inicia en 1. Este
número será el que se va a utilizar de aquí en adelante para referirse a cada una de las
actividades primarias.
• -Actividad- en esta columna se describen brevemente cuáles son las actividades que se han
considerado primarias para la organización.
Las columnas –logística de entrada- , -operación-, -logística de salida-, -mercadeo- y –postventa-,
son las diferentes funciones que pueden desempeñar en la organización cada una de las actividades
primarias.
Para asegurar que la matriz quedó bien desarrollada, debe existir por lo menos una (X) en cada una
de las diferentes funciones que pueden desempeñar las actividades primarias. En caso de existir
alguna actividad que no pueda ser clasificada dentro de estas opciones, entonces debe ser transferida
a la matriz –clasificación de las actividades de soporte-.
MISC-03-1-2
35
CLASIFICACIÓN DE LAS ACTIVIDADES PRIMARIAS
No ACTIVIDAD
LOGÍSTICA
DE ENTRADA OPERACIÓN
LOGÍSTICA
DE SALIDA MERCADEO
POST
VENTA
A1
A2
...
An
Matriz No. 4 Clasificación de las actividades primarias
5.2.5 DEFINICIÓN DE LAS ACTIVIDADES DE SOPORTE
Para seleccionar cuáles son las actividades de soporte que están presentes en la organización, se
deben tener en cuenta los siguientes aspectos:
• Todas las actividades que se vayan a seleccionar como soporte, deben ser parte de las
actividades que le brindan apoyo a la organización, pero no son parte del core del negocio.
• Todas las actividades seleccionadas deberán haber obtenido una calificación inferior a:
((Valor Impacto Alto * número de componentes m) +1) / 2
Para realizar la clasificación de las actividades de soporte con respecto a la función que desempeñan
dentro de la organización, se debe utilizar la matriz –Clasificación de las actividades de soporte-.
Objetivo: especificar cuál es la función que desempeña cada actividad de soporte dentro de la
organización.
Columnas.
• -No- en esta columna se colocara el número asignado a cada actividad de soporte que va a
estar compuesto de la siguiente manera: ASn, donde n es un valor que inicia en 1. Este
número será el que se va a utilizar de aquí en adelante para referirse a cada una de las
actividades de soporte.
• -Actividad- en esta columna se describen brevemente cuáles son las actividades que se han
considerado de soporte para la organización.
Las columnas –infraestructura-, -recursos humanos-, -tecnologías-, y –abastecimiento- son las
diferentes funciones que pueden desempeñar en la organización cada una de las actividades de
soporte.
MISC-03-1-2
36
Para asegurar que la matriz quedó bien desarrollada, debe existir por lo menos una (X) en cada una
de las diferentes funciones que pueden desempeñar las actividades de soporte. En caso de existir
alguna actividad que no pueda ser clasificada dentro de estas opciones, entonces debe ser transferida
a la matriz –clasificación de las actividades primarias-.
CLASIFICACIÓN DE LAS ACTIVIDADES DE SOPORTE
No ACTIVIDAD INFRAESTRUCTURA RECURSOS HUMANOS TECNOLOGÍAS ABASTECIMIENTO
A1 A2 ... An
Matriz No. 5 Definición de las actividades de soporte
5.2.6 DEFINICIÓN DE LA CADENA DE VALOR EXTENDIDA
La cadena de valor extendida (externa) está compuesta por la cadena de valor de los compradores,
proveedores y canales, es decir los actores de las diferentes relaciones de negocio que se pueden dar
dentro de la unidad u organización que se esté analizando.
Objetivo: Permite detectar fácilmente cuales son los principales componentes de la cadena de valor
extendida.
Columnas:
• -No. Relación- Consecutivo que identifica los servicios
• -Relación con- Se describe la relación que tiene la organización con otras empresas, clientes
o proveedores (actores externos). Estas relaciones están conformadas por uno o más
servicios. Cuál es el cliente o proveedor con la cual la organización posee una relación de
negocios. En este espacio se coloca el nombre del actor con el cual se relaciona la unidad o
el negocio analizado.
• -No- Consecutivo que identifica los servicios. Con un mismo actor se pueden tener
diferentes servicios involucrados.
• –Descripción- Se debe colocar muy brevemente cuáles son las actividades que ofrece la
organización para interactuar con la cadena de valor externa, los cuales se consideraran
servicios de la compañía con el objetivo de diferenciarlos con las actividades primarias o de
soporte.
• –Producto / Servicio ofrecido- Cuáles son los productos o servicios que la empresa brinda a
un determinado cliente o socio comercial.
MISC-03-1-2
37
• –Producto / Servicio recibido- Cuáles son los productos o servicios que se obtienen o
utilizan de un determinado proveedor o socio comercial.
• –Cada cuánto- Frecuencia con la cual se realiza un intercambio comercial. Es recomendable
establecer una medida estándar para manejar la frecuencia de este tipo de actividades, es
decir, todas las frecuencias se van a escribir en términos de meses, semanas o días.
• –Tipo de relación- Se especifica si es una relación del tipo B2B, B2C ó B2G3. No
necesariamente esta relación implica uso de tecnologías de información.
• –Cómo- Descripción del proceso y los actores internos de la organización que desempeñan
dicha actividad.
• –Impacto estratégico- Corresponde a un valor de uno (bajo) a diez(alto), dependiendo la
importancia que esa actividad tenga sobre el core del negocio, es decir, sobre las actividades
primarias de la organización o unidad de negocio.
DEFINICIÓN DE LA CADENA DE VALOR EXTENDIDA
No.
RE
LA
CIÓ
N
RE
LA
CIÓ
N C
ON
No
DE
SCR
IPC
IÓN
PRO
DU
CT
O/
SER
VIC
IO
OFR
EC
IDO
PRO
DU
CT
O/
SER
VIC
IO R
EC
IBID
O
CA
DA
CU
ÁN
TO
TIP
O D
E R
EL
AC
IÓN
CÓ
MO
IMPA
CT
O
EST
RA
TÉ
GIC
O
R1
S11 S12 S13 .. S1N
S21
S22
R2 S24
…
S2M
Matriz No. 6 Definición de la cadena de valor externa.
De las Etapas 0 y 1 se han obtenido los elementos tradicionales de la cadena de valor de una
organización o unidad de negocio, se han obtenido las actividades primarias y de soporte, pero 3 B2B (Business to Business) , B2C (Business to Consumer), B2G (Business to Goverment) son los tipos de relaciones más comunes que se encuentran en el ambiente de negocios electrónicos que interesa en este trabajo.
MISC-03-1-2
38
partiendo de las funciones o de los proceso de las organización. Vale la pena tener en cuenta que
haciendo uso de esta guía se pueden eliminar las actividades o procesos redundantes o innecesarios,
esto ocurrirá en el momento en que no sea posible ubicar estos procesos o actividades en las
matrices de clasificación de actividades primarias, o actividades de soporte.
Una vez obtenidas los dos tipos de actividades, es necesario ver las relaciones que tiene la cadena
de valor interna con los aliados de negocio, clientes y proveedores de la organización, es por ello
que se verifican las relaciones con estos actores para generar así la cadena de valor extendida. Otro
de los beneficios de hallar estas relaciones se verán más adelante al hacer uso de esta matriz en el
proceso de identificación de Web Services.
5.3 ETAPA 2: DEFINICIÓN DE LAS NECESIDADES INFORMÁTICAS.
Tener la cadena de valor interna y extendida de una organización o unidad de negocio es una
herramienta para ver la situación actual del negocio. Hasta este momento no se ha incluido
tecnología en la construcción de esta cadena, tampoco se ha derivado ninguna necesidad de
sistematización de procesos. En la Etapa 2, se definirán las necesidades informáticas partiendo de la
cadena de valor.
Figura 6. Etapa 2: Definición de las necesidades informáticas
MISC-03-1-2
39
5.3.1 EVALUACIÓN Y PRIORIZACIÓN DE LAS NECESIDADES INFORMÁTICAS.
Para realizar la evaluación y la priorización de las necesidades informáticas se debe desarrollar la
siguiente matriz de Evaluación y priorización de las necesidades informáticas.
Objetivo: Describir cada una de las necesidades informáticas, o de manejo de información, con
base en el análisis de la cadena de valor desarrollado en la etapa anterior y de las relaciones con
cadenas externas o cadena de valor extendida.
Columnas:
• –No- Número consecutivo para identificar cada una de las necesidades.
• –Origen de la necesidad- Se describen las actividades primarias, secundarias o servicios
(cadena de valor extendida) que motivaron la necesidad informática de acuerdo con las
matrices 4 y 5.
• –Descripción de la necesidad- Se describe brevemente cuál es la necesidad que existe sobre
una actividad primaria, de soporte o sobre el servicio.
• –Impacto estratégico- Qué tanto afecta la solución a esa necesidad la cadena de valor ya
definida?.
• –Área generadora- Cuál es la división o departamento dentro de la organización que generó
la necesidad.
• -Priorización- Esta columna se debe desarrollar después de haber llenado todas las otras
columnas de la matriz. A cada necesidad se le debe asignar un número que representa la
importancia de desarrollarla. Este número va a iniciar en 1 siendo este valor el que
representa la mayor importancia. Esta importancia está dada por la urgencia o relevancia
que tenga la solución a esa necesidad, para las personas que dirigen la organización.
MISC-03-1-2
40
EVALUACIÓN Y PRIORIZACION DE LAS NECESIDADES INFORMÁTICAS
IMPACTO ESTRATÉGICO No ORIGEN DE LA
NECESIDAD DESCRIPCIÓN DE
LA NECESIDAD ALTO MEDIO BAJO
ÁREA GENERADORA PRIORIZACIÓN
ACTIVIDADES
PRIMARIAS
N1 AP1
N2 …
.. APn
ACTIVIDADES SECUDARIAS
AS1
ASn
SERVICIOS
S1
… Sn
OTRAS
O1 …
Nn On Matriz No.7 Evaluación y priorización de las necesidades informáticas.
Una vez identificadas las necesidades informáticas es necesario determinar cuáles pueden ser las
opciones tecnológicas para cubrir dicha necesidad. La siguiente etapa plantea un abanico de
posibilidades, que aunque no son todas, ilustran la forma en que se pueden cubrir algunas
necesidades informáticas.
MISC-03-1-2
41
5.4 ETAPA 3: INCORPORACION DE TECNOLOGIAS DE INFORMACION (WEB
SERVICES & OTRAS)
Figura 7: Incorporación de tecnologías de información
Ahora debemos definir las tecnologías de información que satisfacen las necesidades informáticas
de la organización o unidad de negocio. Para este ejemplo tenemos:
Objetivo: En esta etapa se pretende detectar cuáles son las TI más adecuadas para dar solución a
las necesidades informáticas. Teniendo en cuenta las características y fortalezas de cada una de
estas tecnologías se determinarán cuáles de estas satisfacen los requerimientos de cada una de las
necesidades. Para las tecnologías elegidas se evaluará el impacto, se determinará la viabilidad de la
misma considerando el costo, tiempo, esfuerzo entre otros y por último se darán algunos
lineamientos que se deben considerar en el momento de la implementación
Productos de la etapa:
• Selección de TI.
• Viabilidad de TI.
MISC-03-1-2
42
.
5.4.1 SELECCIÓN DE LAS TECNOLOGÍAS DE INFORMACIÓN.
Deloitte & Touche, experta en consultoría de negocios y tecnología, aconseja a las organizaciones
que necesitan hacer una actualización informática, tener en cuenta algunos aspectos de interés que
permiten ubicar las tecnologías de información, para proveer a las organizaciones soluciones con
base en algunas características que cubren dichas tecnologías. [22]. En el Anexo 2. Se presentan las
tecnologías y sus características más relevantes.
Estas tecnologías y las necesidades informáticas se cruzan en la siguiente matriz, con el fin de
determinar cuál es la opción tecnológica que satisface las necesidades de la organización.
Objetivo: Detectar cuáles son las mejores tecnologías de información que suplen las necesidades
informáticas dentro de la organización.
Columna.
• -Necesidad Informática- en esta columna se enumeran cada una de las necesidades
informáticas descritas en la etapa 2
Es importante aclarar que en la matriz no está una descripción exhaustiva de todas las TI existentes
por tal razón el usuario puede agregar o eliminar tecnologías de acuerdo con sus necesidades.
Aunque se listan algunas de las características de cada una de las tecnologías, debe considerarse
sólo como una guía para entender su alcance, y posible solución a las necesidades existentes,
Luego de llenar esta matriz, se verifican las tecnologías que pueden satisfacer mejor las necesidades
de la organización. Ahora es necesario determinar cual es la estrategia de adquisición de dichas
tecnologías. Se recomienda tener como parámetro los precios de proveedores de estas tecnologías,
facilidad de acoplamiento con sistemas existentes y tiempo de implantación de las soluciones, el
área de sistemas y la gerencia de la organización, se selecciona la tecnología adecuada a sus
necesidades.
MISC-03-1-2
43
NECESIDADES INFORMATICAS TI CARACTERÍSTICAS N1 N2 N3 N4 Agilizar los flujos de datos en la empresa, integrando la información en tiempo real. Minimizar el tiempo de respuesta a clientes y proveedores. Delegar las decisiones en los niveles adecuados, manteniendo el control de gestión Garantizar la disponibilidad de información de soporte a la toma de decisiones.
ER
P
Facilitar el proceso de planeación empresarial, ya que permite obtener información consolidada del grado de consecución de los objetos definidos
X X X X
RELACION ENTRE LAS TECNOLOGIAS DE INFORMACION CON LAS NECESIDADES INFORMATICAS
NECESIDADES INFORMATICAS
TI CARACTERÍSTICAS N1 N2 … Nn Elaboración de tablas para uso individual Crear pequeñas aplicaciones para automatizar procesos personales
SUIT
E
DE
O
FIC
INA
Procesar información para que se facilite su análisis y aprovechamiento.
Aumentar la flexibilidad del espacio de su oficina Mejorar la eficacia y la movilidad, mientras sigue trabajando en cualquier lugar. Ofrecer un mejor servicio a los clientes que posean dispositivos inalámbricos: teléfonos móviles y PDA's
WIR
EL
ESS
Proporcionar a los socios y empleados acceso a información precisa en tiempo real desde cualquier lugar
Fusión con otra empresa u organización cuya forma de operar es distinta. La organización se encuentra dispersa geográficamente. O por cualquier otro motivo la comunicación Inter.-empresarial es muy limitada. El conocimiento mas importante se encuentra concentrado en unos pocos empleados o departamentos y no se distribuye adecuadamente hacia el resto de la organización.
KN
OW
LE
DG
E
MA
NA
GM
EN
T
Se genera un exceso de información en la organización, que se distribuye en forma masiva y sin criterios de selección o importancia.
Automatización de servicios de colaboración complejos, iterativos
WO
RK
FLO
W
Creación de una red compartida de información
MISC-03-1-2
44
Reducción del plazo de disponibilidad de nuevos productos, para su fabricación y comercialización Incremento de la productividad del departamento de ingeniería. Mejora de la calidad de los productos.
CA
D, C
AE
Y
PDM
Disminución de los costos de fabricación.
Inversiones en infraestructura y equipos, relaciones con clientes y proveedores, desarrollo de nuevos productos. Planificación de recursos y asignación de la demanda. SC
M
Programación de recursos y monitoreo de las operaciones.
Almacenar grandes cantidades de datos históricos
Administrar y Consultar los datos históricos
DA
TA
WA
RE
HO
USE
, D
AT
AM
ININ
G
Generar estadísticas y comparaciones sobre los datos para convertirlos en información
Agilizar los flujos de datos en la empresa, integrando la información en tiempo real. Minimizar el tiempo de respuesta a clientes y proveedores. Delegar las decisiones en los niveles adecuados, manteniendo el control de gestión Garantizar la disponibilidad de información de soporte a la toma de decisiones.
ER
P
Facilitar el proceso de planeación empresarial, ya que permite obtener información consolida
Integración de los viejos sistemas con los sistemas con los Net Markets
EA
I
Conocimiento detallado del cliente.
Toma de decisiones basada en información y no en supuestos. Incremento de los ingresos por ventas (satisfacción del cliente). Implementación de canales alternativos (e-commerce)
CR
M
Reducir el trabajo administrativo y las demoras conectando on-line a los distribuidores y proveedores.
MISC-03-1-2
45
Aumentar la capacidad de respuesta ante sus clientes y reducir los costos de mantenimiento de inventario. Optimizar sus relaciones financieras con clientes y proveedores mediante sistemas de pago y facturación a través de la red.
E-C
OM
ME
RC
E
Optimización de la cadena de valor de la organización
Permite la reutilización de la infraestructura existente. Reduciendo costos de implementación. Disminuye la intervención humana en los procesos de la empresa
Se puede implementar en intranet, extranet e Internet Permite la interacción de diferentes plataformas por medio de interfaces XML
WE
BSE
RIV
ICE
S
El fabricante se beneficia de un mayor volumen de ventas.
El minorista se beneficia de tener un stock de productos adecuado y poder ofrecerlo al consumidor final a un precio reducido, incrementando de este modo el volumen de ventas.
E-
CO
LL
AB
OR
AT
ION
El consumidor final se beneficia de unos precios de venta más bajos.
Matriz No. 10 Relación entre las tecnologías de información con las necesidades informáticas
Con la matriz anterior se puede identificar, para cada necesidad informática, la forma en que cada
una de las tecnologías aquí plasmadas puede ser una solución a la necesidad.
Es importante tener presente, que no hay una única solución tecnológica para cada necesidad, y que
es posible que al final del ejercicio se tenga una colección de tecnologías para satisfacer el conjunto
de necesidades de la organización. Lo importante y pedagógico de este ejercicio, está en encontrar
las características de las tecnologías, muchas veces comunes entre una y otra, para así verificar
cómo se puede dar solución a una necesidad.
MISC-03-1-2
46
5.5 TAPA 4: SELECCIÓN DE ESTRATEGIAS DE ADQUISICION, OPERACIÓN Y
MANTENIMIENTO DE LAS TECNOLOGIAS DE INFORMACION
Figura 8: Estrategias de Adquisición, operación y mantenimiento
Usted ha definido ya un portafolio de tecnologías de información que pueden satisfacer las
necesidades de su empresa o unidad de negocio. Ahora deberá definir cuál será su estrategia para
adquirir, operar y mantener dichas tecnologías.
Puede tener una sola estrategia para toda la organización, o definir estrategias de acuerdo con las
tecnologías que ha definido para su organización.
Tenga presente que estas alternativas que formularemos aquí, y el éxito de seleccionar una u otra
depende de la aceptación por parte de la gerencia y del presupuesto asignado para su desarrollo.
Aquí encuentra algunas de las alternativas de solución.
MISC-03-1-2
47
ESTRATEGIA QUIEN LA EJECUTA
VENTAJAS DESVENTAJAS
Compro Producto estándar
En casa Desarrollo nuevo contrato
En casa
Adapto lo actual
contrato
ADQUISICION
Alquilo Personal de planta
Outsourcing OPERACIÓN Y SOPORTE Planta +
outsourcing
En casa MANTENIMIENTO Outsourcing Matriz No. 11 Alternativas de Adquisición, Operación y Soporte de las Tecnologías de Información
seleccionadas
Esta matriz permitirá definir estrategias de adquisición, operación y soporte para la opción o las
opciones tecnológicas seleccionadas. Es importante verificar en cada opción tecnológica y para cada
una de las estrategias, las ventajas y desventajas de cada una. Esta información será sólo un soporte
al proceso de selección de una nueva tecnología. Hacer uso o no de esta fase es decisión del usuario
de la guía.
La matriz será entonces una herramienta informativa, que para el presente documento no posee un
sustento teórico como tal, la construcción de la misma se basa en la experiencia del autor y de un
grupo de personas entrevistadas, con cuya información fue posible determinar estas estrategias.
MISC-03-1-2
48
6 GUIA METODOLOGICA PARA LA IDENTIFICACION DE WEB SERVICES
Al momento de iniciar un proceso de adopción de tecnología, es necesario tener presente una serie
de aspectos que se presentan en detalle en este documento, y que aclaran específicamente, para el
uso de los Web Services, los pasos relevantes desde el entendimiento del negocio hasta la adopción
e implantación de un nuevo servicio tecnológico.
Cada fase presentada aquí tiene un objetivo y un entregable o resultado de la fase.
El siguiente gráfico es un resumen de las fases de esta guía metodológica:
CONOCIMIENTO DEL NEGOCIOCONOCIMIENTO DEL NEGOCIO
IDENTIFICAR PROCESOSIDENTIFICAR PROCESOS
CONSTRUIR CADENA DE VALORCONSTRUIR CADENA DE VALOR
DESCUBRIR DESCUBRIR WEBWEB SERVICESSERVICES
Patrones dePatrones deNegocioNegocio
NegociosNegociosInnovadoresInnovadores
FASE IFASE I
FASE IIFASE II
FASE IIIFASE III
FASE IVFASE IV
FASE VIFASE VI FASE VFASE V
IMPL ANTACION DE LOSIMPL ANTACION DE LOSWEBWEB SERVICESSERVICES
FASE VIIFASE VII
Figura 9: Fases de la guía metodológica propuesta para la identificación de Web Services
MISC-03-1-2
49
6.1 FASE I: Conocimiento del negocio
Objetivo: Identificar el negocio o en otras palabras; “lo que la empresa no está dispuesta a cambiar”,
el factor que es estratégico para la misma.
Al final de esta fase se tiene: la razón de ser del negocio su misión, visión, factores críticos de éxito
y objetivos estratégicos.
En esta fase nos debemos preguntar:
¿Quiénes somos?
¿Qué hacemos (producto/Servicio)?
¿Para quién hacemos nuestro trabajo?
Estas preguntas darán un marco general sobre el negocio, y su razón de ser. Para profundizar en esta
fase, se sugiere utilizar la Etapa 0 de la guía metodológica para construir cadenas de valor que se
encuentra en el capítulo 6.
6.2 FASE II: Identificar procesos
Objetivo: Identificar la forma en que opera la empresa, es decir: aquello que si está dispuesto a
cambiar. En otras palabras, aquí se identifica el ciclo de vida del producto o servicio que ofrece la
empresa.
Al final de esta fase se tiene: el conjunto de procesos de la organización.
En esta fase la pregunta es: ¿Cómo ejecutamos nuestro trabajo? El objetivo es identificar los
procesos de la organización o unidad de negocio, con el fin de obtener una lista detallada de los
mismos, sus actores, entradas y salidas.
El mecanismo para identificar los procesos y modelarlos es seleccionado por el equipo de trabajo.
Se sugiere el uso de UML para identificar de forma fácil y concreta los diagramas de actividad y los
actores de los procesos.
Un ejemplo de la forma en que se puede documentar esta fase se encuentra en el Anexo 1.
MISC-03-1-2
50
6.3 FASE III: Construir Cadena de Valor
Objetivo: Identificar el subconjunto de actividades que pertenecen al ciclo de vida de un producto
y/o servicio, y que son la base para la producción del mismo. Este subconjunto de actividades
corresponden a los factores que determinan la ventaja competitiva o estratégica de la organización.
Al finalizar esta fase se tiene: El detalle de la cadena de valor del producto y/o servicio (actividades
primarias y de soporte). Y el desglose de la cadena de valor extendida, es decir, la relación de la
organización o unidad de negocio con sus socios, distribuidores y clientes estratégicos.
En esta fase, se recomienda hacer uso de la guía metodológica para construir cadenas de valor que
se encuentra en el capítulo 5. Utilizando como insumo para la identificación de las actividades de la
organización, los resultados obtenidos en la Fase II.
De esta fase se obtendrá la cadena de valor interna, y la cadena de valor extendida4.
6.4 FASE IV: Descubrir posibles Web Services en la cadena de valor
De la matriz de generación de la cadena de valor extendida, y de las necesidades informáticas con
sus correspondientes soluciones extraídas de la etapa 5 de la Guía Metodológica para la
Construcción de la Cadena de Valor, y de los pasos que se dan a continuación, se determinan los
aspectos que pueden ser susceptibles de ser desarrollados con Web Services.
4 Cadena de Valor Extendida: es la cadena de valor que relaciona los clientes y proveedores con la cadena de valor interna o del negocio.
MISC-03-1-2
51
Cadena de valorInternaInterna + + ExtendidaExtendida
Identif icar Identif icar Portafolio de AplicacionesPortafolio de Aplicaciones
Nuevas y Nuevas y LegacyLegacy con y sin B2Bcon y sin B2B
Definir si el WS es Definir si el WS es Transaccional y/o de consultaTransaccional y/o de consulta
Determinar si se requiere Determinar si se requiere O no el UDDIO no el UDDI
Definir Definir GranularidadGranularidadSoluciones/entidades
Figura 10: Cómo determinar aspectos que se pueden llevar a Web Services
1. El primer paso corresponde a la construcción de la cadena de valor interna y la cadena de
valor extendida de la organización o unidad de negocio. Esta actividad fue cubierta en la
fase III.
2. Identificar portafolio de aplicaciones nuevas y heredadas de la empresa, para ello no es
necesario que las aplicaciones hayan sido hechas para manejo B2B. Para esta etapa se toma
el listado de aplicaciones con las que cuenta actualmente la organización, adicionalmente se
toma el listado de alternativas de solución que se obtuvo de la matriz No. 8 Definición de
las alternativas de solución, que corresponde a la etapa 3 de la guía para la construcción de
la cadena de valor.
Una vez identificadas las aplicaciones se procede a desarrollar la matriz de Soluciones-Entidades,
donde se espera definir la granularidad con la que se manejan las entidades en las aplicaciones,
teniendo en cuenta que al hablar de entidades nos referimos específicamente a datos que son usados
por las aplicaciones, como se muestra a continuación.
MISC-03-1-2
52
Matriz Soluciones – Entidades
Columnas:
Alternativas de solución - identificadas en la matriz de alternativas de solución y las
soluciones B2B y B2G identificadas de la matriz de la cadena de valor extendida.
Entidad- son las entidades que se utilizan comúnmente para la ejecución de estas
soluciones. Aquí es importante tener presente la “razón de ser del negocio”, y el ciclo de
vida el producto y/o servicio que se maneja, pues de allí es que se obtiene el listado de las
entidades que maneja la organización.
En cada casilla va un valor correspondiente a la frecuencia de uso de esa entidad para esa
solución. Dado que este valor no es fácil de calcular o determinar, se puede colocar 5=Uso
Alto, 3=Uso Medio, 1=Uso Bajo, 0= No usa esta información, por otra parte deberá
especificar si el dato sólo se consulta o si el dato se crea y/o modifica en esa solución. Para
lo anterior se utiliza M=si el dato se crea y/o modifica y C=si el dato se consulta.
No.
So
luci
ón
SOLUCION En
tidad
1
Entid
ad 2
Entid
ad M
1
2
N
Matriz No. 12 Recurrencia del uso de entidades en soluciones informáticas
De esta forma hemos identificado dos posibles fuentes de Web Services, por una parte de la matriz
de Cadena de Valor Extendida se obtienen las relaciones B2B que pueden implementar los Web
Services, por otra parte de la matriz de Soluciones – Entidades se identifican los puntos en los
cuales es factible introducir los Web Services. Esta última parte es la identificación de las
necesidades recurrentes de información.
MISC-03-1-2
53
Para las aplicaciones heredadas (legacy), se utiliza la misma matriz y los mismos conceptos de
calificación de las entidades, teniendo en cuenta que ya son soluciones establecidas y no nuevas
soluciones.
Es importante recalcar en este punto, que una forma sencilla de lograr la adopción de esta nueva
tecnología es iniciar “ordenando la casa”, es decir; involucrando los Web Services en los procesos
de la cadena de valor interna del negocio o unidad de negocio, para luego potenciarlo llevándolo a
optimizar la cadena de valor extendida. De acuerdo con Gartner Group, las primeras
implementaciones de Web Services han sido internas debido a factores más de tipo técnico como la
seguridad transaccional, y fue una tendencia generalizada en el año 2002. Gartner Group considera
que estos proyectos internos de Web Services, son la estrategia correcta para desarrollar los
proyectos de las empresas de hoy[23].
6.5 Fase V: Negocios Innovadores haciendo uso de Web Services
Una vez identificados los puntos de la cadena de valor donde pueden ser utilizados los Web
Services, y como parte del mejoramiento continuo de las organizaciones, conviene analizar los
puntos en los cuales hacer uso de Web Services puede generar nuevos negocios.
Objetivo: Plantear nuevos negocios para la organización o unidad de negocio, que haciendo uso de
Web Services establezcan un modelo innovador.
Se recomienda hacer uso de la taxonomía expuesta en la fase VI, para aplicarla a las ideas o
servicios informáticos descubiertos en el análisis, y así poder dar por intermedio de los patrones de
e-business una caracterización a las soluciones diseñadas, con el fin de identificar los puntos en los
cuales son pertinentes los Web Services.
6.6 FASE VI: Uso de Patrones de Negocio (B2B)
Esta fase es un apoyo a la identificación de Web Services que se trabajó en la fase V.
MISC-03-1-2
54
El objetivo es caracterizar o tipificar aquellos negocios y/o aplicaciones que originalmente se
pensaron usando Web Services para su implementación, pero que aún no han sido valoradas desde
un esquema o patrón que lleve fácilmente a involucrar este nuevo concepto.
Basados en conceptos y marco teórico, cualquier aplicación B2B puede hacer uso de Web Services
en su desarrollo, sin embargo, la forma o el sitio de la aplicación en el que se puede involucrar esta
tecnología no es transparente, por otra parte aspectos como; seguridad y transaccionalidad pueden
llevar al analista a descartar Web Services como tecnología integradora. Por lo anterior, en esta fase
se exploran los patrones compuestos, que haciendo uso de los patrones de negocio e integración dan
un contexto general para usar Web Services, y llevan al usuario de esta guía a entender cuándo es
conveniente o no involucrar Web Services.
Al hablar de patrones estamos tratando de establecer una regla común, un modo de comportamiento
generalizado o un molde que garantiza la producción en serie de algún producto o soluciona de
forma estándar un problema recurrente o común. En otras palabras, hablamos de “las mejores
prácticas” para solucionar un problema o situación común.
Se toma como base la información obtenida de IBM[14] y otros autores como Phill Evans en el
texto Blown to Bits sobre la forma en que están organizados los negocios hoy en día, en especial la
forma en que se puede caracterizar el e-business. El concepto de patrones en e-business ha sido
trabajado por IBM desde 1999, y ha sido clave para el desarrollo de aplicaciones e-business[14].
Actualmente, IBM trabaja estos patrones orientándolos hacia Web Services. En este documento, se
trabajarán como una guía para poder identificar dónde ubicar los Web Services en los procesos e-
business de la empresa, esto incluye los procesos actuales y posibles nuevos negocios para la
organización.
Al iniciar un proceso de adaptación de nuevas tecnologías o generación de nuevos negocios
haciendo uso de tecnologías, es indispensable conocer y caracterizar el negocio, sus necesidades
informáticas serán fruto de este conocimiento y de los requerimientos que surjan del análisis de la
cadena de valor y del levantamiento de información con los clientes internos (cadena de valor
interna) y externos (cadena de valor extendida) de la empresa. Al conocer las necesidades
informáticas se podrán identificar los patrones de e-business o patrones Compuestos a partir de los
patrones de negocio y de integración. La siguiente gráfica muestra este proceso:
MISC-03-1-2
55
Requerimientos delRequerimientos delClienteCliente
PatronesPatronesCompuestosCompuestos
B2BB2BPatronesPatrones
De negocioDe negocioPatronesPatrones
De integraciónDe integración
PatronesPatronesDe AplicaciónDe Aplicación
Topología Topología
PatronesPatronesRuntimeRuntime
Infraestructura TecnológicaInfraestructura Tecnológica
ConocimientoConocimientoDel Del
NegocioNegocio
Diseño de una Diseño de una soluciónsolución
Patr
ones
e-b
usin
ess
Figura 11: Modelo de patrones por capas. Adaptado IBM Patterns for e-business.
http://www-106.ibm.com/developerworks/patterns/
• El primer paso consiste en el entendimiento del negocio, que se ha obtenido desde el análisis de
la cadena de valor del mismo, incluyendo la cadena interna y la cadena extendida.
Del entendimiento del negocio se han obtenido los requerimientos o necesidades informáticas
de la organización, estas necesidades no están orientadas a una tecnología en especial para su
solución, sin embargo, ciertas características de las mismas pueden llevarnos a encontrar la
mejor opción tecnológica posible. Lo ideal una vez se cuenta con las necesidades informáticas
es hacer un pequeño diseño de la solución que puede cubrir esta necesidad, con el fin de
identificar por medio de patrones, cuál es el tipo de “solución de negocio” a la cual se asemeja
(patrón).
• El segundo paso una vez se ha obtenido un diseño o descripción previa del servicio a ofrecer, es
caracterizar ese servicio de acuerdo con los patrones de negocio que se listan a continuación:
• Autoservicio (Self-Service)
• Colaboración
• Agregación de Información
• Empresa Extendida
MISC-03-1-2
56
La combinación de diferentes patrones de negocio con los patrones de integración, dan como
resultado los patrones Compuestos o de Composición, que no son más que la caracterización de
los negocios desde la perspectiva del e-business.
• E-commerce
• E-Marketplace
• Portales
• Acceso o transaccionalidad de cuentas
Los patrones de negocio, de colaboración y de integración se explican a continuación:
Patrones de Negocio
Son construcciones a alto nivel, que pueden ser usadas para describir el propósito que tiene una
solución para un negocio. Los patrones deben describir:
• Objetivo de la solución (¿Para qué se usa ?)
• Participantes que interactúan en ella (¿Quién lo usa?)
• Naturaleza de las interacciones entre los participantes (¿Cómo lo usan?)
Los patrones de negocio nos presentan y definen la forma de hacer los negocios, estos se catalogan
en cuatro Autoservicio, Colaboración, Agregación de Información y Empresa Extendida. Las
características de cada uno de ellos se explican en la siguiente tabla:
MISC-03-1-2
57
TABLA 1. CARACTERIZACION DE LOS PATRONES DE NEGOCIO
Autoservicio Colaboración Agregación de Información Empresa Extendida
Objetivo
Usuarios internos y externos que interactúan con transacciones de la empresa y datos de la misma
Permite a los usuarios trabajar unos con otros para compartir datos e información
Los usuarios pueden acceder y manipular datos desde múltiples fuentes. Para transformar grandes cantidades de datos en información útil.
Maneja la integración de datos y procesos a través de la empresa y con empresas separadas que hacen parte de la operación.
Entidades Usuarios y Negocios Usuarios con Usuarios Usuarios y Datos Negocio a Negocio
El usuario Final y el cliente necesitan interactuar directamente con los proceso del negocio.
Usuarios finales y clientes necesitan interactuar directamente con los procesos del negocio
Los usuarios finales y los clientes necesitan interactuar directamente con los procesos de negocio y/o datos.
No incluye las aplicaciones que se invocan mediante una interfaz de usuario.
Los procesos del negocio necesitan ser integrados con sistemas de negocio e información existente.
La actividad del negocio exige y fomenta la colaboración y compartir información entre sus participantes
La actividad del negocio requiere: agregar, organizar y presentar información de varias fuentes de datos dentro y fuera de la organización.
Los procesos de negocio necesitan ser integrados con sistemas e información existentes.
Debe cumplir con las siguientes
características
Los procesos del negocio deben ser alcanzables de manera común, consistente y simplificada a través de múltiples canales de entrega.
Ocurre en las soluciones e-business donde se puede interactuar de forma asincrónica, sincrónica y broadcast y multi casting.
Los procesos de negocio necesitan ser integrados con sistemas, procesos e información que existen en las organizaciones aliadas.
Industria de seguros: localizar oficinas cercanas, localizar corredores de bolsa, cuentas en línea
e-mail, bulletin board, Newsgroups, Mensajería instantánea, Cuartos de discusión, reuniones en línea
Estrategia y planeación: Análisis de decisiones, planeación estratégica de negocio, análisis estadístico. SCM, CRM
Industria de telecomunicaciones y wireless: pagos de cuentas en línea, adicionar, cambiar y remover servicios Work Flow
Análisis de Mercado: Identificación de mercados, identificar prospectos de clientes, contactar clientes,
Financiero: Transferencias y pagos, obtener información crediticia, chequeo de contabilidad y balances
Ejemplos
Gobierno: Pago de impuestos, bajar aplicaciones y formatos
Administración de procesos internos: Detección de fraudes, administración de riesgos.
Chequeo de inventarios de proveedores y/o clientes, colocar ordenes automáticamente, generar pagos a proveedores.
¿Cómo implementa los Web Services?
La organización puede publicar las funciones centrales del negocio usando Web Services, que pueden ser consumidos por clientes y aliados de negocio.
Individuos, programas y organizaciones, pueden colaborar unos con otros accediendo Web Services estándar como entidades aliadas.
Los agregadores de contenido pueden acceder Web Services provistos por proveedores de contenido. Ellos también pueden usar Web Services para poner contenido disponible a los consumidores.
Las tecnologías de Web Services pueden ser usadas para simplificar procesos de integración de sistemas y procesos de negocio a través de la cadena de valor.
MISC-03-1-2
58
Patrones de integración
Los Patrones de integración tienen como función servir como plataforma de integración de los
problemas descritos en los patrones de negocio. Estos patrones pueden integrar:
• Múltiples aplicaciones
• Múltiples modos de acceso
• Múltiples fuentes de información
Su diferencia con los patrones de negocio radica en que no automatizan problemas específicos de
negocio, pero se usan con los patrones de negocio para dar soporte a funciones más avanzadas.
Los Patrones de Integración están divididos en dos:
1. Patrón de Integración de Acceso: que habilita el acceso a múltiples canales e integra
servicios comunes requeridos para soportar una interfaz de usuario consistente.
2. Patrón de Integración de Aplicación: Reúne múltiples aplicaciones y fuentes de información
sin que el usuario las invoque directamente. Este patrón es efectivo cuando se requieren
esfuerzos de desarrollo que involucran múltiples aplicaciones y acceso a sus respectivos
datos, con el fin de automatizar funciones nuevas y complejas de negocio. La integración
puede ser a nivel de procesos, en el cual se integra el flujo entre las aplicaciones, o puede
ser de datos, el cual integra la información que utilizan las aplicaciones (centraliza datos).
Estos dos patrones podemos clasificarlos de acuerdo con las siguientes tecnologías de integración
ya conocidos en el mercado:
• EAI
• Web Services
• RPC, CORBA, DCOM, RMI
• Batch
Todas las soluciones con excepción de la última, que es asincrónica, funcionan de forma sincrónica
y asincrónica
Los patrones de integración son, como su nombre lo indica, la forma en que se pueden integrar los
patrones de negocio.
MISC-03-1-2
59
Patrones E-business o Patrones Compuestos
Estos patrones son la combinación de los patrones de negocio y los patrones de integración, para
conformar soluciones que desempeñan funciones complejas de negocio.
Los patrones de composición son los patrones de e-business conocidos tradicionalmente en el
mundo de los negocios electrónicos:
• E-commerce o transacciones comerciales
• E-marketplace
• Portales
• Acceso a Cuentas o de consulta de estado de cuenta (son principalmente de carácter
financiero)
Las características de cada uno de ellos y los patrones obligatorios y opcionales que los conforman,
así como el tipo de transacciones y seguridad que se maneja típicamente en cada uno de ellos, están
en el Anexo 9. En el siguiente cuadro se aprecia un resumen de las combinaciones de los patrones
de negocio e integración, que se requieren para obtener el patrón compuesto:
MISC-03-1-2
60
TABLA 2: CONSTRUCCION DE LOS PATRONES COMPUESTOS
Definición Patrones Obligatorios Patrones Opcionales
E-C
omm
erce
Conjunto de procesos y productos que facilitan el intercambio seguro de bienes y servicios sobre el web, incluidos: Publicidad, mercadeo, compras, ventas, pagos, entregas de productos
Patrón de Negocio de Autoservicio Patrón de Negocio de Agregación de Información Patrón de Integración de Aplicación
Patrón de Integración de Acceso Patrón de negocio de Colaboración Patrón de negocio de Empresa Extendida
Intercambio Comercial--- • Patrón de negocio de auto servicio • Patón de Negocio de Agregación de
Información • Patrón de integración de aplicaciones • Patrón de Integración de Acceso
Patrón de negocio de colaboración Patrón de Negocio de Empresa Extendida
Hub del lado del vendedor • Patrón de Integración de Acceso • Patrón de Negocio de Autoservicio • Patrón de Negocio de Agregación de
Información • Patrón de integración de aplicaciones
Patrón de Negocio de Colaboración Patrón de Negocio de Agregación de Información Patrón de Negocio de Empresa Extendida E
-Mar
ketp
lace
Intercambios comerciales que facilitan y promueven la compra y venta y negocios entre comunidades de aliados de un sector.
Hub del lado del comprador • Patrón de integración de acceso • Patrón de negocio de Colaboración • Patrón de Negocio de Autoservicio • Patrón de Integración de Aplicación
Patrón de Negocio de Agregación de Información Patrón de Negocio de Empresa Extendida
Acc
eso
a C
uent
as
Provee acceso permanente a los usuarios a la información de sus cuentas. Les permite a los usuarios, borrar, incluir o actualizar información de sus cuentas
Patrón de Integración de Acceso Patrón de Negocio de Autoservicio
Patrón de Agregación de Información Patrón de negocio de colaboración
Port
al
Provee varios mecanismos como la administración de contenidos, el formateo de la interfaz de usuario y la agregación de datos, para proveer una información apropiada que junto con los sistemas existentes, ayuden a cumplir las metas del negocio.
Patrón de Integración de Acceso Patrón de Negocio de Autoservicio
Patrón de Negocio de Empresa Extendida Patrón de Integración de Aplicación
MISC-03-1-2
61
¿Cómo identificar el uso de Web Services para las soluciones generadas al usar los patrones
de negocio e integración?
Ya se han identificado patrones de negocio que permitirán la implementación de negocios
innovadores, pero queda la pregunta de qué tipo de patrón de integración será adecuado utilizar.
Corresponde ahora validar si es viable hacer uso de Web Services para estos patrones, para lo cuál
se formulan algunas preguntas que son el resultado de analizar las ventajas y desventajas actuales
de los Web Services, estas preguntas son la base para la construcción de una lista de chequeo que
permitirá verificar la pertinencia del uso de Web Services.
1. ¿Qué tipo de transacciones se van a soportar en el sistema?
a) Lectura
b) Lectura y Escritura
Si no se desea conservar la atomicidad y consistencia de los estados modificados, y no se
trabaja bajo el contexto de una transacción distribuida, el esquema de Web Services es
válido.
2. ¿Qué nivel de seguridad se va a manejar?
a) Nivel de Autenticación: los Web Services no soportan este nivel en los ambientes de
construcción, sin embargo la autenticación (firmas digitales, certificados, etc.) se puedae
hacer manualmente (haciendo que la aplicación desarrolle toda la lógica para manejar estos
elementos).
b) Nivel de Encripción: Los Web Services soportan este nivel, ya que corren sobre
protocolo http y se puede usar SSL para encripción.
Los estilos de transacción y niveles de seguridad se definen al nivel de patrones de negocio, una vez
definidos se puede identificar cuál es el patrón de integración de acceso y/o de aplicación a utilizar.
Ahora que se han identificado unos mínimos requeridos para el uso de Web Services, se recomienda
tomar los servicios B2B generados en la identificación de la cadena de valor, y los servicios o
negocios innovadores que se hayan expuesto como soluciones novedosas o negocios B2B nuevos, y
clasificarlos en la siguiente matriz de patrones B2B de la cual se podrá deducir, con base en lo
expuesto anteriormente, si el uso de un web service es adecuado como solución de integración.
MISC-03-1-2
62
Matriz No. 13. Tipo de transacción y seguridad de los Web Services
6.7 Fase VII: Diseño, desarrollo e implantación de los Web Services
Esta fase se propone dentro del modelo pero no se implementa para este proyecto. Lo ideal es la
generación de unos aspectos mínimos para el desarrollo de software, ejecutado con metodologías de
calidad, las fases I a IV se consideran las etapas de planeación y análisis de los sistemas, que en
este caso usará Web Services.
La fase de diseño deberá entregar una arquitectura del sistema y la forma de desarrollarlo,
implementarlo e implantarlo dependerá en gran medida, de la herramienta de desarrollo
seleccionada.
Una vez se define el Web Service o Web Services que la organización o unidad de negocio pueden
implementar, es necesario priorizar los desarrollos. Medir el retorno a la inversión ROI de
implementar cada uno de los Web Services puede ser una medida real y objetiva, que permitirá a la
organización validar con base en cifras, calculadas por la misma organización, el orden en el que
conviene hacer los desarrollos o en el peor de los casos, descartar aquellos Web Service que no
generen ventaja para la empresa.
Tipo de Transacciones Nivel de Seguridad
Descripción del negocio o
aplicación
Patrón de E-
business Lectura
Lectura/Escritura (Sin garantizar atomicidad y
consistencia de estados)
Lectura/Escritura (Garantizando atomicidad y
consistencia de estados) Autenticación Encripción
MISC-03-1-2
63
No se cuenta con estadísticas suficientes ni confiables para medir el ROI de desarrollar Web
Services, mucho menos se cuenta con aplicaciones a gran escala que den un dato certero del cálculo
del ROI. Sin embargo, el ejercicio puede dar una visión global a la gerencia de la empresa. Otros
métodos pueden ser usados para calcular cuantitativamente el beneficio de implementar Web
Services, para esta guía sólo se hace uso de ROI.
6.7.1 Retorno a la inversión (ROI) al usar Web Services
El ROI o retorno a la inversión es una métrica clave a nivel financiero que permite establecer el
valor de las inversiones de un negocio. Se define como la tasa de los beneficios netos sobre los
costos y se expresa como un porcentaje[15]. Para el caso de los Web Services, esta métrica se
define como
ROI =[ (Beneficios Monetarios (Tangibles e intangibles) – Costo de usar la tecnología de Web Services) /
Costo de usar la tecnología de Web Services ] x 100
La organización deberá contemplar, adicionalmente al desarrollo del Web Service como tal, los
costos en que se incurre por hardware, software integración de sistemas, y los costos futuros por el
soporte a las aplicaciones. Es importante tener presente que se ahorran costos al hacer uso de
arquitecturas orientadas a servicios construidas sobre estándares abiertos, algo que no se demostrará
matemáticamente en este documento, pero que es una realidad[15]. Estos servicios impactan las
demás tecnologías de información y las unidades de negocio y desde aquí se establecen los
beneficios potenciales, tanto tangibles como intangibles. Los beneficios tangibles e intangibles o
directos e indirectos se obtienen del ahorro. En el caso de los beneficios directos tenemos la
reducción de costos, el incremento de las ganancias, el desarrollo de sistemas más eficientes y
efectivos, mientras que en los beneficios indirectos se incluye innovación, desarrollo de nuevos
productos y el incremento de capital.
La relevancia e importancia de cada uno de los factores definidos para calcular el ROI, pueden
variar de organización a organización, de implantación a implantación y de aplicación a aplicación.
Los factores que se deben incluir para el cálculo del ROI son [15]:
MISC-03-1-2
64
1. Costos y Gastos
a) Requerimientos de Hardware: Número de servidores, configuración de servidores requerida,
porcentaje estimado de incremento o decremento en el desempeño del hardware existente al hacer
uso de los Web Services. En este punto es importante tener presente que hay costos iniciales y
costos que se mantienen en el tiempo, principalmente en lo relacionado con mantenimiento y
soporte del hardware adquirido así como en las actualizaciones permanentes que se requieran.
b) Requerimientos de Software:
• El soporte a Web Services que dan las aplicaciones existentes y los brokers de integración y qué
otro software es necesario para soportar esta nueva estrategia.
• Costo de actualizar el software actual.
• Cualquier costo operacional asociado.
c) Requerimientos en capacitación:
• En hardware, software y herramientas en general.
• Costo total de entrenar desarrolladores, arquitectos de software, administradores de proyecto,
administradores de sistema y redes y personal encargado de herramientas de soporte,
d) Requerimientos en ancho de banda de la red: cualquier costo asociado al incremento del ancho de
banda de la red para poder usar los Web Services. Se debe estimar la carga que el Web Service
coloca en el ancho de banda de la red. Otra forma de calcular este dato es midiendo y calculando la
inversión que se debe realizar para conocer los requerimientos adicionales de ancho de banda.
e) Herramientas de monitoreo: algunas veces se requerirá invertir en herramientas que permitan
chuequear la calidad, el tiempo de diseño, y lo más importante que es el tiempo de ejecución.
f) Costos operacionales y de consultoría: Costos de instalación de software relacionado con el
Web Service y de la configuración y consultoría sobre el mismo.
2. Beneficios Técnicos
a) Automatización del desarrollo de software: Estimar el número de aplicaciones/sistemas que
pueden reutilizar el Web Service.
• Ahorro en términos de horas-hombre de desarrollo, al hacer uso de los Web Services.
b) Acoplar suavemente las tecnologías middleware:
• Estimar la reducción gastos de hardware.
MISC-03-1-2
65
• Estimar la reducción en gastos de software
• Estimar la reducción de gastos de personal
c) Uso de integración basada en estándares. Se estima el número total de interfaces propietarias
que se pueden construir, desarrollar y mantener si se hace uso de Web Services. Cuánto
representa en ahorro el no desarrollar, y probar un gran número de interfaces para dada uno de
los sistemas propietario de la organización, incluidos los sistemas de integración con aliados y
socios de negocio, tales como aplicaciones EDI.
d) Integración con aplicaciones y con administración de procesos de negocio. Se estima el ahorro
total que se da como resultado de usar plataformas neutrales, también se determina el ahorro
producido, por automatizar y manejar los proceso de negocio como Web Services.
e) Terminar con la duplicación de código de software y aumentar la reutilización: Muchas
organizaciones contienen silos de información, generados por las aplicaciones y código
duplicado que se han desarrollado a lo largo del tiempo. Se pretende medir entonces:
• El número total de sistemas y grupos que manejan información duplicada (silos).
• Analizar cuántos de estos sistemas son redundantes y se superponen unas con otras.
• Calcular el ahorro (hardware, software, personal) al eliminar los sistemas redundantes.
• Calcular el ahorro (hardware, software, personal) al exponer información común de forma
estándar.
3. Beneficios para el negocio
a) Productividad del usuario final: determinar cómo se incrementa la productividad del usuario
final que hace uso de las aplicaciones basadas en Web Services y determinar el porcentaje de
incremento de productividad en su desempeño.
b) Participación en negocios dinámicos: estimar le número de nuevas relaciones de negocios y el
porcentaje de ganancia por estas nuevas relaciones.
c) Actividades de negocio colaborativas: como compartir capital intelectual. Se mide el
incremento en productividad, desempeño, innovación. Finalmente se mide el ahorro generado
por la colaboración que se de entre las compañías de un mismo sector.
Se mide el ahorro en costo resultante del comercio colaborativo generado por las aplicaciones
basadas en Web Services.
d) Mejor y más económico servicio al cliente: medir el ahorro generado como resultado de la
automatización del servicio a cliente por medio de Web Services.
MISC-03-1-2
66
e) Otros beneficios: se presentan otros beneficios directos e indirectos, tales como; rápido tiempo
de mercadeo, incremento de la eficiencia de los procesos, incremento de la eficiencia de los
negocios a través de la automatización de los procesos.
4. Riesgos asociados al uso de Web Services para el cálculo del ROI
Para poder medir correctamente el ROI, es necesario contemplar los riesgos generados o
asociados a estas nuevas tecnologías.5
a) Tecnología Nueva: Las tecnologías que soportan el desarrollo de los Web Services son
nuevas y en constante evolución. En su estado actual, los Web Services pueden ser usados
únicamente en escenarios de llamada-respuesta no transaccionales
b) Estándares no maduros o no finalizados: Los estándares que soportan la tecnología de Web
Services como WSDL, UDDI y WSFL están en evolución y por tanto no están maduros.
No hay garantía de que lo hecho y desarrollado hasta hoy no deba ser modificado y
adaptado, una vez se tengan herramientas más robustas y confiables.
c) Servidores y herramientas de desarrollo de Web Services: El soporte que ofrecen
actualmente las compañías de desarrollo de Web Services no es suficiente para construir,
desarrollar y ejecutar Web Services de misión crítica.
d) Seguridad: Este es uno de los principales aspectos por los cuales se rechaza la adopción de
los Web Services. Los requerimientos claves para usar Web Services son la autenticación,
autorización, protección de datos y no repudiación.
Ya se dieron unas indicaciones para calcular el ROI, ahora se darán unos pocos pasos para obtener
el ROI con base en los Beneficios y Riesgos ya explicados:
Paso 1. Calcular el costo total de implementación de un Web Service, para ello tomar el
punto 1 de costos y gastos, los literales de a) a f) y realizar la sumatoria de los mismos.
Paso 2. Determinar el costo total ahorrado por los beneficios técnicos que se calcularon
del punto 2, realizando la sumatoria de todos los literales.
5 Para profundizar en el tema de riesgos diríjase a la sección del marco teórico..
MISC-03-1-2
67
Paso 3. Determinar el incremento en la productividad, eficiencia y ganancias a través
de los beneficios de negocio al usar Web Services, que se obtienen del punto 3.
Paso 4. Cuantificar el riesgo asociado con la introducción y uso de los Web Services,
que se encuentran en el numeral 4.
El siguiente paso es categorizar los resultados de los pasos 1 hasta el paso 4 bajo los siguientes
encabezados:
Costos del proyecto incluyendo inversión de capital, labor de implementación, administración y
soporte operación y costos de contratación (Paso 1 + Paso 2) (A).
Beneficios del proyecto (técnicos y del negocio), incluyendo beneficios netos tangibles (Paso 3)
(B).
Riesgos del proyecto cuantificados como costos potenciales (Paso 4) (C). Donde C se calcula como
el valor esperado o esperanza de la ocurrencia del riesgo evaluado. Lo que quiere decir que a cada
riesgo se le debe asociar una probabilidad de ocurrencia y un costo en caso de que ese riesgo llegue
a ocurrir. El valor esperado o esperanza se calcula multiplicando la probabilidad de ocurrencia del
riesgo por el costo asociado al mismo.
Usando la fórmula ya explicada anteriormente se tiene:
ROI para Web Services = (B-A-C)/(A+C)*100
Con esta fórmula, se puede obtener el ROI, lo importante aquí es la consecución de todos los
elementos técnicos, de negocio y de riesgos, para tener un dato confiable.
MISC-03-1-2
68
7 VALIDACION DE LA GUIA METODOLOGICA – PRUEBA DE CONCEPTO
A continuación se presentan los resultados de la validación de la guía metodológica para la
incorporación de Web Services en las organizaciones en un caso de estudio particular.
7.1 CASO DE ESTUDIO: CARRERA DE INGENIERIA DE SISTEMAS DE LA
PONTIFICIA UNIVERSIDAD JAVERIANA
Tomando como base la información recolectada en una entidad educativa de nivel superior, se hace
la aplicación para la validación de la guía.
El equipo de trabajo está conformado por el Director de la Carrera, el Director del Departamento y
los docentes del mismo, desde el punto de vista tecnológico el grupo se apoya en el director del
proyecto ORBIS6.
Cada fase de la guía metodológica para la identificación de Web Services, y cada etapa de la guía
metodológica para la generación de cadenas de valor han sido explicada en detalle en los capítulos 6
y 7, por lo cual aquí sólo se presentan algunos de los resultados obtenidos en la validación.
7.1.1 FASE I: Conocimiento del negocio
Se inicia entonces el conocimiento de la Carrera identificando el negocio, y el ciclo de vida que se
lleva a cabo en el mismo.
• NEGOCIO: Formar profesionales en Ingeniería de Sistemas
6 Proyecto ORBIS: Proyecto de la Facultad de Ingeniería de la Pontificia Universidad Javeriana, para el rediseño de procesos y automatización de los mismos.
MISC-03-1-2
69
• CICLO DE VIDA:
Inscripción => Selección => Formación => (Grado, retiro, exclusión)
Aunque la guía metodológica entrega en detalle la cadena de valor interna y extendida, en esta fase
se puede plasmar una cadena de valor tentativa, que no desagrega las actividades primarias de las de
soporte.
Esta cadena se desagrega aún más y se detalla así:
Esta es la forma tradicional de esbozar las cadenas de valor, no se han detallado las actividades, y
por otra parte, aún no es posible determinar si hay actividades redundantes que se pueden eliminar
de la cadena al no generar valor. Por otra parte, no se ve con claridad la cadena de valor extendida,
y las relaciones con los clientes y proveedores externos. Ahora iniciamos la aplicación formal de la
guía metodológica para la construcción de cadenas de valor.
7.1.1.1 ETAPA 0: CONTEXTUALIZACIÓN
El objetivo es contextualizar el negocio e identificar la “razón de ser” del mismo. Para el desarrollo
y cumplimiento del objetivo de la etapa de contextualización se utiliza la misión de la Universidad
Javeriana y se hace uso de la herramienta TASCOI.
Mercadeo Programa
Selección Estudiante
Solicitud Servicios Docentes
Seguimiento Ciclo académico Estudiantes
Grado Estudiante
FFOORRMMAACCIIOONN ESTUDIANTE PROFESIONAL
SSEELLEECCIIOONN
MISC-03-1-2
70
TASCOI
T: Adquirir, apropiar, difundir y generar conocimiento en los bachilleres entregados por la sociedad,
la industria contratante y los profesionales.
A: Docentes y empleados administrativos que laboran en la institución, el actor activo y más
importante del proceso es el estudiante.
S: La sociedad en general, por intermedio y los sectores económicos que proveen los bachilleres y
profesionales de cursos de extensión. Entidades educativas de nivel superior (generadoras de
conocimiento), entidades manejadoras de conocimiento (editoriales).
C: Bachilleres, los padres de familia de los estudiantes, los diversos sectores económicos
contratantes de profesionales, y los profesionales de diversas empresas.
O: Las juntas directivas, consejos académicos, rectores, vicerrectores, decanos dependiendo del
tipo de institución educativa (Ej. Privada, pública, católica entre otros)
I: ICFES, ministerio de educación, entidades acreditadoras, asociaciones de egresados.
Con lo anterior se logra la definición de la IDENTIDAD de la organización.
MISIÓN
Se toma la misión de la Universidad Javeriana, ya que la Carrera de Ingeniería de Sistemas no posee
una misión propia como unidad académica. Un paso interesante aquí, sería identificar la misión de
la carrera a partir de la aplicación del TASCOI. Sin embargo, se utiliza la misión general de la
universidad.
Con base en la misión se obtienen los siguientes componentes:
• Impulsar la investigación
• Impulsar la formación integral centrada en los currículos
• Fortalecimiento de la interdisciplinariedad
• Fortalecimiento de la presencia en el país
• Disminuir la crisis ética y la instrumentalización del ser humano
• Fortalecer el aprecio a la nacionalidad
MISC-03-1-2
71
• Fortalecer la identidad cultural
• Eliminar la intolerancia y el desconocimiento de la pluralidad y la diversidad.
• Eliminar la discriminación social y la concentración del poder económico y político.
• Eliminar la inadecuación e ineficiencia de sus principales instituciones.
• Eliminar la deficiencia y la lentitud en el desarrollo científico y tecnológico.
• Eliminar la irracionalidad en el manejo del medio ambiente y de los recursos naturales
Resultados de la aplicación de la Fase I de la guía: Al iniciar este proceso se tuvieron algunos
inconvenientes en la definición del TASCOI, en especial en la identificación de los propietarios
(O) y de los proveedores (S) de la Carrera de Ingeniería de Sistemas. Para poder llegar a un
consenso confiable sobre el tema, se utilizó un método prospectivo denominado Delfi, que
define al grupo de trabajo como un grupo de expertos en la temática a tratar, en este caso el
tema central fue la selección de los elementos del TASCO, en especial proveedores y
propietarios. Se dio a los expertos una lista de opciones y con base en sus respuestas se llegó a
la conclusión que se refleja en el documento.
7.1.2 FASE II: Identificar procesos – Ciclo de vida del negocio
7.1.2.1 ETAPA 1: SITUACIÓN ACTUAL DEL NEGOCIO
Esta etapa tiene como objetivo identificar la situación actual del negocio desde su “razón de ser”
hasta los procesos, actividades y sistema de valor de la organización o unidad de negocio.
7.1.2.1.1 IDENTIFICACIÓN DE LOS PROCESOS7 DEL NEGOCIO
Una vez se ha comprendido la “razón de ser” del negocio, se hace la definición de los procesos que
realiza la organización para cumplir con su misión y visión o para lograr la transformación. Para
este caso de estudio se ha trabajado con UML para la visualización y entendimiento de los procesos
7 Un proceso es una cadena de actividades acopladas, dirigidas a producir una salida en particular. Un proceso está constituido por fases consecutivas en la elaboración de un producto.
MISC-03-1-2
72
que se siguen en el interior del departamento y la carrera de Ingeniería de Sistemas. Ver Anexo 1:
Procesos de la Carrera de Ingeniería de Sistemas.
El levantamiento de procesos es una actividad compleja y de tiempo, si se tiene en cuenta que
muchos de los procesos pueden depender de actores externos al negocio que se está analizando. En
el caso de estudio, los actores externos identificados son los departamentos como proveedores de la
docencia que las Carreras requieren para la ejecución de su plan de estudio. Por otra parte, entidades
acreditadotas, el ICFES, entidades de préstamos y financiación de matrículas son actores externos
que también intervienen en los procesos de la carrera de forma directa o indirecta.
La definición de actividades y procesos de la carrera fue apoyada desde el proyecto ORBIS, lo que
permitió no sólo ver la carrera de Ingeniería de Sistemas sino todas las carreras de la facultad de
ingeniería en conjunto, lo que abrió el panorama para la definición del sistema de valor.
Dentro de las principales problemáticas halladas en esta fase se encuentra, la dificultad que se
generó al tratar de identificar procesos en una entidad eminentemente orientada a funciones. Este
inconveniente se pudo superar, ya que el proyecto ORBIS había hecho el levantamiento de la
información y construido algunos de los documentos de procesos que fueron utilizados para este
proyecto. Es claro también, que se podría haber hecho uso de la guía para organizaciones
orientadas a funciones, sin embargo, este paso no es transparente para el resto de las fases de la guía
ya que limita en parte la identificación de actividades granulares de la organización o unidad de
negocio.
7.1.2.1.2 DEFINICIÓN DEL SISTEMA DE VALOR.
Inicialmente deben detectarse las actividades que la Carrera de Ingeniería de Sistemas realiza, tanto
a nivel interno como externo. Para determinar estas actividades se da respuesta a las siguientes
preguntas:
¿Cual es el core del negocio?
MISC-03-1-2
73
Definido en la fase de contextualización. Se aclara que no es el core de la Universidad, sino
el de la Carrera de Ingeniería de Sistemas y corresponde específicamente a la
transformación del TASCOI: Adquirir, apropiar, difundir y generar conocimiento en los
bachilleres entregados por la sociedad, la industria contratante y los profesionales.
¿Cuáles son las actividades y/o procesos que generan los mayores ingresos a la empresa?
La matrícula de los estudiantes nuevos y antiguos
¿Qué infraestructura se está utilizando para desempeñar las actividades que generan los mayores
ingresos a la compañía?
• Los sistemas de información que provee la unidad de admisiones y registro
• Las sicólogas que colaboran en el proceso de entrevistas de neojaverianos
• La oficina de promoción institucional
• Los servicios docentes de los diferentes departamentos que prestan servicios a la carrera
(laboratorios)
• Los servicios de los docentes que colaboran en el proceso de entrevistas
¿Cuáles son las personas responsables de realizar estas actividades?
• Director de Carrera
• Auxiliar de Carrera
• Docentes departamentos
• Secretarias
Para organizar y detectar cuáles son las actividades que desempeña la organización, se desarrolló la
matriz “Definición de las actividades de la Organización” que se encuentra en el Anexo 4, y se
alimenta de los procesos (actividades) ya identificados en la etapa de definición de procesos.
De esta matriz se obtuvieron las siguientes actividades:
1 Creación de currículo
2 Mercadeo del programa
3 Selección de nuevos estudiantes
4 Seguimiento ciclo académico de estudiantes
MISC-03-1-2
74
5 Actualización de Currículo
6 Seguimiento de egresados
7 Actividades de acreditación
8 Solicitud de servicios docentes a los departamentos
9 Pago de servicios a los departamentos
10 Control y gestión de la carrera
Ahora se establece el impacto de las actividades (procesos) de la empresa sobre los Componentes de
la Misión . Estos componentes fueron definidos en la etapa de contextualización. El impacto es una
medida de la intensidad en que una actividad genera influencia o, en otras palabras, apoya o no a la
misión. Si una actividad es estratégica, deberá apoyar varios de los componentes de la misión, o
unos pocos pero con impacto alto.
Debido a que se ha definido un grupo de trabajo, y que diligenciar la matriz de actividades Vs.
Componentes de la misión no debe ser actividad de una sola persona, se vuelve a utilizar el método
Delfí, con el fin de obtener un valor más confiable.
El cruce de las Actividades de la Carrera de Ingeniería de Sistemas y los Componentes de la Misión
que han sido extraídos de la primera parte de la Etapa de Contextualización, se aprecian en el
Anexo 5, en la Matriz de Actividades Vs. Componentes de la Misión. De esta matriz se determina el
nivel de impacto por medio de sumatorias por componente de misión y de actividades,
convirtiéndose en la base para la siguiente fase, el resultado útil para alimentar la fase III es el
resultante de la sumatoria de las filas.
Resultados de la aplicación de la Fase II de la guía: Esta fase se alimentó de la definición de
procesos realizada en la fase anterior, sin embargo, es importante aclarar que algunas de las
actividades aquí identificadas, como es el caso de las actividades de acreditación, no se encuentran
aún definidas en los procesos de la Carrera, pero fueron identificadas por el grupo de trabajo como
importantes.
En cuanto a los componentes de la misión, se pudo haber trabajado con los Factores Críticos de
Éxito de la Carrera, sin embargo, estos no han sido definidos en concreto mientras que la misión, a
MISC-03-1-2
75
pesar de ser de toda la universidad, refleja mucho mejor las estrategias y objetivos de la unidad de
negocio analizada.
A partir de la construcción de las respuestas a las preguntas hechas en esta fase se conoce la
organización y se identifican actividades que, a simple vista, haciendo uso de métodos tradicionales
como la identificación de procesos no se podrían identificar.
Hasta esta fase se han utilizado dos de las etapas de la guía metodológica para la identificación de
cadenas de valor, estas dos etapas y las dos fases de la guía metodológica para la construcción de
Web Services, se pueden usar en cualquier tipo de trabajo sobre organizaciones para entender el
negocio, sus procesos, actividades y actores.
7.1.3 FASE III: Construcción de la Cadena de Valor
Esta fase se identifica la cadena de valor interna y extendida, que se construyen haciendo uso de la
guía metodológica para identificar cadenas de valor.
7.1.3.1 DEFINICIÓN DE LAS ACTIVIDADES PRIMARIAS
Una vez aplicados los pasos definidos en la guía, usando los resultados de la matriz de Actividades
Vs. Componentes de la Misión (ver Anexo 5), se obtiene el siguiente resultado en la definición de
las actividades primarias.
CLASIFICACIÓN DE LAS ACTIVIDADES PRIMARIAS
No ACTIVIDAD LOGÍSTICA DE ENTRADA OPERACIÓN LOGÍSTICA
DE SALIDA MERCADEO POST VENTA
1 Creación de currículo X
2 Mercadeo del programa X
3 Selección de nuevos estudiantes X
4 Seguimiento ciclo académico de estudiantes
X
5 Actualización de Currículo X
6 Seguimiento de egresados X
MISC-03-1-2
76
7 Solicitud de servicios docentes a los departamentos
X
8 Grado Estudiantes X
Matriz No.1 4 : Aplicación de la Clasificación de las actividades primarias
Aunque el proceso de gestión y control de la carrera aparece con un puntaje superior que lo
clasifica como actividad primaria (60 puntos), al momento de clasificarlo no fue claro el punto de
ubicación, por lo cual pasa a ser clasificada como una actividad de soporte. Las demás actividades
de puntaje superior, fueron identificadas fácilmente en cada una de las actividades primarias.
7.1.3.2 DEFINICIÓN DE LAS ACTIVIDADES DE SOPORTE
Una vez aplicados los pasos definidos en la guía, de los resultados de la matriz de Actividades Vs.
Componentes de la Misión (Ver Anexo 5), se obtiene la definición de las actividades de soporte.
CLASIFICACIÓN DE LAS ACTIVIDADES DE SOPORTE
No
ACTIVIDAD INFRAESTRUCTURA
RECURSOS HUMANOS TECNOLOGÍAS ABASTECIMIENT
O
1 Actividades de acreditación
X
2 Pago de servicios a los departamentos
X
3 Gestión y Control de la Carrera
X
Matriz No. 15 Aplicación de la definición de las actividades de soporte
7.1.3.3 DEFINICIÓN DE LA CADENA DE VALOR EXTENDIDA
La cadena de valor extendida (externa) está compuesta por la cadena de valor de los compradores,
proveedores y canales, es decir los actores de las diferentes relaciones de negocio que se pueden dar
dentro de la Carrera de Ingeniería de sistemas y otros socios de operaciones y/o negocio dentro y
fuera de la universidad.
A simple vista se identifican algunos de estos actores, como son los departamentos que prestan sus
servicios docentes a la carrera, la unidad de admisiones y registro, asesoría sicológica, Vicerrectoría
MISC-03-1-2
77
académica, decanatura académica y del medio universitarios. Al exterior de la universidad se
identifican otros actores como el ICFES, el CNA, Acofi, entre otras.
La importancia de la cadena de valor extendida radica en las relaciones que la empresa o unidad de
negocio pueda tener con aliados de negocio y clientes. Para la Carrera de Ingeniería de Sistemas la
importancia está en poder vislumbrar los actores externos y las relaciones que existen con cada uno
de ellos con el fin de establecer dichas relaciones ahora con la intermediación de las tecnologías de
información. Por otra parte, es importante generar nuevos negocios con estos aliados, que generen
diferenciación para la Carrera de Ingeniería de Sistemas con respecto a otras carreras de la
Universidad y otras Universidades.
La definición de la cadena de valor extendida se encuentra en la siguiente matriz:
MISC-03-1-2
78
Matriz No. 16 Definición de la cadena de valor extendida para la Carrera de ingeniería de Sistemas
DEFINICIÓN DE LA CADENA DE VALOR EXTENDIDA
No. R
ELAC
IÓN
RELACIÓN No DESCRIPCIÓN PRODUCTO/ SERVICIO OFRECIDO
PRODUCTO/ SERVICIO RECIBIDO
CA
DA
CU
ÁN
TO
TIPO D
E RELA
CIÓ
N
CÓMO
IMPA
CTO
ESTR
ATÉG
ICO
S11
Se solicita a losdepartamentos dictar una asignatura
Una asignatura o conjunto de ellas dictadas por el docente Semestral B2B
Se solicitan los servicios de Director de Carrera a Directores de Departamento, quienes a su vez coordinan con los jefes de sección 10
S12 Pago de servicios docentes
Se genera el pago por lasasignaturas dictadas Semestral B2B
El departamento que ha prestado el servicio emite cuenta de cobro para que le sea cancelada mediante traslado presupuestal 8
R1 Departamentos
S13 Asignación jurados trabajo de grado
Se asigna un jurado por grupo de trabajo de grado Semestral B2C Se asigna un jurado por grupo de trabajo de grado 8
R2
Entidades acreditadotas nacionales y/o internacionales
S21
Proceso de acreditación
Se asignan los pares y ejecuta proceso de acreditación
Varía B2G Se generan todos los procesos y actividades propios de laacreditación, tanto de entidades acreditadotas nacionales comointernacionales.
10
R3 Universidad
S31 Proceso de auto evaluación
Se asigna recurso y establecen los criterios para autoevaluar
Varía B2G Con el apoyo de la vicerrectoría académica y los delegados de lamisma para asegurar el proceso.
10
R4 ICFES S41 Proceso de registro y
renovación de la carrera
Se registra o renueva el registro ante el ICFES
Varía B2G Con el apoyo de la vicerrectoría académica y los delegados de lamisma para asegurar el proceso se registra o renueva el registro dela carrera.
10
R5 ICETEX
S51 Información Préstamos educativos
Se informan los préstamos que tienen los estudiantes con la entidad
Semestral B2G Se informa por intermedio de la Vicerrectoria del medio universitario al ICETEX los préstamos que tienen los estudiantes con la entidad
4
R6 REGISTRO
S61 Información Estado Académico
Se informa su estado académico de acuerdo al registro de notas
Varia B2B Por medio del certificado de notas y de informes verbales, el estudiante se entera de su estado académico para la permanencia en la universidad.
10
MISC-03-1-2
79
Comentarios generales sobre la identificación de las cadenas de valor con base en la guía
metodológica
La identificación de la cadena de valor usando la guía metodológica es transparente para el usuario,
pues se fundamenta en el levantamiento de procesos de la organización. Es importante anotar que
no es suficiente con conocer los clientes, proveedores y aliados del negocio al momento de construir
la cadena de valor extendida, ya que al verificar el tipo de relación que se establece entre los actores
y la organización y la forma en que se desarrollan los procesos es posible ver el flujo de
información, los pasos redundantes del proceso y los posibles problemas que se presentan.
Otro de los valores agregados al construir la cadena de valor extendida está en identificar la
periodicidad o frecuencia con la que se generan las relaciones, pues esta también será una forma de
medir el impacto de mejorar los procesos actuales.
7.1.3.4 ETAPA 2: DEFINICIÓN DE LAS NECESIDADES INFORMÁTICAS.
En esta fase de describen las necesidades informáticas de la Carrera de Ingeniería de Sistemas, y se
otorga una prioridad de acuerdo con las estrategias de la organización.
7.1.3.4.1 EVALUACIÓN Y PRIORIZACIÓN DE LAS NECESIDADES INFORMÁTICAS.
Para realizar la evaluación y la priorización de las necesidades informáticas se desarrolló la matriz
de Evaluación y Priorización de las Necesidades Informáticas. De esta matriz se obtiene un listado
de necesidades de información, aunque aún no se habla de tecnologías para cubrir esas necesidades.
Esta matriz y su desarrollo se observa en el Anexo 6
Algunas de estas actividades han tratado de ser resueltas por algunas herramientas tecnológicas,
pero la gran mayoría de ellas se encuentran sin solución y se trabajan en forma manual, o
simplemente no se llevan a cabo.
MISC-03-1-2
80
La prioridad para solucionar estas necesidades se asignan teniendo presente el impacto estratégico
de suplir esta necesidad en la organización. Para el caso de estudio, la prioridad asignada a cada una
de las necesidades informáticas detectada se encuentra en el Anexo 7.
7.1.3.5 ETAPA 3: INCORPORACIÓN DE LAS TECNOLOGÍAS DE INFORMACIÓN
(WEB SERVICES & OTRAS)
En esta etapa se detectaron cuáles eran las tecnologías de información que podrían satisfacer las
necesidades informáticas de la carrera.
Para la selección de la tecnología de información se utilizó la descripción de tecnologías del
Anexo 2, y se identificaron posibles alternativas tecnológicas para solucionar las necesidades
informáticas.
Se detectó que la relación de necesidad a tecnologías es de uno a muchos, ya que pueden existir
varias tecnologías para satisfacer una necesidad, por otra parte y como se presenta en el anexo
Esta etapa es algo subjetiva, ya que identificar las tecnologías que se ajustan a las necesidades de la
empresa o unidad de negocio no es transparente. Por otra parte, al iniciar un proceso de
incorporación de tecnología no sólo se cuenta con el deseo de incorporar la mejor, sino también
con la realidad del presupuesto, los sistemas heredados, entre otros tropiezos posibles.
Lo obtenido en esta Etapa es entonces sólo una pequeña muestra de las posibilidades de trabajo con
las tecnologías de punta, pero es fácilmente llevable a otras tecnologías.
Para el caso de estudio, la relación entre las tecnologías de información y las alternativas de
solución se encuentra en el Anexo 8.
De acuerdo con los resultados de las densidades, las alternativas tecnológicas a implantar según su
cubrimiento de necesidades son:
MISC-03-1-2
81
Web Services
CRM
ERP
Data Warehouse
E-Commerce
E-Commerce reúne varias de las alternativas tecnológicas presentadas aquí, lo que le da una
ventaja, sin embargo es necesario validar la factibilidad de implantación, para lo cual es importante
no sólo para la tecnologías de información aquí presentadas, sino para todas, verificar presupuesto,
compatibilidad con tecnologías actuales, y si es posible, tener un estudio prospectivo de las
tecnologías que permita hacer una previsión del futuro (planeación prospectiva).
7.1.3.6 ETAPA 4: SELECCIÓN DE LA ESTRATEGIA DE ADQUISICIÓN
La aplicación de esta fase debe ser opcional, ya que aunque se determinen cuáles son las tecnologías
de información que satisfacen las necesidades de la Carrera, es importante aclarar que la estrategia
para adquirir, operar y mantener dichas tecnologías están sujetas a las disposiciones de la
administración central de la universidad, y por tanto lo esbozado en la siguiente matriz es una
sugerencia.
Puede tener una sola estrategia para toda la organización, o definir estrategias de acuerdo con las
tecnologías que ha definido para su organización.
Se recomienda entonces comprar un producto estándar que cubra la mayoría de las necesidades
informáticas y luego hacer las adaptaciones de software necesarias, estas modificaciones y el
mantenimiento en general del software lo haría la empresa proveedora del software, por medio de
un esquema de outsourcing, La operación y soporte se realizaría con personal de planta y
outsourcing.
Para cada una de las tecnologías se puede tener una estrategia diferente, pero como recomendación
lo ideal es tener una sola estrategia para todo el portafolio.
MISC-03-1-2
82
7.1.4 FASE IV: Descubrir posibles Web Services en la cadena de valor
Para descubrir estos puntos se utiliza la información de la matriz de cadena de valor extendida del
numeral 8.1.3.3, usando para ello los aspectos clasificados como B2B, B2E y B2G.
Por otra parte, y de acuerdo con el caso de estudio, y con base en la información extraída de la
matriz de la cadena de valor extendida y de los documentos de procesos8 y cadenas de valor9 de las
diferentes unidades académicas, aunque se hace énfasis en la cadena de valor de la Carrera de
Ingeniería de Sistemas, además de la experiencia vivida por el grupo de trabajo del proyecto
ORBIS10, se analizan las funcionalidades e información requeridas por diversas aplicaciones que
pueden ser cubiertas mediante el uso de los Web Services.
Haciendo uso de la matriz de Soluciones – Entidades tanto para aplicaciones nuevas como
aplicaciones heredadas, y verificando las funcionalidades e información requerida por la Carrera de
Ingeniería de Sistemas (Ver Anexo 3), se obtienen los siguientes resultados:
8 Ver análisis de procesos de la Facultad de Ingeniería en el Anexo 1 9 Las cadenas de valor se obtiene con base en la guía metodológica para la construcción de las mismas. 10 ORBIS. Proyecto de la Facultad de Ingeniería de la Pontificia Universidad Javeriana, para el rediseño de procesos y automatización de los mismos.
MISC-03-1-2
83
Matriz No. 17. Entidades usadas recurrentemente por las aplicaciones definidas para la
carrera de ingeniería de sistemas
No.
Sol
ució
n
SOLUCION
Info
. Est
udia
nte
Info
. Mat
eria
s
Info
. Doc
ente
s
Info
. Es
tadí
stic
a nu
evos
est
udia
ntes
Info
rmac
ión
de
acto
res e
xter
nos
1 Sistematización del currículo, prerrequisitos, correquisitos, créditos académicos y contenidos de las asignaturas. Actividades extrapensum deben ser controladas aquí.
5 M
2
Construcción de aplicativos que respondan en forma automática a inquietudes y consulta de prospectos. Sistema de minería de datos que analice poblaciones de estudiantes futuros bachilleres, colegios de mayor solicitud de ingreso y perfiles para el envío de correspondencia directa.
1 C
3 Sistema de control y evaluación de puntajes de ICFES, puntaje de entrevista y variables de decisión como colegio del cual egresa el aspirante. 1
C 1 C
4 Sistema de información que permita hacer seguimiento al estudiante desde su proceso de admisión. Control de su estado académico y formulación de estrategias correctivas.
5 C
5 Sistema de información para el control y gestión de las asignaturas de la carrera, prerrequisitos, correquisitos y actividades extra pensum. 3
C
6
Sistema de información que permita mantener el historial laboral de los egresados, colaborarles en la consecución de empleos y convocarlos a eventos de la universidad. Sistema que facilite la promoción de posgrados.
3 C
7 Sistema de información que facilite la administración de solicitudes de cursos, y el control de los mismos.
5 C
8
Sistema de Información que permita la gestión y control de la carrera mediante indicadores y estadísticas, y que facilite la toma de decisiones. Se alimenta del sistema curricular . Adicionalmente deberá permitir la definición de los indicadores de acreditación y la generación de las estadísticas de los mismos. Este sistema se alimenta de todos los demás construidos.
3 C
3 C
3 C
3 C
9 Sistema de cobro y traslado presupuestal entre departamentos y carreras de acuerdo con los servicios académicos prestados. 3
C
10 Sistema que permita obtener de los diferentes actores involucrados en el proceso de grados, los paz y salvos, el estado académico y financiero. 5
C
MISC-03-1-2
84
Si se suman las frecuencias de utilización se obtiene que para las aplicaciones nuevas, la entidad
que más se trabaja es la de Materias, seguida por la de estudiantes. En ninguno de los dos casos se
hace creación de datos (M), sólo se generan consultas sobre los mismos.
Ahora se aplica el mismo proceso sobre los sistemas que ya maneja la Carrera de Ingeniería de
Sistemas y en general la Facultad de Ingeniería.
Nombre del Sistema DESCRIPCION SISTEMA
Info
. Est
udia
nte
Info
. Mat
eria
s
Info
. Doc
ente
s
Info
. Es
tadí
stic
a nu
evos
est
udia
ntes
Info
rmac
ión
de
acto
res e
xter
nos
Laborad
Sistema para la administración de los recursos de laboratorios de la facultad de Ingeniería
5 C
3 C
3 C
Práctica Sistema para la administración de la información de proyectos de práctica social y estudiantes que cursan la asignatura, con su correspondiente empresa asignada.
3 C
1 C
1 C 3
C
Consejería Sistema de Información para administración de los estados académicos de los estudiantes, así como de su hoja de vida.
5 C
5 C
Nómina
Sistema de información para administrar datos relacionados con seguridad social, hojas de vida de los docentes, publicaciones, títulos, experiencia laboral y docente, categoría salarial (hora cátedra) y escalafón de profesores de planta.
3 C
Votaciones Votación en línea para elección representantes a consejos académicos
1 C 1
C
Matrículas (RAI) Registro Académico Integrado
Sistema de matrículas de estudiantes. 5 C
5 C
Consultas en línea Consulta de listas de clase y de horarios de estudiantes. Consulta de matrices de conflicto.
5 C
5 C
Matriz No. 18. Entidades usadas recurrentemente por las aplicaciones legacy que apoyan las
labores de la carrera de ingeniería de sistemas
Toda la información anterior es importante para varias aplicaciones. Una vez analizadas las
cadenas de valor de Departamento, Carrera y los procesos de la Facultad, se encuentra que la
información que se solicita con mayor frecuencia es la de estudiante-materia: estudiante, qué
materias está viendo, promedio, créditos aprobados, qué materias vio (para chequear prerrequisitos).
MISC-03-1-2
85
Dependiendo de la priorización de las necesidades de información, se determina aquí que el Web
Service de apoyo que debe desarrollarse en primer lugar, es del de Suministro de Información de
Estudiantes.
Resultados Generales de la aplicación de la Fase IV
De acuerdo con el marco teórico, todo lo que se define como aplicaciones B2B es susceptible de
construirse con Web Services, sin embargo, esta no es la única forma de hacer uso de ellos. En
ocasiones, al mirar al interior de la organización las aplicaciones legacy que han sido utilizadas en
los últimos años, se pueden encontrar puntos críticos en los cuales la misma información
(entidades) es utilizada en múltiples aplicaciones. Es allí donde se corre el riesgo de generar
inconsistencias y errores que pueden llevar a la organización a un caos informático.
Para nadie es oculto que las antiguas aplicaciones son silos de información y que es costoso generar
interfaces comunes que permitan actualizar datos desde múltiples sitos, en una sola fuente o base de
información.
Al aplicar esta fase de la guía, se obtuvo como resultado, una forma diferente de abordar los Web
Services y de potenciar su uso en la universidad. Nuevos negocios en la educación haciendo uso de
Web Services puede haber muchos, pero es más útil para una organización tan grande como esta,
hacer uso de los Web Services para los sistemas ya existentes, de esta forma se eliminan problemas
de inconsistencias y se eliminan las dependencias tecnológicas.
7.1.5 FASE V: Negocios Innovadores haciendo uso de Web Services
De los procesos de la organización y la identificación de actores o aliados de negocios, clientes y
proveedores se obtiene una lista de posibles negocios haciendo uso de Web Services. Esto lo que
nos indica es que el proceso de integración de las organizaciones con sus aliados y clientes, es la
principal fuente de negocios innovadoras haciendo uso de Web Services.
Potenciar la Inteligencia de Negocios (BI), por medio de estándares tecnológicos que garanticen
la integración con sistemas legacy, tanto al interior como hacia el exterior de las empresas, debe
ser la premisa para usar los Web Sevices.
MISC-03-1-2
86
Los Web Services no sólo nos colaboran en la optimización de los procesos B2B, sino que también
dan la oportunidad de crear nuevos negocios. Esta es una lista de posibles opciones de negocio que
se desprenden de los análisis hechos anteriormente:
1. Bolsa de empleo: conexión de las empresas que requieren personal y la bolsa de empleo
2. Cursos de educación continuada (Capacitación corporativa a la medida): aquí se pueden
trabajar Web Services a nivel de Extranet o Internet. Los clientes son las organizaciones
que requieren la capacitación, el servicio es provisto por un conjunto de universidades y/o
institutos, ya que el objetivo es dar una capacitación uniendo las fortalezas de cada una de
las instituciones.
3. Web Service para consulta de notas y referencias para aplicar a postgrados: este servicio
sería consumido por las diferentes instituciones a las cuales un aspirante aplique para ser
admitido en un postgrado. El servicio permitiría que la universidad consulte las notas y/o
referencias directamente de la universidad de la cual el aspirante es egresado.
4. Web Service entre las universidades y las editoriales, con el fin de buscar títulos para
cubrir las necesidades de textos para las asignaturas.
5. Web Service entre las bibliotecas de las universidades, institutos, bases de datos y centros
de investigación, consiguiendo así, que un usuario con un solo criterio de búsqueda obtenga
la referencia del libro o artículo que requiera para su investigación, sin necesidad de buscar
en cada sitio.
Actividades en el interior de una entidad educativa:
1. Construcción de aplicativos que respondan en forma automática a inquietudes y consulta de
prospectos.
2. Sistema de control y evaluación de puntajes de ICFES, puntaje de entrevista y variables de
decisión como colegio del cual egresa el aspirante: El web service, permitiría la consulta de
las notas del aspirante de cada uno de los colegios en los cuales haya estudiado, así como
también información del examen de estado y las veces que lo presentó. Se podría consultar
además, si el estudiante ha estado matriculado en otra universidad.
MISC-03-1-2
87
3. Web Service que facilite la administración de solicitudes de cursos, y el control de los
mismos: ingresando el tipo de curso y el área de conocimiento, se debería facilitar la
consecución de cursos en especial electivos.
7.1.6 FASE VI: Identificar Patrones de Negocio
Esta fase se verifica usando para ello los cuadros de trabajo sobre patrones de negocio que se
encuentran en la guía metodológica. Para cada una de las soluciones propuestas, se trabaja sobre
las matrices de patrones de negocio y se caracteriza cada aplicación de acuerdo con los patrones,
que a su vez ya se han definido determinando la viabilidad del uso de Web Services. Los pasos que
se siguieron para identificar los patrones aptos para cada solución fueron los siguientes:
1. Para cada solución se caracteriza el patrón de negocio o patrones de negocio que se ajusten a las
necesidades.
1. Una vez establecido el patrón o patrones de negocio, se debería establecer el patrón de
integración a utilizar, sin embargo, para este caso queremos trabajar con Web Services, por lo
cual no hacemos selección diferente a ésta.
2. Teniendo en cuenta los patrones de negocio, y el uso de Web Services como patrón de
integración, se procedió a identificar el patrón compuesto o de e-business, con el fin de
caracterizar globalmente el tipo de aplicación de e-business que se quería desarrollar. Los
resultados de esta clasificación son los siguientes:
MISC-03-1-2
88
TABLA 3: CARACTERIZACIÓN DE LOS PATRONES DE NEGOCIO Y DE E-BUSINESS PPARA LA CARRERA DE INGENIERIA DE SISTEMAS
Autoservicio Colaboración Agregación de Información Empresa Extendida
Patrón de e-business
Cursos de educación continuada (Capacitación corporativa a la medida)
Podría permitirse a los usuarios navegar por el sistema, para seleccionar contenidos y establecer su capacitación corporativa.
Las empresas podrían llegar a ofertar dependiendo de las necesidades y de las propuestas que se hagan.
Agregar información desde múltiples fuentes y generar un programa de curso unificado. Se requiera agregar, organizar y presentar información de varias fuentes de datos
Portal E-marketplace desde el lado del comprador (el comprador , en este caso la empresa tiene el poder de decisión)
Servicio que facilite la administración de solicitudes de cursos, y el control de los mismos
Fomenta la colaboración y compartir información de asignaturas entre departamentos y carreras. Puede llegar a manejar Workflow.
Integración de los datos de las diferentes unidades académicas, con el fin de hacer, las solicitudes de cursos semestrales, a cada departamento, en forma automática desde la planeación semestral.
E-marketplace
Interacción entre las universidades y las editoriales para consulta y consecución de textos y material bibliográfico
Se provee acceso a información bibliográfica, artículos, revistas, bases de datos documentales, almacenada en sistemas centrales del negocio y en bases de datos.
Se agrega, organiza y presentar información de varias fuentes de datos
Portal
Interacción entre las bibliotecas de las universidades, institutos, bases de datos y centros de investigación,
Se provee acceso a información bibliográfica, artículos, revistas, bases de datos documentales, almacenada en sistemas centrales del negocio y en bases de datos.
Se agrega, organiza y presentar información de varias fuentes de datos
Portal
Construcción de aplicativos que respondan en forma automática a inquietudes y consulta de prospectos
Se provee acceso a información sobre los programas académicos de la universidad. La información puede estar en diversos sitios y ser variada para los solicitantes.
Se agrega, organiza y presentar información de varias fuentes de datos
Portal
MISC-03-1-2
89
3. Una vez se cuenta con la clasificación global de la solución, miramos de nuevo la
aplicación de Web Services, teniendo para ello la matriz de verificación de Seguridad y
Transaccionalidad de Web Services, para identificar los negocios o servicios que pueden ser
implementados fácilmente con esta tecnología integradora.
Al aplicar la matriz de Seguridad y Transaccionalidad de los Web Services se tiene:
Matriz No. 19. Seguridad y transaccionalidad de las aplicaciones (negocios nuevos) para la
Carrera de Ingeniería de Sistemas
De la matriz anterior se obtiene una visión de las posibles alternativas de uso de Web Services.
Adicionalmente, de la caracterización con patrones de e-business, se pueden determinar los posibles
usos de Web Services para cada una de las necesidades informáticas.
Es importante tener en cuenta, que los patrones de negocio no nos sirven para generar ideas nuevas
de negocio. Los patrones se utilizan una vez se tiene un diseño de solución (formal o en palabras), y
luego se utilizan los patrones aplicados a esta solución.
Tipo de Transacciones Nivel de
Seguridad
Descripción del negocio Patr
ón d
e E
-bus
ines
s
Lec
tura
Lec
tura
/Esc
ritu
ra (S
in
gara
ntiz
ar a
tom
icid
ad
y co
nsis
tenc
ia d
e es
tado
s)
Lec
tura
/Esc
ritu
ra
(Gar
antiz
ando
at
omic
idad
y
cons
iste
ncia
de
esta
dos)
Aut
entic
ació
n
Enc
ripc
ión
Bolsa de empleo Portal- E-Mark. S S S
Cursos de educación continuada (Capacitación corporativa a la medida): E-Mark. S S S Servicio que facilite la administración de solicitudes de cursos, y el control de los mismos Portal S S S Interacción entre las universidades y las editoriales para consulta y consecución de textos y material bibliográfico Portal S S Interacción entre las bibliotecas de las universidades, institutos, bases de datos y centros de investigación,
Portal S S
Construcción de aplicativos que respondan en forma automática a inquietudes y consulta de prospectos Portal S S
MISC-03-1-2
90
La recomendación en este punto, es generar ideas innovadoras sobre nuevos negocios que la
empresa o unidad de negocio considere potenciales para el mejoramiento y generación de valor.
Estos nuevos negocios podrán o no, estar diseñados para usar Web Services, por ello la importancia
de visualizarlos, una vez diseñada la solución, haciendo uso de los patrones de negocio y patrones
de e-business, lo importante no será tratar de involucrar los Web Services a la fuerza, lo importante
es tener claridad de dónde y cuándo son útiles y lo más relevante, cuando podrán tener un ROI en el
menor tiempo posible.
7.1.7 FASE VII: Diseño, desarrollo e implantación de los Web Services
Cada uno de los elementos que componen el servicio deberán ser definidos en esta fase. Aquí se
diseñará el WSDL y el UDDI para el servicio del caso de estudio, el cual manejará la información
básica y académica de los estudiantes, sin importar que facultad, carrera, o instancia de la
universidad lo requiera.
Por no estar dentro del alcance del proyecto actual, se ha dejado la implementación fuera de este
documento, únicamente se tiene una breve descripción de lo sucedido en el proceso de
implementación que se ha llevado a cabo.
Para el caso de estudio, se trabajan las pruebas desde los servidores del proyecto ORBIS, cuya base
de datos está sobre ORACLE, adicionalmente, las aplicaciones se han construido con PL/SQL,
Java, Oracle Forms, entre otras.
La siguiente figura presenta el esquema que se maneja ORBIS para los sistemas de la facultad de
ingeniería hoy en día:
MISC-03-1-2
91
ActualizaciónActualización
SistemaLaboratorios
SistemaPrácticas
SistemaNómina
Sistema1
SistemaN
ORACLEORACLEStoredStoredProcedureProcedure
RA
IR
AI
Registro A
cadémico Integrado
Registro A
cadémico Integrado
SQL Nativo OracleSQL Nativo Oracle
SQL Nativo Oracle
SQL Nativo Oracle
SQL Nati
vo O
racle
Actualización periódicaActualización periódica
ORBISORBISFACULTAD INGENIERIAFACULTAD INGENIERIA
HOYHOY
PL/SQLPL/SQL
JAVAJAVA
JAVAJAVA
ASPASP
OTROSOTROS
Acoplamiento válido Acoplamiento válido sólo cuando es sólo cuando es OracleOracle
Figura 12: Esquema de las aplicaciones de la Facultad de Ingeniería hoy en día
Todos los sistemas que se tiene en la actualidad ORBIS hacen uso de SQL nativo ORACLE para
consultar las bases de datos, en especial la base de datos del Registro Académico Integrado RAI.
Actualmente, y por disposiciones administrativas, la base de datos del RAI sólo puede ser accedida
para consultas, además se debe crear una vista que en el gráfico se ha llamado “Actualización “, con
el fin de tener allí una réplica de la información relevante para las consultas y procesos de los
diferentes sistemas manejados por ORBIS. Esta vista se actualiza sin periodicidad definida, lo que
genera inconsistencias de datos entre la información del RAI y la vista.
Hoy hablamos de una base de datos como ORACLE, y aplicaciones que se han desarrollado en
diferentes lenguajes como PL/SQL y Java entre otros, con lo cual hacer uso de la base de datos se
traduce en uso de SQL Nativo.
La llegada de PeopleSoft como sistema general, académico y administrativo, de la universidad
cuestiona una serie de cambios que se debe realizar sobre las aplicaciones existentes no sólo en
ORBIS, sino en general en la universidad. Qué pasa en el momento en que la información no esté
almacenada en una base de datos ORACLE, sino en cualquier otro tipo de infraestructura? Si es un
MISC-03-1-2
92
manejador de base de datos como INFORMIX o SYBASE no se tendrían que hacer cambios pues
el SQL Nativo sería apropiado en este caso. Pero en el caso de aplicaciones empresariales ERP
(Enterprise Resource Planning) como SAP o PeopleSoft, sistemas CRM o SCM, o con nuevas
tecnologías, sistemas heredados (legacy), la información estará en sus propias bases de datos, y será
necesaria la reconstrucción de las consultas (Querys) para obtener la información que se requiera
según las consultas y estructura de la infraestructura a trabajar.
Por otra parte, tenemos este caso de ORBIS, pero otras facultades tienen su información en diversos
sistemas que van desde hojas en Excel y aplicaciones en Visual Basic, hasta aplicaciones un poco
más robustas también en ORACLE.
Por lo expuesto anteriormente, y revisando las necesidades recurrentes de información obtenidas del
análisis de la cadena de valor de la Carrera de Ingeniería de Sistemas, y teniendo en cuenta que la
información del estudiante es la más solicitada para cualquier tipo de operación o consulta, se
diseñaron dos pequeños Web Services que sin importar el lenguaje en que esté escrita la aplicación
que requiera la búsqueda de los datos, ni tampoco en que tipo de almacenamiento se encuentre la
información permitirá la consulta.
El nuevo modelo haciendo uso de Web Services se presenta aquí:
MISC-03-1-2
93
Cualquier InfraestructuraCualquier Infraestructura
SistemaLaboratorios
SistemaPrácticas
SistemaNómina
Sistema1
SistemaN
••Base de Datos RelacionalBase de Datos Relacional••ERPERP••CRMCRM••SCMSCM••Sistemas Sistemas LegacyLegacy••Nuevas TecnologíasNuevas Tecnologías
Web Web ServiceServicePL/SQLPL/SQL
JAVAJAVA
JAVAJAVA
ASPASP
OTROSOTROS
Web
Web Service
Service
Figura 13: Propuesta del esquema de las aplicaciones de la Facultad de Ingeniería con Web
Services
Aquí hemos eliminado el problema de la consulta sobre el sistema, colocando un Web Service entre
las aplicaciones y la infraestructura de la organización.
Para este caso de estudio, el Web Service se coloca entre las aplicaciones ya desarrolladas en
ORBIS y la base de datos actual de ORACLE, pero se deja constancia de que esta misma interfaz
WSDL, servirá en el momento en que entre en funcionamiento People.Soft. De esta forma se
garantiza un bajo acoplamiento de aplicaciones.
7.1.7.1 Cálculo del ROI para el caso de estudio
Este proyecto no tiene un desarrollo significativo de casos de Web Services, sin embargo, para
efectos de pruebas se ha tomado como caso el Web Service de estudiantes que sirve como
MISC-03-1-2
94
consolidador de múltiples fuentes de información heterogéneas en la Universidad. Como se vio en
el numeral 7.1.4 la consulta de información de estudiantes es recurrente.
Teniendo entonces el Web Service identificado y utilizando porcentajes y valores definidos con un
grupo de desarrolladores del Departamento de Ingeniería de Sistemas de la Universidad, se calcula
el ROI.
ROI =[ (Beneficios Monetarios (Tangibles e intangibles) – Costo de usar la tecnología de Web Services) /
Costo de usar la tecnología de Web Services ] x 100
De acuerdo con la guía metodológica y específicamente con lo relacionado con el ROI se han
determinado cuatro aspectos sobre los cuales se harán las mediciones para el cálculo. Cada uno de
estos aspectos están desglosados y calculados así:
1. Costos y Gastos
Descripción Valor (pesos)
Requerimientos de Hardware
Dell Precision 450 Procesador Intel® Xeon™ 2.40GHz, Caché de 512K, Español (45D24S) MEMORIA: 1GB DDR SDRAM (4 DIMMs) MEMORIA: 1GB DDR SDRAM (4 DIMMs). ATI,RADEON VE,VGA,1 OR 2 MONITOR,WS450 Microsoft® Windows XP® Professional, Español,, disco duro 36GB,HD,S,U320,1IN,15K,FOR PERC3,WS450 48X CD-ROM, garantía de 3 años.
$ 7`500.000
Requerimientos de Software
Se seleccionó el framework Idoox, pero es posible usar cualquiera de los existentes en el mercado. .Net, Sun One, Extend de Novell, entre otros. Los precios del framework son variables. Para el caso de estudio el framework seleccionado es de uso libre en las entidades educativas, pero es necesario adquirir la licencia profesional si se pone en producción.
$25.000.000
Requerimientos en capacitación
Es recomendable que el grupo desarrollador conozca las herramientas que se van a trabajar, en el caso de estudio se requería de Java pues se usó Idoox, por lo tanto no se requiere de capacitación, que en promedio por desarrollador es de $3´000.000.
·3`000.000
Requerimientos en ancho de banda de la red
Si se utiliza el ancho de banda de las red interna de la universidad, por lo que no es necesario invertir en ampliación del canal. Se ha contemplado un valor mensual de U$250 por el alquiler del canal a TRM de $3`000
$750.00
Herramientas de monitoreo:
Muchas de las herramientas que ya existen en el mercado poseen sus propias herramientas de monitoreo. En el caso de
0
MISC-03-1-2
95
estudio no es necesaria la adquisición de herramientas para este fin.
Costos operacionales, de soporte y de consultoría
Con el fin de obtener los mejores beneficios en el desarrollo y puesta en marcha de este servicio, es recomendable contratar la asesoría de un consultor, que colabore en el proceso de instalación del software. En el caso de estudio, por ser una entidad académica, se cuenta con el personal entrenado para esta labor. Suponiendo que el experto que colaboró en este proceso cobrara U$250 por hora, a una TRM de $3000, y si se han trabajado 20 horas (sin incluir soporte) se obtiene el valor que aparece a la derecha.
$15, 000.000
Total Costos y Gastos $51`250.000
2. Beneficios Técnicos Descripción Valor (pesos) Automatización del desarrollo de software
Ahorro en términos de horas-hombre de desarrollo, al hacer uso de los Web Services, traducido en pesos. Un desarrollador de sistemas Web Tradicionales gasta una relación de 5 horas más por cada hora que se demora un desarrollador de Web Services11. De acuerdo con el cálculo de costos y gastos se tienen 20 horas de trabajo que utilizó el desarrollador del Web Service se multiplica por 5 en un desarrollo web normal, lo que nos da 100 horas, a U$250 hora se tiene $75`000.000. Si el costo del desarrollo se calculó en $15`000.000 el ahorro resultante es de: $60`000.000
$60`000.000
Terminar con la duplicación de código de software y aumentar la reutilización, usando para ello integración basada en estándares, con aplicaciones y administración de procesos de negocio
Si cada facultad desarrollara su propia interfaz con sus sistemas actuales y el Sistemas central, invertiría en promedio $4´000.000 . Siendo 19 facultades y sin tener en cuenta que algunas comparten sistemas de información, el beneficio percibido al integrarse mediante Web Services dónde sólo se debería hacer una pequeña adecuación para el consumo del servicio se tiene el valor que aparece a la derecha. El costo de no hacer el desarrollo para cada facultad es de $0.
$76´000.000
Total Beneficios Técnicos $136´000.000
2. Beneficios Para el Negocio
Descripción Valor (pesos)
Productividad del usuario final
No hay interfaces con el usuario final. Sin embargo, actualmente por cada una de las 19 facultades se envía una solicitud de la información de los estudiantes al la Subdirección de Recursos Informáticos, esta solicitud es procesada y se trabaja en batch para entregarla a cada
$4`560.000
11 Este dato fue obtenido con base en consulta a expertos desarrolladores de la Universidad Javeriana, Novell y Microsoft.
MISC-03-1-2
96
facultad. Si se tiene un salario promedio de $800.000, y si la persona invierte ¼ de su tiempo de trabajo diario en generar el reporte, el costo es de: $20,000 si la información se pidiera sólo una vez al semestre y desde una sola facultad, para las 19 facultades el costo es de $380.000. Debido a que esta información se solicita por lo menos en cinco oportunidades en un semestre (dos periodos por año) y dos veces en periodo intersemestral se tiene que el beneficio percibido al año es de:
Participación en negocios dinámicos y Actividades de negocio colaborativas
No aplica para el caso de estudio, por cuanto no se generan ni se participa en negocios dinámicos.
Mejor y más económico servicio al cliente
Aunque se reduce el tiempo al eliminar la generación de solicitudes por correo electrónico, telefónicas o en papel, esta cifra no es cuantificable en términos de dinero.
Total Beneficios Para el Negocio $4´560.000
Para el cálculo de los riesgos asociados al proyecto, verificamos el nivel de impacto que tiene cada
uno de los riesgos en la implementación del Web Service, y con base en los costos asociados a la
implementación se determina el valor de cada riesgo.
Riesgo Descripción Probabilidad de Ocurrencia
Costo12 (pesos)
Tecnología Nueva Poco servicio de herramientas y soporte
Es una tecnología nueva y aún poco probada, la aceptación de la misma por parte de la universidad es complicada. El costo en pesos en caso de ocurrencia de este riesgo es la suma del costo total del software de desarrollo (sólo para Web Services), el costo del desarrollo, consultoría y soporte, y el costo parcial de la capacitación (20%) pues no se pierde la totalidad de la misma. Sino sólo lo relacionado con la herramienta. No se incluye el hardware ni el ancho de banda, pues éstos pueden ser usados en otros sistemas.
30% $40´600.000
Estándares no maduros o no finalizados
Los estándares que soportan la tecnología aún están sin madurar, lo que hace complicado el manejo transaccional. En el caso del servicio implementado no hay transaccionalidad, sólo consultas.
0% $0
Seguridad La seguridad de la aplicación es fundamental para el servicio a prestar, si se tiene en cuenta que se está manejando información confidencial
50% $0
12 Este costo se calcula sobre el valor que se estipuló en costos de Software, por ser este el valor que más capital requiere para iniciar el procesos de desarrollo del Web Service, y por tanto el que generaría un mayor impacto en caso de fracasar el proyecto.
MISC-03-1-2
97
de los estudiantes y que no debe ser vista por más personas que las autorizadas para hacerlo. Se podría concluir que este valor no es cuantificable, en cuanto no existe en el reglamento ninguna cláusula que hable de confidencialidad de la información del estudiante. Esta información se resguarda pero no es 100% confidencial.
Total Riesgos $12`180.000
• Costos del proyecto incluyendo inversión de capital, labor de implementación,
administración y soporte operación y costos de contratación (A).
A= $51´250.000
• Beneficios del proyecto (técnicos y del negocio), incluyendo beneficios netos tangibles (B).
B= 136´000.000 + 4´560.000 = $140`560.000
• Riesgos del proyecto cuantificados como costos potenciales (C).
C=$12´180.000 Esta cifra representa el valor esperado de la ocurrencia de los
riesgos ya especificados.
Usando la fórmula se tiene:
ROI para Web Services = (B-A-C)/(A+C)*100
ROI Web Services Estudiante =
(140´560.000-51`250.000-12´180.000)/(51`250.000+12´180.000)*100=121,59%
Lo que se traduce en que por cada peso invertido en el desarrollo del Web Service, la universidad ve
reflejada la inversión en un beneficio neto de $1, 22 pesos.
MISC-03-1-2
98
8 CONCLUSIONES
Las conclusiones a este trabajo están divididas en varios ítems.
Aspectos Generales de los Web Services:
Definitivamente no estamos hablando de algo nuevo, los web services han existido desde hace
varios años aunque con nombres diferentes. La diferencia con lo que encontramos hoy en día está
en los estándares que soportan esta nueva forma de hacer integración, estándares que aun están
inmaduros pero que ya ofrecen un sinnúmero de posibilidades para hacer negocios dinámicos.
Los Web services son una herramienta poderosa para las organizaciones de hoy en día, ya que
generan ventaja competitiva. Esto se logra al integrar la cadena de valor interna con la cadena de
valor extendida por medio de software programático que, al no requerir la intervención de la mano
humana para su ejecución permanente, hace que la integración sea transparente para los negocios.
Integrarse con la cadena de valor extendida, especialmente con las entidades financieras y los
proveedores, genera una ganancia para las organizaciones en reducción de tiempo (horas/hombre).
En el caso de los proveedores, ya no es necesario tener personal dedicado a labores de revisiones
como; stock de inventarios o puntos de reorden para poder colocar un pedido de suministros,
tampoco es necesario hacer un barrido sobre un listado de proveedores para ubicar el más
económico y con menor tiempo de entrega, para ello, los web services (usando inteligencia de
negocios) hacen las negociaciones software-software, y colocan la orden.
Los proveedores de frameworks de web services que existen actualmente en el mercado, ofrecen
funcionalidades más al nivel de facilidades de desarrollo y publicación de servicios que valores
agregados como tal. Será exitoso el framework que logre eliminar o por lo menos aliviar las
MISC-03-1-2
99
deficiencias actuales que poseen los web services, en especial en el tema de transaccionalidad y
seguridad.
El lado negativo de los Web Services está en:
• Existen pocos directorios públicos UDDI. De aquí que hacer el servicio público y conocido
puede ser difícil. Se requieren estrategias de promoción del servicio, para darlo a conocer.
• El WSDL debe ser enriquecido para permitir más negociaciones programa a programa. Es
necesario que el WSDL incluya la habilidad de negociar pagos para la entrega de los
servicios, pues esta sería la forma en que los proveedores de Web Services podrían hacer
dinero.
• Se requiere mucho trabajo aún por parte de los comités de estándares para hacer confiable
el direccionamiento de mensajes, además de hacer las transacciones complejas seguras,
manejables y enrutables.
• En otras palabras, los estándares de Web Services necesitan ser más maduros,
particularmente en lo relacionado con seguridad de los ambientes transaccionales donde la
disponibilidad, confiabilidad y desempeño son consideraciones claves si un sistema está
siendo usado en situaciones computacionales de misión crítica.
Sobre la guía metodológica para construir cadenas de valor:
La guía fue probada en una entidad el sector académico, sin embargo, no es exclusiva de este sector
pues se ha construido en forma genérica para cualquier tipo de organización, o unidad de negocio.
La guía es una herramienta útil, pues desglosa el negocio y muestra sus necesidades informáticas,
dando las alternativas tecnológicas para su solución en forma independiente de los Web Services.
Por otra parte, la guía permite identificar las posibles relaciones B2B de la cadena de valor
extendida, para luego analizarlas en la guía metodológica para la identificación de Web Services.
Sobre la guía metodológica para la identificación de Web Services:
MISC-03-1-2
100
La guía es un apoyo importante en la identificación de Web Services, pero su uso no se limita
únicamente a esta tecnología. Aunque es la guía para la construcción de cadenas de valor la que nos
lleva a evaluar diversas tecnologías como alternativa de solución, con la guía para la identificación
de Web Services se obtiene un panorama completo del negocio y sus procesos, que al pasar por
patrones de negocio no nos lleva directamente a pensar en Web Services, sino también en un
conjunto de tecnologías integradoras que pueden satisfacer esta necesidad.
La guía es un conjunto de pasos que lleva al usuario a verificar la pertinencia de hacer uso de web
services en su negocio. Pasos, que se apoyan en una guía metodológica para identificar cadenas de
valor y necesidades informáticas, y que culminan con una validación cuantitativa en la cuál se
utiliza el modelo del ROI.
Aunque el tema de web services pertenece al campo tecnológico, la guía hace un recorrido por la
empresa, su contexto, estructura y demás factores que la caracterizan, para concluir con un
panorama general del uso de Web Services en negocios nuevos para la organización, pero
principalmente como apoyo y solución a problemáticas actuales de manejo de información en
aplicaciones legacy.
-Patrones e-business
Usar patrones es una forma sencilla de dar solución a problemas recurrentes, sin embargo, el uso de
patrones de negocio desde la filosofía propuesta por IBM es complejo y requiere de los ajustes
presentados en este documento para aplanar la estructura, y hacer más sencillo su uso.
Los patrones son una forma de caracterizar problemas recurrentes, por lo que el objetivo en esta
guía es llevar al diseñador de soluciones a encontrar la mejor forma de visualizar su aplicación.
Muchos modelos de negocio se han estudiado y validado, los más comunes como e-marketplace y
portales están en estos patrones, lo importante aquí es llegar desde estos patrones a encontrar cuál es
el Web Service que se puede implementar, para garantizar un verdadero e-business, donde las reglas
de negocio son reglas de software.
MISC-03-1-2
101
-Implementación de los Web Services
Sobre las métricas alrededor de los Web Services:
No hay una forma real de establecer, por lo menos actualmente, los beneficios recibidos al
implementar soluciones con Web Services, esto se debe principalmente a la juventud de la
tecnología, a la apropiación de los framework por unas pocas casas desarrolladoras de software y a
la falta de desarrollos o implementaciones a gran escala, que permita establecer comparaciones y
sacar estimados.
- Conclusiones Generales sobre la validación de las guías
Las conclusiones generales relacionadas con la validación de las guías se encuentran en el capítulo
7 de este documento, al finalizar cada una de las fases aplicadas. Sin embargo, lo más relevante de
presenta a continuación:
Al iniciar el proceso de contextualización del negocio aplicando la Fase I de la guía se tuvieron
algunos inconvenientes en la definición del TASCOI, en especial en la identificación de los
propietarios (O) y de los proveedores (S) de la Carrera de Ingeniería de Sistemas. Para poder llegar
a un consenso confiable sobre el tema, se utilizó un método prospectivo denominado Delfi, que
define al grupo de trabajo como un grupo de expertos en la temática a tratar, en este caso el tema
central fue la selección de los elementos del TASCO, en especial proveedores y propietarios. Se dio
a los expertos una lista de opciones y con base en sus respuestas se llegó a la conclusión que se
refleja en el documento. Una vez identificada la razón de ser de la Carrera de Ingeniería de Sistemas
se pudo hacer el trabajo de identificación de actividades y procesos.
Las ventajas de la guía en este punto, es la multiplicidad de fuentes para encontrar el core del
negocio, pues como se vio con el caso de estudio, es normal que una organización o una unidad de
negocio no cuente con una misión definida y detallada, por lo que optar por factores críticos de
éxito y TASCOI entre otras herramientas permite cumplir con el objetivo.
Uno de los posibles tropiezos al momento de hacer el levantamiento de procesos es encontrarse con
una organización orientada a funciones. En el caso de estudio se dio esta situación, pero se corrigió
rápidamente al hacer el levantamiento usando UML, lo que facilitó entender la organización y
MISC-03-1-2
102
colaboró en la transición del esquema de funciones a procesos, para así llegar a las actividades de la
organización.
Hasta la segunda fase del la guía metodológica para la identificación de Web Services, se utilizaron
dos de las etapas de la guía metodológica para la identificación de cadenas de valor, estas dos
etapas y las dos fases de la guía metodológica para la construcción de Web Services, se pueden usar
en cualquier tipo de trabajo sobre organizaciones para entender el negocio, sus procesos, actividades
y actores.
Un consultor de tecnología debe ser conciente de que su trabajo no es instalar “cajas”, por tanto la
guía ofrece una forma corta y sencilla de conocer la organización y entenderla para buscar y
comprender sus necesidades y ofrecer soluciones completas, desde la tecnología y desde el
negocio.
La identificación de la cadena de valor usando la guía metodológica es transparente para el usuario,
pues se fundamenta en el levantamiento de procesos de la organización. Es importante anotar que
no es suficiente con conocer los clientes, proveedores y aliados del negocio al momento de construir
la cadena de valor extendida, ya que al verificar el tipo de relación que se establece entre los actores
y la organización y la forma en que se desarrollan los procesos es posible ver el flujo de
información, los pasos redundantes del proceso y los posibles problemas que se presentan.
Otro de los valores agregados al construir la cadena de valor extendida está en identificar la
periodicidad o frecuencia con la que se generan las relaciones, pues esta también será una forma de
medir el impacto de mejorar los procesos actuales.
Con relación a la identificación de los posibles Web Services se podría decir que todo lo que se
define como aplicaciones B2B es susceptible de construirse con Web Services, sin embargo, esta no
es la única forma de hacer uso de ellos. En ocasiones, al mirar al interior de la organización las
aplicaciones legacy que han sido utilizadas en los últimos años, se pueden encontrar puntos críticos
en los cuales la misma información (entidades) es utilizada en múltiples aplicaciones. Es allí donde
se corre el riesgo de generar inconsistencias y errores que pueden llevar a la organización a un caos
informático.
MISC-03-1-2
103
Para nadie es oculto que las antiguas aplicaciones son silos de información y que es costoso generar
interfaces comunes que permitan actualizar datos desde múltiples sitos, en una sola fuente o base de
información.
Al aplicar la Fase IV de la guía, se obtuvo como resultado, una forma diferente de abordar los Web
Services y de potenciar su uso en la universidad. Nuevos negocios en la educación haciendo uso de
Web Services puede haber muchos, pero es más útil para una organización tan grande como esta,
hacer uso de los Web Services para los sistemas ya existentes, de esta forma se eliminan problemas
de inconsistencias y se eliminan las dependencias tecnológicas.
De lo anterior se puede concluir, que los Web Services se pueden convertir en un futuro en un
“puente” entre las diferentes aplicaciones de la organización y entre la misma y sus aliados de
negocio. Además, este puente será estándar y no se requerirá de nuevos desarrollos al momento de
cambiar las aplicaciones.
En cuanto a nuevos negocios haciendo uso de Web Services, lo importante es pensar en nuevas
aplicaciones o nuevos servicios que generen ventaja competitiva a la organización. Muy
seguramente al momento de pensar en estas aplicaciones, no se tenga presente aún la forma en que
los Web Services puedan ayudar en su construcción. Será necesario entonces generar un pequeño
diseño o una correcta especificación del servicio, con el fin de poderlo expresar en términos de
Patrones de Negocio y Patrones de Integración, para así poder generar modelos de negocio o
Patrones Compuestos. Sobre estos Patrones ya se tiene una especificación de la forma en que se
pueden construir haciendo uso de Web Services.
Es importante tener en cuenta, que los patrones de negocio no nos sirven para generar ideas nuevas
de negocio. Los patrones se utilizan una vez se tiene un diseño de solución (formal o en palabras), y
luego se utilizan los patrones aplicados a esta solución.
La recomendación en este punto, es generar ideas innovadoras sobre nuevos negocios que la
empresa o unidad de negocio considere potenciales para el mejoramiento y generación de valor.
MISC-03-1-2
104
Estos nuevos negocios podrán o no, estar diseñados para usar Web Services, por ello la importancia
de visualizarlos, una vez diseñada la solución, haciendo uso de los patrones de negocio y patrones
de e-business, lo importante no será tratar de involucrar los Web Services a la fuerza, lo importante
es tener claridad de dónde y cuándo son útiles y lo más relevante, cuando podrán tener un ROI en el
menor tiempo posible.
No todo lo que sea Web o B2B puede ser llevado a Web Services. Lamentablemente, estamos
hablando de una nueva tecnología, inmadura y con falencias en seguridad y transaccionalidad, es
allí donde verificar el nivel deseado en estos dos aspectos se convierte en factor indispensable para
la decisión.
Cada uno de los elementos que componen el servicio deberán ser definidos en la fase de desarrollo e
implementación de Web Services. Aquí se diseñará el WSDL y el UDDI para el servicio del caso de
estudio, el cual manejará la información básica y académica de los estudiantes, sin importar que
facultad, carrera, o instancia de la universidad lo requiera.
Pero antes de iniciar cualquier proceso de construcción, es importante hacer una validación
cuantitativa de las ventajas de desarrollar uno u otro Web Service. Para ello se recomendó medir
financieramente el impacto de usar Web Services, usando para ello el ROI.
En esta medición se presentaron varios problemas relacionados principalmente con la forma en que
se palpa o mejor, no se palpa, una aplicación Web Service, más aún cuando se utiliza como
integrador de aplicaciones al interior de la organización y no como un servicio o aplicación nueva.
Vale la pena reflexionar un poco sobre la forma adecuada de medir el impacto financiero de
introducir Web Services, posiblemente no sea el ROI la medida adecuada, pero por lo menos da una
visión preliminar y el cálculo se puede ajustar mediante cambios a las variables medidas aquí.
Uno de los principales inconvenientes en el cálculo del ROI se encuentra en los riesgos asociados a
esta nueva tecnología. Lo importante a tener en cuenta en este punto, es que el riesgo debe ser visto
como una probabilidad de ocurrencia y un costo asociado a que el riesgo ocurra. Medir o calcular
un árbol de decisión en este paso no es necesario, pues el valor calculado es la probabilidad de
ocurrencia por el costo, que se traduce en el “valor esperado”. Por otra parte, medir o cuantificar el
costo asociado al riesgo de seguridad de los Web Services dependerá del tipo de desarrollo hecho y
la confidencialidad de la información que maneje. En el caso de estudio, cuantificar el riesgo
MISC-03-1-2
105
asociado a seguridad de los datos de estudiantes no es trivial, pues auque la información es
confidencial no es medible o por lo menos no es sencillo, encontrar en pesos el perjuicio de que esta
información se divulgue.
- Proyectos futuros:
La etapa final de la guía metodológica para la identificación de Web Services, que corresponde a la
implementación del mismo, deberá se completada. Para ello se recomienda seguir con el proceso ya
iniciado en este documento, en el cual se propone una guía paso a paso para construir el WSDL y
publicar el servicio de acuerdo con las características propias de los UDDI.
Esta guía deberá se lo suficientemente genérica, de tal forma que no quede amarrada a ninguna de
las plataformas que actualmente dominan el mercado.
Establecer un esquema de métricas de software, como puntos funcionales o cocomo, o una
variación de Cocomo II, con el fin de poder medir y estimar el desarrollo de los Web Services.
Construir una herramienta sistematizada que permita generar de forma dinámica las tablas que
actualmente componen la guía metodológica para la construcción de cadenas de valor.
MISC-03-1-2
106
9 BIBLIOGRAFIA
[1] Aguado R.J. La cadena de valor virtual.
http://pp.terra.com.mx/~rjaguado/cadenas.html. Julio de 1995. Fecha de Consulta: Septiembre de
2002.
[2] Alvarez, Alejandro y Brum Cecilia. Gestión estratégica de costos asociada a la cadena de valor.
Universidad Católica del Uruguay Dámaso Antonio Larrañaga (UCUDAL).
http://usuarios.multired.com.uy/marcelo/index.htm. Enero de 2002. Fecha de Consulta: Octubre de
2002.
[3] Ayala Ruiz, Luis Eduardo y Arias Amaya Ramiro. El análisis de la cadena de valor.
http://www.3w3search.com/Edu/Merc/Es/GMerc081.htm. Fecha de Consulta: Mayo de 2002.
[4] Boar, Bernard H. Constructing blueprints for enterprise IT architectures. Editorial Wiley. New
York, 1999.
[5] Box, Don. Ehnebuske et all. Simple Object Protocol (SOAP) 1.1 W3C Note 08. Mayo 2000.
[6] Brittenham, Peter Web Services Development Concepts (WSDC 10).IBM Mayo 2001
[7] Chaparro, Hilda Nota técnica sobre Web Services. Abril de 2002. (No publicada)
[8] Clabby, Joe Web Services explained Solutions and applications for the real world. Prentice Hall
PTR. 2003.
[9] Downes Larry y Mui Chunka. Unleashing the Killer App. 1998. Harvard Business School Press.
http://www.3w3search.com/Edu/Merc/Es/GMerc081.htm. Fecha de Consulta: Mayo de 2002.
MISC-03-1-2
107
[10] Escorsa Castells, Pere. Tecnología e Innovación en la Empresa. 1997
[11] García, Alberto. Sistemas de Información, Planeamiento Estratégico y Análisis. Bogotá, 1994.
[12] Hailstone, Rob; Byron, Dennis; Hendrick, Stephen; Mayo, Sophie; McHale, Steve .Web
Services Adoption Timeline and Related Business Opportunities. http://www.idc.com Febrero 2002
[13] Hegel III, John & Brown John. Your Next IT Strategy. Harvard Business Review Oct 2001.
[14] IBM, IBM Patterns for e-business. http://www-106.ibm.com/developerworks/patterns/ fecha de
consulta Febrero 28 de 2003.
[15] Fletcher, Meter; Waterhouse, Mark. Web Services Business Satrategies and Architectures.
Expert. Press 2002.
[16] Iglesias, Daniel Humberto. Cadena de valor como estrategia. Febrero de 2002
http://www.planagro.com.uy/informacion/redplan/Cadena_Valor_INTA.htm. Fecha de Consulta:
Septiembre de 2002.
[17] Kirtlad, Mary, The Programmable Web - Web Services Provides Building Blocks for Mirosoft
.NET Framework.
www.msdn.microsoft.com/msdnmag/issues/0900/WebPlataform. Fecha de Consulta, Noviembre 23
de 2001.
[18] Kreger, Heather. Web Services Conceptual Architecture (WSCA 1.0). IBM Software Group.
May 2001.
[19] Novell, evento Extend, 30 de Enero de 2003. Gartner Group
[20] Serna Gómez, Humberto. Gerencia Estratégica. Bogotá, Prentice Hall 2000.
[21] Rayport, Jeffrey F y Sviokla John J. Exploiting the Virtual Value Chain. HBR. Noviembre de
2000.
MISC-03-1-2
108
[22] Revista Inter-Cambio. Agosto – Septiembre 2002. No 11. El ABC de las tecnologías de
Información.
[23] Smith, David Explaning Web Services` Apparent Contradictions. AV-16-4551 Gartner Group
4 de Junio de 2002
[24] Taller de Web Services Microsoft Colombia. Conferencista: Ricardo González Vargas.
Pontificia Universidad Javeriana, Marzo 12 de 2002.
MISC-03-1-2
109
10 ANEXO 0. NOTA TECNICA SOBRE WEB SERVICES
10.1 INTRODUCCION
Los Web Services no representan un nuevo concepto, pero si una nueva aproximación para abordar
un viejo problema. Los investigadores en tecnologías de información han buscado la forma de hacer
que la gran cantidad de aplicaciones que existen en el mercado se hablen e intercambien
información haciendo uso de estándares de comunicación [13].
Actualmente, la era de la información y servicios propietarios y exclusivos de cada
organización está llegando a su fin, y estamos entrando en una era de servicios
compartidos [7]. Las empresas han visto la necesidad de dedicarse a sus negocios, hacer lo
que saben hacer, y buscan alternativas para aquellos procesos que otras compañías saben
hacer mejor. En una corto plazo, las compañías querrán adquirir sus tecnologías de
información y sus servicios por Internet, más que adquirir su propio Hardware y
Software[7], esta es una gran oportunidad de negocio para quienes tengan visión e inicien
la construcción de este tipo de servicios compartidos, dando a los usuarios de los mismos
valor agregado y reconstrucción de su cadena de valor.
Este documento es una recopilación técnica de los Web Services, su arquitectura, sus posibles usos
como herramienta de ventaja competitiva, sus diferencias con las páginas web tradicionales y una
breve recopilación de algunos de los proveedores de tecnología que han entrado en esta nueva era
de construcción de servicios en la web.
Se describirán las diferentes tecnologías de hardware y software que componen la arquitectura de
los Web Services, y por medio de ejemplos se mostrará la forma de desarrollo y utilización de cada
una de ellas.
MISC-03-1-2
110
10.2 ¿Qué es un web service?
Un Web Service es un conjunto de aplicaciones que proporcionan datos y servicios a otras
aplicaciones, sin importar las plataformas en la que están soportadas ni el lenguaje en el cual están
implementadas [10]. En forma general podemos decir que son una colección de funciones
encapsuladas en una sola entidad y que se encuentran en la red de manera que puedan ser usados
por otros programas.
Según IDC [13], los Web Services son servicios máquina-máquina que se basan en
tecnologías sobre Internet. La Arquitectura de los Web Services (WSA), se describe como
una aproximación estandarizada a conectividad e interoperabilidad dinámica de
componentes que se ejecutan en tiempo real y bajo estándares de conectividad abierta
incluyendo: Internet Protocol (IP), Simple Object Access Protocol (SOAP) y Web Services
Description Language (WSDL). Otro de los estándares involucrados es el Extensible
Markup Language (XML).
Se apoya en una arquitectura de comunicaciones entre el proveedor del servicio y el cliente
(browser) vía Internet usando XML y mensajes SOAP. Es un componente aplicativo programable
asequible vía protocolos estándares del Web [8].
Visto en forma amplia, un Web Service es una aplicación que se entrega como un servicio y que
puede ser integrada con otros Web Services usando los estándares de Internet. En otras palabras, es
una dirección URL que en forma programática (un llamado interno que funciona por reglas de
software sin necesidad de la intervención humana) retorna información a los clientes que quieren
hacer uso de ella. Una de las características más importantes de los Web Services, es que los
clientes(browsers) no necesitan conocer cómo se implementó el servicio [2].
Desde una perspectiva técnica, los Web Services no son más que una colección de una o más
operaciones relacionadas, que son accesibles sobre la red y que se describen por medio de una
descripción de servicio[14].
MISC-03-1-2
111
Es importante aclarar a qué se refiere el término servicio cuando hablamos de Web Services, en
especial teniendo en cuenta que estamos haciendo una referencia directa a tecnologías de
información (TI). Desde el punto de vista de TI, IDC clasifica los servicios de la siguiente forma:
computacionales, profesionales y de aprovisionamiento [13].
Para comprender en detalle los Web Services, conviene tener presentes algunos de los
términos que se usan comúnmente y su definición. La tabla 1, presenta estos términos.
Término Definición Web Services Architecture (WSA) una aproximación estandarizada a conectividad e
interoperabilidad dinámica de componentes que se ejecutan en tiempo real y bajo estándares de conectividad abierta incluyendo: Internet Protocol (IP), Simple Object Access Protocol (SOAP) y Web Services Description Language (WSDL). Otro de los estándares involucrados es el Extensible Markup Language (XML).
Software para Web Services Incluye las herramientas de desarrollo de software, infraestructura y componentes de aplicación que conforman la WSA
Software de desarrollo y despliegue de Web Services
Herramientas de desarrollo de software, ambiente de desarrollo e infraestructura de desarrollo
Infraestructura de Software para Web Services
Infraestructura para ambientes de ejecución y funciones para soporte administrativo y seguridad, empaquetamiento y transmisión de mensajes y otras funciones que conforman la WSA.
Componentes de Aplicación de los Web Services
Los componentes de software de aplicación pueden usarse solos o combinados con otros componentes o aplicaciones, que son entregados sobre la red y expuestos mediante una interfaz.
Hardware de los Web Services Esta compuesto por la infraestructura de componentes de la empresa que conforman la WSA.
Servicios profesionales de los Web Services Compañías externas prestan asistencia a los compradores en los procesos de planeación, construcción, soporte y mantenimiento de los sistemas y procesos basados en WSA.
Web Services de aprovisionamiento Algunos servicios Xsp basados en la WSA. Tabla 1: Definiciones de Web Services [13]
MISC-03-1-2
112
10.3 Historia
La evolución de los sistemas de e-business, ha llevado a que las aplicaciones sean construidas
desde un conjunto de componentes de servicio, que pueden ser descubiertos, publicados,
combinados y consumidos sobre Internet [2], en otras palabras negocios electrónicos basados en
servicios.
El potencial de Internet hoy en día no está en las .com, este potencial lo tienen los grandes
proveedores de hardware y software, entre ellos Microsoft, Oracle, IBM y SUN[7].
La primera compañía en publicar la idea de los Web Services fue Hewlett-Packard (HP).
Ellos desarrollaron la especificación para e-speak, esta propuesta se convirtió en la
siguiente generación de intercambio de información en Internet. Posteriormente, Microsoft
apareció en el mercado con su estrategia de .Net, IBM siguió con su “Web Services
Toolkit” (WSTK), y el “Web Services Development Enviroment” (WSDE). A su vez,
Oracle anunció el lanzamiento de su “Dynamic Services” el cual fue integrado dentro de
Oracle 8i Release 2. Otros proveedores como SUN desarrollaron su framework para Web
Services, cuya iniciativa está centrada alrededor del ambiente J2EE. Actualmente están
construyendo herramientas de desarrollo rápido tanto para clientes como para servidores[9].
Como se dijo anteriormente, la evolución de los Web Services ha sido un trabajo no de uno,
sino de varios proveedores de tecnología, que de una u otra forma han encontrado utilidad
en la integración de los servicios en la red. Con excepción de Microsoft, se han usado
productos de la suite de Java, estos productos han evolucionado en los últimos cinco años.
[9]. En la figura 1, se observa la evolución de los Web Services desde el año 1998 hasta
Julio de 2001 [3].
MISC-03-1-2
113
Feb. 1998 Abr. 1998 Dic. 1999 Jun. 2000 Sep. 2000 Jun 2001 Jul. 2001
W3C aprueba
XML
MicrosoftAdquierePassport
Technology
ApareceJava 2
EnterpriseEdition
MicrosoftIntroduceSOAP 1.0
Serevela
Microsoft.NET
Se introduceUDDI 1.0
SeRevela WSDL
Se anunciaLa iniciativa
Sun One
SaleIBM WebSphere
Studio 4.0
Se libera el Registro UDDI privado para
IBM WebSphere
EVOLUCION DE LOS EVOLUCION DE LOS WEB WEB SERVICESSERVICES
Figura 1: Evolución de los Web Services [3]
10.4 Estructura y Arquitectura de los Web Services
La Arquitectura de los Web Services (WSA) está formada por varios componentes que pueden ser
representados como una caja negra. Esta caja negra, permite que dichos componentes sean
reutilizados sin preocuparse de cómo fue implementado el servicio [2]. Este concepto se conoce
con el nombre de encapsulamiento. De hecho, el desarrollo de los Web Services, se puede
comparar con la programación orientada a objetos, ya que hace uso de elementos de construcción
como: encapsulamiento, herencia haciendo uso de los tModels, sobre los cuales se trabajará más
adelante, y el registro dinámico[14].
Los Web Services proveen unas interfaces bien definidas llamadas contratos, que describen el
servicio que se provee.
Los Web Services se comunican usando protocolos Web y formatos tales como: HTTP, SMTP y
XML. En otras palabras, el contrato de los Web Services, describe el servicio que provee la
aplicación en términos de mensajes, que acepta y genera, más que la forma en la cual se
MISC-03-1-2
114
implementa el servicio [2]. La clave de la interoperabilidad de los Web Services, es la confianza
únicamente en los estándares Web.
Los modelos de Web Services, representan una mezcla de modelos de sistemas distribuidos y
computación en Internet [4].
En el siguiente diagrama (figura 2), se puede observar que un Web Service es una aplicación que
utiliza una serie de pilas (stacks) de protocolos, específicamente se habla de tres: Wire Stack,
Description Stack y Discovery Stack [1].
Figura 2: Vista de la arquitectura de pila de los Web Services [1]
La Wire Stack describe los servicios asociados a la confiabilidad del sistema, por ejemplo la
seguridad y transaccionalidad. Esta pila provee la lógica no funcional del servicio.
La Description Stack, Provee la arquitectura de la tecnología. Aquí se encuentran las interfaces, la
forma de publicar las interfaces, la generación de los servicios desde las interfaces publicadas. En
últimas, esta pila es el core del framework.
La Discovery Stack, provee la capa para el descubrimiento del servicio.
Cada una de estas pilas se basa en estándares tales como:
MISC-03-1-2
115
UDDI (Universal Discovery Description Integration), el cual define el método para descubrir un
Web Service. Este estándar provee el directorio de servicios a los cuales se puede acceder, y que
han sido previamente registrados por los desarrolladores o proveedores del servicio.
WSDL (Web Service Description Language), que describe el servicio y como acceder al mismo.
En otras palabras, provee las interfaces del framework. Estas interfaces se encuentran escritas en
XML.
Cómo se define el contrato de los Web Services? Actualmente este contrato está definido usando
WSDL (interface definida en XML); publicado en un service registry (UDDI), e invocado sobre
HTTP, usando SOAP con XTML. Los servicios pueden ser implementados en cualquier lenguaje de
programación (EJBs, Clases Java, COM, COBOL, C) y pueden ser desarrollados en cualquier
plataforma (Windows, UNIX entre otros) [2].
SOAP (Simple Object Access Protocol) y XML que son los métodos utilizados para acceder al
registro UDDI y comunicarse con los Web Services.
El siguiente diagrama (figura 3), presenta las capas de la arquitectura de los Web Services,
Description Stack
Wire Stack Discovery Stack
Negocio
Figura 3: Diagrama por capas de la arquitectura de los Web Services
10.5 Características de los Web Services
La primera distinción que podemos hacer sobre los Web Services está dada por su característica de
Pasividad y Actividad: La mayoría de los Web Services que se han construido hasta el momento
MISC-03-1-2
116
son Pasivos. Un servicio pasivo responde a un requerimiento hecho a un Web Service, por ejemplo:
la de conversión de monedas, o un servicio que responda a la solicitud de información sobre la
temperatura en determinado sitio del mundo. Por otra parte, un servicio activo, ofrece un potencial
adicional a una simple búsqueda de información. Este servicio es proactivo, mientras que los
servicios pasivos son reactivos[4].
Los Web Services se han construido sobre estándares, pero también proveen estándares, que pueden
ser resumidos en:
• Una forma de describir la funcionalidad de un componente de aplicación o una fuente de
datos de una manera estándar. Ejemplos de este tipo de Web Services son algunos servicios
pasivos como el de conversión de monedas, o los servicios de consulta de datos de una base
de datos estándar para el manejo de la nómina.
• La habilidad para desarrollar, encontrar aplicaciones o encontrar los componentes que sean
necesarios para cumplir con una funcionalidad requerida. (Ver la sección de ejemplos al
final de este documento).
• La habilidad para encapsular componentes que puedan ser utilizados independientemente
de la localización, plataforma de hardware o de software, o restricciones del lenguaje o de
la aplicación en tiempo de ejecución.
Interoperabilidad: Los web services pueden interactuar entre si, puesto que se basan en SOAP, de
esta manera se evitan los problemas de las conversiones CORBA – DCOM, esto quiere decir que
los web services pueden ser escritos en cualquier lenguaje. [1]
Integración de servicios: Puedo usar cualquier dispositivo que me ofrezca conexión a la red tales
como PDA´s y PC.
Podemos ver también a los Web Services como los bloques de construcción sobre los
cuales construir sistemas distribuidos, de manera que las empresas y las personas pueden
poner sus aplicaciones a servicio de todo el mundo.
MISC-03-1-2
117
Las dos grandes ventajas de la arquitectura de los Web Services son la apertura y la
modularidad. Antes teníamos sistemas propietarios, la empresa desarrollaba o licenciaba
sus aplicaciones y debía contar con un gran grupo humano que mantuviera las aplicaciones
corriendo permanentemente [7]. Este tipo de aplicaciones, generó una gran cantidad de
sistemas operando en la empresa en módulos separados por unidad de negocios, y a la vez,
bases de datos con información independiente y en ocasiones redundantes para la operación
del negocio. Las ERP aparecen en el mercado como una oportunidad de integrar la
información de la empresa, sin embargo, su principal problema es llevar a la empresa a
procesos rígidos [7].
La arquitectura de los Web Services es diferente, ya que está construida sobre Internet, es más
abierta que los sistemas propietarios. Por su construcción y funcionalidad, las compañías pueden
tener la información que necesiten. Por ejemplo: almacenamiento de datos, poder de procesamiento,
aplicaciones específicas de un variado conjunto de proveedores.
10.6 LOS UDDI
En esta sección, iniciamos un recorrido por los componentes de los Web Services. El primer
componente de la arquitectura que analizaremos serán los UDDI.
10.6.1 Qué son los UDDI?
UDDI es un registro público diseñado para almacenar de forma estructurada información sobre
empresas y los servicios que éstas ofrecen. A través de UDDI, se puede publicar y descubrir
información de una empresa y de sus servicios. Se pueden utilizar sistemas taxonómicos estándar
para clasificar estos datos y poder encontrarlos posteriormente en función de la categorización. Lo
más importante es que UDDI contiene información sobre las interfaces técnicas de los servicios de
una empresa. A través de un conjunto de llamadas a API XML basadas en SOAP, se puede
interactuar con UDDI tanto en tiempo de diseño como de ejecución para descubrir datos técnicos
de los servicios que permitan invocarlos y utilizarlos. De este modo, UDDI sirve como
infraestructura para una elección de software basado en servicios Web [3].
MISC-03-1-2
118
10.6.2 Historia de los UDDI
Buscar servicios y descubrirlos es algo que ha estado presente en la red desde sus inicios. Al
comienzo en forma incipiente y estática, pero con el tiempo ha evolucionado a algo más dinámico, a
su vez se ha cambiado de esquemas simples de búsqueda a esquemas de alta complejidad y
funcionamiento.
Los UDDI nacen como una necesidad de unificar la información de los servicios que estaban
apareciendo en la red y que ya no correspondían a simples transacciones electrónicas o páginas
Web. En otras palabras, se vio la necesidad de construir un Register o un DNS para estos nuevos
servicios.
Miremos el siguiente ejemplo:
Suponga que usted ha creado un portal de servicios para el cálculo de las tasas de interés y
liquidación de los intereses y cuotas para adquisición de un vehículo. Este servicio es consultado
frecuentemente por los concesionarios de vehículos al momento de sus ventas. Si el portal cambia
su dirección, debería avisar a todos sus usuarios de su nueva ubicación. Si este servicio es un Web
Service, estará registrado en el UDDI y en caso de cambios en la ubicación del servicio o en la
interfaz del mismo se hará la actualización en el UDDI.
Es un estándar creado por la UDDI.org, que unió la opinión de varios de los principales líderes de la
industria del software. El proyecto de estandarización busca incrementar la interoperabilidad y la
adopción de los Web Services. Estos estándares se basan en especificaciones para el servicio, la
descripción y el descubrimiento del mismo[9].
Algunos de los participantes en el proyecto son:
• Accenture
• Ariba
• Intel
• IBM
MISC-03-1-2
119
• Commerce One
• Compaq
• Fujitsu
• Hewlett-Packard
• i2
• Microsoft
• Oracle
• SAP
• Sun
• Verisign
Fueron más de 750 miembros de más de 300 compañías los que participaron en el proceso de
generación de los estándares.
Los UDDI en resumen son registros de los Web Services que ayudan a encontrar el servicio y su
descripción (WSDL). Las búsquedas, como se explicará más adelante, se pueden hacer por negocio
y por tipo de servicio[9].
Las versiones liberadas del estándar de UDDI a la fecha son:
UDDI V1 Que fue liberada en Junio de 2001
UDDI V2 Liberada en Julio de 2001. Posee categorización por clientes, negocios, asociaciones. Por
otra parte tiene mejores consultas que la primera versión.
UDDI V3 Se espera para Julio del año 2002, y adicionará seguridad, internacionalización, mejores
búsquedas, suscripciones, notificaciones y registros de referencias cruzadas.
10.6.3 Qué se almacena en los registros?
Podemos clasificar lo que se almacena en dos grandes grupos:
1) Cuerpos estándar, información registrada por negocios y programadores sobre los servicios que
ofrecen, incluyendo especificaciones y taxonomias.
2) Registro público de información del negocio sobre ellos mismos y los servicios que ofrecen.
MISC-03-1-2
120
10.6.4 Cómo se registra la información pública del negocio?
Los UDDI poseen tres formas de registrar y por ende acceder a la información, y su manejo es
similar al de los directorios telefónicos.
Se cuenta con estos tres esquemas:
Páginas Blancas: El registro y la búsqueda es por identificación.
• Información sobre el negocio
• Nombre del negocio
• Descripción o descripciones en texto.
• Información de contacto
• Nombre, dirección , teléfono, fax, sitios Web.
• Identificadores
• Lista de Identificadores
Paginas Amarillas: El registro y la búsqueda es por categorías.
Páginas Verdes: El registro y la búsqueda es por servicios.
10.6.5 Cómo es el modelo de datos de los UDDI?
En la siguiente figura (Figura 4) se presenta la arquitectura del modelo de datos de los UDDI.
businessEntity
bindingTemplate
tModel
businessService
Figura 4: UDDI Data Model [9]
MISC-03-1-2
121
Una entrada a un UDDI comienza con una businessEntity cuyos elementos modelan la información
sobre un negocio, incluyendo información básica del negocio, por ejemplo cuál es el nombre del
negocio y la información de contacto. Información de categorización como por ejemplo qué tipo de
negocio es y por último información de identificación.
Un businessEntity posee un conjunto de elementos de businessService, uno para cada Web Service
que el negocio haya publicado. Cada elemento businessService posee información técnica y
descriptiva sobre los elementos businessEntity del Web Service.
Un businessService contiene una colección de bindingTemplate (plantillas de enlace), que
describen el acceso a la información y como el businessService utiliza varias especificaciones
técnicas [10].
El tModel es una representación del negocio que se quiere exponer remotamente.
10.6.6 Cómo publicar el servicio?
La publicación en UDDI es un proceso relativamente sencillo. El primer paso consiste en
determinar información básica sobre cómo definir la empresa y los servicios en UDDI. El siguiente
paso, una vez determinada esta información, consiste en llevar a cabo el registro, ya sea mediante
programación o a través de una interfaz de usuario basada en el Web. Por último, se debe probar la
entrada para asegurar que se registró correctamente y que aparece tal y como se esperaba en
diferentes tipos de búsquedas y herramientas.
Los pasos para el registro son:
Primer paso: Definir la entrada de UDDI
Partiendo del modelo de datos descrito anteriormente, se debe recopilar cierta información
importante antes de establecer una entrada de UDDI.
• Determine los tModels (archivos WSDL) que utilizan las implementaciones del
servicio Web.
MISC-03-1-2
122
Al igual que sucede en el desarrollo de un componente COM, el servicio Web se ha
desarrollado a partir de una interfaz existente o de una interfaz de diseño propio. En el caso
de un servicio Web basado en una interfaz WSDL existente, deberá determinar si el archivo
WSDL se ha registrado en UDDI. Si es así, deberá comprobar su nombre y tModelKey, que
es el identificador GUID (identificador único global) que generó UDDI cuando se produjo
el registro.
Por el contrario, si el servicio Web se basa en un archivo WSDL que no se ha registrado en
UDDI, deberá crear un nuevo tModel para representar esta interfaz. El nombre de este
tModel debería tener un formato URI (identificador de recursos uniforme), como
MyCompany-com:SampleWebService-interface:v1, y señalar a la ubicación del archivo
WSDL.
Si su servicio Web es un servicio de Microsoft® Visual Studio® .NET, podrá generar una
descripción WSDL utilizando una cadena de consulta desde el archivo .ASMX (como
<http://www.mycompany.com/SampleWebService.asmx?wsdl>). No obstante, el archivo
WSDL generado por Visual Studio .NET se relaciona estrechamente con el punto de acceso
para la invocación del servicio Web, lo cual puede no resultar adecuado cuando la interfaz
del servicio tiene varias implementaciones. Esto no supondrá ningún problema si su
intención es que el archivo WSDL sólo tenga una implementación.
Determine el nombre de la empresa y una breve descripción de la misma en varios idiomas, si
es necesario, así como los contactos principales para los servicios Web que ofrece.
UDDI es compatible con el espacio de nombre xml:lang, lo que permite a las empresas
ofrecer su descripción en varios idiomas. Asimismo, UDDI permite enumerar los contactos,
incluyendo datos como el correo electrónico, el teléfono y la dirección. Esta lista de
contactos muestra los recursos de una empresa con los que se puede poner en contacto en
relación con los servicios Web ofrecidos. Por ejemplo, si un usuario desea comenzar a
utilizar el servicio Web deberá ponerse en contacto con el responsable de relaciones
comerciales correspondiente pero, ¿cómo puede llegar a saber quién es? ¿Existe algún
contacto para obtener asistencia técnica a la hora de utilizar los servicios Web de la
empresa? También se debería incluir en la lista a esta persona?.
Determine las categorías e identificaciones adecuadas para la empresa.
MISC-03-1-2
123
Podrá explorar los sistemas taxonómicos compatibles con UDDI actualmente en el nodo
Microsoft UDDI (<http://uddi.microsoft.com/default.aspx> [en inglés]). Estos sistemas son,
por el momento, North American Industry Classification System (NAICS), Universal
Standard Products and Services Codes (UNSPSC), ISO 3166, Standard Industry
Classification (SIC) y GeoWeb Geographic Classification. Seleccione las categorías que
representan de forma más acertada a su empresa.
Determine los servicios Web que la empresa ofrece a través de UDDI.
A continuación, deberá determinar los servicios Web que desea registrar la empresa en el
nodo público UDDI. ¿Existen varios puntos de acceso para este servicio? ¿Es preciso que
los clientes conozcan otros parámetros y otra información para utilizar el servicio Web?
Resulta importante destacar que no todo el mundo puede obtener acceso a un servicio Web
porque éste se haya registrado en UDDI. A una entrada de registro UDDI le pueden
acompañar medidas de seguridad, autorización y autenticación. No basta que el usuario
sepa que existe un servicio Web para que pueda invocarlo. Puede existir una comunicación
fuera de línea entre empresas antes de permitir el acceso a un servicio Web.
Determine las categorías adecuadas para los servicios.
Los servicios Web se pueden categorizar del mismo modo que las empresas. No obstante,
una empresa se debe categorizar a nivel empresarial, como por ejemplo NAICS: Software
Publisher (51121), y el servicio Web (de reserva hotelera, en este caso) se debería
categorizar en el nivel de servicios, como NAICS: Hotels and Motels (72111).
Segundo paso: Registrar la entrada de UDDI
Una vez finalizada la tarea de definición, el siguiente paso consiste en registrar la empresa. Deberá
obtener una cuenta con un registro UDDI. Esta operación no se puede realizar mediante
programación, ya que deberá mostrar su conformidad con una declaración de condiciones de uso. El
nodo de Microsoft utiliza Passport para la autenticación, así que deberá adquirir una cuenta de
Passport
(<http://www.passport.com/Consumer/default.asp>) para continuar con el registro.
En este punto se ofrecen dos opciones: puede utilizar la interfaz de usuario Web del nodo de
Microsoft o realizar el registro mediante programación dirigiendo al propio nodo las llamadas a API
de SOAP. Si no piensa modificar la entrada o ésta es relativamente simple, bastará con la interfaz de
usuario Web. No obstante, si pretende actualizar la entrada con frecuencia, o bien, ésta es más
MISC-03-1-2
124
compleja, resulta recomendable realizar el proceso de registro con secuencias de comandos,
utilizando el SDK de Microsoft UDDI. Además, la interfaz de usuario de Microsoft no está
disponible en otros idiomas, así que se deberá registrar mediante programación para disfrutar esa
característica de la API de UDDI.
10.6.7 Algunos Operadores UDDI en la actualidad
Actualmente la mayoría de los UDDI están a la cabeza de las grandes casas desarrolladoras de
software, algunos de sitios de registro de Microsoft e IBM son:
• IBM UDDI Business Registry Sites:
• Official Registry:
• http://www.ibm.com/services/uddi
• Test Registry:
• http://www.ibm.com/services/uddi/testregistry
• Microsoft UDDI Business Registry Sites:
• Official Registry:
• http://uddi.microsoft.com
• Test Registry:
• http://test.uddi.microsoft.com
10.7 Simple Object Access Protocol (SOAP)
Existe una tendencia muy marcada en las empresas por el desarrollo de aplicaciones que puedan
trabajar sobre Internet, principalmente por la ventaja de la distribución global de la información.
Las tecnologías más usadas para el desarrollo de estas aplicaciones, han sido CORBA (OMG,
Object Management Group), COM (Microsoft) y EJB (Sun Microsistems). Cada una proporciona
un marco de trabajo para la activación de objetos remotos, mediante la solicitud a un servidor de
aplicaciones (o mediante un servidor Web) para la ejecución de servicios de aplicación. Estas
tecnologías han probado ser efectivas para el establecimiento de sitios Web corporativos; sin
embargo, presentan algunas desventajas como la falta de interoperabilidad (es posible, pero
MISC-03-1-2
125
complejo, hacer interoperar COM y CORBA), la dependencia a la arquitectura de trabajo (COM
está muy ligado a Windows, mientras que CORBA tiene muchas implementaciones de diversos
fabricantes), así como el lenguaje de programación (COM usa primordialmente C++ y Visual Basic,
mientras que EJB usa Java).
Esto ha llevado a la industria a considerar un nuevo modelo de computación distribuida de objetos,
sin tener la dependencia de plataformas, modelos de desarrollo y lenguajes de programación usados.
10.7.1 Historia de SOAP
Las tecnologías de los Web Services se basan en protocolos XML. Estos protocolos manejan la
forma en que se hace la comunicación y se manejan los datos.
Los protocolos XML se dividen en dos generaciones. La primera generación de protocolos se basa
en XML 1.0 , la segunda generación toma ventaja de la aparición de XML name y XML scheme,
SOAP es un protocolo XML de segunda generación.[16]
Protocolos de primera generación
Esta primera generación fue poco soportada por los vendedores de tecnología y por tanto fue poco
aceptada entre los mismos.
Dentro de los protocolos de esta generación se encuentra : WDDX (Web Distributed Data
Exchange) y XML-RPC.
WDDX provee un mecanismo de lenguaje y plataforma neutral para hacer intercambio de datos
entre aplicaciones. Este protocolo fue creado por Allaire Corporation (hoy Macromedia Inc.) en
1998.
XML-RPC es un protocolo RPC introducido en 1998 por Userlad. Soporta un conjunto de datos
similar a los soportados por WDDX y usa http.
Esta primera generación presentó algunos problemas dentro de los cuales se destaca la poca
extensibilidad de los protocolos, situación que es superada en la segunda generación cuando se hace
una optimización de los XML namespace.
Protocolos de segunda generación
Microsoft comenzó a pensar en la computación distribuida en 1996. El objetivo era lograr habilitar
las aplicaciones para comunicarse vía Remote Procedure Calls (RPC) y correr sobre http.
MISC-03-1-2
126
DevelopMentor y Userlad se unieron a la discusión y para principios de 1998 se da a conocer
SOAP.
En principio se pensó que Microsoft debería aprovechar su posición en el mercado para promover el
estándar del momento; DCOM sobre http, pero otros creyeron en SOAP y en las facilidades que se
podría tener haciendo un uso adecuado de XML namespace.
El 13 de Septiembre de 1999, mientras Microsoft trabajaba en su versión de XML Scheme (XML
data) y adicionaba soporte a los XML namespace, aparece la primera versión (0.9) de SOAP . La
versión 1.0 de SOAP se libera en Diciembre del mismo año.
SOAP 1.1 es sometida a verificación y el W3C la toma como estándar en Mayo 8 de 2000.
SOAP es un protocolo liviano para intercambio de información en una ambiente descentralizado o
distribuido. Este protocolo se basa en XML.[17].
SOAP 1.0 se ha construido con base en una segunda generación del protocolo XTML, y se enfoca
en todos los aspectos comunes de los escenarios de computación distribuida.
SOAP provee [16]:
• Un mecanismo para definir la unidad de comunicación. En SOAP toda la información es
empaquetada en un SOAP message claramente identificado. Este mensaje es hecho por el
SOAP envelope que encierra toda la demás información. Un mensaje puede tener un cuerpo
body, escrito en XML. Se cuenta también con un número de encabezados headers, que
encapsulan la información fuera del cuerpo del mensaje.
• Un mecanismo de manejo de errores, que permite identificar la fuente y la causa del error,
y envía un diagnóstico del error a todos los participantes. Este manejo se hace mediante la
concepción de SOAP fault.
• Hace un nuevo manejo del namespace permitiendo mayor extensibilidad y flexibilidad.
Esta extensibilidad se hace por medio de los SOAP header y puede ser usado para
construir protocolos más complejos sobre SOAP.
• Un mecanismo flexible para representación de datos que permita el intercambio de datos
siempre serializados, en algún formato (texto, XML, otros), o bien como una convención
que represente una estructura de datos abstracta como se hace con los tipos de datos de los
lenguajes de programación en un formato XML.
• Una convención para presentar Remote Procedures Calls (RPC’s) y respuestas a mensajes
SOAP ya que RPC es un tipo más común de computación distribuida.
MISC-03-1-2
127
• Permite modelos de intercambios de datos más naturales para las interacciones entre
negocios.
• Un mecanismos de búsqueda de mensajes SOAP sobre http, debido a que http es un
protocolo de comunicación común en Internet.
Se pretende que SOAP sea “ubiquitous XML distributed computing infrastucture”,es decir: una
infraestructura basada en XML que permita la ubicuidad y la computación distribuida[16].
Computación Distribuida: implica que SOAP puede ser usado para habilitar la interoperabilidad de
aplicaciones remotas, El concepto de computación distribuida puede tener diferentes facetas, y las
necesidades que cubra el protocolo de comunicación también pueden variar dependiendo del tipo
de aplicación que se quiera construir. Sin embargo, los mínimos requeridos para una ambiente de
transacciones distribuidas son: la pila de protocolo usado para la comunicación, administración de
la conexión, seguridad, soporte de transacciones, marshalling y unmarshalling de datos,
administración de versiones, manejo de errores, auditoria de las transacciones, entre otros. Es claro
entonces que no todo tipo de aplicación requiere todos los aspectos mencionados, pues no es lo
mismo un proceso de administración de inventarios que el pago de servicios o el pago de una
compra, donde el tipo de seguridad y confiabilidad de las transacciones es obligatorio. [16].
Infraestructura implica que SOAP está orientado a desarrolladores de sistemas distribuidos bajo
nivel. No para desarrolladores de aplicaciones de lógica del negocio o usuarios de negocios.
Ubicuidad : significa omnipresencia o universalidad. A pesar de ser lo más importante de esta
definición, esta parte está aún inmadura en el proceso de evolución de SOAP, ya que se requeriría
que SOAP fuese altamente abstracto y tecnológicamente flexible. Mas abstracción generaría más
riesgos al momento de trabajar la interoperabilidad de las aplicaciones[13].
SOAP consta de tres partes [17]:
• El SOAP envelope (sobre) define un marco de referencia para expresar que va en el
mensaje,; quién debe tratar con el y si es opcional u obligatorio.
MISC-03-1-2
128
• El SOAP encoding rules o reglas de codificación, define el mecanismo de serialización que
puede ser usado para intercambiar instancias de tipos de datos de aplicaciones definidas.
• La representación SOAP RPC define una convención que puede ser usada para representar
llamadas y respuestas a procedimientos remotos.
A continuación se presenta la solicitud y respuesta de un mensaje SOAP embebido en http (tomado
de [17]).
Ejemplo: Mensaje SOAP embebido en una solicitud http
POST /StockQuote HTTP/1.1 Host: www.stockquoteserver.com Content-Type: text/xml; charset="utf-8" Content-Length: nnnn SOAPAction: "Some-URI" <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Body> <m:GetLastTradePrice xmlns:m="Some-URI"> <symbol>DIS</symbol> </m:GetLastTradePrice> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
Este mensaje tiene a su vez una respuesta que se presenta a continuación:
Ejemplo: Mensaje SOAP embebido en una respuesta http
HTTP/1.1 200 OK Content-Type: text/xml; charset="utf-8" Content-Length: nnnn <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/> <SOAP-ENV:Body> <m:GetLastTradePriceResponse xmlns:m="Some-URI"> <Price>34.5</Price> </m:GetLastTradePriceResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
MISC-03-1-2
129
Una de las grandes ventajas de los Web Services, es que no es necesario saber XML para
construirlos o consumir el servicio. Esto valida a SOAP como una infraestructura tecnológica. El
mecanismo que permite que esto ocurra tiene múltiples capas de abstracción:
Proveedores y solicitantes usan servicios como los Api’s de Java.
Invocar un Web Service, requiere de una o más invocaciones de métodos Java.
Implementar un Web Services requiere de un BackEnd de Java (una clase o un EJB).
La vista de un Web Services es un mensaje SOAP que será intercambiado entre el solicitante y el
proveedor del servicio.
Las vistas de desarrollo de los Web Services son vistas lógicas. La única vista real es el wire-level ,
donde los paquetes http contienen mensajes que son intercambiados entre la aplicación del
solicitante y el Web Service del proveedor [16]. La figura 5 presenta las capas de la invocación de
un Web Services.
Solicitante ProveedorVista
Desarrollador
Web Service
Wire-level
Java API
SOAP Message
HTTP packet
Java API
SOAP Message
HTTP packet
Fugura 5: Vistas de las capas en la invocación de un Web Service [16]
Aunque las especificaciones de SOAP se usan para la búsqueda http, los Web Services pueden ir
más allá del límite establecido en el http y manejar otros empaquetamientos y esquemas de
MISC-03-1-2
130
protocolos como: paquetes MIME para soportar attachements, SMTP para manejar mensajes
asimétricos sin necesidad de una capa intermedia, entre otros.
La siguiente gráfica (figura 6) presenta la forma en que se envía un mensaje XML para la solicitud
de un servicio usando SOAP.
Figura 6: Mensaje XML usando SOAP [10]
10.8 ¿Cómo se describe el servicio?
Enfoquemos nuestra atención ahora desde la perspectiva del que solicita el servicio; cómo debe
hacer el cliente para saber que clase de mensaje debe enviar para invocar el servicio que quiere
consumir?
Con SOAP envelope tenemos el formato del sobre para enviar el mensaje, pero es necesario
clarificar que tipo de mensaje se colocará en el sobre.
Sería necesario entonces, que el cliente conociera bien XML para poder colocar el body o cuerpo
del SOAP envelope. Y entender el formato de respuesta enviado por el proveedor del servicio. El
cliente necesitaría también conocer el protocolo con el cual se enviaría el mensaje y la dirección de
red para hacer el envío. Ahora bien, si siempre que se quisiera hacer uso de un Web Service se
tuviese que hacer el análisis, diseño, decodificación y codificación de los mensajes, los Web
Services no habrían tenido acogida.
MISC-03-1-2
131
Se requiere, entonces, un mecanismo formal para describir el servicio [16]. La descripción de un
servicio está involucrada directamente con cada una de las tres operaciones de una Service –
Oriented-Architecture (SOA), estas operaciones son: publicar, encontrar y encadenar-enlazar, estas
operaciones se presentan en la figura 7.
Registro del
Servicio
Solicitante del
Servicio
Proveedor del
Servicio
Buscar Publicar
Enlazar
WSDL, UDDI WSDL, UDDI
Descripción del Servicio
Descripción del Servicio
Servicio
Figura 7: Arquitectura Orientada a Servicio (SOA) [16]
El proveedor del servicio publica una descripción del servicio para uno o más service register
(registros de servicio). Esta publicación no es el código del Web Services sino una descripción del
mismo.
El proveedor del servicio usa una descripción del servicio para comunicar al solicitante del servicio,
cada cosa que él necesita conocer para poder invocar el Web Service. Esta publicación es clave para
poder encontrar la operación que el solicitante del servicio requiere. Es por esto que se publica esta
descripción del servicio ofrecido.
El solicitante del servicio quiere encontrar la descripción del servicio, porque esta describe
exactamente que se requiere para que ocurra la operación de encadenamiento.
Capas del Service Description stack:
MISC-03-1-2
132
El Service Description stack: puede ser dividido en dos grandes grupos la capa funcional y la capa
no funcional. En la figura 8 se presentan los detalles en los cuales se fundamenta esta pila.
Service Service AgreggationAgreggation
EndpointEndpointDescriptionDescription
Service Service InterfaceInterface
Service Service ImplementationImplementation
XMLXML
ServiceDescription
Stack
XML XML SchemaSchema
WSDLWSDL
WSDLWSDL
WSELWSEL
WSFL/WSFL/XLANGXLANG
Figura 8: Service description Stack [16]
Los tres primeros niveles XML scheme, WSDL (service implementation) y WDDL (services
interface) son funcionales, ya que describen los detalles de cómo el Web Services es invocado y
como es invocado.
Las capas WSEL y WSFL/XLANG son no funcionales o no operacionales en su naturaleza, ya que
no informa de manera directa los mecanismos de invocación.
Descripción Funcional
Las capas funcionales del Service Description stack, definen la Interface Definition Language
(IDL) que es equivalente a la descripción del servicio.
La descripción del servicio en un Web Services es equivalente o tiene la misma función que el IDL
en otras aproximaciones de la computación distribuida.
MISC-03-1-2
133
Como todo en los Web Services, XML es la base de la descripción del servicio. XML describe los
tipos de datos para los elementos que fluyen en el mensaje SOAP pero en particular con el SOAP
payload (carga), el cual necesita ser formateado por el solicitante del servicio e interpretado por el
proveedor del servicio.
La definición de la implementación del servicio (service implementation definition) y la definición
de la interfaz del servicio (service interface definition) usan el Web Services Description Language
WSDL.
La definición de la implementación del servicio describe: Dónde se localiza el servicio o más
exactamente a cual dirección en la red debe enviarse el mensaje para invocar el Web Services.
La definición de la interfaz del servicio describe qué mensaje necesita ser enviado y cómo usar los
protocolos de mensajes estándar de Internet y los esquemas de codificación para tener un formato
aceptado por el proveedor del servicio.[16]
Descripción no funcional
Mientras que las capas funcionales describen donde enviar el mensaje, la sintaxis del mensaje y
como usar los protocolos para esquemas de codificación, la descripción no funcional se orienta
hacia el por qué un solicitante de servicio debe invocar un Web Services. Por ejemplo: qué función
cumple el Web Services para el negocio y cómo influye en los procesos del mismo.
La descripción no funcional da más información de quién es el proveedor del servicio.
El WSEL (Web Sercices Endpont Language) describe el ambiente o punto final en el cual se
hospeda el Web Services. Las características de este ambiente de hospedaje deben contemplar las
políticas de seguridad y los niveles de calidad del servicio que están disponibles para la invocación
del Web Services, además de las políticas de privacidad que están obligados a cumplir los
proveedores del servicio.
Descripción de Agregación(Aggregation/ Description)
El Web Service Flow Language (WSFL) es una técnica para describir como una colección de
Web Services pueden ser compuestos dentro de un alto nivel de proceso de negocio.
La siguiente tabla, muestra los roles de cada una de las capas del Service Description Stack. [16]
MISC-03-1-2
134
Pregunta Dónde Direcciona
Quién Descripción no funcional
Qué Service Interface (Interfaz de servicio)
Dónde Service Implementation (Implementación de Servicio)
Por qué Descripción no funcional
Cómo Service Interface (Interfaz de servicio)
10.9 Web Services Description Language (WSDL) El WSDL es un estándar propuesto para describir la sintaxis de invocación técnica de Web
Services.
El WSDL fue desarrollado por el W3C como estandarización de IBM, Microsoft y otros en
Septiembre de 2000.
Una descripción de servicio WSDL es un documento XML, no es una descripción completa del
servicio, pero cubre los niveles bajos del services description stack, y es la descripción técnica pura
de la interfaz del servicio.
El WSDL es el IDL para los Web Services. En esencia un WSDL describe tres propiedades
fundamentales de un Web Services:
Qué hace el servicio – las operaciones (métodos) que el servicio provee.
Cómo se accede el servicio – detalles de los formatos de datos y los protocolos necesarios para
acceder a las operaciones del servicio.
Dónde está localizado el servicio – detalles del protocolo, direcciones de red específicas tales como
un URL.
10.9.1 Modelo de información del WSDL [16]
El modelo de información del WSDL toma ventaja de la separación entre las especificaciones
abstractas y las implementaciones concretas de estas especificaciones. Esto refleja la división entre
la definición de la interfaz del servicio (interfaz abstracta) y la definición de la implementación del
servicio (punto final concreto).
MISC-03-1-2
135
La descripción de las capacidades del punto final es la especificación de la interfaz abstracta
representada en el WSDL por un portType (tipo de puerto). Un mecanismo de encadenamiento
(binding) representados en el WSDL por un elemento de búsqueda que es usado para mapear la
definición abstracta del Web Service para una implementaciópn específica usando un protocolo de
mensaje particular, un modelo de decodificación de datos y un protocolo de comunicación a bajo
nivel. Cuando el enlace-búsqueda es combinado con una dirección donde la implementación pueda
ser accedida, el punto final será un punto concreto que el solicitante del servicio puede invocar. Esa
combinación es representada por un elemento WSDL port.
Una interfaz abstracta puede soportar un gran número de operaciones. Una operación es definida
por el conjunto de mensajes que definen sus patrones de interacción.
Como todas las buenas aplicaciones de XML el esquema WSDL define varios elementos de alto
nivel en el lenguaje:
• PortType: una definición de interfaz abstracta de Web Services donde cada elemento
operación-hijo define una forma del método abstracto.
• Message: define un conjunto de parámetros referenciados por el método u operación.
• Types: define una colección de todos los tipos de datos usados en el Web Service y que son
referenciados por varios elementos que son parte del mensaje (tipos de datos base).
• Binding: contiene los detalles de cómo los elementos en una interfaz abstracta (portType)
son convertidos en una representación concreta, en una combinación particular de formatos
de datos y protocolos (ejemplo: esquema de codificación de SOAP sobre http).
• Port: expresa como un enlace (binding) es desplegado en un punto final particular de la red
(lugar donde se especifica el http URL).
• Service: es un nombre o colección de nombres de puertos (ejemplo: los puertos asociados
con los pasos enana transacción de negocios multipasos). En otras palabras es una colección
de endpoints.
El tipo de puerto portType (con detalles del mensaje y el tipo de elementos) describe el que del Web
Services.
El elemento binding describe el como y los elementos port y service describen el donde del web
service.
MISC-03-1-2
136
Este modelo de información se puede observar con claridad en la figura 9.
Figura 9: Modelo de Información del WSDL [10]
El siguiente, es un ejemplo de la codificación del WSDL de un servicio que permite seleccionar un
producto y sus existencias.
<?xml version="1.0" encoding="utf-8"?> <definitions xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:s="http://www.w3.org/2001/XMLSchema" xmlns:s0="http://tempuri.org/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" targetNamespace="http://tempuri.org/" xmlns="http://schemas.xmlsoap.org/wsdl/"> <types> <s:schema elementFormDefault="qualified" targetNamespace="http://tempuri.org/"> <s:import namespace="http://www.w3.org/2001/XMLSchema" /> <s:element name="queryAllProducts"> <s:complexType /> </s:element> <s:element name="queryAllProductsResponse"> <s:complexType> <s:sequence> <s:element minOccurs="0" maxOccurs="1" name="queryAllProductsResult"> <s:complexType> <s:sequence> <s:element ref="s:schema" />
MISC-03-1-2
137
<s:any /> </s:sequence> </s:complexType> </s:element> </s:sequence> </s:complexType> </s:element> <s:element name="queryProductPrice"> <s:complexType> <s:sequence> <s:element minOccurs="1" maxOccurs="1" name="pid" type="s:int" /> </s:sequence> </s:complexType> </s:element> <s:element name="queryProductPriceResponse"> <s:complexType> <s:sequence> <s:element minOccurs="1" maxOccurs="1" name="queryProductPriceResult" type="s:double" /> </s:sequence> </s:complexType> </s:element> <s:element name="DataSet" nillable="true"> <s:complexType> <s:sequence> <s:element ref="s:schema" /> <s:any /> </s:sequence> </s:complexType> </s:element> <s:element name="double" type="s:double" /> </s:schema> </types> <message name="queryAllProductsSoapIn"> <part name="parameters" element="s0:queryAllProducts" /> </message> <message name="queryAllProductsSoapOut"> <part name="parameters" element="s0:queryAllProductsResponse" /> </message> <message name="queryProductPriceSoapIn"> <part name="parameters" element="s0:queryProductPrice" /> </message> <message name="queryProductPriceSoapOut"> <part name="parameters" element="s0:queryProductPriceResponse" /> </message> <message name="queryAllProductsHttpGetIn" /> <message name="queryAllProductsHttpGetOut"> <part name="Body" element="s0:DataSet" />
MISC-03-1-2
138
</message> <message name="queryProductPriceHttpGetIn"> <part name="pid" type="s:string" /> </message> <message name="queryProductPriceHttpGetOut"> <part name="Body" element="s0:double" /> </message> <message name="queryAllProductsHttpPostIn" /> <message name="queryAllProductsHttpPostOut"> <part name="Body" element="s0:DataSet" /> </message> <message name="queryProductPriceHttpPostIn"> <part name="pid" type="s:string" /> </message> <message name="queryProductPriceHttpPostOut"> <part name="Body" element="s0:double" /> </message> <portType name="Service1Soap"> <operation name="queryAllProducts"> <input message="s0:queryAllProductsSoapIn" /> <output message="s0:queryAllProductsSoapOut" /> </operation> <operation name="queryProductPrice"> <input message="s0:queryProductPriceSoapIn" /> <output message="s0:queryProductPriceSoapOut" /> </operation> </portType> <portType name="Service1HttpGet"> <operation name="queryAllProducts"> <input message="s0:queryAllProductsHttpGetIn" /> <output message="s0:queryAllProductsHttpGetOut" /> </operation> <operation name="queryProductPrice"> <input message="s0:queryProductPriceHttpGetIn" /> <output message="s0:queryProductPriceHttpGetOut" /> </operation> </portType> <portType name="Service1HttpPost"> <operation name="queryAllProducts"> <input message="s0:queryAllProductsHttpPostIn" /> <output message="s0:queryAllProductsHttpPostOut" /> </operation> <operation name="queryProductPrice"> <input message="s0:queryProductPriceHttpPostIn" /> <output message="s0:queryProductPriceHttpPostOut" /> </operation> </portType> <binding name="Service1Soap" type="s0:Service1Soap">
MISC-03-1-2
139
<soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document" /> <operation name="queryAllProducts"> <soap:operation soapAction="http://tempuri.org/queryAllProducts" style="document" /> <input> <soap:body use="literal" /> </input> <output> <soap:body use="literal" /> </output> </operation> <operation name="queryProductPrice"> <soap:operation soapAction="http://tempuri.org/queryProductPrice" style="document" /> <input> <soap:body use="literal" /> </input> <output> <soap:body use="literal" /> </output> </operation> </binding> <binding name="Service1HttpGet" type="s0:Service1HttpGet"> <http:binding verb="GET" /> <operation name="queryAllProducts"> <http:operation location="/queryAllProducts" /> <input> <http:urlEncoded /> </input> <output> <mime:mimeXml part="Body" /> </output> </operation> <operation name="queryProductPrice"> <http:operation location="/queryProductPrice" /> <input> <http:urlEncoded /> </input> <output> <mime:mimeXml part="Body" /> </output> </operation> </binding> <binding name="Service1HttpPost" type="s0:Service1HttpPost"> <http:binding verb="POST" /> <operation name="queryAllProducts"> <http:operation location="/queryAllProducts" /> <input> <mime:content type="application/x-www-form-urlencoded" /> </input>
MISC-03-1-2
140
<output> <mime:mimeXml part="Body" /> </output> </operation> <operation name="queryProductPrice"> <http:operation location="/queryProductPrice" /> <input> <mime:content type="application/x-www-form-urlencoded" /> </input> <output> <mime:mimeXml part="Body" /> </output> </operation> </binding> <service name="Service1"> <port name="Service1Soap" binding="s0:Service1Soap"> <soap:address location="http://demosnet/ServicioCatalogo/Service1.asmx" /> </port> <port name="Service1HttpGet" binding="s0:Service1HttpGet"> <http:address location="http://demosnet/ServicioCatalogo/Service1.asmx" /> </port> <port name="Service1HttpPost" binding="s0:Service1HttpPost"> <http:address location="http://demosnet/ServicioCatalogo/Service1.asmx" /> </port> </service> </definitions>
10.10 Extensible Markup Language (XML).
En los años sesenta se perseguía la idea de estructurar los documentos de forma organizada con el
fin de facilitar el intercambio y la manipulación de los datos. IBM creó el GML (lenguaje de
marcado generalizado) para satisfacer las necesidades de sus sistemas internos de edición. Empleó
GML para producir libros, informes y otros documentos a partir de un solo conjunto de archivos
fuente. En empresas específicas se introdujeron otras soluciones de estructuración de información
pero, no se hacia nada para solucionar el tema a gran escala[19].
La primera tecnología de información estandarizada y estructurada fue SGML (Lenguaje de
marcado generalizado estándar), qué también provenía de IBM [19]..
XML (eXtensible Markup Language) es un meta-lenguaje de marcado que permite describir datos
estructurados, es una simplificación de SGML (Lenguaje de marcado generalizado estándar). El
MISC-03-1-2
141
Worl Wide Web Consortium (W3C) comenzó a trabajar en el Extensible Markup Language XML a
mediados de 1996. XML 1.0 se liberó el 10 de Febrero de 1998. XML es el resultado de las
necesidades de la industria de los computadores de desarrollar un mecanismo simple pero extensible
de representación textual de información estructurada y semi-estructurada. Un documento XML
tiene un aspecto similar a un documento HTML. [16]
XML permite la manipulación general de datos y el despliegue de información en la Web sus
principales características son:
- Es Extendible porque permite definir sus tags o etiquetas
- Representación estructural de los datos.
- Tecnología probada en muchos ámbitos por SGML.
- XML es una versión simplificada de SGML.
- Permite acordar estándares para describir la estructura de:
- Documentos de texto puro.
- Un registro estructurado como una cita, una ficha bibliográfica, una orden de compra.
- El resultado de una consulta a una base de datos.
- Es texto por lo tanto es directamente compatible con HTTP.
- Puede ser mezclada con información proveniente de otras fuentes, gracias al formato
común.
- Es legible por los humanos.
XML comprende un conjunto de tecnologías que lo complementan y lo estandarizan para distintos
tipos de aplicaciones, entre las principales se encuentran los DTD (Document Type Definitions), los
Schemas y los NameSpaces.
10.10.1 DTDs (Document Type Definitions)
Desde que surgieron los primeros lenguajes de marcación GML y SGML se generaron diversos
mecanismos para definir como, cuales y cuantos elementos podían existir en determinado formato,
los DTD's (Document Type Definitions) figuran entre los primeros mecanismos.
MISC-03-1-2
142
Uno de los DTD's mas utilizados es el de HTML (se puede observar en
http://www.w3.org/TR/REC-html40 ), todo navegador ("Netscape", "Explorer", "KDE"...etc) esta
diseñado alrededor de estos DTD's. Los DTD's le permiten al navegador validar la información que
reciben en HTML, esto es, si se encuentra un elemento <TITLE>, que otros elementos pueden
seguir? que tipo de información puede contener ?, o bien, un elemento <IMG> que parámetros
requiere? se puede encontrar dentro de otros elementos como <H1> ?
HTML es un estándar y por lo general es utilizado por los ya comunes navegadores (Netscape y
Explorer).
10.10.2 Estructura de los DTDs
Los "Document Type Definitions" (o "Data Type Definitions") son escritos en el formato Extended
Backus Naur Form, sin embargo, este formato presenta varias deficiencias, la más obvia es
expresividad, el siguiente DTD define las características de un fragmento XML que maneja
productos [18]:
<!ELEMENT producto (nombre+)> <!ELEMENT nombre (disponiblidad, descripcion*)> <!ATTLIST nombre modelo CDATA #REQUIRED> <!ELEMENT disponibilidad (#PCDATA)> <!ATTLIST disponibilidad lugar (almacen | exposicion | ambos) #IMPLIED <!ELEMENT descripcion (#PCDATA)>
La primer línea indica que el elemento producto contiene uno o mas elementos llamados nombre.
La siguiente línea describe que el elemento nombre esta compuesto por un elemento llamado
disponibilidad seguido de cero o más elementos llamados descripción.
Posteriormente <ATTLIST> nombre, indica que serán definidos los atributos del elemento nombre,
en este caso modelo el cual es obligatorio (#REQUIRED) y esta compuesto por texto simple
(CDATA).
MISC-03-1-2
143
La quinta línea define que el elemento disponibilidad estará compuesta por texto simple
(PCDATA).
<ATTLIST disponibilidad, empieza a definir los atributos del elemento disponibilidad, en este
caso el único atributo es llamado lugar y esta restringido a los valores almacén, exposición y ambos. Finalmente se indica que el elemento descripción consta de texto simple (PCDATA).
Para emplear este DTD es necesario indicarlo en el documento XML, esto se hace en lo que es
denominado Prologo , el fragmento XML anterior terminaría con la siguiente definición (asumiendo
que el DTD fue nombrado producto.dtd):
<?xml version="1.0"?> <DOCTYPE producto SYSTEM "producto.dtd"> <producto> <nombre modelo="xdfsdf"> <disponibilidad lugar="almacen"> Si </disponibilidad> <descripcion> 60 Watts Doble Canal </descripcion> </nombre> </producto>
La línea <DOCTYPE producto SYSTEM "producto.dtd"> declara que será utilizado el DTD
producto.dtd que reside en el mismo directorio del documento en cuestión. Un valor como
http://misitio.com/xml/dtds/producto.dtd indicaría que el DTD reside en un sitio Web.
A partir de este punto es posible introducir este documento a un programa que haga uso de un
"Parser" DOM ((Document Object Model) o SAX(Simple Api for XML), y mediante las funciones
del "Parser" será validada y manipulada la información del documento.
10.10.3 Namespaces
El concepto de Namespaces surge de la necesidad para combinar diferentes aplicaciones en XML,
es una forma de agrupar distintos elementos para poder ser utilizados en un solo documento sin
ambigüedades, por ejemplo cuando se trabaja con proveedores y clientes que facilitan su
información en XML, debido a que están en la misma industria es muy probable que ya utilicen
MISC-03-1-2
144
elementos en común como <monitor> , <software> , entre otros. Si se desarrolla un programa que
haga uso de estos elementos comunes es mediante Namespaces que se puede saber si un elemento
pertenece a un cliente o proveedor especifico [18].
El siguiente fragmento de código ejemplifica nuevamente el manejo de productos, sin embargo
presenta una ambigüedad como se muestra a continuación:
<producto> <nombre modelo="xdfsdf"> <disponibilidad lugar="almacen"> Si </disponibilidad> <descripcion> 60 Watts Doble Canal </descripcion> </nombre> <empresa> <serie>5845-2543-8614</serie> <nombre>Sonido Real</nombre> </empresa> </producto>
Sobre el elemento <nombre> surge una ambigüedad, en que ocasión se trata de <nombre> con
atributo modelo y en cual <nombre> sub-elemento de empresa ?, a través de Namespace's se
elimina esta ambigüedad al procesar XML. Una definición con Namespace's seria la siguiente:
<producto xmlns="http://misitio.com/definiciones/producto.dtd" xmlns:dist="http://misitio.com/definiciones/distribuidores.dtd> <nombre modelo="xdfsdf"> <disponibilidad lugar="almacen"> Si </disponibilidad> <descripcion> 60 Watts Doble Canal </descripcion> </nombre> <dist:empresa> <dist:serie>5845-2543-8614</dist:serie> <dist:nombre>Sonido Real</dist:nombre> </dist:empresa> </producto>
Los atributos xmlns dentro de producto definen dos Namespace, uno que incluye el DTD de
productos y otro el DTD de distribuidores. Esta declaración de atributos puede darse en cualquier
MISC-03-1-2
145
elemento, la única implicación es el alcance, en el caso anterior los Namespace influyen en
cualquier elemento derivado del elemento producto una vez que termine el elemento producto estas
declaraciones dejan de surtir efecto.
Cada declaración de un Namespace incluye la ubicación del DTD en cuestión, la primera
declaración que carece de :xxx es conocido como el Default Namespace, esto significa que todo
elemento no definido explícitamente pertenece a este Namespace..
La segunda declaración contiene la palabra dist, esto indica que todo elemento definido
explícitamente con dist pertenecerá al Namespace con el DTD distribuidores.dtd, los elementos que
inician con dist: indican al parser el uso de un Namespace distinto , eliminando la ambigüedad del
elemento nombre.
10.10.4 Schemas
Un "schema XML" es algo similar a un DTD, define qué elementos puede contener un documento
XML, cómo están organizados, y que atributos y de qué tipo pueden tener sus elementos.
Un Schema además de basarse fuertemente en XML hace amplio uso de Namespace, a continuación
se describe el Schema para el DTD que se ha visto anteriormente [18].
<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs='http://www.w3.org/2001/XMLSchema'> <xs:element name="producto"> <xs:complexType> <xs:sequence> <xs:element ref="nombre" minOcurrs="1" maxOcurrs="1"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="nombre"> <xs:complexType> <xs:sequence> <xs:element ref="disponiblidad" minOcurrs="1" maxOcurrs="1"/> <xs:element ref="descripcion" minOcurrs="1" maxOcurrs="1"/> </xs:sequence> <xs:attribute name="modelo" use="required" type="xs:string"/> </xs:complexType> </xs:element>
MISC-03-1-2
146
<xs:element name="disponiblidad" type="xs:string"> <xs:complexType> <xs:attributeGroup ref="valoresDisponibilidad"> </xs:complexType> </xs:element> <xs:element name="descripcion" type="xs:string"/> <xs:attributeGroup name="valoresDisponibilidad"> <xs:attribute name="lugar" use="required"> <xs:simpleType> <xs:restriction base="xs:string"/> <xs:enumeration value="almacen"/> <xs:enumeration value="exposicion"/> <xs:enumeration value="ambos"/> </xs:restriction> </xs:simpleType> </xs:attribute> </xs:attributeGroup>
La primer porción del Schema declara que se trata de un documento XML, indicando además el uso
del Namespace calificado http://www.w3.org/2001/XMLSchema con el vocablo xs, esta
declaración no indica la visita al sitio www.w3.org para corroborar el Namespace, sino que le indica
al Parser el uso de este Namespace, el cual ya esta incluido dentro de la estructura local del Parser.
La segunda sección indica que el elemento producto esta compuesto por el elemento nombre el cual
al menos debe presentarse al menos una vez (minOcurrs) y máximo en una ocasión (maxOcurss)
Posteriormente se define el elemento nombre el cual estará compuesto por los elementos
disponibilidad y descripción los cuales ocurren mínimo y máximo una vez; además se define que el
elemento nombre contendrá el elemento modelo el cual es obligatorio (required) y es de tipo String
<xs:element name="disponiblidad" type="xs:string"> define que el elemento disponibilidad
contiene información de tipo String, dentro de esta declaración también se indica que disponibilidad
contendrá los atributos definidos en el grupo(attributeGroup) llamado valoresDisponiblidad.
La quinta parte del Schema define que el elemento descripción es de tipo String.
Finalmente se define el grupo de atributos(attributeGroup) llamado valoresDisponibilidad el cual
esta compuesto por el atributo lugar el cual es obligatorio (required)
El atributo lugar es restringido al tipo String mediante <xs:restriction base="xs:string"/>, a su vez
este String es restringido a los valores de: almacén, exposición, ambos mediante xs:enumeration
MISC-03-1-2
147
Una vez definido un Schema aún es necesario declararlo dentro del documento XML que lo usará,
su declaración es muy similar a la de un DTD en un documento XML partiendo que el schema
anterior fue nombrado producto.xsd:
<?xml version="1.0" encoding="UTF-8"?> <producto xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation='producto.xsd'> <nombre modelo="xdfsdf"> <disponibilidad lugar="almacen"> Si </disponibilidad> <descripcion> 60 Watts Doble Canal </descripcion> </nombre> </producto>
La declaración anterior indica que todo elemento derivado de producto pertenece al Namespace
http://www.w3.org/2001/XMLSchema-instance el cual es representado por el documento
producto.xsd. Al momento de ser procesado este documento XML, el Parser valida que la
composición del documento este de acuerdo al Namespace Schema definido, en este caso
producto.xsd
10.10.5 Procesamiento XML
XML es simplemente un lenguaje descriptivo, por si solo no hace nada mas que almacenar y
describir datos, para poder utilizar los datos almacenados en XML es necesario hacer un
procesamiento de los documentos, en este procesamiento se pueden hacer varias tareas, desde
validar un documento con su DTD, agregar o quitar elementos, o simplemente obtener sus datos
para ejecutar procesamiento con ellos[18].
En el procesamiento de los documentos XML, se utilizan principalmente dos métodos llamados
DOM y SAX.
El procesamiento DOM (Document Object Model) crea una estructura jerárquica de árbol en
memoria en esta se pueden añadir, eliminar y modificar los nodos del árbol de la aplicación , es una
recomendación en el W3C y esta pensado para que el documento se manipule como un “objeto” en
el sentido de la programación orientada por objetos
MISC-03-1-2
148
Las principales ventajas de DOM son:
- Puede ser agregado un nodo (Información) en cualquier punto del árbol.
- Puede ser eliminada información de un nodo en cualquier punto del árbol.
SAX (Simple API for Xml) es un modelo secuencial el cual genera eventos cada vez que procesa un
nodo del documento
- SAX es un parser ideal para manipular archivos de gran tamaño, ya que no ocupa generar
un árbol en memoria como es requerido en DOM.
- Es más rápido y sencillo que utilizar DOM
SAX no es un recomendación W3C pero se considera como un estándar de facto.
La sencillez de SAX tiene su precio, debido a que SAX funciona por eventos no es posible
manipular información una vez procesada, en DOM no existe esta limitación ya que se genera el
árbol jerárquico en memoria y es posible regresar a modificar nodos.
Adicionalmente el trabajo con SAX requiere una mayor cantidad de código, pero no existe un
método correcto u otro incorrecto, simplemente cada uno se usa según la aplicación que se desee
implementar.
La especificación más reciente de SAX es 2.0, y al igual que DOM 2.0 esta se incluye en casi todos
los Parsers disponibles del cual el mas popular es XERCES la implementación de Apache para java
y c++.
10.11 Proveedores de tecnologías para construir Web Services
En el mercado existen compañías proveedoras de software de diversos tamaños que han tratado de
apropiar el concepto de Web Services de diferentes maneras, en la siguiente tabla se presentan las
iniciativas de los más grandes proveedores de hardware y software del mercado actual, que han
incorporado los Web Services como estrategia de negocios para sus clientes [16].
MISC-03-1-2
149
PROVEEDOR PRODUCTO Y/O
SERVICIO DESCRIPCION
IBM Dynamic e-business Incluye una colección de tecnologías para Web Services, incluyendo SOAP como parte de WebSphere (derivado de Apache SOAP 2.2), herramienta WSDL y una implementación de UDDI. Varios de los productos que ofrece IBM en la actualidad, están siendo modificados para incorparar dentro de su portafolio los Web Services.
Microsoft .NET Aunque esta filosofía se basa en Web Services, incluye mucho más que esto pues ha generado un nuevo lenguaje C# y una capa común en tiempo de ejecución, sobre la cual se pueden hacer desarrollos con múltiples lenguajes de programación.
Sun Sun One (open net environment)
Sun creó la noción de Smart Web Services, que permite entender el contexto en el cual se desarrollan o invocan los servicios (identidad del usuario, tipo de dispositivo del cliente y políticas de privacidad entre otros), Smart Web Services contiene estándares para compartir esta noción de “contexto”. Sun basa su plataforma tecnológica en XML, SOAP, WSDL y UDDI, pero también amplia estas tecnologías con derivaciones de ebXML.
Oracle Oracle 9i Web Services Broker
También se basa en la perspectiva tradicional de SOAP, UDDI y WSDL. Hace énfasis en el uso de sus tecnologías de bases de datos como un Service Registry (broker) proveyendo seguridad y otros servicios de valor agregado como un intermediario entre el solicitante del servicio y el proveedor del servicio.
Macromedia Macromedia plattaform Provee un conjunto completo de herramientas para desarrollo de Web Services, para desarrolladores de todo tipo de habilidades.
10.12 Ejemplos de Web Services En esta sección se presentan algunos ejemplos que muestran claramente la funcionalidad de los
Work Flow.
10.12.1 Proceso de negocios y Work Flow
MISC-03-1-2
150
Los procesos de negocio son actividades que se pueden llevar fuera de las actividades
principales del negocio [10]. Ejemplos de estas actividades son: la venta de tiquetes de una
aerolínea, la administración del inventario de una bodega, una orden de compra de
muebles para oficina o para el hogar, Otro tipo de procesos puede ser más complejo y
pesado como por ejemplo hacerle seguimiento a una orden de pedido o a un paquete por
entregar.
Los Workfow son también procesos de negocio, que corren en un ambiente de tecnología
informática TI, soportados por alguna herramienta como MQSeries Workflow de IBM [10].Las
herramientas de Workflow permite a los negocios, definir cada uno de sus procesos de negocios
como una serie de actividades que llevan a cabo individuos o aplicaciones, La secuencia de las
actividades pueden variar dependiendo de las salidas de cada una de las actividades parciales [10].
Ejemplo 1: Un servicio de compra (que puede ser un simple cliente) está ordenando bienes a un
servicio de venta. El servicio de venta es un Web Services cuya interfaz está definida usando
WSDL. El servicio de compra está invocando el método “ordenar” del servicio de ventas usando
SOAP y el WSDL definition para el servicio de venta. El servicio de compra sabe que esperar en
el mensaje SOAP de regreso, debido a que este está definido en el WSDL definition para cada
servicio de venta. Observemos el ejemplo del Workflow y Web Services en la figura 10:
Servicio de Compra
OUT
IN
Servicio de Venta
OUT
IN
ORDEN
Bienes
Figura 1O: Workflow Simple
MISC-03-1-2
151
La figura muestra las cajas IN, OUT para cada Web Services involucrado en este workflow. Este
IN,OUT se definen usando WSDL . La herramienta que encapsula el código para crear el servicio
de compra, entrega el formato de la salida API para el servicio de venta, pero analizando y
trasformando el WSDL description para el servicio de ventas.
Ejemplo 2: La siguiente figura muestra una validación de crédito realizada por el servicio de ventas,
con el fin de asegurarse de que el comprador puede pagar los bienes antes de que le sean enviados.
La validación de crédito se realiza por medio de un Web Service público que está disponible para
servicios e-business en general..
En este ejemplo el servicio de compra y el servicio de venta son servicios e-business, que realizan
actividades relacionadas directamente con el negocio de la empresa. El servicio de validación de
crédito, entre otros, puede ser usado para mejorar el desempeño de las operaciones de las empresas.
Otros servicios e-business pueden ser: encuestas para medir la satisfacción de los clientes, servicios
de seguridad, entre otros.
La figura 11 ilustra el ejemplo del servicio de validación de crédito.
Servicio de Compra
OUT
IN
Servicio de Venta
OUT
IN
2.ORDEN
1. Bienes
Servicio de Validación de Crédito
3.Validar
Figura 11: Workflow más complejo [10]
MISC-03-1-2
152
Ejemplo 3: Un Web Services que puede servir como una actividad de un Workflow, puede a su vez
estar conformado por otra serie de actividades en secuencia (o workflows) [10] como se muestra en
la figura 12:
Servicio de Compra
Servicio de Venta
FLUJO PRIVADO
Servicio de Contabilidad de
Clientes
Servicio de Administración de
Inventario
Servicio de Validación de Crédito
IN OUT
FLUJO PUBLICO
Figura 12: Workflow compuesto [10]
El servicio de venta es un workflow que está encapsulado como un Web Service. Para este ejemplo,
el servicio de venta consta de una actividad de validación de crédito, una actividad de
administración de inventarios y una actividad de contabilidad de clientes.
El servicio de ventas presenta una interfaz simple al servicio de compras, usando un WSDL
definition, y oculta los detalles de bajo nivel del workflow que encapsula. En este ejemplo
contamos con un flujo público y un flujo privado.
Ejemplo 4: En la siguiente figura, el servicio de administración de inventarios se presenta como un
Workflow que incluye varios pasos. Por otra parte, el servicio de validación de créditos, que es
parte del workflow del servicio de ventas, va a un servicio de crédito público en Internet, el cual se
puede encontrar y enlazar usando la información entregada desde un register tal como el UDDI.
MISC-03-1-2
153
Esta figura sirve para ilustrar también, que por debajo todos los Web Services son aplicaciones
codificadas. Para este ejemplo (figura 13), el servicio de contabilidad de clientes es un EJB
(Enterprise Java Bean) encapsulado.
Servicio de Compra
Servicio de Venta
Servicio de Contabilidad de
Clientes
Servicio de Administración de
Inventario
Servicio de Validación de Crédito
IN OUT
FLUJO PUBLICO
Servicio Público de
crédito
FLUJO PRIVADO
Paso 1 Paso 2 Paso 3EJB
Figura 13: Composición avanzada de los Workflow con Web Services
Ejemplo 5. Dentro de las oportunidades de negocio que se pueden encontrar al hacer uso de los
Web Services, se identifican algunos servicios que generarían ventaja competitiva dentro de un
sector como el educativo.
En primera instancia describiremos un Web Service para la selección y montaje de capacitaciones
empresariales:
Servicio: selección de contenidos, horarios, docentes, recursos físicos (infraestructura) y
contratación de los cursos ofrecidos por diferentes universidades para las empresas que requieran
de los mismos .dentro de su plan de formación de empleados.
MISC-03-1-2
154
Beneficiarios del servicio:
Universidades que estén interesadas en ofrecer su portafolio de capacitación empresarial.
Empresas que desean servicios docentes particulares y esperan obtener, no de una sino de varias
universidades, la posibilidad de conformar estos portafolios.
Broker: conformado por la unión de dos o tres de las universidades que hagan parte del
proyecto.
La siguiente figura corresponde al servicio propuesto:
10.13 ¿Cuál es el beneficio de hacer uso de los Web Services?
• La mayoría de los grandes proveedores de infraestructura, están adicionando rápidamente
soporte para los modelos de los Web Services dentro de las plataformas que ofrecen.
• Los Web Services no son una revolución, son una evolución, a estándares 100% abiertos, de
inversiones anteriormente realizadas.
• Los Web Services podrían resolver realmente el problema de la interoperabilidad a través de los
sistemas y la integración de los componentes de los sistemas, permitiendo desarrollo rápido de
aplicaciones, y eventualmente, desarrollo de aplicaciones dinámicas [4].
• Se crean nuevas oportunidades de negocio, nuevos modelos de software para entrega, tales
como: pago por uso o pago por servicio.
Los Web Services, representan una nueva variante de la computación distribuida, donde la
integración es el foco principal. Los Web Services, representan un nuevo Modelo de Integración.
Los Web Services requieren de un proceso de colaboración, seguridad, manejo de transacciones,
monitoreo, registro y conexiones dentro de múltiples sistemas back-end [4].
El principal foco de los Web Services, es redefinir o abrir interfaces de acceso a los sistemas
existentes en la compañía, para habilitar la adición de nuevas líneas de ganancia.
Dentro de las muchas posibilidades que ofrecen los Web Services, se encuentra el hecho de que se
pueda establecer una inteligencia de mercados coherente, entre los miembros de una comunidad de
MISC-03-1-2
155
negocios. Las compañías pueden compartir intereses y/o objetivos comunes, participando en un
modelo económico común, que incremente la viabilidad del mercado[5].
Los Web Services pueden ser desarrollados para soportar diferentes actividades de TI tales como la
construcción de nuevas aplicaciones, la integración de aplicaciones existentes, la automatización de
los procesos de negocio y varias posibilidades de integración B2B. Los beneficios potenciales se
ven dependiendo del tipo de despliegue hecho, que incluye [13]:
• Incremento en la eficiencia de la operación de las TI (reducción de costos e incremento de
la adaptabilidad)
• La creación de aplicaciones ricas en funcionalidad para usuarios con experiencia.
• Generación de un back office eficiente y adaptable (CRM, SCM, administración de la
fuerza de trabajo, e-commerce)
• Mayor acceso desde tecnologías móviles
• Nuevos tipos de posibilidades para proveer servicios.
• Nuevos modelos de negocios que contemplen esta arquitectura.
• Facilita la integración de negocios empresariales (EAI) y/o la automatización de los
procesos del negocio.
La figura 14, presenta los beneficios potenciales de los Web Services y las posibilidades de
desarrollo.
MISC-03-1-2
156
Beneficiospotenciales
Posibilidades de
implantación
Nuevos modelosde servicio
Aplicaciones ricas en contenido Nuevos modelos
de negocio
Información como una utilidad
Acceso a dispositivosmóviles
Eficiencias de IT
Cadena de provisiones,cliente,Fuerza de trabajo,Ventaja de integraciónServicios Web expuestos
Estándares de InternetEstándares de la Arquitectura de Servicios Web
Fuentes de datos
Componentes de aplicación
Describir Encontrar Encapsular
Integración de Aplicacionesempresariales
Construcción deaplicaciones
Integración B2C Integración
B2B
Automatizaciónde los procesosDel negocio
Figura 14: Potenciales Beneficios y posibilidades de desarrollo de los Web Services [13]
10.14 ¿Cómo se ven los Web Services desde la perspectiva de los negocios electrónicos?
De acuerdo con Hagel [7], existen diferentes niveles o capas en la arquitectura de los Web
Services, que se pueden observar en la figura (15).
MISC-03-1-2
157
Estándares y ProtocolosEstándares y ProtocolosEstándares SWEstándares SW- WSDL (Web Services Description Languaje)- UDDI(Universal Description Dyscovery, and Integration)- XML (extensible markup Language)
Protocolos de ComunicaciónProtocolos de Comunicación- SOAP (Simple Object Access Protocol)- HTTP (HyperText Trnasfer Protocol)- TCP/IP (Transmission control protocol / Internet Protocol)
Matriz de ServiciosMatriz de Servicios
Utilidades CompartidasUtilidades CompartidasSeguridad, auditoria y medición de Desempeño de terceros y Facturación y Pagos
Utilidades de Administración de ServiciosUtilidades de Administración de ServiciosAprovisionamiento, Monitoreo, Aseguramiento de calidadde servicio, Sincronización, resolución de conflictos.
Utilidades Administración Conocimiento de RecursosUtilidades Administración Conocimiento de RecursosDirectorios, Brokers, Registries, Repositorios yTransformación de Datos.
Utilidades de Administración de TransporteUtilidades de Administración de TransporteColas de Mensajes, Filtros, medición, monitoreo,enrutamiento, colaboración de recursos.
ServicioServicio ServicioServicio ServicioServicio ServicioServicio
Application ServicesApplication Services
Figura 15: The Web Services Architecture [7] (página 107).
Los estándares y protocolos hacen posible realizar negocios electrónicos.
La Matriz de Servicios, hace el manejo de los servicios especiales dentro de los cuales están:
• Utilidades compartidas: Medición de desempeño para establecer niveles de servicio. Pagos
de servicios.
• Administración de Trasporte: Comunicación segura y confiable con recursos y otros Web
Services.
• Administración de. Conocimiento de Recursos: Describe otros Web Services y como
accederlos. Hace el manejo de recursos.
• Administración de. Servicios: Proveer Servicios de forma confiable, monitoreándolos para
cumplir niveles de servicio y calidad.
Application Services: Servicios especiales para soportar el día a día de los negocios.
De acuerdo con esta gráfica, las Wire stack y la Description Stack se encuentran en la base de la
gráfica . La Discovery Stack, están en la segunda capa, la capa de negocio ese encuentra en el
mismo nivel.
MISC-03-1-2
158
10.15 ¿Por qué es interesante hacer uso de los web services?
Observemos la línea del tiempo de la adopción de los Web Services, y algunas prospectivas que
nos pueden dar un indicio de la relevancia de entrar en esta nueva era.
La figura 16, presenta la línea de tiempo de adopción de acuerdo con IDC [13].
Integ
ració
n simplifi
cada
Integ
ració
n simplifi
cada de de a
plicac
iones
aplic
acion
es
Producti
vidad
Producti
vidad
de de desa
rrollo
incre
mentad
a
desarro
llo in
cremen
tada
Conect
ividad
Conect
ividad
de de soc
ios
socios
de de neg
ocios
simplifi
cada
negoc
ios sim
plifica
da
Funcionali
dad
Funcionali
dad de de a
plicac
iones
enriq
uecida
aplic
acion
es en
riqueci
da
Servici
os basa
dos
Servici
os basa
dos en
en
suscr
ipción
suscr
ipción
Uso Uso de de s
ervici
os
servic
ios ca
sual/
ad hoc
casu
al/ad
hoc
Nuevos
modelo
s
Nuevos
modelo
s de de n
egoc
io posi
bles
negoc
io posi
bles
Uso Uso de de d
isposi
tivos
disposi
tivos
no no tra
dicion
ales
tradici
onale
s
2002
Dentro del
Firewall
2004
Usuarios externos
Contenidos
2006 2008
Busqueda y uso dinámico
Comod
izació
n
Comod
izació
n del sof
twar
e
del sof
twar
e
Figura 16: Línea de Tiempo de Adopción de los Web Services [13]
Esta figura presenta ejemplos de la rata de adopción de los Web Services que IDC considera será
una tendencia dominante representativa. Los indicadores muestran que el 5% de las empresas en
cada uno de los años allí presentados, deberán adoptar los Web Services.
Es importante tener presente que: El tiempo se verá influenciado por la disponibilidad de
tecnologías apropiadas y por la disponibilidad de experiencia en el desarrollo de la implantación del
Web Service.
La forma en que se adopten estas nuevas tecnologías tendrá una figura muy similar a la que
ocurrió con las fases de adopción de las tecnologías para Internet: intranet, extranet y la red mundial
Internet. IDC ha categorizado estas fases como: Desarrollo dentro del firewall, selección de aliados
de negocio e identificación de usuarios específicos, despliegue dinámico completo.
MISC-03-1-2
159
Etapas de adopción:
1. Dentro del Firewall: esta es la fase actual la que estamos viviendo, los mínimos requerimientos
para esta implantación son:
• La habilidad para crear nuevos Web Services o para encapsular aplicaciones existentes
como Web Services.
• La habilidad para definir requerimientos de funcionalidad, ubicación e interoperabilidad
utilizando WSDL.
• La disponibilidad de un ambiente en tiempo de ejecución que puede enviar y recibir
mensajes a través de los protocolos de Web Services (Ej. SOAP).
2. Usuarios externos contenidos: esta etapa se espera para el 2004. Dependiendo de la naturaleza de
las aplicaciones publicadas se pueden agregar los siguientes requerimientos a la infraestructura del
WS.
• Autenticación de usuarios con “global single sign-on”
• Acuerdos de encripción y otros tópicos de seguridad.
• Acuerdos en el estándar para la administración de transacciones a través de Web Services.
• Acuerdo en los estándares para la automatización de los procesos de negocio.
• Estándares para el formato de documentos XML.
• Productos para implementar y automatizar todos estos requerimientos.
3. Uso y búsqueda dinámica: esta etapa se espera entre el 2006 y el 2008. Este es el foco real de los
Web Services: dar a una aplicación la habilidad de reconocer la necesidad de llevar a cabo
funciones particulares para luego encontrar un Web Services apropiado y utilizarlos dinámicamente
sin intervención humana.
Esta fase requiere nuevas funcionalidades con los siguientes requerimientos:
• Creación de herramientas adicionales que ayudan a los desarrolladores a crear dichas
aplicaciones.
• El establecimiento de directorios, de servicios disponibles (implementados usando
estándares UDDI).
• Automatización de los términos y condiciones de negocios.
• Monitoreo y administración de los acuerdos del nivel de servicios (SLAs).
MISC-03-1-2
160
10.16 ¿Qué se espera a futuro?
Los Web Services podrán tener un efecto profundo en el desarrollo tecnológico mundial.
Los efectos serán en los siguientes aspectos [13]:
10.16.1 La infraestructura de software
• Entornos de desarrollo para crear nuevos Web services y para construir nuevas aplicaciones
a partir de Web services.
• Entornos de administración para asegurar niveles de servicio apropiados y, a futuro, proveer
información para el uso de Web services comerciales
• Entornos en tiempo de ejecución para administrar el envío y recepción de documentos y
otros tipos de datos y archivos
• Tecnología de encapsulamiento para exponer funciones heredadas como Web services
10.16.2 El software de aplicación
Se ven los Web services como una forma de integrar dinámicamente componentes dispersos
ejemplos:
• SAP anuncio que va a mejorar su servidor de aplicaciones Web para proveer componentes
de aplicación como Web services y para integrarse con cualquier aplicación y Web service
de otros proveedores.
• Peoplesoft tiene planes de utilizar el concepto de WSA como una forma de integrar su
propia lógica de negocios a través de suites de aplicaciones.
Servicios profesionales (consultoras)
Las firmas de servicios de TI jugarán un rol importante en la aceleración de la adopción de
Webservices. Cómo? Traduciendo los beneficios de TI en Soluciones de Negocio
MISC-03-1-2
161
Las empresas de servicios profesionales podrán jugar varios roles, dar recomendaciones y
responder a ciertos desafíos.
Roles
• Consultoría
• Integración de componentes con la arquitectura ya existente
• Constructores de WS para los proveedores de tales servicios
• Agregando y administrando SLAs de Web Services
Desafíos
• Expresar las ventajas de Web Services en términos de negocios
• Asegurar confiabilidad, monitoreo y garantizar niveles de desempeño
• Asegurar seguridad fuera de la Intranet
Recomendaciones
• Construir habilidades
• Traer las ganancias al departamento de IT
• Administración de expectativas
• Considerar las relaciones con los partners y las alianzas
10.16.3 Sobre los proveedores de servicio
Los Web Services no cambian el juego final, sólo prometen ayudarnos a alcanzarlo más fácil
10.16.4 Relaciones con partners y alianzas
Los vendedores no pueden esperar a que los partners eduquen a los usuarios acerca de los Web
Services, deberán iniciar ellos mismos este proceso
MISC-03-1-2
162
10.17 CONCLUSIONES
Los Web Services, no son una idea nueva, sin embargo, si son una oportunidad de lograr la
interoperabilidad de los sistemas actuales y de que cada empresa se concentre en su negocio.
Los Web Services permitirán que se sigan usando los sistemas legado de las empresas y que éstas se
conecten a la vez con sus partner de negocios, haciendo uso de Internet como canal de
comunicación. Esto no excluye la posibilidad de crear Web Services al interior de las
organizaciones (intranet) y con algunos aliados particulares (extranet), para lograr así la
optimización de procesos y operaciones.
Los Web Services son una oportunidad de negocio no sólo para las empresas que desarrollen y
publiquen sus servicios, sino también para las empresas consumidoras de servicios y para los
vendedores de hardware y software que necesitarán hacer cambios radicales en la forma de orientar
sus ventas, además de desarrollar nuevos productos que permitan manejar Web Services.
El concepto de programación orientada a objetos facilita el entendimiento del proceso de desarrollo
de los Web Services, así como su fundamentación básica en el concepto de encapsulamento.
10.18 PROFUNDIZACION
Web Services.ORG: This web site is a central jumping-off point to everything related to Web Services. It includes News, Software, Events and Papers. Visit http://www.webservices.org/.
UDDI.ORG: Este es el sitio web para el Registry y el Repository. Prove detalles de UDDI, con información adicional de WSDL y SOAP. http://www.uddi.org/.
W3C.ORG: Es el World Wide Web Consortium, donde se encuentran publicaciones de trabajos realizados o en construcción. Adicionalmente se encuetran papers y recomendaciones relacionadas con las especificaciones de XML, SOAP, UDDI y WSDL. Parte 1: Messaging Framework” specification is at http://www.w3.org/TR/2001/WD-soap12-part1-20011002/, with “SOAP Version 1.2 Parte 2: Adjuncts” at http://www.w3.org/TR/2001/WD-soap12-part2-20011002/.
SOAPRPC.COM: Este es un sitio web que prove papers, noticias, software y recursos para construir Web Services, SOAP, WSDL y UDDI. http://www.soaprpc.com/.
MISC-03-1-2
163
XML Cover Pages: Robin Cover maintains a section of his XML Cover Pages web site dedicated to Web Services. He includes an abstract on each topic, with links to the topic detail and related information. Visit http://www.oasis-open.org/cover/wsdl.html.
Microsoft on UDDI: Microsoft tiene un sitio web de UDDI que prove los links al UDDI de Microsoft, tambien poseelinks para UDDI, WSDL and SOAP. http://uddi.microsoft.com/developer/default.aspx.
IBM on WSDL: IBM ofrece muchos artículos, Fuentes, software y links para su sitio web DeveloperWorks http://www-106.ibm.com/developerworks/web/library/w-wsdl.html?dwzone=web.
IBM Corporation: IBM – Es otro de los fundadores del estándar de desarrollo de los Web Services. Se encuentra información en http://www.ibm.com/xml/. Y http://www-106.ibm.com/developerworks/xml/library/ws-wscd.html
Microsoft Corporation: http://www.microsoft.com/business/articles/net/netvision.asp para artículos de discusión o en http://www.microsoft.com/net/ .
Software AG: El software AG EntireX Web Services Development Environment soporta la integración usando varias tecnologías RPC incluyendo Web Services, Java, CORBA y COM. http://www.softwareag.com/ o http://www.softwareagusa.com/. Y http://www.softwareag.com/.
Hewlett-Packard: HP está extendiendo su software e-Speak para soportar iniciativas de Web Services y lenguajes relacionados. http://www.hp.com/ .
SUN: The Sun Open Net Environment (Sun.ONE)está siendo desarrollado por SUN para soportar Web Services Esta es una respuesta a la iniciativa .NET de Microsoft.http://www.sun.com/
Clear Case: La plataforma CapeConnect Web Services y CapeStudio Rapid Development Platform proven el soporte para el desarrollo y la entrega de Web Services. Visit http://www.j2ee-xml-ejb.com/.
10.19 BIBLIOGRAFIA
[1] Van Eyle, Ben. Web Services – A Business Perspective on Platform Choice.
http://www.theserverside.com/resources/article.jsp?l=WebServices Agosto 2001.
[2] Kirtlad, Mary, The Programmable Web - Web Services Provides Building Blocks for Mirosoft
.NET Framework.
www.msdn.microsoft.com/msdnmag/issues/0900/WebPlataform. Fecha de Consulta, Noviembre 23
de 2001.
[3] McDougall, Paul. Decoding Web Services. www.Informationweek.com, Octubre 2001.
[4] Rodhy, Sean. The Information Paradox. Web Services Journal. November 2001.
MISC-03-1-2
164
[5] Govoni, Daren. Information Syndication Using Web Services. A dynamic way to share data and
boost profitability. Web Services Journal. November 2001.
[6] Mikula, Norbert. Mission Critical Web Services. Mission impossible? Web Services Journal.
November 2001.
[7] Hegel III, John & Brown John. Your Next IT Strategy. Harvard Business Review Oct
2001.
[8] Taller de Web Services Microsoft Colombia. Conferencista: Ricardo González Vargas.
Pontificia Universidad Javeriana, Marzo 12 de 2002.
[9] Thomas, Anne Manes CTO, Systinet (formerly known as Idoox), Understanding UDDI.
www.uddi.org. Fecha última consulta: Febrero 15 de 2002.
[10] Kreger, Heather. Web Services Conceptual Architecture (WSCA 1.0). IBM Software Group.
May 2001.
[11] Microsoft. UDDI Microsoft, http://uddi.microsoft.com, fecha última consulta Febrero 15 de
2002
[12 ] http://uddi.org, UDDI Technical Withe Paper. September 6, 2002
[13] Hailstone, Rob; Byron, Dennis; Hendrick, Stephen; Mayo, Sophie; McHale, Steve .
Web Services Adoption Timeline and Related Business Opportunities. http://www.idc.com Febrero
2002
[14] Brittenham, Peter Web Services Development Concepts (WSDC 10).IBM Mayo 2001
[16] Graham, Simeonov et all. . Building Web Services With Java. Making Sense of XML, SOAP,
WSDL and UDDI. Editorial SAMS. Diciembre de 2001.
[17] Box, Don, Ehnebuske et all. Simple Object Protocol (SOAP) 1.1 W3C Note 08 May 2000.
[18] OsmosisLatina, Schemas, Namespaces y DTD's,
http://www.osmosislatina.com/xml/schemas.htm, Marzo 2002.
[19] Morrison, Michael et al. XML Al descubierto. Prentice Hall 2000
MISC-03-1-2
165
11 ANEXO 1 . LEVANTAMIENTO DE PROCESOS
CVEC - CICLO DE VIDA DEL ESTUDIANTE EN LA CARRERA
CICLO DE VIDA DEL ESTUDIANTE EN LA CARRERA
OBJETIVO DEL PROCESO
Presentar las actividades inherentes a la permanencia de los estudiantes de la Facultad de Ingeniería,
desde su admisión en un programa académico hasta su culminación, sea por exclusión, retiro,
transferencia o como egresado.
ALCANCE DEL PROCESO:
Este proceso involucra las actividades de admisión, planeación y ejecución de cada semestre hasta
el grado. Comprende las decisiones de permanencia tales como: transferencias, reintegros,
exclusiones, reingreso y admisión en doble programa. Esta
regido por el reglamento de la Facultad.
DEFINICIÓN DE TÉRMINOS
Aspirante: Persona inscrita que ingresa al proceso de admisión a un programa académico de la
Facultad de Ingeniería
Doble programa: Estudiante que realiza dos programas académicos de la Facultad de Ingeniería de
manera simultánea
Excluido: Estudiante que no cumple los requisitos de permanencia en la Universidad
Graduando: Estudiante que ha cumplido con los requisitos exigidos, para optar por el título
Neojaveriano: Aspirante admitido por primera vez a un programa académico de la facultad de
Ingeniería
Retiro Voluntario: Estudiante que por razones personales, estando en condiciones de permanencia,
decide no continuar en la carrera
MISC-03-1-2
166
Transferencia o Transferencia Externa: Solicitud de cambio de un estudiante de otra institución
académica hacia una carrera de la Facultad de Ingeniería
Traslado: Solicitud de cambio de un estudiante entre programas académicos de la Universidad el
cual puede ser interno, si ocurre entre carreras de la Facultad de Ingeniería.
En el reglamento esta definido como transferencias entre carreras de la Facultad y transferencias
internas
Reingreso: Solicitud de un estudiante que efectúa retiro total de asignaturas o que no se matricula en
un periodo lectivo semestral y desea continuar estudios en la Facultad
Reintegro: Solicitud de un estudiante excluido para vincularse de nuevo a la carrera
PRECONDICIÓN:
Lista de inscritos preseleccionados en cada periodo, con la información de soporte (ICFES, datos
personales).
Reglamento de la Facultad.
Cupos.
Autorizaciones de reintegro, transferencia hacia la facultad, doble programa, y reingreso.
POSTCONDICIÓN:
Lista de graduandos del periodo.
Lista actualizada de egresados.
Lista de excluidos, retirados, transferidos hacia otras facultades.
DESCRIPCIÓN:
Realizar admisión.
Planear y ejecutar cada periodo académico.
Dependiendo del estado académico resultante de cada periodo se registra estado de normalidad,
matricula condicional, exclusión, retiro, transferencia o graduando.
Preparar y realizar grado.
Manejar la relación con egresados.
SISTEMAS DE APOYO:
RAI (Registro de estado) y Excel (Estadísticas)
MISC-03-1-2
167
CALLES
Centro de Apoyo Profesional (C.A.P.)
9. Relación con egresados
Mantener el contacto con los egresados de la Facultad, estos procesos se describen en los siguientes
diagramas:
Educación no formal: REEC-Ofrecer y realizar cursos de educación continuada.
Bolsa de empleo y desarrollo: REEC- C.A.P. Centro de Apoyo profesional.
Programas Académicos de Postgrado: REEC- Postgrados.
Comité de Admisiones y Programa Académico
1A. Preseleccionar traslados/ transferencias
Admisión por transferencia
Recibir en Admisiones y Registro Académico el formulario de solicitud de transferencia, registrar
en el sistema los estudiantes opcionales (tipo O). En el caso de transferencias Internas y externas el
solicitante debe anexar al formulario los documentos descritos en el numeral 7.4.2.2 del
Reglamento de la Facultad de Ingeniería.
Estudiar la solicitud en el Comité de Admisiones y Transferencias de la Carrera destino, entrevistar
al estudiante y emitir concepto, de acuerdo con el promedio de las asignaturas equivalentes
aceptadas, y la disponibilidad de cupo. En todo caso, el máximo semestre en el cual puede ser
admitido un estudiante por traslado o transferencia es séptimo.
Atender exámenes de validación de asignaturas cuando sea determinado como condición de
aceptación.
Decidir la aceptación o rechazo de la solicitud. Esta decisión compete a los Decanos de la Facultad.
Definir el estado académico en que es admitido el estudiante.
Suscribir el acta de equivalencia entre el solicitante admitido y el director de carrera con las notas
homologadas
1B. Preseleccionar aspirantes
Planear entrevistas.
MISC-03-1-2
168
Publicar lista de llamados a entrevista
Realizar entrevistas
Elaborar la lista de los estudiantes admitidos después de entrevista
Decanatura Académica y del Medio
2. Admitir por transferencias, traslados, reingresos y reintegros
Recibir, atender y decidir respecto de la solicitud de transferencia, traslado o reintegro, en
Decanatura.
La solicitud de reingreso, se resuelve en el Consejo de la Facultad, si el estudiante ha permanecido
en retiro por un periodo superior a tres años.
3. Admitir Neojaverianos
Decidir sobre la admisión o no de los aspirantes preseleccionados.
4. Planear y ejecutar semestre (CAS)
El conjunto de actividades académicas y administrativas inherentes a cada periodo semestral se
describen en detalle en el proceso:"CAS -CICLO ACADÉMICO SEMESTRAL". El resultado de
este proceso es el estado académico actualizado de cada estudiante.
7. Preparar grado
Elaborar lista de estudiantes con trabajo de grado aceptado, enviarla a Vicerrectoría Académica para
elaboración de los diplomas y a Secretaría para control de Paz y Salvo.
Generar notas históricas y resolver inconsistencias por curso de vacaciones
Emitir Paz y salvos de laboratorios.
Recibir en ventanilla y validar la documentación correspondiente a los requisitos para graduandos
Solicitar los diplomas a Vicerrectoría Académica
Firmar los diplomas
Definir fecha de ceremonia de graduación. Realizar reunión previa a la ceremonia.
8. Realizar grado
Efectuar la ceremonia de graduación y suscribir el acta de grado.
MISC-03-1-2
169
Archivar el acta de grado en la secretaria de la Facultad.
Estudiante
5. Solicitar Traslado
Durante el ejercicio de su carrera, el estudiante puede solicitar transferencia a otra universidad o
traslado dentro de la Universidad Javeriana.
Si se trata de una transferencia hacia otra Universidad, el proceso a seguir es determinado por la
Institución de destino y por tanto no se incluye en este modelo de negocio.
Si se trata de un traslado dentro de la Universidad, el procedimiento a seguir con la solicitud se
describe en las actividades: "Manejar Inscripciones" y "Admitir por traslado", que hacen parte de
este diagrama.
6. Solicitar autorización doble programa
Un estudiante activo puede optar por cursar doble programa, en este caso se manejan dos estados
académicos independientes. El único estado de un programa que puede afectar el otro es el de
expulsión.
Oficina de Admisiones y Registro Académico
1. Manejar Inscripciones
Recibir de la Oficina de Admisiones y Registro académico la siguiente información de aspirantes
(registrados en el sistema como tipo O):
Caso Neojaverianos:
Lista de aspirantes presentados.
Lista de aspirantes ordenada por puntaje del ICFES.
Lista de aspirantes ordenada por mayor promedio de las asignaturas en el ICFES.
Formularios de inscripción con sus anexos.
Caso Doble Programa
El estudiante debe realizar la inscripción en la oficina de admisiones y registro académico
Formularios de inscripción con sus anexos
MISC-03-1-2
170
Caso Reintegros y Reingresos: Este proceso se lleva a cabo en el interior de la facultad
Traslados y Transferencias
Reclamar y presentar formulario de solicitud en la oficina de admisiones y registro académico.
Recibir el formulario de solicitud con los respectivos anexos.
Secretaría
3A.Registrar y publicar Estado
Publicar las listas de admitidos.
Registrar en el sistema el estado de admitido (Tipo A), y generar el recibo de pago. Una vez el
estudiante entregue el recibo de pago cancelado se registra en el sistema el estado de matriculado
(Tipo M).
Registrar en el sistema las notas consignadas en el acta de equivalencia si el ingreso se ha realizado
por traslado o transferencia.
MISC-03-1-2
171
CICLO DE VIDA DEL ESTUDIANTE EN LA CARRERA
MISC-03-1-2
172
PSPA – PLANEACIÓN Y SEGUIMIENTO DEL PROGRAMA ACADÉMICO
DIAGRAMAS DE ACTIVIDADES
(PLANEACIÓN Y SEGUIMIENTO DEL PROGRAMA ACADÉMICO
OBJETIVO DEL PROCESO
Validar que los currículos atiendan los aspectos de formación académica, religiosa, humanística y
social de acuerdo con los objetivos específicos de la Universidad y de la Facultad.
ALCANCE DEL PROCESO
Este proceso esta dirigido a los currículos de los programas académicos de pregrado y postgrado de
la Facultad.
PRECONDICIÓN
Currículos vigentes para cada programa académico
POSTCONDICIÓN
Currículos actualizados de cada programa académico
HERRAMIENTAS DE APOYO
SIC
CALLES
Comité de Currículo: General y Particular
1. Recomendar creación de programa académico
Los comités general y particular de currículo pueden recomendar al Consejo de la facultad la
apertura de un nuevo programa académico.
MISC-03-1-2
173
10. Proponer cambios al currículo
Los comités de currículo pueden recomendar al Consejo de la Facultad cambios en el currículo de
un programa académico, tales como adición /supresión de asignaturas, de créditos y de
prerrequisitos.
15. Conformar nuevas asignaturas
Establecer los contenidos, bibliografía, metodología y demás componentes de una nueva asignatura.
16. Actualizar contenidos de asignaturas
Incluir dentro del contenido de las asignaturas aquellas modificaciones que sean aprobadas por
Vicerrectoría académica o el Consejo de la facultad.
17. Actualizar plan de estudios
Incluir las asignaturas nuevas, reformar o retirar asignaturas existentes, con el fin de crear un plan
de estudios actualizado
Determinar prerrequisitos, correquisitos, créditos, obligatoriedad de cada una de las asignaturas en
el nuevo plan de estudios
Incluir en el plan de estudios las decisiones tomadas con el fin de conferirle flexibilidad currículo.
Recomendar al consejo de la Facultad la creación o supresión de programas de postgrado y
educación continuada
19. Hacer seguimiento de acreditación
Formular y hacer seguimiento al plan de mejoramiento continuo con el fin de mantener la
acreditación del programa académico.
Suministrar al ente acreditador la información que éste solicite con el fin de realizar las
verificaciones de su competencia.
7. Realizar reflexión curricular
La reflexión curricular considera los siguientes criterios en relación con el Plan de Estudios:
Pertinencia: Este criterio evalúa en el currículo su impacto y adaptación en el contexto nacional e
internacional.
MISC-03-1-2
174
Calidad: Este criterio determina en qué medida el enfoque del Programa Académico está acorde con
la Misión de la Universidad, y en qué medida éste es fiel al proyecto educativo.
8. Revisar contenidos de asignaturas
Evaluar los contenidos de las asignaturas de conformidad con los objetivos establecidos en el
currículo.
9. Recomendar cierre de programa académico
Los comités de currículo pueden recomendar al Consejo de la Facultad el cierre de un programa
académico.
Consejo de Facultad / Vicerrectoría Académica
11. Autorizar cierre de programa académico
El Consejo de la Facultad, con la aprobación de la Vicerrectoría Académica pueden cerrar un
Programa académico determinado.
12. Autorizar nuevas asignaturas
Aprobar la inclusión de asignaturas dentro del currículo.
13. Autorizar cambios en asignaturas
Evaluar y dar aprobación o refutar cambios en los contenidos de las asignaturas.
14. Aprobar modificaciones al plan de estudios
La aprobación de cambios curriculares está a cargo del Consejo de la facultad y/o de la
Vicerrectoría Académica, a no ser que se trate cambios menores.
2. Autorizar creación de programa Académico
"Los currículos de las carreras serán fijados de acuerdo con las normas del Reglamento general".
MISC-03-1-2
175
Director Departamento
20. Ofrecer asignaturas de currículo actualizado
Ofrecer a los diferentes programas académicos las asignaturas propias del currículo actualizado.
3. Conformar programa académico
Definir los objetivos, el plan de estudios, contenidos de las asignaturas, crédito y demás
componentes de un nuevo programa académico.
Director de Programa Académico
18. Implantar currículo actualizado
Poner en funcionamiento el currículo actualizado.
Administrar el cambio de currículo para estudiantes con planes de estudio anteriores.
4. Conformar programa académico
Definir los objetivos, el plan de estudios, contenidos de las asignaturas, crédito y demás
componentes de un nuevo programa académico.
5. Registrar programa ante el ICFES
Cumplir los requisitos para aprobación del programa ante el ICFES.
Registrar el programa académico ante el ICFES.
MISC-03-1-2
176
PLANEACIÓN Y SEGUIMIENTO DE PROGRAMA ACADÉMICO
MISC-03-1-2
177
CICLO ACADÉMICO SEMESTRAL
DIAGRAMAS DE ACTIVIDADES
CICLO ACADÉMICO SEMESTRAL (GENERAL)
OBJETIVO DEL PROCESO
Ejecutar la logística asociada con la prestación del servicio de docencia durante cada periodo
académico semestral.
ALCANCE DEL PROCESO
Este proceso involucra las actividades de planeación de grupos, matrícula financiera, matrícula
académica y actualización del estado académico. Está regido por las normas y procedimientos
relacionados con: Servicios prestados entre la Unidades Académicas; Recaudo de Matrículas y
Registro académico.
PRECONDICIÓN
Hoja de Vida actual de cada estudiante.
Estado académico actual de cada estudiante
Estado financiero actual de cada estudiante
Proyección de grupos y horarios para el periodo
Lista de estudiantes activos
Salones
POSTCONDICIÓN
Grupos
Horarios
Listas de estudiantes por grupo
Listas de salones por grupo
Recibos de pago
Notas
Estado académico de cada estudiante después del periodo
Estado financiero de cada estudiante después del periodo
MISC-03-1-2
178
Hoja de Vida de cada estudiante después del periodo, con novedades de consejería, intercambio,
proyecto de grado, consultoría universitaria y pastoral
Evaluación del profesor de cada grupo
DESCRIPCIÓN
1. Planeación de Grupos
Ajustar grupos y horarios
Asignar salones
2. Matrícula Financiera
Recibir pagos
Determinar estados de morosidad, retiro provisional (notificado o no notificados)
3. Matrícula Académica
Correr prematrícula
Realizar cambios de grupos
Modificar matricula académica
Emitir listas de grupos definitivos
4. Manejar período académico
Enseñar las asignaturas
Realizar y evaluar proyectos de grado
Evaluar profesores
Administrar laboratorios y equipos
5. Actualizar estado académico
Actualizar el estado académico
Controlar el pago y recaudo de servicios del departamento
SISTEMAS DE APOYO
Excel: Planeación de grupos y salones, control de servicios del departamento, estadísticas
Internet: Horarios y notas
MISC-03-1-2
179
RAI: Notas y estado académico
RISCADMIN y RISCACAD: Recibos de pago
Sistema de Información de Vicerrectoría Académica: Evaluación de Profesores
CICLO ACADÉMICO SEMESTRAL (GENERAL)
MISC-03-1-2
180
CICLO ACADÉMICO SEMESTRAL DETALLADO
OBJETIVO DEL PROCESO
Ejecutar la logística asociada con la prestación del servicio de docencia durante cada periodo
académico semestral.
ALCANCE DEL PROCESO
Este proceso involucra las actividades de planeación de grupos, matrícula financiera, matrícula
académica y actualización del estado académico. Está regido por las normas y procedimientos
relacionados con: Servicios prestados entre la Unidades Académicas; Recaudo de Matrículas y
Registro académico.
PRECONDICIÓN
Hoja de Vida actual de cada estudiante.
Estado académico actual de cada estudiante
Estado financiero actual de cada estudiante
Proyección de grupos y horarios para el periodo
Lista de estudiantes activos
Salones
POSTCONDICIÓN
Grupos
Horarios
Listas de estudiantes por grupo
Listas de salones por grupo
Recibos de pago
Notas
Estado académico de cada estudiante después del periodo
Estado financiero de cada estudiante después del periodo
MISC-03-1-2
181
Hoja de Vida de cada estudiante después del periodo, con novedades de consejería, intercambio,
proyecto de grado, consultoría universitaria y pastoral
Evaluación del profesor de cada grupo
DESCRIPCIÓN
1. Planeación de Grupos
Ajustar grupos y horarios
Asignar salones
2. Matrícula Financiera
Recibir pagos
Determinar estados de morosidad, retiro provisional (notificado o no notificados)
3. Matrícula Académica
Correr prematrícula
Realizar cambios de grupos
Modificar matricula académica
Emitir listas de grupos definitivos
4. Manejar período académico
Enseñar las asignaturas
Realizar y evaluar proyectos de grado
Evaluar profesores
Administrar laboratorios y equipos
5. Actualizar estado académico
Actualizar el estado académico
Controlar el pago y recaudo de servicios del departamento
SISTEMAS DE APOYO
Excel: Planeación de grupos y salones, control de servicios del departamento, estadísticas
Internet: Horarios y notas
MISC-03-1-2
182
RAI: Notas y estado académico
RISCADMIN y RISCACAD: Recibos de pago
Sistema de Información de Vicerrectoría Académica: Evaluación de Profesores
CALLES
Admisiones y Registro Académico
23A. Generar listas definitivas
Generar los listados definitivos de los estudiantes en cada una de las asignaturas, estas son las listas
que se le entregan a cada uno de los profesores.
3. Correr matricula
Ordenar que se corra el proceso de matriculas en la oficina de Admisiones y Registro Académico de
la Universidad, una vez depurada la base de datos de los estudiantes de la Facultad.
Establecer las asignaturas que puede ver cada estudiante de acuerdo al plan de estudios, asignaturas
aprobadas y asignación de grupos.
Generar reporte de cupos, capacidades y número de alumnos no matriculados por asignatura en el
RAI
Carrera
10A. Devolver salones sobrantes
Entregar a Admisiones y Registro Académico de la Facultad, los salones que no van a ser ocupados
14. Realizar consejería
Prestar atención personalizada a los estudiantes y orientación en solución de situaciones académicas
y extra-académicas que puedan afectar su proceso de formación.
MISC-03-1-2
183
15A. Realizar seguimiento a proyectos de grado
Dar un continuo apoyo en el desarrollo de los proyectos llevados a cabo por los estudiantes.
Efectuar el seguimiento a las fases de elaboración de proyectos de grado tales como la formulación
del anteproyecto, aprobación del mismo y el seguimiento de avance de los diferentes proyectos de
grado que se realizan en el transcurso del semestre.
16. Evaluar proyectos de grado
Evaluar cualitativamente y cuantitativamente los proyectos de grado que se presenten durante un
periodo académico
Realizar la logística correspondiente a la asignación de jurados, sustentación y reporte de resultados.
1A. Planear grupos y horarios
Definir los grupos y horarios del semestre siguiente tomando como base las proyecciones obtenidas
en semestres anteriores.
24. Planear grupos y horarios
Proyectar los grupos del siguiente periodo de acuerdo a las estadísticas de aprobación de cada una
de las asignaturas.
25. Promover y realizar intercambios
Encontrar oportunidades de intercambio académico con otras universidades en el exterior.
Revisar el plan de estudios de la entidad oferente del intercambio y homologarlo al del programa
académico de la Facultad.
Realizar los convenios de intercambios.
Expedir las certificaciones de notas y contenidos de asignaturas requeridas por la institución.
Hacer seguimiento de desempeño de estudiantes en intercambio.
Incorporar las notas obtenidas por el estudiante en intercambio en las asignaturas correspondientes
al plan de estudios de la Universidad.
26. Realizar actividades extra-académicas
Organizar eventos que promuevan la formación académica y personal del estudiante
27. Realizar seguimiento a práctica profesional
MISC-03-1-2
184
Mantener un contacto directo con el sector industrial del país por medio de la práctica profesional
de los estudiantes.
Promover la contratación de los estudiantes en práctica
Evaluar las actividades realizadas y los aportes de los estudiantes durante la realización de la
práctica profesional
27A. Realizar seguimiento a consultorías universitarias
Mantener un acercamiento social con la realidad del País, por medio de las consultorías
universitarias de los estudiantes
Evaluar las actividades realizadas y los aportes de los estudiantes de la consultoría universitaria
29A. Definir estado académico
Determinar en conjunto con el Director de Carrera el estado académico de los estudiantes que
presentan algún tipo de problema en su continuidad en la carrera.
8. Realizar cambios de grupos
Modificar el horario de las asignaturas abriendo y cerrando grupos de conformidad con el número
real de preinscritos y la disponibilidad de profesores, horarios y salones.
Decanatura Académica
29A. Emitir informe de estado académico
Dar el visto de aprobación de los estudiantes que quedaron en matricula condicional, prueba
académica, excluidos.
Departamento
11. Planear prácticas de laboratorio
Proyectar el número de prácticas de laboratorio de cada una de las carreras con el fin de realizar la
labor logística de la misma.
MISC-03-1-2
185
17. Administrar laboratorios - equipos
Planear la adquisición, adquirir y controlar el uso de los recursos destinados a los laboratorios.
Suministrar soporte técnico en mantenimiento, esta tarea esta asignada a los laboratorios del
departamento de Sistemas
18. Evaluar profesores
Identificar, por medio de la aplicación de la encuesta de Vicerrectoría Académica de la Universidad,
la calidad de los servicios docentes suministrados por cada profesor para tomar acciones correctivas
y preventivas.
Informar sobre los resultados al profesor evaluado, acordar compromisos de mejoramiento y
hacerles seguimiento.
18A. Realizar la retroalimentación a los docentes
Sugerir a los docentes oportunidades de mejoramiento con base en las evaluaciones realizadas.
22A. Corregir Notas
Tramitar ante el Departamento que suministra la asignatura una solicitud de corrección de nota,
previamente refrendada por el profesor respectivo.
28. Controlar pago servicios departamento
Las actividades relacionadas con la prestación de servicios académicos entre departamentos se
describen en el diagrama CAS - Servicios docentes entre Unidades Académicas.
Estudiante
13. Firmar horario definitivo
Formalizar la matrícula académica por medio de la firma del horario definitivo.
15. Realizar proyectos de grado
Elaborar el anteproyecto de grado, una vez aprobado, cumplir con todos los objetivos propuestos
para su respectiva elaboración y así optar por el título como Ingeniero.
MISC-03-1-2
186
Profesor
19. Desarrollar Proceso Docente
Transmitir el conocimiento a los estudiantes de acuerdo al programa académico de cada una de las
asignaturas.
Controlar asistencia.
Orientar el proceso de formación del estudiante en la asignatura
19A. Preparar Materiales
Elaborar los materiales de apoyo a la enseñanza de las asignaturas a cargo del profesor.
Poner a disposición de los estudiantes estos materiales mediante entrega personal, fotocopias,
publicación en web.
21. Manejar notas
Llevar un control de notas de los estudiantes en cada una de las asignaturas.
Reportar las notas definitivas al final del semestre en los formatos establecidos.
Transcribir las nota.
Secretaría
1. Digitar horarios
Generar el reporte de "Creación de grupos: Asignaturas con grupos y horarios"
Digitar los horarios en el RAI con reasignación de horas
Corregir y digitar aquellas asignaturas que han cambiado de horario o las nuevas
10. Emitir listas de grupos definitivos
Verificar en el sistema las asignaturas, los horarios y los cupos
Generar el reporte de asignaturas y horarios
12. Controlar pagos vs créditos
Verificar que los créditos matriculados correspondan al valor de los créditos cancelados
MISC-03-1-2
187
Reportar inconsistencias encontradas para establecer estado de morosidad
2. Solicitar salones
Registrar correcciones en el sistema RAI
Generar listado de los grupos que no se les asignó salón, para reportarlos en Admisiones y Registro
Académico.
Registrar en el sistema las reasignaciones con cupo.
Negociar los cupos en Admisiones y Registro Académico.
20. Registrar retiros
Verificar las razones por las cuales un estudiante cancela una asignatura
Registrar en la base de datos (RAI) los retiros
22. Digitar corrección de notas
Realizar las correcciones pertinentes, verificando con el archivo físico o constatando directamente
con el docente involucrado.
23. Actualizar retiros, graduandos, y reintegro
Modificar el estado de los estudiantes dependiendo de si son retirados, graduandos o se reintegran a
la Facultad, con el fin de preparar el archivo de prematricula.
24. Emitir recibos
Generar los recibos de pago para los estudiantes activos y para los que se reintegran a la Facultad
29. Registrar en el RAI el estado académico
A partir del registro de las notas se actualiza automáticamente el estado de los estudiantes en el
sistema. Si el nuevo estado académico es en prueba, matrícula condicional o excluido, el trámite
respectivo se enuncia en el diagrama CVEC = Ciclo de vida del estudiante en la carrera.
2A. Digitar Notas
Registrar en el sistema las notas obtenidas por cada uno de los estudiantes en las diferentes
asignaturas.
MISC-03-1-2
188
6. Registrar en lista de morosos
Registrar en Excel los estudiantes que no entregaron el recibo de la matrícula cancelado
Enviar archivo a tesorería para actualizar el estado del estudiante
7. Registrar lista de retiro provisional
Registrar en una hoja electrónica los estudiantes que reportan retiro provisional del semestre. No se
ha establecido un control para los estudiantes que se retiran sin reportar.
9. Modificar matrícula académica
Ingresar en el sistema RAI, con el usuario predeterminado, con el propósito de realizar cambios en
los horarios de los estudiantes.
Realizar las modificaciones respectivas en el sistema de acuerdo a las necesidades acordadas con el
estudiante.
Tesorería
4. Cambio o emisión de recibo
Solicitar autorización ante la Decanatura del Medio para cancelar la matrícula en contados
Generar el nuevo recibo de pago con las fechas estipuladas para cada uno de sus pagos
5. Recibe pago
Registrar los pagos provenientes de los bancos, una vez el estudiante cancele el valor total o parcial
de su matrícula.
SERVICIOS DOCENTES ENTRE UNIDADES ACADÉMICAS
OBJETIVO DEL PROCESO
Representar el conjunto de actividades inherentes a la solicitud y pago de asignaturas ofrecidas
entre las Unidades Académicas de la Universidad.
MISC-03-1-2
189
ALCANCE DEL PROCESO
Este proceso tiene aplicación en las asignaturas que ofrecen los Departamentos de la Facultad de
Ingeniería, y las asignaturas que reciben de otros departamentos y del medio Universitario los
Programas académicos de la Facultad de Ingeniería.
PRECONDICIÓN
Oferta de Asignaturas.
Profesores.
Solicitud de servicios.
Plan de estudios.
POSTCONDICIÓN
Asignaturas impartidas.
Cuenta de Cobro por servicios docentes.
Pago de servicios docentes.
CALLES
Departamento
1. Planear oferta de servicios docentes
Definir el contenido de las asignaturas que ofrece el Departamento. El proceso en que se definen los
contenidos de asignaturas requeridos por los programas académicos de Ingeniería es PSPA-
Planeación y seguimiento del programa académico.
Determinar los recursos físicos que necesita la asignatura para ser ofrecida. (laboratorios, equipos,
instalaciones físicas).
Determinar el perfil , hoja de vida y disponibilidad horaria de los docentes que pueden estar a cargo
de la asignatura.
12. Evaluar al profesor
Esta actividad está descrita en el proceso ADRH Manejar Planta de Personal.
MISC-03-1-2
190
13. Controlar pago de servicio
Elaborar cuenta de cobro por concepto de los servicios docentes prestados a la Carrera o postgrado.
Hacer seguimiento al pago de la respectiva cuenta.
Verificar su incorporación como ingreso en el presupuesto del departamento.
3. Planear grupos y horarios
Con base en el reporte de "Grupos, capacidad y ocupación",proyectar el numero de grupos a
conformar por cada asignatura solicitada, de acuerdo con la disponibilidad de los profesores y
horarios.
Profesor
10. Generar notas
Generar y reportar las notas de los estudiantes inscritos en la asignatura.
11. Corregir notas
Presentar acta de corrección de notas en caso de aceptación de un cambio
9. Enseñar asignatura
Dar cumplimiento al programa de la asignatura
Programa Académico
14. Evaluar servicio
Determinar la calidad del servicio de docencia recibido, con base en las evaluaciones que realizan
los estudiantes respecto del profesor y de la asignatura.
2. Solicitar servicios docentes
Elaborar la solicitud de servicios de conformidad con los grupos por asignatura estimados para el
semestre.
MISC-03-1-2
191
Secretaría
4. Generar el reporte de "Grupos "
Generar en el sistema RAI el reporte de "Grupos, capacidad y ocupación", entregarlo a cada
Director de Departamento para tomarlo como base en la conformación de grupos.
5. Corregir en sistema
Registrar cambios de horarios, salones y grupos en el sistema RAI.
6. Asignar salones
Automáticamente el programa del RAI asigna los salones de acuerdo con la capacidad requerida. el
reporte de grupos, capacidad y ocupación.
Conseguir salón para grupos no asignados, mediante negociación con la Oficina de Registro
Académico.
7. Realizar matrículas
Durante el proceso de matrículas se abren y cierran grupos. Tras este proceso se definen los salones
para los grupos definitivos.
MISC-03-1-2
192
SERVICIOS DOCENTES ENTRE UNIDADES ACADÉMICAS
MISC-03-1-2
193
DIAGRAMAS DE ACTIVIDADES
PLANEACIÓN Y CONTROL DE GESTIÓN
OBJETIVO DEL PROCESO
Realizar la planeación, el diagnostico y el plan de trabajo de las actividades que hacen posible el
cumplimiento de la misión de la facultad de Ingeniería, bajo los lineamientos del Plan Estratégico
Corporativo.
Evaluar y controlar los resultados de gestión.
ALCANCE DEL PROCESO
Este proceso comprende la planeación y el seguimiento de actividades académicas, del medio
universitario y de los recursos financieros, no comprende indicadores de gestión porque éstos, si
bien están definidos, el Sistema de Información Actual no soporta su obtención y medición.
Dentro de las actividades académicas se encuentran:
Docencia
Admisión y promoción de alumnos
Investigación
Servicio
Dentro de las actividades relacionadas con el Medio Universitario se encuentran:
Admisión y promoción de alumnos
Pastoral
Asesoría Psicológica
Sector Cultural y deportivo
Instalaciones Físicas
Práctica Social
Atención personal a estudiante
Asociaciones de estudiantes y profesionales
MISC-03-1-2
194
HERRAMIENTAS
Ms office y Finanzas+.
CALLES
Decanatura Académica / Decanatura del Medio Universitario
1. Elaborar Plan estratégico
Consultar los lineamientos de acción de la Planeación Estratégica Corporativa. En el reglamento ya
están definidos los lineamientos generales a seguir en la planeación de gestión, reglamento de cada
dependencia y de la Universidad Javeriana
Realizar el Diagnóstico de la situación actual de la facultad para formular las Líneas de acción a
largo, mediano y corto plazo.
10. Elaborar informe consolidado de gestión
Elaborar los informes consolidados de gestión de la Facultad.
11. Presentar informes de gestión
Presentar los informes de gestión: académica a la Vicerrectoría Académica, del medio universitario,
a la Vicerrectoría del Medio universitario y financiera, a la respectiva dirección en la Universidad.
2. Elaborar plan de trabajo académico y económico
Establecer Plan de trabajo anual de acuerdo con las metas propuestas por la Vicerrectoría
Académica y el Programa de Trabajo de las actividades del Medio Universitario según los
lineamientos establecidos por la Vicerrectoría respectiva.
2B. Aprobar plan de trabajo
La decanatura se encarga de la aprobación de los objetivos y actividades planteados en el plan de
trabajo.
5. Controlar la ejecución de gestión académica y del medio
Evaluar los informes de resultados.
MISC-03-1-2
195
Tomar decisiones con base en estos resultados y establecer los compromisos respectivos en los
planes de trabajo.
Realizar la Reflexión anual y el Informe Gerencial de resultados.
Establecer los lineamientos de acción del siguiente periodo.
Presentar ante la Vicerrectoría Académica y la Vicerrectoría del Medio Universitario de la
Universidad los resultados y los lineamientos de gestión del siguiente periodo.
Divulgar los resultados y lineamientos ante el personal Directivo al interior de la Facultad.
6. Autorizar presupuesto
Definir el monto asignado a una dependencia determinada.
Existen dos clases de presupuesto, uno ordinario que hace referencia al funcionamiento general de
la Facultad y el otro extraordinario que se refiere a las inversiones proyectadas para un periodo
determinado
7. Autorizar inversión gastos y traslados
Evaluar y en caso de conformidad aprobar las inversiones y gastos necesarios para adelantar la
gestión de las diferentes dependencias de la facultad.
9. Control de ejecución Financiera
Hacer seguimiento a la ejecución presupuestal y autorizar las adiciones y modificaciones de su
ingerencia. Este proceso está documentado en el diagrama: AFIN-Administración de recursos
financieros.
Dependencias
2A. Elaborar plan estratégico
Establecer Plan de trabajo anual de acuerdo con las metas propuestas por la Vicerrectoría
Académica.
3. Ejecutar plan de trabajo del período
Cada unidad académica ejecuta y hace seguimiento a sus compromisos dentro del plan de trabajo
del periodo.
MISC-03-1-2
196
4. Registrar ejecución de gestión
Elaborar y presentar los informes de seguimiento de gestión a Decanatura Académica y del Medio
Universitario.
8. Realizar inversión gastos y traslados
Ejecutar las inversiones y gastos necesarios para adelantar la gestión de las diferentes dependencias
de la facultad.
8A. Elaborar informes de ejecución financiera
Elaborar informes de la ejecución financiera a nivel de cada dependencia.
8B. Elaborar informe de gestión
MISC-03-1-2
197
PLANEACIÓN Y CONTROL DE GESTIÓN
MISC-03-1-2
198
12 ANEXO 2. TECNOLOGIAS DE APOYO A PROBLEMATICAS COMUNES EN LAS ORGANIZACIONES
Necesidad: Automatizar procesos empresariales individuales
Solución tecnológica: suite de oficina
Incluye herramientas para la construcción de pequeñas aplicaciones con el objetivo de agilizar y
automatizar las tareas individuales.
Necesidad: Ofrecer a los clientes y empresarios información empresarial en tiempo real y
desde cualquier lugar.
Solución tecnológica: Wireless
Permite realizar operaciones e-business desde cualquier lugar y en cualquier momento, aumentar la
flexibilidad del espacio físico en la organización y ofrecer un mejor servicio a los clientes que
posean dispositivos inalámbricos.
Necesidad: Manejar adecuadamente el conocimiento y el capital intelectual.
Solución tecnológica: Gestión del conocimiento.
El capital intelectual de una organización está conformado por todos aquellos intangibles que
generan valor en la relación con los clientes, en la realización de procesos o en la cultura
corporativa, entre otros campos. Los elementos que componen el capital intelectual son:
documentos, bases de datos, metodologías, instrucciones y sobre todos habilidades y actitudes de
los empleados. La gestión del conocimiento se compone de los procesos que estructuran el capital
humano para maximizar su capacidad de producción.
MISC-03-1-2
199
Necesidad: Optimizar el proceso de colaboración entre los integrantes de la organización.
Solución tecnológica: Workflow
Automatización de servicios de colaboración complejos, iterativos y presentes en varias partes de
un proyecto u organización. Crea una red compartida de información que ofrece a los compradores
y vendedores una vista actual del proyecto o del a organización.
Necesidad: Mejorar el proceso de diseño y desarrollo de nuevos productos.
Solución tecnológica: CAD (Diseño Asistido por Computador), CAE (Ingeniería Asistida por
Computador), y PDM (Gestión de Datos del Producto).
El diseño y desarrollo de nuevos productos es una labor de diferentes departamentos de una
empresa. Existe la posibilidad de acortar significativamente el proceso de diseño mediante la
aplicación de herramientas informáticas como las siguientes:
• Diseño Asistido por Computador (CAD): permite por ejemplo, diseñar complejos montajes de
componentes mecánicos sin necesidad de construir prototipos.
• Ingeniería Asistida por Computador (CAE): una vez diseñado el nuevo producto en forma de
maqueta digital, se analiza para comprobar el cumplimiento de las especificaciones establecidas
y se simula el proceso de fabricación para determinar las posibles incidencias en la calidad del
producto.
• Gestión de Datos del Producto (PDM): facilita la distribución a toda la organización de la
información relativa al nuevo producto, una vez liberado para su fabricación. También gestiona
la realización de cambios de diseño y especificaciones de fabricación de productos.
MISC-03-1-2
200
Necesidad: Lograr la excelencia en operación.
Solución tecnológica: SCM (Gestión de la Cadena de Suministro).
Las soluciones de gestión de la cadena de suministro comprenden el soporte de las actividades
asociadas al flujo y a la transformación de los materiales, desde la extracción de materias primas
hasta el suministro al consumidor final. Estas soluciones SCM integran los flujos de información,
así como las operaciones de almacenaje y transformación. La gestión de las cadenas de suministros
abarca diversas funciones empresariales:
• Entrada de pedidos y de gestión de la demanda.
• Aprovisionamiento y relaciones estratégicas con proveedores.
• Fabricación, distribución y transporte.
Necesidad: Manejo de Información historial e inteligencia de negocio
Solución tecnológica: Datawarehouse (Bodegas de datos) y Data Mining (Minería de datos)
Las bodegas de datos permiten almacenar un gran número de información apoyada en una base de
datos, esto con el objetivo de mantener datos históricos. Adicionalmente para que estos datos se
conviertan en información útil para la empresa es necesario utilizar herramientas OLAP que
permitirá generar consolidados, estadísticas y tablas comparativas de los datos almacenados.
Necesidad: Mejorar la integración y el control de gestión empresarial.
Solución tecnológica: ERP (Planeación de Recursos Empresariales).
Las soluciones ERP, o de gestión empresarial, dan soporte a los principales procesos y funciones de
la empresa, integrando los datos procedentes de las distintas actividades. Son el fundamento del
sistema de información de la empresa, sobre el cual se integran soluciones complementarias
MISC-03-1-2
201
especializadas. Si bien el término ERP nació para las grandes organizaciones, las pequeñas
empresas lo deben aplicar con soluciones adecuadas para su tamaño.
La implementación de una solución ERP a menudo impulsa los cambios organizativos internos y
facilita la estandarización y simplificación de los procesos de negocio.
Necesidad: Integrar los sistemas existentes en la organización
Solución tecnológica: EAI.(Integración de las aplicaciones de la empresa)
Tienen como función integrar los viejos sistemas de las organizaciones o conectar estos viejos
sistemas con los nuevos Net Markets de la industria.
Necesidad: Mejorar las relaciones con los clientes.
Solución tecnológica: CRM (Administración de relaciones con los Clientes).
Las soluciones de CRM integran todas las funciones y procesos que intervienen en las actividades
de la empresa con sus clientes. El principal propósito de las soluciones CRM es maximizar el valor
del cliente, captar, desarrollar y retener a los clientes más rentables. Las principales áreas
funcionales que comprende una solución CRM son ventas, mercadeo, soporte técnico y servicio al
cliente.
Dentro de las soluciones CRM también se incluyen los call centers, los contac centers y el
desarrollo de un sitio web corporativo.
Necesidad: Establecer un intercambio comercial con mis clientes.
Solución tecnológica: e-commerce (Comercio Electrónico)
El ecommerce abarca muchas de las tecnologías que se han mencionado antes, por lo cual se puede
ver como una solución integradora para la empresa.
MISC-03-1-2
202
Permiten optimizar las transacciones comerciales utilizando la red, aumentar la capacidad de
respuesta ante sus clientes y reducir los costos de mantenimiento de inventario, optimizar sus
relaciones financieras con clientes y proveedores mediante sistemas de pago y facturación a través
de la red y reducir el trabajo administrativo y las demoras conectando on-line a los distribuidores y
proveedores.
Necesidad: Optimizar el suministro y gestión del sistema de valor entre compradores y
vendedores.
Solución tecnológica: Webservices (Servicios en la red)
Utilizando Internet los web services representan un cambio fundamental en los negocios: el paso de
un enfoque secuencial de la cadena de suministro con flujos de información en serie, a un enfoque
interconectado e interdependiente con los web services, situados en el centro y con información
automatizada (servicios publicados) que fluye en paralelo entre los procesos tanto de los
compradores como de los vendedores sin importar la plataforma o los sistemas que estén utilizando
cada uno de los participantes.
Necesidad: Optimizar la interacción entre proveedores y fabricantes.
Solución tecnológica: e-collaboration (Colaboración Electrónica)
Las soluciones de e-collaboration permiten a los fabricantes y a sus proveedores hacer negocios de
un modo distinto. Por ejemplo, en lugar de las tradicionales cadenas de pedidos y suministro
verticales, fabricante y proveedor pueden construir una “red de valor” con conexiones horizontales.
Así, un proveedor puede conectarse al sistema de seguimiento de ventas de un minorista para
ayudar al minorista a mantener unos niveles de inventario óptimos: conocimientos compartidos y
tomas de decisiones conjuntas.
MISC-03-1-2
203
13 ANEXO 3. NECESIDADES RECURRENTES DE INFORMACIÓNEN EN LA CARRERA DE INGENIERIA DE SISTEMAS DE LA PONTIFICIA UNIVERSIDAD
JAVERIANA
Funcionalidades e Información Requeridas
Información de Personas (Estudiantes, Profesores, Empleados)
• Estudiantes
o Información Básica (Programa(s) al que pertenece, estado académico, promedio,
semestre, créditos aprobados, datos básicos: e-mail, teléfono, dirección, ciudad, entre
otros)
o Información de Materias que tiene matriculadas (materia, grupo, créditos)
o Información histórica de notas (materia, semestre tomado, nota)
o Información histórica consolidada (por cada semestre: créditos matriculados,
aprobados, perdidos, promedio semestre, promedio acumulado a ese semestre)
o Estado de morosidad (diferentes tipos de morosidad: biblioteca, laboratorios,
financiera)
• Profesores
o Información Básica (Departamento(s) con los que tiene vinculo, tipo de profesor (planta
o cátedra), categoría o nivel en el escalafón, datos básicos, estado (prospecto, activo,
retirado, no activo), máximo título.
o Producción Intelectual (para puntos en el escalafón)
o Materias que esta dando (materia, grupo, horas a la semana, número de semanas)
• Directivos
MISC-03-1-2
204
o Tipo de Directivo (Director de Departamento, Director de Carrera, Director de
Dependencia o Instituto, Jefe de Sección
• Empleados
o Datos básicos, dependencia a la que pertenece, tipo (secretaria, laboratorista, auxiliar,
jefe o director administrativo, monitor)
Información de materias
• Departamento que la ofrece (código y centro de costo), sección dentro del departamento al que
pertenece, programas que la aceptan dentro de su currículo (incluyendo el centro de costo y
número del currículo), créditos reconocidos en cada programa, horas semanales, horas al
semestre, módulos (si está dividida en módulos, especialmente en postgrados), profesor (ó
profesores si tiene módulos), fecha de inicio, fecha final.
• Información de la materia (audiencia, objetivo, resumen del contenido)
• Grupos, profesores y horarios de cada uno.
• Prerrequisitos (puede ser diferente por programa, puede incluirse como prerrequisitos otras
materias o un número mínimo de créditos aprobados para poder cursarla).
• Secciones de laboratorio y sus respectivas sesiones (horarios de laboratorio asignados) y
profesores. (en algunas oportunidades se tiene grupo grande con clase magistral, y grupos
pequeños para los laboratorios).
• Estudiantes (con su email como dato básico mínimo) que están en un grupo de una materia, o en
todos los grupos de una materia.
MISC-03-1-2
205
14 ANEXO 4. MATRIZ DE DEFINICION DE LAS ACTIVIDADES DE LA CARRERA DE INGENIERIA DE SISTEMAS
DEFINICIÓN DE LAS ACTIVIDADES DE LA ORGANIZACIÓN FRECUENCIA AREA No ACTIVIDAD DIARIA SF OTRA
1 Creación de currículo Una vez
2 Mercadeo del programa X
3 Selección de nuevos estudiantes
Semestral
4 Seguimiento ciclo académico de estudiantes X
5 Actualización de Currículo X
6 Seguimiento de egresados X
7 Actividades de acreditación
Cuando las entidades lo soliciten
8 Solicitud de servicios docentes a los departamentos Semestral
9 Pago de servicios a los departamentos Semestral
UNICA
10 Control y gestión de la carrera X
MISC-03-1-2
206
15 ANEXO 5. MATRIZ DE ACTIVIDADES Vs. COMPONENTES DE LA MISION DE LA CARRERA DE INGENIERIA DE SISTEMAS
Impu
lsar
la in
vest
igac
ión
Impu
lsar
la fo
rmac
ión
inte
gral
cen
trad
a en
los
curr
ícul
os
Fort
alec
imie
nto
de la
inte
rdis
cipl
inar
ieda
d
Fort
alec
imie
nto
de la
pre
senc
ia e
n el
paí
s
Dis
min
uir
la c
risis
étic
a y
la i
nstr
umen
taliz
ació
n de
l se
r hu
man
o
Fort
alec
er e
l apr
ecio
a la
nac
iona
lidad
Fort
alec
er la
iden
tidad
cul
tura
l
Elim
inar
la
in
tole
ranc
ia
y el
de
scon
ocim
ient
o de
la
pr
ural
idad
y la
div
ersi
dad
Elim
inar
la
disc
rimin
ació
n so
cial
y l
a co
ncen
trac
ión
del
pode
r eco
nóm
ico
y po
lític
o
Elim
inar
la
inad
ecua
ción
e i
nefic
ienc
ia d
e su
s pr
inci
pale
s in
stitu
cion
es
Elim
inar
la in
efic
ienc
ia y
lent
itud
en e
l des
arro
llo c
ient
ífico
y
tecn
ológ
ico
Elim
inar
la ir
raci
onal
idad
en
le m
anej
o de
l med
io a
mbi
ente
y
de lo
s re
curs
os n
atur
ales
Sum
ator
ia p
or a
ctiv
idad
Creación de currículo 5 5 5 5 5 5 5 5 5 5 5 5 60
Mercadeo del programa 5 5 3 5 1 1 3 1 3 1 3 3 34 Selección de nuevos estudiantes 1 3 3 5 3 5 5 5 1 1 1 1 34 Seguimiento ciclo académico de estudiantes 1 3 0 3 5 3 5 3 5 1 3 1 33 Actualización de Currículo 5 5 5 5 5 5 5 5 5 5 5 5 60
Seguimiento de egresados 1 1 1 5 5 1 1 3 3 5 3 3 32 Actividades de acreditación 1 5 5 5 3 1 1 0 0 0 0 5 26
Solicitud de servicios docentes a los departamentos 5 5 5 5 5 5 5 0 0 0 0 1 36
Pago de servicios a los departamentos 1 1 1 1 1 1 1 1 1 1 1 1 12 Control y gestión de la carrera 5 5 5 5 5 5 5 5 5 5 5 5 60 Grados Estudiantes 3 3 3 3 3 3 3 3 3 3 3 3 36
Sumatoria por Componente 33 41 36 44 41 27 27 29 25 27 27 31
ACTIVIDADES
COMPONENTES DE LA MISION
MISC-03-1-2
207
16 ANEXO 6. MATRIZ DE EVALUACION Y PRIORIZCION DE LAS NECESIDADES INFORMATICAS DE LA CARRERA DE INGENIERIA DE SISTEMAS
EVALUACIÓN Y PRIORIZACION DE LAS NECESIDADES INFORMÁTICAS
IMPACTO ESTRATÉGICO No ORIGEN DE LA
NECESIDAD DESCRIPCIÓN DE LA NECESIDAD
ALTO MEDIO BAJO
ÁREA GENERADORA PRIORIZACIÓN
ACTIVIDADES PRIMARIAS
1 Creación de currículo
Manejar la información del curriculo, prerrequisitos, correquisitos, créditos académicos y contenidos de las asignaturas. Actividades extrapensum como deportes, grupos de interés, menciones, concursos, publicaciones de los estudiantes, asistencia a eventos. X Universidad 2
2 Mercadeo del programa
Responder en forma automática a inquietudes y consulta de prospectos. Generar análisis de poblaciones de estudiantes futuros bachilleres, colegios de mayor solicitud de ingreso y perfiles para el envío de correspondencia directa y mantener la huella para proceso de admisiones. X Carrera 8
3
Selección de nuevos estudiantes
Control y evaluación automática de puntajes de ICFES, puntaje de entrevista y variables de decisión como colegio del cual egresa el aspirante. X Carrera 7
4
Seguimiento ciclo académico de estudiantes
Hacer seguimiento al estudiante desde su proceso de admisión. Control de su estado académico y formulación de estrategias correctivas. X Carrera 1
5 Actualización de Currículo
Control y gestión de las asignaturas de la carrera, prerrequisitos, correquisitos y actividades extra pensum. X Carrera 2
6 Seguimiento de egresados
Mmantener el historial laboral de los egresados, colaborarles en la consecución de empleos y convocarlos a eventos de la universidad. Sistema que facilite la promoción de posgrados. X
Carrera-Universidad 9
7
Solicitud de servicios docentes a los departamentos
Facilitar la administración de solicitudes de cursos, y el control de los mismos. X
Carrera-Departamentos 3
8 Proceso Grados Estudiantes
Es la salida del proceso cuando se entregan los profesionales a la sociedad. Aquí es necesario revisar estado académico, aprobación de tesis, pago de derechos de grado, paz y salvos con la universidad. Este proceso genera un enlace con el Ministerio de Educación. X Carrera 8
ACTIVIDADES SECUDARIAS
1
Actividades de acreditación
Se alimenta de la información que arroja el proceso curricular. Adicionalmente deberá permitir la definición de los indicadores de acreditación y la generación de las estadísticas de los mismos. X
Carrera-Universidad 6
2
Pago de servicios a los departamentos
Cobro y traslado presupuestal automático entre departamentos y carreras de acuerdo con los servicios académicos prestados. X
Carrera-Departamentos 5
3
Control y gestión de la carrera
Permitir la gestión y control de la carrera mediante indicadores y estadísticas, y que facilite la toma de decisiones. X Carrera 4
Matriz No.7 Evaluación y priorización de las necesidades informáticas.
MISC-03-1-2
208
17 ANEXO 7. PRIORIZACION DE LAS ALTERNATIVAS DE SOLUCION A LAS NECESIDADES INFORMATICAS DE LA CARRERA DE INGENIERIA DE SISTEMAS
Solución Beneficio Impacto Éxito Demanda Prioridad
SOLUCION 40 PRIORIZACIÓN DE LAS ALTERNATIVAS DE SOLUCIÓN
ALTERNATIVA DE SOLUCIÓN
BENEFICIO
IMPACTO
EXITO
DEMANDA
PRIORIDAD
Sistematización del currículo, prerrequisitos, correquisitos, créditos académicos y contenidos de las asignaturas. Actividades extrapensum deben ser controladas aquí.
8 8 7
7 30
Construcción de aplicativos que respondan en forma automática a inquietudes y consulta de prospectos. Sistema de minería de datos que analice poblaciones de estudiantes futuros bachilleres, colegios de mayor solicitud de ingreso y perfiles para el envío de correspondencia directa.
8 8 8 8 32
Sistema de control y evaluación de puntajes de ICFES, puntaje de entrevista y variables de decisión como colegio del cual egresa el aspirante.
6 5 5 5 31
Sistema de información que permita hacer seguimiento al estudiante desde su proceso de admisión. Control de su estado académico y formulación de estrategias correctivas.
10 8 8 8 34
Sistema de información para el control y gestión de las asignaturas de la carrera, prerrequisitos, correquisitos y actividades extra pensum.
8 8 7
7 30
Sistema de información que permita mantener el historial laboral de los egresados, colaborarles en la consecución de empleos y convocarlos a eventos de la universidad. Sistema que facilite la promoción de posgrados.
5 5 5 5 20
Sistema de información que facilite la administración de solicitudes de cursos, y el control de los mismos. 9 9 9 9 36 Sistema de Información que permita la gestión y control de la carrera mediante indicadores y estadísticas, y que facilite la toma de decisiones.
9 9 9 9 36
Sistema de información que se alimenta del sistema curricular. Adicionalmente deberá permitir la definición de los indicadores de acreditación y la generación de las estadísticas de los mismos. Este sistema se alimenta de todos los demás construidos.
9 9 9 9 36
Sistema de cobro y traslado presupuestal entre departamentos y carreras de acuerdo con los servicios académicos prestados.
9 9 9 9 36
Matriz No.9 Priorización de las alternativas de solución.
MISC-03-1-2
209
18 ANEXO 8. RELACION ENTRE LAS TECNOLOGIAS DE INFORMACION CON LAS ALTERNATIVAS DE SOLUCION
RELACION ENTRE LAS TECNOLOGIAS DE INFORMACION CON LAS ALTERNATIVAS DE SOLUCION
ALTERNATIVAS DE SOLUCIÓN
TI
CARACTERÍSTICAS 1 2 3 4 5 6 7 8 9 10 Elaboración de tablas para uso individual Crear pequeñas aplicaciones para automatizar procesos personales
SUIT
E
DE
O
FIC
INA
Procesar información para que se facilite su análisis y aprovechamiento. X Aumentar la flexibilidad del espacio de su oficina Mejorar la eficacia y la movilidad, mientras sigue trabajando en cualquier lugar. Ofrecer un mejor servicio a los clientes que posean dispositivos inalámbricos: teléfonos móviles y PDA's
WIR
EL
ESS
Proporcionar a los socios y empleados acceso a información precisa en tiempo real desde cualquier lugar X Fusión con otra empresa u organización cuya forma de operar es distinta. La organización se encuentra dispersa geográficamente. O por cualquier otro motivo la comunicación Inter.-empresarial es muy limitada. El conocimiento mas importante se encuentra concentrado en unos pocos empleados o departamentos y no se distribuye adecuadamente hacia el resto de la organización.
KN
OW
LE
DG
E
MA
NA
GM
EN
T
Se genera un exceso de información en la organización, que se distribuye en forma masiva y sin criterios de selección o importancia. X X X X X X X X Automatización de servicios de colaboración complejos, iterativos
WO
RK
FLO
W
Creación de una red compartida de información X X X X X X X X X Reducción del plazo de disponibilidad de nuevos productos, para su fabricación y comercialización Incremento de la productividad del departamento de ingeniería. Mejora de la calidad de los productos.
CA
D, C
AE
Y P
DM
Disminución de los costos de fabricación.
SCM
Inversiones en infraestructura y equipos, relaciones con clientes y proveedores, desarrollo de nuevos productos.
X X X X X X
MISC-03-1-2
210
Planificación de recursos y asignación de la demanda.
Programación de recursos y monitoreo de las operaciones.
Almacenar grandes cantidades de datos históricos
Administrar y Consultar los datos históricos
DA
TA
WA
RE
HO
USE
, D
AT
AM
ININ
G
Generar estadísticas y comparaciones sobre los datos para convertirlos en información X
X
X
X
X
X
X
X
X
X
Agilizar los flujos de datos en la empresa, integrando la información en tiempo real. Minimizar el tiempo de respuesta a clientes y proveedores. Delegar las decisiones en los niveles adecuados, manteniendo el control de gestión Garantizar la disponibilidad de información de soporte a la toma de decisiones.
ER
P
Facilitar el proceso de planeación empresarial, ya que permite obtener información consolidada del grado de consecución de los objetos definidos X X X X X X X X Integración de las viejos sistemas
EA
I
Integración de los viejos sistemas con los sistemas con los Net Markets X X X X Conocimiento detallado del cliente. Toma de decisiones basada en información y no en supuestos. Incremento de los ingresos por ventas (satisfacción del cliente).
CR
M
Implementación de canales alternativos (e-commerce) X X X X X X X X X X Reducir el trabajo administrativo y las demoras conectando on-line a los distribuidores y proveedores. Aumentar la capacidad de respuesta ante sus clientes y reducir los costos de mantenimiento de inventario.
E-C
OM
ME
RC
E Optimizar sus relaciones financieras con clientes y
proveedores mediante sistemas de pago y facturación a través de la red. X X X X X X X X
Optimización de la cadena de valor de la organización
WE
BSE
RIV
ICE
S
Permite la reutilización de la infraestructura existente. Reduciendo costos de implementación.
X X X X X X X X X X
MISC-03-1-2
211
Disminuye la intervención humana en los procesos de la empresa Se puede implementar en intranet, extranet e Internet
Permite la interacción de diferentes plataformas por medio de interfaces XML
El fabricante se beneficia de un mayor volumen de ventas. El minorista se beneficia de tener un stock de productos adecuado y poder ofrecerlo al consumidor final a un precio reducido, incrementando de este modo el volumen de ventas.
E-
CO
LL
AB
OR
AT
ION
El consumidor final se beneficia de unos precios de venta más bajos.
Matriz No. 10 Relación entre las tecnologías de información con las alternativas de solución
MISC-03-1-2
212
19 ANEXO 9 CARACTERIZACION DE LOS PATRONES DE E-BUSINESS
Definición Ejemplos Patrones Obligatorios Patrones Opcionales Intercambio de bienes de consumo (compra, venta)
Patrón de Negocio de Autoservicio: provee acceso a los clientes a las funciones del Web Site, como navegar por el catálogo o colocar una orden. Estilo de transacción: Lectura/Escritura no distribuida Nivel de Seguridad: Encripción (Nivel ideal : autenticación)
Patrón de Integración de Acceso: incrementa la amigabilidad del sito por medio de personalización y acceso a otros dispositivos electrónicos.
Patrón de Negocio de Agregación de Información: Usado para agregar información desde múltiples fuentes y generar un catálogo unificado. Estilo de transacción: Lectura Nivel de Seguridad: Encripción
Patrón de negocio de Colaboración: provee funciones tales como confirmación automática de ordenes por e-mail y opciones de chat para solución de dudas a clientes. Estilo de transacción: Lectura Nivel de Seguridad: Encripción
E-C
omm
erce
Conjunto de procesos y productos que facilitan el intercambio seguro de bienes y servicios sobre el web, incluidos: Publicidad, mercadeo, compras, ventas, pagos, entregas de productos Uso de sistemas para apoyo de
procesos de compra y venta de bienes y servicos, por ejemplo call center que apoyan el proceso a sus consumidores y hacen uso del sistema para dar información.
Patrón de Integración de Aplicación: que se usa para combinar los patrones de Autoservicio y Agregación de Información. Provee una solución unificada al cliente
Patrón de negocio de Empresa Extendida: puede ser usado para generar una conexión directa con las compañías de envío de mercancias. Estilo de transacción: Cualquiera Nivel de Seguridad: Cualquiera
MISC-03-1-2
213
Patrón de negocio de AutoServicio: facilita la interacción entre el comprador y el e-Marketplace. Ver el catálogo, participar en subastas, hacer intercambios. También sirve para actualizar el catálogo, chequear ordenes. Estilo de transacción: Lectura/Escritura no distribuida Nivel de Seguridad: Encripción (Nivel ideal : autenticación)
Patrón de negocio de colaboración: puede ser usado para habilitar el proceso de aprobación de compras. Estilo de transacción: Lectura/Escritura no distribuida Nivel de Seguridad: Encripción (Nivel ideal : autenticación)
Patón de Negocio de Agregación de Información: Usado para crear el catálogo del E-Marketplace desde múltiples fuentes de proveedores, productos, precios, entre otros. Estilo de transacción: Lectura Nivel de Seguridad: Encripción
Patrón de integración de aplicaciones: usado para integrar los dos patrones de negocio y soportar la integración con otros sistemas ya existentes como el de pagos. Atención: Soportar el nivel de pagos requiere de seguridad por autenticación y manejo de transacciones distribuidas.
E-M
arke
tpla
ce
Intercambios comerciales que facilitan y promueven la compra y venta y negocios entre comunidades de aliados de un sector.
Intercambio Comercial: Compradores y vendedores intercambian bienes y servicios en un sitio público.
Patrón de Integración de Acceso: usado para proveer una interfaz al protal con funciones single-sign-on y funciones de personalización.
Patrón de Negocio de Empresa Extendida: puede ser usado desde el lado del comprador y el vendedor. Desde el comprador encadena las funciones de abastecimiento de éste con las funciones comerciales del e-marketplace. Desde el vendedor encadena las funciones de abastecimiento del e-marketplace con sus proveedores. Estilo de transacción: Cualquiera Nivel de Seguridad: Cualquiera Es importante tener presente la complejidad de las transacciones financieras, la integridad y seguridad de las mismas al momento de seleccionar cómo se integrarán las aplicaciones entre las diferentes empresas.
MISC-03-1-2
214
Patrón de Integración de Acceso: usado para proveer una interfaz unificada al cliente. Patrón de Negocio de Colaboración: permite
habilitar y reversar subastas y otras funciones de compras colaborativas. Estilo de transacción: Lectura/Escritura no distribuida Nivel de Seguridad: Encripción (Nivel ideal : autenticación)
Patrón de Negocio de Autoservicio: que permite a los usuarios navegar a través de un catálogo, crear una orden y colocarla en el Hub. Estilo de transacción: Lectura/Escritura no distribuida Nivel de Seguridad: Encripción (Nivel ideal : autenticación)
Patrón de Negocio de Agregación de Información: integra y presenta un catálogo unificado con precios comparativos y recomendaciones que pueden ser publicadas. Estilo de transacción: Lectura Nivel de Seguridad: Encripción
Patrón de Negocio de Agregación de Información: Usado para agregar información desde múltiples fuentes y generar un catálogo unificado. Estilo de transacción: Lectura Nivel de Seguridad: Encripción
Hub del lado del vendedor: los vendedores son los propietarios del e-marketplace y lo utilizan como vehículo para vender sus bienes y servicios a posibles compradores en elWeb.
Patrón de integración de aplicaciones: usado para integrar los dos patrones de negocio.
Patrón de Negocio de Empresa Extendida: Integra este hub con servicios de proveedores externos como instituciones financieras, manejadores de créditos, compañías para entrega física de los productos. Estilo de transacción: Cualquiera Nivel de Seguridad: Cualquiera Es importante tener presente la complejidad de las transacciones financieras, la integridad y seguridad de las mismas al momento de seleccionar cómo se integrarán las aplicaciones entre las diferentes empresas
MISC-03-1-2
215
Patrón de Integración de Acceso: provee una forma única de acceso al sitio y una interfaz personalizada.
Patrón de Negocio de Agregación de Información: Ayuda a integrar el contenido de diversas fuentes de información a través del Web. Estilo de transacción: Lectura Nivel de Seguridad: Encripción
Patrón de negocio de Colaboración: permite a los participantes ofertar y participar en subastas y responder RFPs y RFQs. Estilo de transacción: Lectura/Escritura no distribuida Nivel de Seguridad: Encripción (Nivel ideal : autenticación)
Patrón de Negocio de Autoservicio: permite a los compradores crear RFPs y RFQs. Estilo de transacción: Lectura posible Escritura no distribuida Nivel de Seguridad: Encripción
Hub del lado del comprador: los compradores son los dueños del e-marketplace y lo usan como un vehículo para hacer compras o presupuesto de adquisición y solicitar mejores acuerdos a posibles vendedores.
Patrón de Integración de Aplicación: Integra este hub con los sistemas de abastecimiento y otros sistemas centrales del negocio.
Patrón de Negocio de Empresa Extendida: Integra este hub con servicios de proveedores externos como instituciones financieras, manejadores de créditos, compañías para entrega física de los productos. Estilo de transacción: Cualquiera Nivel de Seguridad: Cualquiera Es importante tener presente la complejidad de las transacciones financieras, la integridad y seguridad de las mismas al momento de seleccionar cómo se integrarán las aplicaciones entre las diferentes empresas
Acc
eso
a C
uent
as Provee acceso
permanente a los usuarios a la información de sus cuentas. Les permite a
Corredores de bolsa y administradores de cuentas. Manejo de tarjetas de crédito, aplicaciones provistas por bancos, compañías de seguros.
Patrón de Integración de Acceso: provee una forma única de acceso al sitio y una interfaz personalizada.
Patrón de Agregación de Información: por medio del cual se resume la información de múltiples cuentas para entregar una vista del portafolio unificado al cliente.
MISC-03-1-2
216
Patrón de negocio de colaboración: incluye funciones como chat en línea para dar un mejor soporte a los clientes. Estilo de transacción: Lectura/Escritura no distribuida Nivel de Seguridad: Encripción (Nivel ideal : autenticación)
los usuarios, borrar, incluir o actualizar información de sus cuentas
Patrón de negocio de Autoservicio: provee acceso a información almacenada en sistemas centrales del negocio y en bases de datos. Estilo de transacción: Lectura/Escritura no distribuida Nivel de Seguridad: Encripción (Nivel ideal : autenticación)
Si incluye los anteriores patrones, es posible utilizar un patrón de integración de Aplicación para integrarlos.
Patrón de Integración de Acceso: provee una forma única de acceso al sitio y una interfaz personalizada.
Patrón de Negocio de Empresa Extendida: Integra este hub con servicios de proveedores externos como instituciones financieras, manejadores de créditos, compañías para entrega física de los productos. Estilo de transacción: Cualquiera Nivel de Seguridad: Cualquiera Es importante tener presente la complejidad de las transacciones financieras, la integridad y seguridad de las mismas al momento de seleccionar cómo se integrarán las aplicaciones entre las diferentes empresas
Port
al
Provee varios mecanismos como la administración de contenidos, el formateo de la interfaz de usuario y la agregación de datos, para proveer una información apropiada que junto con los sistemas existentes, ayuden a cumplir las metas del negocio .
MISC-03-1-2
217
Patrón de negocio de Autoservicio: provee acceso a información almacenada en sistemas centrales del negocio y en bases de datos. Estilo de transacción: Lectura/Escritura no distribuida Nivel de Seguridad: Encripción (Nivel ideal : autenticación)
Patrón de Negocio de Agregación de Información: Ayuda a integrar el contenido de diversas fuentes de información a través del Web. Estilo de transacción: Lectura Nivel de Seguridad: Encripción
Patrón de Integración de Aplicación
