lunes, 11 de abril de 2011

Cuando el dato falla... (y 2)

La verdad es que me he sentido muy 'usuario' (cosa rara en un consultor) al pasar por el banco.
Como comentábamos en el artículo anterior, un porcentaje alto de los borradores de hacienda están mal y explicábamos una serie de causas.
La causa principal es que no incluyen todo lo que tienen que incluir y, por tanto, asumíamos que Hacienda (con H mayúscula) pretendía ahorrarse algunos eurillos en devoluciones si colaba el borrador erróneo.

Pensando en que el borrador estaba mal por esta razón, me he pasado por mi oficina bancaria a pedir los datos fiscales del año pasado y cuál sería mi sorpresa de que los datos que me han suministrado no incluían temas hipotecarios.

Así que, ¿si ni el propio banco los tiene cómo narices los va a tener Hacienda?. Aparte de la obviedad, nos lleva al cuarto motivo de que un dato falle: omisión técnica o 'el dato que nunca estuvo allí'.

¿Un dato es correcto en un determinado momento aunque sepamos que le falta algo pero que todavía no estará disponible? ¿Por qué no se advierte de esta circunstancia en el borrador con un mensaje tipo...

Hemos hecho un borrador. No sabemos exactamente lo que incluye ni si falta o sobra. Revíselo usted porque lo que es nosotros no estamos seguros y al final Hacienda somos todos... Una ayudita.

?

El caso es que como usuario de Hacienda creo que los datos no me cuadran. Y como usuario de mi banco me pregunto qué extraño proceso informático necesita 4 meses para calcular las retenciones de una hipoteca sencillita como la de un servidor (especialmente cuando me envían cada año de antemano lo que voy a pagar de intereses y amortización de capital...)

Señores de mi Banco, si necesitan una ayudita con procesos de gestión de datos sólo tienen que pedirla que encantado les ayudaré... A un interés muy alto.

sábado, 9 de abril de 2011

Cuando el dato falla...

Ahora que hace poco que ha comenzado la campaña de la renta de 2010, leo con 'estupefacción' que uno de cada tres borradores (entre ellos el de un servidor) tienen errores.
No he hecho nunca un proyecto en el que me permitieran errar el dato en un 33% alegremente, especialmente cuando se habla de temas de dinero.
¿Os imagináis hacer una aplicación que cada mes meta la pata en la nómina del 33% de los trabajadores? No se tardaría mucho en quemar algo más que papeleras...
El caso es que la AEAT ha decidido cambiar la aplicación PADRE por una que se llama RENO, dándole ya a la primera el sobrenombre de 'JUBILADA' y ya sabemos qué pasa en las migraciones cuando no se comprueba bien el dato.

Un dato es erróneo por dos causas fundamentales:
1) Por criterio. Un dato no tiene validez si no incorpora todos los criterios para serlo o bien se mira desde una perspectiva que no corresponde con la información que presenta.
Por ejemplo, si definimos la facturación de una empresa de fabricación de tornillos, ¿es cuando sale de la fábrica, cuando se entrega, cuando se factura o cuando se cobra? Dependiendo del criterio elegido, la facturación del mes será diferente y podrá incluir o no, por ejemplo, los abonos.
2) Por inexactitud. A veces el cálculo o el proceso es erróneo en algún caso, lo que produce que un número (esperemos que pequeño) de los datos no esté bien o bien que tenga una precisión inexacta (falten decimales), afectando en un porcentaje muy pequeño al montante final, que suele asumirse como exacto aunque se sepa que sólo es exacto al 99%.

Así pues, entiendo que la AEAT ha pecado de ambos casos: no ha tenido en cuenta adecuadamente todas las desgravaciones adecuadas y algunas de las que ha tenido en cuenta un porcentaje alto es erróneo. Vamos, que es muy fácil luego echarnos a los informáticos la culpa de que los sistemas funcionen mal y tal y tal.

Pero mirando el bosque en lugar de los árboles, uno se pregunta si realmente han sido errores o bien se establecen como el tercer punto que viene a ser algo así como 'lo-pongo-mal-porque-yo-lo-valgo-y-a-ver-si-cuela-y-entonces-devuelvo-menos-dinero', que también es algo habitual para que a uno le echen menos broncas ante ciertos datos:
- Sale 5
- No puede ser, ha de ser 3,5.
- Pues sale 5.
- Que no, que tiene que salir 3,5
- Pues con los datos y el cálculo, 5.
- Vale, pues que sea 3,5, que si no me matan.
- Ok... Pues habrá que quitar desgravaciones de algún lado...
- Pues sí... Algo habrá que hacer...

