lunes, 31 de enero de 2011

Crowdsourcing Vs. Criminalidad, una vuelta de tuerca a la "colaboración ciudadana"

El crowdsourcing tiene aplicaciones que van mucho más allá de aquellas que he explicado en post anteriores (alquiler de vehículos, espacio de oficina, soluciones a problemas técnicos, test de productos, iniciativas políticas, etc...) hay una que me ha llamado mucho la atención en los últimos tiempos: la solución de crímenes y la lucha contra la delincuencia.

Un buen ejemplo, aunque muy triste, es el caso del asesinato de la joven de 25 años Joanna Yeates, esta arquitecta desapareció el 17 de diciembre del año pasado a la salida de un pub en un pueblo de las cercanías de Bristol y su cuerpo fue encontrado la mañana del día de navidad por una pareja que paseaba a su perro por una carretera comarcal en la localidad de Failand. 

Sólo tres días después de su desaparición la policía (The Avon & Somerset Constabulary) alertó a la población sobre la desaparición de Joanna y les pidió su colaboración por si la habían visto y para ello colgó imagenes de un vídeo de una tienda (visitado por unas 120.000 personas) por la que la Joanna había pasado el día de su desaparición así como una foto suya. Conforme pasaban los días la policía fue añadiendo más información en su web y cuando el cuerpo de la infortunada joven fue encontrado construyó un microsite en el que se desarrolló una clara estrategia de crowdsourcing:
  1. Se solicitó la ayuda de los ciudadanos que hubiesen podido ver a Joanna en los últimos momentos antes de su desaparición y al tradicional número de teléfono se añadió una página en facebook para colgar mensajes con solicitudes de información sobre el asesinato.
  2. Se creó un canal en YouTube con vídeos e información sobre el caso, casi 39.000 reproducciones.
  3. En Google Maps se colgó un mapa en el que detallaban los últimos movimientos de Joanna y que fue visitado por más de 55.000 personas en apenas 3 semanas.
  4. Se dedicó un programa de televisión especial sobre el caso en la serie Crimewatch de la BBC en el que se reconstruían los últimos movimientos conocidos de Joanna, más de 300 personas llamaron a la policía al terminar el programa.
  5. La organización crimestoppers también se involucró en el caso, esta organización ha utilizado el crowdsourcing con gran éxito para identificar a conocidos delincuentes británicos que vivían en España.


A todo esto se unió el "circo" de los medios de comunicación lo que me temo que distorsiona el crowdsourcing en este tipo de casos, la denominada "colaboración ciudadana" siempre ha existido pero las herramientas de las TIC pueden llevarla a extremos de los que todavía no somos plenamente conscientes, ¿veremos organizaciones como Crimestoppers en España?, quizás se resuciten en nuevos formatos programas como ¿Quíen Sabe Dónde?. De lo que no estoy tan seguro es de que la policía española tenga una estrategia 2.0 para obtener la ayuda de los ciudadanos, al menos su site de colaboración ciudadana me parece cuando menos limitado, poco atractivo y con escasa información para que los usuarios sepan como colaborar y no definen los casos más urgentes en los que la colaboración inmediata es imprescindible, simplemente se les indica que cumplimenten un formulario.

Para terminar, comentaros que el caso parece haberse resuelto con la detención de un ingeniero holandés de 32 años vecino de la joven arquitecta, ahora la familia y amigos del acusado que claman por su inocencia han comenzado a usar los medios para defenderle. Según la policía la pista definitiva vino de una llamada de una mujer que había visto el programa Crimewatch.

Un poco de Project Management: el ABC de las Request For Proposals (RFP)

De la sopa de letras de la familia de las RF.. (RFI, RFQ, RFP,..) vamos a ocuparnos hoy de la más importante de todas cuando hablamos de proyectos (lo que obviamente incluye los proyectos de outsourcing), se trata de la Solicitud de Propuesta, en inglés Request For Proposals, o RFP.

En los proyectos externos es habitual que en determinados tipos de empresas (generalmente las más grandes y con un sistema de compras o incluso de licitaciones ya desarrollado) nos encontremos ante el momento de la verdad, se nos ha invitado a licitar en un proyecto para el cliente en cuestión. 

Se trata pues de una solicitud formal (cuando no es así se suele tratar de proyectos internos) para que presentemos una propuesta al cliente, éste nos pide mucho más que que le coticemos un precio por el servicio o el producto (esto iría más en la línea de la RFQ o Request For Quotation) y que responde a una serie de pautas:
  • Se nos va a proporcionar una descripción del trabajo, lo que nos lleva al alcance del proyecto.
  • Incluye los requisitos del cliente, que determinan las especificaciones y los atributos del proyecto.
  • Se especifican los entregables que el cliente espera.
  • Muestra una relación completa de los artículos tanto a suministrar como a recibir del cliente.
  • Se listan las aprobaciones requeridas por el cliente en cada unos de los hitos del proyecto de cara a las correspondientes certificaciones.
  • Tipología del contrato (precio cerrado, time & material, costes reales,...).
  • Condiciones de Pago.
  • Proporciona instrucciones para el formato y contenido de las propuestas de los contratistas, se les suele requerir que documenten detalles sobre la historia de su empresa, sus capacidades financieras (balances, cuentas de resultados, avales bancarios), sus capacidades técnicas (equipamiento, maquinaria, RRHH) y su experiencia (casos de éxito en proyectos similares así como certificaciones y habilitaciones). Además se señala una fecha límite para la presentación de propuestas.
  • Normalmente se incluye una lista de criterios de evaluación (experiencia, equipamiento, equipo humano, programa de trabajos, razonabilidad de los costes,...) además de un mecanismo de comunicación con el cliente de cara a la formulación de preguntas o solicitud de aclaraciones sobre el contenido de la RFP (todo ello con sus correspondientes plazos y formularios).
  • Incluso puede llegar a determinar de qué fondos dispone el cliente como máximo para llevar a cabo el proyecto.
