Caso práctico: Six Flags Entertainment Corporation

27/Mar/2016 | Eder

Inicio » Casos Prácticos » Caso práctico: Six Flags Entertainment Corporation

Six Flags Entertainment Corporation es la compañía detrás de múltiples parques temáticos en Estados Unidos, México, Canadá y otros países. En 2015 decidió aplicar un programa piloto para la organización de eventos limitados en algunas de sus instalaciones.

Uno de ellos se orientaba a miembros universitarios de escuelas públicas, por lo que un grupo reducido de personas tenía el objetivo de conseguir un mínimo requerido de entradas para el día de la celebración cercano por solamente 7 semanas a partir de la fecha de autorización por parte del departamento de ventas.

Nuestro reto

El equipo de desarrollo ofreció sus propuestas al grupo recién formado y decidieron unirse. El primer obstáculo fue establecer una organización de las tareas la cual fue evolucionando progresivamente para así cubrir tareas específicas en un momento dado y las eventualidades que llegaron a ocurrir.

El verdadero problema a superar estaba relacionado directamente con dar a conocer las características de la nueva idea. Gracias a los esfuerzos y la creatividad de P(dot)co, una filial de nuestra organización conseguimos brindar la confianza suficiente entre muchos miembros de la comunidad de estudiantes para que pudiesen interesarse en el evento a través de algunas actividades que se hicieron aprovechando la difusión de contenido autogenerado y distribuido a través de las redes sociales más populares.

Sin embargo, los precios de las entradas eran bastante elevados y la situación económica de nuestro mercado meta no estaba en una buena posición. Cuando se hizo la observación del mismo, el bussiness team (con quien colaboró el staff de NativeHex) resolvió con los representantes de Six Flags Theme Parks (la marca o brand de la empresa en cuestión) permitir a los asistentes cubrir costos en un máximo de tres periodos.

Al tratarse de problemas complejos, resulta bastante factible descomponerlos en factores más sencillos que permitan proporcionar una mejor retroalimentación.

  • Se necesitó difundir la existencia de esa nueva idea a celebrar en pocas semanas a un público seleccionado con anterioridad aprovechando estrategias creativas que llamaran la atención de las personas objetivo con contenido cuyo objetivo fuera distante de producir polémica y reacciones diversas entre los visitantes y suscriptores
  • Al comenzar el proyecto, hubo algunas experiencias negativas con el intercambio de las primeras entradas. Las quejas se difundieron por la red virtual estudiantil demasiado rápido y la reputación del bussiness team no estaba en una situación adecuada cuando el equipo de NativeHex llegó a evaluar la situación.
  • El bussiness team adoptó una política de emergencia ofreciendo difusión durante los días escolares para recuperar eventualmente la confianza del público objetivo. Es así como el departamento de ventas de la empresa nos proporciona material genérico publicitario en el cual los interesados podían contactarnos a través de email y redes sociales.
  • Los precios de las entradas eran bastante altos; solamente un pequeño grupo podía permitirse gastar esa cantidad de dinero y ahorrar para los gastos adicionales a realizar ese día. Para mejorar el margen de ganancia, se hizo la observación y final decisión de permitir aplicar una política de tres pagos a aquellas personas que lo necesitaran.
  • Tras hacerse un estudio inicial de nuestro mercado meta y de las técnicas utilizadas por el bussiness team para difundir los detalles del evento, pudimos percatarnos que la información brindada era inexacta, poco llamativa, redundante y en algunos casos se contradecía. La gente no se motivaba a leer y perdía el interés.
  • Las estadísticas ofrecidas por los reportes analíticos devueltos por nuestra filial P(dot)co no ofrecían la suficiente información sobre el comportamiento de los visitantes. Con la motivación del punto anterior, el staff de NativeHex lanzó en pocos días un sitio web llamativo con la información suficiente y los medios oficiales de distribución, así como el calendario de actividades del equipo que además aprovechaba en conocer un poco más de detalles sobre nuestros visitantes y el origen de los mismos.
  • La primera fecha de recepción de pagos se hizo el registro de usuarios de manera manual, lo que fue una experiencia bastante agotadora para los  miembros del bussiness team.

Por qué brindamos nuestros web services