Y luego resulta que los piratas somos los informáticos. ¿La Ley Sinde no se aplica a la Agencia Tributaria? ;-)

jueves, 7 de abril de 2011

Barato barato, oiga

No hace mucho tenía yo una conversación con alguien totalmente ajeno al mundo de la consultoría en que hablábamos de tarifas y similares.
Ante la pregunta de '¿cuánto factura por día un consultor?' se quedó alucinado al plantearle jornadas utópicas de 1000€ o más.
Tras explicarle la fabulosa decadencia tarifaria de los servicios de consultoría informática en los últimos 10 años, aún se quedaba perplejo al llegar a una tarifa objetiva de 400-500€ por jornada.
Y entonces surgió la pregunta:
Oye, ¿y no hacéis la semana mágica como El Corte Inglés?

El caso es que me hizo pensar si Iecisa sigue los mismos patrones de oferta que el centro comercial (cosa que no voy a comprobar pero que me temo que no es así) y me permitió explicarle que hay empresas de consultoría que son supermercados y otras que son delicatessen.

Lamentablemente, en los tiempos que corren, es complicado plantear que alguien pueda facturar a los precios que se hacía en el año 2000 (y tampoco eran tan buenos tiempos) pero a veces el regateo es excesivo.
En el grupo de LinkedIn de Profesionales del BI se discutía no hace mucho si el 2011 iba a ser el año del BI y se llegaba a la conclusión de la ridiculez tarifaria con un buen ejemplo que adornaré adecuadamente:

Un día vas al cirujano estético porque quieres quitarte la rodilla que tienes en lugar de nariz y poder parecer un busto griego. El cirujano que te atiende te dice que te costará 5000€.
Tú, como no te interesa pagar 5000€, le dices:
- A ver, señor doctor, usted me quiere cobrar 5000€ por pasar una noche en la clínica, un par de inyecciones de anestesia local y media hora de trabajo suyo y de una enfermera. Le ofrezco 700€, que me parece una suma aceptable.
El médico, obviamente, se niega. Y tú, obviamente, te vas.

Con este ejemplo queda claro que a veces no es fácil vender la experiencia y el 'savoir faire' a un precio adecuado (cosa de la que ya hemos hablado algunas veces en este blog) pero que hoy en día es aún más complicado y se hace por sistema.
Un ejemplo claro son las gasistas. ¿Os ha bajado la factura del gas? ¿A que no? Pues estoy completamente seguro (por haberlo padecido) que de forma sistemática las gasistas han rebajado las tarifas de sus proveedores hasta límites insospechados. ¿Podían pagar más? Claro, pero ¿por qué hacerlo si al final obtengo lo que busco a un precio mínimo?.

Mientras las empresas de consultoría no nos plantemos y planteemos un precio de servicio justo, adecuado y común, nos seguiremos quejando de lo bajas que son las tarifas. Esto es algo que tal vez la Asociación de empresas de consultoría podría tratar... Pero obviamente no le interesa.

miércoles, 6 de abril de 2011

Informatría académica

Hace algunas semanas había colocado en este blog una pequeña encuesta acerca de si debía publicar artículos académicos en lugar de los habituales que suelo publicar.
A pesar de los pocos votos (tendré que regalar un jamón... o un i-jam) sorprende que la mayoría considere que los artículos de este blog sean académicos (más allá del cachondeo de la respuesta...).
Según la RAE, la definición de académico en su tercera acepción (y más adecuada por lo que parece) es:
"Perteneciente o relativo a centros oficiales de enseñanza"

No se da el caso de que mi blog se considere un centro oficial de enseñanza. De hecho, al ser un blog de opiniones y vivencias en el marco de la informática está más cerca de una escuela filosófica que de una academia. Pero es que resulta que la sexta acepción de académico es:
"Perteneciente o relativo a la escuela filosófica de Platón. "