Este tipo de estructura de las RFP lleva usándose mucho tiempo, las nuevas tecnologías han supuesto la simplificación del proceso de las RFP, en los entornos B2B este tipo de solicitudes se repiten a menudo y los contratistas ya están "clasificados" por lo que la información básica (financiera, técnica y de experiencia) no se ha de entregar una y otra vez (solamente ha de actualizarse) y el proceso de preguntas así como el de entrega de ofertas es mucho más sencillo.

No es menos cierto que si un contratista juega bien sus bazas puede hacer algo de marketing previo a la RFP, por ejemplo, si conoce bien al cliente y al equipo directivo del mismo puede saber de los rasgos principales de las RFP que estén por salir e incluso puede ir más allá y asesorar al cliente a identificar las necesidades a cubrir mediante la RFP y como solventarlas.  Ni que decir tiene que muchas veces ni se llega a lanzar la RFP o se hace simplemente "de cara a la galería", no es raro que esto pase en contratos de outsourcing en los que ya hay contratistas trabajando, es la búsqueda constante de reiterar ventas a un mismo cliente.

Si al final no hemos sido capaces de hacer movimientos previos a la RFP y nos vemos ante el dilema de licitar o no licitar (lo que siempre es una decisión en términos de tiempo y dinero) deberíamos tener en cuenta los siguientes factores:
  1. Competencia (ventajas competitivas, vínculos con el cliente, etc..).
  2. Riesgo (financiero y técnico).
  3. Ampliación de capacidades (supondrá atacar proyectos más grandes de los que habitualmente realizamos).
  4. Reputación (qué éxitos/fracasos hemos tenido en anteriores RFP con el cliente).
  5. Fondos del cliente para el proyecto (algo muchas veces difícil de averiguar).
  6. Recursos de que disponemos para elaborar nuestra propuesta.
  7. Recursos de los que dispondríamos para ejecutar el proyecto, especialmente en lo que se refiere a RRHH propios y a subcontratas.
Licitar por licitar es un error, daña nuestro prestigio si nuestras propuestas son técnicamente débiles y nos quita toda credibilidad si realizamos "bajas temerarias".

Si nos hemos decidido por presentar nuestra propuesta hemos de tener claro un primer concepto, se trata siempre de un documento "vendedor" nunca de un sesudo informe técnico, lo que debe hacer es demostrar al cliente que nosotros como contratistas:
  1. Entendemos lo que él quiere y podemos llevarlo a cabo.
  2. Le proporcionaríamos el mayor valor posible para el proyecto en cuestión.
  3. Somos los mejores para solucionar su problema o necesidad.
  4. Aprovechamos nuestra experiencia exitosa en proyectos similares.
  5. Haremos el trabajo de forma profesional y lograremos los resultados deseados.
  6. Completaremos el proyecto dentro del presupuesto y de acuerdo al programa.
  7. Dejaremos satisfecho al cliente al finalizar el proyecto.
Siempre han de redactarse las propuestas con un estilo claro y conciso, siempre pareciendo realistas a los ojos del cliente especialmente en términos de alcance, costo y programa.

En el próximo post continuaré con el desarrollo de esta introducción a las RFP, especialmente en lo que se refiere a cómo desarrollar una propuesta ganadora o a consideraciones en torno a la fijación de precios.


sábado, 29 de enero de 2011

El Libro del Mes en Outsourceando: La Estrategia del Océano Azul




Este es un título que se ha comentado hasta la extenuación, así que os voy a dejar los power points de  un curso que dimos hace poco, para ser sincero entiendo la teoría de W. Chan Kim y Renée Mauborgne pero no estoy del todo seguro de su verdadera aplicación (el tiempo nos los dirá) aunque también es verdad que muchos de los principios de esta teoría se me han quedado grabados y los aplico cuando analizo un negocio o una oportunidad de negocio.

Aquí os dejo unos vídeos sobre esta "nueva" teoría de la estrategia empresarial, espero que el post de hoy os haya resultado de utilidad.




martes, 25 de enero de 2011

Productividad: nuestro problema

Cuadro tomado de un informe fruto de la colaboración entre Mckinsey y Fedea titulado "Una Agenda de Crecimiento para España", sin comentarios....

Jornada sobre Business Analytics en la Fundación Ramón Areces (24 de enero de 2011)

Si hace unos días acudía a un evento sobre BPM ahora le tocaba el turno a otro "hype", lo que para muchos es la evolución de la tan manida Business Intelligence (BI), a saber, la Análitica de Negocio o Business Analítics, BA para los amigos. Concretamente se trataba de una jornada en la Fundación Ramón Areces y la verdad es que la organización ha resultado impecable lo mismo que las instalaciones.



La jornada contaba con el apoyo del European Center por Soft Computing (ECSC) que es según su propia web un centro de investigación y desarrollo promovido por la Fundación para el Progreso del Soft Computing y ubicado en Mieres, Asturias. Sus objetivos son tanto la investigación básica y aplicada en el área del Soft Computing, como la transferencia de tecnología en aplicaciones industriales de diseño de sistemas inteligentes para la resolución de problemas reales. El ECSC también es conocido por su promoción de la enseñanza de postgrado en BA ya que conjuntamente con la Universidad de Oviedo organiza el Master on Soft Computing and Intelligent Data Analysis, el único en esta materia que se imparte en España.


La presentación de la Jornada corrió a cargo de Alfonso Novales Cinca (Catedrático de Economía en la Universidad Complutense de Madrid) y de Raúl del Coso López que es el Gerente del ECSC, este último definió la BA como la utilización del análisis inteligente de datos en entornos empresariales, frente al BI que estaría más en la línea de la extracción y reporting de datos.

