Más ejemplos de como usar mal un CRM

Hace unos días José Alarcón, un compañero de Geeks, me comentaba los problemas que había tenido con su operadora de ADSL al querer modificar el servicio que le prestaban (podeís leerlo en su blog). Esto, junto con algunas otras experiencias, me ha hecho pensar en cómo muchas veces las empresas toman los sistemas CRM como una herramienta para controlar a su fuerza de ventas, y en el grave error que supone esto.


El caso es que Alarcón tenía una línea ADSL con Wanadoo que funcionaba perfectamente a una determinada velocidad, sin embargo, a la vista de las nuevas ofertas de 20MBs decidió cambiar. Como hombre precavido que es, llamó en varias ocasiones para consultar si era posible el cambio y si esto no interrumpiría el servicio, en todas ellas la respuesta fue positiva, el cambio se haría sin ningún corte del servicio. Algo que a cualquier persona en este mundo le parecería lo más lógico al no cambiar en ningún momento de operador, aunque ya sabemos que las operadoras de telecomunicaciones no suelen ser de este mundo. Sin embargo, ya sabéis lo que pasó, ese cambio tan sencillo del que le había asegurado no interrumpiría el servicio se convirtió en un mes sin conexión a Internet en su casa. El motivo fue algo tan sencillo como que el operador que hizo la transacción tramitó una baja y una nueva alta, en vez de realizar un simple cambio de servicio.


Lo que más extrañaba a Alarcón es el motivo por que el teleoperador había tramitado la baja y nuevo alta en vez de un cambio de servicio, y la verdad es que de buenas a primeras puede parecer ineptitud por parte del teleoperador. Pero seguramente, la culpa de esto no es otra que haber utilizado una herramienta CRM como un “gran hermano” de la fuerza de ventas. Me refiero, a que la empresa probablemente utiliza la información proporcionada al CRM por su fuerza de ventas como un instrumento de control de las actividades comerciales, por lo tanto, el CRM en vez de proporcionar la automatización de tareas y ayudar a la labor comercial, lo que hace es crear una fuerza de ventas que desconfía del CRM y se siente presionada. Con lo que el teleoperador en su afán por mejorar sus estadísticas de ventas, para mantener su trabajo o mejorar su sueldo, decidió que sería mejor apuntarse un alta que un simple cambio de servicio.


Otra cosa que puede resultar muy rara es que la empresa no se molestase en comprobar el motivo de una baja, o ni siquiera intentase la retención del cliente. Esto evidencia que de nuevo la empresa ha cometido un error de libro en el marketing relacional, no centra su estrategia en retener clientes sino en captarlos. Esto es una gran equivocación ya que normalmente es más barato retener un cliente que captarlo, y es el verdadero objetivo del CRM, hacer relaciones duraderas. Acaso no sería más barato haber hecho una llamada al cliente para conocer los motivos de la baja y tratar de evitarla (algo muy fácil en este caso ya que no era una baja deseada), que los gastos que genera la captación de un cliente (proceso de alta, modem/router adsl, etc…). Es más, no debemos dejar la retención del cliente para el momento en el que ya ha tomado la decisión de irse, la retención del cliente debe conseguirse día a día con la personalización del servicio y el trato adecuado.


Y ya para acabar de rematar la faena, como es posible que una vez detectado el caso la compañía no haya sido capaz de remediarlo. Parece increíble que la única solución propuesta haya sido la de continuar un proceso de alta normal (1mes), y sin ninguna compensación al cliente. Todo ello debido, seguramente, a la falta de flexibilidad en sus procesos de negocio.


Llegados a este punto la compañía debería plantearse serios cambios en su CRM. Por una serie de errores de libro, ha perdido a un cliente, es más ha ganado una prescripción negativa muy importante. En este caso se presentan, por lo menos, tres de los grandes errores que cometen las compañías en sus estrategias CRM. Primero, no han sabido manejar la incidencia provocada por su propio servicio y solucionar el problema del cliente de forma adecuada, a pesar de haberse dado cuenta de la situación no ha dado prioridad al alta para solucionar el problema. Segundo, el operador que lo atendió no escucho al cliente, en vez de hacer un cambio tramitó un nuevo alta, seguramente presionado por mejorar sus estadísticas comerciales. Tercero, la empresa no ha sabido establecer un mecanismo de retención de clientes, y no me refiero a poner trabas para darse de baja, sino a hablar con el cliente para conocer los motivos de su baja y en caso de ser posible tratar de evitar la pérdida.


Espero que esta reflexión sobre errores de CRM os sirva de algo. En este mundo, muchas veces se aprende más de los errores que de los aciertos. Además, viendo estos errores, seguro que a la mayoría se os ocurren soluciones a los mismos con Microsoft Dynamics CRM ¿verdad?


