Archives

Cada día se le da más importancia a la experiencia del usuario (UX), que implica considerar su nivel de satisfacción al utilizar apps, websites y afines. En este sentido, el objetivo es que los clientes tengan experiencias digitales gratificantes con las marcas ya que este factor ayuda a que la compañía se posicione con respecto a sus competidores y a fortalecer la fidelidad hacia una empresa.

Promediando el 2014, ya se pueden advertir las tendencias en UX para los próximos meses:

• Diseñadores, más atentos al mercado: El diseño de un producto puede convertirse en la clave para que sea un éxito en ventas. Por este motivo, los diseñadores, que hasta ahora se enfocaban en la fase de diseño de producto, comenzarán a salir a calle para aprender todo lo que puedan del mercado y luego iniciar su trabajo en función de ese conocimiento. De esta manera, el diseñador comienza a influir en la estrategia del producto desde una etapa más temprana para asegurar mejores resultados desde el punto de vista del negocio.

• Profesionalización del UX: De a poco observaremos como empiezan a proliferar las ofertas académicas vinculadas con el UX. Como un mayor número de profesionales reconoce la importancia del diseño, las universidades contemplarán esta materia en carreras vinculadas con marketing y negocios. No sería extraño que surjan doctorados, maestrías o cursos de especialización de UX.

•  Hacia los gestos: Así como el diseño conoció toda una nueva dimensión de experimentación con el surgimiento de Internet y de las páginas webs, tímidamente comenzarán a aparecer las apps que se ejecutan por medio de gestos.

Dado que las empresas observan cómo los usuarios interactuar con sus aplicaciones, habrá todo un proceso de aprendizaje para comprender cómo las personas ejecutan por medio de los gestos, ya que esto impactará en el diseño.

• Más iconografía: En los próximos meses  veremos un creciente uso de la iconografía para ayudar a simplificar y agilizar los diseños como parte de la tendencia más general hacia lograr presentaciones más planas y simples. En definitiva, los diseñadores y desarrolladores utilizarán cada vez más íconos en lugar de palabras. De esta manera las interfaces serán más visuales y con menos texto.

• Icono de navegación: Durante el último tiempo muchos websites han abandonado su menú principal para reemplazarlo por un ícono de tres líneas que fue creado para usarse en apps móviles. Esta movida continuará durante los próximos meses generando confusión entre los usuarios a los cuales en varias ocasiones les costará encontrar las opciones de navegación del website, tal como sucede en el site Slate.com.  Algunos otros sitios incluso eliminarán el menú de navegación tal como sucede en Mosey.

• Experiencias digitales: Con el objetivo de lograr que los usuarios “conecten” con lo digital y se sientan más motivados a utilizar herramientas de este tipo, los diseñadores se esforzarán por apelar a la sensibilidad del usuario.  Al respecto, Good es un buen ejemplo para observar cómo una plataforma que se centra en la conciencia y en la comunidad resulta no ser intrusiva ni manipuladora.

La evolución de UX nunca se detiene. Por el contrario, avanza al ritmo en el cual los usuarios consumimos tecnología. Se trata de un recorrido incesante, en donde la prueba y el error se colocan en el centro de la escena.

Al hablar de la sigla “BPM” (en inglés, Business Process Management), nos referimos a la manera de administrar procesos estructurados y repetibles, siendo los mismos un conjunto de actividades diseñadas para alcanzar determinados objetivos de negocio. En complemento, nos referimos (en este ámbito) al término “agilidad” como la habilidad de generar la satisfacción del cliente a través de entregas tempranas y continuas, aceptando y respondiendo a los cambios, colaborando con el negocio a través de una mayor adaptabilidad a las necesidades del mismo.

Sobre la base de de procesos de desarrollo clásicos aplicados en iniciativas BPM, encontramos que IBPM (Integrated BPM Project Methodology) tiene su foco principal en el análisis y diseño, y provee mejoras prácticas (best practices) y artefactos para capturar necesidades de negocio y transformar las mismas en requerimientos acordes. Las características principales de esta metodología incluye:

• Ejecución de la iniciativa BPM de una manera estructurada;
• Basado en BPMN (Business Process Modeling Notation), una notación gráfica estandarizada que facilita el modelado de procesos de negocio en formato de workflow;
• Empleo de mejores prácticas tales como IBPM Framework (combinación de aspectos  de orientación a procesos y orientación a servicios, mediante cinco niveles de organización: “Planificación”, “Análisis”, “Diseño del Negocio”, “Implementación del Diseño” e “Implementación”); IBPM Pattern Catalogue (disponibilidad de patrones predefinidos tales como “guías de modelado BPMN”, “templates de interfaz de usuario”, etc.) e IBPM Project Approach (basado en la metodología waterfall a través de las cinco fases de organización mencionadas).

Desde otro ángulo, el framework SCRUM (un ejemplo “ágil”) nos trae un marco de desarrollo versátil y sencillo de entender basado en un enfoque incremental e iterativo para controlar riesgos y maximizar la predictibilidad. Entre sus características se incluyen, entre otras:

• Es un modelo de referencia, no una metodología;
• Define un conjunto de prácticas (“Sprint Planning”, “Daily Scrum”, “Sprint Review” y “Sprint Restrospective”), artefactos (Product Backlog”, Sprint Backlog” y “Product Increment”)  y roles (“Product Owner”, “Scrum Master” y “Team”);
• Puede tomarse como punto de partida para definir el proceso de desarrollo;
• Permite la creación de equipos multidisciplinarios y autogestionados;
• Reconoce que, durante la ejecución de un proyecto, los clientes pueden cambiar sus necesidades y/o ideas, y que dichos escenarios no pueden ser fácilmente enfrentados de una forma predictiva y planificada.

Ahora bien, ¿es posible transicionar de la tradicional gestión de procesos pre-definidos y predecibles, hacia un modelo iterativo y flexible que provea valor sostenible para las clientes? La respuesta: “Si...y es momento de evaluarlo” Y, ¿que consideraciones se deben tener presente en esta transición?

1. La adopción de un cultura organizacional de bienvenida a los cambios, eliminando el pensamiento colectivo de “...si anda perfecto, ¿porque cambiarlo?...”;

2. La facilitación en la comunicación, colaboración y coordinación de todos los interesados (stakeholders) que participan en el flujo de trabajo con el fin de alcanzar los objetivos estratégicos;

3. La permisión de que los usuarios adopten sus procesos de acuerdo a las necesidades (cambiantes) del negocio.

Objetivos y enfoques

Los objetivos core del Business Process Management apuntan a hacer flexibles los procesos de negocio, mejorandolos de manera continua.

En el inicio, la mayoría de los proyectos BPM no resultan claros en referencia a los diferentes niveles de detalle requeridos, sino hasta que los stakeholders / end users comienzan a apreciar incrementos en la solución esperada,  potencialmente entregable al entorno productivo, esperando que dichos incrementos se repitan entre 2-4 semanas de trabajo.

El approach ágil en el desarrollo de esta clase de productos de software reduce la sobrecarga de varios meses de trabajo dedicados exclusivamente a las fases de análisis y diseño. Una de nuestras más altas prioridades es la satisfacción de nuestros clientes a través de la entrega de resultados visibles en fases tempranas del ciclo de vida de un proyecto BPM; por ello, abracemos el cambio como uno de nuestros key inputs de mejora hacia la excelencia.

Referencias:

- An Introduction to Agile Business Process Management: http://www.cmswire.com/cms/information-management/an-introduction-to-agile-business-process-management-008610.php

- An Agile BPM Project Methodology: http://frapu.net/pdf/bpm2013.pdf

- Agile and BPM: Theory to Practice.

El rol actual de los testers es más versátil que nunca, y requiere un amplio rango de habilidades. Los testers tienen tareas dentro del sprint, y también se encargan de programar. No necesitan especializarse en un solo lenguaje: mientras más conozcan, mejores soluciones podrán encontrar. Un buen ingeniero especializado en testing debe poder adaptar su conocimiento de acuerdo a las necesidades del desarrollo.

Teniendo esto en cuenta, y apoyándonos en la imagen inferior, podemos examinar en más detalle el trabajo de los testers y su distribución de tareas dentro del sprint. En métodos Agile, podemos considerar un sprint previo presente y futuro: el tester deberá encargarse de tareas de estas iteraciones.