A continuación comenzó una mesa redonda titulada "La importancia de análisis en la gestión empresarial" en la que actuó como moderador el profesor del IE Business School Salvador Aragón que la verdad estuvo bastante simpático al comentar "BA en estos momentos es como el sexo en la adolescencia, algo de lo que todo el mundo habla, poca gente practica y aquel que lo hace lo hace fatal" pero también recalcó que merecía la pena la inversión en bastantes casos.

El primero de los tres participantes en la mesa redonda fue Antonio Álvarez García (Experto en Soluciones Analíticas de Business Objects - SAP) que destacó lo siguiente:
  • Ahora con BA se busca el conocimiento del negocio verticalizado, hay que ir más allá de la BI.
  • La BA debe ayudar no sólo a las personas con más conocimientos técnicos sino a todas aquellas que puedan conseguir beneficios de la misma en la organización.
A continuación se presentó a Ignacio Poch (Director de Desarrollo de Negocio de SAS) para el que estamos viviendo el comienzo del adiós a la intuición como herramienta exclusiva para la gestión de empresas, ahora somos capaces de modelizar antes de tomar decisiones y, al fin, podemos aplicar el método científico. Ahora bien, no podemos utilizar la BA sin tener clara la estrategia competitiva de nuestra organización, esto que parece lógico es aún relativamente raro en las empresas y más raro aún es el esfuerzo por alinear la organización con la estrategia.

El tercer y último participante en la mesa redonda fue José Antonio Rubio (Gerente Senior de BA en Indra) que definió los siguientes puntos clave de la BA:
  • Ayuda a fomentar la cultura del análisis en la empresa.
  • Acelera el alineamiento en la organización.
  • Permite un ciclo continuo de mejora del rendimiento con vocación al largo plazo.
  • Incide en las áreas de mayor impacto en las organizaciones, aquellas que afectan a la cuenta de resultados y al cambio organizacional.
  • Tiene una fuerte orientación hacia la simulación y los sistemas expertos
A continuación comenzó un breve debate en el que se comentaron algunos temas de interés:
  • La aplicación de la BA en las PYMEs: todos los ponentes coincidieron en que de un modo o de otro tenía espacio en este tipo de empresas, la cuestión está en la estrategia de acceso que diseñen los grandes vendor acostumbrados a clientes muy grandes, las opciones pasan por la paquetización de soluciones y por el SaaS. Desde el público se hicieron preguntas sobre la utilidad de las aplicaciones Open Source de BA pero no hubo respuesta desde los ponentes, parece obvio que ese no ha sido ni será su negocio.
  • Cómo se puede alinear a la organización para que apoye a los proyectos de BA: con la "esponsorización" desde la alta dirección, la superación de la visión departamental por la visión holística de la BA, la definición de una estrategia empresarial clara, la mejora continua de procesos (y el correspondiente feedback), etc..
  • Cómo hacer BA de la BA, o lo que es lo mismo, cómo medir el ROI de la BA, obviamente es un problema tan antiguo como el management, pero los ponentes optaron por la postura de comparar resultados/performance (retención de clientes o de personal, ingresos, campañas de marketing, cross-selling, riesgos de crédito, etc..) antes y después de la implantación de la BA. En definitiva, ver el delta.
  • Dónde estamos en la curva del hype que es la BA, el consenso es que la demanda nacional aún es débil cosa que no sucede en el exterior, quizás en nuestro país queda mucho por hacer en BI y luego de arreglar los déficits en data warehousing y reporting se podrá avanzar hacia la BA. En el momento actual en España hemos pasado por una situación de "supervivencia" de las empresas, ya no se centran en calcular el beneficio de un decisión empresarial dada sino en definir y medir los riesgos asociados a la misma, aquí el papel de la BA es relevante.
  • Cuán necesaria es la BA: se destaca un estudio presentado por la MIT Sloan Management Review en el que se marcaban como retos principales de las empresas el logro de la diferenciación competitiva, la mejora de los ingresos, la reducción de costes y la mejora de la eficiencia, todo ello se puede lograr con un importante papel de la BA.
La BA es resultado de un proceso evolutivo:
  1. Mejora del producto (s. xix)
  2. Mejora del control de costes, fordismo (primera mitad s. xx)
  3. Mejora de la calidad de los productos, TQM (años 80)
  4. Reingeniería de procesos (1990)
  5. Estandarización de las aplicaciones de TI (1995-2000)
  6. CRM (2000-2010)
  7. BA (hoy)
En realidad este proceso evolutivo es el de la denominada Investigación Operativa, que nace con los conflictos bélicos y que tras la Segunda Guerra mundial va pasando de un sector a otro según van utilizando la probabilidad como herramienta de toma de decisiones, comenzando por las aseguradoras y los bancos y acabando por la logística o la gran distribución.

Cabe destacar que muchos de los casos de éxito mencionados en la mesa redonda fueron del sectores de banca y seguros, con alguna pincelada en telecomunicaciones y gran distribución, siempre en grandes empresas.

Tras el descanso comenzó una tanda de tres intervenciones de unos 15 minutos titulada genéricamente "Aplicaciones empresariales de nuevas técnicas de análisis" presentada por Wolfram Rozas Rodríguez de IBM Global Services y que versaron sobre los desarrollos matemáticos asociados a la BA, los ponentes fueron:
  • Óscar Cordón García del ECSC (Investigador Principal).
  • Francisco Herrera Triguero (Catedrático de la Universidad de Granada).
  • Helena Ramalhinho (Profesora de la Universidad Pompeu Fabra).
Los tres ponentes comentaron muy sucintamente los desarrollos matemáticos existentes detrás de los algoritmos de la BA, lo hicieron para tres áreas, a saber industria, finanzas y logística respectivamente, de los que podemos destacar los siguientes:
  • Lógica difusa.
  • Redes neuronales
  • Algoritmos evolutivos / genéticos y metaheurísticos (como los algoritmos de optimización basados en colonias de hormigas u OCH).
  • Razonamiento probabilístico.
