Phenobarbital con Soda

Este artículo es una mezcla entre queja formal, documento informativo, petición de ayuda y hasta una forma de catársis con respecto al gran malestar que tengo sobre algunos procesos y “modalidades” de migración y de la comunidad del software libre en Venezuela.

Preámbulo: Sobre SGHM

SGHM fueron las siglas escogidas (casi que al azar) para indicar “Sistema de Gestión de Historias Médicas”; el SGHM se dispone a ser:

“Una aplicación sencilla, escalable, n-capa, múlti-servicios todas las necesidades del Sistema de Salud Venezolano (incluyendo los Centros Médicos Diagnósticos de Alta Tecnología), se ha tomado la decisión de modelar (y posteriormente implementar) una solución ntegrada de desarrollo que contempla entre otras cosas:
1. Gestión de historias clínicas distribuidas y escalables
2. Administración de los procesos médicos, ambulatorios y administrativos en un sistema abierto de flujo de trabajo
3. La utilización de una gran variedad de estándares internacionales de desarrollo de aplicaciones médicas
4. Implementación de una plataforma escalable y ampliamente distribuible
5. Gestión de todos los procedimientos médicos y administrativos (gestión clínica-hospitalaria)
6. Banco común de datos de personas y pacientes (permite por su estructura y jerarquía, realizar importantes manejos estadísticos así como minería de datos)
7. Llevar los requerimientos de hospitalización, servicios, pacientes de una manera centralizada o distribuida
8. Establecer estandares comunes de desarrollo para toda la plataforma de salud pública
9. Mejorar la seguridad de los sistemas administrativos-médicos actuales al implantar una plataforma de seguridad única y centralizable”

Un vinculo con un documento descriptivo de la idea aqui: SGHM y CMDAT

SGHM no ha recibido hasta los momentos ningún apoyo por parte de algún ente interesado; ya veremos por qué …

Pero el desarrollo de ideas y aplicaciones como esta se estrellan contra una gran cantidad de obstaculos, vamos a enumerarlos uno a uno.

Obstaculo 1: Tecnología

Existiendo alternativas (openEHR) y protocolos ya existentes (HL7), normas ISO y demás; es una apuesta innecesaria no utilizar estándares existentes (como XDS, un tipo de XML::OpenDocument ideal para el intercambio de información médica) y la construcción de aplicaciones siguiendo ideas y normas como IHE (Integrating Healthcare Enterprise); la gran mayoría de las personas aun apuesta por esquemas privativos; formas de trabajo obsoletas (plataformas cliente-servidor no escalables, ausencia de modelo SOA, o uso de una API no común y cerrada); un ejemplo clásico ocurre en ¿Por qué hacer un esquema propio de clasificación de enfermedades si ya existe ICD?, ¿Generar historias en PDF?, ¿Por qué si OASIS posee años de experiencia en el modelaje de estándares abiertos de formatos documentales, incluyendo uno para formatos médicos?.

La cuestión con la tecnología se estrella contra una segunda pared; la ausencia de personal realmente capacitado para llevar a cabo una propuesta de este tipo; en Venezuela, existe la costumbre altamente extendida de mentir en el curriculum; esta mentira se extiende a las capacidades de las empresas; muchas ofrecen una experiencia “solo igualable a la de Dios” en ambientes médicos, de gestión documental o de desarrollo de aplicaciones en SL y en algunas, solo veremos que tienen una demo en Visual Fox Pro.

El hecho de tener un sistema heterogéneo, de n-capas, con un backend en LDAP o PostgreSQL, choca con la ausencia de personas capacitadas no solo para entender el modelo de datos; sino que además, entiendan las herramientas donde se sentarán las aplicaciones (¿Cuantas universidades actualmente están enseñando postgreSQL o están enseñando normas LDAP v.3?); con lo cual, se hace imperioso que el sistema sea abierto, colaborativo, para obtener la mayor participación de la gente dispuesta; sin importar sin son venezolanos o neo-zelandeses.

Pero ahi viene la tercera pared y el obstaculo número 2.

Obstaculo 2: El esquema tradicional de “los esclavitos” versus “Desarrollo Colaborativo”.

