Blog de JoseMPelaez

Aprendimiento: aprender del entorno con atrevimiento

Posts Tagged ‘información’

Información accidentada

Posted by josempelaez en Lunes, 25 agosto 2008

La catástrofe aérea de Barajas muestra que debemos mejorar la forma de reaccionar ante un desastre desde los planos informativo y organizativo. También ha dado ocasión para que algunos intentaran aprovechar el aluvión mediático en defensa de sus intereses particulares.

«Je suis désolé» es una de las pocas expresiones que recuerdo del francés aprendido en la enseñanza secundaria de los 60. Después de haberlo sentido mucho, la aflicción, el desconsuelo, la tristeza… que me afectaron inicialmente —tras el reciente desastre aéreo en el aeropuerto de Barajas— han ido migrando hacia el desconcierto, la contrariedad, el disgusto… por mi percepción de lo que estuvo sucediendo luego.

avion_spanair

Imagen de archivo del avión de Spanair siniestrado. (Foto: AFP)

Nos sigue quedando mucho por aprender. Opino que el tratamiento que damos a la información en este tipo de sucesos es malo, francamente malo. Directivos, periodistas, políticos, trabajadores, ciudadanos…, todos hemos de preguntarnos sobre lo que debiera mejorarse en circunstancias de esa naturaleza.

¿Está establecido que los familiares y amigos de las víctimas de un accidente aéreo sólo puedan confirmar los pasajeros mediante una llamada del transportista? ¿Cómo se va a evitar que reciban informaciones imprecisas a través de los que cuentan lo que creen saber o haber visto u oído? ¿Por qué no se publican inmediatamente los datos contrastados que se van teniendo sobre los hechos?

En el caso del avión de Spanair en Madrid, la lista de pasajeros embarcados, el historial de operación y mantenimiento del aparato estrellado, la grabación de AENA del despegue, el número y distribución de heridos en los hospitales… eran informaciones tratables informáticamente. En contra de lo que hicieron algunos, considero que debieran haberse ofrecido a todos los involucrados al cabo de muy poco tiempo. No pueden escudarse en la posibilidad de errores. ¿A quiénes preguntaron o qué hicieron para verificar la lista del pasaje publicada pasadas varias horas? El siniestro no ocurrió en un país poco desarrollado, ni en un lugar remoto o aislado de la geografía española.

Me parece que son demasiados los que consideran que los directivos, técnicos o autoridades (de las empresas u organismos involucrados) que no están en la comisión de investigación tienen más capacidad para entender lo ocurrido y analizar los datos de un accidente que los demás interesados. Por consiguiente, según esos, la mayoría no tenemos por qué conocer las informaciones de partida ni las hipótesis causales, sino sólo las conclusiones, pero para éstas hay que esperar muchos meses.

No obstante, nadie va a evitar que los humanos emitamos opiniones y juicios, y que éstos, aparte de que puedan ser precipitados, se apoyen en suposiciones. La carencia de datos veraces y claros sólo provocará que especulemos más y peor. Por tanto, algunas de las conjeturas, hipótesis, deducciones o valoraciones hechas con datos cuestionables no serán más que estupideces, o intentos burdos de manipular la opinión pública si hay intereses espurios, como creo que ha habido en algún caso.

¿Por qué los directivos no informaron inicialmente con más claridad sobre la causa del retraso en el primer intento de despegue? Habiendo tanta regulación, ¿por qué no hay mejores límites a la discrecionalidad con la que actúan las compañías aéreas, autoridades aeroportuarias y comandantes de vuelo cuando “secuestran a los viajeros” una vez facturados los equipajes, traspasados los controles y efectuados los embarques?

accidente_aereo_cd080823ePor otra parte, en este caso, creo que los periodistas han estado por debajo del nivel exigible en demasiadas ocasiones. ¿Quién manda a los que, micrófono y cámara en mano, tratan de obtener imágenes morbosas o declaraciones emocionales y acusadoras de los más afectados? ¿Dónde han aprendido a hurgar en la herida y formular preguntas propias de gilís? ¿Cómo se titulan las noticias para extractar sin errores el cuerpo de la información? ¿Para qué lanzan cuestiones al aire en vez de buscar a los que saben las respuestas? ¿No deberían contrastar mejor sus informaciones?

