Consejos para lanzar un proyecto SocialMedia en una compañía

Tengo la suerte de  ser colaborador de SegurosRed, el primer portal social de seguros en España. Hace ya varios años que sigo de muy cerca el fenómeno socialMedia, este año 2010 tiene que ser el año de su explosión, por este motivo hay muchas publicaciones que han aumentado sus artículos sobre las redes sociales y el social media. Por este motivo me gustaría compartir con vosotros 5 pautas básicas para plantearse un portal SocialMedia.

1. Prestar atención a las estadísticas: Como indica Slideshare en suNewsletter de Enero, los Jefes de Marketing van a dedicarle mucha mayor atención a cómo medir las conversiones del Social Media. Las startups interesadas en un proyecto socialMedia pueden consultar la Superlista de métricas de social media de Robin Broitman (en inglés), que incluye varios recursos de evaluación estupendos.
2. Escalar las buenas costumbres: Según Slideshare, “Lo que funciona para 2 personas no funciona para 20. Todo nuestro equipo debería estar motivado para responder rápidamente, publicar de forma constante y comunicarse como seres humanos”. Éstos son algunos recursos (en inglés) para determinar los objetivos y capacidades de nuestra empresa: la lista de preguntas de social media en Museum 2.0, el artículo de DoshDosh sobre establecimiento de objetivos de campañas,  el mapa de estrategias y hoja de trabajo de social media de Beth Kanter. A la hora de evaluar nuestra “voz humana”, es interesante leer el debate (en inglés) entre Chris Saad de Echo y Jeremiah Owyang del Altimeter Group.
3. Tener reglas, pero confiar en la gente: Según Slideshare, los ejecutivos deben “predicar con el ejemplo, en lugar de controlar con el reglamento en la mano”.
4. La creatividad y la personalidad triunfan sobre los grandes presupuestos: Se puede llegar a realizar un proyecto creativo sin tener un gran presupuesto.
5. Escuchar, escuchar, escuchar: A principios del año se hablaba sobre cómo el análisis de sentimientos sería cada vez más importante en 2009. Para realizar un seguimiento de las conversaciones sobre nuestra empresa, podemos probar ContextVoice, PostRank y/o Echo. Para examinar todo nuestro sector en general, puede que queramos crear nuestra propia Hoja de consejos para red social.

En conclusión, estos son los 5 puntos base que los gurús de socialMedia están indicando y marcando como puntos clave para lanzar un proyecto de este tipo. En mi opinión y como comentaba al principio, este año y principios del siguiente, creo que las redes sociales enfocadas al negocio cogerán un fuerte protagonismo y pueden llegar a incrementar el valor de la venta on-line y sobre todo para la obtención de información de nuestros clientes y clientes potenciales.

El thin clients, una posibilidad de los departamentos TIC de las compañías de seguros

Primero de todo, para las personas que no sepan que es un thin clients, básicamente y en vocabulario llano, son ordenadores que no llegan a tener ni disco duro, eso significa que son terminales (maquinas tontas) de trabajo que no tiene ningún tipo de acceso desde fuera (CD, usb…) son totalmente herméticos y tiene configurado un escritorio 100% para el uso profesional.

Esta opción se puede llegar a plantear en las compañías por varios temas, uno seria el ahorro de costes, porque se puede aprovechar maquina antiguas porque no es necesario tener un ordenador potente y otro tema muy importante es la parte de seguridad, porque como ya hemos comentado son terminales herméticos y así no se puede escapar mucha información, siempre nos quedara el correo.

La nueva generación de thin clients viene de la mano de la  vitalización, que permite una administración centralizada y una mejor gestión de las tecnologías de la información en la compañía. Además el hardware que necesitan debería ser mucho más económico que los equipos habituales.

¿A partir de qué nivel podría ser rentable? Para ser realistas puede ser una buena opción  cuando contamos con más de 100 puestos informáticos, donde los Thin Clients pueden dar lo mejor de sí y comenzar a ser rentables para la compañía. Claro que su gran virtud también es su mejor inconveniente, la centralización. Si falla el servidor, x puestos se quedarán sin trabajar.