Por lo general; es de común arraigo en Venezuela que las empresas desarrollan software y el estado les compra; en este caso es una simple transacción financiera capitalista; donde una empresa vende un software; este mal ejemplo ha sido “migrado” a la filosofía del software libre y en vez de crear grandes proyectos colaborativos; donde dos o más empresas se unan para colaborar con esta aplicación (OpenOffice: Proyecto Oasis; Ubuntu: Canonical; Bind-DNS-DHCP: ISC; etc) en Venezuela se sigue el esquema de reducir la migración a Software Libre a una simple transacción comercial donde “la empresa crea, el estado compra” o donde “el estado contrata y recibe un software).

El problema oficial de este esquema es que una sola empresa no tendrá el recurso para contratar a: expertos en modelado de aplicaciones y arquitectos, programadores con amplios conocimientos del lenguaje, especialistas de lógica del negocio, etc; como siempre digo en mis charlas “ninguna empresa venezolana que esté haciendo una aplicación en python podrá contratar de 8 a 12 y de 2 a 6 a Güido Van Rossum (creador de Python); pero podrá contar con su experiencia si libera el código y a Güido le gusta la aplicación”.

El término “esclavitos” deviene de la costumbre ancestral de que una aplicación debe ser desarrollada por gente de la misma empresa; sin intervención ni injerencia de entes externos; por ende, terminas contratando a cientos de chamos (pasantes, tesistas, perro-calienteros, quincalleros tecnológicos, etc) bajo el esquema de “sean inteligentes de 8 a 12 y de 2 a 6, lunes a viernes” y “les pondré computadoras, cigarros, internet y coca-cola”; sin embargo, en el área de SL todos sabemos que esto no es así (el 80% del código fuente del kernel Linux fue desarrollado en horas no laborales por técnicos de empresas como HP, IBM o Sun; el stack para webcams del kernel linux fue desarrollado por un matemático y físico del MIT luego que se jubiló y el profiling de los elevators del kernel fue optimizado por un anestesiologo en sus ratos libres) y este esquema lleva a un fracaso terrible; ya que además de coartar la libertad de colaborar a cualquier hora; nunca en tu staff de “esclavitos” tendrán la experiencia de años de desarrollo en tecnologías libres que podría tener cualquier miembro de la comunidad de SL y que quisiera participar colaborativamente en el proyecto.

¿Desde cuando estoy pidiendo yo tener acceso al código fuente de la aplicación de CADIVI para mejorar los errores de validación que tienen a nivel de la lógica del dominio? …

Obstaculo 3: La empresa capitalista y el esquema colaborativo

El tercer punto importante en esta cadena es que al tener una única empresa mamá de todos los pollitos y custodia del gallinero; nos encontramos realmente con una imposibilidad técnica y política de generar un desarrollo colaborativo; en vez de usar canales verdaderamente regulares del Software Libre (CENDITEL, RINDE, SourceForge) la tendencia es mayoritariamente a crear un entorno capitalista donde una empresa vende y un estado compra; nada de participación de la comunidad. ¿Alguien tiene acceso a la API del SENIAT o al repositorio del CNE? …

Una de las excusas más nombradas por este aspecto es tener a “alguien que me dé soporte” (más bien: “Alguien a quien echarle la culpa”); sin embargo, ya muchos usan OpenOffice y como he dicho, una cosa muy distinta es quien lleva el proyecto (Sun-Fundación Oasis) y otra es quien sabe OpenOffice y lo instala en tu oficina (cualquier empresa o cooperativa); mezclar ambos conceptos (quien te instala y da soporte es quien te hace la aplicación) es volver al viejo esquema de comprar licencias Microsoft.

Para los funcionarios y líderes de instituciones que “desconocen” la forma como se “debería” gestionar un proyecto de Software Libre; aquí va un flujo de trabajo:

1. Se postula una prueba de concepto; basado en investigaciones dentro de la institución, sobre requerimientos y necesidades en materia de SL
2. Se procede a la solicitud de empresas (y/o cooperativas) que puedan “facilitar” una plataforma de desarrollo colaborativo (repositorio, bugtracker, wiki, página de documentación del proyecto, página oficial del proyecto, etc) y una plataforma de pruebas (banco de pruebas) completamente confiable
3. Se procede a hacer público el proyecto, a través de meRINDE y/o CENDITEL y se convoca a empresas a participar.
4. Se nombra un líder oficial del proyecto; siendo la(s) empresa(s) las que mantendrán el desarrollo abierto y funcional.
5. Se obtiene a través de LOCTI apoyo a aquellas empresas que presten horas/hombre de desarrollo colaborativo para la aplicación
6. Se convoca a otros entes gubernamentales que se beneficiarán de la herramienta; a ayudar a pequeñas cooperativas y empresas a dedicar recursos al apoyo de este proyecto.
7. Cada cierto tiempo las empresas líderes liberarán versiones “estables” del código para el uso por los entes participantes.
8. Otros grupos organizados (e incluso la comunidad en general) podrá contribuir con parches, documentación, Wiki, traducción a otros dialectos, etc.

Este esquema no se cumple aun en NINGUNA aplicación funcionando actualmente en Venezuela; y eso nos lleva al siguiente obstaculo.

Obstaculo 4: Implantación de lo inestable

La gran mayoría del desarrollo de software (privado o abierto) en Venezuela; salvo ciertas excepciones, pasa directamente de su desarrollo a fase de implantación sin pruebas previas; siendo corregidos sus errores con data en vivo (¿cuantos fallos de aplicación fueron corregidos en la página del SENIAT cuando la gente se quejaba de su operatividad?); constituyendo esto el gran enemigo del software libre como lo conocemos.

Una cosa importante que aclarar es que por lo general todo software abierto se le considera en “beta perpetua”; porque siempre se le están agregando nuevas funcionalidades; eso no significa que como proyecto, todo código agregado debe ser “puesto en producción” sin unas pruebas previas al mismo y sin realmente estar completamente seguro que “en todas las plataformas, combinaciones, arquitecturas y clientes” el código va a funcionar como se esperaba.

El ciclo que por lo general se debería seguir es el siguiente:

1. Se declara una “alpha” privada, en un portal vinculado al servidor de desarrollo, donde la gente puede probar la aplicación y recomendar mejoras o reportar bugs (esta alpha debe tener vínculos a los sistemas de bugtracking, tickets de soporte y al wiki del proyecto).
2. Se declara una “beta pública” sobre la que se agregan pocos cambios y se van resolviendo los bugs de la alpha; se extiende el proceso de pruebas al mayor número de personas posible en la mayor cantidad de plataformas posibles
3. Se declara una “versión estable” a la que solo se le corregirán los bugs que se vayan encontrando en el código
4. Toda nueva solicitud de función, será agregado a la próxima liberación de una “alpha pública”; volviendo a comenzar el ciclo.

Dicho ciclo no se cumple; ya que en muchisimos casos ni siquiera se tiene acceso a un sistema de reporte de fallos para que las personas encargadas del desarrollo de la aplicación sepan “qué está fallando” y cuando lo deben corregir.

Otro de los grandes males que causa la implantación de lo inestable es la mala fama que muchas aplicaciones “hechas con Software libre” han sido mal diseñadas y le aportan mala fama al movimiento (recuerdo una aplicación hecha en visual basic, con un back-end en mySQL; los programadores hacian las consultas optimistas, con bloqueo de tabla y registros del lado del cliente; pero el que la aplicación fuera lenta era culpa de la “base de datos libre” y no del mal diseño de la aplicación VB); ¿Es culpa del estándar ECMA que CADIVI valide mi presencia en el portal usando un javascript desactivable? … no, es como le digo a todo el mundo, usando el argot OSI, ¡es problema de Capa 8!

Obstaculo 5: El FUD de las empresas de desarrollo

Muchas empresas (incluso en este proceso, de ayudar al CNE, MINSalud, ONIDEX) han llegado con extensa publicidad sobre sus grandes capacidades en SL; algunas publicitan sus productos como “software libre” pero solo le entregan el código a quien lo adquiere y no realiza ni transferencia tecnológica ni mucho menos le permite distribuir los cambios realizados al software; coartandose una o a veces todas las libertades del software libre.