Si miramos a los jefes de los “informadores”, no creo que encontremos un panorama mejor. ¿Por qué algunos decidieron presentar opiniones parciales como parte de un análisis de causas del accidente? ¿A quién pretenden imputar la culpa algunos editores con pocos escrúpulos? ¿Por qué dan rango de información a cualquier majadería que diga un afectado, por mucho que lo esté? ¿Cuál es la noticia: el dolor, la impotencia, el deseo de venganza o la supuesta responsabilidad de alguien?

Tras la catástrofe del Prestige, ¿quién es el jefe partidista que ahora osa no personarse en el lugar de una tragedia para decir «esta boca es mía»? ¿A santo de qué viene enzarzarse en “batallitas” irrelevantes sobre quién fue el primero en activar el plan de emergencia en Madrid? ¿Por qué unos políticos técnicamente ignorantes revelan los comentarios privados de otros que saben menos de aeronáutica que muchos miles de ciudadanos? ¿Qué pretenden examinar los parlamentarios en paralelo con la comisión de investigación? ¿Es que van a revisar las prioridades de gasto en los presupuestos o abroncar a una ministra por un retraso de ejecución que no hubiera impedido nada?

Me sorprendió la rapidez con la que salieron a la palestra televisiva los sindicatos de técnicos de mantenimiento y pilotos de aeronaves a dar sus versiones y opiniones sobre lo que estaba sucediendo. Según ellos, ambas categorías de trabajadores no tienen que decidir nada en este tipo de circunstancias. Dicen que todo lo que hacen está determinado por unos procedimientos escritos. Me parece que esos portavoces no mostraron mucha vergüenza al sostener esa postura. También me parece que no fueron buenos profesionales quienes les preguntaron cuando trataron de hacernos creer que los afiliados a sus gremios no son responsables de nada en relación con el mantenimiento y vuelo de los aviones (¿sólo siguen instrucciones de manual?).

spanair_protesta

Manifestación, en agosto, de los trabajadores de Spanair contra el ERE y por la falta de personal. (Foto: J. Avelló)

Me ha parecido torticero el proceder del SEPLA con sus comunicados relativos a las circunstancias empresariales de Spanair y las negociaciones laborales en curso. ¿Es que sólo los directivos representan a su empresa? La patronal ha tenido que replicar. Si los pilotos de verdad creyeran que las operaciones estaban sufriendo por la crisis de la empresa, ¿por qué retiraron la última proclama de su web al conocer el accidente pocas horas después de haberla difundido? ¿Qué dudas querían sembrar para negociar mejor cuando lo más sensato era sostener que una tripulación no se juega la vida si estima que hay algo que va mal?

Los mayoría de los humanos siente la pérdida de vidas, tanto en accidentes de escaso interés mediático como en catástrofes concentradas en el espacio y el tiempo. En momentos de emociones intensas, ya sean individuales o colectivas, a veces expresamos nuestros sentimientos con palabras que no resistirían un mínimo análisis racional, pero que nos resultan muy útiles para poder continuar la vida. Nuestros problemas pueden comenzar cuando alguien las usa para otros fines, o cuando nos empeñamos en buscar una causa, origen, responsable, acusado, culpable… para cobrarnos un precio por lo sucedido.

¿Quién decidió que viviésemos nosotros y no el hermano que no nació porque nuestra madre abortó accidentalmente? ¿Por qué ha de ser más asumible la muerte por enfermedad que en un incendio? La vida está llena de accidentes. Todos alteran el orden regular de las cosas (según nuestro insignificante punto de vista). Unos son menos fortuitos y más predecibles que otros, pero todos tienen efectos inalterables. El riesgo es inevitable. Lo que podemos hacer, como seres racionales, es tratar de identificar las circunstancias que rodearon lo sucedido para poder prevenir su repetición si condujeron a algo desagradable o doloroso.

