¿QUÉ MUEVE A TU EMPRESA? - Delia Esquer …desquer.ens.uabc.mx/afi/articulos/SG06_4_jul_ago.pdf04...

Software Guru CONOCIMIENTO EN PRÁCTICA

w

ww

.sof

twar

egur

u.co

m.m

xS

OFT

WA

RE

GU

RU

CO

NO

CIM

IEN

TO

EN

PR

ÁC

TIC

A

Juli

o-A

gost

o 20

06

Año 02 No.04 • Julio-Agosto 2006 • www.softwareguru.com.mx

[ Tutorial ] SAP NetWeaver

Noticias • Eventos • Fundamentos • UML • Tecnología • Reflexiones

Año

02

No.

04

• Reconstrucción de arquitecturas

• Patrones de diseño

• SOA

¿QUÉ MUEVE ATU EMPRESA?Las aplicaciones detrás de tus procesos

[ ENTREVISTA ]Gloria QuintanillaAcadémica, empresaria, consultora y pionera

ESPECIALIntegración de Aplicaciones

México, $65.00

02 JUL-AGO 2006 www.softwareguru.com.mx 03JUL-AGO 2006www.softwareguru.com.mx

DIRECTORIO

Editor EjecutivoPedro Galván

Coordinación EditorialMara Ruvalcaba

Edición y ProducciónEdgardo Domínguez

Arte y DiseñoOscar Sámano, Dafne Ortega

Consejo Editorial Francisco Camargo, Guillermo Rodríguez, Ralf Eder y Raúl Trejo, ITESM CEM; Hanna Oktaba, UNAM-AMCIS; Luis Cuellar, Softtek; Luis Vinicio León, e-Quallity - ITESO

ColaboradoresLuis Daniel Soto, Ariel García, Jorge Palacios, Ana Vázquez, Rigoberto Calleja, Walter Risi, Gerardo Borbolla, Adrián Ruffinatti, Enrique Duhne, Luis Antonio Rangel, Marco Antonio Cruz, Valerio Adrián Anacleto, Eduardo Noriega, Gabriel Vázquez, Sergio Orozco, Teresa Lucio Nieto, Leon Tripp, Joaquín Uribe.

VentasClaudia Perea, Natalia Sánchez

DistribuciónDaniel Velázquez

Ilustración de PortadaMiguel Ángel Gonzaga Leyva

[email protected]+52 55 5239 5502

SG Software Guru es una publicación bimestral editada por Brainworx S.A. de C.V., Malinche no. 6, Col. El Parque, C.P. 53398, Naucalpan, México. Prohibida la reproducción total o parcial del contenido sin previo aviso por escrito de los editores. Todos los artículos son responsabilidad de sus propios autores y no necesariamente reflejan el punto de vista de la editorial. Reserva de Derechos al Uso Exclusivo: 04-2004-090212091400-102. Certificado de licitud de tí-tulo: 12999. Certificado de licitud de contenido:10572. ISSN: 1870-0888. Registro Postal: PP15-5106. Se imprimió en junio de 2006 en Litográfica Roma. Distribución controlada por Sepomex. Distribución en locales cerrados por CMDE.

El proyecto esencial de software en cualquier organización, es el desarrollo o im-plantación de un sistema integral de información que automatice e integre los pro-cesos operativos. Sin duda, estos son proyectos que no pasan desapercibidos, y cada empresa tiene su propia historia de éxito o terror al respecto. El objetivo de este número de SG es compartir tips y mejores prácticas para maximizar las probabilidades de éxito en su próxima aventura con una aplicación empresarial.

Agradecemos el entusiasmo y esfuerzo de todos los colaboradores que hicie-ron posible este número de SG. En especial a Gloria Quintanilla, quien nos hace sentir muy orgullosos de tener gente como ella en la industria. Les recordamos que pueden enviar cualquier propuesta de contenido, o retroalimentación a [email protected].

Adicionalmente, queremos compartir con ustedes nuestra alegría por la madurez y crecimiento que está alcanzando SG. El siguiente hito en este crecimiento está en lograr que los gurús internacionales vengan a nuestro país a compartir su conocimiento y experiencia. Esto lo vamos a conseguir con el congreso SG ‘06 en septiembre de este año, que precisamente se junta con el segundo aniversario de SG. Asi que nos vemos en SG ‘06 para celebrar.

Equipo Editorial

A >

EDITORIAL

02 JUL-AGO 2006 www.softwareguru.com.mx 03JUL-AGO 2006www.softwareguru.com.mx

contenido jul-ago 2006 Año 2 número 04

Productos

LO QUE VIENE 10Genero db, Eclipse Calllisto, Microsoft/SAP Duet

NOVEDADES 12Visual Studio TeamSystem

TUTORIAL 16SAP Composite Application Framework

Prácticas

ARQUITECTURA 36Reconstrucción de ArquitecturasValerio Adrián Anacleto nos enseña la técnica de reconstrucción de arquitecturas para conocer cómo se encuentra estructurada una aplicación

DISEÑO 38Combinando Patrones de DiseñoEduardo Noriega nos muestra como combinar patrones de diseño para desarrollar soluciones flexibles y robustas.

ARQUITECTURA 42Integración y Orquestación con SOAEn la primera parte de esta serie, Gabriel Vázquez nos brinda un panorama sobre la arqui-tectura orientada a servicios (SOA), así como la integracion y orquestación basada en servicios.

Columnas

Tejiendo Nuestra Red 08por Hanna Oktaba

Mejora Continua 10por Luis Cuellar

Tendencias en Software 45por Luis Daniel Soto

Cátedra y Más 54por Joaquín Uribe

En Cada Número

Noticias y Eventos 04UML 46Fundamentos 48Carrera 48Infraestructura 50

EN PORTADAAplicaciones EmpresarialesCualquier empresa moderna requiere de aplicaciones empresariales para automatizar e integrar sus procesos. En esta ocasión, profundizamos sobre la adquisición, implantación y evolución de éstos sistemas.

26

Entrevista 24 Gloria Quintanilla

ESPECIAL 20Enterprise Application Integration (EAI) Walter Risi nos da un paseo por los conceptos básicos de la integración de aplicaciones, así como los escenarios más comunes.

04 www.softwareguru.com.mxJUL-AGO 2006

NOTICIAS

Noticias

TechBA Montreal

El pasado 9 de junio se llevó a cabo la apertura de TechBA Montreal, la tercera aceleradora de negocios creada por el gobierno federal para impulsar empresas mexicanas de tecnología en Norteamérica.

El programa TechBA tiene por objetivo apoyar empresas mexicanas altamente innovadoras, que hayan desarrollado tecnología propia y estén interesadas en buscar nuevos mercados y aumentar sus posibili-dades de hacer negocios en el extranjero. TechBA Montreal es la tercera aceleradora de este programa (junto con la de TechBA Silicon Valley y Austin), que en conjunto apoya a 97 empresas a la fecha.

TechBA Montreal se enfocará en los mercados de dispositivos médicos, aeroespacial, alimentos y sistemas de software embebido para el sec-tor automotriz

Más información en: www.techba.com

2° Foro Nacional de Innovación y Tendencias Tecnológicas

La Cámara Nacional de la Industria Electrónica, de Teleco-municaciones e Informática (CANIETI), organizó del 1 al 3 de junio en las ciudades de Tijuana y Ensenada, el 2º. Foro Nacional de Innovación y Tendencias Tecnológicas.

El propósito del foro fue generar espacios de discu-sión de los expertos y especialistas internacionales, sobre las tendencias en las industrias de: electrónica (TV Digital y semiconductores, nanotecnología), auto-motriz, tecnologías de la información, productos mé-dicos y biotecnología.

Entre los conferencistas participantes estuvieron Mr. Rajiv Chumar Bhatia (Embajador de la India en México), Luis Daniel Soto (Microsoft), Héctor Nava (IDC), y Ricardo Zermeño (Select).

DebConf6

Del 13 al 22 de mayo se celebró en México la conferencia anual de desarrolladores de De-bian, DebConf6, a la cual asistieron cerca de 300 desarrolladores de todo el mundo.

Debian es un sistema operativo basado en software libre que utiliza el kernel de Linux. Es reconocido por su estabilidad y seguridad.

A diferencia de otras distribuciones de Linux, Debian no es financiado por grandes empre-sas, y es enteramente desarrollado por una fuerte comunidad de voluntarios de todo el mundo. El objetivo de DebConf es juntar a esta comunidad de desarrolladores una vez al año para conocerse, implementar mejoras al sistema, compartir experiencias, definir di-recciones futuras y, por supuesto, divertirse. Las ediciones anteriores del DebConf se han

llevado a cabo en Francia, Canada, Noruega, Brasil, y Finlandia, así que fue un gran honor que México fuera elegido este año. Agradece-mos el esfuerzo de los organizadores locales, especialmente Gunnar Wolf, por enfrentar este reto y contribuir a poner a México en el mapa mundial del software.

Más información sobre Debian en: www.debian.org

05www.softwareguru.com.mx JUL-AGO 2006

Eventos

IBM Technology Evaluation Center El pasado 1° de junio, IBM inauguró el Technology Evaluation Center (TEC) de la ciudad de Monterrey. Este es un centro con salones de computadoras disponibles para conocer y utilizar las soluciones de software de IBM. Se pue-den utilizar para realizar pruebas de concepto, cursos, hands-on labs, tuto-riales, etc. Esta es una excelente herramienta para los partners que desarrollan soluciones sobre la plataforma de IBM, y requieren de un lugar para mostrar sus productos funcionando.

Este centro es el segundo de su tipo en nuestro país. El primero fue el de la Ciudad de México, el cual ha tenido un gran éxito y, de acuerdo con la gente de IBM, es el TEC con mayor utilización de América.

4 y 5 Julio 2006 – Cd. de México6 y 7 Julio 2006 – Monterrey, N.L.The CIO Dashboard & IT Performance ManagementCutter Consortium4 y 5 de Julio, Hotel W, Cd. de México6 y 7 de Julio, Hotel Radisson Casa Grande, Monterrey N.L.Info: www.ciodashboard.cutter.com.mx Tel: (55) 5544 8253e-mail: [email protected]

22 y 23 de Julio 2006Seminario Gratuito - Mejores Practicas en la Admón. de Proyectos a través de una Oficina de Proyectos IBM e Itera22 de Julio, Cd. de México23 de Julio, Monterrey N.L.Info: www.itera.com.mxTel. (55) 3300 0650e-mail: [email protected]

23 al 28 Julio 2006Agile 2006Agile AllianceMinneapolis, MinnesotaInfo: www.agile2006.com e-mail: [email protected]

31 Julio y 1 Agosto 20062da. Cumbre de Gobierno y Tecnología 2006IDCCentro Banamex, Cd. de MéxicoInfo: www.idc-eventos.com/cumbregobierno06 Tel: (55) 5661 3791e-mail: [email protected]

30 Agosto al 1 Septiembre 2006The Economics of ITGartnerCentro Banamex, Cd. de MéxicoInfo: www.gartner.com/mx/econit Tel: (55) 5584 9370e-mail: [email protected]

11 al 14 Septiembre 2006SD Best PracticesSoftware Development Media GroupHynes Convention Center, Boston MAInfo: www.sdexpo/2006/sdbp e-mail: [email protected]

14 al 16 Septiembre 2006VI GULEV Congreso Internacional de Software LibreWorld Trade Center, VeracruzInfo: www.gulev.org.mx

20 al 22 Septiembre 2006SG ’06 Conferencia y ExpoSoftware GuruWTC y CompuSoluciones, Cd. de MéxicoInfo: www.softwareguru.com.mx/sg06 Tel: (55) 5239 5502e-mail: [email protected]

JavaOne 2006

Del 15 al 19 de mayo se realizó el JavaOne 2006 en San Francisco, re-uniendo a más de 14 mil entusias-tas de esta tecnología. El evento inició con el primer keynote de Jo-nathan Schwartz como CEO de Sun Microsystems.

Los temas más populares durante la semana fueron la nueva versión de J2EE (ahora llamada Java EE), Ajax, y Java Server Faces.

Del 15 al 19 de mayo la delegación mexicana inte-grada por sus servidores Ana Vázquez y Jorge Pa-lacios, presentó la NMX-I-059/02-NYCE-2005 (po-

pularmente conocida como MoProSoft), en la 19th ISO/IEC JTC1 SC7 Plenary Meeting 2006, obteniendo la aprobación para que sirva de base para el futuro estándar ISO/IEC “Software Engineering — Lifecycle Profiles for Very Small Enterprises (VSE)”. A continuación les narramos algunos detalles sobre esta participación.

¿Qué es el ISO/IEC JTC1 SC7?La Organización Internacional de Estándares (ISO) y la Comisión Internacional Electrotécnica (IEC) con-forman un sistema especializado en la definición de estándares internacionales. Las naciones que son miembros del grupo de ISO o IEC participan en el desarrollo de estándares internacionales a través de comités técnicos establecidos por cada una de estas organizaciones. Las propuestas de estándares inter-nacionales son recibidas por el comité técnico corres-pondiente y enviadas a los representantes de cada país miembro. Para ser publicada como estándar in-ternacional, una propuesta requiere tener una apro-bación de al menos 75% de los países miembros.

En el caso de temas de interés mutuo entre estas organiza-ciones, se generan comités técnicos mixtos. Tal es el caso del comité técnico JTC1, dedicado al área de Tecnología de Información. Dentro de éste, el subcomité SC7 es el de-signado para ingeniería de software y sistemas. A su vez, como parte del SC7, existe el grupo de trabajo 24 (WG24), cuyo objetivo es generar estándares para el desarrollo de perfiles y lineamientos para el ciclo de vida de software en micro y pequeñas empresas.

¿Cómo fue que se fijaron en nosotros?En octubre del 2005, la Dra. Hanna Oktaba presentó MoProSoft durante un evento sobre mejora de procesos para pequeñas empresas organizado por el Software Engineering Institute (SEI) en Pittsburgh (ver “Tejien-do Nuestra Red”, Ene-Feb 2006). Una de las personas que más se interesó en MoProSoft fue Claude Laporte, fundador del Software Improvement Process Network

(SPIN), de Montreal, y líder de la delegación Canadien-se para un grupo de trabajo en el ISO.

En noviembre de 2005, Claude asistió a la conferencia SEPG LA realizada en Guadalajara, donde Gloria Quin-tanilla le presentó MoProSoft en detalle. Fue entonces que Claude se dirigió con Ivette García de la Secretaría de Economía para solicitarle la participación oficial de México en el WG24 para presentar MoProSoft.

Fue así que México fue invitado para presentar MoProSoft en el marco de la sesión plenaria 2006 del ISO/IEC JTC1 SC7 en Bangkok, Tailandia, y que sus servidores fuimos elegidos para integrar dicha delegación.

Desarrollo de la Sesión PlenariaDurante la sesión plenaria, presentamos MoProSoft for-malmente ante los miembros del WG24. El resultado fue muy positivo. El Convener del grupo, Tanin Uthayanaka propuso usar las normas mexicanas como base para los trabajos del grupo, obteniendo aprobación unánime por parte de todos los delegados. Posteriormente discutimos sobre las razones por las que las pequeñas empresas no utilizan estándares, y presentamos detalles sobre la co-bertura que tiene la norma mexicana de estándares como ISO/IEC 9000, 12207, 15504 y 9126, además de modelos de referencia como CMMI y PMBoK.

El grupo de trabajo quedó satisfecho, y nos solicitó una versión en inglés de la norma mexicana, para poder uti-lizarla como base para el nuevo estándar. Se acordó que la próxima reunión del grupo de trabajo se realizará en Luxemburgo del 2 al 6 de octubre de este año, y solicitaron la participación de la delegación mexicana para dar conti-nuidad a este proyecto.

¿Por qué fue Importante esta participación?• Porque ubica al modelo de procesos mexicano a la cabe-za de los estándares internaciones para PyMES.• Porque prueba que “lo hecho en México, está bien hecho”, y no sólo eso, sino que puede llegar a ser de calidad internacional.

06 www.softwareguru.com.mxwww.softwareguru.com.mxJUL-AGO 2006

CO

LUM

NA

Poniendo el EjemploNorma Mexicana Será Base para una Nueva Norma ISO

TEJIENDO NUESTRA RED

No lo puedo creer. Cuando un domingo de agosto de 2002, nos juntamos ocho mujeres en mi casa de descanso cerca de Yautepec, para poner a volar nuestra imaginación y conocimientos, ideando un esqueleto general de lo que hoy es MoProSoft, nunca imaginábamos que cuatro años después éste llegara a tener un reconocimiento internacional. Durante este tiempo, varias instituciones y personas han puesto sus granitos o granotes de arena para que esto su-ceda. En esta ocasión les cedo la palabra en esta columna a Ana Vázquez y Jorge Palacios de la AMCIS, quienes, como representantes de México, lograron que la norma mexicana fuera aprobada como base para una nueva norma ISO.

La Dra. Hanna Oktaba es profe-sora de la UNAM a nivel licenciatura y posgrado. Sus áreas de interés principales son Ingeniería de Software, Tecnología Orientada a Objetos, Modelos de Procesos de Software y Mejora de Procesos. Es fun-dadora de la AMCIS, de la cual actual-mente es Secretaria. Estuvo a cargo de los proyectos MoProSoft, EvalProSoft y Pruebas Controladas, base de la actual Norma Mexicana para la Industria de Software. Actualmente es miem-bro de International Process Research Group (IPRC), orga-nizado por Software Engineering Institute (SEI), cuyo objetivo es definir las líneas de investigación en el área de procesos para los próximos diez años. También es Directora Técnica del proyecto COMPE-TISOFT, cuyo objetivo es la mejora de pro-cesos para fomentar la competitividad de pequeña y mediana industria de software en Iberoamérica.

• Porque con esto estamos a la vanguardia en una rama de la tecnología, ya que la metodología también es tecnología.• Porque probamos ante los especialistas que nuestro mo-delo nacional cumple no sólo con los estándares de referencia, sino también con los objetivos para los que fue creado.

Hallazgos durante nuestra participaciónA continuación compartimos lo que hemos llamado “la ca-dena de hallazgos” que tuvimos durante esa semana de trabajos.

1. Fuimos los únicos latinoamericanos en asistir, y junto a dos españoles éramos los únicos que por lengua materna teníamos el español. Los latinos no acostumbramos figu-rar en estos comités, y no porque no tengamos algo que aportar, sino porque aún no terminamos de resolver al interior de nuestros países las causas que nos mantienen fuera de la punta tecnológica.

2. Los miembros de las demás delegaciones nos recibieron, convivieron y trabajaron con nosotros en una forma muy afable y cordial, tanto que nos hicieron sentir como con nuestro propio equipo de trabajo. A pesar de que todos los presentes eran prestigiosas personalidades en cada uno de los tópicos, nadie se etiquetaba como experto.

3. Nos dimos cuenta que el WG 24 es uno de los grupos con mayor participación del SC7, donde delegados de países como Irlanda, India, Luxemburgo, USA, Canadá, Finlandia, Corea, Bélgica, Tailandia, corroboraron nues-tra sospecha sobre que la mayoría de las empresas que producen software en sus países son de menos de vein-ticinco personas. Esto les hace casi imposible imple-mentar CMMI, y en contraparte no tienen una forma de comprobar que son confiables para realizar un proyecto de software.

4. Encontramos que el estándar mexicano cumple con un alto porcentaje de los requerimientos planteados por el grupo, y que estos son asombrosamente similares a los que el Gobierno Federal (de México) planteó cuando de-cidió apoyar esta iniciativa. Los comentarios derivados de la presentación de la norma estuvieron en el orden de “It is terrific”, o “It has extremely high quality”. Algunos de-talles quedaron capturados en video, y próximamente los publicaremos en el blog de SG.

5. El SC7 contiene 25 grupos de trabajo, cada uno tra-bajando en desarrollar y/o mejorar estándares rela-cionados con ingeniería de software y sistemas. Nos entristeció saber que ningún mexicano, de hecho nin-gún latino, trabaja en alguno de estos grupos. En com-paración, Estados Unidos contó con la participación de más de cincuenta delegados. Con ello, interviene prácticamente en todos los grupos de trabajo, lo que le permite influenciar sus resultados y recoger los avan-ces para diseminarlos en sus comunidades, lo que sola-mente contribuye a aumentar la brecha.

6. Algo que nos sorprendió, fue que no encontramos a na-die del SEI. Esto nos dejó claro que la ingeniería del soft-ware es mucho más que CMMI.


TEJIENDO NUESTRA RED

ConclusiónLos mexicanos tenemos una evidencia más de que con disciplina, trabajo en equipo, creyendo en nosotros mismos y aplicando las mejores prác-ticas hoy por hoy podemos crear organizaciones que desarrollen software de clase mundial de la única manera que en realidad podemos hacerlo: “a la mexicana”.

—Ana Vázquez y Jorge Palacios

Ana Vázquez es Directora de la AMCIS. Coordinó el proyecto de pruebas controladas de MoProSoft y actualmente es Practicante MoProSoft.

Jorge Palacios es VicePresidente de la AMCIS. Participó como editor de EvalProSoft y actualmente es evaluador profesional MoProSoft.

L a semana pasada asistí a un curso en el SEI en Es-tados Unidos. En él, tuve la oportunidad de convivir con un grupo de consultores, directores de calidad

y otros expertos en calidad con experiencia en implanta-ciones de CMMi en diferentes tipos y tamaños de compa-ñías. Durante la semana surgieron varias conversaciones referentes a los problemas que habíamos enfrentado al in-tentar implantar procesos, métricas y modelos en nuestros ámbitos de trabajo, así como diferentes técnicas, teorías y actividades para lidiar con dichas situaciones. Pero lo que me asombró, fue cómo la conversación regresaba una y otra vez a los valores de la organización. As

La relación entre valores y comportamiento¿Qué valora tu organización como lo más importante? Esta pregunta es sumamente relevante. Muchas veces la idea de llevar a la organización a CMMi parecería que sólo tiene que ver con definir procesos y entrenar a los diferentes partici-pantes en cómo seguir estos procesos para después obli-garlos a llevarlos a cabo. Desafortunadamente el cambio a largo plazo no funciona de esta manera.

Existe una fuerte relación entre lo que la organización va-lora, y cómo se comporta. No podemos definir procesos y exigir que la organización los lleve a cabo, si no cambia-mos los valores que rigen el comportamiento. ¿El cliente es lo más importante?, ¿La organización valora el trabajo inteligente o el trabajo extremo? ¿La organización apoya al crecimiento de los individuos? ¿El entrenamiento se ve como una necesidad o como un premio? Es una combina-ción de todas estas ideas y valores, lo que conforma la naturaleza de una compañía. Estas preguntas no siempre son sencillas, y las respuestas no siempre son lo que nos gustaría oír. Pero es imprescindible hacerlas y responder-las con gran franqueza, ya que las respuestas definen la dirección que toman nuestras acciones como individuos y como grupos.

Démosle un nuevo valor a la organizaciónAhora bien, la pregunta importante: Si los valores son tan importantes para manejar el comportamiento, y la única forma de cambiar el comportamiento es a través de cam-biar los valores, entonces ¿cómo cambiamos los valores? Ésta pregunta es parte del estudio de antropólogos, so-ciólogos y filósofos. La realidad es que no está muy claro cómo se generan los valores en las personas, y por ende cómo se modifican. Algunas teorías argumentan que los valores se crean en base a la observación de nuestro mun-do y a la suma de experiencias y sucesos que nos lleva a tomar decisiones de nuestra vida, formando así un punto de vista sobre lo que queremos y es importante para no-sotros. La siguiente gráfica muestra el ciclo que forman nuestras observaciones, valores y comportamientos.

Iniciamos con preguntas sobre nuestro medio ambiente: Si lo más importante para mí es generar proyectos que me den utilidad, entonces ¿por qué no los estoy generando? Esto me lleva a observar a mi alrededor, ¿cómo es que genero y pierdo valor en mis proyectos? Esto me lleva a entender que mien-tras los proyectos ocupen más horas que las planeadas no puedo generar valor, por lo que ahora mi enfocaré en ser una compañía con proyectos siempre bajo control, y eso me lleva a incrementar la planeación y seguimiento. A su vez, esto me lleva a nuevas preguntas como ¿por qué el diseño que hace-mos no es óptimo?, y así sucesivamente genero nuevas ob-servaciones que llevan a nuevos valores y comportamientos.