• Ser parte de la reunión de planificación para el sprint actual. El tester debe encargarse de proveer estimaciones sobre la creación de datos, casos de testing positivos y negativos, ejecución de pruebas, diseño de frameworks y sus mejoras, configuración de entornos y más.
• Ser parte de la reunión de planificación para el sprint futuro. Antes de comenzar la nueva etapa, el tester debe informar sobre la creación de entornos de trabajo complejos, y sobre cualquier modificación o mejora al framework de automatización.
• Redactar criterios de aceptación para cada ítem del sprint futuro. Los testers deben crear criterios de aceptación para las historias de usuario, ayudando al Business Analyst mediante sugerencias sobre estándares, user experience, problemas de performance y posibles bugs. Dependiendo de qué tan Agile es el equipo, tendremos criterios de aceptación y/o casos de prueba (esto también depende de la compañía). Redactar estos criterios es una tarea realmente creativa, pero debe validarse con el equipo para que se adapte a los procesos.
• Actualizar los criterios de acuerdo a comentarios, y crear casos de prueba para el sprint futuro. Una vez que el tester recibe el feedback sobre los criterios, debe amoldarlos a los comentarios y críticas que haya recibido.
• Automatizar APIs (sprint actual). Si la aplicación está dividida en niveles, tendremos APIs, o servicios. El tester puede comenzar con el scripting antes de que los programadores terminen con su código en el sprint actual. En un primer momento, las pruebas fallarán, pero la situación cambiará gradualmente en tanto avance el proyecto (ATDD). Esta automatización puede lograrse mediante herramientas como SoapUI y Jmeter.
• Ejecutar criterios manualmente (sprint actual). Los casos de prueba deben ser ejecutados manualmente al menos una vez cuando cada historia de usuario se completa. La verificación manual nos provee una serie de bugs, una idea sobre las limitaciones del proyecto y sobre la importancia del caso de prueba. Además, esta práctica puede determinar los candidatos de automatización para el sprint futuro.
• Automatizar pruebas de interfaz (sprint anterior). Automatizar la interfaz de usuario una vez que la aplicación es estable puede ayudarnos a evitar muchos dolores de cabeza. En esta etapa, el tester debe encargarse de la smoke test para las funciones del desarrollo, y de las regresiones para los módulos complejos. Hacia adelante, esta prueba puede ser actualizada, agregando nuevas características.
• Pruebas exploratorias. Este tipo de testing puede encontrar bugs y errores que ninguna prueba automatizada detecta. No hay nada que pueda compararse con la creatividad del tester, y es por ello que debe aplicarse una vez por sprint.
• Ejecutar testing de Seguridad: El testing de seguridad es una validación clave para entregar un buen producto de calidad.  Validaremos desde encriptación de datos hasta XSS y demás técnicas avanzadas tratando de corromper la aplicación basados en  “Etical Hacking”.
• Ejecutar testing de Performance: Las pruebas de performance tienen que ser ejecutados en dos instancias al menos a lo largo de un proyecto. Una en una etapa intermedia del mismo, y otra previa a salir a producción en un ambiente lo mas parecido posible a la infraestructura del servidor real. En la primera instancia detectaremos grandes problemas de recurrencia entre usuarios y manejo de recursos.
• Ser parte de la reunión de review para el sprint actual. Los testers pueden encargarse de las demostraciones internas o externas. El objetivo es mostrar el compromiso del sprint actual, e idealmente no debemos mostrar ningún problema en vivo! En este sentido, el tester debe elegir el camino seguro e indicar los conflictos ya identificados anteriormente.
• Ser parte de la reunión retrospectiva para el sprint actual. En esta reunión participan todos los integrantes del sprint, identificando tareas bien logradas, cuestiones por mejorar y acciones para aplicar.

El manejo, organización y monitoreo de los procesos de negocio se ha convertido en una pieza clave a la hora de buscar una ventaja competitiva dentro de las organizaciones de IT. Así, todo el compendio de técnicas y metodologías de BPM (Business Process Modeling) ha adquirido una relevancia notable. Sin embargo, muchas organizaciones encuentran dificultades a la hora de adoptar BPM dentro de su estructura interna.

Básicamente el problema radica en decidir cuándo, cómo y dónde se aplicaran técnicas BPM. Una posible forma de aproximación a BPM consiste en utilizar modelos de maduración (maturity models), los cuales proponen una forma de iniciarse estructurada y fija. En pocas palabras estos modelos proponen primero determinar el nivel de madurez de la empresa u organización en BPM, y a partir del mismo determinar los aspectos a mejorar para conseguir gradualmente ir avanzando de nivel.