...Que tampoco tiene que ver, la verdad, pero es más próximo, como decíamos. Lo más cerca que he estado de Platón era cuando Microsoft compró Analysis Services a una empresa con dicho nombre...
Así pues, ¿se puede considerar que un artículo como por ejemplo cubos y estrellas es académico por el hecho de especificar ciertas conductas y consideraciones a la hora de plantearse una solución arquitectónica? ¿Es menos académico el artículo de la patrona de los informáticos por su poco contenido teórico?
La gente que conozco que lee mi blog suele decir que 'se me va la pinza' pero que 'tengo más verdad que un santo' (hala, besitos y florecillas silvestres para mí) al contar sin demasiados tapujos muchos de los entresijos de la consultoría y el Business Intelligence y creo que ahí radica mucha parte de lo académico que pueda considerarse este blog.

Existen otros blogs como el de Aníbal Goicochea, el de BI Fácil o el de Chema Arce que tienden a relatar con auténtica pasión pruebas de productos, detalles de implantaciones y demás que son muy útiles (en especial debo felicitar al señor John Goodwin por su blog que me ha sacado de más de un apuro) pero encuentro a faltar blogs de contenido más liviano con el que sentirse un poco identificado en el día a día del consultor accesible al profano de estos mundos (en la medida de lo posible). Eso sí, intentaré leerlos poco que debo conservar mi imparcialidad.

Tras este rollo que tampoco venía a cuento pero que era necesario contar como justificación al resultado de la encuesta, por mucho que pueda molestar al personal (tengo tantos lectores que unos pocos miles que puedan irse no me afectarán sustancialmente...) intentaré que los artículos de Informatría Aplicada sean aplicados y no académicos en la línea editorial habitual de este vuestro blog (aplausos y silbidos, emoción desbordada y ropa interior planeando ante tamaña noticia).

martes, 5 de abril de 2011

Obsolescencia Programada

Detrás de este par de palabrejas se esconde uno de los problemas/virtudes fundamentales de la informática: la obsolescencia programada.
¿Que qué es eso de la obsolescencia? La obsolescencia viene a ser cuándo algo se transforma en obsoleto.

¿Y por qué programado? Porque eso es lo que al final da dinero.

Ejemplo: Si habéis visto alguna vez los progamas 'Overhaulin' o 'Pimp my ride' os habréis fijado que muchas veces los vehículos que reparan/tunean suelen tener más años que los conductores que los heredan. Este es un ejemplo de obsolescencia mal programada. Un vehículo debe de durar como máximo 5-6 años para que así se produzca un nuevo ciclo de compra que permita mantener la economía automovilística a flote. A ningún fabricante le interesa que sus coches duren 50 años y que la gente tenga muy buena opinión de sus vehículos dado que este segundo hecho no le llena la cuenta del banco.

El caso más sonado de este tipo de obsolescencia es en las bombillas. En tiempos de Edison, las bombillas no se fundían... Simplemente se cambiaban de cuando en cuando al romperlas por motivos ajenos a su construcción. Entiendo que a Sylvania no le hacía mucha gracia.

Si trasladamos este caso a la informática, nos encontramos multitud de programas que fueron muy buenos en su época y que han sido sustituidos por otros más avanzados y supuestamente mejores. La realidad es que aún hay una base implantada de AS400 muy importante y de empresas que utilizan listados via query al transaccional o al datawarehouse porque no les supone ningún tipo de mejora cualitativa el hecho de utilizar un ERP más moderno o un sistema de informes ergonómico. Éste es el caso de tener un Corvette del 57 en buen estado.

Yo ya me imagino la mente calenturienta de algún fabricante de software hablando con su equipo de desarrollo:
- ¿Y qué hay de nuevo, viejos?
- ¡Hemos implementado la exportación a excel!
- ¿Y qué más?
- ¡Y ahora además funciona por la web!
- Parad, parad, que me emociono...
- ¡Y hemos incluido 3 tipos nuevos de gráficos!
- Oooh, increíble...

Con estas tres mejoras un fabricante de software tiene, generalmente, para tres versiones completas que repercuten en licencias, implantación, consultoría... Y aquí aparece la relación habitual entre fabricantes y consultoras: yo recomiendo tus productos que dentro de un año tendré que cambiar porque habrás sacado una versión nueva que entonces incorporará la funcionalidad X y me dará trabajo y volveré a recomendar...


Pero claro, plantearse un escenario en que la informática no tiene caducidad sí que generaría obsolescencia programada e inmediata para el 98% (dato aproximado) de las compañías relacionadas con la informática en el mundo. Y yo no querría quedarme sin trabajo...