Medir, aprender y moldear nuestros valoresParece bastante sencillo y directo: una empresa de calidad es una empresa que constantemente se pregunta cómo satisfa-cer mejor sus objetivos, luego genera métricas que la ayudan a generar observaciones sobre lo que está sucediendo, y ge-nera conclusiones. Estas conclusiones hacen que modifique sus valores y comportamientos en base a los resultados.

Desafortunadamente no es tan sencillo. Para empezar, no siempre es fácil responder ¿qué es lo más importante? En la mayoría de los casos no es una relación directa entre una pregunta, una observación y un nuevo valor, sino que se se requieren muchas preguntas y muchas para cambiar un va-lor. Otra complicación es el hecho de que en muchas ocasio-nes existe un retraso entre una observación y la acción que la generó, lo cual hace mucho más difícil el aprendizaje.

Pero al final de cuentas, ese es el reto para un verdadero agente de cambio. Sigamos abriendo preguntas, enfocando observaciones y cambiando nuestras organizaciones. Si quieres platicar más sobre el tema nos vemos en:www.agentesdecambio.org o escríbeme a: [email protected]

—Luis Cuellar

CO

LUM

NA

08 www.softwareguru.com.mx

Valores y comportamientosLa clave para el cambio

MEJORA CONTINUA

Luis R. Cuellar es Director de Calidad a nivel mundial de Softtek Information Services. Luis es reconocido por la American Society for Quality (ASQ) como Certified Quality Manager, Certified Software Engineer, y Six Sigma Black Belt. En los últimos cinco años ha estado a cargo de la definición e implantación de la estrategia para CMM5 y Six Sigma a través de las diferentes áreas del centro de desarrollo de Softtek.

JUL-AGO 2006

Ciclo para generar nuevos valores y comportamientos

Four Js Development Tools, en conjunto con la empresa ANTs Software Inc., lan-zan al mercado Genero db, una base de datos relacional de alto desempeño y escalabilidad, diseñada para atender miles de usuarios concurrentes. Genero db obtiene estas ventajas del ANTs Data Server, un sistema para bases de datos relaciona-les basado en un novedoso motor de ejecución de SQL que explota al máximo las ven-tajas de los procesadores modernos, comunicándose al nivel de operaciones atómicas de CPU, y brindando así una novedosa arquitectura sin candados (lock-free).

Genero db soporta el estándar SQL-92, y brinda soporte nativo para las bases de datos de Informix, Oracle y Microsoft, incluyendo stored procedures y triggers, logrando que el usuario pueda migrar a Genero rápidamente, con el mínimo es-fuerzo y bajo costo. La base de datos incluye capacidades de recuperación de desastres, replicación y recuperación automática.

Los sistemas operativos soportados incluyen Windows 2000/XP/2003, Red Hat Enterprise, Suse, Fedora y Solaris.

Mayor información en: www.4js.com

PR

OD

UC

TO

S

PRODUCTOS

AMQPProtocolo Open-Source para Mensajería

Un grupo de empresas que incluye a JPMorgan, Iona y Red Hat están desarrollando un nuevo pro-tocolo para manejo de colas de mensajes, denomi-nado AMQP. El objetivo es proveer una alternativa a tecnologías propietarias como IBM MQSeries y Sonic Software. La visión es que diferentes provee-dores puedan desarrollar productos basándose en un mismo protocolo, o incluso que las empresas puedan desarrollar sus propias soluciones.

Algunos analistas cuestionan el éxito que pue-da tener un proyecto de este tipo, argumentan-do que sería mejor utilizar JMS (Java Message Service) al nivel de infraestructura de mensa-jes, y resolver los aspectos de interoperabili-dad al nivel de interfaces de servicio. En fin, ya veremos que sucede.

LO QUE VIENE

Four JsBase de Datos de Alto Desempeño

DuetComunicación entre Office y SAP

SAP y Microsoft están por liberar Duet, un producto desarrollado en conjunto que permite acceder e interactuar con aplicaciones empresariales de SAP, a través de Microsoft Office. Duet es el resultado del proyecto anunciado por ambas empresas hace un año, con el nombre clave “Mendocino”.

Algunas de las cosas que se podrán hacer con Duet serán:• Registrar tiempos (time management) desde el calendario de Outlook.• Acceder información organizacional (empleados, posiciones, organigra-mas) como contactos de Outlook.• Visualizar reportes calendarizados desde Excel.• Administrar actividades de venta (citas, contactos, workflows) desde Outlook.

El producto ha estado disponible como beta para clientes selectos desde hace varios meses, y se espera su disponibilidad general hacia principios de julio. Ambas empresas han anunciado que será un producto en constan-te desarrollo, y se esperan nuevas versiones antes de que termine el año.


Eclipse Lanzamiento Simultáneo de Diez Proyectos

La Fundación Eclipse liberará nuevas versiones de diez de sus proyectos de manera simultánea, en un esfuerzo para sincronizar la compatibilidad de éstos. Dicho lanzamiento tiene el nombre clave “Callisto”, e incluye cerca de 7 millones de líneas de código. Callisto incluye nue-vas versiones del framework de modela-do, el editor visual, las herramientas de prueba, y herramientas de business in-telligence y reporteo.

Cada uno de estos proyectos se había desarrollado por separado, por lo que la integración y comunicación entre sí no era de lo mejor. El objetivo con Callisto es integrarlos y sincronizarlos para pro-veer una mejor experiencia al usuario. Quince empresas de software contribu-yeron con desarrolladores localizados en doce países diferentes para colaborar en dicho esfuerzo.

PR

OD

UC

TO

S

Visual Studio Team SystemCreando Proyectos de EquipoPor Rigoberto Calleja

M icrosoft Visual Studio Team System (VSTS) es un con-junto de herramientas de gestión del ciclo de vida de desarrollo de software que abordan las necesidades de

una variedad de roles dentro de la organización. VSTS viene en cinco ediciones diferentes e incluye una plataforma de colabo-ración denominada Team Foundation Server (TFS) que permite administrar y dar seguimiento al avance y al estado del trabajo en base a una serie de servicios Web y repositorios integrados. El elemento clave dentro de TFS es el proyecto de equipo que pro-porciona una ubicación central para que los usuarios coordinen su trabajo. En este artículo hablaré de qué son los proyectos de equipo, explicaré los conceptos principales asociados a aquéllos, daré un brevísimo panorama de la funcionalidad de TFS y descri-biré tanto el procedimiento como algunas consideraciones sobre cómo crear un proyecto de equipo.

Conceptos ImportantesUn proyecto de equipo no es otra cosa más que un contenedor que mantiene información acerca de cada paso del ciclo de vida de desa-rrollo de software en un repositorio central dentro de TFS. Los pro-yectos de equipo se componen de una serie de elementos de trabajo, piezas de código, casos de prueba, productos de trabajo, métricas, etc., los cuales son empleados para dar seguimiento al trabajo de un proyecto.

Vale la pena aclarar que un proyecto de código de Visual Studio es diferente a un proyecto de equipo en Team System. Mientras que el primero sirve para organizar código, el último se usa para organizar todo el esfuerzo de desarrollo de software.

Dentro del contexto de la creación de un proyecto de equipo existen dos componentes clave: la plantilla del proceso y los reportes del proyecto.

La plantilla de proceso es un mecanismo de Team System que define tanto la configuración como el contenido inicial del proyecto de equi-po, a través de: un conjunto default de elementos de trabajo, plan-tillas de artefactos, reportes, grupos de seguridad y documentos de la orientación del proceso. Toda plantilla está basada en un proceso de desarrollo de software que va acompañado de un enfoque muy particular acerca de cómo desarrollar y mantener software.

Team System incluye dos plantillas de proceso base: MSF for CMMI Process Improvement, orientado a organizaciones que requieren un proceso formal y con guías explícitas, y MSF for Agile Software De-velopment, orientado a proyectos con un ciclo de vida más ágil, y donde los miembros del equipo no van a recurrir mucho a las guías de proceso. Desde luego, es posible modificar estas plantillas, ex-tenderlas, o crear nuevas plantillas en base a los procesos específi-cos que sigue una organización.

Team System emplea el concepto de elemento de trabajo para dar seguimiento a la asignación y al estado del trabajo asociado al ciclo de vida de desarrollo de software. Existen varios tipos de elementos de trabajo en función del tipo de trabajo que repre-sentan. Por ejemplo el elemento de trabajo “tarea” permite dar seguimiento a las actividades de desarrollo, pruebas, etc. Otros ejemplos de elementos de trabajo son: solicitud de cambio, re-querimiento y revisión. Altamente acoplada con la plantilla de proceso está la orientación del proceso, que es la documentación acerca de roles, actividades, productos de trabajo y reportes personalizados para un método de ingeniería de software. En muchas organizaciones de desarrollo, los documentos de orientación del proceso forman un interminable grupo de carpetas mientras que en Team System, la orientación del proceso está completamente integrada a las herramientas de desa-rrollo. (Ver la siguiente figura)

NOVEDADES

Rigoberto Calleja Cervantes es Ingeniero de Procesos de Software de Itera. Es egresado del ITESM y actualmente está cursando el Certificate in Software Engineering en la Universidad Carnegie Mellon.


NOVEDADES


Por otro lado, cada plantilla de proceso incluye un conjunto prede-finido de reportes. Los reportes constituyen una de las herramien-tas más poderosas de VSTS ya que permiten al administrador del proyecto monitorear el estado y tendencias del proyecto de equipo. TFS incluye un almacén de datos en el que se recopilan los datos operativos que provienen de los elementos de trabajo, control de versiones, generaciones del producto y resultados de las pruebas. Este almacén es empleado para producir los reportes. Una de las enormes ventajas de usar Team System, desde la perspectiva de administración de proyectos, es que no es necesario correlacionar manualmente datos provenientes de varias fuentes.

Entre los reportes que se incluyen están: reportes estilo semáforo sobre la salud del proyecto, reportes informativos que muestran: la tasa de defectos, la productividad del equipo, la efectividad de las pruebas en las distintas generaciones del producto, el progreso del trabajo en el tiempo y la estabilidad de los requerimientos en el tiempo. (Ver las siguientes dos figuras.)

Procedimiento de Creación de un Proyecto de EquipoPara crear un proyecto de equipo se emplea una ventana llamada Team Explorer. Esta ventana permite navegar y administrar todos los elementos de un proyecto de equipo tales como la estructura del equipo de trabajo, el portal del proyecto, el repositorio de control de código fuente, la base de datos de elementos de trabajo, documen-tos, reportes y plantillas.

Para crear un nuevo proyecto de equipo se siguen estos pasos:1. Seleccionar la opción de menú File>New>Team Project. El asis-tente de nuevo proyecto de equipo aparecerá pidiéndole el nombre del proyecto.

2. Seleccionar una plantilla de proceso, ya sea MSF For CMMI, MSF for Agile, o alguna personalizada.

Vale la pena recalcar que la decisión más importante de todo el pro-cedimiento de creación de un proyecto es justamente determinar qué plantilla de proceso se empleará. Uno de los aspectos funda-mentales de VSTS, es que a diferencia de otros productos de Mi-crosoft, éste no fue diseñado para sacarlo de la caja y usarlo; es necesario emplear cierto tiempo en definir una estrategia de uso, y configurarlo. Es decir, es necesario adecuarlo a la manera cómo usted desarrolla software. La selección del proceso de desarrollo de software y plantilla asociada se basa en tres factores: la forma de cómo su organización trabaja actualmente, las necesidades de ne-gocio actuales de la organización, y la manera como se desea que la organización trabaje en un futuro. Por ejemplo si usted forma parte de una organización de gran tamaño, probablemente ya tiene una metodología de desarrollo de software que le fue prescrita; si tra-baja en proyectos gubernamentales probablemente su proceso de desarrollo de software es compatible con modelos de referencia ta-les como MoProSoft o CMMI, y finalmente, si usted colabora en una organización que emprende proyectos cortos con un ciclo de vida reducido, probablemente está usando una metodología ágil.

3.- Posteriormente se asigna un título para el portal del proyecto y una descripción del mismo.

Este portal es un sitio web que se construye a partir de Windows Sharepoint Services (WSS 2.0) y que provee acceso ligero a aquellos miembros del equipo de trabajo que requieren tener visibilidad acer-ca del proyecto. A través del portal los usuarios pueden ver reportes, revisar documentos y mirar anuncios entre otras cosas.

4.- En la última página del asistente se establecen las opciones pre-liminares de control de código fuente. Usted tiene la opción de crear una carpeta de control de código fuente para su proyecto o crear una nueva rama a partir de un árbol de control de código fuente existente.

Team Foundation Server provee capacidades avanzadas para control de versiones, tales como conjuntos de cambios, ramas, fusiones, comparación de archivos, protecciones atómicas y soporte a equi-pos distribuidos geográficamente. Dichas capacidades sobrepasan fácilmente lo que puede hacer un simple Visual Source Safe, y están diseñadas para satisfacer las necesidades de equipos grandes desa-rrollando aplicaciones complejas.

Una vez que el procedimiento de creación de un proyecto de equipo ha concluido, dependiendo de la plantilla de proceso que usted haya seleccionado, una serie de documentos de orientación del proceso serán generados para su proyecto. Asi mismo, varias carpetas apare-cerán en el Team Explorer.

El árbol del proyecto de equipo tiene cinco nodos principales: Ele-mentos de Trabajo, Documentos, Reportes, Generaciones del Equipo y Control de Código Fuente. El nodo de elementos de trabajo incluye consultas predefinidas y personalizadas que sirven para listar los elementos de trabajo asociados a su proyecto. El nodo de documen-tos contiene una serie de carpetas que apoyan en la organización de los artefactos generados por el proceso de desarrollo. El nodo de

reportes incluye una variedad de tipos de reportes para mirar las mé-tricas de su proyecto. El nodo generaciones del equipo ofrece acceso a una variedad de tipos de generaciones, incluyendo tipos personali-zados. Finalmente, el nodo de control de código fuente le da a usted acceso al árbol de código fuente.

ConclusiónEn Team System un proyecto de equipo representa la mate-rialización de un proyecto de desarrollo y se compone de re-portes, plantillas, orientación de proceso, mejores prácticas, control de código fuente, elementos de trabajo, generaciones del producto y un portal de proyecto entre otros elementos. En este artículo se describió el procedimiento para crear un proyecto de equipo el cual consta de cinco pasos, al térmi-no de los cuales se obtiene un poderoso entorno de gestión del trabajo soportado por la plataforma de colaboración de Team Foundation Server.

Portal del proyecto

PR

OD

UC

TO

SNOVEDADES

Team Explorer


PR

OD

UC

TO

S

SAP Composite Application FrameworkAutomatización Flexible de ProcesosPor Gerardo Borbolla

TUTORIAL


Una de las grandes promesas del uso de BPM, en conjunto con arquitec-turas orientadas a servicios, es la

capacidad de poder automatizar procesos de negocio de forma flexible, utilizando ser-vicios e información de aplicaciones existen-tes. El objetivo de este tutorial es mostrar cómo se puede lograr esto a través del Com-posite Application Framework de SAP.

El Composite Application Framework (CAF) es un conjunto de herramientas para inte-grar componentes de manera que formen una sola aplicación, enfocándose al diseño y configuración con un mínimo esfuerzo de programación. A través del CAF, podemos ensamblar aplicaciones a partir de cualquier componente definido en SAP NetWeaver, o componentes externos a través de estánda-res y protocolos como SOAP, XMLA, servicios de SSO, RMI, IIOP, entre otros.

Recordemos que NetWeaver es la plataforma sobre la que se ejecutan las aplicaciones de SAP. Adicionalmente, provee servicios para integración entre aplicaciones e interacción con componentes externos. Así que en resu-men, NetWeaver es el middleware de integra-ción y ejecución para las aplicaciones de SAP.

En este tutorial, crearemos un “Guided Procedure”, que es un proceso orientado a usuarios. Esto se hace en el portal de SAP, el cual nos permite diseñar procesos para lue-go ejecutarlos ahí.

Instalación de SAP NetWeaver Sneak PreviewAfortunadamente, es posible descargar de forma gratuita una versión de evaluación del ambiente de desarrollo y ejecución de la plataforma NetWeaver. Esto se obtiene a tra-vés del portal para desarrolladores de SAP (sdn.sap.com).

Una vez que se registran y entran al SDN, en la sección de “Downloads” seleccio-nan el “Sneak Preview SAP NetWeaver...” y posteriormente seleccionan la “Full Java Edition 2004s”, que es la más completa. Tengan en cuenta que los instalables mi-den cerca de 5GBs, así que tengan pacien-cia o descárguenlos desde una conexión muy rápida. También consideren que van a necesitar una máquina con un mínimo de 1GB en memoria.

ComenzandoUna vez hecha la instalación, podemos de-dicarnos a desarrollar un workflow. En este caso, vamos a implementar uno muy sencillo con los siguientes tres elementos:• Captura de información.• Búsqueda de información relevante a los datos del proceso.• Autorizaciones de otros usuarios.

Para implementar este proceso, los pasos a grandes rasgos son:

1. Crear un usuario y los roles correspon-dientes.2. Crear los componentes que se utilizan en el flujo.3. Crear el flujo y ejecutarlo.

Administración de UsuariosLa administración de usuarios se realiza a través del mismo portal de SAP. Para crear los usuarios seguiremos los si-guientes pasos:

1. Entrar en el portal utilizando el URL http://localhost:50000/irj con el usua-rio y password ‘admin’, que son los pre-establecidos por default.2. Seleccionar la ceja “Gestión de usua-rios” y la ceja inferior “Usuarios”.3. Seleccionar la liga “Crear usuarios”, en la sección de Navegación detallada.4. Llenar los campos obligatorios (son los que tienen un asterisco rojo) y hacer click en el botón “Crear” (hay que ha-cer scroll hacia abajo). En este ejemplo, crearemos un usuario llamado Blanca Gómez (bgomez).

Ahora asignamos roles a este usuario. En SAP Portal, los roles se relacionan con las páginas y aplicaciones que un usuario puede acceder. Asignaremos los roles para diseñar, ejecutar y administrar guided procedures.

Buscaremos el usuario dentro de la admi-nistración de roles y luego le asignamos los pertinentes:

1. Seleccionamos la ceja “Gestión de usuarios” y la ceja inferior “Roles”.2. Seleccionamos “Usuarios” en el drop-down-list y ponemos bgomez en la caja “Buscar”.3. Hacemos click en “Iniciar”. 4. Cuando muestre el resultado, hacer click en la liga “Tratar”, del renglón de bgomez.5. En esta pantalla buscaremos el rol *eu* en el panel inferior del lado iz-quierdo. Seleccionaremos los dos ren-glones que aparecen y haremos click en “Añadir”.6. Hacer click en “Guardar”.

��

��

��

��

��

�

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

Gerardo Borbolla Luna es asesor de tecnología para SAP NetWeaver en SAP México. Es especialista en diseño de la arquitectura de soluciones basadas en J2EE, portales, herramientas de KM, colaboración, integración y desarrollo de aplicaciones. Ha colaborado para LGEC, BEA y Quarksoft, entre otras empresas, trabajando sobre BEA Tuxedo, C++, TCP/IP, Sybase, Informix, SQLServer, Oracle, Linux, Solaris, BEA Weblogic y Java.

Figura 1. Plataforma NetWeaver

TUTORIAL