Se superan los handicaps de la programación lineal para gracias a la capacidad de la informática actual de trabajar con enormes cantidades de datos afrontar problemas adicionales a la BA como serían la optimización, la planificación, o el modelado-predicción. Dicha capacidad de la informática viene dada no tanto por el desarrollo del hardware como por el del Soft Computing que permite el diseño de sistemas inteligentes para resolver problemas reales, trabajando con información imprecisa, incierta y/o incompleta.

Las ventajas del Soft Computing vienen de su habilidad para ofrecer soluciones:
  • Precisas.
  • Simples.
  • Baratas.
  • Con gran cantidad de aplicaciones reales.
Los casos prácticos que pudimos atisbar brevemente fueron algo más variados que en ponencias anteriores, así por ejemplo se comentaron aplicaciones de algoritmos de optimización a plantas de fabricación de motores (Nissan en Barcelona), a algunas cajas y bancos con problemas de riesgo de impagados como Caja Granada y Caja Navarra, ubicación de parques de bomberos en Barcelona, problemas de ruteo y redes logísticas, localización de ubicaciones óptimas para almacenes, proyecto de mejora de la localización de las administraciones de las loterías del Estado, etc...

El escaso tiempo del que disponían los ponentes unido a la complejidad de la materia hizo que para la mayoría de la audiencia allí presente el aprovechamiento de las ponencias fuese escaso, si bien, al menos personalmente, me parece un tema apasionante, pero sobre todo recalca la absoluta necesidad de incrementar la disponibilidad por parte de las empresas españolas de estadísticos y matemáticos no ya orientados hacia la universidad sino hacia los negocios.

La penúltima parte de la conferencia estuvo centrada en los denominados "casos de éxito en empresas", el primero de ellos tuvo como ponente a Rafael Álvarez Cuesta que es el Director de Information Management en Cajastur, caja que es uno de los principales apoyos del ECSC.

El Sr. Álvarez comenzó su ponencia con una cita y, curiosamente, con las conclusiones de lo que sería su presentación:
  • Un problema bien definido es un problema resuelto.
  • Hay que buscar siempre la adecuada combinación entre estrategia y tecnología (por este orden), éste es el secreto para poder alcanzar el éxito.
La verdad es que fue una presentación muy ágil y nada aburrida, para explicar la utilidad de BA nos puso como ejemplo una de mis películas favoritas "Atrapado en el Tiempo", puso la escena de la versión doblada al castellano pero no he podido encontrarla nada más que en inglés, en todo caso, Bill Murray nos demuestra como un buen data mining y la posterior analítica pueden llevarnos a algo que podríamos definir como un éxito.



Después de este simpático vídeo nos comentó brevemente la historia del BA en Cajastur con sus éxitos y sus fracasos, curiosamente Cajastur fue la primera empresa en España en adquirir SAS Enterprise Miner allá por el año 1995 y tras algún traspiés (minimizados por el esfuerzo en establecer un data warehousing de alta calidad) la utilización de la analítica se ha consolidado dentro de esta caja, hasta el punto que no compran consultoría en esta materia sino que tienen su propia oficina de consultoría interna en BA que presta servicio no sólo al área comercial (CRM) sino también al resto de áreas de la organización.

La arquitectura de proveedores de tecnología de BA en Cajastur es la siguiente:
  • Data Warehousing: Teradata.
  • Data Mining: SAS y Kxen
  • Acceso a la información: SAS y Business Objects
Los factores de éxito en el caso de Cajastur han sido:
  1. Quitar el liderazgo de estos proyectos a TI y llevarlo a las áreas de negocio.
  2. Un data warehousing único y sin errores.
  3. El software de SAS.
  4. Ser capaces de obtener talento analítico, no incorporando a los equipos perfiles de ingeniería o informática, sino otros más cercanos al negocio así como a la econometría, la estadística o las matemáticas. Se valoran los doctorados, cosa que el resto de las empresas no hace.
  5. Pagar bien a estos perfiles: "si pagas con cacahuetes tendrás monos", "si el talento te parece caro prueba con la mediocridad".
  6. Cuando se usan perfiles "científicos" únicamente pueden surgir problemas ya que tienden a buscar soluciones a los problemas siempre desde su área de especialidad, pero los problemas en los negocios suelen preferir un enfoque multidisciplinar.
  7. Establecer modelos de decisión claros y potentes: data mining, intelligent data analysis, soft computing, fuzzy logic.
Por otra parte, la mayoría de los fracasos en las implantaciones de BA vienen de:
  1. Desconocimiento de las posibilidades de la BA.
  2. Falta de apoyo de la alta dirección.
  3. ROI poco claro, hay muchos intangibles.
  4. Falta planificación y metodología.
  5. Falta adecuación de los procesos organizativos.
  6. Resistencia al cambio, la BA no es algo prioritario ya que hay que enfocarse en el día a día.
  7. Falta de los RRHH adecuados.
El segundo caso de éxito en la empresa que se nos presentó fue el de una consultora en BA, especializada en grandes superficies, la inglesa Dunnhumby que tenía como ponente a Giles Pavey.

La presentación comenzó con un vídeo muy interesante sobre cuál es el negocio de Dunnhumby, aquí lo tenéis:



El siguiente slide elaborado por mi en base a la presentación de Dunnhumby resume bastante bien la metodología de esta empresa:


En cuanto a casos de éxito mencionó sus principales clientes como Tesco, Home Depot, Best Buy, Macy's, Kroger, etc, principalmente en EE.UU. y Reino Unido.

El Sr. Pavey recalcó varias cosas:
  • Hay que centrase siempre en el consumidor, conocerlo mejor que la competencia y llevar ese conocimiento a la acción antes que ésta.
  • Debemos convencernos que si conocemos cómo la gente compra entenderemos mucho de sus necesidades y creencias, esto es la clave para cualquier negocio.
  • Las soluciones de BA deben ser simples pero no simplistas.
  • Una cosa es obtener respuestas desde el análisis de los datos y otra muy distinta poder aplicar ese conocimiento en el mundo real.
  • Siempre hay que pensar en el largo plazo.