Descansen en paz los muertos. Encontremos consuelo para vivir los que moriremos más adelante y, mientras llega ese momento, intentemos dejar información precisa, puntual y plena a nuestros descendientes, algo que nuestra técnica y cultura permiten sobradamente.


[Foto 1: Avión MD-82. AFP]
[Imagen 2: Titular erróneo (rectificado parcialmente: no en la foto). Cinco Días]
[Foto 3: Protesta de trabajadores. El Mundo]

Entradas relacionadas: —

Posted in gestión | Etiquetado: , , , , , | 3 Comments »

Paradojas en el proceso

Posted by josempelaez en Viernes, 4 julio 2008

Tras lo escrito en las tres anotaciones previas, creo que ya hay bastante consenso en que las estructuras maestras de datos no “han de ser” comunes en las aplicaciones empresariales —ni en otros tipos—. Obviamente pueden serlo, pero probablemente sea mejor que no lo sean. ¿Por qué?: porque así hay más…

  • flexibilidad, para reaccionar mejor ante los cambios,
  • rapidez de despliegue, al combinar y reusar componentes,
  • adaptación a distintos problemas, al configurar y reemplazar elementos,
  • control de riesgos, al poder evolucionar paulatinamente y emplear métodos ágiles de desarrollo,
  • economías, al aplicar estándares y no requerirse proyectos de integración complejos, etcétera.

CBDOtra de las grandes paradojas de los sistemas de información (SI) empresariales es que las consultoras de negocio y sistemas, que promovían su empleo con el discurso de la reorganización por procesos, luego solían prescribir sistemas más orientados a datos y documentos.

Lo primordial en los procesos son las relaciones, comportamientos y estados de los objetos que interaccionan como abstracciones de la realidad. Me refiero a planos, especificaciones, órdenes, acciones, tareas, movimientos, pedidos, viajes, cargas (mercancías), inventarios, entregas, facturas, apuntes… Cada uno de estos elementos sigue unas secuencias de pasos dependiendo de ciertos eventos (workflow), pasa por una serie de situaciones (states), y tiene una vida determinada con principio y fin (lifecycle).

Los típicos documentos de un sistema administrativo (partes, albaranes, listas…) se pueden considerar subproductos de información generados durante la ejecución de los procesos —según las fórmulas de la ingeniería y las reglas de los negocios— a partir de un suceso desencadenante (orden, petición, incidencia…). Teniendo el registro histórico de las transacciones detalladas se pueden extraer luego toda clase de informes estadísticos, paneles de indicadores operacionales, cuadros de mando directivos, análisis de rentabilidad por actividades, información agregada para decisiones…

Aquí encuentro otra paradoja porque, si un SI está orientado a los procesos, el tratamiento requerido de los documentos asociados (registros de información) se produce como una consecuencia lógica, pero ésto no suele suceder en sentido opuesto. Creo que hay un mal enfoque de muchos SI que se deriva de la simple mecanización de los viejos procedimientos administrativos. ¿Cuántas veces los programadores de los System/38, AS/400 y System i de IBM, tan usados en las medianas empresas industriales y comerciales, han tenido que borrar transacciones de movimiento de fondos o de mercancías porque alguien no quería que se viera lo que había sucedido realmente durante el proceso? ¿Es útil esta información adulterada?

Network SynchroEn los procesos, los datos maestros que se repiten en muchos documentos son secundarios. Incluso los que aplican el principio de unicidad de maestros no pueden impedir que existan datos duplicados. ¿No son también entidades proveedoras las clasificadas como clientes, aunque lo sean de otras organizaciones del «ciclo productivo»? ¿No debiera tener el componente “cliente” un comportamiento distinto según las circunstancias? El que sus atributos más estables puedan estar almacenados de manera consistente en varios sitios es un problema técnico que hoy ya está bien resuelto. Que se hable de replicación de bases de datos, coordinación de agendas, alineamiento de maestros, red global de sincronización de datos (GSDN )…, debiera de ser una cuestión menor.