Para comprobar que se han asignado correcta-mente los roles, hay que entrar al portal (http://localhost:50000/irj) con “bgomez” y revisar que se tiene la ceja “Guided Procedures”.

Elementos de un Guided ProcedureAntes de continuar, necesitamos conocer los elementos con que cuentan los Guided Procedures para implementar un flujo de trabajo. Estos son:

Callable Object. Un callable object encapsu-la un componente técnico para ser usado de forma fácil en un proceso.

Action. Un action (acción) es una actividad en el proceso. La acción a su vez encapsu-la un callable object, y le agrega atributos como permisos, documentos y atributos de vigencia con notificaciones.

Block. Un block (bloque) es una secuen-cia de acciones, otros bloques e incluso procesos. Los elementos de un bloque se pueden ejecutar en forma secuencial, en paralelo, en ciclos o de manera discreta (como un block case).

Los datos que fluyen en un bloque se de-finen relacionando los parámetros de las acciones y bloques que contiene. A este proceso se le llama Consolidación de Pará-metros. En un bloque también se definen los responsables que se van a encargar de realizar las acciones. Este proceso se lla-ma Consolidación de Roles. A un bloque también se le pueden asociar documentos y ligas.

Proceso. Un proceso consta de una serie de bloques o procesos, agregando las siguien-tes características:• Definir el número de instancias que se pueden ejecutar de manera simultánea.• Asignar de manera predefinida usuarios o grupos a los roles definidos en los bloques.• Consolidar roles: crear roles a nivel pro-ceso a partir de los roles de los bloques o procesos que lo conforman.

Uso de la Interfaz GráficaLa interfaz para definir Guided Procedures se accede por el browser y se encuentra en la ceja “Guided Procedures”, en la ceja inferior “Design Time”. En este caso usaremos a Blanca Gómez como creadora del proceso (los permisos son muy importantes en la creación del proceso).

Los elementos de Guided Procedures (Callable Objects, Acciones, Bloques, etc) se agrupan en una estructura similar a un sistema de archivos. El acceso y administración de estos ele-mentos se hace en la Galería de Guided Procedures.

Tenemos controles para crear y borrar carpetas, ligas para crear componentes y un área que muestra un resumen del componente seleccionado. En todas las pantallas de creación de componentes, existe una liga arriba y del lado izquierdo con la etiqueta “Gallery”, que siem-pre nos remite a esta interfaz.

Creación de Callable ObjectsSeleccionemos el icono “Root” y luego hagamos click en “Create Folder” al que vamos a bautizar como TutorialGP.

Seleccionemos este nuevo fólder en la galería y luego la liga “Create Callable Object”. Vamos a crear varios objetos de esta manera:

El primer Callable Object que crearemos será un objeto de búsqueda de información. Así que al crear el objeto seleccionaremos el tipo “Web Pages” y lo nombraremos “InfoMarca”. Ha-ciendo click en “Next” nos lleva a la pantalla para definir el URL de la página. Ingresaremos http://www.google.com/search?hl=es. En la siguiente pantalla podemos ingresar los pará-metros adicionales para el URL. Vamos a insertar uno con los parámetros “Technical Name” = q y “Name” = Marca. Continuamos con las siguientes pantallas hasta el final en donde hace-mos click en “Finish and Open”.

Una vez que hayamos dado click en “Test callable Object” para probar que todo esté bien, debemos activarlo para poder usarlo. Esto se hace con en “Activate Callable Object”.

Figura 2.. Galería de Guided Procedures

Es muy importante activar TODOS los obje-tos creados (Actions, Blocks, etc) para poder utilizarlos.

Para regresar a la galería seleccionamos la liga “Gallery” en la esquina superior izquierda.

El siguiente objeto que crearemos será un Obje-to de Captura de datos. El tipo es “Data Forms/Data input form”, y le vamos a poner el nom-bre CapturaDatos. Seleccionamos “Next” en el paso “Define Object” y en la pantalla siguiente insertamos cuatro campos de tipo string:• nomAsegurado (Nombre)• apAsegurado (Apellidos)• marcaAuto (Marca del auto)• modeloAuto (Modelo del auto)

Finalizamos la creación de nuestro objeto, lo probamos y lo activamos.

Seguimos con un Objeto de aprobación. El tipo es Process Control/Visual approval con el nombre “Aprobacion”. En el paso “Define Input”, crearemos los mismos campos que en el objeto de captura de datos (lo hacemos así por facilidad, pero pudieran tener nom-bres diferentes). Finalizamos la creación del objeto, lo probamos y lo activamos.

AccionesPara crear las acciones que necesitamos ha-cemos lo siguiente:

En la galería, seleccionamos nuestro fólder de trabajo, y “Create action”. Entonces in-gresamos “Capturar datos de la póliza” y seleccionamos “Save and open”.

Aquí veremos las actividades para configurar la acción. Damos click en la liga “Callable Objects” y se presenta la pantalla para crear o escoger el Callable Object a asociar a esta acción. Hace-mos click en “Choose...” del renglón “Object for Execution”, seleccionamos nuestro objeto Cap-turaDatos, y damos click en “Save”. Recuerden activar la acción después de hacer esto.

Ahora vamos a crear una acción denomi-nada “Aprobar póliza”, relacionada con el

objeto de aprobación. Sin embargo, en esta ocasión asociaremos el objeto de búsqueda como una liga que aparecerá en esa acción, para asistir al usuario a buscar autos. Para esto, seguimos los mismos pasos, pero an-tes de activar vamos a hacer click en “Add info Callable Objects”, y agregamos el ob-jeto “InfoMarca” y salvamos. Por último, seleccionamos de nuevo “Add Info Callable Objects” y hacemos click en el botón “Map Parameters”. Aquí relacionamos el paráme-tro del objeto de búsqueda con los pará-metros de nuestra acción. Seleccionamos “marca” en ambas listas y click en “Done”. Luego salvamos y activemos la acción.

Definición del Proceso Utilizaremos un método que crea un proceso con un bloque. Para esto, vamos a la gale-ría y seleccionamos nuestra carpeta y luego “Create Simple Process”. Después de pasar la pantalla de bienvenida, damos nombre al proceso y al bloque que lo compone. Acepta-mos el tipo de bloque secuencial y pasamos a la siguiente pantalla.

Flujo. Comencemos por definir el flujo en caso de que la póliza no se apruebe. Para esto, expandamos el elemento “Aprobar póliza”, y seleccionamos “Input data is re-jected”. Después hacemos click en “Define Target...” y seleccionamos “Capturar datos de la póliza”. De esta manera indicamos que mientras no se apruebe la póliza, esta va a regresar a la captura.

Consolidación de parámetros. Relacionamos los parámetros de las acciones de nuestro proceso entre sí. Para realizar esta relación seleccionemos los elementos a asociar (Ej. los “nombres”), escribimos un nombre en el campo “Consolidate To” y damos click en “Go”.Posteriormente hacemos lo mismo con los demás parámetros.

Consolidación de roles. Aquí se asocian los roles de diferentes actividades y se les asigna un nombre. Dejemos esta pantalla como está y terminemos el proceso guar-dando y activando.

Visualizar el panel de ayuda de acciones. Para visualizar el panel de ayuda de las accio-nes hay que seleccionar el proceso en la gale-ría (hay que actualizar la página) y hacer click en “Open”. Después, seleccionar la liga “Se-lect Views” (aceptar crear una nueva versión en la ventana que se despliega) y presionar el botón “Save”. Activar el proceso de nuevo.

Ejecución del ProcesoPara ejecutar el proceso, nos vamos a la pestaña “Runtime” y seleccionamos la liga “Start a process”. Esto nos presenta la gale-ría, donde seleccionamos nuestro proceso y damos click en “Next”.

1. Asignación de grupos y usuarios. Al iniciar un proceso hay que indicar los usuarios de los roles. Tenemos los roles definidos mas tres administrativos. Para asignar usuarios hacemos click en “Add user”, buscamos a “bgomez”, y le asig-namos todos los roles.2. Iniciar el proceso. Damos un nombre a este proceso y seleccionamos “Initiate”.3. Utilizar el proceso. El sistema nos muestra las tareas y actividades, mar-cando las actividades realizadas y, pre-sentando en la sección de “Options”, los objetos de ayuda que nosotros asocia-mos a ciertas acciones.4. Podemos consultar en la pestaña “Runtime” los procesos en curso y las actividades realizadas y por realizar.

PR

OD

UC

TO

STUTORIAL


ConclusiónEste tutorial presentó con un ejem-plo simple la forma de integrar la información de diversas fuentes y aplicaciones en un flujo de trabajo orientado a usuarios. La manera de configurar y modificar los procesos en Guided Procedures es realmente fácil, utilizando aplicaciones existen-tes. Para más información, consultar las guías de configuración y desa-rrollo, en la sección de xApps en: sdn.sap.com

ENTERPRISE APPLICATION INTEGRATION

Mucho más que Productos de ModaPor Walter Risi

Imaginemos el caso de una compañía petrolera, cuyos pro-cesos de negocio van desde el descubrimiento de nuevas

fuentes de hidrocarburos hasta su explotación, pasando por varios procesos intermedios. Todos estos procesos son sopor-tados por diferentes aplicaciones, en un ambiente hetero-géneo con distintos proveedores, plataformas y productos. Supongamos ahora que necesitamos una ficha completa de un pozo petrolero en una ubicación geográfica particular. Dicha información podría estar diseminada entre una de-cena de aplicaciones distintas, ¿cómo podemos obtener la información integrada?

Situémonos ahora en la mesa de dinero de un importante banco que ha pasado por una fusión con otro banco de envergadura similar. Algunos productos financieros son manejados por una aplicación perteneciente al banco ad-quirido, y otros por aquella que tenía ya el banco compra-dor. Sin embargo, debemos consolidar ambas fuentes para poder calcular ganancias y pérdidas... ¿Volcamos reportes de ambas aplicaciones y los consolidamos manualmente? ¿Qué costo tendría eso? Y, ¿Cuál es la posibilidad e impacto de un error?

Situaciones como la anterior son vividas a diario por gran-des empresas de diferentes mercados, desde hace más de una década. Estas situaciones surgen de fenómenos natu-rales en la empresa... aplicaciones que nacieron y crecieron aisladas... aplicaciones de diversos fabricantes... fusiones y adquisiciones... y, sin duda, otras razones particulares. Sin embargo, algo queda claro: en la empresa actual, cuyas estrategias están cada vez más apoyadas desde las TIs, la in-tegración de las aplicaciones siguiendo las necesidades del negocio es una realidad. Pero la solución no está en SOA, Enterprise Service Bus, message-oriented middleware ni algún otro buzzword tecnológico, sino en una estrategia de inte-gración claramente alineada, planeada y ejecutada según las necesidades del negocio. De eso trata este artículo, de cómo abordar la Integración de Aplicaciones Empresariales con un marco de trabajo en el cual la tecnología está “al servicio” del negocio.

¿Qué es “Enterprise Application Integration” (EAI)?Se llama EAI al uso de medios de software para conectar a un conjunto de aplicaciones empresariales. En la definición ante-rior, “medios de software” es cualquier mecanismo que permita realizar tal conectividad, desde archivos planos hasta servicios de mensajería. Por otro lado, una “aplicación empresarial” es cual-quier aplicación que da servicios a la empresa, desde una aplica-ción propia del mercado en el cual opera (petróleo, banca, etc.) hasta las aplicaciones administrativas típicas (CRM, ERP, etc.).

La forma más simple de EAI, como para ilustrar este con-cepto, es el intercambio de datos entre dos aplicaciones a través de algún medio como un archivo plano o una base de datos. Es muy común en una empresa, por ejemplo, la existencia de “interfaces” consistentes en archivos planos de-positados temporalmente por un proceso en un directorio compartido, que luego son tomados por otro proceso. Otra forma muy común es a través de bases de datos accedidas por diferentes sistemas. Finalmente, las formas más modernas de EAI hacen uso normalmente de servicios de mensajería, des-de ad-hoc hasta basados en estándares de la industria.

Una Necesidad de Hoy y SiempreEl concepto de EAI no es para nada nuevo. Es tan antiguo como la necesidad de intercambiar datos entre dos aplicaciones separa-das, y las empresas han tenido este problema casi desde el mismo momento en que empezaron a usar sistemas de software.

¿Por qué EAI es una necesidad “de hoy y de siempre”? Por-que es una realidad que una empresa es un ecosistema de aplicaciones diferentes en naturaleza, que requieren comu-nicarse entre sí, pero que no fueron destinadas a comunicar-se entre sí. La necesidad de integración es estratégica y está para quedarse. La integración no debe entenderse como un problema del “hoy”, heredado de los sistemas legacy que no tuvieron en cuenta la necesidad de integrarse. Muy por el contrario, la integración es una realidad de siempre, ya que siempre tendremos sistemas diferentes en diferentes sectores del negocio, cuyas realidades siempre serán diferentes.

Walter Ariel Risi es Coordinador de Consultoría Tecnológica y consultor en mejora de procesos de software para Pragma Consultores Argentina. Anteriormente, se desempeñó como consultor de Lifia (Laboratorio de la Universidad Nacional de La Plata) para JPMorgan y Lumina Finance. Adicionalmente realiza tareas de investigación, habiendo publicado artículos en congresos y publicaciones internacionales. Walter posee las certificaciones Certified Quality Engineer (CQE) y Cer-tified Software Quality Engineer (CSQE) de la American Society for Quality (ASQ). [email protected]


ESPECIAL

Mientras que los problemas técnicos son generalmente visibles, los problemas

organizacionales no son tan evidentes.


Las Dificultades del EAILas dificultades más inmediatamente visibles, aunque no necesariamente las más importantes, son principalmente técnicas. Dado que muchos de los sistemas son pensados para ser utilizados en forma aislada (para un departamento o pequeño grupo de usuarios), raramente están preparados para soportar la seguridad y escalabilidad requeridas para ha-cerlos disponibles hacia otros usuarios y sistemas.

Por otro lado, existen problemas del estilo organizacional o de gestión, entre los cuáles distinguimos los siguientes:

• Integración “miope” y no planificada. Las interfaces pensadas para resolver la necesidad inmediata a veces crean acoplamientos indeseables, que se suman a la pila de sistemas legacy poco mantenibles. Se resuelve un pro-blema y se crea otro. • Carencia de un análisis de impacto en la forma de trabajar de los usuarios. Es decir, “luego de la integración de A y B... ¿cómo se ve afectado el trabajo de los usuarios de A y B?”.

Los anteriores no son más que manifiestos evidentes de los siguientes problemas de fondo, aún más graves:

• Mapa de aplicaciones no definido, desconocido o “spaghetti”. Esto dificulta de sobremanera detectar si una nueva integración no está causando un acoplamien-to indeseable, o si se está integrando en forma consisten-te en diferentes sectores de la empresa.• Relación entre aplicaciones y procesos de negocio no definida, poco clara o desordenada. Esto impide discer-nir qué aplicaciones son responsables de cada proceso o flujo de información y, por lo tanto, impide discernir la forma de integración más adecuada para el negocio.

Mientras que los problemas técnicos son generalmente visibles, los problemas organizacionales no son tan evi-dentes y, por lo tanto, son mucho más riesgosos. Y no sólo eso, sino que en general son también más difíciles y caros de solucionar. Por otro lado, la mayoría de los proyectos de EAI son conducidos por informáticos bien capacitados para resolver el aspecto técnico de la integra-ción, pero quizás no tan duchos en la detección y resolu-ción de los problemas organizacionales.

Finalmente, es importante pesar las dificultades en térmi-nos de los riesgos que las mismas suponen para el negocio. Una dificultad técnica normalmente puede solucionarse, eventualmente con costo adicional. Sin embargo, una integración (posiblemente costosa) que no fue pensada claramente desde el punto de vista del negocio, puede no acarrear beneficios para el mismo, redundando en un gas-to necesario (y tal vez problemas adicionales). Dejando a un lado el peso relativo de tales problemas, es claro que un proyecto de EAI es tanto informático como organiza-cional, ya que tanto las necesidades como las dificultades están de ambos lados.

Más adelante en este artículo revisaremos un enfoque estruc-turado y alineado al negocio, que busca encontrar y resolver problemas organizacionales para un proyecto EAI. Pero an-tes, conozcamos los diferentes tipos de integración.

Tipos de IntegraciónNo existe una forma única de integración adecuada a todas las situaciones, por el contrario, a lo largo de los años se han de-sarrollado diferentes formas de integración, adecuadas a dife-rentes necesidades. Si bien no hay una taxonomía estándar, los siguientes son tipos de integración generalmente aceptados:

1. Integración Orientada a la Información. Consiste en el pasaje de información de un sistema a otro. Casos típicos: el envío de transacciones comerciales, y las bases de datos inte-gradas (por ejemplo, bases de datos que reúnen los datos de todos los clientes de una compañía, en forma sincronizada con las demás aplicaciones que usan tales clientes).

Figura 1. Integración Orientada a la Información.

Típicamente, la integración orientada a la información no requie-re modificaciones en las aplicaciones integradas, sino solamente la implementación del mecanismo de pasaje de información entre los repositorios de datos de las aplicaciones respectivas; esto hace que sea la forma de integración más simple y de menor impacto.

Si bien la integración orientada a la información consiste en el pasaje de datos entre los repositorios de las aplicaciones, no necesariamente esto implica que tal integración se realice pura y exclusivamente usando tecnología de base de datos. También podría realizarse mediante archivos planos, APIs de las aplica-ciones, o incluso servicios de mensajería. La clave de este tipo de integración no está en el medio técnico, sino en el hecho de que lo que se integra es información y no procesos o servicios.

2. Integración Orientada a Procesos. Subiendo en el nivel de abstracción, nos encontramos con la integración orien-tada a los procesos de negocio. Esta integración consiste en la automatización de los diferentes pasos de un proceso de negocio a través de una o más aplicaciones. Si bien esto mu-chas veces implica intercambio de información entre aplica-ciones, esto es simplemente un medio para lograr el fin en cuestión. Además de información, en la integración orien-tada a procesos de negocio también se integra el control. Tí-picamente, este tipo de integración se lleva a cabo mediante un flujo de trabajo (workflow).

ESPECIAL

Figura 2. Integración Orientada a los Procesos de Negocio.

3. Integración Orientada a Servicios. Otro tipo de integra-ción, muy en boga en estos días, es la integración orientada a servicios. En este modelo, una aplicación expone una se-rie de servicios de negocio que pueden ser usados por otras aplicaciones. Se busca no solamente el reuso, sino también el hacer que cierta lógica de negocio sea implementada una única vez en la empresa, y reutilizada el resto de las veces.

Figura 3. Integración Orientada a los Servicios.

La orientación a servicios también permite la creación de las llamadas “aplicaciones compuestas”. Nuevas aplicaciones que surgen a partir de la unificación de diferentes servicios preexis-tentes en la organización. En el diagrama anterior, la Aplicación de Trading Web podría ser una aplicación compuesta, si toda su lógica partiera de invocación a servicios de otras aplicaciones.

La orientación a servicios y la orientación a procesos no son excluyentes, sino complementarias. De hecho, el caso ideal de la integración es aquel en el cual los procesos de negocio pueden ensamblarse a partir de la invocación ordenada y coordinada de diferentes servicios, que satisfacen las necesi-dades de los distintos subprocesos.

4. Integración Orientada a los Portales. Finalmente, algu-nos autores distinguen la integración orientada a los portales como un tipo separado. El aspecto distintivo de esta forma de integración es la agrupación de varios aplicaciones bajo una interfaz visual común, normalmente un portal web.

Figura 4. Integración Orientada a los Portales.

La integración mediante portales tampoco es necesariamen-te excluyente de los otros tipos de integración. De hecho, el portal puede alimentarse a través de servicios, y el mismo portal puede también soportar la participación de actores humanos en procesos de negocio.

Eligiendo un Tipo de IntegraciónNo existe una receta mágica acerca de qué tipo (o tipos) de integración se puede aplicar en cada situación. Sin embargo, los siguientes puntos pueden proveer una guía básica:

• Si la necesidad es centralizar el origen de un cierto tipo de dato (por ejemplo, centralizar una base de clientes), entonces en principio nos es suficiente con una integra-ción orientada a la información. En este caso es crucial revisarlo con todos los actores importantes (los represen-tantes de TI y negocio relacionados con las aplicaciones a integrar) y acordar universalmente el flujo resultante de la integración. Esto para evitar futuras integraciones inconsistentes con esta (por ejemplo, que si se acordó una base única de clientes, no surja de pronto una base alternativa de clientes).• Si la necesidad es centralizar cierta función de negocio (por ejemplo, el cálculo de precios de los productos de la compañía), entonces es conveniente pensar en térmi-nos de servicios. Una aplicación debe ser elegida como la oficial para realizar tal función (podrían ser varias, en caso de que se determine en qué casos se invoca a una y en qué casos a otra).• El caso de la integración orientada a procesos normal-mente está asociada a una decisión más estratégica. Si la necesidad va más allá de un dato o función, y tiene que ver con formalizar o automatizar procesos de negocio completos, ésta es la opción adecuada.• La integración orientada a portales generalmente es un caso más particular, y tiene que ver con la necesidad de faci-litar la llegada de la información a quiénes la deben utilizar. Por ejemplo, si un operador debe consultar cinco aplicacio-nes al comenzar el día, claramente pierde bastante tiempo al tener que abrir las cinco y navegar hasta los datos que necesita; un portal personalizado puede hacerle llegar todos esos datos en una única pantalla. El portal puede servirse de integraciones de información, servicios, e incluso facilitar la automatización del proceso de negocio. Por esto, la orienta-ción orientada a portales puede convivir perfectamente con los otros tipos de integración.


��

��

��

��

��

��

��

��

��

��

En cualquiera de los casos, es importante ver cómo juega el negocio en la decisión del tipo o tipos de integración a utilizar. En los primeros casos, más simples, veamos que rescatamos la necesidad de consensuar la integración con los actores. En el caso de los procesos, es claro que tales procesos deben ser definidos por el negocio, y soportados por la TI. En el caso de los portales, hablamos de que la integración está motivada por las necesida-des de información de un actor del negocio. Es fundamental, entonces, siempre tener en cuenta las necesidades de la organización antes de elegir productos que nos fuercen a un tipo de integra-ción que no es el que necesitamos.

Una Mapa de Ruta para la IntegraciónTras haber conocido la necesidad, las dificul-tades inherentes y las diferentes formas que puede tomar la integración, nos resta hilar esos componentes en un mapa de ruta que po-damos usar para guiar nuestros proyectos de EAI. Veamos una metodología que nos puede servir como checklist básico.

En primer lugar, reconozcamos una realidad de la empresa, y es que no todos los emprendi-mientos del día a día responden a planes estra-tégicos claramente orquestados. Es por eso que muchas necesidades de integración a las cuáles nos enfrentamos puedan no responder a una estrategia mayor, y aún así requerir llevarse a cabo para responder a necesidades bien reales. En cualquiera de los casos, un enfoque cuida-doso y estructurado nos ayudará a evitar que la respuesta a necesidades tácticas de hoy entor-pezca la integración estratégica que busquemos mañana. Por esto, dividimos nuestro mapa en dos “rutas”: una táctica y una estratégica.

La Ruta TácticaLa ruta táctica es aquella que seguiremos para responder a las necesidades de hoy, pero sin ir en detrimento de aquellas que podamos tener mañana. Recurrimos a ella cuando tenemos una necesidad a corto plazo que debemos suplir. Los pasos recomendados son los siguientes:1. Identificar la necesidad a cubrir. Determinar si debemos integrar información, funcionalidad y/o procesos. En el caso de tratarse de un proceso, de-berá ser un proceso sencillo y aislado; en caso con-trario, raramente podrá ser tratado a nivel táctico, y requerirá un enfoque estratégico. El caso de los portales raramente puede ser tratado a nivel tác-tico, a no ser que se trate de un prototipo inicial restringido a un grupo limitado de usuarios.2. Identificar el alcance e impacto organizacional.

Determinar las unidades organizacionales, pro-cesos, aplicaciones y usuarios afectados. Una necesidad táctica no debería ser, por lo general, muy abarcativa a nivel organizacional. En caso contrario, se recomienda nuevamente revalidar si el rumbo no debería ser la ruta estratégica.3. Identificar concesiones para hoy y acciones para mañana. Es posible que la naturaleza táctica de la solución requiera hacer algunas concesiones, como por ejemplo, realizar una integración que resulta en un acoplamiento no del todo deseable. En tal caso, es muy im-portante identificar tales concesiones y esta-blecer algunas reglas de juego para evitar que los riesgos subyacentes se potencien con el tiempo. Por ejemplo, acordar que un acopla-miento indeseable no será explotado más allá de este proyecto particular. Adicionalmente, pueden programarse acciones a futuro para remover tal acoplamiento.4. Definir el tipo de integración a utilizar. Una necesidad táctica normalmente podrá ser resuelta con una integración de informa-ción o servicios.5. Seleccionar tecnología de integración. Elegir la forma de implementar el tipo de integra-ción seleccionado. Si la necesidad es táctica, es conveniente que sea resuelta con alguna de las tecnologías ya probadas en la organización.6. Planear la integración. Como todo pro-yecto, una integración requiere cuidadosa planificación. En especial, debe realizarse un cuidadoso análisis de riesgos.7. Planear la transición. ¿Qué debe hacerse para que el negocio siga funcionando co-rrectamente tras implantarse la integración? Esto normalmente incluye comunicación y capacitación a usuarios de las aplicaciones afectadas, y eventualmente la baja de alguna función de alguna en las aplicaciones utiliza-das anteriormente. 8. Implementar la integración y la transición. Llevar a cabo la integración y la transición si-guiendo los planes establecidos.

La Ruta EstratégicaLa ruta estratégica es aquella abordada por la organización más allá de un proyecto particu-lar, y responde no sólo a necesidades de hoy, sino que adelanta las de mañana. Se utiliza cuando la necesidad está guiada por optimizar procesos de negocio en forma integral. Los pa-sos recomendados son los siguientes:1. Identificar la necesidad a cubrir. Un pro-yecto estratégico normalmente estará asocia-do a formalizar la manera en que uno o más procesos de negocio son soportados por las

aplicaciones, y optimizar la forma en que tales aplicaciones se relacionan para soportarlos.2. Identificar el alcance e impacto organizacio-nal. Determinar las unidades organizacionales, procesos, aplicaciones y usuarios afectados. 3. Identificar el mapa actual de procesos y aplica-ciones. Es muy probable que aunque se conozca qué procesos se desea automatizar, los detalles de los mismos no sean completamente conoci-dos, ni tampoco la forma en que se mapean a las aplicaciones. Es fundamental, antes de ini-ciar un enfoque de integración estratégico, do-cumentar los procesos afectados, las unidades a las que pertenecen, los roles que participan y las aplicaciones requeridas para llevarlos a cabo. De otra manera, no se tendrá el mapa actual requerido para trazar el mapa futuro. 4. Trazar el mapa futuro de procesos y aplica-ciones. Una vez detectado el mapa actual, de-terminar como el mismo se verá afectado tras la integración. Puntos clave a considerar son los procesos que sufrirán modificaciones, las aplicaciones que sufrirán modificaciones o se-rán retiradas, y cómo los diferentes roles de la organización deberán cambiar su forma de trabajar en un aspecto u otro.5. Establecer la ruta de transición a seguir. Un proyecto estratégico raramente se ejecuta de una sola vez, dado su alcance y magnitud. En cambio, el mapa futuro se alcanzará siguiendo una ruta consistente a través de varios proyec-tos que acercarán paulatinamente la situación actual a la futura. 6. Implementar la ruta de transición establecida. Siguiendo lo ya mencionado, la ruta se ejecuta a través de varios proyectos de índole táctica.

ConclusiónLa Integración de Aplicaciones Em-presariales es un tema de gran im-portancia. Sin embargo, muchas veces los conceptos centrales del EAI se pierden en la complejidad de la oferta tecnológica y las promesas de los proveedores. EAI es un concepto que debe entenderse desde las necesi-dades del negocio, la arquitectura de las aplicaciones, y el valor que estas últimas proveen al negocio... y no solamente desde la perspectiva pura-mente tecnológica.

En definitiva, ¡EAI es mucho más que un conjunto de productos de moda!


La integración mediante portales tampoco es excluyente de los otros tipos

de integración.

ENTREVISTA

24 www.softwareguru.com.mxJUL-AGO 2006 25www.softwareguru.com.mx JUL-AGO 2006

Gloria QuintanillaAcadémica, empresaria, consultora y pionera

Gloria Quintanilla es uno de los íconos de la calidad del soft-ware y mejora de procesos en México. Sin embargo, no podemos encasillarla solamente en ésta área. Su trayectoria es tan larga como diversa, y durante ella se ha desempeñado en México y el extranjero como programadora, investigadora, consultora, empresaria y académica.

Además de sus múltiples facetas, Gloria también es una pio-nera. Hace más de veinte años, ya se dedicaba a evangelizar sobre orientación a objetos. En 1993, cuando las fábricas de software eran algo desconocido en nuestro país, ella arran-caba una fábrica de software. Cinco años después, fue parte fundamental del equipo que llevó a Tecnosys a ser la primera empresa latinoamericana en certificarse en SW-CMM 3.

Actualmente, Gloria es Directora de Consultoría en Itera, y Presi-dente de la AMCIS, donde continua aplicando todo su conocimien-to y experiencia para contribuir al desarrollo de la industria.

¿Como empezó tu carrera en el software?Empecé a trabajar en informática cuando to-davía estaba en la universidad. Todavía me tocó programar en Cobol con tarjetas perfo-radas. Posteriormente hice una maestría en el extranjero, y al regresar me integré al IMAS (Instituto de Matemáticas Aplicadas y Siste-mas) de la UNAM, donde conocí a Hanna, que acababa de llegar de Polonia. Ahí empezamos a trabajar juntas en paradigmas de lenguajes de la programación.

¿Cómo llegaste al área de calidad?Me salí de la academia para poner una fábrica de software en Xalapa, lo cual funcionó bastan-te bien, hasta la crisis del 95. Entonces formé una empresa de consultoría en reingeniería de procesos, con la cual estuve algunos años. Sin embargo, después de un tiempo me agobió ser empresaria, y empecé a buscar trabajo. Mi experiencia fuerte era en OO, y pensé que me iban a contratar por eso. Sin embargo, lo que más le llamó la atención a las empresas de mi currículum era que entre mis hobbies había lis-tado “interés en calidad de software”. Y es que en ese entonces se estaba consolidando CMM a nivel internacional, y estaba llegando a Méxi-co como requisito para las grandes empresas como IBM, Telmex, EDS. Fue así que entré a Tecnosys, al área de calidad.

Cuéntanos sobre la AMCIS y lo que hace.La AMCIS surgió como un círculo de estudio para aprender sobre calidad en el software. Durante 10 años, operó en base a una sesión mensual, pero acabamos de tomar la decisión de ya no hacer estas reuniones. Los socios de la AMCIS, y la industria de software en Méxi-co, han evolucionado mucho desde que em-pezamos. La mayoría de los socios con cierta antigüedad ahora son directores de calidad o tienen su propia empresa de servicios. Por otro lado, las empresas ya no necesitan convencer-se de si necesitan calidad o no, sino que más bien quieren saber cómo hacerlo. Así que la AMCIS debe evolucionar para satisfacer estas necesidades. De hecho, parte de esto es la co-laboración que estamos teniendo con SG para apoyar la organización del congreso SG ’06.

¿Qué está pasando con MoProSoft?Estamos haciendo historia. Es la primera vez que en el ámbito de software se genera una norma mexicana, cuyo impulso de evolución no viene del ámbito internacional. Ahora nece-sitamos formar el grupo que lo evolucione.

Lo que es interesante es que la norma mexica-na nos ha rebasado en términos del impacto en la industria internacional y se está utilizando como base en otros países. Hay dos iniciativas,

la primera es el proyecto COMPETISOFT que dirige Hanna, donde se está utilizando MoPro-Soft como base para la mejora de procesos en las PyMEs en Iberoamérica. La otra inesperada es el reconocimiento internacional dentro de la ISO (ver “Tejiendo nuestra red, pag. 6).

¿En qué te basaste para diseñar la arquitec-tura de MoProSoft?El origen de MoProSoft en términos del con-cepto y marcos de referencia, viene del diseño conceptual que se hizo para el sistema de ca-lidad en Tecnosys. Cuando desarrollamos este sistema de calidad, teníamos el requisito por parte de IBM para certificarnos en ISO9000. Sin embargo, había un proyecto para hacer una fábrica de software orientada al merca-do americano, y ahí el requerimiento era SW CMM nivel 3. Por otro lado, para estos proyec-tos internacionales nos estaban pidiendo que nuestros administradores de proyectos fueran PMPs. Entonces tuvimos que entender estos marcos de referencia, combinarlos, y hacer el diseño de un sistema de calidad certificable al ISO9000, pero alineado al SW CMM, e incorpo-rando la practicas del PMI.

¿Cual es tu opinión sobre la industria de software en México?Me gusta y me sorprende la sinergia que se ha generado alrededor de los Clusters, la energía que se vive cuando estas dentro de las asocia-ciones o tienes contacto con ellas. Creo que eso es nuevo, y esta generando mayor fortale-za regional en la oferta, esta descentralizando la oferta, eso va a ser de un gran valor.

Desde la perspectiva de calidad, siento que ya pasamos el punto donde dejamos de evange-lizar sobre su importancia. Ya las empresas lo reconocen como una necesidad, y como algo que les da valor. Y por lo mismo, ya hay dis-posición a invertir. El problema que enfrentan ahora es ¿en qué debo invertir? ¿qué modelo usar? ¿cómo lo llevo a mi organización?

Tú que trabajaste en Irlanda, ¿qué crees que podemos aprenderles?Lo más importante de Irlanda es que se atrevió a transformarse de una nación rural a una de tecnología. Porque no solamente le entraron a TI, sino también a otros campos como la tec-nología médica. Fue una acción concertada, donde hubo inversión, no solo en aspectos técnicos, pero también aspectos comerciales.

¿Qué modelo debería aplicar México, el de In-dia (servicios), o el de Irlanda (aplicaciones)? Más que una dirección en particular, creo que hay que creer en la regionalizaron. Hay que creer en el mercado interno como el pri-

mer sustento de la industria mexicana. No podemos pensar que una empresa desde cero va a llegar a competir a los ámbitos in-ternacionales. Creo que hay un proceso de maduración y estamos todavía en él. Hay empresas que ya han llegado a un punto de madurez donde hace sentido una oferta hacia el exterior. Pero la mayor parte de la industria mexicana necesita ese proceso de maduración y de gestación. Yo creo que los clusters van a jugar un papel muy importan-te, y la política gubernamental también, en la maduración del mercado interno. Cuando volteas hacia fuera, hay mucho del mercado interno que no tenemos, y a nivel regional, son impresionantes los huecos.

¿Crees que la vinculación entre academia y empresas esté mejorando?Sé que hay esfuerzos para mejorar esto. Por ejemplo, se creó una asociación civil, donde hay inversión de la industria vinculada con la academia. Creo que el problema es que lo que se está haciendo no ha tenido la suficiente di-fusión. Además, los resultados en este punto no son inmediatamente visibles, sino que tar-dan varios años. Hay que tener paciencia.

¿Qué opinas sobre el nivel y habilidades de los profesionistas de software en México?La impresión general que tengo es que somos muy buenos técnicos, pero está el hueco en la formación en el ámbito de gestión. Visto des-de mi perspectiva, no hay suficiente énfasis en la parte de gestión de proyectos y procesos. Los muchachos salen de la universidad como buenos técnicos, y a los pocos años cambian su rol a ser administradores, y ahí tienen que empezar desde cero.

¿Por qué hay tantas mujeres en QA? Creo que se debe a que es un trabajo de mucho detalle. También influye que en las empresas mexicanas, la mayoría de los desa-rrolladores y líderes de proyecto son varones, así que es más fácil que acepten ver cosas de calidad con una mujer. En Irlanda también el grupo de QA eran mujeres, y los programa-dores eran hombres. Las mejores QA que he conocido son mujeres.

¿Algo que quieras compartir con los lectores?Yo creo que la AMCIS y SG como iniciativa juegan una labor fundamental, en la integra-ción de la comunidad, en la identificación de los jugadores y del conocimiento, en la di-fusión de las tendencias, y por eso es tanta afinidad. Más que una iniciativa de negocio, es el deseo de fortalecer el conocimiento y darle a la comunidad la capacidad de com-partir la experiencia.


Gloria QuintanillaAcadémica, empresaria, consultora y pionera

Las aplicaciones empresariales son más que una forma de automati-zar operaciones tales como finanzas, manufactura y recursos humanos dentro de un gran corporativo. Significan una ventaja competitiva para las compañías que optan por su implantación. Sin embargo, se requiere de una visión sistemática para manejar el desempeño combinado de los recursos que brindan los distintos usos del software empresarial, lo que asegura a los profesionales de la TI una óptima integración de servicios, mismos que aseguran un control total sobre la información generada por la empresa. Recursos, empleados, clientes, planes de negocios, abasteci-mientos, ventas, distribución, inventario, comunicación interna, son sólo algunos de los rubros que se pueden mejorar mediante una infraestructu-ra de aplicaciones empresariales.

A continuación presentamos cuatro artículos relacionados con aplicaciones empresariales. Comenzamos hablando sobre su evolución, posteriormente abordamos puntos a considerar al adquirir un ERP, después estudiamos fac-tores clave para una implantación exitosa, y por último revisamos el caso de estudio de una implantación de un sistema de gestión de Recursos Humanos.

Aplicaciones EmpresarialesLas aplicaciones detrás de tus procesos

EN PORTADA: INTRODUCCIÓN


La inteligencia en la cadena de abastecimientoPor Adrián F. Ruffinatti

Durante muchos años, una amplia variedad de aplicaciones empaquetadas de alcance empresarial, desde los Enterprise Resource Planning (ERP) y los sistemas de Manufacturing Resource Planning (MRP), han estado disponibles para la automatización y administración de los procesos de nego-cio en corporaciones que estaban fuertemente involucradas en la industria o en alguna cadena de valor de esas características. En particular, los módulos de aplicaciones “devotos” a las manufactu-ras, y las relaciones con los proveedores en los paquetes ERP, primariamente Baan, Oracle y SAP, consiguieron una amplia adopción de sus productos en las industrias manufactureras. También en esta categoría, algunas corporaciones han administrado los contactos con los proveedores y dis-tribuidores, utilizando aplicaciones empaquetadas para la administración de las relaciones con los clientes (Customer Relationship Management, CRM), aunque dichas aplicaciones no habían sido originalmente diseñadas con ese propósito.


En años recientes, surgió una nueva categoría de software empresarial que se enfoca específicamente en la adminis-

tración de la cadena de abastecimiento (Supply Chain Managemen o SCM). Las aplicaciones SCM complementan los sistemas ERP y CRM, proporcionando una funcionalidad basada en transacciones empaquetadas para la administración de materiales, planificación de la demanda y servicios de planificación de la producción.

Las aplicaciones ERP y SCM han logrado un punto de madurez donde sus características son bastante ricas, además de que son ro-bustas en general, y bien comprendidas en términos de las mejores prácticas. Aún así, muchas de ellas están desprovistas de capacidades analíticas (con la excepción de unos pocos reportes), que puedan darle a los especialistas y gerentes la información de los procesos de manufactura y de la cadena de valor que requieren. Las aplicaciones analíticas empaquetadas para la inteligencia de la cadena de abaste-cimiento, conforman una nueva categoría de software empresarial denominado Supply Chain Intelligence (SCI), que promete proveer información de aspectos estratégicos para las corporaciones.

Las aplicaciones SCI, permiten la toma de decisiones, a través de la recolección de información detallada de diversas etapas del ciclo de vida del producto. También proveen la inteligencia de negocios, el elemento de business intelligence del cual carecían los sistemas ERP y CRM.

Las aplicaciones analíticas SCI, recolectan información amplia y detallada de toda la cadena de valor. SCI toma una vista de am-plia perspectiva sobre toda la cadena de valor, utilizando datos de nivel atómico, que son requisitos para comprender el costo total y las ramificaciones en cuanto a calidad a largo plazo se refiere.

Podemos decir que Supply Chain Intelligence es el complemen-to de Supply Chain Management. Las aplicaciones empaquetadas para SCM se enfocan largamente en administrar las relaciones de adquisiciones y producción en la cadena de valor. Las aplicacio-nes SCI, en cambio, proveen una vista general de la cadena de valor entera que revela el ciclo de vida de un componente o de un producto. Requerimientos de Software para la Inteligencia de la Cadena de Abastecimiento Un software SCI debe cumplir ciertos requisitos básicos:Aplicación analítica empaquetada.- Las funcionalidades descritas para un SCI deben estar integradas dentro de un entorno único de un paquete de software de aplicación analítica.

Adrián F. Ruffinatti vive en Córdoba, Argentina. Es Ingeniero en Sistemas de Información por la Universidad Tecnológica Nacional (UTN). Trabaja como Consultor en Sistemas y su experiencia incluye diferentes empresas: Harriague y Asociados, Vitopel, Klöckner Pentaplast y Núcleo Eléctrica Argentina - Central Nuclear Embalse. Además, es Profesor Ayudante en la UTN en las cátedras de Gerenciamiento Estratégico de los SI/TI (Ingeniería en Sistemas) y Programación I (Tecni-catura en Programación). Ruffinatti puede ser contactado en: [email protected]

EN PORTADA: LA EVOLUCIÓN EN EL SOFTWARE EMPRESARIAL

Supply Chain Management (SCM) Supply Chain Intelligence (SCI)

Administración de las relaciones de Provee una vista general de la cadena compras y producción en puntos de la de valor en su conjunto, revelandocadena de valor. ciclos de vida de los productos.

Transaccional. Analítico.

Decisiones tácticas. Toma de decisiones estratégicas.

Ayuda a reducir costos a través de una Revela oportunidades para reduccioneseficiencia operacional mejorada. de costos, pero también simula crecimiento en los ingresos.

Generalmente sólo tiene datos de la Integra datos del producto, de lapropia aplicación. industria y de los proveedores.

Registra un estado de los datos, Conserva un registro histórico.representando el “ahora”.

Asiste en la planificación de materiales Predicciones del tipo What Ify de la producción. (qué pasa si...) basadas en los datos históricos.

Cuantifica el costo de algunos materiales. Habilita la comprensión del costo total.

Simples consultas. Entorno colaborativo, con un monitoreo personalizado de las métricas.

Servicios profesionales.- Cada empresa tiene una irrepetible y única colección de entidades de negocios, así que el modelo de datos que representa la aplicación analítica debe ser personalizado para cada or-ganización, y en ese lugar, entran en juego los profesionales.

Tabla 1. Comparativo entre SCM y SCI


ConclusionesEn definitiva, la inteligencia de la cadena de abastecimiento le permite a las organizaciones reducir costos, mejorar la calidad de sus productos, tener una vista global de dicha cadena y otros factores secundarios, que logran como consecuencia, establecer una fuente de ventaja competitiva, además de un crecimiento significativo en el desempeño de la empresa.

Dentro del proceso de crecimiento normal de cualquier empresa, se llega a un punto donde es obligada la decisión por mejorar sus procesos informáticos con el fin de optimizar la gestión y confiabilidad de la información, así como controlar y mantener el crecimien-to del negocio. Se trate de un rediseño en el sistema actual, o la incorporación de una nueva tecnología.

A continuación, podrán encontrar algunos pa-sos generales y tips a detalle, para poder tomar una correcta decisión respecto a qué sistema de información o ERP adquirir. ¿De dónde viene la idea? ¿Por qué la empresa quiere im-plantar un sistema tipo ERP? Generalmente sucede por algunas de las siguientes razones:

¿Por qué un sistema nuevo? Generalmente se debe a cambios en la admi-nistración de negocios. Es decir, reingeniería, benchmarking, calidad total, outsourcing, cambios tecnológicos, pero, sobre todo, dudas respecto a la calidad de los sistemas de infor-mación actuales de la empresa.

La empresa se plantea preguntas como: • ¿Son confiables los datos generados por los sistemas, o se requieren conciliaciones, revisiones y ajustes para que los números parezcan aceptables? • ¿La compañía evalúa su situación finan-ciera con la información que dan los siste-mas, o se basa en hojas de cálculo donde se vacían los reportes del sistema? • ¿Están las funciones del negocio integra-das por el sistema, o se requiere personal para que mantengan consistente el flujo de información? • ¿Es el número de personas en actividades de soporte comparable al de otras empre-sas de tamaño similar? • ¿Son satisfactorios los tiempos de res-puesta para los clientes?

Cuando una organización responde “no” a alguna, o todas las preguntas anteriores, es momento de replantear el sistema de infor-mación. Lo que no necesariamente significa reemplazar el sistema actual, ya que tal vez con cambios ligeros en la aplicación, y ciertos cam-

bios en los procesos de negocio de la empresa, sería suficiente para corregir la situación.

Una vez comprendida la necesidad de migrar a un sistema de información integral, la segunda pregunta obvia es: ¿por qué no un desarrollo in-terno? El desarrollo de una aplicación a la medida permite tener una aplicación que funciona exacta-mente como lo requiere la empresa. Sin embargo, también trae consigo varias desventajas:

• Para desarrollar sistemas que realmente mejoren la competitividad de la empresa en su mercado, se requeriría personal con múltiples habilidades y conocimientos en muchas áreas.• Necesitan dominar: MRP, MRP II, ERP, Supply Chain, mantenimiento, logística, ABC, simulación de procesos, finanzas, S.I. Ejecutivos, además del conocimiento de de-sarrollo de aplicaciones.• Desarrollar Sistemas Integrados, no es el negocio central de la empresa, ni en lo que tiene experiencia.• Se corre el riesgo de sistematizar errores en toda la empresa.

La Decisión de Adquirir un ERP Por Enrique Duhne Ayala

No es ningún secreto que toda organización exitosa cuente, entre sus muchas características, con información confiable que le permita tomar decisiones oportunas y a tiempo, lo cual le facilita mantenerse por arriba de su competencia. Es en este tipo de empresas donde la tecnología juega un papel muy importante, no para mantenerse al ritmo de un mundo cada vez más “tecnológico”, sino para contar con la información que necesitan, cuando la necesitan.

Destreza en el dominio.- La proposición de valor primario de cual-quier aplicación analítica para SCI, es la destreza en el dominio que encapsula. Cualquier persona que evalúe un producto de SCI debe considerar en primer término este punto.

Diseñar versus Comprar.- Para la clásica decisión, siempre deben considerarse las ventajas y desventajas de una y otra opción. Reduc-ción del tiempo de implementación y beneficios de costos (en com-prar) versus beneficios derivados por la personalización del software a los requerimientos de la empresa (en diseñar). Por lo tanto, debe buscarse cuál es el factor que más influye.


Las ventajas que se tienen con un desa-rrollo interno, se pueden lograr si se elije

una solución ERP flexible, que permita “ordenar” la empresa por medio de mejores prácticas, pero que sea lo suficientemente flexible, para que aque-llos procesos de negocio que vuelven competitiva a la organización, se puedan incluir en la solución. Sin duda alguna, estas pequeñas diferencias son las que vuelven única a cada organización, y es de suma importancia que se puedan integrar al ERP.

El Rol del Área de SistemasLas funciones típicas de un departamento de sis-temas de una empresa con ERP son:• Mantenimiento y soporte.• Extensiones para crecerlo junto con la empresa. • De programadores, se convierten en analistas.• Alinean a la empresa con la tecnología.• Se mantienen a la vanguardia para que la empre-sa crezca junto con el ERP y la tecnología.

Como en todo proyecto nuevo, existe un cier-to rechazo “normal” a este tipo de soluciones. Es importante tener dos puntos claros para poder combatirlo:• Compromiso de la alta dirección.• Recalcar que los problemas de los sistemas ac-tuales, como duplicación del trabajo, informa-ción poco accesible, necesidad de conciliaciones, trabajo extra para los cierres, dependencia perso-nal de TI; serán superados con el nuevo sistema. Cuando un usuario o analista de la información logra ver de forma clara el beneficio que el siste-ma le brindará en su trabajo diario, es entonces cuando éste adquiere sentido.

Una vez que se cuenta con el apoyo de la direc-ción, empieza el proceso de selección, para lo cual es importante decidir si trabajarán solos o con consultores. Las ventajas de usar consultores son: uso de una metodología probada, experien-cia, y dedicación completa. Sin embargo, una gran parte de las implantaciones de un ERP, se logran con tan sólo el apoyo y compromiso de la dirección, el departamento de sistemas de la empresa y del proveedor, que por lo general tam-bién respalda el proceso de implantación.

El proceso para elegir el paquete más apro-piado, depende en gran parte de la empresa. No existe un sistema perfecto, pero tampoco existen los “sistemas malos”, mas bien existen sistemas o ERP para empresas. Es importan-te definir, antes de iniciar el proceso de se-lección, las características básicas con las que debe contar el ERP, para de ahí partir con una base sólida.

La ventaja común de cualquier ERP es la integra-ción. La información se registra en línea desde la fuente, se eliminan controles y redundancia, la información está disponible de inmediato. La empresa necesita desarrollar criterios de evalua-ción para poder elegir. Es importante definir estos criterios preliminares, como son:

• Base instalada.• Recursos máximos disponibles para invertir.• Soporte local probado.• Funciones indispensables: EDI, proyec-tos, e-commerce, etc.• Herramientas de personalización.

Es fundamental que para cualquier proyecto ERP se tenga claro quiénes serán los “jugado-res” del proyecto, así como sus roles. Dentro de un proyecto ERP existen al menos dos juga-dores: el proveedor del SW, y la Empresa. Por lo tanto es necesario tenerlos bien identificados dentro del proyecto de implantación.

El Rol del Proveedor del Software• Debe entregar el software y su documenta-ción lo antes posible.• Ajustar los parámetros del paquete para optimi-zar su desempeño en la plataforma del cliente.• Entrenamiento inicial (train the trainer). • Brindar soporte y aseguramiento de calidad sobre la implementación.• Debe comprometerse a seguir dando sopor-te en el futuro, a pesar de la magnitud de las modificaciones y de quién las haga.

El Rol de la Empresa• Debe participar y contribuir activamente, no sólo exigir resultados.

• Los responsables deben desarrollar un cono-cimiento profundo del producto.• Conseguir la participación de los que deben involucrarse.• Organizar las tareas de conversión de datos y desarrollo de interfases.

La conversión consiste prácticamente en ac-tualizar catálogos y archivos maestros a través de programas que leen los registros y los re-escriben en el nuevo formato.• Puede requerirse captura de datos.• La conversión debe iniciarse tan pronto como sea posible.

Por último, para cualquier proyecto así, es de suma importancia la revisión y evaluación cons-tante. Es muy común que durante el proceso de implantación de cualquier ERP se tengan que tomar decisiones que podrían cambiar el rumbo de una implantación, por lo tanto, se recomien-da tener juntas mensuales o quincenales para revisar avances, logros y retrasos. Los objetivos principales de estas reuniones, además de los que ya mencionamos, serían:

1. Mantener informado al comité sobre el estatus del proyecto.2. Tomar medidas correctivas y solicitar en su caso, la intervención de los directivos.3. Mantener el compromiso de la empresa con el proyecto y sus objetivos.

Se debe considerar que la tecnología está en un constante cambio; apoyarnos en el creci-miento, conocimiento y desarrollo realizado por un tercero, para después incorporarlo, significa un gran beneficio para cualquier empresa. Sin embargo, es muy importante que el sistema de información acceda un ni-vel de flexibilidad que permita a la empresa incorporar esos procesos de negocios, que la vuelven única.

Sin lugar a dudas, la tecnología por sí sola, no vuelve competitiva a la organización, sino su co-rrecta implantación apoyada con procesos de ne-gocios únicos.

EN PORTADA: LA DECISIÓN DE ADQUIRIR UN ERP

Enrique Duhne Ayala es el Director de Operaciones de KEPLER MATRIZ. Así mismo es miembro fundador de InteQSOFT, Cluster de TIC del estado de Querétaro. KEPLER es un ERP 100% mexicano con más de 30 años de experiencia en el mercado de México y América Latina.


10 Factores Clave en la Implantación de ERPPor Luis Antonio Rangel

Estás por iniciar, sino es que ya lo hiciste, un proyecto para implementar un sistema ERP que normalice tus procesos clave y/o admi-nistrativos. Ya fuiste asediado e invadido por multitud de consultores, quienes te vendieron la idea de que esta tecnología es la solución a tus problemas y que mejorará tus indicadores de desempeño. Les planteaste inquietudes y, a oídas de diferentes historias de terror, te aseguraron que cuentan con la mejor metodología y el mejor personal, comentando que los fracasos les suceden a “otros”, aquellos que no tienen la experiencia ni las competencias (lógicamente, tus competidores).

Lamentablemente, el éxito depende de algo más que la confianza que te hayan infundido y que le puedas otorgar a un consultor. Más bien estriba en la gestión de diversas variables que forman una compleja ecuación, que es mejor tener el gusto de conocerla, antes de vivir con ella diariamente.

Si bien existen multitud de factores que inci-den en la marcha y resultados de estos proyec-tos, me concentraré en 10 que considero más importantes, pues aportan 80%, o más, del impacto positivo o negativo. La decisión: ¿de qué lado se carga la balanza?, puede estar en nuestras manos si actuamos pertinentemente.

1. El primer punto de capital relevancia, del que se deriva todo, es la propia justificación del pro-yecto. Salvo que sea por mandato corporativo o requisito de tus clientes o industria, la implemen-tación de un ERP debe obedecer invariablemente al plan estratégico, analizándose como proyecto de inversión; esto nos obliga a perfilar claramente los beneficios en términos de objetivos e indica-dores de nuestro negocio, evaluándolos contra el costo de implementación.

Estarán implicados varios miles de dólares, por lo que nunca debe iniciarse sin antes entender claramente cómo contribuirá a tu estrategia y cuánto aportará a tu estado de resultados, me-diante un Caso de Negocio (Business Case). Implementaciones que no cumplen esta con-dición, son una aventura, no un proyecto, con-virtiéndose en un barco a la deriva que puede llevarte al puerto de pérdidas financieras; esto, sin contar los dolores de cabeza que te ocasio-nará. Alinea y justifica muy bien el proyecto a tu estrategia de negocios.

2. Otro aspecto fundamental es la visión con la que concibes el proyecto: corto o lar-go plazo; pareciera obvio que los proyectos deberían planearse, para poder entregar be-neficios durante el tiempo más largo posible; pero no es la constante, ya que la visión im-perante en nuestro país, por nuestro modelo económico, es “cortoplacista”, buscando en-tregar beneficios económicos lo antes posible; y si se puede todos al mismo tiempo, mejor.

Debemos saber, que implementar un ERP es un gasto de capital. Como todo activo, su re-torno de inversión toma tiempo, generalmente de 12 a 24 meses para los primeros resultados tangibles. Lo importante es que una vez que se presentan, sean sustentables, cosa que se lo-gra siendo disciplinado en la implementación y aprovechamiento continuos de las prácticas de negocio ofrecidas por el ERP. No inicies una implementación esperando que arroje ganan-cias inmediatas, pues puede estresar a tu orga-nización, poniendo en riesgo la propia llegada de los beneficios.

Planifica tu proyecto a largo plazo, proponien-do flujos de retornos en conformidad con un Caso de Negocios, donde la mejora gradual, pero continua, sea la directriz. Distribuye los beneficios a lo largo del tiempo, y por ende, los esfuerzos y la complejidad.

3. El tercer factor crítico que propongo se relaciona directamente con el ERP, en concreto, con su oferta tecnológica. Exis-ten múltiples opciones en el mercado, cada una pregona ser la mejor; pero elegir no es trivial. Es importante contar con informa-ción detallada de cada sistema que permita dimensionar su alcance funcional, oferta de servicios, tiempos de implementación, costos y perspectivas de crecimiento, pues estos cinco criterios son fundamentales para respaldar una buena selección.

A menos que tengas que implementar un determinado ERP por estrategia corporati-va o compatibilidad con socios de negocios, nunca elijas el sistema sin haber hecho un análisis comparativo de, al menos, tres a cinco opciones; y mucho menos cuando ni siquiera sabes exactamente para qué lo quie-res, es decir, qué procesos y requerimientos deseas sistematizar con él.

www.softwareguru.com.mx

Diseña un instrumento formal de eva-luación cuantitativa y cualitativa que,

en función al peso que le otorgues a cada cri-terio, determine cuál es la mejor opción, en función a tus necesidades y las de nadie más. De ser factible, contrata un asesor especializado para realizarlo con objetividad e imparcialidad, cuidando que no esté vinculado a ningún fabri-cante o consultor de los ERP que manejas como opciones. Toma la decisión en función a los re-sultados del instrumento, nunca con base en lo que quisieras que sucediera, en la preferencia de tu Director General ni en tu intuición.

4. Superadas estas tres primeras disyuntivas, que tienen que ver más con la estructura y pre-paración del propio proyecto; el cuarto punto aborda la definición del liderazgo y la respon-sabilidad del proyecto. Lógicamente, si has ob-servado el primer aspecto y tu iniciativa se ha considerado estratégica, la asignación resulta lógica: el líder del proyecto será una persona de alto nivel directamente involucrada con los procesos de negocio abarcados por el ERP.

Esto rompe abruptamente el paradigma donde generalmente la responsabilidad se le asigna al Gerente de Sistemas, bajo el argumento de que el proyecto es tecnológico. Nada más erróneo, pues ni el proyecto es informático ni la perso-na es especialista en las prácticas del negocio, además, no tiene la autoridad para poder tomar decisiones en este tenor; ciertamente, suelen ar-marse equipos multidisciplinarios donde sí parti-cipa gente de la operación; sin embargo, si deseas realmente que el flujo de decisión y acción sea ágil y efectivo durante todo el proyecto, lo más conveniente es que tu líder tenga el suficiente tramo de control para poder mover los intrinca-dos hilos de la organización, que en ocasiones se traman y obstaculizan la buena marcha.

Designa como líder a uno de tus Directores o Gerentes de las áreas de negocio, otorgándole ofi-cialmente las facultades y autoridad para tener el

control completo del proyecto y de las personas que participen en él. Confiérele la responsabilidad de dirigir el barco hacia el destino planeado, opti-mizando los recursos disponibles.

5. Relacionado con el anterior, el quinto factor versa sobre la composición del equipo de traba-jo. Asignar el liderazgo a las áreas del negocio, es sólo el primer paso. Es importante contar con un equipo cuyos recursos humanos puedan aportar cuatro grandes campos de conocimien-tos (todos indispensables): entendimiento de los procesos del negocio, comprensión del entorno tecnológico propio de la empresa, conocimiento de la cultura y estructura de su organización, y dominio de la funcionalidad del ERP.

Los dos primeros, se resuelven conformando un equipo con gente bajo la responsabilidad del líder designado, que conozca los flujos y requerimientos de la operación, así como con personal del área de sistemas (el tercero lo tra-taré con detalle en el punto nueve. Está re-lacionado con el involucramiento del área de Recursos Humanos). El cuarto punto, gene-ralmente se cubre contratando a un consultor, por lo que es importante que te asocies con uno que no sólo maneje perfil tecnológico, sino que conozca su industria y sus procesos desde la perspectiva de negocios. Por lo re-gular los consultores eminentemente tecno-lógicos, intentarán hacer que tus procesos se adecuen a las prácticas por defecto del ERP, mientras que un consultor de negocio, puede capitalizar más las capacidades y mejores prác-ticas para ofrecerte esquemas más flexibles.

Integra un equipo de trabajo multidiscipli-nario que cubra los cuatro campos de cono-cimientos, siempre buscando un adecuado balance entre los perfiles de negocio, tecno-lógico y humano. Asóciate con empresas con-sultoras competentes, con experiencia probada en estos frentes, que puedan entregarte más soluciones y menos problemas.

6. El enfoque de implementación es el sexto rubro: decidir si se adoptarán las prácticas sugeridas por el sistema, o bien, se realizarán adecuaciones que pueden implicar desarro-llos, conocidos como add-ons. Esto depende directamente del grado de cobertura que te ofrezca el ERP que seleccionaste y de las par-ticularidades de tus transacciones de negocios; sin embargo, la determinación del enfoque va más allá, pues aun cuando lo ideal pudiera resultar arropar el ERP con desarrollos, esto agrega complejidad y costo, que puedes no es-tar dispuesto a manejar.

Desarrolla entonces sólo lo que sea indispen-sable, pues si no lo hicieras, pones en riesgo la operación o sus ventajas competitivas; cual-quier otro requerimiento, evalúalo en térmi-nos del cambio de alcance en tu proyecto. Busca balance entre lo que te ofrece el ERP y lo que necesitas. Hay que estar consciente de que en estos proyectos es normal, e inclusive mejor, alinear el proceso antes que cambiar el sistema. Respáldate en el personal de tu área de sistemas para tomar las mejores decisiones.

7. El siguiente punto es un parte aguas en la concepción y dinámica del proyecto, por lo que hago énfasis en este séptimo factor, ya que mul-tiplica o minimiza las posibilidades de generar beneficios, según cómo sea aplicado: enfoque a procesos. Cuando se implementa un ERP, no se está desarrollando un sistema aislado que puede concentrarse en los requerimientos de una sola área e independizarse del resto; toca naturalmente todas las áreas del negocio, por tanto, es muy importante que su arquitectura responda a flujos horizontales, abarcando las diferentes áreas que participan en cada proceso, promoviendo un ambiente integral.

Asimismo, considera que hay que aprovechar el esfuerzo de análisis de procesos, para identi-ficar mejoras y oportunidades de integración, ya sea propias de la operación o habilitadas por

EN PORTADA: 10 FACTORES CLAVE LA IMPLANTACIÓN DE ERP

El Ing. Luis Antonio Rangel es Gerente del Centro de Competencias en CoSphere Consulting Group, firma líder en la implementación de modelos de adminis-tración del desempeño estratégico basados en Balanced Scorecard. Es asesor y especialista en las áreas de tecnología de información, administración de proyectos, reingeniería de procesos y planeación estratégica. Se ha desempeñado como consultor en las firmas Mancera Ernst & Young y CoSphere Consulting Group, donde desarrolló diversos proyectos planeación, mejora de procesos e implementación de ERP, para empresas como Grupo Nacional Provincial, Effem México (Grupo Mars), Grupo Proa (Laboratorio Médico del Chopo), entre otros. El Ing. Rangel ha impartido seminarios, cursos y conferencias en Administración de Proyectos, Ingeniería de Software y Análisis de Procesos para la Universidad de Guanajuato, el Instituto Tecnológico de Sonora y el ITESM Campus Querétaro.


el ERP, pues es una oportunidad natural para poder implementar todos aquellos cambios que no has podido o no te has atrevido a adoptar. Nunca busques mantener intactos tus procesos, pues estarás desperdiciando mucho del potencial de estos proyecto, como soluciones de mejora. Asume la actitud de cambiar y capitaliza mejores prácticas, en pro de conseguir los beneficios que hayas estimado en tu Caso de Negocios.

Los últimos tres puntos tienen que ver con capas de gestión que permiten apuntalar la solución que se esté desarrollando. Considé-ralos como rieles que mantendrán el tren con rumbo y estabilidad, brindándote la oportu-nidad de maximizar probabilidades de éxito, así como minimizar riesgos y eventualidades.

8. La necesidad de administrar el proyecto es innegable y es nuestro punto ocho. Sin em-bargo, no nos referimos a la supervisión de actividades, como muchas veces se hace, ni al seguimiento de un plan de trabajo para repor-tar avances a la Dirección. Las organizaciones generalmente asignan esta responsabilidad al líder, en el entendido que llevará a cabo las ta-reas necesarias para poder mantener el control, pero nunca dando a conocer las expectativas al respecto.

La administración de proyectos implica llevar toda una metodología, de la que existen ya, estándares establecidos por el Project Manage-ment Institute, que propone la gestión de rubros fundamentales de toda estructura de proyecto, como son: alcance, tiempos, costos y recursos, así como eventualidades tales como asuntos o issues, riesgos y cambios al proyecto.

Por lo regular, si no se establecen mecanismos concretos de administración que se difunden a todos, es difícil mantener la fotografía com-pleta del proyecto, obstaculizando la toma de decisiones. Es como dejar el barco sin capitán ni timón, a merced de las tempestades que puedan ocurrir en el trayecto.

Administra tu proyecto formalmente, bajo métodos y procedimientos establecidos, que formen un hábito en la organización. Apóyate en todo tu equipo de trabajo para mantener el control del proyecto. En caso necesario, con-

trata un Gerente de Proyecto especializado en la metodología y en proyectos de TI.

9. El noveno punto tiene que ver con un as-pecto vital, que muchas veces es subestimado o ignorado: el papel de los recursos humanos; no sólo como un participante con la respon-sabilidad de realizar determinadas actividades, sino como actor protagónico al momento de operar la solución que entregará el ERP.

La administración del cambio organizacional, es un enfoque que plantea colocar en el centro del proyecto a tu gente, pues al final, será ella un factor determinante para el éxito, convirtiéndose en motor u obstáculo para la adopción de nue-vos procesos, competencias y sistema. Muchas empresas reducen este trabajo a la realización de actividades de capacitación y comunicación, con frecuencia, poco consistentes, y reduciéndose sólo a la parte del cambio tecnológico.

La administración del cambio tiene su propia metodología, la cual involucra gestionar todos los aspectos que inciden en el desempeño del personal, ya que afectan las condiciones de tra-bajo durante y después del proyecto. Define una estrategia integral y un plan de acción que te permita cubrir todas las aristas del aspecto hu-mano, en términos de estructura organizacional, competencias, comunicación, liderazgo, sentido de logro, incentivos, motivación, entre otros.

Incorpora al Gerente de Recursos Humanos, otorgándole un rol fundamental: ser el res-ponsable de diseñar el modelo, bajo el cual, el personal adopte el cambio y se adapte a él, con todo lo que conlleva. Apóyalo con todos los re-cursos disponibles, inclusive consultores exter-nos, pues es un seguro de vida para tu proyecto, que cubre un riesgo muy alto y cuyos siniestros pudieran ser de impacto considerable. Toma en cuenta que tu gente debe ser, y mantener-se siempre como el mejor aliado. Asegura esta condición trabajando decidida e inteligente-mente sobre el factor humano.

10. Para finalizar, nuestro décimo factor alude al ambiente del proyecto; si bien éste ya fue abor-dado durante la alineación estratégica, ahora nos referimos en específico al entorno tecno-lógico; que debe ser considerado, por obvias

razones, al incorporar un

nuevo componente tecnológico a tu plataforma, porque puede alterar sustancialmente las premisas del plan estratégico de desarrollo tecnológico.

Como ya sugerimos, al adoptar una solución ERP, establecemos un matrimonio de largo plazo, que como todo compromiso de este tipo, reestructura completamente las condi-ciones de vida; pero no te inquietes, se tra-ta, específicamente, de la arquitectura de TI. Principalmente en el caso de que existan otros sistemas o desarrollos propios, el personal de sistemas suele ver al ERP como un cuerpo ex-traño, amorfo, inclusive una amenaza.

Es importante, por tanto, dejar en claro qué alcance tendrá el ERP en el largo plazo, para poder determinar estrategias de incorporación y sustitución gradual, así como de integración tecnológica en el caso de que supervivan apli-caciones que deban convivir con el ERP.

Desarrolla con el Gerente de Sistemas una es-trategia de evolución tecnológica, comunicán-dola claramente para manejar las expectativas de todos los impactados, preparando el ambiente para los cambios. Adecua en consecuencia, el plan estratégico de tecnología de información.

No pretendo establecer un decálogo de princi-pios que deba ser observado de forma religiosa y dogmática durante cualquier implementa-ción de ERP. Mucho menos, aseguro, que si se cumplen, se alcanzará el paraíso en la orga-nización al final del proyecto, pues menores pecados, también pueden ser representativos.

Simplemente te comparto 10 recomendaciones básicas para evitar incurrir en faltas mayores. Considerarlas puede apoyarte fuertemente para mantener el buen rumbo y sortear las dificulta-des más comunes y de mayor impacto. En todo caso, tú eres el principal arquitecto de la mejor estrategia. Diséñala apropiadamente a la reali-dad y cultura de la organización, atendiendo adecuadamente los principales factores de inci-dencia. Te deseo el mayor éxito en tu proyecto.


En esta ocasión, presentamos el caso de la línea aérea Transportes Aéreos del Continente Ame-ricano (TACA), y la solución de TI que está implantando para administración de RH.

AntecedentesTACA cuenta con alrededor de 7,000 em-pleados dispersos en los 19 países donde tiene presencia, desde Canadá hasta Argentina. An-teriormente, la información de los empleados estaba dispersa, muchos de los expedientes se archivaban aún en papel, y los trámites eran lentos y complicados. Esto evitaba que hu-biera un vínculo de comunicación sólido y efectivo entre los empleados y los procesos de negocio, que al hablar de una línea aérea y un centro de mantenimiento aeronáutico, deben cumplir con una serie de normas internacio-nales muy estrictas.

Por esta razón, esta organización consideró la implementación de un Centro de Servi-cios Compartidos para la efectiva y oportuna administración de su personal. Los objetivos fueron: brindar un alto nivel de servicio a un menor costo; buscar economías de escala a través de la estandarización de algunas activi-dades, y especialización de otras; brindar ser-vicios eficientes sustentados en la tecnología y con un nuevo enfoque de autoservicio para así crear estructuras flexibles para apoyar la evolución y crecimiento del negocio; generar sinergia entre las diferentes áreas del negocio; y lograr un mayor acercamiento con el perso-nal, sus expectativas y necesidades.

Evaluación de AlternativasAl definir la estrategia de solución, se plan-tearon las opciones de actualizar los sistemas existentes, adquirir un software que resolviera los servicios estratégicos de RH y subcontra-tar únicamente los servicios RH de carácter

operativo (ej. Nóminas) con una empresa global, o implantar una nueva plataforma tecnológica para la gestión global del capital humano e intelectual. Se decidió ir por esta última opción, ya que es donde se podían lo-grar los mayores beneficios.

Para escoger dicha solución tecnológica, TACA elaboró un RFP (Request for Propo-sal) para determinar el alcance básico de la funcionalidad esperada, y que resolviera 80% de sus necesidades (sabiendo que di-fícilmente encontrarían una solución “out of the box” que resolviera sus necesidades al 100%), y se encontraron 10 proveedores a lo largo y ancho de América que ofre-cían soluciones que cumplían un porcen-taje razonable del RFP. De éstos, se generó un “short list” con tres proveedores, y con cada uno se realizó una prueba de concep-to sobre las funcionalidades centrales es-peradas, además de visitar clientes de cada

EN PORTADA: CASO DE ESTUDIO

Marco Antonio Cruz es Director de Servicios en Meta4 México. Tiene diez años de experiencia en la industria de TI. Cursó la carrera de Ciencias de la Informática en el IPN y ha implementado sistemas de nómina y RH en distintas organizaciones como: Grupo Industrial Saltillo, Grupo Bimbo, Price Waterhouse Coopers y Kodak, entre otras.

Caso de EstudioImplantación de una Plataforma de Gestión de RHPor Marco Antonio Cruz

Como sabemos, uno de los activos más importantes para una empresa de ser-vicios son sus recursos humanos. Ad-ministrar la información de éstos no es algo trivial, sobre todo en grandes em-presas multinacionales. Por ejemplo, consideremos el caso de una línea aé-rea. Este tipo de organizaciones suelen tener un vasto número de empleados ubicados en diversos países y plazas, esto se presta para que la información del personal esté dispersa y los trámites administrativos se hagan cada vez más complicados; y es que lograr el vínculo de colaboración entre los empleados y los procesos de negocio en estas condi-ciones suele ser complejo.


proveedor para conocer su experiencia y resultados. Fue así que se seleccionó la so-lución PeopleNet KSystem, de Meta4. Es-tas son las principales ventajas que TACA encontró en PeopleNet:

1. Tecnología: BD centralizada y tecnolo-gía WEB.2. Modelos funcionales estándar: proce-sos completamente enfocados al recurso humano.3. Flexibilidad: herramientas de desarrollo para adecuar los procesos a los requeri-mientos del negocio.4. Integración: asegurar que el sistema se integre eficientemente con las distin-tas aplicaciones del negocio, como ERP, CRM, etc.5. Amplitud y madurez: experiencia del proveedor en implantaciones globales.

Alcance del ProyectoEl alcance del proyecto es establecer una sola herramienta para procesar las nóminas de 17 países y estandarizar en una sola plataforma los procesos de recursos humanos de sus 19 países. Estos incluyen: • Estructura Organizacional• Gestión de Personal• Selección• Evaluación• Formación• Remuneraciones• Competencias

Adicionalmente, se construyeron los portales para empleados y managers: ESS (Employee Self Service) y MSS (Manager Self Service), mediante los cuales se brindarían los servicios on-line a todos los empleados y se establece-rían los distintos flujos de autorización por los gerentes del área.

Etapas del ProyectoUna vez pactados los contratos respectivos con el proveedor, se planteó un gantt origi-nal para la parametrización de los distintos módulos y se segmentaron en tres bloques principales las implementaciones de nómi-nas: primero, casa matriz (40% del HC y complejidad mayor), luego el resto de Cen-troamérica y México y, por último, en el ter-cer bloque, todo Sur América.

Se inició con una etapa de alineación de pro-cesos e información en toda la organización. De esto se obtuvo un rediseño de cada uno de los procesos establecidos en un modelo de administración de nóminas y recursos huma-nos, que fue validado por los responsables del área RH y Nóminas de cada uno de los países y consolidado por un equipo de consultoría externa. Una vez establecidas en un documen-to las adecuaciones necesarias al producto, se inició una fase de construcción.

Una vez desarrollados los cambios de acuer-do a los requerimientos establecidos, se inició una fase de pruebas. En esta se realizó una simulación de todos los procesos para el país con mayor complejidad, generando así un ciclo de optimización proceso-detección e implementación de mejora. Durante esta fase fue indispensable establecer los criterios para determinar cuales de ellos se implantarían en una segunda fase.

Para la fase de capacitación y roll-out se es-tableció un equipo que realizaría la imple-mentación en los distintos países; el cual está compuesto por un equipo de migración de datos, un equipo de funcional y capacitación y un equipo de soporte a producción. El roll-out se consolidó en cinco agrupaciones de países en los cuales los dos primeros grupos abarcan 60% de la organización. Cada grupo de roll-out estaba separado por un periodo de dos meses que es el tiempo necesario para la implantación del siguiente bloque.

Estructura del EquipoEl equipo del proyecto está formado por cua-tro grandes grupos: los representantes de Re-cursos Humanos de cada país; los analistas de negocio, que rediseñan los procesos y realizan la capacitación funcional; los consultores de Meta4 que dan asesoría sobre la herramienta y realizan las adecuaciones a ésta; y el perso-nal de TI de TACA, que se encarga de la mi-gración de datos, desarrolla los componentes nuevos, y da soporte técnico a los usuarios.

Lecciones Aprendidas y Riesgos a CuidarComo resultado de los dos primeros bloques de implantación se identificaron las siguientes lec-

ciones a tomar en cuenta y riesgos a controlar para facilitar las siguientes etapas de liberación.

1. Revisar las definiciones de los procesos a desarrollar, para que empate con los pro-cesos de selección y cumpla con ellos.2. Establecer claramente el alcance del proyecto y de las adecuaciones para cada bloque de implementación.3. Facilitar el proceso de migración y ali-neación de información.4. Consolidar un proceso de acopio de información, estableciendo la fuente de la información, la precisión, conversiones de datos, etc. 5. Realizar de forma oportuna la transfe-rencia de conocimiento hacia el personal encargado del soporte a producción.

BeneficiosEntre los beneficios institucionales identifica-dos de manera inmediata se encuentran:• El establecimiento de un proceso de recluta-miento automatizado.• La estandarización de políticas y métodos. • La reducción en los tiempos para los trámites.• La optimización de los recursos de entrena-miento.• La compra centralizada de materiales y equipos.• La implementación de un centro de contac-to para atención a empleados.

Inversión y RetornoDebido a que la solución no se ha termina-do de implantar en todos los países, aún no se cuenta con el costo total del proyecto; no obstante, el planteamiento original es que los ahorros generados permitan recuperar la in-versión en dos años y medio.

Agradecemos el apoyo de José Giovanni Hernández, Líder de Pro-yecto en TACA, para el desarrollo de este artículo.


JUL-AGO 2006 www.softwareguru.com.mx

PRÁCTICAS

El Lic. Valerio Adrián Anacleto es socio fundador y consultor en Epidata Consulting, una empresa basada en Argentina que se especializa en brindar servicios re-lacionados con la arquitectura de software. Adrián también es docente en la Universidad de Buenos Aires, y ha publicado artículos sobre arquitectura de software en medios como .Code, JAIIO y agile-spain.

Reconstrucción de Arquitecturas de Software

ARQUITECTURA

36

Muchos son los escenarios en los cuales es ne-cesario realizar la reconstrucción total o par-cial de una arquitectura. La mayoría de estos

escenarios se encuentran relacionados con la carencia o pérdida de documentación actualizada de la arqui-tectura, y la posible necesidad de analizar los requeri-mientos de calidad que debe cumplir la arquitectura.

A través de la reconstrucción de arquitecturas se ob-tienen vistas de la arquitectura del sistema actual, que reflejan cómo fue implementado el sistema. Las vistas de la arquitectura proveen documentación útil sobre el sistema y puede ser utilizada para tomar decisiones acerca del mismo.

La reconstrucción de arquitecturas es un problema que puede catalogarse como: interpretativo, interac-tivo e intensivo.

PerfilesEn una reconstrucción de arquitectura suele necesitarse la intervención de varios perfiles profesionales. Entre ellos: experto en ingeniería en reversa; un arquitecto familiari-zado con la reconstrucción de arquitecturas; expertos del dominio de negocio; y conocedores de la aplicación, si es que existen y están disponibles.

El Proceso de Reconstrucción de Arquitecturas del SEIDiremos que un proceso de reconstrucción de arqui-tecturas es ciego, cuando partimos de un descono-cimiento total de la arquitectura y reglas de negocio existentes. Muchos de los procesos existentes para la reconstrucción de arquitecturas parten de esta premi-

sa. Mostramos a continuación uno de los procesos de reconstrucción de arquitecturas más difundidos, propuesto por el SEI[1] y del que podemos encontrar más información.1. Extracción de Información. 2. Construcción de una base de datos. 3. Fusión de vistas. 4. Reconstrucción.

Este proceso es iterativo y termina cuando se tiene una arquitectura de la aplicación. El criterio de finalización no se encuentra del todo definido y dependerá de los involucrados en el proyecto.

Actividades en la Reconstrucción de ArquitecturasEn cada una de las etapas se realizan las siguientes tareas:1. Extracción de Información: se encarga de analizar y extraer información de la aplicación a partir del código fuente. Se extraen relaciones de lec-tura, escritura y creación entre los elementos del código fuente mediante la utilización de herramientas tales como: parsers, analizadores léxicos, profilers, etc.2. Construcción de una base de datos: con la información extraída se pro-cede a la Construcción de una base de datos. 3. Fusión de vistas: mediante el despliegue de vistas de la base se proce-de a analizar y quitar ambigüedad a la información recopilada, depurando los datos obtenidos. 4. Reconstrucción: en la reconstrucción se procede a visualizar e interac-tuar con la información extraída y a definir e identificar patrones dentro de esa información (componentes).

El SEI creó una herramienta que permite manipular la información y des-plegarla de manera gráfica, la herramienta se llama DALI.[2]

El Proceso en Entornos Reales: Tips para Hacerlo más EficienteSi bien el proceso de reconstrucción propuesto por el SEI es bueno en los ca-

Por Valerio Adrián Anacleto

Reconstrucción de Arquitecturas de Software

sos en los que no se cuenta con información de contexto o se tiene un arquitectura con una carencia total de documentación, en la mayoría de los casos de la vida real se cuen-ta al menos con algo de información que po-dría hacer mucho más fácil la reconstrucción de un arquitectura. Por otro lado, el objetivo del resultado final no está debidamente de-finido desde el comienzo. Cuestiones como el nivel de abstracción de la arquitectura a definir, vistas necesarias, etc. queda librada a juicio de quien realiza la reconstrucción cuando es dado a pensar que el objetivo de-bería estar alineado con las necesidades de la empresa. Empezar relevando claramente el objetivo permite trazar un mejor camino adecuado hacia él.

Demasiado Hincapié en la Vista ConceptualEl proceso del SEI hace fuerte hincapié en la vista conceptual (estática) de la arqui-tectura, dejando de lado otras vistas de la arquitectura. Por ejemplo, si tuviéramos que lidiar con la reconstrucción de un arqui-tectura que incluye una capa de integración basada en J2EE, ¿de qué manera descubri-ríamos la parte topológica y altamente com-pleja de la arquitectura? Para resolver este problema, el SEI propone la utilización de los descriptores y meta información clásica de los componentes EJB, pero deja de lado la visualización dinámica de éste.

Definir un Lenguaje Adecuado para la Representación de la ArquitecturaLa metodología del SEI no utiliza un lengua-je de descripción de arquitecturas (DDL) lo cual dificulta la comunicación entre los pro-fesionales. Una solución es representar la arquitectura mediante diagramas UML 2.0 estándar, si bien UML carece de un DDL, es posible representar arquitecturas de manera razonable para la mayoría de los casos y, lo que es mejor, puede ser utilizado para comu-nicarse adecuadamente con profesionales de desarrollo de software capacitados.

Relevar la Información de ContextoAntes de comenzar una reconstrucción de una arquitectura es dado a pensar que un buen relevamiento previo puede agregar un gran valor a la tarea de reconstrucción. La formalización de las técnicas de recopi-lación de información serían de un aporte muy interesante. Preguntas relativas al flujo de los datos dentro de la arquitectu-ra, el relevamiento de la arquitectura de hardware existentes, una vista de ejecu-ción de arquitectura, son sólo algunos de los artefactos fácilmente recopilables.

Relevar e Identificar MétricasContar con métricas sobre la arquitectura y sus falencias actuales puede ser de ayu-da al momento de identificar arquitecturas subyacentes. Muchas de estas métricas pueden obtenerse mediante la creación de cuestionarios adecuados con la técnica de GQM (Goal Question Metric)[3].

Referencias1. Liam O’Brien, Christoph Stoermer, Ar-chitecture Reconstruction Case Study (CMU/SEI-2003-TN-008).2. Rick Kazman, Liam O’Brien, Chris Verhoef, Architecture Reconstruction Guidelines, 2nd Edition (CMU/SEI-2002-TR-034).3. Liam O’Brien, Christoph Stoermer, Chris Verhoef, Software Architecture Re-construction: Practice Needs and Current Approaches (CMU/SEI-2002-TR-024).4. Bass, Len. Clements, Paul. Kazman, Rick. Software Architecture in Practice. Addison Wesley. 1998.5. C. Stoermer, L. O’Brien, C. Verhoef. Moving Towards Quality Attribute Driven Software Architecture Reconstruction, Working Conference on Reverse Enginee-ring, Victoria, BC, Canada. 2003.



PRÁCTICAS

Eduardo Noriega de Armas es Director General del proyecto AprendaMas.Net (www.aprendamas.net). Realizó sus estudios de Licenciatura y Maestría en la Universi-dad Central de Las Villas, en Cuba. Ha sido profesor en las Universidades Central de Las Villas en Cuba, Universidad de Guadalajara e Instituto Tecnológico y de Es-tudios Superiores de Occidente (ITESO). Ha sido consultor en varias empresas y forma parte del equipo de desarrollo de la compañía Grupo Flextronics S.A. de C.V.

Patrones de DiseñoCOMBINA Y GANAPor Eduardo Noriega

DISEÑO

38

En este artículo, mostramos la fortaleza de utilizar y combinar diversos patrones de diseño en la solución de un problema. Para lo que desarrollamos un ejemplo en cuya solución utili-

zamos los patrones Abstract Factory, Facade y Observer.

Como sabemos, los patrones de diseño, describen un problema que ocurre repetidas veces en algún contexto determinado del desarrollo de software y entregan una buena solución ya pro-bada. Esto ayuda, a diseñar correctamente en menos tiempo, a construir soluciones reutilizables y extensibles, y facilita la docu-mentación. Los patrones nos dicen cómo aplicar de manera eficaz la herencia, el polimorfismo y todas las ventajas que posee el pa-radigma orientado a objetos.

En el libro “Design Patterns: Elements of Reusable Object-Orien-ted Software” (Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides), los autores presentan una excelente recopilación de 23 patrones, clasificados en patrones de creación, estructura y conducta. Estos ofrecen excelentes soluciones a muchos de los problemas, que como desarrolladores de software, encontramos día con día.

Sin embargo, muchas veces, para solucionar un problema específico, no basta con aplicar un determinado patrón, sino que, de manera creativa, tenemos que combinar varios de ellos para conformar la solución. Por lo tanto, mostraremos un problema y daremos su solución, combinando varios de los patrones descritos en el libro antes mencionado.

Trabajemos entonces el siguiente problemaSe desea implementar una aplicación que verifique si un cliente es elegible para un crédito hipotecario. Dicha verificación con-sistiría en revisar sus cuentas bancarias y revisar su estado cre-diticio. Estas operaciones de verificación son complejas y varían de un país a otro. Deseamos que sea suficiente con cambiar un parámetro, para que todas las verificaciones se hagan para un determinado país. Además, que la incorporación de un nuevo país al ambiente, sea algo sencillo. Deseamos además, que la interfaz visual vaya mostrando como van avanzando cada una de esas verificaciones.

Según este problema, necesitamos verificar cuentas bancarias y es-tado crediticio para diferentes países. Para solucionarlo, podemos utilizar el patrón Abstract Factory. Que nos permite crear una clase concreta para cada país, y trabajar con ellas de una manera total-mente uniforme, logrando que nuestra aplicación cliente se abstrai-ga de las complejidades de trabajar con uno u otro país.

La solución se modelaría utilizando el siguiente diagrama UML.

En el diagrama podemos ver cómo obtendremos una clase abs-tracta llamada AVerificador, la cual tendrá un método estático GetPaís(). A ese método le pasaremos un indicador del país que deseamos crear y nos devolverá una instancia de la clase concreta con que se modela el país, ya sea México, USA u otra. Esas clases concretas heredan de la clase abstracta AVerifica-dor, que implementan los métodos comunes GetBanco(), Get-Credito(), etcétera.

La clase Cliente declarará una variable del tipo AVerificador y la instanciará a través del método estático GetPais() de esa misma clase, obteniendo entonces una instancia del país en concreto. De esa manera, bastará con cambiar el parámetro que le pasa-mos al método GetPais y que indica el país con el que desea-mos trabajar, para que toda la solución se enfoque en el país de nuestro interés.

El método GetBanco() devolverá instancias de las clases Banco-Mexico o BancoUSA, en dependencia del país con el que estemos trabajando. Esas clases implementarán la interfaz IBanco, en la que se declaran las características comunes de los bancos para todos los países. De la misma manera, el método GetCredito() de-volverá instancias de las clases CreditoMexico o CreditoUSA, en dependencia del país desde donde se haya invocado. Esas dos clases implementarán la interfaz ICredito, en la que se declaran las características comunes de los créditos de todos los países.

La clase Cliente declarará variables del tipo IBanco e ICredito, a las que, se le asignarán instancias de las clases BancoMexico, BancoUSA, CreditoMexico o CreditoUSA, respectivamente. De

tal manera, podrá interactuar con las clases concretas de una manera transparente, pues lo hará a través de las interfaces que ellas implementan.

Así, tenemos nuestro problema solucionado en buena medida. No obstante, el modelo puede mejorar. Sucede que la clase Cliente, va a tener que declarar un Verificador, instanciar el país en concreto, obte-ner su banco y su crédito e interactuar con ellos a través de sus inter-faces. Lo que puede significar demasiada complejidad para un cliente; mas si deseamos implementar diversos clientes para diversas tecno-logías (digamos una aplicación Windows, una aplicación Web y otra para móviles), sería mucho mejor extraer esa complejidad del cliente y colocarla en una clase de alto nivel en la capa de negocio.

Esa clase, tratará toda la lógica del patrón Abstract Factory como un subsistema, encapsulando su complejidad, ofreciendo al cliente una sencilla y única interfaz; permitiendo que el trabajo del cliente sea lo más sencillo posible.

La implementación de lo que hemos dicho, nos la da el patrón Faca-de. Que nos sugiere la implementación de una Fachada que interac-túe con el subsistema, ofreciendo al cliente una interfaz sencilla.

La solución se modelaría utilizando el siguiente diagrama UML:

Ya tenemos un cliente sencillo y una clase que hace la verificación que deseamos. Sólo nos queda un punto por resolver. El problema inicial dice “Deseamos además, que la interfaz visual vaya mostran-do como van avanzando cada una de esas verificaciones”. ¿Cómo lo-grar entonces que el cliente se entere que la Fachada de verificación ha hecho cada uno de los pasos?

Nos podemos apoyar en el patrón Observer, que nos dice, cómo re-lacionar dos clases pasando mensajes entre ellas, sin que esto con-lleve al establecmiento de un acople fuerte. El patrón nos sugiere la creación de una interfaz Sujeto (ISubject) que será el sujeto observa-do, y una interfaz Observador (IObserver) que será quien se interese por los cambios de estado en el sujeto.

ISubject ofrecerá un método Subscribe() que reciba un parámetro de tipo IObserver, a través del cual un Observador podrá suscribirse a los eventos del sujeto. Además, ofrecerá un método Unsubscribe(), que también recibirá un IObserver para que éste se pueda desuscribir. Por último, tendrá un método Notify, en el que recorra la lista de observa-dores, invocándole a cada uno su método Update, para que el obser-vador se entere que el sujeto cambió su estado y generó un evento.

Por su parte, la interfaz IObserver ofrecerá ese método Update() que será invocado por el sujeto, a través del cual, el observador se enterará del cambio de estado en el sujeto y realizado una acción al respecto.

La inclusión del patrón Observer en nuestra solución se refleja en el siguiente diagrama:

Se observa en este caso, cómo la clase Cliente implementará la interfaz IObserver, mientras que la clase FachadaVerif imple-mentará la interfaz ISubject. A partir de ese momento, Cliente se convierte en un Observador, mientras que FachadaVerif se convierte en el sujeto observado. El Cliente entonces, se puede suscribir a los eventos de la Fachada, y ésta, cuando verifique el banco, invocará su método Notify para avisar al cliente que se ha dado un paso. Pasará lo mismo cuando revise el crédito. De tal manera el Cliente recibirá eventos a medida que se van ejecu-tando los diferentes pasos de la verificación, además de contar con la libertad de hacer ciertas acciones, como por ejemplo, ir avanzando una barra de progreso, entre otras.

Así finalizamos este ejemplo. En él utilizamos tres patrones: el Abs-tract Factory, el Facade y el Observer, para a través de su combina-ción, obtener la solución a nuestro problema.

Referencias• Profesional Design Patterns in VB.NET: Building Adaptable Applica-tions. Tom Fischer, et al. Apress, 2003.• Design Patterns: Elements of Reusable Object Oriented Design. Erich Gamma, et al. Addison Wesley, 1995.

40 JUL-AGO 2006 www.softwareguru.com.mx

PRÁCTICAS

DISEÑO

DISEÑO


PRÁCTICAS

Gabriel Rolando Vázquez Pérez, tiene más de diez años de experiencia en Consultoría de la Tecnología de Información en ambientes multiplataformas. Actual-mente es arquitecto de arquitecturas SOA y vocero de CrossVision, en Software AG. Se ha desempeñado en el área de consultoría y preventa en las industrias de telecomunicaciones, financiera, sector público, transporte y manufactura. Dentro de Software AG ha desempeñado varios cargos durante su trayectoria tanto a nivel nacional como internacional en las áreas de soporte técnico, preventa, consultoría de estrategia y negocio.

Arquitectura Orientada a ServiciosPARTE 1: INTEGRACIÓN DE APLICACIONES Y ORQUESTACIÓN DE SERVICIOS Por Gabriel Vázquez

ARQUITECTURA

42

A ctualmente, las empresas necesitan explotar sus intangibles: cultura, capacidad de aprendizaje y procesos, como ventaja competitiva para lograr un mayor beneficio de negocio. A lo

largo de los años, ha existido un abismo entre las necesidades de las empresas por adaptarse a los cambios que el mercado demanda, y la facilidad de cambio en las aplicaciones para cubrir los nuevos proce-sos de negocio. Se han creado ecosistemas tecnológicos con sistemas legados, portales, ERPs, CRM, call centers y SCM, etcétera; en un in-tento por resolver el problema del cambio en demanda. Sin embargo, no ha sido suficiente, ya que la colaboración y la capacidad de cambio de los sistemas es tecnológicamente limitada, y de esta manera han surgido las islas de automatización donde la colaboración requerida se resuelve por procesos manuales de difícil adaptación.

Arquitecturas Orientadas a Servicios Con el surgimiento de XML se han desarrollado estándares encami-nados a resolver la interoperabilidad de los sistemas, como los ser-vicios Web con SOAP. Esto permite que las aplicaciones expongan su funcionalidad como un conjunto de servicios reutilizables y pre-parados para colaborar entre ellos. También surge la necesidad de independencia de proveedor, abordar la diversidad tecnológica y protección a la inversión existente en las aplicaciones empresaria-les. Este es el concepto clave de SOA: exponer la funcionalidad de las aplicaciones con servicios estándares con XML que se puedan utilizar de forma ágil para lograr la flexibilidad tecnológica deman-dada por la dinámica de los procesos de negocio.

Los servicios Web con SOAP proporcionan un mecanismo estándar para la integración de las aplicaciones ampliamente adoptado en la industria. Sin embargo, esto no es suficiente. También se requiere de una nueva generación tecnológica que permita abordar la cola-boración inteligente de las aplicaciones que requieren los procesos de negocio para integrar tecnología y personas. La respuesta de la industria de TI es la creación de nuevas herramientas que ayuden a

incrementar la madurez de las empresas a través de una mejor capa-cidad de los procesos que realizan.

Cabe resaltar que SOA no es un componente tecnológico que pue-da ser adquirido como una sola licencia, realmente es una estra-tegia tecnológica basada en servicios que permite a las empresas construirla de acuerdo a sus necesidades.

Las nuevas tecnologías se han diseñado en capas con funcionalidad definidas y encaminadas a resolver necesidades específicas: 1. Integración de aplicaciones y orquestación de servicios.2. Gestión de procesos de negocio.3. Integración de la información con una vista única.4. Nuevas aplicaciones.5. Metodología.6. Modelo de gobierno.

En este artículo hablaremos de la integración de aplicaciones y or-questación de servicios. El resto de los temas serán abordados en subsecuentes oportunidades.


Integración de Aplicaciones y Orquestación de ServiciosA lo largo de los años las empresas se han apoyado en fuertes inversiones en tecnología y aplicaciones como soporte de los diferentes procesos de negocio. Los procesos son llevados a cabo entre diferentes áreas de las empresas donde la integración se ha llevado a cabo me-diante personas o intercambio de documentos entre las mismas. Una consecuencia de esta necesidad es la latencia de la información, es decir, que existe aquella información en un área que es requerida por otra para tomar alguna decisión importante. Con esto queremos decir que la integración de los sistemas siempre se ha llevado a cabo a lo largo de los años.

El problema inicial es que la mayor parte de los sistemas, tradicionalmente, no fueron pen-sados en integrarse o colaborar, ni preparados para proporcionar funcionalidad en Internet. Esta brecha ha sido solucionada de diferentes formas en las empresas:• Programación de interfases que puedan extraer la información de las aplicaciones y la pue-dan depositar en un formato o archivo intermedio que pueda ser tomado por la aplicación destino. Generalmente estas interfases dependen del lenguaje con que se programan. Si se tiene que transmitir la información por la red, se tiene que programar la interacción a bajo nivel o se realiza el intercambio por protocolos de transferencia como el FTP. También se deben resolver en la interfase programada, las diferencias de plataformas y transformación de la información. Las conexiones que se tienen son punto a punto.

• Middleware orientado a mensajes que proporciona un API estándar en cada una de las plataformas que resuelve sus diferencias. Sin embargo, todavía es necesario programar con su API. La ventaja sobre la programación de interfases en la estandarización de la integración bajo la visión con un solo método e independiente de lenguaje. La unidad de intercambio de información es un mensaje que contiene un buffer donde residen los datos. Durante la transferencia de datos no existe inspección sobre los mismos, este middleware sólo se encarga de asegurar la entrega a la aplicación destino, la transformación de la in-formación todavía se tiene que programar en cada una de las aplicaciones integradas.

• Broker de mensajes que consiste en un middleware inteligente que contempla la in-clusión de herramientas para elaborar mediante flujos de intercambio de información. En este nivel de integración es posible inspeccionar el contenido para cada uno de los mensajes y, con base en el mismo, aplicar características de transformación de datos, reglas de negocio y ruteo basado en su contenido. La interacción con las aplicaciones se basa en adaptadores que por un lado son capaces de comunicarse con la API de la aplicación y, por otro, generar un mensaje canónico que puede integrarse al ambiente; es posible tener reuso de componentes de integración, siempre y cuando no se salga del ambiente del Message Broker.

PRÁCTICAS

ARQUITECTURA

Se han desarrollado un mundo de herramientas que proveen esa funcionalidad, sin embargo, aunque proporcionaban ambientes distribuidos sobre la red y eliminaban las necesidades de pro-gramación, la comunicación entre cada uno de los componentes era propietaria, por lo que se dependía de un solo proveedor para enriquecer las ofertas. Hay quienes llaman a estos ambien-tes de integración aplicaciones legadas en la integración.

• Bus empresarial de servicios es la respuesta a las deficiencias de los Message Brokers. Se tienen las ventajas de transformación de datos, reglas de negocio, ambiente distribuido, ruteo basado en contenido, adaptadores, etc. La diferencia fundamental es que se basan en XML en la representación de los datos en los mensajes y la interacción se lleva a cabo mediante servicios Web, lo que incorpora una fuerte estandarización entre cada uno de los componentes que proporciona la flexibilidad de utilizar el proveedor que se requieraEsta capa está orientada al intercambio de información.

• La integración bajo el enfoque de arquitecturas orientadas a servi-cios permite utilizar componentes de las capas anteriores bajo están-dares como XML y Servicios Web con un enfoque total que permita abrir la información de los sistemas como soporte a los procesos de negocio bajo un objetivo de negocio. La diferencia con las capas an-teriores es que se dedican a resolver la integración desde el punto de vista de intercambio de datos y resolver problemas técnicos.

Los servicios Web son creados para exponer funciones de nego-cio en un formato y mecanismos estándar a diferentes niveles de granularidad. Por ejemplo, pueden ser necesarios servicios Web de transacciones puntuales de aplicaciones legadas, y por otro lado, necesitamos componer un nuevo servicio que requiera la invocación en secuencia de los servicios Web anteriores, esto es la orquestación de servicios, y permite crear servicios Web inteligentes y de gran va-lor coordinando; los servicios Web puntuales, lo que se conoce como servicio orquestado.

Desde un punto de vista lógico, la integración de las aplicacio-nes puede ser llevada a cabo de tres formas: sesión, transacción y datos. La integración de sesión se lleva a cabo mediante el uso de la funcionalidad que se obtiene de la navegación de la funcionalidad. La integración de transacción consiste en llamar directamente las transacciones existentes de las aplicaciones mediante un API oficial. Finamente la integración de datos se lleva a cabo con las fuentes directas de la información a partir

de las bases de datos mediante los APIS de los manejadores de las bases de datos, ODBC o JDBC.

La integración de sesión claramente ofrece un gran valor en aque-llos escenarios donde no se cuente con un API oficial de integra-ción. Este tipo de integración es en un solo sentido. Por ejemplo, las aplicaciones de z/OS pueden ser expuestas como servicios Web pero no pueden participar como consumidores de otros ser-vicios. También encapsulan generalmente la funcionalidad exis-tente que cuenta con una interfaz de usuario o una rutina que permita llamarla.

En otros escenarios, las aplicaciones se encuentran bien estruc-turadas en capas de presentación, negocio y datos. Idealmente las transacciones que contienen lógica de negocio pueden ser llamadas desde SOA mediante servicios Web. La integración de transacciones se puede hacer bidireccional y asume que las apli-caciones se encuentran bien estructuradas, en caso contrario, deberán someterse a reingeniería. La funcionalidad de las aplica-ciones expuesta puede ser tan puntual que es necesario utilizar la orquestación de servicios.

La integracion de datos se presenta cuando es necesario acceder a la información que almacena una aplicación, sin requerir de su lógica de negocio. Los retos a vencer son la encapsulación de los datos re-queridos en sentencias SQL o que se puedan ejecutar procedimien-tos almacenados; el estándar de conectividad es generalmente JDBC o ODBC. Sin embargo, al acceder directamente a los datos, hay que tener en cuenta que se puede cometer errores de interpretación de datos, además de que se están saltando las reglas de validación e integridad de éstos.

ConclusionesCuando adoptamos la integración de aplicaciones con los estándares SOA nos permite preparar la estrategia estandarizada tecnológica-mente que pueden convivir con cada una de las otras capas que dis-cutiremos en artículos posteriores. Además de obtener flexibilidad en la elección de aquellos componentes tecnológicos y proveedores que más se adapten a su ecosistema tecnológico y necesidades que permitan por un lado proteger la inversión actual y, a la vez, poten-ciar sus procesos para lograr la agilidad de respuesta de la tecnolo-gía demandada por los procesos de negocio.


ARQUITECTURA

www.softwareguru.com.mx JUL-AGO 2006 45

Luis Daniel Soto Maldonado es Direc-tor de Evangelización en Nuevas Tecnologías en Microsoft México. Entre sus funciones actuales están la administración de la relación con el Gobierno Mexicano para el desarrollo de la industria de software (ProSoft). Luis Daniel es jurado del “Gran Or-den de Honor al Mérito Autoral” en software del INDAUTOR/SEP y fundador de diversas asociaciones de Tec-nologías de Informa-ción (TI) relacionadas a inteligencia competiti-va, administración del conocimiento y cons-trucción de software. Luis Daniel Soto es Ingeniero en Sistemas de la Fundación Arturo Rosenblueth y ganó el primer lugar en el concurso nacional para software de ex-portación en 1989. blogs.msdn.com/luisdans

CO

LUM

NAEl Nuevo Microsoft

Tecnologías emergenes

TENDENCIAS EN SOFTWARE

E l pasado 15 de junio, Bill Gates anunció un plan de transición de 24 meses — a partir de julio del 2008 su principal actividad será filantró-

pica. Warren Buffet, el segundo hombre más rico del mundo, anunció unos dias después un regalo por 30 mil millones de dólares a la Fundación Bill y Melinda Gates. Sin duda esta ONG tiene una gran capacidad para alterar temas sociales, con fondos por arriba de 60 mil millones de dólares. En comparación, las nacio-nes unidas operan con 12 mil millones de dólares al año y la fundación Ford ahora parece enana con 11 mil millones de dólares en capital.

Ray Ozzie, creador de Lotus Notes y de Groove, junto con Craig Mundie serán los líderes técnicos del nuevo Microsoft. Ellos pertenecen mucho más a la generación de “software como servicio” que a la presente, esto se aprecia claramente en sus blogs.

Abundancia de Tecnologías EmergentesEn silencio, hay una inmensa cantidad de nuevas tecnolo-gía y adquisiciones por parte de Microsoft. Estos son algu-nos ejemplos únicamente:

1. Microsoft Robotics Studio. Una plataforma de desarrollo para aplicaciones para una variedad de hardware que inclu-ye además un simulador de aplicaciones robóticas en 3D.

2. Microsoft Forefront. La mayor integración de múltiples tecnologías de seguridad.

3. Microsoft PerformancePoint. La mayor integración de funcionalidad de panel de control, análisis y planeación.

4. Microsoft Windows Compute Cluster Server. Ahora Mi-crosoft Excel 2007 soporta nativamente un millón de ren-glones por 16 mil columnas descargando el análisis a la plataforma de cómputo de alto desempeño acomodada en forma de granja y con servidores de 64 bits

5. Microsoft Unified Communication Strategy. Pretende unir las islas de correo electrónico, mensajería instantánea, Voz sobre Internet, telefonía móvil y videoconferencias. Esto requerirá integración a nivel hardware interactuando con productos existentes y futuros de oficina.

Embarcar software, embarcar software, embarcar softwareEl desarrollo de Visual Studio Orcas – planeado para la se-gunda mitad del 2007 se encuentra en su pleno apogeo. El

arranque en el desarrollo de Visual Studio Hawaii y Office System 14 (Office 2007 System + 1) se han concretado.

Las áreas de mejora que veremos son muy numerosas: desarrollo desconectado, aplicaciones altamente inte-ractivas en web y en Windows, aplicaciones empresaria-les, móviles, distribuidas, intensivas en acceso a datos y escenarios simplificados para el uso de entusiastas no programadores.

Transformemos nuestra cultura en una de actualización permanente.El 95% de la población de T.I. confunde hoy una “arqui-tectura basada en servicios” – o la capacidad de crear una aplicación distribuida – con los “servicios web” (normas que no necesariamente se tienen que utilizar para crear una aplicación distribuida).

Ante este punto de partida, es claro que los informáti-cos tenemos grandes retos y oportunidades en la ver-tiginosa transformación de la industria de software. Si no abrimos el espacio, el tiempo y los foros para dialogar sobre tecnologías actuales y futuras en su aplicación (v.gr. www.on10.net) estaremos muy pronto viviendo en el pasado. La responsabilidad es de cada uno de nosotros.

He laborado para la “empresa de las ventanas” por más de trece años. Ciertamente en el año 2000 observé el auge desmedido por las empresas de tecnología. En cier-to modo, “el presente” parece ser relativamente estable pero se están gestando una cantidad inmensa de cambios, y debemos estar al pendiente de ellos.

Lecturas y recursos adicionales http://rayozzie.spaces.msn.com/ http://msdn.microsoft.com/robotics/ http://www.microsoft.com/Forefront/default.mspx http://office.microsoft.com/en-au/FX101550371033.aspx http://msdn.microsoft.com/vbasic/Future/default.aspx http://www.on10.net/

MAY-JUN 2006 www.softwareguru.com.mx

UML

caso, es el dominio de UML el que permite lo-grar comprender las cosas de una forma más sencilla. La mejor forma de transmitir esta habilidad es a través de capacitación que in-volucre simulacros de proyectos reales, en lu-gar de únicamente explicar los “dibujos” que conforman los diagramas de UML.

La Magia de Armar RompecabezasLa “magia” para ayudarle a los usuarios a en-tender su negocio por medio de UML consis-te en saber pegar las piezas aisladas que nos proporciona en un rompecabezas completo y coherente que sea mucho más claro que la explicación original. Incluso el usuario ve las cosas con más claridad cuando le mostramos eso que él mismo explicó, por medio de los modelos. Al respecto, mis alumnos suelen preguntarme qué artefactos de UML son los más apropiados para ser utilizados en la co-municación directa con el cliente. Es decir, cuáles le pueden entregar con la seguridad de que el cliente los va a entender.

Entre los artefactos básicos que yo sugiero para esto, están:a) Para definir la funcionalidad del sistema, los casos de uso.b) Para comprender la jerga del cliente, el mo-delo conceptual. c) Para validar con el cliente si comprendemos el trabajo (procesos/procedimientos) que rea-liza su empresa y que desea automatizar; posi-blemente no haya nada como el diagrama de actividades.