Un saludo,


Marco Amoedo Martínez

Modificación masiva de registros sin programar

Ayer, leyendo el blog del equipo de Microsoft Dynamics CRM, encontré un post sobre la poco conocida capacidad que tiene el CRM para permitir modificar varios registros a la vez. La verdad, es que para mi esta capacidad era una total desconocida, y eso que en más de una ocasión la he echado de menos.


La causa del desconocimiento de esta funcionalidad puede estar provocada por su “ocultación” y la confusión a la que da lugar su nombre. Para acceder a ella tenemos que seleccionar editar, en el menú “más acciones” de la vista de grid de la entidad que queramos editar. Como veis no es que este muy a la vista, ni tampoco que su nombre permita entrever la capacidad de edición múltiple que tiene. De hecho, en el propio Blog del equipo del CRM le achacan la falta de conocimiento de esta funcionalidad a esto.


Para utilizarla tenemos que seleccionar el conjunto de registros sobre los que vamos a realizar la modificación, y luego pulsar la opción editar en el menú “más acciones”.



Esta funcionalidad se encuentra disponible para varias entidades del CRM, como casos, cuentas, contactos, oportunidad, productos, listas de marketing, clientes potenciales…). Cuando accedamos a esta opción nos aparecerá un formulario de edición del tipo de la entidad seleccionada con todos los campos en blanco, en este formulario modificaremos sólo aquellos campos que deseemos editar en conjunto para todos los registros, los que queden en blanco no sufrirán modificación ninguna. Además, al acceder a este formulario veremos cómo hay campos inhabilitados y sobre los que no podremos hacer una edición múltiple, como por ejemplo el propietario en los contactos.



¿Cuándo puede ser útil? Pues muy fácil, imaginad que una empresa cliente cambia su ubicación o su teléfono y tenemos que modificar esos datos en todos los contactos de esa cuenta. Vamos a la vista de contactos, hacemos una búsqueda avanzada para filtrar los contactos de esa cuenta, los seleccionamos todos y utilizamos la edición múltiple para modificar los datos de ubicación y teléfono.


¿Os habéis encontrado alguna vez con la necesidad de editar múltiples registros?¿Ya conocías esta funcionalidad? ¿Nos sorprenderá el equipo del CRM con más funcionalidades ocultas?


Un Saludo,


Marco Amoedo Martínez

Crear Consultas FetchXML de forma Sencilla – FetchXMLBuilder

En el último post hablábamos sobre las formas de recuperar colecciones de objetos de Microsoft Dynamics CRM a través de peticiones a los métodos RetrieveMultiple y Fetch de los servicios web, y veíamos las diferencias entre ambos. Veíamos también, como Fetch utilizaba un lenguaje de consulta llamado FetchXML, que puede resultar un poco “complejo”. Pero gracias de nuevo a la gran comunidad que existe sobre esta solución CRM, nos encontramos con una herramienta que nos facilitará muchísimo la vida a la hora de crear y evaluar consultas FetchXML.


La herramienta gratuita de la empresa Tekatur se llama FetchXML Builder, en el enlace a su web encontrareís la herramienta para descarga así como la documentación de la misma. Esta utilidad nos permitirá crear y probar sentencias FetchXML de forma sencilla y rápida, adaptándose además a nuestra implementación de CRM ya que lo primero que hace la aplicación al iniciarse es recuperar la lista de metadatos de nuestro servidor CRM.



Una vez obtenidos los metadatos de nuestra instalación de Microsoft Dynamics CRM, nos aparecerá la siguiente pantalla donde tendremos las principales opciones para crear una nueva consulta y probarla. Como podéis ver, podemos seleccionar la entidad principal de la consulta, los campos que queremos incluir, la ordenación, filtrado y los joins con otras entidades.



Si pulsamos sobre añadir un nuevo Link aparecerá el formulario para editar enlaces. Este formulario, nos permitirá seleccionar la relación sobre la que haremos el join (o especificarla manualmente), seleccionar los filtros sobre la relación, y seleccionar los campos de la entidad relacionada que queremos incluir en los resultados. Esta última posibilidad, incluir campos de otras entidades en los resultados, es una de las diferencias entre usar Fetch o RetrieveMultiple. Además también tenemos la posibilidad de establecer el tipo de join (natural,inner y outer), la ordenación, y el alias de la relación que se mostrará en los resultados. A continuación podéis ver este formulario de edición de links.



Finalmente, tenemos los formularios para editar filtros y condiciones de los filtros, que nos permiten establecer filtrados tanto para la propia entidad como para los links con otras entidades.




