 |
|
Enero 2009 |
Newsletter de Business
Intelligence |
N°7 |
| En este Newsletter...
|
Temas
abordados en esta edición:
- Business Intelligence - Data Mining |
| Oportunidades
en Tiempos de Crisis Una crisis es una etapa particular de cambios rápidos, a veces violentos, y difíciles de prever en un proceso evolutivo socioeconómico relativamente inestable. Es un período de incertidumbre, de reestructuración, más que de expansión, donde el impacto de las buenas decisiones significa la supervivencia y el de las malas la extinción en un plazo relativamente corto. Afloran distintos mecanismos defensivos perjudiciales, pero también adquieren aun mayor importancia los recursos internos de una organización. Una crisis es una etapa en la que florecen los agoreros, gurúes, opinadores, buscadores de culpas ajenas y otras tantas subespecies del Homo sapiens. Se exacerban los intereses corporativos de diversos sectores de la sociedad, el pensamiento mágico y fantasioso, el voluntarismo, las angustias, las conductas preventivas (exageradas), los mecanismos defensivos (negación y otros tantos) y otros diversos fenómenos que solo logran aumentar el nivel o la agudeza de la crisis, y contribuyen más a la extinción que a la supervivencia. Algunos sectores de una sociedad (estados, partidos políticos, gremios y otros) pueden ampararse en el voluntarismo, las ideologías políticas, las grandes “teorías” (¿cuántas veces escuchó hablar en el último tiempo de “neolieralismo”, “neokeynesianismo”, etc.?) y, a pesar de la considerable ignorancia y falta de capacitación de su estamento dirigente, sobrevivir. Pero esta no es, en general, una alternativa posible ni deseable para las empresas. Aunque incómodas, las crisis son oportunidades de cambios significativos, la posibilidad de lograr un nuevo y más estable equilibrio y perspectiva. Las crisis en general y sus manifestaciones no son nuevas. Han ocurrido a lo largo de la historia reciente suficientes veces, dándoles a los científicos sociales amplias oportunidades para estudiarlas, descubrir sus mecanismos y desarrollar herramientas para enfrentarlas. Las causas pueden variar, pero las estructuras y procesos biológicos, sociales y económicos se mantienen suficientemente similares a lo largo de periodos prolongados de tiempo y sucesivas crisis. Gracias a esto, los conocimientos e instrumentos desarrollados por los científicos sociales conservan plena vigencia y utilidad. Una respuesta exclusivamente económica ante una crisis es insuficiente, tanto para una entidad trasnacional como para una humilde pyme. Esgrimir clichés remanidos, surgidos de filosofías o teorías vagas y olímpicamente generales, evita incómodos vacíos comunicativos en dirigentes que se sienten impelidos a aportar su “granito de arena”, pero no modifican la situación real, solo son síntomas de incapacidad y carencia de recursos. Las grandes y tantas veces mencionadas teorías económicas, están demasiado distanciadas de los sucesos concretos de nuestro complejo mundo real. Las inferencias deductivas que hay que realizar a partir de ellas para “bajarlas” a una situación práctica son tantas, tan diversas y heterogéneas, que vuelven a estas grandes teorías prácticamente inútiles en la práctica. Solo sirven para alimentar mecanismos defensivos (no adaptativos) de negación, distorsión de la realidad, estereotipia de decisiones y conductas, etc. El refrán de que “no hay nada más práctico que una buena teoría” sigue siendo muy válido, pero las “macro” teorías económicas no son, justamente, las teorías apropiadas. Los científicos sociales (en un sentido amplio) estudiaron,
durante los últimos cincuenta años, los mecanismos,
características, futuro, etc. de nuestras sociedades post-industriales.
Estos estudios incluyen herramientas “blandas” (teorías
y conceptos de las características y mecanismos sociales)
y herramientas “duras” (métodos, técnicas,
algoritmos, etc. aplicables a distintos tipos y niveles de problemas).
Muchos de estos estudios incluyen, precisamente, los fenómenos
de crisis. En un nivel intermedio de abstracción, los distintos programas creados para mejorar la la efectividad de las empresas ofrecen concepciones y herramientas probadas y útiles. Unos cuantos años después de su puesta en práctica inicial, y con la perspectiva del tiempo transcurrido y los resultados obtenidos, es claro que ninguna es una “silver bullet”, pero que, complementándose y apropiadamente aplicadas, pueden ser instrumentos efectivos en la supervivencia de organizaciones en tiempos turbulentos. Es así que enfoques como los programas Just-In-Time, desarrollados desde la década de 1920 en adelante, los de Total Quality Management, los de reingeniería de procesos y la Teoría de restricciones, más recientes, en apropiada complementación son “toolkits” potencialmente efectivos. En el nivel inferior de abstracción, todas las concepciones antes formuladas recurren a herramientas analíticas bien conocidas de predicción, optimización, satisfacción, análisis de datos, análisis de sensibilidad, escenarios what-if, etc. Son todas herramientas probadas, relativamente conocidas por las empresas (aunque es cierto que en muchos casos no han desarrollado destrezas para su aplicación en un nivel apropiado), y para las que la mayoría ya disponen de herramientas computacionales mínimas (o no tan mínimas, según el caso) razonables. La buena noticia de todo lo anterior es que no hace falta inventar nada para sobrevivir e incluso prosperar en la crisis. No se necesitan grandes y costosas inversiones en hardware o software, ni prolongadas capacitaciones. La resolución del problema consiste en tomar las decisiones apropiadas basadas en teorías y prácticas adecuadas e implementarlas de un modo eficaz. La información necesaria surge, en la mayoría de los casos, de los sistemas existentes ya instalados. El ambiente turbulento no exige realizar predicciones u optimizaciones con una precisión muy grande ni necesariamente muy frecuente o acelerada, más bien realizarlas en el sentido apropiado y con las concepciones indicadas. Todo esto no requiere de grandes recursos, pero si del conocimiento, las destrezas y la experiencia apropiadas. La mala noticia es que esto último viene siendo un recurso bastante escaso en la última década. La política de recursos humanos de las grandes consultoras (esencialmente la misma en todas) y de unas cuantas empresas de software asociadas con ellas viene atentando desde hace años contra una ley fundamental de la “ecología social”, para usar el término de Vickers. Esta ley dice algo así como lo siguiente: la medida en que un sistema es capaz de adaptarse exitosamente a su entorno es función directa de su variedad. Es decir, cuánto más homogéneo (y especializado) es un sistema, mayor el riesgo de su extinción cuando cambian las condiciones del entorno. Las grandes consultoras han tendido a especializarse en cuestiones que en ambientes estables, de expansión, y más o menos previsibles, son indudablemente importantes, pero que en este momento han pasado a segundo plano. Todos los recursos de la mayoría de las consultas grandes
se orientaron en este sentido; especializándose, usando como
recurso humano principal una masa de consultores junior de baja
y estrecha experiencia, y perdiendo, en buena medida, buena parte
de su memoria institucional. Por lo tanto, carecen de variedad para
enfrentar situaciones de crisis como la presente. Surgen, entonces,
los “charlistas”, e incluso malas interpretaciones o
implementaciones desviadas de las que serían las herramientas
naturales en este momento. Muchas de estas conductas pueden interpretarse
como mecanismos defensivos (de las consultoras) ante la crisis.
Se advierte en muchos casos una importante tendencia a negar sistemáticamente
(por desconocimiento o no) unas cuantas cuestiones fundamentales
ya conocidas de las crisis y a proponer más (mucho más)
de lo mismo, justamente de lo único que a esta altura saben
o recuerdan cómo hacer. Lamentablemente, esto no es muy útil
para la supervivencia de una empresa que intenta navegar en mares
turbulentos y llegar a buen puerto. Algunas sugerencias para aprovechar las oportunidades que plantea la crisis actual:
Para consultar:
|
Planificación e Implementación de Proyectos de Data Mining En la actualidad la planificación e implementación de un proyecto de Data Mining puede beneficiarse de al menos quince años de experiencias (buenas y malas) en el tema. Como con cualquier nueva tecnología, hemos atravesado períodos de sobreventa, decepción y finalmente perspectivas más realistas. El Data Mining como actividad mostró claramente su potencialidad y alcance, al mismo tiempo que se hicieron evidentes algunos errores comunes que suelen reiterarse más de lo deseable en muchos proyectos. Luego de una mención de los errores más frecuentes, hacemos un breve análisis de los mismos. Finalmente esbozamos un esquema de estrategia para lograr proyectos exitosos. Una versión detallada de esta estrategia es la que MAySA propone para sus proyectos en data mining. Errores comunes Existen varios errores muy frecuentes en la planificación e implementación de un proyecto de Data Mining que conviene evitar. Muchos de ellos atentan seriamente contra el éxito de este tipo de proyectos.
Análisis de los errores comunes Proyectos “ad hoc” Este es, tal vez el error más importante debido a sus consecuencias. Muchas veces (demasiadas) un proyecto de data mining surge de diversas motivaciones un tanto vagas. En lugar de ser el emergente de una necesidad natural a partir de consideraciones estratégicas y consensuadas dentro de una empresa, con demasiada frecuencia los proyectos de data mining son planteados como un “must do” por parte de un pequeño sector directivo temporalmente influyente, sin un fuerte compromiso o comprensión de otros sectores de la empresa. Las motivaciones del sector directivo impulsor están más cerca de la adopción de una moda, imitar experiencias exitosas pasadas, etc. Por lo general, esto produce proyectos que nacen divorciados de un panorama estratégico global, que se desarrollan enquistados, desaprovechando los recursos propios e insertándose malamente dentro de la cadena de valor de la empresa y que desaparecen, más tarde o más temprano, sin alcanzar siquiera los cálculos más pesimistas de ROI (si es que se hicieron alguna vez). Este error es responsable, o al menos potencia, la mayor parte
de los errores que mencionamos a continuación. En lugar de
que la inserción estratégica del proyecto pase a ser
la cuestión importante, se derrocha tiempo y esfuerzo en
problemas que muchas veces son, en realidad, pseudo problemas, como
qué software adquirir, o en realizar proyectos de ETL “ad
hoc” o “ingenuos” para asegurarse (más
bien tranquilizarse) de tener datos disponibles una vez comprado
el software de análisis. Este problema de un proyecto de data mining funcionando en un “vacío organizacional” ya ha sido advertido por diversos analistas e investigadores. Uno de los intentos de resolver esta cuestión es el llamado Data Mining Organizacional (DMO): “Data Mining es el proceso de descubrir e interpretar patrones previamente desconocidos en bases de datos. Es una poderosa tecnología que convierte los datos en información y conocimiento potencialmente accionable. Sin embargo, obtener nuevo conocimiento en un vacío organizacional no facilita una toma de decisiones óptima en un marco de negocios. El desafío organizacional único de comprender y utilizar DMO para producir conocimiento accionable requiere asimilar las perspectivas de campos organizacionales y técnicos y desarrollar un marco abarcativo que soporte la búsqueda de una ventaja competitiva sustentable por parte de la organización” (Nemati y Barko, 2004). Qué software adquirir Existe una considerable confusión sobre el problema del software. Para quienes intentan planificar e implementar un proyecto de data mining esta suele ser la razón fundamental de sus desvelos. La expectativa de obtener el “mejor software”, hurgar en detalles (muchas veces irrelevantes), considerar demos muchas veces atractivas pero de dudosa utilidad, etc. se apoyan en la creencia (falsa) de que el software de data mining es el elemento clave y esencial del proyecto. Pero esto no es así y muchas veces es un despropósito el tiempo y esfuerzo que se emplea en esta cuestión. Existen métodos bastante consolidados para la evaluación del software que pueden utilizarse (aunque raramente se hace) y, obviamente, contar con un conjunto de herramientas informáticas apropiadas es importante. Sin embargo, si tan solo se consultan las evaluaciones de consultoras como Gartner, Bloor y otras tantas puede advertirse que existe una cantidad relativamente grande de software de data mining con muy buenas características, seguramente perfectibles, pero (y este es el punto) que exceden considerablemente la capacidad de utilización y aprovechamiento por parte de empresas con proyectos incipientes o no tanto. Las principales dimensiones a tener en cuenta al evaluar un software son performance, funcionalidad, usabilidad y soporte de tareas auxiliares (incluyendo la integración con componentes de ETL, reporting, etc.). Cualquiera de los grandes players tiene mucho que ofrecer en cualquiera de estas dimensiones. Heurísticas generales como la magnitud de inversión del vendedor de software en investigación y desarrollo, la amplitud y profundidad de su software para la realización de tareas de análisis estadístico de datos, el apoyo de una plataforma empresarial de software en la que el componente de Data Mining se inserta, la base de un lenguaje de programación sólido de cuarta generación y otros tantos criterios técnicos bastan para una evaluación rápida y efectiva de las alternativas de software (estos y otros tantos criterios son los que usan Gartner y las otras evaluadoras). Pero todos los grandes vendedores de software de Data Mining tienen muy buena performance en todas estas características. Por eso, las diferencias entre ellos son irrelevantes para la mayoría de los proyectos. De modo que la cuestión del software pasa más por el costo en relación con un ROI apropiadamente definido, por los “extra” que puedan obtenerse del vendedor de software, por el apoyo a nivel de entrenamiento, soporte, etc. (aunque véase más abajo) que pueda obtenerse. La utilidad de los otros “diferenciales” más técnicos o académicos es bastante opinable. Poner énfasis en estos últimos es otro despropósito frecuente. En la gran mayoría de los casos, los problemas y motivos de insatisfacción con un software determinado tienen mucho más que ver con la incapacidad, tanto del equipo técnico del cliente como de los representantes de la empresa de software (vendedores, soporte técnico, etc.), de resolver los problemas (inevitables) que surgen debido a los déficit, señalados más abajo, del recurso humano, que a verdaderas falencias de las herramientas informáticas. Datos e infraestructura de acceso disponibles Hasta hace no demasiado tiempo, había pocos datos (en formato digital). Ahora hay muchos, y esto ha sido una fuerza impulsora del data mining. Sin embargo, los “muchos datos” suelen encontrarse fragmentados en distintas fuentes, con distintos formatos, con una calidad dudosa y, aún ahora, para problemas de negocios específicos, puede ocurrir que falten datos. La necesidad de un acceso apropiado (oportuno, eficiente, etc.) a datos adecuados (relevantes, vigentes, limpios, etc.) para tareas de data mining, y BI en general, fue la fuerza impulsora de “disciplinas” como el “datawarehousing” y “data quality”, de conceptos y herramientas como los estándares de metadatos, las “data federation”, las arquitecturas orientadas a servicios (SOA), los cubos OLAP y tantos otros. El área de acceso a los datos para data mining se volvió muy compleja, con tantas herramientas como problemas. Actualmente un proyecto de DM presupone un proyecto paralelo (y sincronizado) de acceso a los datos, y existen diversas metodologías para la planificación e implementación coordinada de proyectos de warehousing, data quality, mining, etc. (Por ejemplo, la metodología IPI propulsada por SAS). Es una ocurrencia muy frecuente subestimar la cuestión del acceso a los datos (supone no un acceso de única vez, sino un acceso sistemático, organizado y periódico, a datos con una semántica y una calidad apropiada, entre otras cosas). Suele creerse que la escritura y ejecución exitosa de un conjunto de programas en sql que producen algún conjunto de datos potencialmente relevantes (pero que no responden a ninguna formulación de objetivos de mining concretos, de modo que la presunción de relevancia es un tanto vaga) resuelven el problema o muestran que el problema sería fácilmente resoluble. Esta falsa creencia tranquiliza provisoriamente al equipo encargado de un proyecto de data mining, pero es, más tarde, responsable de considerables retrasos, conflictos y deterioro de las relaciones con quienes deben recibir los resultados de mining. La disponibilidad de un conjunto de datos inespecifico (sin relación muy concreta con proyectos de mining específicos) no es garantía en absoluto de que durante la puesta en producción de tareas de mining concretas se vaya a disponer de los datos relevantes y apropiados. También es una ocurrencia frecuente la sobreestimación del problema. Esto se ve en una inversión de recursos desmedida en una infraestructura de acceso a los datos que alimentaría el proyecto de mining, en detrimento de las tareas posteriores de análisis de esos datos o, incluso, en un déficit en la definición de cuáles exactamente serían los datos apropiados. De esta manera los datos están (aunque no siempre, a veces se descubre que se invirtió un gran esfuerzo en ganar acceso a los datos equivocados), pero el producido analítico es tan pobre que no justifica el esfuerzo invertido. Inserción de resultados en la cadena de valor de una empresa El error de una definición inadecuada (o inexistente) de la inserción de los resultados de mining es, en buena medida, una consecuencia de la ausencia de una concepción estratégica. Es moneda corriente el desaprovechamiento de los resultados de data mining por parte de los sectores que debieran ser sus principales beneficiarios y la capacidad ociosa (en software y recursos) en el sector de data mining, apenas transcurridos unos pocos meses de la implementación de un proyecto. La forma más eficaz de evitar este problema consiste en un diseño estratégico del proyecto y emplear una de las tantas metodologías conocidas que logran una participación e involucramiento de los distintos sectores implicados (Para solo dar un ejemplo, la de centros de competencia). ROI de un proyecto de DM Un cálculo (apropiado) del ROI de un proyecto de DM sirve para poner los pies en la tierra y ganar una perspectiva adecuada para la mayoría de las cuestiones que surgen en un proyecto de este tipo. Es sorprendente la cantidad de proyectos que eluden completamente la cuestión. El esfuerzo de generación de un ROI apropiadamente definido es una excelente herramienta para acercarse a una inserción estratégica del proyecto. No es posible definir un ROI sin una mirada de mediano plazo vinculada a los objetivos estratégicos de la empresa. Tampoco es posible definirlo sin considerar bastante precisamente cómo será la inserción de sus resultados en la cadena de valor de la empresa. Por otro lado, una resolución apropiada de la inversión en software, recursos humanos, consultoría, etc. pasa ineludiblemente por la consideración del retorno esperado. Partners inapropiados Una empresa con un proyecto de data mining suele utilizar los servicios de consultoria de la empresa productora del software que adquirió o de una consultora “partner”. Muchas veces, estos resultan ser los “socios” inapropiados, por diversas razones. Solo mencionaremos las más evidentes. Debido a la política de recursos humanos imperante, las empresas productoras de software y consultoras asociadas (especialmente las de primera línea) trabajan con personal poco calificado y casi ninguna experiencia. Justificaciones hay muchas, pero cuando se lleva esta política a la práctica, esto significa que el staffing de un proyecto está compuesto por algunos consultores junior con escasa o ninguna experiencia, a veces (no siempre) algún consultor senior que podría, o no. tener experiencia y conocimiento (esto es bastante aleatorio) y algún Project manager con escaso conocimiento técnico del proyecto (y lo que es peor, interés). Es cierto que muchos de los grandes vendors y consultoras poseen explícitas y detalladas metodologías de implementación de proyectos, y esta es una de las justificaciones de la política de recursos humanos de bajo nivel. Con un “andador” metodológico tan detallado, ¿quién podría equivocarse? Sin embargo, ocurren fenómenos curiosos, que más de una vez resultan explosivos en el desarrollo de un proyecto. Para solo mencionar un ejemplo, el de los “hitos”. Un instrumento, en principio apto para resolver la cuestión del monitoreo del desarrollo de un proyecto, como es el cumplimiento de hitos, muy frecuentemente se ve desvirtuado y, al contrario, atenta contra el éxito de un proyecto. Cuando en un proyecto se emplean recursos de bajo nivel, el hito
no es una consecuencia de una etapa exitosa sino prácticamente
el objetivo, a lograr como sea. Esto pervierte un instrumento potencialmente
eficaz. En nuestra experiencia, existe una alarmante frecuencia
de hitos alcanzados de maneras dudosas, mediante soluciones, herramientas,
etc. totalmente irrazonables y frágiles (suelen “romperse”
a los pocos días de aprobado el hito). En manos de recursos
no calificados, el éxito de una etapa y el cumplimiento de
un hito pasan a ser dos objetivos distintos que compiten entre sí.
Como el cumplimiento exitoso de la etapa suele ser irrealizable
para ellos en los plazos definidos (justamente por la falta de capacitación),
todos los esfuerzos se vuelcan a llegar al hito (como sea) que es,
después de todo, lo (único) que le interesa a un Project
manager, que en general no quiere verse involucrado en “tecnicismos”
que no comprende. En síntesis, una historia de perversión. Tareas preparatorias Por más que las empresas de software transmitan la impresión
de que si se tienen los datos, obtener un resultado de data mining
es poco menos que inmediato e “indoloro” (gracias a
la usabilidad, performance, etc. de sus herramientas), esto es fantasía
pura. Cada problema de negocios a resolver mediante alguna técnica
de data mining plantea sus propias exigencias en lo que a preparación
se refiere. Una implementación exitosa de un proyecto de
warehousing, data mart o similar, incluyendo una apropiada implementación
de técnicas de data quality pueden facilitar las tareas de
data mining, pero las tareas preparatorias de un proyecto específico
concreto nunca desaparecen. Capacitación y experiencia del recurso humano Al igual que tantos otros instrumentos tecnológicos, un software de data mining es tan bueno o tan malo como la mano que lo controla. En lo que a la implementación de un proyecto específico se refiere, la única garantía final de éxito es la capacitación y experiencia del grupo humano que lo lleva a cabo. Si esto está, cualquier otro problema es resoluble. Data Mining es una disciplina con algunos “handicaps”: es una disciplina novedosa (no más de quince años de edad) en una intersección inestable entre diversas disciplinas más “consolidadas” (estadística, aprendizaje automático, bases de datos, etc.). La formación académica en DM es irregular por diversas razones. Un “miner” capacitado y experimentado debe tener una experiencia sólida en las ramas principales de la estadística, una buena formación en bases de datos y algún lenguaje relacional, un conocimiento teórico significativo de algoritmos y estructuras de datos, aprendizaje automático y un conocimiento práctico sólido en algún lenguaje de programación de cuarta generación y en los componentes relevantes de software de por lo menos alguno de los grandes vendedores de software (no solo en el componente de data mining). Es verdad que muchas carreras de especialización y maestrías en data mining incluyen estos temas, pero también es cierto que por la filosofía de implementación de estas carreras y debido también al público heterogéneo al que sirven (desde médicos hasta actuarios y contadores, pasando por las más diversas profesiones), la formación resulta muy deficitaria. La mayoría pasa a “saber mucho de nada” y termina desarrollando e implementando en la práctica la falacia de la “caja de herramientas”: para ellos data mining es un conjunto de herramientas, sin mayores relaciones entre ellas, que sacamos de una caja para resolver un problema determinado,. El paso siguiente en la “trayectoria” profesional del esbozo de miner es, entonces, volverse “especialista” en alguna herramienta y, por supuesto, en esta perspectiva, para un martillo cualquier cosa es un clavo. Estas y otras cuestiones relevantes hacen a una escasez aguda de recursos verdaderamente calificados y producen distintos fenómenos que se observan con mucha frecuencia en las empresas: proyectos de data mining de muy bajo nivel (inútiles, en realidad), recursos humanos con escasa comprensión de las tareas que realizan y las herramientas que utilizan, personal de cualquier área y con escasa o ninguna formación asignada a este tipo de tareas, y tantas otras experiencias similares. Elementos de la estrategia de MAySA En MAySA utilizamos una estrategia de planificación e implementación de proyectos de data mining que es producto de la destilación de nuestra propia experiencia, de estrategias formuladas por diversos vendors y consultores, y, más que de las historias de éxito tan difundidas por estos, de las historias de los fracasos (estas se encuentran más ocultas, hay que escarbar bastante para obtenerlas). La estrategia tiene muy en cuenta los errores y problemas antes mencionados. Para evitar las consecuencias de objetivos de negocios vagos, se define con anterioridad a la planificación del proyecto de DM cuestiones básicas como los objetivos estratégicos y la situación actual de la empresa (objetivos, problemas, recursos), los objetivos estratégicos del proyecto, las áreas prioritarias de aplicación, las métricas de éxito del proyecto y una cuantificación de sus beneficios (en lo posible mediante un análisis de costo-beneficio). Se busca realizar un relevamiento de los recursos existentes,
y el involucramiento del personal clave en toda la empresa. La estrategia
incluye la evaluación de las herramientas de software apropiadas
y la participación en la relación con el o los proveedores
de software, a fin de evitar consabidos “ruidos” y desinteligencias
que consumen mucho tiempo y esfuerzo. Finalmente, la implementación de la estrategia se realiza mediante ciclos de refinamiento progresivo a través del desarrollo de prototipos en cada proyecto específico cuya performance se incrementa en los ciclos sucesivos. De esta manera, se logra una inserción inicial rápida en la cadena de valor, y una estimulación y mejoramiento de la participación de los distintos sectores de la empresa involucrados que serán los principales beneficiarios. Para mayor información sobre nuestra estrategia, consulte a info@maysaconsultores.com.ar Referencias:
|
| Si no quiere seguir recibiendo este Newsletter por favor enviar un mail de respuesta colocando "EXCLUIR" en su título. |