¿Alguien Sabe Cómo Funciona Este Negocio?Y es que suele ser la regla, más que la excep-ción, encontrarse con usuarios que no com-prenden del todo los procesos dentro de los cuales participan. Por lo que nosotros, como analistas, terminamos recogiendo todas las piezas del rompecabezas para después pe-

Del Negocio al Sistema: El Diagrama de Actividad MANUFACTURA O CONSULTORÍAPor Sergio Orozco

Sergio Orozco es director general e instructor senior certificado por la OMG en Milestone Consulting. Primer empresa mexicana miembro de la OMG, especializada en la capacitación práctica y consultoría en UML, CMM y orientación a objetos. [email protected] www.milestone.com.mx

¿C uál es la diferencia entre la manu-factura de software y la consultoría

de software? En mi opinión la consultoría le ofrece un valor extra al cliente más allá de la construcción del software. Para hacer con-sultoría debemos de ponernos en los zapa-tos del cliente para comprender su problema y necesidades, y de esta forma ser capaces de ayudarle a definir el sistema adecuado para su negocio.

En la manufactura la responsabilidad sobre la definición de la solución podría ser de menor proactividad que la de un consultor. En este caso el cliente nos especifica cuál es el soft-ware que necesita y nosotros lo fabricamos según sus instrucciones, con poco o nulo cuestionamiento de nuestra parte respecto a la relevancia de cada función a implementar en dicho sistema. El problema en este último es-cenario consiste en que el cliente NO suele ser un experto en sistemas de forma que pueda proponer el sistema ideal. El cliente es experto en su negocio y nosotros somos expertos en el nuestro: en el desarrollo de sistemas. Por lo tanto habría que tener clara la responsabilidad de cada quien dentro de un proyecto.

