"Nuestras herramientas no prometen, cumplen"
Gabriel Martin, director general de Mercury Interactive
Mercury Interactive se instaló en España hace algo más un año, ¿podría hacer un breve balance de cómo ha sido su evolución?
- Durante este año lo que hemos desarrollado básicamente ha sido la creación de una fuerza de venta directa, además de toda la labor que supone la puesta en marcha de la subsidiaria. En este sentido, nuestra primera acción se centró en trabajar sobre la base de clientes que tenía nuestro distribuidor con el objetivo de ofrecer un mejor servicio a los clientes. Me explico, nuestro distribuidor desarrollaba una excelente labor, pero que en general no iba más allá de lo que podía ofrecer cualquier distribuidor en líneas generales.
¿Cómo está estructurada la política de alianzas de Mercury?
- Tenemos dos tipos de alianzas, una con los fabricantes de software tipo Siebel, SAP, Oracle..., y por otro lado, tenemos las alianzas con integradores como por ejemplo con Accenture, que es a nivel mundial, y al mismo tiempo también estamos abriendo alianzas con integradores grandes pero más locales. La razón es que en el mercado de BTO (Business Technology Optimization) queremos reproducir exactamente el modelo que llevó al éxito a SAP o a Siebel, y ahí el éxito dependió mucho de los integradores.
Mercury Interactive decidió instalarse en el mercado español en un momento en el que la crisis era ya una realidad, teniendo en cuenta que su empresa aborda el mercado BTO en el que ya operaba su competencia más directa ¿cómo ha logrado posicionarse en este mercado?
- El equipo que formó Mercury tenía y tiene una gran credibilidad en los clientes. No hay que olvidar que nosotros fuimos los que creamos la división de cliente/servidor de Compuware. Hicimos mucho ruido y la credibilidad que conseguimos en ese momento fue la que nos sirvió para años más tarde montar Mercury. Eramos las mismas personas, con las mismas ilusiones pero con unas herramientas mucho mejores.
En una intervención suya llegó a asegurar que en España se malgasta muchísimo dinero.
- Eso es cierto, aún así quiero dejar claro que la informática se ha decantado por una altísima tecnificación orientada a sistemas, en cambio en Mercury lo que promulgamos es una orientación hacia lo que se entiende como proyecto de negocio que es lo que verdaderamente importa. De hecho, toda aplicación responde siempre a unos procesos de negocio críticos que dan soporte a un proceso de negocio, y así es como hay que entenderlo. Y es en este contexto en el que opera Mercury, y en este sentido, opinamos que en un momento de recesión como el actual lo que las empresas quieren es precisamente hacer más con menos, y para ello requieren de herramientas que sean eficaces.
¿Se puede afirmar que las herramientas actuales son por lo general poco eficaces?
- No, lo que ocurre es que cuando se compra una herramienta la labor de ponerla en producción es altamente dificultosa y costosa. En cambio, las herramientas de Mercury funcionan siempre, y ésta es una de las claves de nuestro éxito. Me explico, llevamos más de cinco años vendiendo herramientas de testing, algo que nos costó realmente mucho, ya que nos vimos obligados a realizar a priori una labor evangelizadora, puesto que la mayoría de las empresas no entendían la necesidad de disponer de ellas. Hasta ese momento, las labores de testing las realizaban de forma manual que suponían un alto coste.
¿Por qué un cliente elige Mercury y no a un competidor?
- Nuestro eje estratégico es realizar operaciones comerciales muy cualificadas y, además, intentamos solucionar la necesidad del cliente pero no la táctica sino la estratégica, y ésta siempre va encaminada a reducir costes. Por lo tanto, hay que ser capaces de encontrar ese punto en el que el cliente vea resuelta su problemática estratégica. De hecho, nuestra venta siempre es personalizada a cada cliente, no nos limitamos a presentarles nuestra herramienta.
¿Se podría decir que el diferencial de Mercury está en esa capacidad de adaptación al cliente más que en la propia tecnología?
- Los productos de Mercury son espectacularmente buenos, y esto nos permite tener una confianza ciega en satisfacer al cliente desde el punto de vista técnico. Pero además, damos muy buenas soluciones que atacan directamente el problema de la empresa en cuestión. El problema del cliente lo hacemos nuestro, y lo resolvemos de forma real en un periodo de tiempo muy corto. Algo que se resume en problema=solución, y esto es algo que satisface plenamente a los clientes. Tenemos una tasa de renovación de mantenimiento superior al 90%, y esto lo que deja al descubierto es que nuestras herramientas no prometen, sino que cumplen.
¿La operativa comercial de Mercury es básicamente proactiva, en el sentido de que las empresas todavía no demandan este tipo de herramientas?
- Nuestra labor es fundamentalmente proactiva, pero las empresas sí saben lo que necesitan. El problema es que hemos tenido cierta mala suerte. Me explico, cuando abrimos Mercury sabíamos que el testing estaba por explotar y en condiciones normales habría sido un mercado con un gran crecimiento, la dificultad ha estado ocasionada por los efectos de la crisis. Algo que si bien ha propiciado una concienciación en las empresas hacia el desarrollo de tareas de testing, se está viendo paralizada por una reducción de los presupuestos.
Si se entiende que las tareas de testing son fundamentales para el funcionamiento de la aplicación, ¿se puede asegurar que es algo que se está haciendo de forma generalizada?
- No, se están haciendo en un porcentaje realmente pequeño, y además se está haciendo de forma manual.
¿Dispone de algún dato que de forma explícita muestre la importancia de realizar tareas de testing en cualquier aplicación?
- Las estadísticas aseguran que cuando una aplicación se va a poner en producción en el 100% de los casos no soporta ni el 20% de la capacidad para la cual está diseñada. Es decir, que si una aplicación está diseñada para soportar 100 usuarios al ponerla en producción no llega a soportar ni 20 usuarios.
Cuando una empresa decide pasar una aplicación directamente a producción sin realizar tareas de testing, ¿qué costes se está ahorrando en un primer momento y qué costes le puede suponer a posteriori?
- Depende mucho de cada aplicación. Pero si hablamos de aplicaciones críticas hay que ser conscientes de que el probar una aplicación puede suponer en una aplicación media no más de 20 millones de pesetas. En cambio, el no probar esa aplicación puede suponer que realmente no funcione. De acuerdo con esto, cuando las empresas optan por esta segunda opción lo que hacen es ir parcheando la aplicación doblando el ha