En todo caso es un sistema que puede ser adecuado, sobre todo cuando se ejecuta por departamentos, y no todos los puestos dependen del mismo equipo centralizado. Se trataría de ejecutar una gestión centralizada con distintas cabeceras, que serían los referentes para cada departamento.

En conclusión, tenía ganas de comentar esta posibilidad porque parece que en tiempos de crisis se recuperan viejas tendencias, pero debo decir que yo personalmente no soy muy partidario a los terminales tontos, porque todo usuario (del departamento de TIC) se merece tener su momento de desconexión y relajar la cabeza, a parte hay que tener cierta confianza en tus empleados, sino mal vamos.

Actualizar nuestras aplicaciones, ¿como debemos enfocarlo?

En toda compañía llega un momento que nos damos cuenta que nuestras soluciones de software que utilizamos cada día se están quedando obsoletas, o aun peor identificamos que para realizar un pequeño cambio cuesta mucho tiempo y dinero, como dice la frase “ es mas fácil tumbar la pared que escalarla “.

Tenemos que ser conscientes que realizar un cambio de ERP sobre nuestra compañía es un cambio muy importante y critico, pero también hay que tener presente que las limitaciones que nos puede dar nuestra aplicación, puede ser una ventaja para nuestros competidores.

También hay que tener presente que el cambio de una aplicación en la compañía normalmente el usuario es reacio al cambio (por naturaleza) y esta resistencia al cambio puede hacer que nuestras aplicaciones dejen de ser productivas, por este motivo la gestión de cambio debe ser un punto muy presente en la toma de decisión.

¿Cuando debemos cambiar nuestra aplicación? Esto ocurre generalmente cuando la herramienta llega a su límite de esfuerzo, con esto quiero decir que este limite puede ser tanto a nivel de leguaje de programación (dificultad para encontrar personal), puede ser porque nuestra herramienta es muy estática (cualquier cambio conlleva un esfuerzo enorme) , en definitiva el punto que nos debe marcar ese limite es cuando la aplicación que nos ahorraba tiempo en nuestras tareas, llega un momento que nos proporciona mas trabajo  y perdemos mas tiempo en ella.

No se trata tampoco de invertir cantidades desorbitadas para las empresas, sino de buscar una solución adecuada para nuestra empresa. Asesorarnos bien, estudiar el mercado, comparar soluciones y seleccionar la herramienta que mas se acople a nuestra organización.

En conclusión, siempre hay que mirar por la agilidad de nuestra organización, y saber si nuestro taller de productos es rápido y dinámico, si necesitamos personal, saber que en el mercado hay suficientes y no esta desactualizado, … así cada uno debemos identificar nuestras herramientas y valorar si ha llegado el momento de plantearse un cambio, eso si!, si es posible solicitar ayudar por terceras personas, que puedan proporcionar una visión desde fuera.

Posible modelo para la gestión de múltiples aplicaciones EAI hacia BPM (Parte II)

Haciendo referencia al post  “Posible modelo para la gestión de múltiples aplicaciones EAI hacia BPM (Parte I)” hoy me gustaría explicar el siguiente paso Natural para llegar a tener un EAI orientado hacia BPM.

Como ya se explicaba en el primer paso ya tenemos la “integración de sistemas basado en funcionalidades, no en datos”.

Ahora nuestro siguiente paso es automatizar nuestros procesos que hasta el momento lo realizamos de forma manual y poco estructurada, o mejor dicho, cada persona y cada organización tiene sus procesos claros, no diré documentados, porque eso seguro que mas de uno suspende, encima si sumamos que actualmente una compañía puede haber adquirido una o mas compañías, una buena forma de organizar y sobre todo tener claro los procesos críticos de la compañía es la utilización de un BPM y a parte así vamos adelantando trabajo para SolvenciaII.

El paso 2 seria dotar a nuestros sistemas de lógica de negocio. Cuando decimos lógica de negocio entraría directamente relacionado con el BPM, porque dentro de este punto ya entraría el workflow de nuestros procesos, también utilizaríamos el motor de reglas de negocio y facilitaríamos a nuestros usuarios finales las suficientes herramientas de acción sobre el proceso.