IQ, Experiencia o Simplemente TécnicasLo fascinante del modelado de negocio se puede ver en situaciones como la siguien-te: no es raro notar la sorpresa en la cara de nuestros alumnos cuando descubren que su instructor de UML pareciera comprender me-jor que ellos las reglas de negocio y reque-rimientos de sus propios sistemas, tan sólo con haber realizado un par de diagramas de UML durante un curso.

Pero sería muy presuntuoso pensar que un consultor o un instructor puede dominar las reglas de un negocio simplemente por su capacidad o coeficiente intelectual. En todo


garlas y así comprender los procesos del ne-gocio que serán automatizados.

Responsable del NegocioHace poco un alumno me preguntaba si el trabajo de modelar los procesos de negocio le correspondían a la gente de sistemas. La respuesta no es tan simple, pues en el mun-do ideal habría un rol que se encargara de eso y el equipo de desarrollo sólo tendría que preocuparse por definir y construir el sistema adecuado. Pero todos sabemos que el mundo no es color de rosa, así que no es raro que ten-gamos que ocupar dicho rol ante la ausencia de alguien más que asuma esta responsabili-dad. Con esto no quiero decir que recomiendo que la gente de sistemas se encargue de esta tarea, sin embargo, no podemos tapar el sol con un dedo, pues esto ocurre con bastante frecuencia ante la ausencia de un rol asignado para realizar dichas tareas entre los usuarios.