Para este ponente la foto de abajo muestra el dilema que afrontamos con la BA, ¿cómo bebemos de un hidrante?, donde el chorro de agua a presión representa el enorme flujo de datos que han de gestionar las organizaciones.


La conferencia de clausura la impartió el investigador danés Gert H. N. Laursen (Director de BA en la naviera Maersk Line) y se titulaba "Information strategy: achieving corporate objectives using analytics to create knowledge", se da el hecho de que estoy preparando un post bastante amplio sobre el último de sus libros publicados titulado "Business Analytics for Managers: Taking Business Intelligence Beyond Reporting" y además buena parte de su conferencia versó sobre dicho titulo por lo que en pocos días os proporcionaré un buen resumen de las opiniones de este autor que está teniendo gran éxito con sus publicaciones.

Sólo recalcar una "perla" de la conferencia de Laursen: no todo es matemáticas, muchas veces basta con el sentido común del analista y su conocimiento del mercado, pero siempre trabajando con datos.

Se cerró la jornada con unas breves palabras del Director de la Fundación Ramón Areces D. Raimundo Pérez-Hernández y Torra, donde se centró en recordar al auditorio cuál es el principal problema de la economía española, la incapacidad de lograr el crecimiento económico a través de mejoras en la productividad, muerto el modelo del ladrillo hay que replantearse las cosas, y el papel tanto de BI como de BA es fundamental, en el mundo en que vivimos (y en el que competimos) con la intuición de los directivos no nos alcanza para salir de la crisis.


miércoles, 19 de enero de 2011

Evento BPM España 2011 - Habber Tec / IBM Lombardi

Este martes 18 de enero, hemos tenido el placer de acudir al evento "BPM España 2011" organizado por la consultora Habber Tec  en el Hotel Hesperia de Madrid, donde nos han comentado algunos de los principios básicos del BPM como filosofía de management pero, sobre todo, como software, ya que Habber Tec es partner de IBM y la finalidad del evento era presentar su producto WebSphere Lombardi Edition.



Tras una breve introducción por parte de los Directores de Habber Tec y Lombardi pasamos a la primera presentación que tenía como ponente a Leonardo Vieiralves a la sazón Director General de Habber Tec Brasil y se titulaba "justificación económica de un proyecto de BPM".

Han sido 30 minutos muy interesantes dedicados a comentar varios estudios de consultoras como Gartner y Mckinsey.

Para Mckinsey en su "2009 Exec Survey" las dos prioridades principales de los CIOs son:
  1. Mejorar la eficiencia de los procesos de negocio.
  2. Mejorar la eficacia de los procesos de negocio.
Queda clara la relevancia de tecnologías como el BPM según este estudio.

Por lo que a Gartner se refiere el ponente nos ofreció dos estudios, el primero de ellos "Leading in Times of Transition: The 2010 CIO Agenda" consideraba que perfeccionar procesos de negocio fue la acción más demandada de las áreas de negocio en relación a TI desde el comienzo del estudio en el 2005 y que casi el 57% de los CIOs (respondieron 1.586 de estos directivos de empresas globales) eligieron la mejoría de procesos como su prioridad número uno y consideran que dicha tendencia se mantendrá al menos hasta el 2013.

El segundo estudio de Gartner era mucho más específico, tal y como su título indica "Justifying BPM Projects 2009" cuyas notas más importantes serían:
  1. El 90% de los proyectos de BPM fueron exitosos, se habla de éxito cuando la tasa de retorno interno del proyecto es del 10% como mínimo, aquí no iremos más allá ya que desconocemos como se hace dicho cálculo exactamente.
  2. El 78% de los proyectos de BPM tuvieron una tasa de retorno superior al 15%.
  3. El 50% de los proyectos duran menos de 4 meses y el 67% menos de 6 meses.
  4. El 77% de los proyectos tuvieron un retorno superior a los 100.000$.
  5. El valor percibido por las compañías respecto al BPM fue superior al percibido respecto a ERP, CRM y SCM.