Las empresas tienen a llenar no solo de publicidad de “dudosa validez” acerca de su experiencia; sino que además, llenan de FUD a la comunidad del SL y no le permiten a ésta participar del desarrollo, validación, ampliación o colaboración; convirtiendo a la comunidad de software libre más que en un aliado, en un enemigo.

Obstaculo 6: Cumplimiento de las libertades

Entiendase por las libertades del software libre; a todas aquellas acciones que le permitan a todos disfrutar de los beneficios y participar en el crecimiento y uso de una aplicación; una aplicación no puede declararse “libre” cuando no permite modificaciones en el código; cuando no permite “forks” o cuando no hace pública una API para realizar extensiones o mejoras.

El simple hecho de no cumplir las 4 libertades del software libre; debería descartar a cualquier desarrollo (venezolano o no) de ser “considerado” Software Libre. El decreto 3390 ha causado más un mal que un beneficio; al permitirle a las empresas captar clientes potenciales usando “desinformación” publicitandose como “héroes del software libre” aun cuando NADIE ha visto una línea de código de esas empresas.

Obstaculo 7: Paquete versus tecnología

De último, pero no menos importante se encuentra en el modo como se ha “orientado” la migración en Venezuela; por lo general históricamente el venezolano se ha acostumbrado en el área informática a ser consumista y a aprender “paquetes” y no “tecnologías” (ejemplo; en vez de ANSI C, aprendes Borland C, en vez de ANSI SQL, aprendes Oracle u MS SQL Server, en vez de aprender Basic, Visual Basic, en vez de (x)HTML aprendes Dreamweaver y en vez de aprender Documentación y ofimática aprendes Microsoft Office); por lo que erroneamente se ha enfocado a la migración de la misma manera; el reemplazo de un paquete por otro; en este caso, muchos ministerios (incluyendo el de salud) orientan al sistema de historias médicas no como un sistema abierto, interoperable, completamente GPL, sino en un “paquete” creado por una única empresa y como reemplazo de algún único paquete anterior (o en estos casos, un paquete que se implanta usando un modelo privativo de desarrollo en donde no habia nada).

El problema de esto es que no estamos fomentando la existencia de estándares, uso de tecnologías existentes ni tenemos la forma de formar especialistas en el área médica; volveremos a formar “expertos en paquetes”; pero esta vez, paquetes GPL.

El hecho de que pueda argumentar que un modelo “arbóreo” (tal vez LDAP) es más idóneo para organizar datos de personas y sus interrelaciones que una BD relacional (mySQL, postgreSQL) me da pie para pensar que puedo hacer un fork de una aplicación de historias médicas aplicando otra metodología y otra tecnología para mejorar su organización o tal vez su desempeño; pero, ¿como puedo crear un fork de una aplicación o como puedo participar en su mejoramiento tecnológico de algo a lo que no tengo acceso?.

El peor de los casos es cuando el paqueterismo crea “nichos”; donde el alto acomplamiento de los componentes que conforman el sistema hace virtualmente imposible que; por ejemplo, el sistema de CADIVI viva sin Oracle o el del CNE sin postgreSQL; tambien imposibilita la creación de sistemas heterogéneos.

Un ejemplo de un sistema heterogeneo podría ser combinar las capacidades de openLDAP y postgreSQL en una misma aplicación; más toda una infraestructura de comunicación basada; por ejemplo, en XML-RPC, permitiendole a aplicaciones de terceros ser “consumidores” de mi información, y no obligar a todo el mundo a llegarle a mi aplicación via “una página web hecha exclusivamente para Internet Explorer” como pasa con algunos proyectos.

Conclusiones

No podemos seguir otorgandole nuestras aplicaciones “vertebrales”; los centros neurálgicos de información a dos o tres empresas y además confiar más en los “paquetes como un todo” que en la implantación correcta de las tecnologías.

Es hora ya de crear un modelo estable, coherente y participativo para la creación de las aplicaciones de SL para la administración pública; ya es suficiente de tener aplicaciones implantadas incompletas e infuncionales y que además no podamos ni siquiera quejarnos de las mismas pues no existe la infraestructura para ello.