El ArtefactoEl diagrama de actividades es un artefacto muy útil y simple para comunicarse con el cliente porque en esencia es un diagrama de flujo, y ¿quién no ha visto o elaborado un diagrama de este tipo? La mayoría de los usuarios no tie-nen problema en entender este diagrama sin tanta explicación. La esencia del diagrama de actividades consiste en mostrar una secuencia de acciones o actividades, ya sea un proceso, un procedimiento, un conjunto de eventos de un caso de uso o los de un algoritmo.

Para mostrar los flujos más básicos sería su-ficiente utilizar dos elementos del diagrama: las actividades o acciones y las transiciones. En otras palabras, los pasos del proceso y el orden en que estos ocurren. De ahí podemos agregar más elementos para modelar flujos cada vez más complejos. Por ejemplo, un ele-mento básico a representar nos indicaría ex-plícitamente cuál es el inicio y fin del flujo.

MAY-JUN 2006 47www.softwareguru.com.mxwww.softwareguru.com.mx

Condiciones, Carriles y Flujos ParalelosQué felices seríamos si los procesos siguie-ran una ruta simple para cumplir con su objetivo. Desafortunadamente existen situa-ciones alternativas que hay que considerar y que complican su modelado. Estos flujos al-ternativos se pueden representar utilizando las condiciones que nos indican que tenemos que irnos por uno u otro camino, como cuan-do vamos a pagar una compra en el súper mercado y nos pregunta el cajero si quere-mos pagar en efectivo o con tarjeta. Cada op-ción requiere pasos alternativos a modelar a partir del símbolo de decisión.