Como veis, esta es una magnífica herramienta que nos puede ayudar en más de una ocasión con el lenguaje FetchXML, y sobre todo, que nos puede servir de muchísima ayuda para comprender mejor este potente de lenguaje de consulta de Microsoft Dynamics CRM.


Sólo tengo una pega, la edición de filtros no permite anidarlos, con lo que perdemos posibilidades a la hora de crear filtros. Es decir, no es posible crear un filtro tipo (cond1 or (cond2 and cond3)) con esta herramienta, algo que si está soportado por el lenguaje FetchXML. De todas formas hay un rodeo sencillo para conseguirlo, que es crear los filtros por separado, sin anidamiento, y luego modificar la consulta FetchXML que genera para anidarlos nosotros. Por ejemplo encerrando los filtros en un nuevo filtro <filter type=’or’> …. <filter>


¿Qué os parece la herramienta? ¿Creéis que es útil el lenguaje FetchXML?


Saludos,


Marco Amoedo Martínez

Descargar FetchXML Query Builder

Recuperar colecciones con los Servicios Web – RetrieveMultiple y Fetch

La última vez que hablamos sobre los métodos de los servicios web del CRM dejamos a un lado dos métodos que nos permiten recuperar colecciones de entidades, los métodos RetrieveMultiple() y Fetch(). Como vamos a ver, los dos nos permiten recuperar colecciones de objetos de Microsoft Dynamics CRM, aunque con unos matices y filosofía de utilización muy distintos.


RetrieveMultiple


El método RetrieveMultiple es un método “fuertemente tipado” que nos permite recuperar una colección de registros de una sola entidad del CRM, es decir nos permite recuperar una colección de objetos del mismo tipo. Esta es una de las grandes diferencias con Fetch, ya que el lenguaje de consulta FetchXML utilizado por el método Fetch no es fuertemente tipado con lo que podemos recuperar atributos de distintos tipos de entidad al igual que hacemos en sentencias SQL. Por poner un ejemplo, si queremos recuperar varias columnas de la entidad contactos y el nombre de la cuenta a la que pertenecen en una sola consulta tendremos que usar FectchXML, ya que con RetrieveMultiple solo podemos recuperar columnas de una entidad con lo que no podríamos incluir el nombre de la cuenta.


La otra característica distintiva de este método es que nos permite construir las consultas de manera programática, utilizando objetos QueryExpression o QueryByAttribute. ¿Cuándo utilizamos uno u otro? Pues la respuesta es más o menos sencilla. Si lo que necesitamos es recuperar un conjunto de registros de una entidad en los que un conjunto de atributos tome un determinado valor, utilizaremos QueryByAttribute. Como por ejemplo, recuperar todas las cuentas cuya ciudad sea Madrid y su país España.











// Create the QueryByAttribute object.


QueryByAttribute query = new QueryByAttribute();


query.ColumnSet = new AllColumns();


query.EntityName = EntityName.account.ToString();


 


// The query returns all accounts where address1_city is Madrid


// and address1_country is España.


query.Attributes = new string [] {«address1_city», «address1_country»};


query.Values = new string [] {«Madrid», «España»};


 


Si necesitamos condiciones más complejas tendremos que usar un objeto del tipo QueryExpression. Este tipo de objetos de consulta dispone de una propiedad Criteria, que nos permite utilizar objetos FilterExpression para crear condiciones de filtrado más complejas. Y de la propiedad LinkEntities que nos permite establecer filtros con Joins sobre otras entidades. Por ejemplo, podemos crear una consulta con la que obtener el nombre y el identificador de las cuentas cuyo dueño no tenga como apellido Amoedo.









 


// Return Accounts whose owner’s last name is not Amoedo


// Create a column set that holds the names of the columns to be retrieved.


ColumnSet cols = new ColumnSet();


 


// Attributes that we want to retrieve.


cols.Attributes = new string [] {«name», «accountid»};


 


// Create the condition expression.


ConditionExpression condition = new ConditionExpression();


 


// Set the condition for the retrieval to be when the last name of the account’s owner is not Amoedo.


condition.AttributeName = «lastname»;


condition.Operator = ConditionOperator.NotEqual;


condition.Values = new string [] {«Amoedo»};


 


// Build the filter based on the condition.


FilterExpression filter = new FilterExpression();


filter.FilterOperator = LogicalOperator.And;


filter.Conditions = new ConditionExpression[] {condition};


 


// Create a LinkEntity to link the owner’s information to the account.


LinkEntity link = new LinkEntity();


 


// Set the properties of the LinkEntity.


link.LinkCriteria = filter;


 