El staff de NativeHex hizo diferentes evaluaciones sobre los puntos débiles que podían perjudicar gravemente la estabilidad del proyecto a cumplir en esas semanas para introducir mejoras que se reflejaran en aspectos económicos y motivacionales de cada miembro del equipo.

Motivación

Desde el principio decidimos aceptar esta propuesta con el objetivo principal de acercar y simplificar las IT haciendo uso de servicios en la nube y aplicaciones OpenSource a través de una filosofía basada en la simpleza.

Seguridad

Más allá de querer desarrollar soluciones funcionales, nos preocupamos por que la información y cada una de las operaciones dentro de nuestro equipo fueran las correctas aplicando con eficacia las políticas de seguridad y recomendaciones necesarias para reducir el riesgo de pérdidas o fugas de datos por parte de intrusos o incluso ex-miembros del bussiness team.

Un paso adelante

Esta experiencia no se trató solamente de vender entradas para algún suceso independiente; en realidad siempre se buscó dar un paso adelante y motivar a los miembros del bussiness team para aprender algo nuevo y compartirlo con los compañeros. Gracias a eso, tiempo después de finalizado el proyecto, los miembros entendieron un poco más la importancia de trabajar en equipo.

Resultados

Comenzar a trabajar en una solución que brindara una estabilidad y automatizara todos los procesos relacionados con el registro de asistentes y apartado de lugares fue algo que se realizó de inmediato tras la primera recepción de pagos realizada presencialmente. En las siguientes fechas permitió hacer un registro superior al 85% de los asistentes, lo que simplificó muchas de las labores posteriores de asignación de entradas basándose en los números de folio e identificadores únicos.

Un mes más tarde se decidió ensamblar un servicio más completo que permitiera a los usuarios registrarse en la plataforma utilizando la API de Facebook (formalmente conocida como Graph API) respetando las especificaciones del protocolo Open Graph. Entre sus características relevantes fue obtener la información de los clientes, almacenarlas en la base de datos y con base en ello asignar números de folio secuenciales así como una fecha de entrega establecida en nuestro calendario que, en coordinación con los representantes de la empresa, logramos definir.

El despliegue de aquella plataforma originalmente se realizaría utilizando un modelo PaaS aprovechando algunos servicios en la nube como Amazon EC2, Amazon S3 e incluso Elastic Load Balancing. Una repentina acción de recorte de presupuesto nos obligó a buscar una alternativa más sencilla, la cual culminó brindando resultados positivos con una adecuada configuración de un DBMS como MariaDB y el servidor web Nginx que también se encargó de hacer load balancing.

El proceso de análisis estadístico fue realizado tan pronto concluyó el evento; los informes fueron entregados y discutidos por el bussiness team. Al final del día los resultados fueron mejores a los esperados con más de 2 500 asistentes y una cantidad recaudada cercana a los $90 000 USD.

En cuanto a los respaldos de la información, se aprovechó una técnica de replicación de datos genérica que almacenaba la información en contenedores cifrados a través de diferentes servicios en la nube. Por otra parte, los documentos digitales emitidos y distribuidos al equipo fueron firmados digitalmente.

Soluciones a futuro

El proyecto piloto fue descontinuado meses más tarde y no hubo ediciones posteriores. Las ideas existentes antes de este suceso fueron las siguientes:

  • Crear una infraestructura básica aprovechando los servicios en la nube que permitiera distribución del contenido, almacenamiento de datos y distribución de los mismos a través de un servicio web.
  • Ofrecer una API para llevar el desarrollo y gestión de los siguientes eventos aprovechando tecnologías existentes en dispositivos móviles.
  • Aplicar técnicas de minería de datos para realizar estudios de la información más precisos que permitiesen tomar decisiones mejor fundamentadas.
  • Prescindir de los servicios de terceros para llevar informes estadísticos.
  • Mediante técnicas de aprendizaje automático, ofrecer a los usuarios alternativas a los horarios que eligieron si estos se encontraban saturados en función de su disponibilidad aprovechando el análisis del tiempo que pasaban disponibles en Facebook durante los fines de semana.
  • Realizar streaming sobre los eventos en vivo a través de Internet y sin necesidad de usar servicios de terceros como una estrategia de publicidad para motivar a los visitantes a acudir a la siguiente edición del suceso.
Acerca de Eder
Software Engineer, estudiante politécnico del CECyT No. 3 y ESCOM-IPN.

Comentarios

Los comentarios se encuentran cerrados