En muchas situaciones querrás saber a quién le corresponde cada tarea del proce-so modelado, ¿al vendedor?, ¿al cliente?, ¿al encargado del almacén? Podemos represen-tar en este diagrama de una forma simple, mediante carriles, quién es el responsable de cada actividad dentro del proceso.

Los procesos se pueden complicar aún más al requerir actividades que se lleven a cabo en paralelo. Tampoco hay mayor problema, pues las barras de sincronización nos muestran cla-ramente esta característica del flujo que esta-mos modelando.

Uso y Generación de Productos¿Y qué hay de los productos o documentos que se utilizan o generan durante una activi-dad del proceso? Por ejemplo, para fabricar un carro, necesitas un motor y un chasis; es-tos son productos de entrada para generar un producto de salida. Para entregar cierta mercancía necesitas una orden de entrega. Este tipo de diagramas permiten represen-tar los productos de entrada y de salida para cada actividad, por medio de objetos y flu-jos de objetos.

Apto para Todo MundoLo mejor de todo es que estos diagramas no requieren mayor ciencia para ser entendidos. Al menos así ocurre con los procesos que no requieran demasiados tipos de elementos de este artefacto. Después de haber asesorado a todos esos proyectos durante estos años en las tareas de modelado, puedo asegurar que a los clientes les fascina este diagrama, pues de una forma simple definen su trabajo

y muchas veces lo ven por primera vez de una forma ordenada.

La Transición al SoftwareOtra gran ventaja de este tipo de diagra-mas consiste en la transición del análisis del negocio a los requerimientos del siste-ma de una manera más transparente. Nos ofrece la formidable ventaja de facilitarnos la identificación de los principales casos de uso del sistema, pues algunas de las acti-vidades mostradas en el diagrama se con-vierten directamente en casos de uso. De esta forma, comienza a aparecer mucha de la funcionalidad principal para el cliente; claro que no es toda la funcionalidad, pero por lo menos la que posiblemente sea más relevante para el negocio.

Para terminar, recuerda la regla del 20/80: 20% de los elementos de un artefacto te pueden ayudar en 80% de los casos. Así que para comenzar puedes subsistir con este pequeño resumen que aquí te presenté. Mucha suerte y hasta la próxima.

Figura 1. Diagrama de Actividades para la impresión

de una esquela en un periódico.


FUN

DA

ME

NTO

S

ITILUn Marco para la Calidad del Servicio de TIPor Teresa Lucio Nieto

Teresa Lucio Nieto es Directora General de Customer Care Associates (CCA), donde ha participado en proyectos relacionados con lealtad, retención y servicio a clientes, aplicando CRM, ITIL e ISO. Tiene experiencia en el diseño e implantación de estrategias de reingeniería de procesos, calidad y servicio a clientes en áreas de tecnología de información, recursos humanos, calidad, manufactura, distribución y centros de atención a consumidores para organizaciones como Gamesa (FritoLay), FEMSA, Prosa-Carnet, Coca Cola, IFE, PEMEX Exploración, PEMEX Perforación y Nextel entre otras. [email protected]

ITIL son las siglas de Information Technology Infrastructure Library y consiste en una se-rie de publicaciones que sirven de guía para proporcionar servicios de TI de calidad. ITIL describe una serie de buenas prácticas que, apoyadas en procesos y una amplia lista de roles, tareas, procedimientos y responsabili-dades, pueden adaptarse a cualquier organi-zación o área de TI.

A finales de los ochenta nace ITIL para me-jorar los servicios de TI que el gobierno de Gran Bretaña brindaba a los ministerios y otras oficinas del sector público, pero en la actualidad, es el marco de referencia para la gestión de servicios en la industria de la tecnología de información. El éxito de ITIL es tal, que hoy es utilizado como el estándar de Administración de Servicios de TI por al-gunas empresas líderes en el mundo, lo que ha dado pie al surgimiento de ISO 20000 (BS15000) como estándar propio de TI.

ITIL define los objetivos y las actividades, así como las entradas y las salidas de los pro-cesos de la organización TI. Sin embargo, no brinda una descripción específica de la forma en la que se deben implementar, ya que esto puede variar de organización a organización. Es decir, no se trata de una metodología, más bien es un marco de trabajo y de procesos. En esencia, los 10 procesos (interrelaciona-dos) que conforman la estructura básica de ITIL, tienen objetivos bien definidos y orien-tados a brindar servicios a un nivel de cali-dad preacordada (entre el cliente/usuario y el proveedor) al mejor costo posible.

Libros que Conforman las “Mejores Prácticas”A continuación los siete libros que conforman

ITIL, cada uno se enfoca a temas específicos, al servicio de TI en sus diferentes implicacio-nes. Cada uno se conecta con los otros:• Soporte del Servicio.• Entrega del Servicio.• Administración de la Seguridad.• Administración de la Infraestructura de TI.• Administración de Aplicaciones.• Planificación para Implementar la Adminis-tración de Servicios.• Perspectiva del Negocio.

Los libros de Soporte del Servicio y Entrega del Servicio, son considerados la parte cen-tral del marco de procesos propuesto por ITIL para la Administración de Servicios de TI. En este sentido, la estructura básica de ITIL se compone de cinco procesos relacionados con la Entrega del Servicio y cinco procesos de Soporte al Servicio. El Service Desk o Mesa de Servicio, si bien no es un proceso sino una función, que se incluye en la parte de Soporte del Servicio, aunado también con Administra-ción de la Seguridad, que forma parte de otro estándar en sí (BS7799 o ISO 17799).

Los procesos orientados a dar Soporte al Servicio; son los relacionados con el día a día del servicio de TI:

• Centro o mesa de servicio: Única función (no proceso), cuya razón de ser es dar sopor-te a la provisión de los servicios acordados, garantizando el acceso a la organización TI y comprometiéndose con algunas activida-des de los procesos. La Mesa de Servicio se constituye como el punto único de contacto entre los clientes y/o usuarios y la organiza-ción, o área de TI.• Gestión de incidentes: Restituir rápidamente el servicio después de un incidente y en cum-

plimiento de los Acuerdos de Nivel de Servicio (SLA) predefinidos, a fin de que afecte lo me-nos posible a las actividades del negocio.• Gestión de problemas: Descubrir y elimi-nar la causa de los problemas (o incidentes repetitivos), siendo la base de la mejora con-tinua del servicio. • Gestión de configuraciones: Mantiene infor-mes fiables de los detalles de los elementos de TI (hardware, software, documentación).• Gestión de cambios: Garantizar que se utilicen los procedimientos y los métodos estándar para que se puedan implementar los cambios/proyectos con rapidez y con el menor impacto posible en la calidad del ser-vicio de TI.• Gestión de versiones: Maneja y distribuye versiones de software y hardware utilizados para proporcionar el nivel de servicio acordado.

Procesos relacionados con la entrega del servicio de TI:

• Gestión de niveles de servicio: Garantizar que se mantengan y mejoren continuamen-te los servicios TI que necesita el cliente, además de establecer acuerdos de niveles de servicio (SLAs) que cumplan con sus ex-pectativas y definan la pauta a cumplir en los productos y servicios de TI.• Gestión financiera de los servicios TI: Ayu-dar a la organización TI interna, administran-do de una manera efectiva los costos de los recursos TI necesarios para proporcionar los servicios.• Gestión de la capacidad: Proveer de ma-nera consistente los recursos TI necesarios cuando son requeridos y a un precio justo, alineados con los requisitos futuros y actua-les del cliente.• Gestión de la continuidad de servicios TI:

www.softwareguru.com.mxwww.softwareguru.com.mx

Ayudar a toda la gestión de la Continuidad del Negocio (BCM), garantizando que la in-fraestructura y los servicios de TI puedan restaurarse dentro de los límites previamen-te especificados luego de un desastre.• Gestión de la disponibilidad: Proporcio-nar un nivel de disponibilidad de servicio de TI definido y eficiente en costo, que permita al negocio alcanzar sus objetivos.

ITIL en MéxicoA pesar de que en otros países la adop-ción de ITIL se ha consolidado a través del tiempo, en países como el nuestro vamos creciendo. Las principales causas de la baja tasa de adopción, es el desconocimiento de lo que implica y de sus beneficios potencia-les en las organizaciones. Por otra parte, implementar ITIL es una tarea que requiere esfuerzo, ya que su introducción demanda tiempo y esfuerzo, además de que fomenta un cambio a una cultura de calidad en la pro-visión del servicio, la cual no sólo impacta a TI sino que involucra a toda la organización.

Con todo, algunas empresas mexicanas, tales como ProsaCarnet, HSBC, HEB, Cerve-cería Cuauhtémoc-Moctezuma, Banjército, entre otras, ya han implementado ITIL con éxito. Éstas reportan como principales be-neficios la generación de ventajas competiti-vas, disminución en tiempos de respuesta a usuarios, mayor control de los gastos de TI y mejora tangible en la calidad del servicio.

Alrededor del mundo, las organizaciones están adoptando las prácticas definidas por ITIL, debido a que ya se ha comprobado el valor que genera su implantación. Entre los beneficios más comunes se encuentran: una entrega de servicio más orientada al cliente y/o usuarios; se controla mejor la calidad y el costo del servicio; la organización (o área) de TI desarrolla una estructura más clara que se vuelve más eficaz y se centra más en los objetivos de la organización, la dirección de TI tiene más control del servicio y costos; los cambios o proyectos resultan más fáciles de realizar y de asegurarse que no se generan

más incidentes por implementaciones mal planeadas o ejecutadas; mejora la comuni-cación interna y alienta el cambio hacia una cultura de provisión de servicios TI.

La Necesidad de InvertirIniciar un proyecto de ITIL requiere de los recursos necesarios para capacitarse, para adquirir tecnología que agilice el servicio, contratar consultoría que conduzca a la or-ganización a implementaciones exitosas y, lo que es más importante, un alto compro-miso del personal de TI a cambiar la forma actual de trabajar por mejores prácticas de servicio. Además, es necesario tomar en cuenta que ITIL se complementa con ISO 17799, CoBIT y CMM.

Retos de Implantar ITILSe espera que la adopción de ITIL tenga un auge en los próximos dos o tres años. En México, las áreas de TI ya se están pre-ocupando por entender este marco de pro-cesos y están validando cómo integrarlo a sus prácticas de trabajo diario, estamos seguros que las organizaciones que imple-menten ITIL más temprano, obtendrán los mayores beneficios.

Algunos consejos de cómo acelerar su adopción:• Determinar la justificación del proyecto li-gando TI a los objetivos de la organización y/o negocio.• Considerar tiempo y esfuerzo necesarios para su introducción (cambio a cultura de servicio) y difusión de los beneficios que traerá a todas las áreas de la organización.• Prepararse para evidenciar la mejora a través de información tangible sobre los procesos, con sus indicadores y métricas orientadas a la satisfacción de sus usuarios y clientes, y a generar valor en la organización.• Tener un enfoque de mejora del servicio y de reducción de costos (aunque no siempre es visible en el corto plazo).• Asegurarse de lograr el involucramiento y compromiso del personal a todos los niveles de la organización de TI.


Durante este mes me he dedicado a la eva-luación de una solución de telefonía IP para el corporativo donde trabajo. En este proce-so he tenido la oportunidad de conocer las soluciones de los principales proveedores de soluciones de comunicaciones IP y me he dado cuenta de las diferencias entre una solución tradicional y una basada en IP. Du-rante el proceso de evaluación tuve la opor-tunidad de leer un documento de uno de los principales proveedores, el cual me ayudo a “digerir” más el entendimiento de la imple-mentación de una red convergente y dismi-nuir los miedos naturales a la adquisición de una nueva tecnología. A continuación les presento un resumen de los principales pun-tos de este artículo y al final una referencia para que puedan revisarlo a detalle.

Siempre surgen muchas preguntas acerca de las tecnologías de comunicaciones IP, así como mitos. En los siguientes párrafos plati-caremos de los principales mitos que existen cuando hablamos de la implementación de redes convergentes y soluciones de comuni-caciones IP.