Ejemplo: Con el paso 1, podemos tener integrado en un EAI nuestra BBDD y nuestra aplicación y a parte la BBDD de nueva adquisición y también su aplicación, entonces podemos seleccionar un procesos Piloto y desarrollamos un BPM por una capa superior del EAI, así nuestro BPM se nutre de información de todas nuestras BBDD como si fuera un Data global, una vez tenemos toda la información en nuestro proceso ya podemos ejecutar nuestro proceso, por ejemplo las liquidaciones de comisiones, que podría ser un buen ejemplo porque deberíamos ir a una BBDD a buscar todas las ventas y comisiones de un agente y luego deberíamos ir a la segunda BBDD e ir a buscar las ventas y las comisiones del mismo agente.

Hay que tener presente que en un papel todo se aguanta, lo que aquí se escribe puedes parecer sencillo, pero ya puedo asegurar que es un proyecto muy costoso tanto en tiempo como el precio.

En conclusión, dentro de este mundo de compras y uniones de compañías, puede ser una buena solución, primero para poder identificar y tener un modelo único de procesos y lo segundo es para llegar a tener una sinergia entre todos los sistemas de la compañía.

EAI: Herramienta para poder integrar “N” aplicaciones/sistemas

BPM: Gestión de los procesos de negocio.

Workflow: Flujo de trabajo

BBDD: Base de datos

Pilar I de solvencia II, desde un punto de vista no técnico

Hace varias semanas hablando con Gregorio me comprometí a realizar mis observaciones sobre el pilar I de solvencia II, lo quería haber hecho antes, pero por compromisos profesionales no había tenido tiempo y como lo prometido es deuda… hay va.

Pilar I, es el bloque que va relacionado con la Exigencia de Recursos propios, dentro de este bloque se regularan los Requisitos de capital objetivo y Capital mínimo para todo los riesgos de la compañía, a parte se regularan las reservas y la inversiones realizadas.

Como bien dice la definición, estamos hablando de dos niveles de capital, el calculo de los capitales es a nivel individual y esta basado en modelos de riesgo (UE o interno)
Con esto quiero decir que se puede calcular el nivel de capital objeto (target Capital) con un modelo estándar proporcionado por la UE o se puede realizar el calculo con un modelo interno.
Y el segundo calculo de capital que estamos hablando seria el Nivel de Capital Mínimo (minimum capital).

Dejando de lado los modelos estándar para calcular el nivel ideal de capital que facilita la UE, nos fijamos en los modelos internos, lo primero que se realiza es el desarrollo de un criterio de aprobación para la UE en cooperación con varios grupos de consulta y tomando en consideración la experiencia del sector bancario.
Se permitirá entregar modelos parciales para facilitar la introducción de nuestro modelo interno.
Y es aconsejable fijarse en modelos de fuentes externas como reaseguradores, bancos o consultores.

Otro punto importante del capital objetivo es llegar a modelar nuestra capacidad de asumir riesgo.

A gran escala se debería modelar varios tipos de riesgo y acumulaciones tomando en cuenta sus correlaciones. Por ejemplo:

Tendríamos un Riesgo Total, este riesgo total se calcularía en base a nuestros riesgos de suscripción, riesgos de crédito, riesgos de mercado, riesgos de liquidez y nuestro riegos operativo, y de cada tipo de riesgo nos irían apareciendo el detalle de donde realizamos el calculo, como por ejemplo nuestro riesgo de crédito se calcularía en base a nuestro riesgo de prima, riesgo de reservas, riesgo de eventos extraños… acumulando todo nuestros indicadores de riesgo al nivel de detalle mas bajo.

Hay varios modelos de riesgo, aquí os pongo el ejemplo de 60 riesgos individuales basado en el modelo de riesgo de la Kolnishe ruck.

Y para no alargarme mas, por ultimo un ejemplo de categoría de riesgo Underwriting.

Por un lado podemos tener riesgos de Volatilidad: Desastre natural, eventos catastróficos, terrorismo, guerra, epidemias, cúmulos…
Y por otro lado riesgos de Error: Primas equivocadas, reservas equivocadas, cálculo erróneo de exposición máxima (pml)

Y así podríamos ir identificando todo tipo de riesgos.

Con este post intento explicar “a mi manera” de una forma no técnica lo que para mi significa el PILARI de SolvenciaII, espero que os haya servido de una pequeña ayuda para visionar y entender como se forma el calculo de capitales y exigencias de recursos propios.