// Set the linking entity to be the account and set the linking attribute to be the owninguser.


link.LinkFromEntityName = EntityName.account.ToString();


link.LinkFromAttributeName = «owninguser»;


 


// Set the attribute and entity being linked to.


link.LinkToAttributeName = «systemuserid»;


link.LinkToEntityName = EntityName.systemuser.ToString();


 


// Create the query.


QueryExpression query = new QueryExpression();


 


// Set the properties of the query.


query.EntityName = EntityName.account.ToString();


query.ColumnSet = cols;


query.LinkEntities = new LinkEntity[] {link};


 


Sobre QueryExpression y QueryByAttribute hay que comentar un par de cosillas más. Como la existencia en ambos tipos de objeto de la propiedad PageInfo, que permite recuperar los resultados página a página según el tamaño de página que indiquemos. Y también, la posibilidad de utilizar el método Execute para realizar consultas mediante el mensaje RetrieveMultipleRequest.


 


Fecth


Este método, al contrario que RetrieveMultiple, no utiliza tipado “fuerte” para consultar datos. En vez de utilizar objetos para construir las consultas, utilizamos un lenguaje de consulta llamado FetchXML, y en vez de obtener una BusinessEntity Collection como resultado, obtenemos un documento XML. Con esto conseguimos una mayor flexibilidad, a cambio de una mayor “complejidad” a la hora de crear las consultas. Digo mayor complejidad, porque normalmente es más sencillo construir una consultar mediante objetos query que mediante FetchXML, y por que puede resultar más cómodo obtener los resultados como una colección de objetos que como un documento XML.


Sin embargo, gracias a la ausencia de tipado fuerte, tenemos algunas ventajas como el poder recuperar columnas de más de una entidad. Es decir, el resultado de la consulta puede mezclar datos de varias entidades, cosa que no se puede hacer con RetrievMultiple. Vamos, que tenemos las mismas posibilidades para hacer joins que en SQL.


Por ejemplo, veamos como quedaría la consulta que anteriormente hacíamos con una QueryExpression utilizando FetchXML.









// Retrieve all accounts where the last name is not Amoedo.


string fetch2 = @»


<fetch mapping=’logical’>


<entity name=’account’>


<attribute name=’accountid’/>


<attribute name=’name’/>


<link-entity name=’systemuser’ to=’owninguser’>


<filter type=’and’>


<condition attribute=’lastname’ operator=’ne’ value=’Amoedo’ />


</filter>


</link-entity>


</entity>


</fetch>


«;


 


// Fetch the results.


String result2 = service.Fetch(fetch2);


 


Evidentemente, el código es menos extenso, pero como veis ahora la consulta no es más que un string con XML, con lo que perdemos las comprobaciones en tiempo de compilación propias del tipado fuerte. Además, los resultados también son un string con XML, con lo que para manejarlos tendremos que incluir más lógica.


Otra cosa muy interesante de FetchXML, que ya comentamos en el artículo sobre RSS, es que Microsoft Dynamics CRM almacena todas las consultas avanzadas y las consultas de las vistas del sistema como FetchXML, y como estas consultas son accesibles a través de los servicios web (entidad savedquery) tenemos un montón de ejemplos de consultas incluidas de serie en nuestro sistema.


Destacar también, que al igual que con los objetos Query, con FetchXML también es posible utilizar paginado.


RetrieveMultiple vs Fecth


Bueno, y después de todos esto ¿Cual usamos? Pues como buen gallego que soy ya sabéis la respuesta… Depende.


Vamos a repasar las principales diferencias primero entre ambos métodos:






















RetrieveMultiple


Fetch


Valores de retorno “fuertemente tipado”


Valores de retorno NO fuertemente tipados


Consultas construidas con objetos tipo Query


Consultas construidas con FecthXML


Centrado en Business Entities, devuelve valores de una única entidad


Business Entities agnóstico, puede devolver valores procedentes de atributos de varias entidades


Soporta Join (pero solo para filtrado)


Soporta Join


 


A la vista de las diferencias, la idea queda más o menos clara. Debemos tratar de utilizar RetrieveMultiple cuando queramos obtener resultados de fuertemente tipados, de una única entidad, y queramos realizar alguna operación sobre los objetos de negocio obtenidos, por ejemplo, recuperar las cuentas de una ciudad para asignárselas a un determinado comercial mediante los servicios web.