Los Mitos Comunes1. Los clientes deben de esperar a que las soluciones basadas en comunicaciones IP alcancen estándares maduros antes de ini-ciar su implementación.2. Una solución basada en comunicaciones IP requiere de una inversión más grande que la implementación de una solución de comunicaciones tradicional TDM (time-divi-sion multiplexing).3. Hoy por hoy, no existe una “killer applica-tion” para una solución de comunicaciones IP. 4. Las soluciones de comunicaciones IP son menos seguras que las soluciones híbridas donde podemos trabajar con una mezcla de servicios TDM e IP. 5. Implementar una solución de comuni-caciones IP implica desechar toda la in-

versión que hemos realizado en nuestra infraestructura basada en una solución de voz tradicional.

Mito 1. Los clientes deben de esperar a que las soluciones basadas en comunicaciones IP alcancen estándares maduros antes de iniciar su implementación. La percepción que tene-mos aquí es que no existen estándares lo su-ficiente maduros que nos permitan invertir en una solución de comunicaciones IP, sin correr el riesgo de adquirir tecnología cerrada que sea incompatible con futuros desarrollos o nuevas versiones. Esto obviamente se refle-jaría como una mala inversión.

Realidad. Actualmente existen están-dares maduros en soluciones de comu-nicación IP y seguramente continuarán emergiendo muchos más conforme evolu-cionen las aplicaciones. En el mundo de las comunicaciones puede tomar hasta menos de un año para que un estándar se vuelva obsoleto, pero la mayor parte de los estándares que son críticos para la im-plementación de una solución IP ya llevan bastante tiempo en el medio, por ejemplo, el Inline Power over Ethernet 802.3af que define las características eléctricas en la alimentación de los teléfonos IP data des-de el año 2003.

Mito 2. Una solución basada en comu-nicaciones IP requiere de una inversión más grande que la implementación de una solución de comunicaciones tradicio-nal TDM (time-division multiplexing). Hoy en día los teléfonos IP dan la apariencia de ser mucho más costosos comparados con los aparatos de un sistema de circui-tos de telefonía tradicional. En un sistema de comunicaciones IP, la inteligencia de la solución reside en el equipo telefónico. En el caso de los equipos de telefonía tra-dicional la inteligencia reside en las tarje-

tas y gabinetes de circuitos del PBX. Esto generalmente crea una percepción donde el grueso de la inversión de la solución se encuentra en los teléfonos. El cliente final sólo ve que el costo de un teléfono IP es muy alto, y pierde de vista el costo de las tarjetas necesarias para el funcionamien-to completo de un equipo telefónico de la telefonía tradicional. El resultado de esto es una barrera de sensibilidad al costo, que obstaculiza la adopción de una solu-ción de comunicaciones IP. Las empresas pequeñas y medianas, que son aún más sensibles a los montos de inversión, se espera que adopten este tipo de tecnolo-gías a un ritmo mucho más lento que los grandes corporativos.

Realidad. Está comprobado que las so-luciones de comunicación IP proveen un menor costo total de propiedad (TCO) y una mayor retorno de inversión (ROI) comparado con la telefonía tradicional. Un teléfono promedio de comunicaciones IP cuesta lo mismo o menos que su equi-valente en una solución tradicional TDM. Cuando uno toma en cuenta el valor to-tal de la solución y el TCO proveniente de una infraestructura que opera bajo una red convergente de voz, datos y video; una solución de comunicaciones IP puede ahorrarnos una cantidad considerable de dinero a las organizaciones por conceptos de: mantenimiento, administración, capa-cidad de crecimiento, cableado estructu-rado, etc.

Mito 3. Hoy por hoy, no existe una “killer application” para una solución de comuni-caciones IP. Después de todo, si existiera alguna, ¿no deberían de estarla adquiriendo y utilizando todos? Y, ¿no deberían las orga-nizaciones esperar a que existiera dicha apli-cación, antes de iniciar la inversión en una red convergente y de comunicaciones IP?

INFRAESTRUCTURA

A medida que las redes de voz, datos y video tienden a la convergencia, la mayor parte de las organi-zaciones comienzan a buscar el valor de implementar comunicaciones basadas en soluciones IP, tales como: telefonía IP, mensajería unificada, correo de voz, soluciones de telemercadeo, audio, video y conferencia web.

Mitos de la Telefonía IPBases para la ImplementaciónPor Ariel García

Realidad. Hoy por hoy existen muchas apli-caciones disponibles que reducen los costos de operación, incrementan la productividad y mejora la satisfacción de los clientes. El verdadero poder de las comunicaciones IP reside en la convergencia de voz, datos, video y las aplicaciones para el usuario. La arquitectura de las comunicaciones IP permite que las aplicaciones IP se integren a las aplicaciones existentes en la compa-ñía, como: correo electrónico, gestores de la relación con clientes (CRM), sistemas de calendario verticales como búsquedas de inventarios, llamadas de despertador de hoteles, sistemas asistencia de escuelas, video vigilancia, etc. Así como no existe una razón para no adoptar el uso de la Internet, no existe una razón para no adoptar el uso de comunicaciones IP.

Mito 4. Las soluciones de comunicaciones IP son menos seguras que las soluciones híbri-das donde podemos trabajar con una mezcla de servicios TDM e IP. Para mucha gente, no hay punto de discusión en cuanto a que las soluciones de comunicaciones IP son menos seguras que las soluciones con sistemas hí-bridos. El sentimiento que surge es: ¿Cuán-do fue la última vez que un troyano o gusano de Internet afecto a nuestro PBX?

Realidad. Las comunicaciones IP son segu-ras y confiables. La seguridad es un punto importante aun cuando no estemos co-rriendo nuestra red de voz en la red de da-tos. Pero el mito verdadero es pensar que los sistemas híbridos sean más seguros que los sistemas totalmente IP. Cualquie-ra de nosotros está familiarizado con la composición de los sistemas tradicionales PBX. Con estos sistemas debemos de pro-tegernos contra fraudes de llamadas, en-mascaramientos, y guerra de marcaje. Con los sistemas tradicionales, el acceso no autorizado es tan complicado como el uso

de una par de caimanes y bocina telefóni-ca, pero probablemente no tengamos que preocuparnos por gusanos de Internet. Sin embargo, existen quienes piensan que no es necesario preocuparse por la seguridad de la red, si uno opta por una estrategia de migración “híbrida”, usualmente pro-mocionada por proveedores de telefonía tradicional. Típicamente el primer paso en este tipo de estrategias es extraer el CPU y el procesador de llamadas fuera de los gabinetes e integrarlo a la red dedicada. Uno debe cerciorarse que la red sea total-mente segura, debido a que un ataque al procesador de llamadas afecta a todos los usuarios del sistema y no únicamente a los usuarios con teléfono IP. En este escenario no sólo se debe tener en consideración la seguridad de la red, como en un sistema totalmente IP, también hay que agregar la carga de trabajo debido a la administración de dos redes separadas, sin poder obtener los beneficios de una solución integral en una sola red convergente.

Mito 5. Implementar una solución de co-municaciones IP implica desechar toda la inversión que hemos realizado en nuestra infraestructura basada en una solución de voz tradicional. Debido a que la mayor parte de las compañías ya cuentan con una inver-sión en infraestructura de voz tradicional de algún tipo, la mayor parte de los usuarios piensan que el cambio a una solución de comunicaciones IP implica el desechar toda esta inversión.

Realidad. Las soluciones de comunicación IP ofrecen migraciones en fases, adecua-das a las necesidades del negocio. Lo si-guiente es un ejemplo de adecuar una vieja forma de pensar a un nuevo paradigma. En el mundo TDM, la telefonía está pensada como una serie de cajas que se encuentran físicamente en cada edificio de la compa-

ñía. Cada caja contiene cierto número de archiveros, y cada archivero contiene cier-to número de tarjetas y cada tarjeta contie-ne cierto número de puertos. En el mundo de comunicaciones IP, la telefonía está pensada como un servicio en la red. Este servicio está disponible desde cualquier punto de la red y es independiente de la ubicación física del equipo. Por ejemplo: en un negocio que cuenta con múltiples oficinas conectadas entre sí por una red, la implementación de un sistema de procesa-miento de llamadas se puede llevar acabo de forma centralizada, y después habilitar el acceso del resto de los sitios a este ser-vicio a través de la red.

Para mayor información y detalles de la solución:http://www.cisco.com/en/US/netsol/ns340/ns394/ns165/ns268/networking_solutions_white_paper0900aecd80104370.shtml

Está comprobado que las soluciones de comunicación IP proveen un menor costo total de propiedad y un mayor retorno de inversión.

ConclusiónLa mayor parte de los proveedores concuerdan en la tendencia de la desaparición de los equipos PBX. Las soluciones de comunicaciones IP es-tán diseñadas para integrarse a los principales sistemas PBX del merca-do, para permitir una migración pau-latina acorde a las necesidades del negocio en lugar de las limitaciones de la tecnología tradicional. Estos principales mitos de la soluciones de comunicación IP resultan ser falsos, la tendencia mundial a la migración de estos sistemas viene creciendo y no sólo para los grandes corporati-vos, sino también para las empresas medianas y las pequeñas con solu-ciones de outsourcing.


Nike + iPod

Sport KitEL Air Zoom Moire es el primer modelo de la marca Nike diseñado para contener el Sport Kit, un sistema inalámbrico compuesto de un sensor que envía información a un receptor que se conecta al iPod Nano para desplegar en su pantalla información de distancia recorrida, tiempo y ritmo. Para evitar distracciones al co-

rrer, también se puede hacer que la información se emita por voz a través de los audífonos del iPod. Después del ejercicio, los datos almacena-dos se pueden transferir a la computadora para archivarlos y mantener un control del progreso. Obviamente, las marcas han aprovechado para crear listas de reproducción específicas con ar-tistas exclusivos, y pronto se presentarán más productos, como chamarras, bandas para bra-zos y muñecas y otros modelos de calzado que aprovechen esta tecnología.


TECNOLOGÍA

Samsung

Q1La esencia detrás del desarrollo del concepto UltraMobilePC, al cual pertenece este muy peculiar producto de Samsung, fue la libertad digital, la convergencia tecnológica en un dispositivo. Además de incorporar funciones de PDA, reproductor de audio y video, sinto-nizador de TV y una tablet PC, el Q1 tiene un diseño muy llamativo y funcional.

Una pantalla táctil de 7 pulgadas, con resolución máxima de 800x480 pixeles —en formato 16:9—, es ideal para disfrutar de un sinfín de formatos, como AVI y WMV, además de DVDs y VCDs, ya sea desde su lector, o desde una fuente externa, pues además el Q1 tiene un puerto de entrada RCA, para conectarle incluso una consola de videojuegos. El sistema operativo Windows XP Tablet OS, le da funcionalidad de PC, permitiendo conectarle un teclado y mouse vía USB o utilizarlos inalámbricamente gracias al Bluetooth 2.0 que incor-pora. Soporta Wi-Fi, para navegar en cualquier hot-spot sin problemas, y además tiene un micrófono integrado para poder hacer llamadas vía Internet. La batería que se incluye da hasta 3.5 horas de vida en reproducción de video, y hasta 5 horas funcionando como PC, sin embargo, se puede adquirir un accesorio que extiende la vida hasta 10 horas.

NetGear

Skype Wi-Fi PhoneSkype es una aplicación descargable que permite hacer llamadas gratuitas vía Internet con contactos que usen el mismo software. Además, incorpora servicios para llamar a líneas locales en cualquier parte del mundo, video conferencia y mensajes de texto.

Lo más sencillo para disfrutar de Skype es con una computadora, pero ahora está dis-ponible este teléfono celular, que funciona en redes 3G y GSM, y soporta el protocolo Wi-Fi, para las llamadas vía Internet. Con ambas opciones, es posible comunicarse con los usuarios de Skype mientras se en-cuentre un hot-spot cerca. El Wi-Fi Phone es ideal para ahorrar en llamadas de larga distancia, además de que tiene un diseño sobrio y funcional.

Mi primer contacto con los ERPs fue en 1995, cuando se deci-dió en la empresa instalar uno. En esa época, los principales fabricantes eran SAP, Baan, Oracle Financials, JD Edwards y

People Soft. Realmente pocos sabían en qué consistía un ERP. Lo prime-ro que hice fue investigar qué empresas —en las cuales tuviera algún amigo— ya contaban con uno de estos sistemas. Me enteré que en una empresa líder en la fabricación de computadoras ya tenía uno y que no estaban muy contentos con su desempeño pues los inventarios de pro-ducto terminado no eran confiables, por lo que cuando tomaban alguna decisión con base en dicha información, resultaban teniendo problemas ya sea porque vendían computadoras que no tenían o dejaban de ven-der algunas que sí tenían. Esto se debía a que en ese tiempo el ERP con el que contaban hacía trabajaba con varias bases de datos las cuales se sincronizaban diariamente en la noche, lo que hacía que la información sólo estuviera actualizada en todos lados en la madrugada, pero una vez iniciada la jornada de trabajo empezaban las diferencias.

La primera recomendación que me dio Ernesto —amigo que trabaja-ba en esa empresa— fue que el proyecto completo lo pagara el cor-porativo y que él decidiera cómo parametrizar el sistema de tal forma que fuera homogéneo a todo lo largo de la empresa, la cual contaba con varias divisiones autónomas. Pero debido precisamente a esa autonomía, no se aceptó que sólo el corporativo pagara, por lo que cada división compró el ERP, aduciendo que al ser el mismo sistema en todas las divisiones se iba a poder comunicar sin problemas. Sin embargo, derivado de que las configuraciones fueron distintas en cada división, a la fecha no podemos tener una integración fluida entre las diferentes divisiones, siendo el problema más grave la di-ferencia de catálogos.

Hablando de catálogos, hay que tener mucho cuidado con este aspec-to tan “inocente”, pues no sólo los proveedores, sino también algunos informáticos convencen a sus clientes o usuarios de que se puede usar una tabla de conversión para traducir los códigos de un catálogo a otro. Sin embargo, al implementar esta solución, la misma dinámica de la operación tiende a provocar que las interfaces de traducción fallen. Lo más conveniente es planear las cosas para que los catálogos de todo tipo sean únicos a lo largo de toda la empresa.

Ya que toqué el punto de las interfaces, vamos a abordarlo un poco más en detalle. En la mayoría de los casos, es necesario desarrollar interfaces con el ERP. Las razones más comunes para esto son: bre-chas en la funcionalidad del ERP, buscar facilidad de uso, cumpli-miento con políticas y consulta a información histórica. Veamos cada una de éstas:

Brechas de funcionalidad. Existen funcionalidades que son fun-damentales para la empresa, y que no están cubiertas por el ERP. Por ejemplo, la nómina y el cálculo de impuestos en México son muy complicados, por lo que es común manejar esto por separa-do. También hay industrias muy especializadas, para las cuales no existen soluciones desarrolladas. El hecho de que el ERP no tenga la funcionalidad de los sistemas actuales hace que conser-vemos algunas partes y hagamos interfaces para solventarlo.

Facilidad de uso. La forma como se opera un ERP puede ser muy complicada para los usuarios acostumbrados a otras aplicaciones, por lo que se desarrollan aplicaciones que facilitan el la captura de información y posteriormente ésta se introduce a través de una in-terfaz.

Políticas. Hay procesos que se desarrollan en la empresa y que a to-das luces van en contra de las mejores prácticas, pero que por políti-ca se tienen que llevar a cabo. Tal es el caso de empresas que deben cumplir con una normatividad gubernamental o que es exigida por el corporativo de un grupo de empresas. También se da el caso de la separación física y lógica de información confidencial de las bases de datos comunes en la empresa, lo cual implica la implementación de interfaces.

Podríamos encontrar algunas otras razones, pero el problema reside en que no es fácil el manejo de las interfaces; entre los aspectos más importantes a considerar y que normalmente se menosprecian están los formatos, el tipo y longitud de los datos, la liga entre tablas, la conversión de datos, la validaciones de los mismos, la verificación de versiones de archivos origen y el manejo de las cifras de control, aspectos que a la postre no son triviales

En fin, si queremos un ERP para seguir operando como hasta ahora con las mismas facilidades y sin considerar que un ERP cambia la cultura misma de la empresa, vamos a tener que hacer un uso intensivo de in-terfaces, las cuales ocasionan todo tipo de contratiempos, como la falla de ellas mismas, la desactualización de la información, el retraso en al-gunos eventos o procesos, el alto costo de su mantenimiento agravado por los cambios de versión, etc. Entonces, mi recomendación es elimi-nar las interfaces; no usarlas en ninguno de los casos antes menciona-dos, tener el ERP lo más simple posible. No lo olviden, cuándo vayan a implementar un ERP, pregúntense para qué, podría salir muy costoso y con un beneficio, si es que existe, marginal.

—Joaquín Morales

CO

LUM

NA


Un ERP, ¿Para Qué?Aspectos a Tener en Cuenta

CÁTEDRA Y MÁS

El Dr. Joaquín Morales Uribe es Subgerente de Tecnologías de Información en PEMEX. Es Doctor en Ciencias Administrativas, y Maestro en Administración de Negocios, con estudios de especialización en Matemáticas Aplicadas e Informática en Toulouse, Francia. Imparte cátedra a nivel doctorado y maestría, y ha participado en foros y congresos en las áreas de TI, competitividad y administración.

INDEX

Anunciante Páginas SitioAMCIS 55 www.amcis.org.mxAvantare 49 www.avantare.comFour Js 15 www.4js.comGartner F3 www.gartner.com/mx/outsourcingIDC 53 www.idc-eventos.comIIDEA Solutions 37 www.iidea-solutions.comImexsoft 39 www.imexsoft.com.mxIngressio 47 www.ingressio.comItera 11 www.itera.com.mxMagnabyte 43 www.magnabyte.com.mxMilestone F4 www.milestone.com.mxMicrosoft 41 www.microsoft.com/mexicoRoca Sistemas 19 www.rocasistemas.com.mxSafeNet 09 www.safenet-inc.comSG Conference F2-1 www.softwareguru.com.mx/sg06

TENEMOS UN ESPACIO RESERVADO PARA TISi deseas anunciarte contáctanosen el (55) 5239 5502 o en [email protected]

DIRECTORIO



CA

RR

ER

A

Certificación en Administración de ProyectosOpciones y BeneficiosPor León Tripp

¿Quién me Garantiza una Correc-ta Administración de Proyectos?Como empresa, lo más conveniente es buscar personal capacitado, y mejor aún si cuenta con un certificado que ampare su conocimiento. Como profesionista, lo más adecuado es ca-pacitarse y certificarse para tener un diferen-ciador que te permita obtener una ventaja en el competido mercado laboral. Existen varias organizaciones para certificación en adminis-tración de proyectos, como el Association for Project Management (APM), con influencia en varios países de Europa, o el Computing Tech-nology Industry Association (CompTIA), que reside en Chicago, Estados Unidos.

Sin embargo, la autoridad indiscutible es el Pro-ject Management Institute (PMI), organización profesional fundada en 1969 con el objetivo de generar y difundir de manera no lucrativa el co-nocimiento relacionado a la Administración de Proyectos. El PMI cuenta actualmente con más de 200 mil socios ubicados en 125 países, y se ha posicionado rápidamente, no sólo como una institución americana, sino como una verdadera organización mundial, abriendo recientemente oficinas de representación en Europa y Asia.

Certificación PMPLa certificación emitida por el PMI se conoce como Project Management Professional (PMP) y es, actualmente, la certificación de este campo más respetada en el mundo, ya que el instituto mantiene un riguroso sistema de acreditación, contando a la fecha con 180 mil profesionales certificados a nivel mundial.

La publicación Microsoft Professional Magazi-ne, a través de su sitio de Internet www.CertCi-tes.com consideraba la certificación PMP como la número 10 más interesante para obtener en el año 2004. Sin embargo, para el 2006, se po-

siciona en el lugar número 4. Y no es de admi-rarse, ya que los PMPs certificados suman a la fecha 181,281, habiéndose certificado 96,884 tan sólo en el año 2005. Lo que representa un crecimiento de más del 100% en un año.

Si bien conseguir esta certificación represen-ta un reto profesional interesante, ya sea por la experiencia, o capacitación requeridas para ser elegible a presentar el examen; esto es justamente lo que las empresas y el mercado laboral aprecian. Una institución que cuenta con los filtros suficientes para garantizar que los profesionales que avala, cuentan con los conocimientos y experiencia necesarios para sacar sus proyectos adelante.

Para obtener la certificación PMP, cualquier aspirante debe satisfacer un mínimo nivel de capacitación, cierta experiencia participando en proyectos, estar de acuerdo con el código de conducta profesional del PMI y aprobar el examen, que por su complejidad y límite de tiempo que se tiene para realizarlo, muchos profesionales eligen tomar algún curso. Se im-parten varios en Estados Unidos y en nuestro país. Tomar uno de ellos aumenta la probabi-lidad de aprobar el examen. Siempre y cuan-do el proveedor educativo tenga la suficiente experiencia en los cursos que ofrece. Por otro lado, los números de los proveedores hablan por sí mismos. Al elegir proveedor de cursos es importante conocer algunos datos como son: • Porcentaje de aprobación de sus alumnos.• Material de apoyo.• Garantía que ofrece el proveedor en caso de no acreditar el examen.• Costo.

Los precios de un curso en México varían de entre 12 y 36 mil pesos de acuerdo a su experiencia y ofrecimientos. Adicionalmente

se tendrá que pagar el costo del examen que es de 534 dólares.

BeneficiosSi consideras que los costos son altos, bas-ta echarle un ojo a la encuesta de salarios que en julio de 2004 emitió el PMI, donde el salario anualizado en México para personas dedicadas a la Administración de Proyectos y que “no” cuentan con una certificación PMP es de 480 mil y una persona certificada 570 mil al año. Es un promedio, ya que las varia-ciones se presentan en función del puesto en la organización, años de experiencia, zona geográfica, industria, etcétera. Un PMP pue-de llegar a percibir hasta 800 mil anuales.

Otros Datos InteresantesEn el sitio web de OCC Mundial, aparecen pu-blicadas todos los días, al menos tres o cuatro vacantes, donde uno de los requisitos es es-tar certificado como PMP. También vale decir, que muchas empresas privadas y dependen-cias gubernamentales han optado por incluir, dentro de los requisitos para la asignación de contratos, el hecho de que el Líder de Proyec-to esté certificado ante el PMI.

Otra de las ventajas de estar especializado y certificado en la materia, es que las pers-pectivas de crecimiento en una empresa son muchas, ya que a un Project Manager se le ve actualmente como un “agente de cambio”: una persona capaz de ejecutar los cambios que la organización necesita.

Referencias• www.pmi.org • www.salary.com • www.alpha-consultoria.com • Project Management Institute. Project Management Salary Survey, Third Edition.

Las organizaciones realizan cada vez más proyectos, y cada vez son más complejos. En la mayoría de los casos, la planeación, ejecución y control de éstos se asigna a algún ejecutivo con buena reputación en la organización, habilidades gerenciales, mano dura y sentido común; todo ello de manera empírica. El resultado histórico es que 74 por ciento de los proyectos sufren una desviación de entre el 10 y 20 por ciento sobre los planes originales. Es por ello, que las organizaciones cada vez ponen un mayor énfasis en la correcta administración de sus proyectos.

León Tripp Delie está certificado como PMP por el Project Management Institute, y forma parte del equipo de consultores en administración de proyectos de Alpha Consultoría. Anteriormente se desempeñó como consultor de procesos en Accenture, participando en proyectos como la integración BBVA-Bancomer, y la transformación operativa y tecnológica en Grupo Nacional Provincial (GNP).

w

ww

.sof

twar

egur

u.co

m.m

xS

OFT

WA

RE

GU

RU

CO

NO

CIM

IEN

TO

EN

PR

ÁC

TIC

A

Juli

o-A

gost

o 20

06A

ño 0

2 N

o. 0

4

¿QUÉ MUEVE A TU EMPRESA? - Delia Esquer …desquer.ens.uabc.mx/afi/articulos/SG06_4_jul_ago.pdf04...

Documents

Transcript of ¿QUÉ MUEVE A TU EMPRESA? - Delia Esquer …desquer.ens.uabc.mx/afi/articulos/SG06_4_jul_ago.pdf04...