Gestión por funciones vs. Gestión por procesos

Pasar de la gestión por funciones a la gestión por procesos, no resulta fácil, como señala el artículo de referencia, es una tarea progresiva dónde el BPM (Business Process Management) es de gran ayuda y fundamental desde las primeras implementaciones.


Muchos productos o servicios se pueden copiar sin mayor dificultad, pero algo pasa, porque los resultados comerciales no se aproximan a  los del original.  En la mayoría de los casos, la explicación esta dada en todo lo que rodea a un producto o servicio: los procesos.

Esta demostrado en las grandes marcas, que la clave de su éxito no está en la producción, lo que en muchos casos es lo primero que se externaliza, sino en todas las actividades que se realizan antes, durante y después de la elaboración y comercialización del producto, tales como el diseño, gestión logística, marketing o servicios post venta.  Lo que se trata, es lograr ventajas competitivas a través de los procesos clave que aporten valor, ventajas duraderas que se basarán en la mejora continua de los procesos.

Pasar de la  gestión por funciones a la gestión por procesos, no resulta fácil, como señala el artículo de referencia, es una tarea progresiva dónde el BPM (Business Process Management) es de gran ayuda y fundamental desde las primeras implementaciones.

Referencia: SAP SDN

Los Test de Stress repuntan el software de gestión de riesgo

Las pruebas de resistencia o “stress test”, mecanismo por el cual se constata la solvencia de las entidades financieras, no es un nuevo “invento”, sino que en el panorama de incertidumbre actual, donde los mercados exigen máximas garantías, las entidades regulatorias se has visto obligadas a la publicación de los resultados de estas pruebas.


Las pruebas de resistencia o “stress test”, mecanismo por el cual se constata la solvencia de las entidades financieras, no es un nuevo “invento”, sino que en el panorama de incertidumbre actual, donde los mercados exigen máximas garantías, las entidades regulatorias se has visto obligadas a la publicación de los resultados de estas pruebas.

¿Qué es un test de stress?

Estas pruebas consisten en la definición de escenarios críticos, donde los principales parámetros configuran un deterioro general de la economía, evaluándose como repercute, en la entidad financiera evaluada, el impago de créditos, devaluación de inversiones o deterioro de activos como los inmobiliarios, identificando la capacidad de la entidad para superar estos escenarios adversos con sus propios recursos (capital más reservas, beneficios no distribuidos, participaciones, etc.) y hacer frente a las inversiones de riesgo (créditos concedidos, acciones u otras operaciones)

Oportunidad para el Software de Gestión de Riesgo

Para superar estas pruebas, las entidades financieras deben estar preparadas, para ello requieren de herramientas informáticas que les permitan definir escenarios con los parámetros exigidos, los cuales pueden variar en el tiempo, pero por sobre todo, requieren una alta capacidad de procesamiento.

Esta necesidad es una oportunidad para empresas de nicho, especializadas como MathWorks, que están viendo un incremento en la demanda de sus productos.  SAS, por su parte, quiere aprovechar la oportunidad, dando una respuesta inmediata con soluciones como High-Performance Risk, una herramienta que ofrece una alta capacidad y velocidad de respuesta, basada en procesamiento in-memory.

Empresas como SAP, Oracle o IBM, también presentan sus cartas para el software de gestión de riesgo, basadas en sus soluciones de Business Intelligence adaptadas, pero que quizás, tengan poco que contar para los test de stress, donde la velocidad de respuesta con altos volúmenes de datos, es el principal factor a tener en cuenta.

Referencias:

Principios básicos para seleccionar un implementador BI

Los aspectos de mayor relevancia en la adopción de una determina Tecnología de la Información (TI) es la selección de la herramienta y el proveedor que la implementa, en este último aspecto, Forrester propone los cuatro primeros pasos que se deberían seguir para elegir el partner adecuado para implementar Business Intelligence (BI) o cualquier otra TI.


Los aspectos de mayor relevancia en la adopción de una determina Tecnología de la Información (TI) es la selección de la herramienta y  el proveedor que la implementa, en este último aspecto, Forrester propone los cuatro primeros pasos que se deberían seguir para elegir el partner adecuado para implementar Business Intelligence (BI) o cualquier otra TI.

Forrester, además de ser un referente de opinión en procesos de negocios y tecnologías de la información, provee recursos que pueden ayudar a mejorar la gestión de las organizaciones (bases de datos, herramientas de diagnostico, comparativas y análisis de TI). Los pasos son los siguientes:

  • Identificar los posibles proveedores según las necesidades del proyecto.  Considerando aspectos como alcance geográfico, tecnología y tipo de soporte que se necesita. El artículo original hace referencia al uso de una herramienta desarrollada por Forrester, que según los parámetros introducidos genera una relación de proveedores con un breve resumen de su perfil.
  • Ajustar la lista de potenciales proveedores. La lista de posibles proveedores podría variar considerando aspectos adicionales, tales como, casos de éxito, referencias, tamaño del proveedor (global,  regional o local), especialización o diversificación del  proveedor. La importancia de estos aspectos variará en cada organización según su estrategia, cultura y necesidad.
  • Solicitar propuestas a los posibles candidatos. Elaborar el RFI (Request for  information) o RFP (Request for proposal) que incluya la necesidad de conocer el enfoque del proyecto, personal para cada necesidad específica, costes, técnicas, etc.
  • Selección de finalistas. La fase más compleja de este proceso, la cual tiene un componente subjetivo importante. Se sugiere profundizar en analizar las capacidades de asesoramiento estratégico, metodología a emplear, arquitectura de referencia, gobernabilidad de los datos y experiencia en tecnologías BI-next.