Modelos de Maduración
Para determinar el nivel de madurez inicial se suele implementar una serie de cuestionarios y entrevistas para obtener un diagnóstico inicial. El mismo dará como resultado un cierto nivel de maduración BPM de la empresa. Cada nivel tiene una descripción y una serie de puntos a mejorar que permitirán a la organización avanzar al siguiente nivel.
El concepto de modelos de maduración no es nuevo, y ha sido aplicado con éxito en otras ocasiones. El primer ejemplo surge del Instituto de Ingeniería de Software en la universidad de Carnegie Mellon (http://www.sei.cmu.edu/). Este modelo que se conoce como Capability Maturity Mode, surgió en los años 90 para medir la madurez en el desarrollo de software.
Diversas organizaciones han lanzado sus propios modelos de maduración BPM. Dos ejemplos son Gartner Inc.( http://www.gartner.com/technology/home.jsp) y OMG (http://www.omg.org/). En [1] se describen algunas de las fases del modelo Gartner. Para aquellos en el nivel incial (nivel 1) se recomiendan concentrarse en técnicas BPM, elegir herramientas simples, y entender a fondo las prioridades de los procesos de negocio. Para pasar al nivel siguiente, se deberá buscar herramientas con mayor capacidad, y documentar y monitorear actividades BPM. Este último paso acercará a la empresa a las tareas de gestión BPM. Para el nivel 3 se requiere la creación de un equipo encargado de definir métodos y guías BPM, incluyendo templates, capacitación, creación de material de comunicación, métricas de performance, e interacción con recursos IT. Ya para los niveles sucesivos se requiere profundizar en la noción de métricas, así como también en la simulación y ejecución de procesos.

Guías y consejos para adoptar modelos de maduración
En [1] se describen guías útiles al momento de utilizar BPM y modelos de maduración:
1. No utilizar ciegamente los modelos y/o los templates. Usarlos como inspiración y no tener miedo de personalizarlo a las necesidades de la empresa.
2. No enfocarse en las herramientas, enfocarse en los procesos. Las herramientas ofrecen un camino más atractivo, pero sin el marco general de la definición de procesos el esfuerzo dedicado será probablemente inútil.
3. Utilizar estándares y un equipo humano competente. En este sentido es útil que alguien lleve el rol de BPM “champion”, similar al concepto de Product Owner en las metodologías ágiles.
4. Evitar discusiones abstractas y enfocarse en proyectos y procesos concretos.
5. Seleccionar y descartar los templates del modelo que no son útiles para el proyecto actual.
6. No forzar la implementación BPM. Ciertas actividades podrían no ser relevantes para la empresa y forzar su ejecución causará solo problemas y dolores de cabeza.

Niveles de Madurez sugeridos por empresas
Desde la empresa Gartner se sugieren distintos niveles de madurez, de acuerdo a la capacidad y características de la empresa. Como siempre, el primer paso es una evaluación general de todos los sectores y procesos de la organización. Para empresas pequeñas, un nivel aceptable para llevar a cabo tareas de BPM es lograr un nivel dos, enfocándose principalmente en la identificación (nivel 1) y la gestión de procesos (nivel 2). Ya organizaciones medianas y grandes deberán lograr al menos un nivel 3. Esto radica fundamentalmente en lograr una gestión centralizada de los procesos y teniendo una vista de alto nivel de los detalles y toma de decisiones. El esfuerzo dedicado en centralizar los procesos y tener entonces de manera rápida control sobre los mismos se justifica únicamente en organizaciones medianas y grandes.

Oracle [2] agrega una interesante vuelta de tuerca para las grandes organizaciones al agregar una nueva dimensión. Más allá del nivel de madurez BPM, Oracle considera también los distintos sectores de la empresa. Puede ser el caso de sectores con nivel 3, 4, otros recién arrancando en el primer nivel, e incluso otros que ni siquiera estén contemplando BPM. Según cómo esté distribuido BPM en la organización existen niveles desde No- Implementado hasta Nivel-Enterprise, donde BPM está implementado en todos los sectores de manera consistente. También existen niveles intermedios para contemplar los casos donde existen distintos niveles de maduración entre los diversos sectores. En este sentido se advierte que no es recomendable tener niveles demasiados “desparejos” en toda la organización, ya que llevará a conflictos internos a nivel gerencial. Para evitar esto se sugiere que el sector o los sectores más avanzados compartan y trasladen su madurez BPM a otros sectores, impulsando su crecimiento. Así, de manera gradual, la organización irá paulatinamente logrando los hitos necesarios para avanzar en su nivel de madurez BPM en ambas dimensiones: mayor experiencia en BPM, y mayor transversalidad de sus conceptos a lo largo de la organización.

Referencias:
[1] http://www.allaboutrequirements.com/2011/07/using-bpm-maturity-model-for-inspiration-when-implementing-bpm.html

[2] http://www.oracle.com/technetwork/topics/entarch/oracle-pg-bpm-roadmap-r3-0-176693.pdf

GlobalLogic, empresa líder en Innovación y Desarrollo de Software, informó su participación en CES donde fue presentado un acelerador de solución para el sistema IVI llamado Nautilus, plataforma que funciona en Texas Instrument y que posibilita a la compañía ayudar a sus clientes a desarrollar nuevas y creativas soluciones basadas en Android.

La reciente plataforma de Nautilus, consiste en un conjunto de aceleradores de soluciones que incluye conceptos arquitectónicos, una distribución de sistema operativo Android modificado y conceptos avanzados de interfaz de usuario. De esta forma, GlobalLogic colabora en acelerar el diseño del sistema IVI y el desarrollo a través de los componentes de software confiable, seguro y bien optimizado de la plataforma.

La dificultad más común para la adopción de Android en el software de la industria automotriz es la falta de fiabilidad, seguridad y largo tiempo de arranque. Sin embargo, la nueva plataforma resuelve este problema mediante la separación de software de misión crítica (por ejemplo, CAN / servicios vehículo más, de asistencia al conductor, servicios de emergencia) del software de información y entretenimiento (por ejemplo servicios multimedia, navegación y aplicaciones de la nube).

Nautilus asegura que su sistema funcionará de manera óptima en el hardware de TI subyacente a través de la plataforma Android Automotive Grade (AGA), una distribución de sistema operativo Android modificado que acelera significativamente el tiempo de arranque y velocidades de operación. Los sistemas construidos en esta plataforma están listos para usar dentro de 5-7 segundos después de haber activado y la cámara de visión trasera de la unidad principal se activa dentro de 1-2 segundos de cambiar a la marcha atrás inmediatamente después del encendido.

“Este anuncio de GlobalLogic nos abre un camino de investigación y desarrollo para una industria tan sofisticada e innovadora como es la automotriz. Esperamos poder generar nuevos trabajos y profundizar lo realizado, reflejando el knowhow de la compañía, en el ámbito local”, indicó Sebastián Gryngarten, VP Manager de GlobalLogic.

Desde el clásico modelo de cascada hasta las últimas vertientes en modalidades ágiles, los ciclos de vida en el desarrollo de software han ido sufriendo modificaciones y evolucionando. Un ciclo de vida puede ser visto como un conjunto de pasos, técnicas y herramientas que permiten modelar el proceso de desarrollo de software de punta a punta, desde la captura de requerimientos hasta la puesta en producción y mantenimiento. La misma noción puede aplicarse para la gestión de procesos de negocio en BPM. Como sucede con el desarrollo de software, existen distintos modelos aplicables a BPM. A continuación se verán dos ejemplos. Un modelo clásico y general, que puede adaptarse fácilmente a cualquier organización (ver [1]), y el propuesto desde la empresa JBOSS (http://www.jboss.org/jbpm).

Modelo Clásico de Ciclo de vida BPM

En el modelo clásico coexisten cinco fases diferentes, que están unidas en un proceso continuo. Esto implica que luego de la quinta actividad se vuelve a la primera, para corregir errores e introducir lo aprendido en el ciclo anterior. Las cinco fases son: modelado, implementación, ejecución, monitoreo y optimización.

En la etapa de modelado, el esfuerzo se concentra en describir los procesos a alto nivel, tratando de entender de manera conceptual cómo funcionan cada uno de los procesos. Es importante es este punto no distraerse con cuestiones de implementación y priorizar el entendimiento general.

En la etapa de implementación se profundiza la etapa anterior, introduciendo todos los detalles necesarios para llevar el proceso adelante. Se debe prestar especial atención a la interacción entre actividades así como dependencias con servicios externos.

En la etapa de ejecución los procesos detallados en la etapa anterior son puestos en marcha.

En la etapa de monitoreo se debe supervisar cada uno de los procesos, controlando que su comportamiento sea el esperado. Se debe medir la eficiencia y productividad de cada una de las etapas, y aplicar métricas que garanticen un resultado aceptable.

Finalmente, en la etapa de optimización se está en condiciones de detectar problemas y cuellos de botella que llevan a retrasar de manera innecesaria un determinado proceso. Todas las actividades involucradas deben revisarse para solucionar los problemas detectados.

Una vez completado el ciclo se puede volver a generar una nueva iteración, incorporando en cada paso lo aprendido en el ciclo anterior.

Modelo jBPM

En [2] se describe con detalle este modelo que cuenta con el soporte de tener un framework detrás, una herramienta que permite llevar a cabo todo lo planeado en cada una de las etapas. La herramienta se conoce como jBPM (http://www.jboss.org/jbpm). La gran ventaja de contar con una herramienta de software es que permite tener en un único lugar todo el proceso BPM, y tener asistencia digital en cada etapa.

Las fases de este modelo son conceptualmente similares al modelo ya visto, pero introduciendo en cada una un sabor distinto. Para la etapa de modelado se sugiere seguir un ciclo de 3 actividades: diseño, testing y simulación. Esta forma de estructurar el modelado permite una mayor robustez en el proceso. Es decir, cada proceso será diseñado, luego verificado a través de un proceso de testing, y se podrá ver una primera forma de ejecución en la tercera etapa de simulación. Todo esto es aplicable desde la herramienta jBPM.

La segunda etapa recibe aquí el nombre de Deploy, donde finalmente todos los procesos identificados de la etapa anterior son integrados. jBPM ayuda en esta etapa al disponer de un repositorio de procesos, lo cual facilita su mantenimiento y supervisión.

La tercera etapa de ejecución se lleva a cabo a través del motor BPMN2, el cual permite ejecutar procesos diseñados en el lenguaje BPMN. Nuevamente se ven las ventajas de contar con una herramienta que automatice cada paso. Esto se ve más claramente en le atapa de monitoreo, que viene provista como funcionalidad predefinida en la herramienta. Finalmente, en la etapa de análisis se pueden realizar ajustes sobre los procesos, viendo su rendimiento y eficiencia.

Conclusiones

En el presente artículo se han descrito dos posibles ciclos de vida BPM. El primero es un modelo más general, y el segundo, puede verse como una implementación del primero instanciado en una herramienta en particular, con toda la garantía de una empresa como JBOSS. Tener en cuenta y seguir un ciclo de vida BPM ayudará a organizar su puesta en marcha y lograr los objetivos propuestos.

Referencias:
[1] http://www.pnmsoft.com/resources/bpm-tutorial/bpm-lifecycle/
[2] http://people.redhat.com/kverlaen/BPM/

La irrupción de Internet como medio de medios significó un cambio profundo en la manera en que se gestiona la comunicación en las organizaciones. La velocidad y la ubicuidad se volvieron la norma. Los tiempos que corren obligan a las empresas a hacerse cargo de su presencia online, que tiene un impacto cada vez mayor en las esferas de la vida real.

Mientras el marketing tiende hacia las técnicas de CRM (Customer Relationship Management), el Community Manager surge como uno de los puestos clave de los entornos laborales del siglo XXI, transformándose en la voz de la organización y actuando como un puente para ampliar la del público. Esta nota busca develar algunas de sus principales funciones.

Roles y tareas
El ecosistema de trabajo que rodea al Community Manager se complejiza cada año, en tanto evoluciona a la velocidad de la web. Los roles que cumple un CM son variables, y dependen en gran parte de la organización para la que trabaje. En todos los casos, el objetivo de base es agilizar y gestionar las interacciones con los clientes, escuchando su feedback para identificar oportunidades en el camino. Es por ello un puesto multifacético, en el que se cruzan habilidades de manejo informático con áreas más tradicionales de relaciones públicas, prensa y marketing.

Un Community Manager debe cumplir roles flexibles y dinámicos, y debe estar preparado para trabajar en equipo. A los esfuerzos del CM se le suman los del Social Media Manager, que es quien diseña la estrategia de comunicación digital de la empresa, a la vez que editores y generadores de contenido social preparan el material para ser publicado.

En este sentido, un concepto clave para el trabajo del CM es la calendarización del contenido, que implica una planificación del material que se publica en los días de la semana. Para esto se analizan las características del público y del canal, buscando maximizar la llegada de las publicaciones. La calendarización permite definir los objetivos a corto y mediano plazo, y genera una expectativa en los lectores, que saben qué y cuándo esperar en relación al contenido.

Otra de las tareas diarias del CM implica estar al tanto de las conversaciones que surgen en los múltiples canales de la red. Existen servicios que permiten realizar monitoreos sobre palabras clave dentro del infinito flujo de contenidos: a partir de esta posibilidad, se abre el camino para las interacciones directas con el consumidor, que ahora puede hacer llegar sus reclamos y consultas sin frustrarse por intermediarios.

El CM tiene a su disposición un arsenal creciente de herramientas web, que le permiten trabajar metódicamente sobre la imagen de la marca, generando reportes sobre su presencia e impacto. En este sentido, debe estar a la vanguardia de la comunicación estratégica, adelantándose a posibles crisis y avanzando en base un plan con objetivos progresivos.

En definitiva, el CM debe encargarse de administrar los sitios o servicios en los que la marca tiene presencia, fomentando un interés genuino hacia las novedades de la empresa y facilitando la interconexión de usuarios en función de la comunidad. El Community Manager es, de esta manera, el brand evangelist más visible e importante de la organización.

Herramientas y KPI
Un CM debe estar siempre al tanto de las novedades de Internet. Se trata de un puesto que requiere una sensibilidad especial para este medio, ya que las acciones deben enmarcarse en la lógica de la web para ser exitosas. El Community Manager tiene que conocer servicios y redes sociales al detalle, pero con ello no alcanza: para cumplir efectivamente con su función, debe comportarse como un verdadero nativo digital.

Los servicios de gestión de imagen online son muy variados: el Community Manager debe mantener una caja de herramientas heterogénea, capaz de medir las interacciones desde todos los ángulos posibles. Existen soluciones completas, que integran en un mismo panel de control múltiples herramientas de monitoreo. Servicios como Radian6, HootSuite o Sprout Social permiten escuchar selectivamente el tráfico que circula cada día por las redes sociales; mientras tanto, una batería de herramientas oficiales (como Facebook Pages Manager) permiten una administración en detalle de las interacciones y el progreso de la cuenta.

Estos y otros servicios se conjugan en reportes con métricas y KPIs, que permiten conocer el progreso de la estrategia de comunicación. En resumen, las métricas de negocios son indicadores que indican al Community Manager si está o no cumpliendo con los objetivos estipulados. Su análisis es importante para rectificar rumbos y ajustar planes de comunicación.

Los KPI representan a los Key Performance Indicators, también conocidos como indicadores clave de desempeño: estos miden el nivel de eficiencia de los procesos, enfocándose en el "cómo" e indicando el rendimiento de los procesos. La idea de los KPI es permitir una valoración de actividades difíciles de medir, como pueden ser el nivel del servicio, la satisfacción de los consumidores o el compromiso de los empleados.

Es importante que cada organización pueda definir sus KPI en base a su plan de comunicación estratégico, teniendo siempre en cuenta las necesidades de sus procesos particulares de negocio. Los KPI varían de una empresa a otra, pero también entre servicios: en Facebook el dato importante puede ser el número de Fans de una página, o las interacciones durante la semana; en Twitter son relevantes los retweets de los mensajes; en un Blog tradicional puede seguirse de cerca la cantidad de suscriptores por correo y RSS.

Dimensiones de la marca
Una buena brújula para el Community Manager es la teoría de Aaker sobre las cinco dimensiones de la marca: Sinceridad, Entusiasmo, Capacidad, Sofisticación y Aspereza (Sincerity, Excitement, Competence, Sophistication y Ruggedness).

El modelo utiliza estas analogías en relación a grandes dimensiones humanas, que incluyen a su vez una estructura interna con ciertos rasgos distintivos. En el caso de la dimensión de Sinceridad, se destacan rasgos de la marca como honesto, sano y alegre; en Entusiasmo, pueden aparecer rasgos como atrevido, actualizado; en Capacidad se encuentra el éxito y la confianza; en Sofisticación la pertenencia a clases altas y en Aspereza la resistencia o robustez.

Se trata de un marco conceptual sumamente útil para describir y medir la “personalidad” de la marca frente a su audiencia, lo que significa su posicionamiento subjetivo dentro de las fuerzas del mercado. Puede utilizarse para investigar el estado actual de la marca, y también para describir el estado futuro deseado.

El Community Manager debe utilizar todas estas herramientas y marcos teóricos para ponerse al frente de la comunicación en la organización. El CM sabe mejor que nadie hacia dónde enfocar las interacciones y acciones sociales. Sus aportes en relación a la imagen de la marca son invaluables, ya que provienen del contacto directo con la audiencia que se quiere interpelar. Mientras Internet siga invadiendo todas las esferas de la vida real, el Community Manager tomará una posición cada vez más central en las organizaciones, interconectando los departamentos de marketing, legales, recursos humanos y prensa.

Todavía es común que se confundan los conceptos y suponer que la virtualización es prácticamente lo mismo que Cloud Computing. Sin embargo, si bien los modelos de cómputo en la nube no podrían existir sin las tecnologías de virtualización, es importante comprender sus diferencias. El objetivo de este artículo es resaltar aquellos puntos que puedan tener en común y luego aclarar estas diferencias. En la Figura podemos apreciar una representación gráfica del concepto de virtualización.

La primera capa corresponde al hardware físico disponible, por ejemplo un potente servidor o un Blade. La segunda capa corresponde al Hypervisor, quién es el encargado de controlar y gestionar las máquinas virtuales que se estarán ejecutando. El hypervisor dependerá de la tecnología de virtualización que estemos utilizando (VMWare, XEN o Microsoft Hyper-V entre otras). La tercera, cuarta y quinta capa corresponden a cada una de las máquinas virtuales que estemos ejecutando.

En este punto podemos hacer una analogía con Cloud Computing y recordar los distintos modelos de servicio ofrecidos:
• IaaS (Infraestructure as a Service)
• PaaS (Platform as a Service)
• SaaS (Software as a Service).

Es decir, podríamos asociar el Hardware Virtualizado con el modelo IaaS, mediante el cual ofrecemos recursos tecnológicos como capacidades de procesamiento, almacenamiento, conectividad, etcétera. Podemos asociar el Sistema Operativo virtualizado con el modelo PaaS, el cual ofrece una plataforma operativa, por ejemplo mediante Windows Azure.

Finalmente, podemos asociar las aplicaciones con el modelo SaaS. En este último caso se ofrece usabilidad y control sobre una funcionalidad específica, como por ejemplo guardar información en la nube (Google Drive, Dropbox, etc), crear y editar documentos (Google Docs, Office 365, etc.) e incluso tener un CRM online, como es el caso de salesforce.com.

Diferencias
Sin embargo, independientemente de que la virtualización es la tecnología fundamental gracias a la cual existe la computación en la Nube, son conceptos diferentes y sus aplicaciones también varían. De hecho, un impulsor del Cloud Computing (que no tiene que ver directamente con aspectos tecnológicos en sí) es la baja de los precios del equipamiento de hardware, en particular el hardware asociado al almacenamiento. A esto se le suma el avance de las tecnologías de comunicaciones, las cuales permiten alcanzar velocidades del orden del Gb a muy bajo costo.

Más allá de los aspectos tecnológicos y de costos, la mayor diferenciación se logró desde los modelos de servicios, ofreciéndole a los clientes distintas alternativas como las vistas previamente y la posibilidad de disponer de las nubes públicas, privadas, comunitarias e híbridas.

A modo de conclusión podemos afirmar que el aumento de las capacidades de procesamiento, de almacenamiento y de conectividad, sumado a la baja de los costos de hardware, impulsó el uso de tecnologías de virtualización que anteriormente estaban reservadas únicamente para las grandes empresas, también a las pequeñas y medianas.

A su vez, estos avances posibilitaron que se diseñen servicios muy flexibles adaptados a las necesidades de consumo de los clientes, de forma tal que puedan pagar en función del consumo realizado. Estas son algunas de las claves que hacen de la computación en la nube un modelo que vino para quedarse y seguir creciendo.