Sin embargo, Fetch será adecuado cuando necesitemos realizar alguna consulta para obtener una combinación de datos de varias entidades, cuando queramos guardar la consulta en un fichero de manera sencilla, cuando no necesitemos resultados fuertemente tipados, o incluso cuando obtener los resultados en XML sea una “obligación” para poder interoperar con otro sistema. Por poner un ejemplo de uso de Fetch, imaginad que disponemos de un servicio web que proporciona información sobre los productos en oferta a nuestros mayoristas, aquí podríamos utilizar un servicio web que utilice una consulta FetchXML, almacenada en un fichero XML, para obtener un documento XML para enviar como resultado a través del Servicio Web.


Compatibilidad de FetchXML y los objetos Query


Finalmente, decir que existe la posibilidad de hacer conversiones entre ambos formatos. Para ello, disponemos de los mensajes FetchXmlToQueryExpressionRequest y QueryExpressionToFetchXmlRequest, que utilizados con el método Excute de los servicios web nos permitirán convertir de un formato a otro. Aunque hay que tener cuidado, ya que la conversión no siempre es directa.


Para terminar


Existen trucos para construir consultas en FetchXML, como utilizar el editor de consultas avanzadas del propio Microsoft CRM, guardar la consulta, y luego recuperar el FetchXML a través de los servicios web o de las vistas Filtradas. Pero, no os preocupéis, próximamente veremos que existen herramientas para crear consultas FecthXML de manera sencilla.


Para obtener más información sobre todo esto, os recomiendo que echéis un vistazo al SDK. En especial a la sección Building Queries del apartado de desarrollo con los Servicios Web de Microsoft CRM.


Bueno, espero que este “rollo” haya sido de utilidad para alguien. Dejad los comentarios, dudas, sugerencias, quejas y demás que queráis.


Un Saludo,


Marco Amoedo Martínez




Feeds RSS en Microsoft Dynamics CRM, Solución de Problemas

Hace ya unos meses que tenemos disponible un pequeño gran add-in para Microsoft Dynamics CRM que nos permite mostrar información del CRM a través de feeds RSS. Aunque en principio la tecnología RSS fue concebida para la sindicación de noticias, es una idea aplicable a otros tipos de información, como viene a demostrar este ejemplo.


La verdad es que el concepto, contrariamente a lo que se pueda pensar, es muy interesante para dinamizar una implementación de Microsoft Dynamics CRM. Podemos disponer de información del negocio de manera dinámica sin ni siquiera tener que abrir el CRM, recibiremos información sobre nuevas oportunidades, nuevas cuentas, productos, nuevas incidencias, etc… directamente en nuestro lector de feeds. Nos mantendremos actualizados de la nueva información importante que se introduzca en nuestro sistema CRM.


Por poner un ejemplo, que seguro que ya se os están ocurriendo un montón, imaginad un agente de servicio técnico que trabaja todo el día a través de Outlook con el cliente de CRM instalado, para ese agente sería genial tener un feed RSS que le avisase de las nuevas incidencias que se la han asignado, de nuevos artículos interesantes en la base de conocimiento, y todo ello automáticamente sin tener que preocuparse. Y además sin salir de Outlook, por que aunque hay buenos clientes RSS externos a Outlook, también tenemos clientes como IntraVnews para Outlook 2003, y Outlook 12 (Office 2007) que ya trae incluido un lector de RSS; aunque todavía no se puede utilizar con Microsoft CRM.


Funcionamiento y Seguridad


La versatilidad de este add-in es increíble por su forma de crear los feeds RSS. Pone a nuestra disposición un hilo rss por cada vista que tengamos disponible en el sistema, por ejemplo: Mis Citas, Cuentas activas, Mis casos, etc. , lo que nos permite crear feeds RSS a placer ya que las vistas son personalizables. Pero eso no es todo, los usuarios también puede personalizar su experiencia con los feeds ya que ellos mismos los pueden crear guardando su consultas avanzadas.


¿Cómo consigue esto? Pues seguro que ya lo habéis adivinado, gracias a los Servicios Web y el al hecho de que todas las vistas y consultas pueden ser obtenidas de ellos. Estas consultas se guardan en formato Fetch XML (del que hablaremos otro día) lo que permite al add-in utilizarlas directamente en el método Fetch de los servicios web para obtener la información de los feeds.


 En cuanto a la seguridad podemos estar tranquilos, por que utiliza impersonación en las llamadas a los servicios web, con lo que los usuarios sólo podrán acceder en el RSS a la misma información que su rol en Microsoft Dynamics CRM le permita.


La instalación y el Problema


El addin CrmRssFeeds, lo podéis descargar siguiendo el enlace, es en realidad una pequeña aplicación web que incluye unas páginas aspx para la generación de los feeds. Incluye todo el código, lo que como veremos no solucionará un problema, y un sencillo pero muy descriptivo manual de instalación. Que básicamente nos guiará en la compilación y el despliegue de la aplicación.


