¿Qué tipo de tecnología sustenta un modelo de negocio digital?

  • Negocio digital
por

Cuando hablamos de vender por Internet (ecommerce) existen numerosas herramientas que resuelven con eficiencia y escalado las necesidades de gestionar un catálogo, enriquecer un proceso de compra, promocionar productos y servicios, manejar distintos precios, mercados y monedas…

Por ello, ante un proyecto de este tipo abundan las respuestas sencillas tipo:

“Esto ya está inventado, tira de herramientas que te lo den todo hecho, que sean muy baratas y sencillas de montar, que utilice ya mucha gente. El valor no está en la tecnología sino en tu capacidad de enganchar con las necesidades de los clientes”.

Pero en una estrategia más global como la descrita en el post anterior, donde no sólo nos centramos en la capacidad que nos ofrece el canal sino en su potencial como elemento transformador de un sector o negocio, normalmente requiere de otros aspectos que van más allá de los puntos identificados. Una mayor flexibilidad.

La solución estándar, esa que se monta en un suspiro y a la que se suele aplicar alguna plantilla, puede ser una buena solución en los inicios de un negocio, sobre todo para testar el modelo o la propuesta en plan low cost.

¿Pero qué pasa cuando necesitas modificar la propuesta, en base a tus métricas de negocio, las pistas que te da el mercado o el comportamiento de tus clientes?

Que todo empieza a crujir y los cambios a incorporar a la herramienta implantada o bien son parches insufribles o suponen costes no esperados que amenazan la viabilidad del negocio.

Cada vez nos encontramos con más escenarios de este tipo. La respuesta suele ser que estamos siguiendo los preceptos de moda, esos vinculados al concepto de lean startup, y que cuando confirmemos el gran potencial del negocio ya invertiremos y revisaremos todo el modelo tecnológico.

El problema es que rara vez se da ese momento de eclosión en el que la situación del negocio te dice:

Ya está, la estoy petando, me está entrando dinero a chorros y ahora es cuando voy a tirar lo que tengo y hacerlo de nuevo como debe ser.

Normalmente hay una progresión en el negocio, más o menos rápida, pero que genera unos niveles de caja que permiten seguir invirtiendo con medida y precaución y que por tanto limitan a la hora de rehacer lo que hemos planteado inicialmente.

El proceso de amortización de la herramienta no siempre es tan rápido como se espera.

Además rehacer lo que se tiene supone un esfuerzo y dedicación importante, que hay que compaginar con la explotación cotidiana del negocio. En otras palabras, nos lleva a un periodo de MUCHO SUFRIMIENTO.

La alternativa no requiere necesariamente acudir a largos proyectos iniciales, más costosos, con herramientas pesadas, etc.

Sobre todo lo que hace falta es tener una visión global del objetivo que se persigue, las cosas que nos gustaría que pasasen en el negocio, las que son más previsibles y elegir la tecnología a utilizar en base a ello y sobre todo en base a la flexibilidad que nos dé.

Innovar o plantear un modelo más global requiere muchas veces salirse de la caja, romper con las prácticas de otros o modelos ya establecidos, y es en estas ocasiones donde se hace necesario contar con herramientas que te permitan hacer cosas distintas con facilidad.

 

 

¿Qué estrategia tiene sentido?

La podemos resumir en los siguientes puntos:

  1. Conviene contar con tecnología versátil para resolver el núcleo del proyecto que combine fácilmente y con costes ajustados la funcionalidad de:
    • Un ecommerce
    • Una potente herramienta de gestión de contenidos
    • La posibilidad de incorporar funcionalidad de lo denominado Social Business Software

    modelotecnologico

     

  2. Deberán tener una amplia comunidad detrás que nos permita contar siempre con abundantes proveedores y especialistas que estén cualificados, bien para contratarlos, bien para incorporarlos en la compañía para llevar el día a día y ganar en flexibilidad.
  3. Esta amplia comunidad o soporte permitirá mantener la herramienta viva, de manera que nos pueda aportar cada vez más valor, con funcionalidad nueva, optimizando la existente, adaptándose a nuevos dispositivos, versiones de navegadores, de sistemas, etc.
  4. Integración demostrada y contrastada con sistemas de información y gestión ya existentes en una organización, con especial atención a CRM y ERP.
  5. Un modelo que además se complemente con herramientas de nicho muy especializadas que preferentemente se incorporen en modo SaaS o Cloud, que sobre todo se orienten a recabar información de valor de nuestros clientes y poder servirles contenidos y propuestas pertinentes de forma dinámica y afinada. Por poner ejemplos: soluciones de analítica, de inbound marketing, de gestión de clientes (CRM), retargeting, encuestas, foros, personalización en la presentación de contenidos en base a perfiles de uso…
  6. Sin olvidar aspectos más manidos y convencionales pero igualmente necesarios: escalabilidad demostrada, coste de adquisición bajo, coste de mantenimiento conocidos y previsibles.
  7. Por último, un entorno tecnológico que, cuando lo requiera el negocio y su evolución, permita desarrollar funcionalidad ad hoc con calidad, motivar perfiles profesionales que busquen la excelencia y que con sus aportaciones entreguen ese valor necesario y diferente que pueda hacer que un negocio funcione de verdad.

 
