Nos ocuparemos de cinco áreas técnicas en las que la experimentación puede ayudar a que las TI mejoren su posicionamiento en el negocio. Decida usted cuáles son las opciones más viables para su empresa.
Experimento de TI con bajo riesgo No. 1: API
Si bien cierta información es secreta, la mayoría de datos se enriquecen más mientras más circulan. De hecho, muchas compañías Web no tienen problemas en reconocer que comparten algunos de sus mejores datos con otras, incluso de la competencia. Lo que se necesita es comunicarse adecuadamente con sus API (interfaz de programación de aplicaciones, por sus siglas en inglés).
Incluso las más indigeribles reliquias del siglo XIX pueden salir ganando con una combinación correcta de datos a través de una API. Solo hace falta identificar la información que más buscan los clientes, y construir una API que brinde el dato correcto a la gente correcta en el momento correcto.
Por lo general, esta información ya se provee a través de una interfaz Web. Una API equivaldría a la misma información empaquetada en un formato amigable para el programador, como XML o JSON. Por ejemplo, un formulario de nuestro sitio Web puede ser redefinido como una llamada API para enviar información. Dicha API permitiría que nuestros socios de negocios automaticen el proceso de llenar y enviar el formulario, brindando, en adelante, un vínculo más profundo entre nuestro Website y el suyo.
Digamos que nuestra empresa requiere que los nuevos clientes se registren. Si convertimos este formulario de registro en una API, permitiremos que nuestros socios registren automáticamente a los clientes. De esta forma, los clientes obtienen acceso a los servicios de ambas compañías, mientras que ambas empresas logren incrementar significativamente sus bases de datos trabajando conjuntamente a través de esta API.
Aunque abrir funciones -como la de registro- es sencillo, hay otros recursos de datos que requieren más cuidado. De hecho, la automatización deja de ser buena cuando abre las puertas a spammers, bots, etc. Muchas API limitan la cantidad diaria de veces que un socio envía pedidos, una barrera simple que protege una relación mutuamente beneficiosa. Con el fin de simplificar algunos problemas que surgen cuando exponemos la información bajo la modalidad de API, algunas compañías, como Mashery.com, ofrecen autenticación y restricciones básicas.
El equipo de desarrollo de negocios puede resultar de gran ayuda para descubrir la mejor manera de trabajar con otra organización mediante las API. Una vez que el departamento de TI ha esbozado posibles atributos para la API, el equipo de negocios puede analizar el impacto del proyecto, garantizando que la compañía obtenga el máximo beneficio por esta apertura de sus almacenes de datos a sus socios.
Una API, por ejemplo, puede ahorrarle a la compañía significativos costos de desarrollo si, manejando la información de este modo, logra pasar buena parte de la carga de trabajo a las espaldas de sus socios. Más aún, si la organización depende del efecto de red para dirigir los ingresos a través de, por ejemplo, un incremento de participación, podrá capitalizar su alcance atrayendo, a través de las API, tantos usuarios como le sea posible. Al abrir los registros, a los socios les resulta más sencillo compartir clientes. Si el objetivo son los ingresos basados en el usuario, entonces la API debe buscar que los usuarios se conviertan en clientes (que pagan por el servicio) limitando, por ejemplo, la cantidad de información gratuita disponible.
El beneficio colateral es que las propias llamadas API producen gran cantidad de información útil que puede ser analizada para dar soporte a la conclusión final. Aun si las llamadas API son gratuitas, las plantillas de pedidos pueden resultar muy valiosas si se combinan con una iniciativa NoSQL: los datos recogidos por las llamadas API pueden generar ganancias.
Todas estas interacciones comienzan con el equipo de tecnología y culminan con el equipo de negocios. Uno abre el flujo de datos, el otro decide qué tanto se pueden abrir las puertas.
Experimento de TI con bajo riesgo No. 2: redes sociales
La mayoría de los gerentes de negocios quieren encontrar la manera de aprovechar el poder de las redes sociales. Su organización seguramente no es la excepción. A menudo, los planes que la gente de negocios propone son complicados e implican una programación intensiva. Y no tiene por qué ser así.
Twitter, por ejemplo, facilita la tarea de linkear nuestro contenido a un post con un simple URL: http://www.twitter.com/home?status=MESSAGE. En este URL se puede agregar cualquier mensaje, de manera que no resulta complicado añadir un botón para que los visitantes puedan compartir el contenido de nuestro sitio Web o, anunciarles a sus seguidores la reciente adquisición de nuestros productos.
Facebook ofrece una opción similar para URL: http://www.facebooks.com/sharer.php?u=URL= MESSAGE. Para vincular nuestro sitio con Facebook solo hay que reemplazar el URL y MESSAGE.
Con estos trucos podemos evitarnos algunas de las opciones más complejas que ofrecen las redes sociales. Cuando un usuario haga clic en estos links, será derivado al sitio respectivo de la red social para verificar si está registrado. De no estarlo, el sitio le pedirá que se loguee para poder editar sus mensajes. Es decir, el sitio controla la autenticación, y nos libera de esa responsabilidad.
Con las opciones más sofisticadas, como verificar la identidad del usuario con un protocolo llamado Oauth, se obtiene una integración más detallada que puede ser adecuada para completar implementaciones. En un principio, sin embargo, no son necesarias. Si la primera parte del experimento es exitosa, entonces tendrá sentido pasar a la siguiente.
Luego de agregar estos sencillos botones a nuestras páginas Web quizá valga la pena analizar la propagación de estos mensajes a través de las redes sociales de nuestros usuarios. Tal análisis puede resultar muy útil para planificar cargas, diseñar campañas de marketing y más. Si logramos comprender la manera en que los usuarios reaccionan ante un contenido, producto o servicio publicado en nuestro website, nuestra compañía tendrá mayores posibilidades de aprovechar esa información para incrementar la exposición de esos contenidos, bienes o servicios para una audiencia más grande, o profundizar la afinidad que los usuarios ya muestran con las ofertas de nuestra compañía.
Desafortunadamente, los links básicos mostrados previamente no sirven para obtener información sobre el movimiento de los URL a través de las redes sociales. En el caso de Facebook, se puede resolver esta limitación agregando parámetros únicos a cada URL antes de pasar al Facebook. Luego nuestros archivos de registro rastrearán el URL único.
Experimento de TI de bajo costo No. 3: aplicaciones móviles
El smartphone es la plataforma predominante entre los usuarios móviles. Por eso, una aplicación para smartphone bien construida puede hacernos buena publicidad y, al mismo tiempo, brindar un servicio real a clientes y usuarios finales.
Sin embargo, la creación de aplicaciones smartphone puede convertirse en un dolor de cabeza. La demanda de desarrolladores de aplicaciones móviles con experiencia es alta. Una solución sencilla es construir un sitio Web apto para dispositivos móviles. Gracias a plantillas básicas, como jQTouch es fácil armar un sitio que presente información en browsers Webkit, como los que se usan en los dispositivos iPhone y Android. Solamente hay que reescribir un poco de HTML, y los usuarios podrán hacer búsquedas a través de nuestra información en sus teléfonos.
Este enfoque funciona bien con las API y no requiere aprobación del fabricante respecto al contenido o a la propia aplicación. El usuario simplemente crea un marcador para nuestra página Web de smartphone y el contenido se encarga de lo demás. Por ejemplo, el mencionado jQTouch permite agregar un ícono que aparecerá en el teléfono del usuario, como si fuera una aplicación de la tienda de aplicaciones. La gente que use el teléfono para visitar nuestra página Web puede almacenar el marcador con este ícono en su página principal. Ese es otro canal para distribuir aplicaciones.
Este enfoque será más provechoso para algunos negocios que para otros. Si los trabajadores de la compañía tienen que viajar frecuentemente o pasan mucho tiempo fuera de las instalaciones físicas, sin duda apreciarán acceder fácilmente al Website de la empresa desde un smartphone. Lo importante es identificar la información y las transacciones más útiles para esos empleados. Como el diseño de Small-screen UI es complicado, no vale la pena ofrecer algo más allá de las opciones básicas.
Como es muy posible que el departamento de TI no esté al tanto de las transacciones más utilizadas por los usuarios de la compañía, sería productivo reunirse con el equipo de desarrollo de negocios y la fuerza de ventas para establecer conjuntamente un plan de trabajo con miras a ofrecer a los usuarios los datos y los servicios apropiados, una vez que esté listo el prototipo adaptado para smartphone.
Experimento de bajo riesgo de TI No. 4: Geocoding
Todos los departamentos de TI tienen una base de datos llena de diagramas, cada uno de los cuales puede incluir, sin ningún problema, dos columnas extras. Actualmente, gracias a los browsers y smartphones que reportan la ubicación del usuario, resulta cada vez más sencillo obtener información de latitud y longitud. ¿Por qué no usar esta información para enriquecer el almacén de datos de nuestra compañía agregando dos columnas a nuestros diagramas más importantes?
información geográfica puede ser útil para descubrir tendencias. ¿La mayoría de nuestros clientes provienen de la costa o de la sierra? ¿Están agrupados? A menudo, un rápido vistazo a los mapas que se pueden confeccionar gracias a esta sencilla recopilación de datos, puede darnos más pistas interesantes que una sala llena de expertos en estadística.
Y estos mapas son solo el comienzo. Como la información sobre posiciones geográficas puede ayudar a reconocer cómo se agrupan clientes, pedidos, contratos y otras oportunidades de ingresos, se puede aplicar minería de datos por criterio de relevancia. ¿Tal campaña de marketing tuvo buenos resultados en una región específica? ¿Un equipo de ventas está destacando entre los demás? ¿Vale la pena renovar un determinado contrato de publicidad? Muchas de estas respuestas se pueden encontrar analizando la información geográfica, tarea que era bastante engorrosa antes de que llegara el geocoding.
Experimento de TI de bajo riesgo No. 5: NoSQL
Hace solo diez meses, el NoSQL (No solo SQL, por sus siglas en inglés) solo les interesaba a algunos fanáticos de las TI empeñados en crear los más eficientes dispositivos de almacenamiento de datos. Al analizar las bases de datos SQL, estos ingenieros se dieron cuenta de que JOIN reducía el performance y complicaba, e incluso imposibilitaba completamente, la distribución de datos a través de varias máquinas. Obviamente, hubieran podido desnormalizar los esquemas y explorar algunas herramientas de fragmentación automática y desencadenaron una revolución.
Muchas de las herramientas de fuente abierta derivadas de NoSQL -Cassandra, MongoDB y CouchDB, entre otras- requieren una gran cantidad de experimentación y mucha voluntad para soportar sus complicaciones. Si a eso le añadimos el hecho de que ni siquiera están listas para proyectos de misión crítica, será fácil darse cuenta por qué cada experiencia con NoSQL puede ser muy diferente.
Sin embargo, para los departamentos de TI que desean sacarle el mayor provecho a los datos no necesariamente críticos, el tiempo de respuesta y la sencilla escalabilidad de NoSQL pueden dar buenos frutos. Estas herramientas sacrifican la precisión para obtener mayor performance, o “consistencia eventual” como se le llama en la comunidad NoSQL. Quien haya observado cómo aparecen y desparecen los posts en Facebook sabrá que a los usuarios de bases de datos NoSQL, incluido Facebook, no les preocupa mucho que sus servidores sean completamente consistentes.
¿Cómo puede utilizar estas herramientas el departamento de TI? NoSQL ofrece análisis de los datos efímeros que a menudo pasa desapercibida. Por ejemplo, para no verse desbordadas, muchas compañías eliminan sus archivos de registro al cabo de algunos días. También desechan otros datos por la sencilla razón de que no vale la pena pagar una licencia para que una base de datos seria se encargue de ellos.
Lo que se puede hacer es reunir esta información en tablas NoSQL (por una fracción del costo de un software de base datos premium), agregarle algunos valores de latitud/longitud y comenzar a hacer aparecer mapas para ilustrar las tendencias.
Los experimentos con NoSQL y análisis prosperan cuando los resultados están orientados a responder preguntas específicas o a sustentar un tema propuesto por el equipo de negocios. Si nuestra organización desea expandirse a nuevas regiones, presentaremos una tabla con los resultados de archivos de registro provenientes de esas regiones. Si lo que se desea más bien es comprender por qué los clientes usan más una parte específica del sitio Web o un servicio Web en particular, entonces podemos acudir a NoSQL para reunir esta información y vincularla con nuestra base de clientes.