El principal problema que podemos tener si seguimos al pie de la letra los pasos del manual es que vamos a encontrar una Excepción en la llamada a los servicios web ¿Por qué? Pues porque en ningún sitio hemos puesto la url de nuestros servicios web. La url se encuentra configurada en el propio código de los proxys de los servicios web (tal y como la deja Visual Studio por defecto), con lo que para cambiar la configuración debemos modificar la url en los ficheros crmservice.cs y metadataservice.cs.


Otro problema con el que me he encontrado, es que mucha gente ignora el aviso de que hay que compilar la aplicación con .Net Framework 1.1 y utiliza el prompt de Visual Studio 2005. Si compilamos con .Net 2.0 el rss funcionará correctamente, pero, Microsoft CRM no lo hará y encontraremos errores como que no se puede mostrar el calendario de servicios. Esto se debe a que al hacer esto el pool de aplicaciones de Microsoft CRM será reasignado a la versión 2.0 de ASP.NET. Si llegais a esta situación tendréis que cambiar manualmente la configuración del pool en el administrador de IIS. Para evitar este problema basta con asegurarse de utilizar la versión 1.1 de .Net con el compilador de C#, por ejemplo, modificando el make.bat para que utilice obligatoriamente la versión correcta indicando el path completo C:WINDOWSMicrosoft.NETFrameworkv1.1.4322csc /out:RSSServices.dll /target:library MetadataCache.cs MetadataService.cs CrmService.cs


Versión Modificada


Como el CRM Rss está publicado con código abierto bajo una licencia de código fuente, me he permitido el lujo de modificarlo. Espero no estar infringiendo ningún acuerdo de licencia, que por lo que he leído me parece que no.


La modificación que he hecho es una tontería para evitar los problemas que he descrito:




  • Añadir un web.config con dos entradas de configuración de la aplicación CRMServiceUrl y MetadataServiceUrl.


  • Modificar los proxys de los servicios web para que utilicen esas entradas de configuración.


  • Modificar el readme para avisar de estos cambios


  • Modificar el make.bat para incluir la ruta completa al compilador adecuado de C#.

Podeis descargarla desde geeks, CRM Rss Connector Modified by Marco.


Conclusiones


El soporte para Rss en Microsoft Dynamics CRM 3.0 es una herramienta increíble que nos proporciona un dinamismo inimaginable en nuestra implementación de Microsoft Dynamics CRM, y lo hace de la forma más sencilla posible. Además, es otro gran ejemplo de las cosas que podemos construir utilizando el SDK de Microsoft Dynamics CRM.


¿Qué os parece la disponibilidad de feeds rss en aplicaciones de negocio como CRMs? ¿Creis que con esto acercamos la tecnología al usuario? ¿Me meteré en un lío por modificar el CRM Rss Feed Connector?


Un Saludo,


Marco Amoedo Martínez


Fechas para el Update Rollup 1 de Dynamics CRM 3.0

Este pasado viernes aparecía un post en el Blog del equipo del Microsoft Dynamics CRM en el que se hablaba la disponibilidad de un artículo de la base de conocimiento de Microsoft, que muchos ya conocíamos, que contiene todos los updates & hotfixes disponibles de Microsoft Dynamics CRM 3.0.


Lo interesante de este artículo, además de las definiciones de lo que es un update y un hotfix, es la mención de la posible liberación del Update Rollup 1 for Microsoft CRM 3.0 a finales de Octubre. Sin duda, los que a menudo curioseamos los artículos sobre CRM 3.0 en la base de conocimiento ya nos preguntábamos cuando tenían previsto este rollup, y es que ya hay un montón de artículos de solución de problemas.


Además en ese artículo se hace mención a otro gran trabajo sobre Microsoft Dynamics CRM 3.0 que verá la luz dentro de pocos meses, se trata de Microsoft CRM 3.0 Performance Whitepaper. En este documento se explicarán muchos temas sobre como afinar el rendimiento de nuestro CRM 3.0, al igual que ya se había hecho con la versión anterior. Tendremos que permanecer atentos.


Personalmente creo que el equipo de soporte de Microsoft CRM 3.0 está haciendo un gran trabajo, no hay más que consultar la base de conocimiento y otros artículos para darse cuenta del gran esfuerzo que han hecho para resolver rápidamente todos los problemas que han ido apareciendo. Os recomiendo a todos que cuando tengáis algún problema probéis a buscar en la Base de Conocimiento de CRM 3.0, ya que es posible que encontréis la solución, y si no en las news hay mucha gente dispuesta a ayudar.


Saludos,


Marco Amoedo Martínez