Fuente de la imagen: Acquia.

Comentarios

  1. Jose Pita

    30 Septiembre 2014

    El planteamiento del post me parece acertado y yo iría incluso un poco más allá al decir que una plataforma hiper-popular con un plantillazo no suele ser la respuesta tecnológica cuando hay un análisis previo con una profundidad mínima.

    En el proceso de análisis previo casi siempre van a salir necesidades del negocio que requerirán tanto adaptaciones funcionales de la plataforma como especificaciones de diseño que nos marquen requisitos que no es habitual que estén disponibles, al menos todos juntos, en las plantillas habituales y que a nivel de desarrollo requieren de plugins de terceros que muy dudosa calidad o simplemente no existen.

    Es posible que podamos partir de una plantilla como base si tenemos poco presupuesto pero no es posible que no requiera ni una sola modificación, adaptación o mejora… y en muchas ocasiones ahí empieza a salir cara la plantilla.

    Ahora bien, sobre los 7 puntos o requisitos que indicas sobre la plataforma tecnológica ¿Dónde está ese unicornio? ¿Alguien lo ha visto? Yo todavía no lo he encontrado.

    • Diego Cenzano

      30 Septiembre 2014

      Gracias por tu comentario. Efectivamente, como bien dices no resulta fácil encontrar una solución que resuelva lo que describo en el post. Pero mi sensación es que hay distintos frameworks que van en la buena dirección. Nosotros en Biko hemos identificado Drupal como una vía con mucho potencial. Nos da mucho de partida y si tienes un buen equipo técnico que se haga con la solución te permite personalizar y afinar muchas cosas. Estamos montando grandes portales, soluciones de ecommerce y algunas herramientas de trabajo colaborativo que aprovechan funcionalidad de comunidades. También lo hemos integrado con SAP, Salesforce, Hubspot y otras soluciones de una manera bastante rápida.

  2. Jose Pita

    30 Septiembre 2014

    Uy, esto da para un largo debate, pero no quiero dejar de contestarte:

    Frente a tu propuesta de “un Framework para gobernarlos a todos”, en este caso Drupal, yo opto por la vía contraria: soluciones tecnológicas más especializadas integradas entre sí (por ejemplo.: Magento o Prestashoip + WordPress / + Zendesk), y aquí la clave esta en la capacidad de integración, que sean plataformas abiertas, con API’s potentes, abiertas y documentadas.

    No entro a defender si es un modelo u otro porque, como siempre, no hay una verdad ni una mejor solución. Creo que cada equipo / empresa en base a sus perfiles, capacidades y filosofía de trabajo se adaptará y hará mejores productos con el modelo al que esté mejora adatado.

    Sin profundizar mucho y simplificando demasiado, me gustaría apuntar que el modelo “Framework general” tiene la gran ventaja de que el cliente trabajará siempre con la misma herramienta pero la desventaja de la herramienta será muy buena para unas cosas y peor, incluso mala, para otras. El modelo de “soluciones especializadas” hace que el cliente tenga que trabajar con una diversidad de entornos que aveces puede ser agobiante, pero nos aseguramos de que cada herramienta hace bien lo que tiene que hacer.

    Lo que digo lo hago desde la experiencia de haber estado en los dos lados. En el caso de los Framework nosotros hemos trabajado muchos años con Typo3 y también bastante con Drupal…. en ambos casos nos encontramos con la realidad descrita de que para ciertas partes de la solución que necesitaba el cliente las propuestas que ofrecían eran malas o peores.

    Interesante debate…

    PD: Por lo que sé y en base a la gente que se ha decantado por Drupal, estoy seguro de que hoy en día debe ser un Framework muy potente y que si se tiene los técnicos adecuados (mucha experiencia) las integraciones son rápidas; pero mi experiencia particular, en la época de Drupal 4 / Drupal 5 fue bastante negativa y mis opiniones al respecto no van a ser objetivas, mejor me las callo 😉

    • Diego Cenzano

      30 Septiembre 2014

      Efectivamente es un largo debate. Sobre el modelo que planteas, me parece muy interesante, aunque el principal problema que tiene son los costes ocultos que tiene para los clientes en mantenimiento de distintas plataformas, integraciones, etc. un escenario que suelen generar mucha frustración.

      En cuanto a Drupal, nosotros nos enganchamos al modelo a partir de la versión 6, antes no nos atrevimos con ello. Igual tu orientación pionera te jugó una mala pasada 😉 Antes tirábamos de desarrollos propios. Hoy en día podemos decir que ha sido una decisión muy acertada que nos está dando a nosotros y a nuestros clientes grandes resultados.

    • karlos g liberal

      7 Octubre 2014

      Interesante debate

      Estoy de acuerdo en que “un Framework para gobernarlos a todos” es un tema delicado. Como bien dices en nuestro negocio no existen la balas de plata y eso que yo no paro de buscarlas. Pero es cierto que tampoco encajan bien la generalidades.

      Un framework “clásico” al estilo, rails, symfony, zend, puede y debe ser la respuesta en algunos casos. Como lo son las “soluciones tecnológicas más especializadas” que comentas.

      Pero en estos momentos la importancia de la gestión de contenidos en los proyectos digitales hace que tanto el framework clásico como la solución especializada muchas veces no encajen.

      Creo que este es el motivo por el cual Drupal tiene tanto éxito. Drupal es un framework pero IMHO no un framework enfocado en la funcionalidad sino un framework enfocado en la gestión de contenidos y en eso es donde reside todo su potencial.

      Por último, te fuiste de drupal en el momento del cambio, yo empezé con la la 4.6 y ahora que estamos en la 7 (casi en la 8) y los cambios son notables, aparte del crecimiento en forma de negocio de la comunidad Drupal

      Salud

  3. Sten Svensson

    8 Octubre 2014

    Este es un problema sin solución.

    O, si se prefiere, digamos que no hay una solución única o idónea, sino que uno debe ceñirse a las características técnicas de los productos que elige. Y debe escoger una estrategia que explote las ventajas y minore o eluda las desventajas de esos productos. Lo contrario, un comportamiento errático, es cortejar el desastre.

    Aquí entra el papel del CTO: no es un tipo (o tipa) que sabe programar a saco. Es alguien que debe entender la estrategia general de su empresa y proponer una hoja de ruta tecnológica que encaje con esa estrategia y con el medio en que se desenvuelve la empresa. Y, lo que es más difícil, hacerse entender con el CEO.

    Sin entrar en nombres, el CEO debe entender las implicaciones de los productos escogidos. Una lista somera de criterios que un jefe entenderá fácilmente.

    • qué tipo de proveedores le pueden acompañar;
    • si estos proveedores estarán muy ocupados con clientes más jugosos;
    • si se pretende conseguir desarrolladores expertos en el mercado local de provincias para incorporarlos a la plantilla y con qué sueldos;
    • si, por el contrario, se espera recurrir a consultores patanegra de a mil euros la jornada;
    • el tiempo de amortización esperado encaja con el ritmo de discontinuación de la tecnología;
    • la orientación a proveedores de licencias o de servicios (los jefes, por más que sean atecnológicos, entienden instintitvamente las servidumbres de estos modelos);
    • si la inversión en eficiencia va a enfatizarse en el desarrollo interno, en la red comercial (extranets), o directamente de cara al público;
    • si el turnover del producto o servicio y la volatilidad del mercado implican hacer cambios rápidos;
    • cuál va a ser el modelo de mantenimiento y si se depende del tráfico generado y, a su vez, este varía con ignotos requerimientos de terceros (SEO) y modas, por lo que hay que cambiar con frecuencia;
    • si el nivel de gasto y renovación tecnológica están en consonancia con el sector y cuadran con las tendencias previstas.

    Y así. Casi nada.

    Cualquiera que sea la solución escogida, framework, integración, plantilleo, etc, debe despejar convincentemente estas incertidumbres, porque debe jugar con ellas, a poder ser a favor, nunca en contra.

    Si hubiera que traducirlo a un lenguaje moderno, lo pondría así: ¿Cuánto vas a gastarte de forma eficiente y en cuánto tiempo debes amortizarlo?. En Biko nos ha ayudado indentificar los criterios que Diego expone ahí arriba. Pero como digo al principio, no hay una solución única.

    [Post scriptum: me edito y completo, que para eso soy el webhamster de este lugar]

Deja tu comentario