See discussions, stats, and author profiles for this publication at: http://www.researchgate.net/publication/256198812Consideraciones para proyectos deimplementacin de procesos utilizandoplataformas BPMSCONFERENCE PAPER NOVEMBER 2012DOWNLOADS576VIEWS2042 AUTHORS, INCLUDING:Bernhard HitpassUniversidad Tcnica Federico Santa Mara13 PUBLICATIONS 2 CITATIONS SEE PROFILEAvailable from: Bernhard HitpassRetrieved on: 09 August 2015Consideraciones para proyectos de implementaci on de procesos utilizandoplataformas BPMSDiego MoyaUniversidad T ecnica Federico Santa MaraDepartamento de Inform aticaBPM CenterSantiago, Chilediego.moya@outlook.comBernhard HitpassUniversidad T ecnica Federico Santa MaraDepartamento de Inform aticaBPM CenterSantiago, Chilebernhard.hitpass@usm.clAbstractLa competitividad y dinamismo del mercadoobligaalasorganizacionesaresponderyadaptarsefrentealas m as variadas necesidades de sus stakeholders. Las m ultiplesrelaciones y la variedad en modelos de negocio, ha impulsadoa muchas organizaciones a incorporar disciplinas como laGesti onporProcesos deNegocio(BPM), conel objetivodeserm as ecientes, ecaces y agiles. Laconsolidaci ondelasTecnologas de la Informaci on (TI) como agente transformadorycentral paralaautomatizaci onycrecimientodetodaslasorganizaciones, ha redenido muchos modelos de negocio. Lassoluciones para BPMhan madurado tanto a nivel de susfuncionalidades como su presencia en el mercado, sin embargo,las plataformas BPMSa unnologranposicionarse comolacomponente central para el desarrollo e implementaci on de losprocesos de negocio crticos de las organizaciones. La ausenciadeunaguaparalaejecuci ondeestetipodeproyectos, halimitadolaexploraci onyvalorizaci ondeestas plataformas,dej andolas muchas veces asociadas a procesos de caracteradministrativos y/o fuera del core del negocio. Comprender losdesafosdeimplementarprocesosconunaplataformaBPMSconsiderandoaspectosdegesti ondeproyectos, esel objetivodeestetrabajo, entregandounconjuntoderecomendacionesque permitan una implementaci on correcta, m as agil y segura.Keywords-Business Process Management (BPM); ProjectManagement (PM); Plataformas BPMS;I. INTRODUCCI ONA. Motivaci onCada da son m as las organizaciones que optan poradquirir eincluir plataformas BPMSensus eco-sistemasdesolucionestecnol ogicas. Apesardelasfuncionalidadesavanzadas que estas poseen, existendesafos importantesasociadosac omoyqui enlasutilizar a. Enel casodelasplataformas BPMS, el objetivo es brindar a la organizaci onla exibilidad y rapidez en la implementaci on o modicaci onde los procesos de negocio. Cu ales son las consideracionesque deben ser analizadas para asegurar una implementaci oncorrecta, m as agil y segura?,es la pregunta centralde estepaper paralasprincipalesdimensionesquetodoproyectodebe abarcar: costos, tiempos (plazos), calidad y la gesti onde riesgos.Al igual que todoproyectode desarrollode software,no s olo de la capacidad t ecnica de los programadoresdepender ael exitodelos proyectos. Diversos autores [8]dedicados al estudio de BPMhan publicado modelos ypatrones sugeridos para implantar BPM como disciplina degesti on, sin embargo, hasta la fecha no existe un modelo dereferenciaquesehagacargodeguiar laimplementaci onde sistemas utilizandoplataformas BPMS, de una formaintegrada conlas otras dimensiones de las iniciativas delaGesti onpor Procesos, an alisis (BPA: Business ProcessAnalysis) y monitoreo y control (Process Controlling).La contribuci on de este paper, radica en la formalizaci ondeunconjuntoderecomendacionesasociadasalagesti onde proyectos de implementaci on de sistemas utilizandoplataformas BPMS, que permiten anticipar los riesgos yamenazas asociadas a la gesti on de proyectos y a la adopci onde esta nueva forma de desarrollar aplicaciones.B. Contextualizaci onLa evoluci onde las tecnologas yla globalizaci onharepercutido en la forma de hacer negocios. La aparici on deinternet comolaprincipal reddecomunicaci onydifusi onde informaci on ha impulsado a las empresas a replantearsesus estructuras y procesos de negocio. Para enfrentar elescenarioantesrelatado, muchasdisciplinashanemergidoparaapoyarlagesti ondelasorganizaciones, cadaunadeellas asociadas aunobjetivoparticular desu epoca, porejemplo: enlad ecadade1980el focofuelacalidad, en1990fuelaglobalizaci onydesdeela no2000enadelanteha sido la velocidad [2]. Tanto la industria como la academiahan reconocido que hoy en da son dos las principalesdisciplinasquepermitenalasorganizacionesaumentarsurentabilidad, estas son: la Gesti on de Proyectos (PM - ProjectManagement) y la Gesti on de Procesos de Negocio (BPM -Business Process Management).Desdelaconsolidaci ondeBPMenlasorganizaciones,muchas herramientas tecnol ogicas han emergido con elprop ositodedisminuir labrechaqueexisteentrelos re-querimientos del negocio y las funcionalidades que sonimplementadas por los departamentos de Tecnologas de laInformaci on (TI) [1]. En este ambito las tecnologas deBPMse han agrupado bajo la denominaci on de BPMS(BPMsuitesosystems), lascualespermitentantolaim-plementaci on como el monitoreo y control de los procesosde negocio.Qu e es una plataforma BPMSy qu e la hace distintaalos frameworks dedesarrollodesoftwaretradicionales,sonlas primeras interrogantes quedebenser claricadas.Dependiendo de la fuente, es posible hallar diversas deni-ciones y propuestas del alcance que una plataforma BPMSdebiese tener, dado lo anterior, fue necesario homologar y es-tandarizar su denici on, para lo cual se considerar a lo escritoen[10], BPMSeslainfraestructurat ecnicaparagesti ondeprocesosqueextiendeel modeladoyejecuci ondelossistemas de workow con potencialidades para el monitoreoy control en lnea de procesos. De forma complementaria,valelapenarecalcar lasdiferenciasqueotrosautores[9]les atribuyen versus los tpicos sistemas de workow, ellosindican que la gran potencialidad que deben desarrollar losBPMSeslacapacidaddediagn osticodelosprocesosdenegocio,yquesoloestopermitir asudiferenciaci ondelastecnologas y sistemas de workow presentes hace d ecadasen la industria tecnol ogica.A pesar del avance en las tecnologas asociadas a BPM,las pr acticas en gesti on de proyectos y los niveles demadurezdelasorganizacionesimpidenolimitanel exitoesperado. Si a lo anterior se suma que existen diversos mode-los de operaci on y organizaci on al interior de las empresas,yquelosproveedorestecnol ogicosvendensolucionesqueno siempre se adecuan a las necesidades prioritarias delos negocios, se logra mantener y/o aumentar el porcentajehist orico de fracasos en la implementaci on de proyectos TI,el cual alcanza un escaso 20-30% [6] de exito. En [15], losautoresindicanqueConstruirsistemasesdifcil ycadada est a aumentando su complejidad. Muchos proyectos soncanceladosymuchos otrosnootorganelvalor denegocioesperado. Estadsticamente, laindustriadelasTI nohanmejoradoapesardelosesfuerzosporhacerdeestam asconable y predictiva.C. Gesti on de proyectos de implementaci on y BPMHoyendamuchasorganizacionescontin uanutilizandolas cl asicas metodologas vinculadas a la Ingeniera deSoftware para la gesti on de proyectos de implementaci on deprocesos utilizando las plataformas BPMS, sin embargo ex-isten muchas diferencias, una de las principales radica en queunesquemapurodeBPMnorequeriradeprogramadorespara modicar un sistema que soporte un proceso de negocio[17]. Paraentenderqu eesunproyectodeimplementaci ondeprocesosusandoBPMSsedebecomprendercu al eselciclodevidadeunprocesoyacotar el alcancequefueutilizado. El modelo m as com un en la gesti on de proyectosde desarrollo de software, es el waterfall lifecycle, que denelas siguientes etapas: Especicaci on y an alisis de requerimientos Dise no de la arquitectura Implementaci on e integraci on Vericaci on Operaci on y mantenci onElfundamentocentraldeesteenfoqueeslarigidezqueexisteparapasardeunaetapaalasiguiente. Lasventajasest an relacionadas a que el perodo de an alisis por logeneralesextenso, locualpermiteidenticarconclaridadlosalcancesdel sistema, evitandocambiosposteriores. Laexperienciahademostradoqueel costodemodicacioneses innitamente menor al inicio de un proyecto que enetapas de construcci on y/o explotaci on. Dado lo anterior, estetipo de enfoque es sumamente recomendable para proyectosqueimplementar anprocesos estables enel tiempoyqueno requieren muchos cambios y/o para proyectos en que laaparici on de alg un defecto sea tan grave como para impactarel exito del mismo. Otra caracterstica positiva es que paranuevos integrantes siempre existir a extensa documentaci on.A pesar que lo anterior podra hacer suponer que el ciclodevidadeproyectosencascadasesunaexcelenteopci on,sedebeprevenir respectoasusdesventajas. Com unmentelosusuariosal momentodeverunsistemadesear ancam-biosynuevasfuncionalidades, principalmentedebidoalabrechadetiempoentrequedeni oloquedeseabaversusloquerealmenteseconstruy o. Desdelaperspectivadelaimplementaci on misma, los desarrolladores suelen descubriral momento de terminar de construir que ciertas decisionespudiesenhabersidooptimizadas, porloquesi noexistennuevasfases, el costodel cambioser asuperior. Lamayorconsideraci on es que los procesos de negocio son din amicos,debidoasurelaci ondirectaconlos clientes, por locualtanto modicaciones en la economa como en leyes y regu-laciones, pudiesen impactar en modicaciones relevantes, aloscualeslasorganizacionesdebenresponderenelmenortiempo posible para mantener su posici on en el mercado y/opara cumplir con normativas.Como alternativa a la metodologa en cascada han surgidodistintos modelos, tales como: iterativo, incremental y agiles[12][5]. Enel casodel enfoque agil, unprincipiob asicoeslaentregaincremental desoftwareestable, integradoycerticadoa los usuarios, de modode obtener feedbackque pueda generar nuevos requerimiento o cambios en ellos.Las organizaciones que han madurado en los m etodos agilesasignan gran relevancia al proceso de captura de requerim-ientos y la estimaci on de impacto frente a las solicitudes decambio. En lo que reere a testing del software desarrollado,es recurrente el usode Test-DrivenDevelopment (TDD)[4], el cual denerelatosdeusuarios(User Stories) paravalidar y comprobar que los requerimientos del sistema est ensiendocumplidosencadaiteraci on. Laliteraturatambi enha comenzadoa estudiar ydiscutir c omola agilidadeslograda en el contexto de BPM, indicando que la concepci onactual de automatizaci on de procesos operacionales no est adirectamente relacionada con la agilidad de la organizaci on,puesto que esta s olo es alcanzada a trav es de ciclos r apidosdecreaci ondeconocimientoylaaplicaci ondelmismoenlamodicaci ondelosprocesos, transformandomuchosdelosprocesosdenegocioenunconjuntodeactividadesno-estructuradas [11].Quiz as el error m as recurrente entre las organizaciones enloquerespectaalasnuevastecnologasessuadquisici onpreviaaunan alisisprofundodelosbeneciosydesafosque esto traer a a cada compa na. El caso de las plataformasBPMSnoesdistinto, tal ycomosese nalaen[18], dichoautor indicaquelacomprapreviadesoftwarecomounade las peores pr acticas en lo que respecto a proyectosBPM/SOA se reere. El adquirir la tecnologa inicialmentenopermitemaximizarsurentabilidad, dadoquelasinicia-tivas y proyectos tratar an de explotar las potencialidades dela misma en lugar de buscar la herramienta o soluci on quemejor se adapte a la estrategia y necesidades del negocio.II. AN ALISIS DEL CONTEXTOA. Clasicaci on de proyectos BPMLagranvariedaddeenfoques einiciativas asociadas aBPM, hacennecesariasdistintasconguracionesyestruc-turas organizacionales, tantoparasugesti onyejecuci on.Lo anterior, genera distintos esquemas de colaboraci on y tra-bajo, algunas pueden optar por equipos internos o externos,contar onoconasesoresyespecialistas, sub-contrataci ondepersonal expertoporunplazodenidoparaadquirirelknow-how o simplemente, como un soporte permanente.El desafo inicial en toda organizaci on involucrada en unainiciativaBPM, constaenlaidenticaci ondel alcanceycomplejidad, y as ser capaz de estimar y denir el plan quepermita conseguir los recursos necesarios para su ejecuci on,el tama no de la organizaci on y de sus procesos, tal como semenciona en [3], es un factor que incide directamente en laforma de comprender la iniciativa a desarrollar.Respectoalagesti ondeproyectosBPM, losescollosycomplicaciones m as recurrentes son: Insuciente denici on del alcance del proyecto Faltadecompetencias enBPMdelas personas queparticipan en este Inadecuada gesti on de riesgos Error al identicar y denir supuestos Falta de preparaci on, experiencia y formaci on de lderesde proyectos Ausenciademetodologasyestrategiasglobalesparaabordar el proceso a implementar Ausencia de un plan de comunicaci on efectiva queinvolucre todos los niveles de la organizaci onComplementariamente a lo antes mencionado, existenfactores que inuyen directamente en la forma que debieseserconcebidoygestionadounproyectoBPM, entre estosest an: BPMen s debe estar basada en una visi on globaldecolaboraci ondecadaorganizaci on, tantoensudi-mensi oninternacomoexterna,permitiendoidenticarc omolosprocesosdeestaspuedengatillaryalcanzarlosbeneciosdeseadosmedianteelapalancamientoymejora continua de sus procesos [13]. Documentaci on incompleta de modelos de procesosoinadecuadalecturaeinterpretaci ondelosmismos,sin una perspectiva global, impiden obtener el m aximoprovecho de BPM. Los procesos ocultan ineciencias,puestoque pocas personas conocenc omorealmenteoperan, generando sobre producci on, tiempos de esperasuperiores a los deseados, err onea gesti on de inventar-ios, entre otros factores [9]. La falsa creencia consistente en asumir que todoslosprocesosdebenser ejecutadosinternamenteynomirar ni adoptar alternativas al quehacer actual de cadaorganizaci on, inyectando ideas nuevas y cambios en losesquemas tradicionales, podra impedir que una culturaorientada al mejoramiento continuo en BPMpuedanacer y madurar.Con la nalidad de recabar la situaci on actual en diversasempresas, acomienzosdea no, el centroespecializadoenBPM de la Universidad T ecnica Federico Santa Mara, BPMCenter, realiz o una encuesta para conocer el estado de BPMen el mercado local. Los resultados, sobre una muestrade 20 organizaciones distintas, entreg o valiosa informaci onreferida al estado actual y madurez de BPM.Figure 1. Encuesta BPM - Tipos de iniciativas en el mercado localEl primerhallazgorelevante, esqueun21%deorgani-zaciones declaraestar realizandoalgunainiciativadeim-plementaci on de procesos utilizando una plataforma BPMS,sin embargo misma proporci on indica que cuentan coniniciativas de implementaci on de procesos sin la utilizaci onde plataformas BPMS. Dicho similitud induce a cuestionarpor qu e existe un n umero importante de organizaciones queno optan por plataformas BPM?, Existe real conocimientosde dichas plataformas y sus ventajas?, Existen las compe-tencias sucientes para liderar dichos proyectos?. Respectoa la complejidad de lo proyectos de implementaci on BPM,la percepci on de ellos es que son m as simples que aquellosque son gestionados bajo las metodologas tradicionales dedesarrollo de software.Figure 2. Encuesta BPM - Elementos claves gesti on proyectos BPMAl igual queenresultados deotros estudios acercadela gesti on de proyectos, el atributo con mayor ponderaci onpara el exito de un proyecto BPM es: Obtener y contar conel respaldodelaaltadirecci on. Unavaloraci onrelevanteobtiene Disponer con proveedores con experiencia, lo ante-rior sugiere que gran parte de las organizaciones cuenta conapoyo externo para la gesti on de estas iniciativas.B. DesarrolloEl coredenidoparalaelaboraci onyconstrucci ondelModelodeReferenciaparaproyectosBPMsebasaenlacategorizaci onparainiciativasBPMexpuestasporHitpassen [7]. Lo anterior presenta una divisi on de proyectos BPMen dos grandes bloques: BPM Governance BPM OperacionalAl modelo all expuesto, se recomienda incluir una terceraagrupaci on, asociadaa ProyectosdeImplementaci ondeplataformas base. Este grupo de proyectos es transversal eindependientedelosproyectosquedecidanejecutarse,porejemplo, un proyecto de an alisis y re-dise no de procesos. Lasiguienteguramuestralaagrupaci ondeproyectosBPMsugerida por los autores:Dado el alcance de este trabajo, s olo se detallan losproyectosenel ambitodeBPMOperacional.Enestesub-grupo se han denido dos tipos de proyectos:1) Implementaci on de ujos: Sistemas legados para soporte BPM: este tipo deproyecto tiene por nalidad brindar las interfaces nece-sarias para integrarse con los motores de workow quetraen las plataformas BPMS. Las grandes corporacionescuentanconsistemas robustos ycomplejos, basadoscom unmenteentecnologasnoorientadasaservicios,por locual estetipodeiniciativasdemodernizaci onFigure 3. Tipos Proyectos BPMes fundamental para mantener controlado el riesgo tec-nol ogico y la continuidad de negocio. Es com un incluiralg un proyecto de SOA (Service Oriented Architecture)debido a la necesidad (ventaja) de contar con unaarquitectura normada y estandarizada que facilite laintegraci on de y entre aplicaciones. Nuevos procesos: este tipo de proyecto es en s elmenosriesgoso, dadoquelacontinuidaddenegocionoimplicaunaamenaza. El procesodenegociopu-diese ya existir pero sin ejecuci on autom atica ni semi-automatizada de las tareas que componen su ujo. Modicaci ondeujos: estetipodeiniciativas es lam as recurrentepuestoqueinvolucralamodicaci onpermanenteyconstantedeaquellosprocesosqueyacuentan, total o parcialmente, con soporte tecnol ogico.Nosiempreser aatrav esdeunasuiteBPMS, perolaimplementaci on a trav es de estas provee las potenciali-dades bases: control del ujo, integraciones a trav es deservicios, derivaciones y escalamientos, indicadores detiempos de ciclo, entre otras.2) Monitoreo y control: Estosproyectosconsistenenlaelaboraci ondeherra-mientas de control y monitoreo de indicadores claves dedesempe no del negocio, mediante la supervisi on de lostiempos, usoderecursos, identicaci ondecuellosdebotellaycomplicacionesquepuedenestarocurriendodurantelaejecuci ondeunainstanciadeunproceso.La realidad de muchas organizaciones consta en elan alisis post-mortemde la informaci on, mediante lautilizaci ondeplanillasdec alculoMSExcel y/oMSAccess, en las cuales se realizan todo tipo de cruce deinformaci on, talescomotablasdin amicas, entreotras.Enel ambitodeproyectosdeBPMOperacional, lasherramientas de control y monitoreo deben permitir aldue nodel procesocontar coninformaci onreal yenlnea del estado de las distintas instancias de cada unode los procesos bajo su control, pertimi endole mejorarsu proceso de toma de decisiones. Otrotipodeiniciativasorientadasal control ymoni-toreosonlos cubos deinformaci onpresentes enlosdata warehouse de las compa nas, sobre dichas fuentesde datos se aplican diversas t ecnicas para extraer infor-maci on relevante y, com unmente, consolidada desde lossistemas transaccionales. En el ambito de BPM, la exis-tencia de herramientas para Business Intelligence (BI),esuncomplementoquepermiterecabar informaci onuna vez que las instancias ya hayan nalizado su ujo,dichodeotraforma, corresponder aalan alisisex-postdel proceso.Acorde a [7], unproyectodel grupoanterior est a in-serto en la capa de BPE(Business Process Execution),la cual asume la existencia un modelo operacional deprocesoquepermitir aalas areastecnol ogicas, acargodelaimplementaci on, laconguraci ondelprocesosobreunaplataformaBPMS. LacapaBPEcontemplalassiguientesetapas:1) Recepci ondel modelooperacional desdelacapadenegocio2) Dise nodearquitectura, deworkowycapadepre-sentaci on3) Conguraci on y desarrollo de la soluci on BPMS4) Fase de pruebas y puesta en marcha5) Capacitaci on6) Traspaso a producci onFigure 4. Capa BPE: Business Process ExecutionEstemodeloasumequeunavezrecibidoel modelodeprocesos operacional, se inicia la etapa de dise no, donde sedenen cu ales actividades ser an manuales, semi-autom aticasoautom aticas, adem as de identicar las m etricas e indi-cadores deseadas. A lo anterior, se a nade la confecci on deldise nofsico, analizandolaplataformaTIquesoportar aelproceso y nalmente se dene un plan de implementaci on.III. RECOMENDACIONES EN PROYECTOS DEIMPLEMENTACI ON CON BPMSLas recomendaciones han sido identicadas gracias alaexperienciaadquiridatantoenlaimplementaci oncomogesti ondeproyectoscondiversasplataformasBPMS, es-pecialmenteOracleBPMS11geIntalioBPMS. Dichosproyectoshansidoimplementadosenel sector p ublicoyprivado, en algunos de ellos dentro del marco de un proyectoglobal de adopci onde BPMcomo disciplina de gesti oncorporativa, ytambi en, encasos enque algunas institu-ciones han deseado conocer las funcionalidades de estetipo de soluciones. Las buenas pr acticas (recomendaciones)aqu mencionadas, son divididas en dos grupos, el primeroasociadoalas actividades previas alaimplementaci onyconguraci onmismadelos procesos sobrelaplataformaBPMS, y la segunda respecto a las particularidades propiasde la implementaci on y los resguardos necesarios para queel proceso realmente permita y facilite el establecimiento deBPM como una disciplina que agregue valor a la compa naynotransformar laplataformaBPMSenunanuevaher-ramienta de desarrollo de software.A. Previas a la implementaci on Identicaci on de procesos candidatos a ser soportadossobre la plataforma BPMS Selecci on y evaluaci on de proveedores para imple-mentaci on utilizando suite BPMSB. Durante la implementaci on de procesos Identicar lo que se requiere y desea controlarSin una adecuada y temprana identicaci on de loselementos a medir es difcil elaborar unmodelodeproceso que permita entregar el conjunto de indicadoresbase para los reportes y elementos de control sobre lasinstancias. Una pr actica reiterativa entre los analistas deprocesosesquesededicanaconfeccionarunmodelode proceso (diagrama) basado en el control del ujo deactividades, postergandoellevantamientoydenici onde indicadores. Levantar en forma conjunta con elanalistadenegocioyel lder del proyectopor partedeTI, ypreviamentealaelaboraci ondel modelodeprocesoanivel t ecnico, el conjuntodeindicadoresyreportes que debiesen ser parte del ujo a implementar. Aunardistintas excepciones deunprocesoenun unico modeloSuelesuceder quelas areas ounidades deprocesosse dedican prolijamente a denir modelos de procesoscon amplia documentaci on. Sin embargo, vislumbrar unprocesoreusableparaimplementaci ondeunsistemainform aticodieretantoenel gradodecomplejidadcomoenlos niveles de abstracci onde los modelosqueseutilizanparacapturar lal ogicadesistemaseintegraciones. Cuandounprocesoposeaaltacomple-jidadybajaestructuraci ondelujo, esrecomendableabstraersul ogicayconcebirunaversi onsimplicadaquepermitaal usuarional operar el sistemayvercomo ir mejor andolo paulatinamente, a trav es de nuevasiteraciones. Lograr una r apida implementaci onTodonuevosistemageneraexpectativasyanhelosenlos usuarios de negocio, ya que esperan que dichodesarrollo les facilite las tareas diarias y operativasde sus labores. Es importante recalcar que muchosproyectos fracasan por incorporar niveles de detalley complejidad aspirando a revertir o mejorar todaslasdebilidadesdelosprocesosactuales. Enel marcodeproyectosconBPMSlarecomendaci onesdividirel alcanceenel ujoprincipal del procesoparaunaprimeraiteraci onysobredichaversi onir a nadiendolas funcionalidades y particularidades requeridas. Analizarydenirmejoras deseables peronour-gentesEn todo proyecto inform atico es normal que los usua-rios soliciten modicaciones a las especicaciones ini-ciales y/orecuerdenfuncionalidades noidenticadasal iniciodel proyecto. Estas solicitudes com unmenteson recibidas durante la ejecuci on de las fases deconstrucci onypruebas. Enel casodelos proyectosBPM, es recomendable indicar a los usuarios que estosson incrementales, basados en la mejora continua, porlo cual no conciban estos hechos como algo negativo.Sin embargo al igual que todo proyecto, estas iniciativasdebentener uninicioyunt ermino, por locual losugerido es identicar las mejoras y documentarlas, sinembargo explicar que su implementaci on se realizar a enuna pr oxima versi on del proceso. Lo anterior, permiteinculcar unestilode trabajoorientadoenla mejoracontinua, basado en un ciclo de vida para procesos queincluya: an alisis, dise no e implementaci on, y, luego, elmonitoreo y optimizaci on como mejora continua. No forzar la adaptaci on de metodologas tradi-cionales de ingeniera de softwareConcebir un proyecto de implementaci on utilizandounasuiteBPMSconlasmismaspr acticasnopermiteobtenerel mayorbenecioposible. Porqu e?Lare-spuesta es simple, pero no siempre evidente. En laingenieradesoftwaremuchasvecesseutilizalafasede an alisis para levantar la situaci on actual y vislumbrarreci en las mejoras (funcionalidades) que el sistemadeber a soportar.Enel casodeBPM, seasumeunmodeloyamejo-radoyqueincluyeal menosel ujodecontrol yladenici ondepantallasdelsistema. Lacomposici onanivel de roles tambi en sufre modicaciones [16], puesesrecomendadocontarconprofesionalesespecialistascon el perl de: Analista de Negocio, Arquitecto de Ne-gocio, Jefe de Proyectos, Arquitectos de la Soluci on y,nalmente, los implementadores y encargados de cali-dad. Lo anterior permitir a unicar el dise no del procesotantoalascapasdeNegociosuperiores(ArquitecturaEmpresarial) como elaborar un dise no reutilizable y quecumpla con los patrones de dise no de la arquitectura enlas soluciones de la organizaci on. El modelodeprocesosesydebeserel diagramaprincipal para comprender el sistema a construirCon la aparici on de plataformas BPMS capaces de eje-cutar directamente ujos de procesos en BPMN 2.0, laconfecci ondeartefactosdesoftwarecomplementario,tales como diagramas UML, pudiese o no ser requerida.La pr actica ha permitido validar que solo un diagramageneral decasos deusos es sucienteparapermitirla denici on inicial de requerimientos funcionales quedeber an ser contemplados en el proceso. La simplicidadde BPMNpermite validar con los propios usuariosde negociola l ogica del procesoya la vez ser eldocumentoinicial de construcci on(implementaci on).Hayqueadvertir quelaelaboraci ondeunproyectorequiere contar conservicios capaces de abstraer lacomplejidaddelas operaciones CRUDmnimas querelacionen los datos del proceso. Evitar mezclar roles de administraci on de sistemasen los modelos de procesosEnla implementaci onde sistemas suele convivir lal ogica misma de la aplicaci on y las funcionalidades quepermiten la administraci on de esta, tales como: creaci onde usuarios, asignaci on de perles, modicaci on deinformaci on de contacto, conguraci on de par ametros,entre otras. En la pr actica, la administraci on de sistemasesgestionadaporlas areasTI, loanteriorimpideunaentrega total de los sistemas, generando una dependen-cia natural con las areas t ecnicas.La correcta implementaci on de un proceso sobre BPMSdebedistinguirdoscapasmnimas: administraci ondeusuarios sobre BPMS y administraci on de usuariosdel proceso. El primer tipo de administraci on debefocalizarse en la habilitaci on de credenciales y perlesasociados a los usuarios de uno o m as de los procesosdisponiblesenlasuite. El segundotipodicerelaci onconlagesti onderolesyusuariosdeunprocesoenparticular, lo que incluye las relaciones de dependenciaparalacorrectaejecuci ondelastareasvinculadasenel proceso. Separar y parametrizar reglas de negocioLas reglas de negociodebiesenser modicables sinnecesidad de alterar la versi on del proceso en pro-ducci on. Larecomendaci onincluyeutilizar motor dereglas de negocio o implementar una componente inde-pendientedesdelaperspectivatecnol ogica,quepuedaser consultadomediantelainvocaci ondeunservicioen la implementaci on t ecnica del ujo del proceso.Si lasreglasdenegocioseentrelazanconlasreglasdel ujodel proceso, cadamodicaci on, porejemploen los montos m aximos para un proceso de aprobaci oncrediticia, obligar a a los usuarios nales a solicitarunamodicaci onsobreelujodeprocesoal areadeprocesos, impactandonegativamenteenel atributodeagilidad esperado para BPM.IV. VALIDACI ONLa metodologa de validaci on consider o dos casos deproyectos reales de implementaci on de procesos. En amboscasosladecisi ondelaempresafuelautilizaci ondeunaplataformaBPMSparalaautomatizaci ondeestos proce-sosdenegocio. Previoaestasiniciativas, laorganizaci on(compa na de seguros) contaba con una metodologa basadaen un conjunto de documentos bases para la gesti on ycontrol de sus proyectos, sin embargo no exista un rolencargado de velar por la correcta aplicaci on de cada una delas etapas ni en el contenido de los documentos generados.Porejemplo: unmismojefedeproyectosasumarolesdeanalista, dise nador, arquitectoytester. Algunos proyectoseran desarrollados internamente y el resto con empresasexternas.A. Casos de muestraAcontinuaci on se explica brevemente el alcance decada uno de los procesos de negocio que gatillaron laelaboraci ondedosproyectosdeimplementaci onsobrelaplataforma BPMS. El primer proyecto no hizo uso delasrecomendacionesexpuestasenestetrabajo, fueguiadobajo la metodologa de gesti on de proyectos tradicionaldelacompa na, orientadaadesarrollodesoftwaresobretecnologas Cobol y .NET. En el segundo caso, el proyectofueorientadodesdeunaperspectivadegesti ondeproce-sos, aplic andoselasrecomendacionesdesdeel procesodeselecci on de proveedores hasta su nalizaci on, que incluy oun ciclo de mantenciones peri odicas que permiten ajustar elproceso de negocio a los cambios del negocio.1) Proyecto1:: Elalcancedelprocesoes:Controlarlagesti on de los estudios de abogados que prestan apoyoalacompa naenlastareasasociadasalarecuperaci onde dineros vinculados a siniestros. Desde la perspectiva desistema, el requerimiento consista en habilitar un canal webque permita a cada estudio de abogado enterarse de los casosasignados, describirlospasosejecutadosyel resultadodesus acciones.2) Proyecto2: Elalcancedelprocesoes:Controlarlasacciones relativas al proceso de liquidaci on de siniestros devehculos una vez que se han decretado p erdidas totales, confoco en la gesti on de activos y stock de vehculos en casasde remate. Desde la perspectiva de sistema, el requerimientoconsistaencontarconunsistemaquepermitaconocerycontrolar de manera eciente cada una de las actividades delproceso de liquidaci on, concentrando toda la informaci on delos siniestros y gestionar el stock de vehculos.B. Evaluaci on y resultadosLa comparaci on y evaluaci on entre los proyectos fuerealizadotomandoencuentaunsubconjuntodeelementosque dan cuenta de los criterios emergentes para la evaluaci onde desarrollos de software adaptativos presentados en [14]:1) Cumplimiento en plazos: el t ermino y entrega delsistema fue en la fecha inicialmente comprometida.2) Cantidad de re-planicaciones: cu antas veces elproyecto fue replanicado.3) Satisfacci on usuaria: percepci on del cliente internorespecto al valor entregado al negocio y, complemen-tariamente, si la plataforma le permite contar coninformaci on para controlar su proceso.4) Costo real vs inicial: comparaci on entre el presupuestoinicial estimado y el real.5) Iteraciones etapa de pruebas: cantidad de certica-ciones por el usuario, permite validar si el requer-imiento inicial fue o no r apidamente entendido eimplementado de forma correcta.Acontinuaci onsepresentanlos resultados delacom-paraci on entre los proyectos:Table ICOMPARACI ON DE PROYECTOSCumplimientoplazos [d]Cantidad re-planicacionesSatisfacci onusuariaCostoreal vsinicialIteracionesetapa depruebasProyecto 1 180 5 Baja +30% 4Proyecto 2 20 1 Alta +0% 2V. BENEFICIOS ESPERADOSLas recomendaciones base para el modelode refenciaparaproyectosdeimplementaci ondeprocesosenBPMS,traeconsigounconjuntodebeneciosendistintasdimen-siones, estas corresponden a: Costos, Tiempos, Calidad y enGesti ondeRiesgos. Acontinuaci onsepresentaunabrevedescripci on estas:A. Reducci on de costos Disminuci onenlacantidaddeiteracionesderevisi ondurante la etapa de testing y certicaci on usuaria,graciasaunamayorparticipaci onyvalidaci onconelusuario/cliente. Menorutilizaci onderecursosparaladocumentaci on,graciasalasimplicidadyunicaci ondelamismaatrav es del modelo de procesos en su nivel t ecnico.B. Ahorro en tiempos La identicaci on de m etricas e indicadores, en conjuntocon las reglas de negocio, en una etapa inicial y comorestricci on para el inicio de la implementaci on, evitar amodicaciones posteriores sobre lo desarrollado.C. Aumento en la calidad La inclusi on de etapas incrementales de funcionali-dadessobreel sistema, inicialmenteprocesoyluegofunciones complementarias, permitir a la realizaci on devariadas iteraciones de validaci on, mejorando la calidadnalD. Reducci on de riesgos La identicaci on de caractersticas propias de losproyectosdeimplementaci onconplataformasBPMS,disminuir aeventualesriesgosgravesparael exitodelproyecto, por ejemplo: identicaci on tarda de indi-cadores que obliguen la modicaci on del ujo decontrol del proceso.VI. CONCLUSIONESEl paper hadadocuentadelaspr acticasyrecomenda-cionesnecesariasparalograrunmejordesempe nodurantelas principales etapas de un proyecto de implementaci on deprocesos sobre una plataforma BPMS. La experiencia y re-visi on de los desafos y problemas recurrentes en la Gesti onde Proyectos, en especial, en la industria del desarrollo delsoftware, permiti ocorroborar queparteimportantedelascomplicaciones son reproducibles en proyectos BPM.Respecto a la implementaci on de procesos utilizandosuites BPMS fue posible corroborar que un modelo t ecnicodeprocesosdeprocesoss oloser adevalor cuandotengacontempladas las dimensiones analticas yde gesti onre-queridas.Elestudiodelmercadolocal,permiti oidenticarun riesgo importante asociada a la asignaci on y preparaci ondeproyectosBPMS, estos ultimossoncom unmentedele-gadosajefesdeproyectosquenocuentannecesariamenteconlaexperienciaenlosprocesosdenegocio. Maximizarel benecio de la utilizaci on de una plataforma BPMSdepender a de conocer las potencialidades de la misma,entendiendoquees unnuevoparadigmaquemodicaelcl asico proceso de desarrollo de software.El pr oximodesafoesacoplar lasrecomendacionesac aplanteadas enunmarcode referencia para proyectos deimplementaci on de procesos, el cual permita que quiendise ne y ejecute la etapa de BPA, tome en consideraci on loselementos base para la futura implementaci on de procesos,y as lograr entregar la agilidad, eciencia y ecacia que ladisciplina BPM promete.REFERENCES[1] Morteza Alaeddini and A. A. Kardan. Using an old techniqueinanewtechnologyAnovel methodfor deningthescopeofISsinBPMprojects. ComputersandInformationTechnology, 2009. ICCIT 09. 12th International Conferenceon, 2009.[2] S. Azzopardi. Evolution of project management, August2011. http://www.projectsmart.co.uk/.[3] J orgBindner andGunther Mayer-Leixner. Differences inbusiness process management between global players andmicroenterprises - experiences frompractice. InWernerSchmidt, editor, S-BPMONE-LearningbyDoing-DoingbyLearning, volume213of CommunicationsinComputerand Information Science, pages 256270. Springer BerlinHeidelberg, 2011.[4] A. Fox and D. Patterson. Engineering Long-Lasting Software:An Agile Approach Using Saas and Cloud Computing, AlphaEdition. Strawberry Canyon LLC, 2012.[5] Mara Consuelo Franky. Agile management and developmentof software projects based on collaborative environments.SIGSOFT Softw. Eng. Notes, 36(3):16, May 2011.[6] Standish Group. The standish group: The chaos report 2011,August 2011. http://blog.standishgroup.com.[7] Bernhard Hitpass.BPM Fundamentos y Conceptos de Imple-mentaci on. BPM Center, 2012.[8] J. Jeston and J. Nelis. Business Process Management:Practical GuidelinestoSuccessful Implementations. Taylor& Francis, 2012.[9] Ryan K. L. Ko. A computer scientists introductory guide tobusiness process management (bpm). Crossroads, 15(4):4:114:18, June 2009.[10] Michael zur Muehlen Maggie Bin Lai. Information Require-ments of Process Stakeholders- A Framework to Evaluate Pro-cess Monitoring and Controlling Applications. ICIS workshopon Process Management, 2004, 2004.[11] OliveraMarjanovic. Insideagileprocesses:Apractitionersperspective. In HICSS, pages 110, 2009.[12] E. Mathisen, K. Ellingsen, andT. Fallmyr. Usingbusinessprocess modelling to reduce the effects of requirementschanges in software projects. In Adaptive Science Technology,2009. ICAST2009. 2ndInternational Conferenceon, pages14 19, jan. 2009.[13] Bjoern Niehaves and Jorn Henser. Business process manage-ment beyond boundaries? - a multiple case study explorationof obstacles to collaborative bpm. In Proceedings of the 201144thHawaii International ConferenceonSystemSciences,HICSS 11, pages 113, Washington, DC, USA, 2011. IEEEComputer Society.[14] Brent Hailpern Peri Tarr, Clay Williams. Toward Governanceof Emergent Processes andAdaptive Organizations. IBMResearch, 2008.[15] K. Schwaber andM. Beedle. AgileSoftwareDevelopmentwith Scrum. Prentice-Hall, 2001.[16] Venky Shankararaman and Pervez Kazmi. Unifying ea, bpmand soa through a synergestic framework. E-CommerceTechnology, IEEEInternational Conferenceon, 0:286293,2011.[17] Keith Swenson. Bpm is not software engineering, November2008. http://social-biz.org/.[18] W. Wood. Best and worst practices in bpm and soa, August2011. http://www.club-bpm.com/.