El Sr. Vieiralves terminó su exposición con un caso clásico de aplicación del BPM como es el de su aplicación a los procesos de peritaje de seguros del automóvil, la empresa en cuestión fue la aseguradora brasileña HDI (https://www.hdi.com.br/2010/index.php).

A continuación fue el turno de Juan Manuel García López del Departamento de Business Development de WebSphere (IBM) cuya presentación se titulaba "BPM y Sistemas de Gestión de Reglas", el tema parece evidente, la aplicación de la automatización de las reglas de negocio, en este caso mediante la plataforma de IBM WebSphere ILOG JRules.

La presentación se centró en la idea de que la utilización de ILOG en conjunción con Lombardi proporcionaba un BPM "más inteligente", lo que se traduce en:
  1. Eliminación de obstáculos a la agilidad con el beneficio de una puesta en marcha más rápida cuando se producen cambios (en regulaciones, leyes, ordenanzas, cambios de criterios) que afectan a las reglas de negocio.
  2. Reducción de la intervención manual lo que supone mayor transparencia, control y coherencia.
  3. Disminución de la carga de trabajo en IT con la consiguiente reducción de costes.
La reducción de costes venia dada más concretamente por:
  • La reducción del desarrollo y mantenimiento de las aplicaciones.
  • El aumento del procesamiento directo.
  • La mejora de la conformidad con las regulaciones.
E incluso podría producirse una cierta generación de ingresos en virtud de una puesta en producción más rápida y una relación con el cliente más personalizada.

Tras el reglamentario "Coffee Break" pasamos a la última parte del evento que comenzó con una introducción a IBM Lombardi por Ricardo Argüello (Director de Desarrollo de Negocio de Habber Tec), podemos destacar estas dos slides de su presentación:



Continuó el Sr Argüello con una serie de casos de éxito como Pfizer, Ford, Wells Fargo, etc.. pero no se mencionó por su nombre ningún cliente español si bien si se describieron algunos casos de éxito en el sector inmobiliario, en utilities y en banca.

Luego se procedió a una demostración de Lombardi por el especialista de producto de Habber Tec (Sr. Azorín), aquí un resumen puede hacer poca justicia a lo que vimos así que al final de este post incluiremos un vídeo que os pueda dar una idea de lo que fue esta parte del evento.

En todo caso, aquí tenéis un par de slides sobre la arquitectura del Lombardi:



El evento finalizó con un caso real de implantación de BPM, concretamente en el banco Rabobank Brasil, presentado por un "Senior Executive" del mencionado banco, el Sr. José Benicio Oliveira. Su ponencia, que contó con traducción simultánea al español, fue un colorido relato de cómo la implantación de un BPM ha cambiado completamente el funcionamiento del banco tras varios fracasos en la implantación de proyectos de TI enfocados a la modernización de los procesos del banco. Lo más relevante de esta intervención fue el hecho de que nos recordó la absoluta necesidad de un apoyo a este tipo de iniciativas desde la más alta dirección y el imprescindible liderazgo asociado a la gestión del inevitable cambio cultural propio de estas implantaciones.
Tal y como os comentábamos antes y para finalizar os dejamos un vídeo de la plataforma para BPM WebSphere Lombardi Edition, que es muy parecido a la demostración que nos han hecho hoy, el ejemplo en nuestro caso ha sido relativo al área de compras mientras que en el vídeo se refiere a RRHH.

domingo, 16 de enero de 2011

Crowdsourcing: Instituto Tecnológico Metalmecánico (AIMME) - Premios Internet 2011

Aquí estamos otra vez hablando del crowdsourcing, hace unas semanas os mostraba una estupenda  iniciativa de crowdsourcing del Instituto Tecnológico Metalmecánico (AIMME) pues bien, cosas de las redes sociales, ahora me entero de que se presenta la candidatura de dicha iniciativa a los Premios Internet 2011 de la Asociación de Usuarios de Internet y me parece que al menos se merece un repaso del mencionado post así como la posibilidad de vuestro voto.

Os dejo unos links:





P.D.: Un saludo para Santiago Bonet

martes, 11 de enero de 2011

¿Qué es el Business Process Management? - Una introducción al BPM (Segunda Parte)

Tal y como comentaba en las últimas líneas de mi post anterior, comenzaré éste mencionando los beneficios que ha supuesto para la empresas la adopción del BPM y que, entre otros, son:
  1. Operar con menos costes (algo razonable desde el punto y hora en que al trabajar con procesos "end to end" se superan las barreras departamentales eliminando costes de estructura inútiles) además el trabajo se hace de un modo más rápido y eficiente.
  2. Se favorece una mayor capacidad para responder a los cambios repentinos en el mercado frente a la metodología tradicional, para ello utiliza las métricas de control de rendimiento de los procesos frente a la insuficiencia de las métricas estrictamente financieras que adolecen de un obvio decalaje temporal.
  3. Proporcionar un "paraguas" para una amplia serie de iniciativas dedicadas a mejorar el rendimiento de una organización tales como la implantación de un ERP, un BI o una plataforma de B2B e incluso favorecer la transición en un proceso de fusión. Estas situaciones tradicionalmente se han tratado como fenómenos independientes lo que se ha traducido en descordinación, problema que se soluciona gracias al enfoque global propio del BPM.
Pese a todas estas ventajas y a los logros conseguidos por muchas empresas al usar el BPM hay otras muchas organizaciones que no consiguen alcanzar éxitos parecidos, la razón estriba en que éstas últimas  no tienen un management o una cultura empresarial que congenien con la gestión por procesos y a menos que cambien dicha situación no dejarán de fracasar a la hora de implantar el BPM.

Para lograr el éxito a la hora de implantar procesos de alto rendimiento hay 5 "activadores" indispensables:
  1.  Diseño de los procesos, sin él lo único que se obtiene es una actividad de tipo individual descordinada con el resultado del caos organizacional.
  2. Métricas de procesos: las métricas funcionales son insuficientes, hay que ir más allá para cubrir los procesos por completo, los objetivos se deben fijar en base a dichas métricas y el rendimiento controlado a través de las mismas. Además, las métricas deben estar equilibradas para que mejoras en una parte de un proceso no enmascaren problemas en otras partes del mismo.
  3. El personal que ejecuta el proceso: las habilidades que necesitan son diferentes de las del personal en una empresa con una gestión más convencional, estos trabajadores han de entender el proceso en cuestión y sus objetivos además de ser capaces de trabajar en equipo al tiempo que actúan de un modo proactivo e independiente.
  4. Las infraestructuras de los procesos: el personal debe obtener un apoyo adecuado de las funciones de TI y de RRHH.
  5. La existencia de la figura del "dueño" del proceso: en una empresa que no aplica la metodología del BPM un proceso "end to end" no tiene un responsable (luego carece de un gestor), si se implanta el BPM la figura del dueño del proceso (por lo general un gerente senior) se torna esencial.
Es evidente que  no todas las empresas son igual de capaces de disponer de estos "activadores", ¿por qué aparece esta carencia?, la respuesta está en si la empresa dispone o no de una serie de capacidades críticas:
  • Liderazgo: ni más ni menos que la completa implicación de la alta dirección.
  • Cultura: el BPM suele verse como una amenaza para muchos "reductos de poder" dentro de la empresa, la razón es que exige poner al cliente primero, trabajar en equipo, compartir información y asumir responsabilidades, se trata de un perfil de trabajador con un nivel de madurez dificil de encontrar en las organizaciones que, de hecho, suelen favorecer lo contrario, especialmente en los niveles gerenciales.
  • Gobernanza: deben existir mecanismos que asignen responsabilidades e integren procesos (evitando "silos" funcionales), además se hacen indispensables figuras organizativas como la "Oficina de Procesos" (un departamento mucho más necesario que otros muchos en una empresa que trabaja con BPM) o el "Comité de Procesos" en él que los "dueños" de los procesos y la dirección alineen los mismos con la estrategia (mediante el lógico feedback) y marquen prioridades.
  • Conocimientos y experiencia: implementar y gestionar procesos es una tarea muy compleja en la que las empresas se juegan mucho. Se necesitan expertos en diseño de procesos, métricas, gestión del cambio, etc..., además muchas organizaciones fallan al desarrollar e institucionalizar estas capacidades (planes de carrera, formación, compensación y beneficios, etc..) y luego se encuentran con que no pueden alcanzar los ambiciosos objetivos que marcan a sus programas de BPM.
De estas cuatro capacidades críticas la más importante con diferencia es el liderazgo, simplemente es imposible lograr la implantación de procesos de alto rendimiento sin la figura del líder catalizador dentro de la organización, la gestión del cambio (cultura) al contrario de lo que se piensa no es un imposible si bien requiere tiempo y energía, los otros dos son mucho menos dificiles de alcanzar si bien suelen obviarse.

También puede resultar de utilidad mencionar una serie de axiomas que sirven para de base para el BPM:
  • Cualquier trabajo forma parte de un proceso: el BPM se puede aplicar tanto a tareas altamente estructuradas de tipo transaccional (pedidos, atención al cliente, etc..) como en otras mucho menos definidas y que se caracterizan por la creatividad tal y como sería el caso del desarrollo de productos. Hay que destacar que existen tres tipos de proceso, los procesos "core" que crean valor para el cliente y son esenciales para el negocio, los procesos de soporte (TI, reporting,..) y los procesos asociados al gobierno de la empresa (planificación estratégica, risk management, etc..).
  • Cualquier proceso es mejor que ningún proceso.
  • Un buen proceso es mejor que un mal proceso.
  • Una versión única de un proceso (estandarización) es mejor que varias.
  • Incluso el mejor de los procesos debe ejecutarse de un modo efectivo.
  • Un buen proceso siempre puede hacerse mejor.
  • Cualquier buen proceso puede convertirse en uno malo.
En el inicio de cualquier proyecto de BPM está la utilización el denominado Enterprise Process Model o EPM (Modelo de Procesos Empresariales) que es una representación gráfica de los procesos de la empresa ("core", soporte y gobierno) que muestra las interconexiones de dichos procesos así como sus inputs y outputs. Un EPM efectivo debe ser simple, suele caber en una sola hoja y no suele incluir más allá de 5 - 10 procesos "core", posteriormente esta representación se desagrega en subprocesos que a su vez se dividen en actividades.

Aunque no existe un estándar definitivo de EPM si parece que está ganado aceptación la denominada Business Process Modeling Notation (BPMN) o Notación para el Modelado de Procesos de Negocio y su  UML (Unified Modeling Language), para no alargarme en demasía intentaré volver a esta notación un próximo post, por si alguien quiere saber más os dejo la web del Object Management Group que es el organismo que se ocupa de este proceso de estandarización desde el 2005: http://www.omg.org/.

Y como una imagen vale más que mil palabras también dejo algunos vídeos explicando el UML  (muy centrados en la informática) que además sirven para ambientar cualquier discoteca que se precie:







Músicas aparte, la verdad es que pese a sus éxitos el BPM apenas está saliendo de su infancia y muchas compañías que están implementándolo están lejos de terminar esta evolución además la gran mayoría de las empresas (hablamos de sectores o industrias enteras) ni han llegado a plantearse el BPM como una opción.

Todavía quedan muchas cuestiones por despejarse entorno al BPM, para muestra unas pocas:
  • Tiene un impacto enorme en las estructuras de gestión y en la definición de los niveles de responsabilidad en las empresas, cuando hablamos de "dueño" de un proceso no estamos pensando en la figura clásica del director de un departamento, muchas cosas han de cambiar, el primer movimiento lo vemos en la aparición de los centros de servicios compartidos, mucho más afines a la figura del "dueño" de procesos.
  • Los "dueños" de los procesos empizan además a tener responsabilidades en la gestión de las bases de datos de la empresa, cómo se adaptarán los ERPs, CRMs, BIs, etc.. al BPM todavía no está claro.
  • Los procesos ya no se desarrollan "end to end" dentro de una sóla compañía, la subcontratación en la cadena de suministro está totalmente generalizada, es ese tipo de esquemas se tendrá que definir quién es el "dueño" de un proceso.
  • Cómo va a evolucionar el outsourcing en relación al BPM, lo que conocemos como Business Process Outsourcing (BPO), cuando deje de ser "hype" (cosa que está comenzando a suceder) ¿veremos procesos de consolidación empresarial?, ¿de qué países serán estas empresas?.
  • ¿Se producirán cambios en la forma en la que definimos los sectores o industrias a consecuencia del impacto del BPO?
Espero que esta introducción os resulte de utilidad como primer paso para adentraros en el mundo del BPM y quedo a vuestra disposición para cualquier duda o comentario que tengáis.

domingo, 9 de enero de 2011

¿Qué es el Business Process Management? - Una introducción al BPM (Primera Parte)

Para comenzar el año 20101 he escogido una temática que ha sido una de las constantes de los últimos años en el mundo del outsourcing, la denominada Gestión de Procesos de Negocio o BPM (Business Process Management), sobre la que creo hay ciertas confusiones, algo de teoría y bastante menos práctica.

La verdad es que aunque el BPM es una disciplina del management bastante reciente y aún por consolidar se puede decir sin temor a equivocarse que el primer esfuerzo teórico sobre los procesos lo tenemos en la obra de Taylor aunque estrictamente podemos decir que son dos antecedentes del BPM:
  1. El trabajo de Schewhart y Deming sobre el control estadístico de procesos que llevaría al desarrollo del movimiento moderno de control y gestión de la calidad, que evolucionaría hacia el TQM en los años 80 del siglo pasado y posteriormente al Six Sigma
  2. La reingeniería de procesos (BPR) de los años 90 se centra en el diseño de procesos más que en la ejecución de los mismos (en lo que se centra la calidad) y establecía que el rendimiento de un proceso venía determinado por su diseño, si el rendimiento exigido a un proceso es mayor de lo que el diseño del mismo permite debe ser sustituido por otro.
Del TQM el BPM toma una serie de conceptos básicos:
  • Las operaciones son un factor decisivo de éxito para la empresa y merecen la máxima atención por parte del management.
  • El uso de métricas para medir el rendimiento de cada proceso.
  • El foco debe ponerse en los datos antes que en la opinión.
  • La culpa de los fracasos es de los procesos no de las personas que los llevan a cabo.
  • Los problemas de rendimiento en un proceso dado tienen siempre causas objetivas y se pueden solucionar.
  • La idea de "mejora continua".
Del BRP toma el BPM un cierto concepto de "proceso", que sería un conjunto de tareas "end to end" que atraviesan la empresa y que se caracteriza por crear valor para el cliente.

Si se prefiere, se puede definir el BPM como el logro de los objetivos de una organización a través de la mejora, gestión y control de los procesos de negocio esenciales o también como la disciplina dentro del management enfocada en la mejora del rendimiento empresarial mediante la gestión de los procesos de negocio de la empresa.

A principios de este siglo ambas aproximaciones (TQM y BRP) convergieron en lo que conocemos como BPM, un sistema integrado de gestión del rendimeinto de los negocios basado en la administración de negocios, gráficamente sería algo como lo siguiente:


El gráfico parte de la creación de un proceso formal de negocio, algo que no es tan fácil como parece ya que hay procesos con un nivel bajo de actividad y muy creativos como sería el desarrollo de productos en los que el sobresfuerzo y la improvisación sustituyen a la disciplina de un proceso bien definido.

Una vez que disponemos del proceso éste deber ser gestionado, su rendimiento medido y comparado con unos objetivos previamente marcados.

Si el mencionado rendimiento (que puede venir definido por las expectativas del cliente, las necesidades de la empresa, el benchmarking con competidores, etc...) no se alcanzase la causa sería:
  1. Un problema de diseño de proceso.
  2. Un problema de ejecución del proceso.
Las causas de los problemas de ejecución son dificiles de identificar (recursos insuficientes, falta de formación, problemas de  comunicación, liderazgo, fallos de equipo, etc...) pero fáciles de solucionar una vez localizados dichos los problemas, mientras que con los problemas de diseño pasa lo contrario, son fáciles de localizar pero muy difíciles de solucionar ya que hay que repasar toda la estructura del proceso en cuestión.

Como mencionamos anteriormente, el rendimiento se logra por medio de la gestión de procesos de negocio (end to end) que generan valor para el cliente, se trata, por lo tanto, de una metodología de gestión centrada en el consumidor y que supone que:
  • La gestión del rendimiento de la organización no se gestiona ya a través del método de prueba y error.
  • No hay que forzar el rendimiento de las personas como única salida para mejorar el rendimiento de los procesos.
  • El rendimiento de la organización tampoco se logra mediante la "manipulación" o ingeniería financiera.
Esta claro que al cliente le dan igual muchas cosas que dentro del funcionamiento interno de cualquier organización se consideran básicos (estrategia, estructura de capital, organigramas, etc...), lo que realmente le preocupa es una única cosa: resultados.

Los resultados no son el producto del genio en estado puro de unos directivos extraordinariamente bien pagados, son simplemente el resultado de procesos de negocio (secuencias de actividades) llevados a cabo por gente normal.

Clientes, resultados y procesos son el triángulo que define la "seriedad" de una organización, no basta en centrarse en uno sólo de dichos ángulos hay que hacerlo en los tres.

No basta con tener un buen diseño de un proceso, ésto es sólo el comienzo y no garantiza el éxito ya que los problemas son parte del día a día del mundo real (averías de equipos, problemas de formación, corrupción de datos, etc...). Lo que hace una organización que trabaja con el BPM es usar la gestión de procesos para monitorizar el rendimiento de los mismos y reconocer y corregir tales problemas, así como para aprovechar las oportunidades que aparezcan para modificar el diseño de los proceso y aumentar su rendimiento.

En definitiva, se hace obvia la influencia del famoso "Ciclo de Deming" o PDCA (Plan Do Check Act) lo que nos lleva a hacer una consideración que tiene su razón de ser en un error muy común, el pensar que el BPM es una herramienta tecnológica cuando no lo es. El BPM es una rama del management que puede ser perfectamente útil sin usar tecnología alguna. Es muy peligroso para una organización pensar que con disponer de un software de modelado de procesos todos sus problemas estarán resueltos y el BPM implementado, nada más lejos de la realidad, de poco sirven dicho programas informáticos sin la metodología del BPM o careciendo del apoyo de los directivos.

Así que el BPM se utiliza, como otras muchas otras siglas que nos encontramos en el mundo del management, de modos muy diversos:
  • Como una solución tecnológica para la automatización de procesos.
  • Como un software de modelado de procesos.
  • Para algunos consultores es una nueva sigla mágica que oculta la más tradicional reingeniería de procesos.
  • Para algunos directivos es simplemente la última tendencia a la que adherirse para que parezca que están "a la última".
  • Hay analistas de procesos que utilizan el BPM para "inflar" sus aspiraciones para modelar procesos.
En un próximo post continuaré con esta breve introducción al BPM hablando de sus ventajas así como de sus problemas.