Referencia: Blogs Forrester

Ventajas de SAP BPC NW con relación a SAP BPC M

Es evidente que ambas presentaciones del mismo producto están adquiriendo funcionalidades diferentes, según la plataforma en la que se implemente: Netweaver (NW) o Microsoft (M). Ambas se basan en la misma filosofía del producto original, OutlookSoft.


Es evidente que ambas presentaciones del mismo producto están adquiriendo funcionalidades diferentes, según la plataforma en la que se implemente: Netweaver (NW) o Microsoft (M).  Ambas se basan en la misma filosofía del producto original, OutlookSoft.

Al margen de  tal o cual funcionalidad, vemos tres ventajas que puede aportar SAP BPC para entornos Netweaver con respecto a entornos Microsoft, ventajas que son consecuencia de la arquitectura del entorno operativo, que se podrían aprovechar en SAP BusinessObjects Planning and Consolidation:

  • Independencia de la base de datos.  En entornos Microsoft, una implementación de SAP BPC sólo es posible con bases de datos MS SQL Server 2005 o 2008. En entornos Netweaver, es posible elegir cualquier base de datos, soportada por SAP NW.
  • Uso de ABAP.  SAP BPC permite realizar cálculos especiales con cierta complejidad a través de un lenguaje script (K2 script logic), para ello, ofrece una serie de sentencias estándar que en entornos Netweaver pueden ser reforzadas con el uso de programación ABAP, facilitando la codificación de pequeñas rutinas (Business Add-In – BAdI) que luego pueden ser utilizadas desde los scripts de BPC, permitiendo realizar cálculos u operaciones más complejas que quizás demandarían más tiempo.
  • BW Accelerator. En entornos Netweaver, donde se procesan grandes volúmenes de información, el reporting puede mejorarse significativamente con el uso de SAP BW Accelerator. SAP BPC podría beneficiarse del uso de de SAP BWA, en todas las tareas de reporting o lectura de datos, pero sólo se justifica en implementaciones con un gran volumen de datos (aquí más información sobre SAP BWA).

¿Un equipo de implementadores de SAP BPC NW se asemeja al de un SAP BW – IP?

A principios de 2007 SAP buscaba, con relación a Integrated Planning (BW- IP), mayor simplicidad para el desarrollo de proyectos de planificación y OutlookSoft (hoy SAP BPC, SAP BusinessObjects Planning and Consolidation) se presentaba como la mejor alternativa, por su facilidad de uso y porque además incluía características de consolidación.


A principios de 2007 SAP buscaba, con relación a Integrated Planning (BW- IP), mayor simplicidad para el desarrollo de proyectos de planificación y OutlookSoft (hoy SAP BPC, SAP BusinessObjects Planning and Consolidation) se presentaba como la mejor alternativa, por su facilidad de uso y porque además incluía características de consolidación.

Una anécdota cuenta que para despejar dudas, antes de concretar la compra, SAP convocó a miembros OutlookSoft a la sede principal de la compañía en Walldorf, los que se reunieron con un equipo especialistas SAP conformado por expertos BW, desarrolladores ABAP, programadores Web y consultores financieros.  A ambos equipos se les planteó un escenario de negocios, al cabo de media hora, el equipo de OutlookSoft tenía una aplicación completa y el equipo de BW-IP logró el mismo objetivo luego de seis horas.

SAP BPC 7.5, caminos diferentes para Netweaver y Microsoft

SAP BPC se ofrece en dos presentaciones, una para plataformas Netweaver (NW) y otra para plataformas Microsoft (M), esta última, lo más parecido al OutlookSoft original.  En junio del presente año, según la información que contábamos, concluía el período de pruebas (denominado ramp-up) de la nueva versión, pero sólo se ha puesto a disposición de los usuarios la edición para plataformas Microsoft, la cual ya cuenta con dos actualizaciones.  Después de dar nuestros primeros pasos con la nueva versión, SAP BPC 7.5 M, vemos que algunas de las mejoras, las que particularmente nos parecen mas interesantes, sólo estarán disponibles para plataformas Netweaver, la cual aun no se encuentra disponible.

Trayendo a colación la anécdota de la adquisición de OutlookSoft, surge una observación: Para el desarrollo de un proyecto en SAP BPC la composición de los equipos difieren si se implementará sobre una plataforma SAP Netweaver o Microsoft, ¿si se tratará de SAP BPC NW, la estructura de los equipos no se asemejan al de BW – IP de la anécdota?