Considero sumamente importante que este proyecto puede ser el pilar fundamental de ello; SGHM (o como alguien quiera llamarlo) es una idea liberada bajo la FDL (Free Documentation License) y aspiro ir trabajando la idea todos los días y conseguir un lugar donde hacer un repositorio, un bugtraker, colocar a la disposición de la comunidad un wiki, un centro de sugerencias, área de documentación y esperar la participación de todos y cada uno de los presentes en la comunidad de software libre; no esperemos a que la “Empresa de Producción Social Perico de los Palotes y compañia” gane acceso irrestricto a toda nuestra información (datos bancarios, CNE, onidex, inces, minsalud) y que ni siquiera tengamos la posibilidad de contribuir con una mejor arquitectura, una mayor seguridad o un mejor modelo de datos; que nuestra información fiscal, financiera, de dólares o de sunacoop se convierta en una simple transacción financiera entre A y B y uno como ciudadano soberano no tenga ni siquiera la posibilidad de saber si lo que está ahí detrás es seguro o algún loco (como Tascón) tiene acceso ilegal a los datos y hacen con mi vida lo que les viene en gana.

¿Acaso les gustaría que una persona cualquiera usando algún ataque no documentado, publique al mundo que son impotentes porque tuvo acceso a nuestra información médica de manera ilegal? …

Es menester como comunidad que empecemos a demostrar que verdadero y amplio desarrollo colaborativo es posible; ayudenme a demostrar que eso es así …

Estuve leyendo los comentarios generados luego del BRM para la votación y aprobación de ISO/IEC 29500 (OOXML) y de verdad me he quedado atónito de las recomendaciones que hace ISO para convertir a OOXML en un estandar “util” (y así, inutil y todo, ¿votaron que sí?, que pena hombre!); le queda mucho trabajo a Microsoft, ECMA, ISO JTC1 y el SC34 (además de a FONDONORMA) para poder crear una versión completa e interoperable de este estandar.

Algunos puntos de interés

El NB Alemán (el DIN) propone generar una lista de compatibilidades e incompatibilidades ODF <-> OOXML para lograr una verdadera interoperatibilidad entre ellos; por ejemplo, a la hora de la conversión (aseguro que dicha conversión favorecerá más a ODF si viene de la comunidad de software libre y más a OOXML si viene de Microsoft); que dicha “hoja de ruta de conversión” venga de una oficina del ISO en Alemania permitirá para un futuro mejorar las relaciones entre ambos formatos.

De hecho, aproximadamente 7 Technical Bodies trabajan en distintas partes de la interoperatibilidad de ODF con OOXML (como la construcción de schemas compatibles con DTD) incluso ya ISO/IEC JTC1 SC34 ha iniciado un proceso de evaluación para indicar cual de los formatos responde mejor a un regimen de mantenimiento en el tiempo y que responda eficientemente a pruebas y posea suites que lo implementen; como sabemos, el único beneficiado de esta evaluación será ODF.

Permitiendo la modularidad

Como indiqué en el anterior post; OOXML posee dentro de sí una cantidad enorme de formatos (VML, XAML, SpreadSheetML, OMML, etc); para la mayor modularidad de la implementación; ISO ha solicitado una nueva votación para dividir en 4 la especificación de OOXML:

1.- OOXML en si mismo; todo lo que respecta al nucleo del formato

2.- OPC: el formato de compresión basado en ZIP (si estoy en linux, preferiría bzip2)

3.- Extensibilidad (compatibilidad con otros formatos, esto no existía en OOXML)

4.- Otras características: VML y otros lenguajes (WordML, OMML, etc) y características de migración.

Dentro de esta cuarta categoría se incluyen otros lenguajes de OOXML

Además, se debe forzar a OOXML a ser:

• Compatible con otros estándares ISO
• Usar una Sintaxis Backus-Naur (BNF)
• Se debe obligar a OOXML a usar siempre notaciones IANA/ISO en códigos (colores, nombres, country codes, etc)
• Permitir; por defecto, el uso de medidas ISO (y no formatos de papel anglo; ej. ISO A4 por sobre “US Letter”)
• Uso de formatos ANSI/ISO de fecha y no los personales de Excel
• Definir un sistema de validación basado en schemas (como Relax NG, Schematron o XSD)
• Definir el uso de DTD en sus documentos y la conformación de namespaces para la construcción de documentos complejos (ej.
• <math:derived>
• Sustituir spreadsheetML y OMML por un lenguaje más modular, como MathML y compatible con namespaces, como openFormula
• Excesivas referencias a “vocablos Microsoft” en el motor XML deben ser eliminadas y agregadas solo compatibilidades con la W3C

El nacimiento de un monstruo o el sacrificio del neo-nato

Puede Microsoft (quien despidió a David Robbins en 2004 por no poder modificar su motor XML .NET para hacerlo compatible con estandares) hacer todos estos cambios sin afectar tecnologías ya impuestas (que siguen las mismas reglas de OOXML) como XAML, .NET u otras?.

Puede Microsoft dedicarse de lleno a asesorar al grupo conformado por los NB, comité ISO y ECMA para evitar que su formato se convierta en un monstruo incapaz de manejarlo con sus propias tecnologías?

De plano, considero que si OOXML sigue las reglas fundamentales de crecimiento de todo estandar ISO (como ODF) será algo importante de ver en los proximos años y algo satisfactorio que .NET (y su contraparte Mono) sean ahora más estrictos con las normas de XML y no tan “relajados” y muy a lo “Microsoft-stylish development” (de hecho, ya quiero ver un modulo para silverlight-moonlight que use SVG en vez de XAML como lenguaje de vectores).

Es una tarea titánica lograr hacer funcionar a OOXML según las normas arriba expuestas; es más facil integrar las cosas que le faltan a ODF (pues al menos cumple con las reglas de ISO) que modificar a OOXML; considero que Microsoft comenzará a implementar a OOXML sin esperar estos cambios, causando (otra vez) que sus documentos sean incompatibles y renderizen mal en otras aplicaciones.

Esto es; Microsoft sacrificará a su neo-nato y se quedará con el Draft que metió a ECMA en diciembre del 2006; toda correción subyacente dentro de ISO tardará mucho tiempo en salir como para que Microsoft espere por ellas para empezar a implementar OOXML; es toda una cuestión de políticas de mercado, marketing y venta de licencias y aplicaciones; nada de apertura de estandares, buenas aplicaciones y mejora en la tecnología.

Y lo que viene

ODF inscribirá su versión 1.2 en ISO dentro de poco; como parte de su gradual expansión e inclusión de nuevas características; OOXML posee más de 3000 errores y más de 1000 características que implementar para ser un estandar válido para ser usado seguramente en aplicaciones en un futuro cercano; ejemplo:

No hay forma de determinar (al no existir validación DTD) si tengo un tipo incorrecto de archivo a la hora de abrir el documento, por ende, puedo agregar y ejecutar código malicioso haciendolo pasar por otro tipo de documento sin que existan dentro de OOXML reglas para prevenir esto (sigue Microsoft sin forma de prevenir Virus).

La eliminación de Bitmasks por atributos, es algo que OOXML usa demasiado y no hay una forma sana de corregirlo

Todos los errores de fechas no han sido corregidos …

OOXML debe soportar muchos más algoritmos de cifrado que los impuestos en su draft

Debe abrirse una ventana para la interoperatibilidad entre OOXML y otros formatos (SVG, por ejemplo)

Eliminar todo lo MS-centric (o US-Centric) de las especificaciones y agregar más como: soporte a unicode estricto, control de medidas ISO, soporte a escrituras no occidentales (escritura derecha-izquierda, por ejemplo) y más accesibilidad (para personas con discapacidades).

De hecho ODF agrega muchas características de accesibilidad en su versión 1.1; la industria verá con mejores ojos agregar nuevas características a ODF que corregir los errores y agregar nuevas a OOXML; por lo que OOXML quedará relegado al uso exclusivo de Microsoft y su séquito de seguidores.

Conclusiones

A estas alturas, quien se le ocurra instalar una beta de MS Office 2008 es un completo y cegado fanático Microsoft, de eso no hay duda …

Si Microsoft acepta corregir todas las observaciones, fallas, errores de diseño e implementar mejoras y ampliaciones, no veremos una implementación sana y segura de OOXML sino hasta MS Office 2010 (quien quita si MS Office 2021 jajaja) por lo que MS implementará a como de lugar su “estandar” de la manera como el sabe, “a lo arrecho y a su modo”; este año y el próximo será de evolución de ambos formatos y veremos el nacimiento de un creciente nicho de mercado para las aplicaciones de oficina “No-Microsoft” y un evidente ascenso de los formatos libres; incluyendo ODF.

Todos más o menos conocemos la definición formal de Burocracia; a este sentido la división especializada y formal de tareas dentro de la administración pública tiene como fín lograr un mejor desenvolvimiento del estado como un todo; mejorando notablemente la actividad y la satisfacción de los ciudadanos; pero eso en venezuela, ¿es así? …

Un amigo (Tr0n), siempre dice que en Venezuela la constitución debería tener un único artículo, que rezara “Aquí es así!, punto!”; a eso lo uno con la patética viveza criolla para lograr un estado lleno de gentes por “amiguismo”, “palanca”, “roscas” o “cuanto hay pa’mi!”; creandonos una administración pública inútil, sosa, pesada, llena de defectos, con personas que no desean para nada innovar, tener la iniciativa o con ganas de aumentar su productividad; en fin, la burocracia nos carcome el sistema.

Aunque de manera más que evidente, los ejemplos que tengo para acotar son muchisimos, realmente no quiero extender mucho este artículo salvo para dar una alerta y quejarme de a donde estamos llevando al país con tanta pesada maquinaria burocrática sin sentido; la gente no se da cuenta pero estamos acabando con el país por culpa de sus acciones, nada de medidas macroeconómicas o “la culpa es de Chávez”, esto ha sido así siempre y con el incremento de la maquinaria del estado por parte del gobierno es mucho más palpable y evidente.

Llegamos a un punto, donde hasta hacemos mal en nuestro sitio de trabajo público ya que en otro me trataron mal, convirtiendose en una cadena de malos tratos o desidia interminable …

El título de este artículo viene de un hecho insólito dentro de esa maquinaria burocrática y de como los trámites administrativos creados por estos seres (serán en verdad humanos?) dentro de esas maquinarias son hechos más para frustrar las intenciones de los usuarios de gestionarlos que en favorecer la transparencia del estado; les comentaré …

Realizando unos trámites administrativos para la constitución de una  cooperativa; me encuentro con qué el actual INCES emite un documento que es necesario por el Ministerio del Trabajo, insólitamente durante los trámites, el INCES requiere para el trámite del documento una formas emitidas por el Ministerio del Trabajo que solo son emitidas por este si tiene en su poder la solvencia del INCES; ¿ven a donde quiero llevarlos?; alguno de los 2 institutos siempre “flexibiliza” su postura (o a veces, si eres impaciente, te pedirán dinero para “flexibilizarse” un poco) pero a fín de cuentas; organizativamente, ambos documentos son requeridos y son mutuamente excluyentes el uno del otro, haciendo imposible su emisión sin alguna “maraña” de por medio.

Lo más triste del caso es que ambos documentos posee “caducidad” y uno vence antes que el otro, obligandote a veces (si no eres rápido) a sacar uno de los documentos por segunda vez; para colmo de males, el INCES solamente trabaja en las mañanas y atiende a no más de 5 personas por día (según ellos, porque los trámites son engorrosos y no se pueden dar el lujo de “abarrotarse” de solicitudes; en algunas veces solo atendían a una persona diariamente (lo cual contraviene mis derechos constitucionales; pero, ¿a quién le reclamas? …

Para añadirle una pizca de sabor a tu vida; SUNACOOP requiere AMBOS documentos para tramitarte la solvencia y te la entregará a los 3 meses; pero los documentos tienen una caducidad de 15 días por lo que cuando SUNACOOP te entregue sus documentos, los otros estarán vencidos …

¿Donde queda la simplificación de procesos?, ¿La automatización de tareas?, ¿las mejoras en la gestión? …

Bueno; les diré, pero me deben pasar la pregunta por escrito y en triplicado agregando la fotocopia de la cédula de identidad, vacunas del perro y últimos 3 estados bancarios …

ah!, la recepción de recaudos es todos los viernes entre 8:45 pm y 8:46 pm (ambos inclusive) y deben venir en sobre manila  membretado …