En el diseño moderno de SI, ¿vamos a seguir empleando como restricciones las de la informática antigua?: ahorrar espacio de almacenamiento, normalizar datos para evitar redundancias e inconsistencias, programar sin parámetros ni reglas contingentes para procesar rápido, trabajar en local para eliminar indisponibilidades o latencias de red… ¡Qué paradoja que un sector de innovación tan acelerada siga lastrado por dificultades técnicas superadas!

En el campo empresarial de las operaciones —el que conozco mejor—, desde la extracción de la materia prima hasta su recuperación al final de su ciclo de vida útil, hay muchas actividades concatenadas que afectan a numerosas empresas de diversos tamaños y especialidad. ¿Cómo ha de tratarse la información asociada a esos procesos para gestionarlos mejor?

La visión de la empresa que se apoya en estructuras organizativas y maestras de información es anticuada. Replica organigramas y formularios propios de una organización tradicional ya superada. ¿De qué empresa hemos de tomar la “visión dominante” en una «demand-driven supply network»? ¿Por qué no pueden gestionarse directamente los procesos (comerciales, ingeniería, operativos, de personal, de sistemas, contables…) en lugar de los documentos, ya sean de una empresa o de una red de organizaciones? Cada abstracción de la realidad tiene sus datos de referencia y reglas asociados. Éstos no tienen por qué ser visibles desde el exterior del componente si se emplean esquemas de «petición-respuesta» en el funcionamiento de los SI. ¿Por qué han de estar agrupados en maestros comunes?

Service Oriented ArchitectureMe parece que las grandes consultoras industriales, que hace tiempo que aparcaron el discurso del BPR, ahora hablan mucho de SOA, BPM, ESB… Tengo dudas acerca de que sepan realmente, o de que quieran explicar bien, lo que ello implica, que es más que integrar servicios de aplicación. Me temo que sólo traten de seguir vendiendo jornadas de servicios profesionales a espuertas bajo una nueva etiqueta, como sucedía en los grandes proyectos de implantación de ERPs de hace pocos años.

A mí, la «arquitectura orientada a servicios» me refresca lo que aprendí en la universidad sobre resistencia de materiales, como recordaba en Maestros y estructuras. Las flexibles no se oponen de forma rígida a las acciones derivadas de los cambios del entorno que actuan sobre su periferia; se acomodan para no colapsar bajo su presión y poder conducir el esfuerzo resistente hacia unas bases sólidas de sustentación, servicio prestado por los cimientos. ¿Qué relación veo entre el análisis estructural y la arquitectura de servicios?

Para mí, un enfoque de SOA para los SI transaccionales debiera permitir trabajar con todos los variados y variables detalles que intervienen en las diferentes partes de los procesos. Es lo que considera un arquitecto o ingeniero cuando contempla las posibles acciones de viento, nieve, agua, vibración… que pueden impactar en las distintas partes de la estructura para calcular sus efectos. El análisis también debería contemplar servicios para guiar las acciones de cada agente participante (persona, equipo, máquina), registrar lo ocurrido en cada lugar e instante relevantes, y transmitir todos esos datos precisos, puntuales y plenos para su consolidación, como cuando se instrumenta una estructura resistente. Así se lograría una base de información real, no organizada necesariamente en documentos, sino más orientada a procesos, acciones o servicios. Ello permitiría decidir y dirigir mejor las empresas en todos los escalones de sus actividades sin tener que esperar obligadamente al final de cada semana o mes para que se hayan “cocinado” los datos relevantes.

Parafraseando a Eduardo Torroja, un tipo estructural de «sistema monolítico» basado estructuras maestras de datos comunes no va a adaptarse bien a los cambios; uno flexible armado con componentes que interactuan, encapsulando sus datos y reglas de comportamiento, sí que puede hacerlo. Se adapta sobre la marcha y no hay que post-procesar nada.

[Ilustración 1: Component-Based Development Cycle © OIG Ltd 2002-2003]
[Ilustración 2: XC Bridge, © Xchange Network]
[Ilustración 3: Service Oriented Architecture © eSchool News]

Posted in integración | Etiquetado: , , , , , | 3 Comments »