Reorganización del equipo de Microsoft Dynamics

Hace unos días que se anunciaba oficialmente que el equipo de Microsoft Dynamics CRM se reorganizaba para incluirse dentro de grupo de Microsoft Office. Este movimiento según, según cuenta Philip Richardson en su blog, no supondrá ningún cambio para los planes existentes sobre Microsoft Dynamics CRM. Y como podemos leer en el blog del equipo del CRM tampoco lo desliga de Microsoft Business Services, a la que seguirá muy unido para armonizar en la familia de productos Dynamics. Además hay que recordar que Microsoft Office se encuentra dentro de Microsoft Business Division, con lo que seguirán teniendo a Jeff Rikes como presidente.


Aunque esto de las reorganizaciones y divisiones de Microsoft es un lío, que la verdad es que hay tantos equipos, grupos, divisiones y demás que nos perdemos. La idea que podemos sacar de esta noticia está muy clara: Hay que hacer que las aplicaciones de gestión empresarial se integren en el trabajo diario para poder sacarles partido. Y como Office es la base del trabajo diario en la mayoría de las empresas, es ahí donde hay que integrar la potencia de Dynamics. Ya teníamos el primer acercamiento con uno de los puntos fuertes de Dynamics CRM, los clientes para Outlook que permiten utilizar una herramienta CRM en el entorno de trabajo habitual del personal de Ventas, Marketing y Servicio. Y el CRM SnapIn que ya nos permiten una integración con Office. Pero la idea es ir más allá, y llegar a integrase mucho más con otros productos como Sharepoint o Microsoft Project.


Si recordáis la estrategia que Microsoft planteaba en el Proyect Green (Microsoft Dynamics) tenía uno de sus puntos fuertes en centrarse en los usuarios, y este es claramente un movimiento más dentro de esa estrategia. Si algo caracteriza a Microsoft Dynamics CRM, es la capacidad para superar el problema de no aceptación de los usuarios gracias a la facilidad de uso y a su integración con el trabajo diario, integración que no sería posible sin convivir con Office. Por lo tanto parece que este movimiento puede ser un gran acierto.


¿Qué os parece esta reorganización? ¿Alguno tiene claro las divisiones y grupos de Microsoft y se anima a hacer un esquema? Creo que ni en Microsoft lo deben tener muy claro.


Hasta la próxima,


Marco Amoedo Martínez

El CRM, the next Billion Dollar Baby

Hace unos días aparecía una noticia en CRN en la que se podía leer que varios ejecutivos de Microsoft consideran a Microsft Dynamics CRM el siguiente billion dollar bayby, es decir, que el CRM se convertirá en el nuevo superventas de la compañía, aunque sin alcanzar los niveles de Office.


La verdad, es que después de un comienzo suave con sus dos primeras versiones, las cifras de la versión de Dynamics CRM 3.0 asustan: 7.000 clientes, y 180.000 usuarios de los cuales 50.000 se han incorporado en el último cuarto. Un crecimiento impresionante, y más teniendo en cuenta que aún se está completando la liberación de versiones localizadas, creo que todavía faltaban el Japon e Israel y acaba de salir la China.


De esta noticia y los comentarios que hacen en Microsoft, podemos extraer la conclusión de que en la compañía tienen muchas expectativas puestas en Dynamics CRM y se está haciendo un gran esfuerzo por sacarlo adelante. Y la verdad es que de momento parece que los clientes les están dando la razón.


¿Qué os parece la noticia? ¿Llegará el CRM a convertirse en una aplicación presente en todas las empresas como el Office?

Novedades en Dynamics CRM, CRM Live y un Nuevo Cliente Móvil

La noticia que tratamos saltaba ayer mismo en la conferencia mundial de partners, Microsoft ha anunciado la disponibilidad de Microsoft CRM live para el próximo año 2007. Y diréis, ¿Qué es eso de CRM Live? Pues la verdad es que aún está por ver claramente, pero la idea es proporcionar una versión de CRM siguiendo el modelo de Software-as-a-Service (SaaS) en el que Microsoft alojaría el CRM en sus datacenters y los clientes podrían utilizarlo tanto con cliente Outlook como con navegador web. Esta idea no es nueva, de hecho a una edición de Microsoft Dynamics CRM 3.0 for Service Providers cuyo objetivo era soportar el modelo de SaaS, en el que el cliente utilizaría un despliegue de CRM alojado en las instalaciones de un Partner, y por el que se cobrarían cuotas mensuales.


