Cadastre-se
Tecnología - 28/03/2019
“Su conexión con este sitio no es segura.»¿Pero qué significa esto?
En los días actuales, que la información tiene mucho valor, se recomienda extremadamente proteger sus datos y asegurarse de que información sigilosa o personal no caiga en manos equivocadas. Para ello, es necesario que los sitios web usen un certificado de seguridad, que es el responsable de validar el sitio y establecer una conexión segura entre el visitante y el servidor de sitios.
Probablemente, ya debe haberse deparado con el siguiente mensaje al visitar algún sitio: “SU CONEXIÓN CON ESTE SITIO NO ES SEGURA”. Esto ocurre en sitios que no tienen protocolo de seguridad (SSL/TLS). Es decir, todavía usan el protocolo HTTP en vez de HTTPS.
El HTTPS es la combinación del protocolo HTTP con el protocolo SSL/TLS. En resumen, la diferencia entre HTTP y HTTPS es justamente la capa extra de criptografía agregada por el protocolo SSL/TLS, que permite que el intercambio de información ocurra de forma segura sin ser interceptada antes de llegar a su destino.
Según Google, los esfuerzos para concientizar sobre el uso de certificados de seguridad desde 2017 ha surtido efectos:
- Más del 68% del tráfico del Chrome, tanto en Android como en Windows, está protegido.
- Más del 78% del tráfico en Chrome OS y en Mac está protegido.
- 81 de los 100 principales sitios de la web usa HTTPS por default.
Otra encuesta hecha por la empresa BigData Corp en 2018 muestra que la media global de sitios que ya usan certificados de seguridad es del 91,43%.
Parte del mérito de este aumento se debe a Google, que desde julio de 2018 pasó a marcar dichos sitios que no son certificados como “Inseguro” en la barra de dirección del Google Chrome. De esta forma, al usuario se le hace más fácil identificar si el sitio es seguro o no. La falta del sello de seguridad, representado por el “candado” en la barra de dirección y por la “s” en el HTTPS, causa inseguridad en los usuarios y muchos no se sienten cómodos, y con razón, en compartir sus informaciones.
Una vez que un sitio sea ofrecido en el protocolo HTTPS, toda la información (nombre, e-mail, teléfono, empresa en la que trabaja, datos bancarios, etc.) provistas por el usuario en el navegador son cifradas y pasibles de lectura solamente en el servidor, lo que evita ataques MITM (Man in the Middle), en los que dichos datos pueden ser interceptados antes de llegar al servidor.
Además, como parte de la estrategia para incentivar el tráfico seguro de información, los sitios “seguros” son mejores clasificados en el ranking de búsquedas del Google. Es decir, el uso del protocolo de seguridad sumado a estrategias de SEO es una buena receta para quien busca seguridad y visibilidad en sus sitios. Porque, además de garantizar la seguridad de la información, evitar la incomodidad de los usuarios al depararse con dicha frase, consecuentemente hace que el sitio aparezca en resultados privilegiados en las búsquedas, lo que causa un aumento considerable en el número de accesos a los sitios.
Publicado por Eliézer Oliveira.
Tecnología - 27/02/2019
Datos Estructurados en XBRL y el impacto en las empresas
Como es sabido y usted puede recordar un poco del asunto en este artículo, una de las principales intenciones del XBRL es hacer que las computadoras puedan comparar datos estructurados de resultados trimestrales y/o anuales de la misma empresa en diferentes períodos con peers de mercado o con cualquier otra empresa. Dejar que una computadora haga esa tarea traería resultados más veloces, confiables y menos cansadores.
Desde 2009, la SEC viene enfrentando algunos problemas relacionados con datos estructurados: las empresas no están adhiriéndose significativamente a la taxonomía propuesta debido a marcos de valuation y contabilidad propios. El problema para FPIs es aún más profundo debido al hecho de adherirse a mas de una bolsa.
La solución para empresas que no consiguen adherirse a la taxonomía propuesta es la creación de extensiones. Este método es una forma de que la empresa se asegure de que sus datos estructurados únicos serán pasados lo debidamente fidedignos. A pesar de ser un poderoso recurso en su uso, el principal problema es limitar la comparabilidad entre diferentes datos estructurados.
Estamos construyendo un escenario en datos estructurados del que poco podremos usufructuar porque, debido a la alta creación de extensiones y a la falta de estandarización en los reports de las empresas, difícilmente un software de comparación entre XBRLs conseguirá presentar información útil a los usuarios. Entonces, en vez de tener un avance de lectores automatizados y dinámicos en un archivo compacto, quedamos paralizados con los lectores de documentos en formato estático.
Escrito por Fernando Fernandes
Destaque - 31/01/2019
Inline XBRL (iXBRL)
Obligatoriedad del iXBRL
Que todos sabíamos que la obligatoriedad para las empresas que reportan sus Estados Financieros (DFs) en International Financial Reporting Standards (IFRS) a la U.S. Securities and Exchange Comission (SEC) llegaría (y usted puede descubrir un poco más aquí), todos lo sabíamos. También sabíamos que la creciente corriente del iXBRL se convertiría en obligatoria en algún momento. La SEC creó el 28 de junio de 2018 un modelo en fases (phase-in) para que las empresas y los fondos que reportan en USGAAP comenzaran a reportar sus estados financieros en iXBRL. En este artículo nos concentraremos en las empresas que reportan en IFRS y, para éstas, la SEC creó la obligatoriedad de reportar sus estados financieros en iXBRL cuando el ejercicio fiscal de la empresa cierra el o después del 15 de junio de 2021. Sin embargo, las empresas que desean adelantar sus presentaciones en iXBRL reportándolas en IFRS ya pueden hacerlo.
Pero, ¿qué es el iXBRL?
iXBRL significa InLine XBRL y es un modelo de archivo que consigue en un único documento proporcionar tanto información que puede ser leída por humanos (EDGAR/HTML) como por computadoras (XBRL/XML). Hasta el surgimiento del iXBRL, las empresas debían presentar sus resultados en EDGAR (leído por humanos) y XBRL (leído por máquinas) y en esta nueva tecnología la entrega se hace en un archivo único que integra la lectura de ambos.
iXBRL incorpora dentro del HTML las etiquetas del XBRL y les da significado a las figuras y declaraciones financieras en un formato que puede ser entendido por las computadoras.
Puede verse una muestra de un iXBRL aquí.
¿Y cuáles son los beneficios de efectuar la presentación en InLine XBRL?
Por tratarse de la integración de dos archivos en uno, reducirá costos y tiempo de creación de los estados financieros, existirá sólo un proceso de revisión por la eliminación de uno de los dos archivos, se hace más confiable y preciso visto que no existirán inconsistencias entre los archivos HTML y XML, le da a quien prepara el archivo control total sobre cómo se presentará la información dentro del HTML y mejorará la experiencia de visualización del documento para el inversionista que desea verificar información del XBRL dentro del propio HTML.
Publicado por Fernando Fernandes
Destaque - 11/10/2018
¿Usted sabe lo que necesita para tener un buen sitio web de RI?
El sitio de RI es uno de los principales vehículos de storytelling de su compañía.
Los sitios de RI les permiten a los inversionistas/analistas no sólo consumir información, sino también acceder e interactuar directamente con el área de RI. Sin embargo, queda la duda: ¿cómo tener un buen sitio de RI? ¿Invirtiendo más en diseño? ¿Usabilidad? ¿Disposición de la principal información financiera en la página principal? ¿Fácil acceso a los documentos divulgados? ¿Mayor interacción con las redes sociales?
Después de estudios, elaboramos una pequeña guía que puede hacer que su sitio de RI sea más asertivo:
1 – El sitio no lo hace solamente el equipo de RI.
Al iniciar un proyecto de sitio, es común contar solamente con la participación del equipo de RI y los otros miembros son convocados en diferentes momentos del proyecto. Muchas veces, después de la entrega del enlace navegable, se envía para validación de la dirección, que puede solicitar cambio del layout, de la estructura, del contenido… Muchas veces estos ajustes tienen impacto en la estructura del sitio y es necesario hacer una nueva codificación, programación y pruebas, lo que tiene impacto en el cronograma de entrega.
Sugerimos un pequeño comité responsable de la aprobación del sitio que involucre a los equipos de comunicación, marketing TI y RI. De esta forma, el proceso será más asertivo.
2 – Siga las novedades tecnológicas:
Aproveche lo que la tecnología puede ofrecerle para hacer que su sitio sea más dinámico, fácil de usar, hacer que las búsquedas sean más simples (por mención o documento), APIs, mejorar posicionamiento en Google, aplicación de SEO. La utilización de chatbots y actualización automática son elementos que ayudan al día a día. Tenga en mente que su navegador también deberá ser «actualizado» para que dichas herramientas puedan ejecutarse tranquilamente.
3 – Cuente su historia: ¡Su historia es importante para su público!
Los inversionistas en potencia quieren saber su historia para entender su estrategia, propósito, momento y números. La clave es mantener su historia envolvente y concisa para que sus inversionistas puedan tener una noción de quién es usted en un abrir y cerrar de ojos. Una línea del tiempo simple con fotos de los principales eventos de su camino resuelve el problema.
4 – Tenga el contenido correcto y manténgalo actualizado:
El contenido institucional no debe ser replicado en el sitio de RI. Tenga la información necesaria para su público. Pocas empresas comparten su tesis de inversiones en su sitio web, sin embargo, es una información valiosísima para analistas e inversionistas. Es de extrema importancia que la información financiera sea actualizada constantemente. Cabe recordar que el contenido adecuado apoyado en una buena acción de SEO ayudará a mejorar su indexación en Google de forma orgánica.
5 – Diseño:
Es importante tener un layout atractivo. Pero recuerde que sus visitantes esperan un promedio de 5 segundos para que su sitio sea cargado completamente y puedan navegar por él. Videos pesados y animaciones que tardan para cargar pueden hacer que su público tenga una mala experiencia, dejando el sitio antes de hacer el primer clic, lo que impacta la estrategia de comunicación con stakeholders.
Un diseño más simple es más funcional (buena performance en diferentes dispositivos es de extrema importancia. Si eligió alguna funcionalidad que no tiene buen desempeño en la versión móvil, no hay problema en no tenerla en ese dispositivo). Tenga en mente que la simplicidad aliada a la buena performance puede mejorar la interacción con su público.
6 – Seguridad:
Debe ser una preocupación en todos los niveles: desde la divulgación de los datos hasta la infraestructura del sitio. Su equipo técnico podrá ayudarlo sobre el servidor en que estará hospedado du sitio y las certificaciones digitales adecuadas, entre otras cuestiones.
7 – Analytics: If you can measure it, you can manage it!
¿Cómo saber cuáles secciones son las que tienen más accesos? ¿Cuánto tiempo navega el usuario por mi sitio? ¿Qué tipos de información son más buscados? ¿Qué secciones se han tornado obsoletas? ¿De dónde viene el tráfico del sitio? ¿Conseguí llegar a mi público destinatario? ¿Qué palabras buscadas llevan a mi sitio? Analytics responden éstas y otras preguntas.
En la actualidad, todos los softwares y plataformas colectan datos para validar sus tesis, implementar cambios y mejoras, medir interacción con el público… No existe ninguna herramienta disponible que no esté colectando datos. Cuanto más información pueda agrupar, más asertiva será su toma de decisiones.
Además, puede combinar y profundizar el análisis de los datos colectado, integrar otras acciones de marketing al monitoreo, establecer metas de resultado…
Su estrategia será más asertiva si se fundamenta en datos.
Ésta es una pequeña guía para tener impacto positivo en la forma como el mercado analiza su comunicación.
Escrito por: Fabiana Mesquita Lopes
Recientes - 15/08/2018
¿Por qué creamos un equipo de productos?
Los equipos de productos están cada vez más en evidencia. Es muy común encontrar a estos equipos. No importa el tamaño ni el segmento de actuación de las empresas en los que estén inseridos.
Este artículo es el primero de la serie en la que abordaremos conceptos relacionados con nuestro equipo de productos. Dividiremos los temas en los siguientes tópicos:
Parte I: Por qué creamos un equipo de productos.
Parte II: Cómo aplicamos el concepto de MVP.
Parte III: Cuál es la influencia real de los datos en nuestras decisiones estratégicas.
Introducción
Antes de comenzar a desarrollar el tema sobre nuestro equipo de productos, cabe una pequeña introducción sobre la empresa en que estamos inseridos.
MZ es una empresa líder en el mercado brasileño en el sector de relaciones con inversionistas y tiene 19 años de existencia y consolidación en el mercado. Nuestro principal objetivo es cumplir íntegramente nuestro propósito de facilitar y agregar cada vez más valor a nuestros clientes. En este contexto, vimos la necesidad de cambiar el rumbo de la compañía.
Decidimos entonces preparar la empresa para un mundo cada vez más rápido y digital. Con este foco, iniciamos los procesos de transformación digital y cultural. En este proceso, diseñamos toda la operación de la empresa alrededor de los nuevos productos que estamos construyendo. Para eso, invertimos en tecnología de punta y cambiamos la forma como trabajábamos hasta entonces.
Una de las primeras acciones efectivas que ejecutamos fue la creación de nuestro equipo de productos, que pasó a ser responsable del nuevo posicionamiento.
Para entender lo que representa este cambio, es esencial que miremos nuestro pasado. Durante mucho tiempo, nuestros equipos estuvieron divididos de la siguiente forma:
Equipos de negocios: responsables de identificar las necesidades de nuestros clientes y asegurar que se satisficieran todas sus necesidades.
Equipos de tecnología: responsables del mantenimiento de los productos existentes y del desarrollo de nuevas funcionalidades especificadas por el equipo de negocios.
Este modelo, a pesar de ser utilizado por diversas empresas, tiene algunas fallas, entre las que podemos destacar:
- El equipo de negocios no tiene el conocimiento necesario en tecnología. Con eso, acaban surgiendo diversos productos “fantasmas” que no pueden ser reaprovechados y demandan mantenimientos futuros, además de costos para la empresa.
- El equipo de tecnología no tiene un entendimiento claro del posible crecimiento de los productos; de esta forma, las decisiones estratégicas raramente son efectivas.
- Documentación extensa y dificultad de control: En un mundo ágil y de cambios, la entrega debe ser rápida. Transformar mantenimientos en megaproyectos causa un trastorno para todos los involucrados (cliente y equipos internos).
- Dificultad de actualización: El proceso de creación de nuevas herramientas y de actualización de las tecnologías existentes se hace extremadamente difícil. Son muchas reglas de negocios distribuidas por todas las aplicaciones creadas.
Al mirar el escenario, percibimos la extrema necesidad de tener un control más rígido de nuestros productos y asegurar que se desarrollen solamente funcionalidades efectivamente relevantes.
Al analizar el mercado y las empresas actuales, nos deparamos con diversos ejemplos de funcionamiento. Dos ejemplos nos llamaron la atención y resolvimos estudiarlos a fondo para aplicar sus conceptos a nuestra empresa: Spotify (Squads) y Google (OKRs).
Estructura del equipo (Squads)
El requisito básico para alcanzar la excelencia es tener profesionales con diferentes calificaciones trabajando juntos en pro de un propósito. Entonces, creamos un equipo de productos compuesto por:
Los principales desafíos de este equipo son asegurar que el equipo de desarrollo producirá solamente lo que generará valor para nuestros clientes y que podrá ser escalable y replicable, así como analizar todos los datos generados por la plataforma y tomar decisiones sobre las funcionalidades existentes (cambiarlas si es necesario o inclusive descontinuarlas).
El hecho de tener un equipo multidisciplinario es fundamental para cumplir nuestros objetivos. Conseguimos analizar el producto de punta a punta entendiendo si es posible crearlo con la tecnología existente (especialistas técnicos), si generará beneficios para el mercado que buscamos (especialistas RI), si está bien diseñado/estructurado, si será aceptado por el público (especialista UX) y si el momento para su lanzamiento es oportuno (líder).
Prototipado y validación
Hay mucha literatura sobre cómo debe ser la rutina de un equipo de productos. Optamos por seguir las enseñanzas de Google Ventures (GV), que pueden encontrarse aquí: http://www.gv.com/sprint/
Nuestros sprints, así como el de GV, se dividen en cinco días. Cada día tiene sus actividades específicas y el fin de la semana (viernes), conseguimos aprobar o no nuestra idea. Si es aprobada, esta funcionalidad sigue para el equipo de desarrollo para ser implementada.
De forma bien resumida, para nuevas funcionalidades, trabajamos con el principio de que no hay necesidad de implementación sin validación previa. De esta forma, concentramos nuestros esfuerzos en discutir qué reglas de negocios deben satisfacerse y cuál es la mejor forma de satisfacerlas.
Después de definir lo que deberá entregarse, creamos prototipos funcionales y los validamos con clientes y con otros especialistas. Si tuvimos el aval de más del 75% de nuestro público destinatario, seguimos adelante.
La única regla que no seguimos al pie de la letra es el tiempo desprendido. De acuerdo con GV, sería necesario trabajar enfocados por lo menos seis horas diarias. Debido al hecho de tener una operación esbelta y otras obligaciones, dedicamos sólo un período diario. A pesar de ello, no nos sentimos perjudicados y nuestra tasa de retrabajo en desarrollo disminuyó drásticamente.
Medición y mantenimiento
Para las funcionalidades ya desarrolladas y en uso, no existe nada más asertivo que datos. Conseguimos recoger información diversa sobre utilización, tiempo utilizado en cada acción y facilidad de uso, entre otros.
Con eso, sugerimos cambios diversos (layout, flujo de información o inclusive reglas de negocios) y validamos dichas alteraciones con nuestros clientes/público interno antes de implementarlas.
Lo más increíble de trabajar con datos es que en más del 95% de los casos los cambios sugeridos son muy bien aceptados y elogiados. De esta forma, ahorramos tiempo utilizado en correcciones de bugs y podemos invertir correctamente en la creación de nuevas funcionalidades.
Sin embargo, los datos no eximen la necesidad de interacción con el cliente. Siempre es muy importante escuchar al cliente y validar sus solicitudes. Para eso, utilizamos una herramienta de feedback, un Google Forms con cuatro preguntas. Dichas preguntas permiten que la solicitud/sugerencia se haga de forma estructurada. Evitamos así el tradicional: “Sería muy bueno si…” y cambiamos la sugerencia incierta por algo que realmente generará valor para quien la solicita.
Conclusión
El mundo está cambiando. Surgen nuevas tecnologías cada hora y debemos estar preparados para alcanzar la excelencia y utilizar lo más moderno que existe. Es imposible innovar, mejorar y evolucionar si quedamos enyesados en procesos antiguos y anticuados. La creación de un equipo de productos como el nuestro puede agilizar y asegurar la rapidez necesaria para las evoluciones y adecuaciones necesarias.
Otro punto importante es siempre recolectar datos en cualquier implementación realizada. Hablaremos más sobre esto en el tercer artículo de esta serie.
En el próximo artículo, hablaremos sobre cómo trabajamos el concepto de MVP y cómo éste nos ayuda a ahorrar horas y más horas en el desarrollo de nuestros productos.
Escrito por: Felipe Furlan