La novedad de CRM Live es el hecho de que Microsoft proporcionará su propia infraestructura para dar hosting al CRM, y que según se puede entender en la noticia toda la base de código de esta versión será la misma que las existentes con lo que los ISV’s pueden estar tranquilos ya que sus desarrollos y personalizaciones para Microsoft Dynamics CRM serán compatibles en todas las versiones.


Bueno ¿Y entonces que opciones tendremos para desplegar Dynamics CRM? pues principalmente tres:




  • Que el cliente lo tenga en sus propias instalaciones (la tradicional), conocida como On-Premise (disponible).


  • CRM ejecutándose sobre los servidores de un partner, llamada Partner Hosted (disponible).


  • CRM Live, en la que Microsoft mantendría el CRM en sus datacenters (en 2007).

En principio según se comenta en el artículo todas las versiones podrán ser personalizadas y extendidas siguiendo los métodos soportados, aunque no veo claro como se harán en la plataforma live cierto tipo de personalizaciones como extensiones con .Net Framework. Pero seguro que ya tienen algo pensado, o están en ello.


Entonces, si las tres se pueden personalizar y extender, la pregunta es: Si Microsoft ofrece CRM live, es decir, CRM en hosting ¿Qué van a hacer los partners que ofrecen hosting de CRM? Pues la respuestas es que los partners seguirán ofreciendo hosting pero de soluciones CRM con algún valor añadido, como comercio electrónico integrado, o verticalizadas para algún sector en particular.


Cliente Móvil y otras novedades


Adicionalmente al anuncio de CRM Live, se han hecho públicas otras novedades sobre Microsoft Dynamics CRM en la Worldwide Partner Conference 2006. Las más llamativas un nuevo cliente para dispositivos móviles de Microsoft Dynamics CRM en código abierto, y nuevo conector para Bizztalk que permitirá al CRM comunicarse con otros ERPs y CRM’s de terceros.


Lo más llamativo para mí es el anuncio del nuevo cliente para dispositivos móviles en código abierto. ¿Qué pasa con la que ya existía? Y además anuncian el lanzamiento para agosto, o sea, que pronto lo veremos. Habrá que mantenerse atentos.


Comentarios del equipo del CRM


Por otra parte, en el bog del equipo del CRM, también comentan el anuncio de CRM Live y hablan de que no sólo se trata de proporcionar soporte de SaaS, que la siguiente versión incluirá más novedades como soporte multilingüe, más opciones de personalización, mayor integración con office… etc. Además en el post hablan de que a finales de este año saldrán las pre-releases de las nuevas versiones y de CRM Live.


¿Qué os parecen las novedades? ¿CRM Live intentará atacar el nicho de mercado de aplicaciones como salesforce.com? ¿Y no me diréis que no os sorprende un nuevo cliente móvil en código abierto? Estoy deseando verlo.


Un Saludo,


Marco Amoedo Martínez

Microsoft entra en la F1

Microsoft ha ganado la licitación internacional hecha por la FIA para elegir un proveedor en exclusiva de ECU’s (Electronic Control Units) para todos los equipos de F1 entre 2008 y 2010. Las ECU’s son las centralitas electrónicas que los equipos utilizan para telemetría y ajuste de algunos reglajes del coche. Hasta ahora la principal empresa proveedora de ECU’s era Magneti Marelli, con 5 equipos entre los que destacan Renault y Ferrari. La cual se quedará fuera del negocio con este nuevo contrato en exclusiva.


Esta decisión se enmarca dentro de un paquete de medidas para intentar abaratar radicalmente los costes en la F1, y afecta a otros componentes de los coches de F1 como las ruedas. De las que Bridgestone será el proveedor en exclusiva, dejando a su rival Michelin fuera de la F1, ya a partir de la siguiente temporada.


Microsoft entra en este negocio sin tener demasiada experiencia previa en el desarrollo de este tipo de sistemas de control. Esperemos que los de Redmond sepan lo que hacen y no veamos a Fernando Alonso cambiando la célebre frase “trata de arrancarlo”, popularizada por Carlos Sainz, por la de “trata de reiniciarlo”. Os imagináis: “Su coche ha detectado una operación no valida y se apagará. ¿Desea enviarle un informe de errores a Microsoft?”.


Y ahora viene lo divertido, buscarle la relación a esta noticia con Microsoft Dynamics. Pues aunque es una tontería hay una. Marcas como SAP, rival directo de Microsoft Dynamics, llevan años con presencia en la F1 como sponsors de equipos mientras que Microsoft fiel a sus orígenes americanos ha ignorado en gran medida este escaparate. Sin embargo con este nuevo contrato Microsoft entra a lo grande en la F1.


Bueno, ¿Qué os parece? ¿Acabará Alonso corriendo en Microsoft F1 Team?


Marco Amoedo


Fuente