Blog de JoseMPelaez

Aprendimiento: aprender del entorno con atrevimiento

Archive for 30 junio 2008

Estructuras maestras

Posted by josempelaez en Lunes, 30 junio 2008

El comentario con que arrancaba mi reflexión sobre Maestros y estructuras es el que me había llevado a preguntarme: ¿por qué las distintas aplicaciones empresariales tienen que «disponer de estructuras maestras comunes para las transacciones particulares»? En esta anotación voy a avanzar en la exposición de mi pensamiento, pero su conclusión quedará para la siguiente, por lo que ya advierto de que tampoco voy a llegar a mi destino en este segundo intento.

Creo que, con datos maestros, nos estamos refiriendo a los atributos de entidades tales como clientes, proveedores, empleados, materiales, productos, vehículos, rutas, ubicaciones, centros, operarios, cursos, unidades de obra, cuentas… Es decir, aspectos de la realidad empresarial que tienen cierta estabilidad, si es que esto sigue existiendo hoy. Es preciso que se introduzcan o modifiquen en un sólo sitio, o mejor dicho, una sola vez en cada ocasión en que se requiera. Tienen que ser consistentes y no depender de las aplicaciones. No obstante, con el estado de la técnica moderna, opino que no deben sacrificarse ciertas cosas (flexibilidad, creatividad, innovación, agilidad, adaptabilidad, economía…) a fin de evitar copias duplicadas para ganar espacio, tiempo o robustez del sistema.

grid computingNo es que estos últimos factores no sean ya importantes, sino que se pueden conseguir unos niveles adecuados para ellos a base de replicar, publicar-suscribir, propagar, emular, etcétera. Las computadoras en cluster, los gestores de bases de datos distribuidas, la tecnología grid, las redes de intercambio entre pares, la sincronización de agendas, la “virtualización” de sistemas operativos, el utility/cloud computing… nos brindan posibilidades que antes sólo conocían muy pocos ya que eran aplicables en ambientes reducidos.

Ahora, el almacenamiento y el procesamiento son baratos y bien conocidos. Se puede trabajar perfectamente de forma interactiva y con alta disponibilidad empleando sistemas distribuidos, lo que a veces requiere duplicaciones controladas y datos “desnormalizados”. Me parece que los mayores defensores de los supercomputadores de multiproceso simétrico herederos del mainframe (IBM, Sun…), frente a los más partidarios del proceso masivamente paralelo (Intel, HP, Fujitsu, Dell…) —que emplean granjas de «estaciones de trabajo», redes de servidores estándar baratos, armarios compactos con blades, etcétera— no pueden esgrimir otro argumento mejor que el de la eficiencia energética, y de manera discutible.

También me parece que SAP nos brinda un ejemplo muy ilustrativo en el campo de las aplicaciones y sus datos. Su producto integrado —R/2-R/3-MySAP ERP, para entendernos, ya que en la praxis tienen el mismo núcleo interno— comenzó a implantarse para ofrecer una respuesta financiera inmediata en las grandes empresas alemanas muy estructuradas y dispersas territorialmente por el mundo. Aunque SAP tardó mucho en cambiar su discurso comercial por otro menos limitante, lo hizo finalmente con el anuncio de Netweaver a primeros de 2003. La rigidez puede llegar a ser muy eficiente, pero no suele generar eficacia, que es lo primero que hay que lograr.

No fueron muchos los que se dieron cuenta que su cambio rompía el enfoque de paquete con modelo integrado de datos que aseguraba estructuras maestras comunes para las aplicaciones, lo que habían defendido a ultranza durante casi 30 años. Al nacer el mercado del business software en 1969 —tras “segregar” IBM las aplicaciones y servicios del hardware de sus mainframes— lo que se ofrecía eran soluciones best-of-breed inconexas para los paquetes empresariales (contabilidad, nómina, almacén…). Los problemas de inconsistencias y demoras de consolidación de información que SAP resolvió en sus comienzos tienen ahora mejor respuesta. Y ésta fue adoptada por quienes habían propagado un enfoque previo monolítico y cerrado, pero que resolvió un problema real, al menos para los directores financieros que tardaban meses en consolidar las cuentas anuales de su grupo.

Los planteamientos alternativos a los problemas derivados del ERP integrado no se habían consolidado como una buena opción. Las programaciones de interfaces a medida, el empleo de estándares derivados de EDIFACT, la ejecución de proyectos de «integración de sistemas» con paquetes de EAI dotados de conectores, y la promoción de algunas capacidades de los portales B2B (exchanges) han sido soluciones caras y complejas de implantar y mantener. No han llegado a ser útiles de manera general porque los estándares EDI son rígidos y de mínimos, los proyectos ad hoc emplean mucho tiempo y dinero, y los marketplaces, además de facilitar el intercambio de datos, también pretenden reintermediar los negocios existentes, lo que no gusta a sus agentes.

Entreprise Service Bus Las herramientas de integración basadas en sistemas de mensajería referidas (EAI) nacieron a mitad de los 90 con la proliferación de aplicaciones departamentales. Ésta se apoyó en la difusión de la arquitectura C/S —que también potenció extraordinariamente el despliegue de R/3—, y a su consolidación se aplicaron los enfoques utilizados en la automatización de fábricas y diálogos entre sistemas financieros de los 70 y 80. En la década actual han ido evolucionando hacia los llamados ESB y BPM, planteamientos derivados de los gestores de workflows documentales (difundidos con Lotus Notes) y de las herramientas ingenieriles para diagramar procesos. Creo que estos productos comerciales, junto a las suites de aplicaciones a las que me referiré en otro momento, se van a seguir considerando buenas opciones. Están introduciendo el mismo tipo de middleware que permite conformar un sistema integrando fácilmente muchos componentes «débilmente acoplados». Otra cosa es que puedan mantener sus precios dadas las alternativas disponibles en programación de código abierto.

En cualquier caso, considero que en la base de estos movimientos está el hecho de que, a finales de los 90, el “viejo” lenguaje XML y los estándares de «servicios web» para el intercambio automático de información en internet entre aplicaciones (una forma de interfaz M2M) empezaron a modificar radicalmente el panorama. Después del posterior abandono de Microsoft del grupo de empresas tecnológicas que apoyaban el lenguaje Java multiplataforma para desarrollar aplicaciones empresariales en internet, el XML ha quedado como la herramienta más efectiva de programación orientada a datos de entre las consensuadas en el mundo. Frente a otras de este tipo, como SQL, XML tiene la ventaja de ser extensible y autodefinible. Por tanto, es más capaz de salvar las diferencias que caben al interpretar o implementar los estándares de consenso, por naturaleza lentos en su avance.

Termino esta reflexión con la idea de referirme en la siguiente a algunas implicaciones relevantes del actual enfoque adoptado por la mayoría de las grandes empresas suministradoras de sistemas empresariales, así como a su impacto en las «estructuras maestras comunes» de sus aplicaciones.

[Ilustración 1: arquitectura grid promovida por el CERN.]
[Ilustración 2: tomada de la nota sobre ESB, BPM y SOA en el blog La vida en bytes.]

Posted in software | Etiquetado: , , , , | 2 Comments »

Maestros y estructuras

Posted by josempelaez en Viernes, 27 junio 2008

Hace pocos días estuve contrastando opiniones con Luis-tic616 y Rafa en el Diario de un Director de sistemas sobre la interacción entre aplicaciones empresariales. Luis decía:

«Creo que hay que resolver todavía como disponer de estructuras maestras comunes para las transacciones particulares – el caso típico es el de maestro de clientes.»

Para pensar un poco más y tratar de fundamentar las mías he regresado en buena medida al pasado, cuando aún no se hablaba de “aplicativos”. Para el que vaya a leer esta entrada en el blog, aviso de antemano que sólo va a ser la primera parte de mi argumentación.

Enlace entre bloques estructuralesEn 1973, mi padre cambió mi regla de cálculo por una calculadora científica para que ganara agilidad en la resolución de problemas de resistencia de materiales. Gastó unos 4.700€ de hoy (actualizando con el IPC) en una HP45, pero debió de pensar que merecía la pena si yo aprobaba finalmente la materia que amenazaba con retenerme en 2º de carrera. Desarrollé mucha destreza ejecutando algoritmos a mano con la curiosa RPN, y pasé de curso (no sólo gracias a la maquinita, claro).

Pocos meses después, ya en 3º, aprendí a programar procesos de cálculo en Fortran IV en un miniordenador de HP con tarjetas perforadas. Por cierto, recuerdo que, por aquella época, uno de nuestros profesores iba a uno de los famosos cursos de IBM para enterarse de lo que era el time-sharing. El Cobol sólo me sonaba de nombre, y así se quedó poco más o menos. Me dijeron que era para “programas de gestión”, y que nosotros éramos ingenieros. Además de resolver ecuaciones con métodos numéricos, nos adiestrábamos programando juegos, como el clásico del ahorcado, o calculando duraciones de proyecto e identificando caminos críticos en un grafo PERT. La “gestión” era otra cosa, y se aplicaba en la banca, seguros, administración pública….

En la primera mitad de los 80 tuve que utilizar ordenadores IBM en la ingeniería donde trabajaba. Me familiaricé con los lotes (batch processing), el JCL, los ficheros indexados (ISAM) y las bases de datos transaccionales jerárquicas (IMS). El análisis funcional y orgánico de la época me introdujo en los modelos de datos, el distingo entre transaccionales y maestros y en la «arquitectura de información».

De alguna forma reviví las estructuras resistentes y sus «muros maestros». Estas aplicaciones se sustentaban en datos y no en procesos. Los modelos de comportamiento rígido, elástico y plástico resurgieron como agradables recuerdos (me gradué en la especialidad de estructuras). Lo que ahora no veía en este marco era el aislamiento de elementos mediante condiciones de contorno, tan típico de mi querido análisis estructural. En éste, las acciones externas y elementos colindantes se aislaban mediante su representación con campos de fuerzas. Éstas “solicitaban” al elemento resistente, que respondía deformándose (si no se rompía) y reaccionando.

Programando en Fortran descomponíamos los problemas en módulos de flujo que codificábamos en bloques estructurados. También empleábamos muchas funciones y subrutinas, que devolvían resultados (request-response) sin saber cómo estaban programadas aquellas bibliotecas (libraries) de cálculo reutilizables. Era algo que me resultaba familiar.

Ahora ya no programaba, pero en los análisis que hacía —para “lo de la gestión”— echaba de menos los flujogramas que diagramaba antes. En este trabajo lo importante eran los «organigramas de datos», como yo los llamaba. Las relaciones entre elementos del sistema se habían reducido a las de las entidades de información, compuestas por ficheros o tablas de registros que variaban mucho (transacciones) o poco (maestros). Los “cálculos” que había que hacer eran «alta, baja y modificación» y, a todo tirar, teníamos que contar, sumar y dividir para sacar subtotales y medias. El súmmum eran los «totales de totales», también llamados “grandes totales”. Todo aquello, según IBM y Andersen Consulting, por lo menos, recibía el apelativo de Management Information System. ¡Qué curioso y sencillo me resultaba este enfoque, especialmente cuando soy de los que conserva sus viejos y apreciados instrumentos de cálculo (regla deslizante, HP45 y otras tres más, ya programables)!

Me perdí la entrada en la liza comercial de las bases de datos relacionales al cambiarme a la consultoría de dirección y a la gestión de personal. No obstante, recuerdo haber leído cosas sobre las reglas de Codd. Las simplifiqué mentalmente pensando que trataban, básicamente, de aportar flexibilidad, reducción de duplicados y consistencia de datos.

En 1992 escuché hablar por vez primera de la programación orientada a objetos. A mitad de esa década leí sobre el desarrollo basado en componentes: módulos encapsulados, débilmente acoplados y buenas abstracciones. En el “mundo real”, la BD Access de PC se popularizaba reemplazando al DBase III y Clipper en muchas empresas. Los lenguajes de programación 4GL habían hecho furor en las más grandes y pudientes de la mano de los SO Unix, y de la fulgurante expansión comercial de las BD relacionales (Oracle, Ingres, Informix, Sybase…) con sus 4GLs. Aparecieron los entornos RAD con Delphi, PowerBuilder, etc. que fueron cediendo terreno al Visual Basic. Ya en esta década, el auge de la web había catapultado a Java con su plataforma robusta y compleja, se popularizaron los lenguajes dinámicos (scripting) abiertos de internet, entró a competir la arquitectura .NET (un SO y varios lenguajes), y blablabla…

Por hoy lo voy a dejar aquí. Ya está bien de historieta. El próximo día pasaré raudo y veloz sobre flujogramas, organigramas, algoritmos, datos, maestros, profesores, consultores… y llegaré a mi destino, espero. ¿Será la SOA?

[Imagen: Equilibro estructural. Prof. Dr. Dimitris Theodossopoulos de la Universidad de Edimburgo. Ilustra dos sistemas estrucurales de la naturaleza que interactúan mediante un puente. Éste permite los intercambios entre ellos, además de soportarlos.]

Posted in software | Etiquetado: , , , , | 2 Comments »

Rentabilidad del SaaS

Posted by josempelaez en Miércoles, 25 junio 2008

Cotización Salesforce.com 5 añosSiguiendo con el tema del SaaS, y en la misma búsqueda que me llevó a escribir sobre su flexibilidad, encontré una anotación de un jefe de analistas de AMR Research acerca de su rentabilidad. También hizo que me detuviera a pensar un rato, y a escribir esto.

Bruce Richardson, que así se llama, comenta en ella que lleva diez años escuchando que el SaaS es la plataforma del futuro. Sin embargo no recuerda haber leído nada sobre las ganancias de las empresas que lo promueven. Ello me llevó a pensar en lo que declaró Larry Ellison meses atrás, con motivo de la presentación del Business ByDesign de SAP.

Yendo al análisis de Bruce, su punto —los costes de ventas y marketing— es aplicable tanto a los vendedores de SaaS como a los tradicionales, como él señala. Tras exponer sus interesantes datos y hacer un par de consideraciones, concluye:

«My primary point is that margins are lean, thanks primarily to the cost of newcustomer acquisition. »

Aunque contempla luego el caso de Taleo, que tiene un porcentaje de gastos comerciales del 35% frente a un promedio superior al 50%, deduce que debe de ser la excepción que confirma la regla. Y ahí se queda, en espera de lo que le depare el futuro (tanto del SaaS como del viaje a Dubai que estaba a punto de hacer).

Recuerdo haber leído hace años que un ejecutivo de Salesforce.com manifestaba que pensaban que su modelo de software bajo demanda en la web se extendería entre las pymes con poca necesidad de venta tradicional. Añadía que la realidad se había revelado con otro aspecto. Los clientes que se interesaban por su herramienta CRM eran empresas más grandes, y comparaban su solución con la alternativa on premise (Siebel era el líder). Por tanto, en lugar de “despachar” suscripciones en la web, como esperaban, tuvieron que salir a vender puerta a puerta con el estilo que tan bien conocía Marc Benioff de sus antecedentes en Oracle.

¿Será que eso es así y ha de ser siempre así? ¿Estaremos ante un caso como el de Amazon.com, en el que no se hace dinero mientras se sube por la curva de aprendizaje ganando eficiencia y masa crítica?

Hace tiempo que mis referencias del SaaS para empresas se ampliaron desde Salesforce.com, NetSuite, Workday… con 37Signals, Google, AdventNet, Amazon… ¿Emplean éstas el mismo modelo que los proveedores del estudio de Bruce? ¿Se basan fundamentalmente en la comercialización web y el boca-oreja? Creo que la respuesta es clara.

David Heinemeier Hansson ofreció una estupenda “representación” (31′) en la Startup School 08 sobre «The secret to making money online» En ella expone a los futuros emprendedores que, para ser rentables, no es preciso “levantar” dinero de los VCs en rondas sucesivas. Este enfoque se suele considerar imprescindible para hacer grandes inversiones mercadotécnicas con las que obtener sustanciales y rápidos crecimientos en los mercados online (B2C y B2B).

Me resulta curioso que las primeras empresas referidas hayan tenido que capitalizarse mucho, al igual que los inversores dicen que hay que hacer en las orientadas al B2C, pero parece que no sucede lo mismo con las dedicadas al B2B de pymes. ¿Por qué aparece esta singularidad?

Voy a dejar el asunto en este punto, por el momento. Sólo anotaré, como una de las pistas que tengo en mente, lo que conversé con Rafael Gil hace poco sobre la “consumerización” de las TIC empresariales. ¿Serán muchos los que duden de que Google llegue a ser capaz de ofrecer un servicio de software empresarial que sea seguro, disponible, integrable, fiable…? Hay quienes protestan de lo de hoy, pero…

Opino que, poco a poco, los empresarios irán siendo conscientes de que sus empleados también son usuarios fuera de la empresa, y de que lo que emplean dentro no es mejor, ni más seguro, ni más robusto, ni más barato que lo que encuentran en el “mundo salvaje”. Ya hablaremos de las decisiones TIC y de los estatus a que se refiere Marc…

[Ilustración de Yahoo! Finance con la evolución de la cotización de Salesforce.com, que ahora tiene una capitalización bursátil similar a la de Sun Microsystems].

Posted in software | Etiquetado: , , , | Leave a Comment »

Flexibilidad del SaaS

Posted by josempelaez en Lunes, 23 junio 2008

plexus web siteHoy me he llevado una pequeña alegría al toparme con Plexus Systems y su aplicación online para gestión de empresas manufactureras. ¡Por fin encontramos a alguien con quien poder compararnos en el SaaS de operaciones!

En su web ofrecen una explicación ilustrativa sobre las capacidades de su herramienta. He tomado nota para cuando hagamos la nuestra. Me ha parecido un buen ejemplo visual en línea con las presentaciones de Xplane, aunque interactiva.

He llegado a ella al haberme encontrado previamente un artículo en el que su máximo responsable advierte contra el secuestro del término SaaS que hace una buena parte de la industria de IT. No voy a entrar ahora en lo que sostiene sobre las antiguas ofertas de los ASPs, las viejas aplicaciones habilitadas para la web, o el nivel de multi-tenancy requerido para poder ser calificado como un verdadero SaaS. Lo que ha llamado mi atención es una frase donde dice que:

«All customers run off of the same code base. […] Customers can deploy the application very rapidly, since they don’t have the lead time and hassles associated with configuring their local environments.»

¿Qué querrá decir con que los clientes no tienen que lidiar con las dificultades asociadas a las configuraciones locales de su entorno? ¿Se refiere sólo a la plataforma técnica? ¿Incluye también el software?

No estando seguro he buscado más en su web para ver si salía de dudas. Sólo he sido capaz de encontrar algo relacionado en unos puntos de su apartado de beneficios. En ellos dicen:

  • «[…]Fully integrated system
  • Flexible
  • Standard modules for all aspects of manufacturing
  • Special configuration where required[…]»

No es mucho, pero lo de «especial cuando se requiera» me ha dejado pensativo. También me ha sorprendido observar que organizan la funcionalidad de su ERP en términos de «áreas de software», a pesar de decir que son expertos en fabricación.

Por otra parte, en sus áreas, no incluyen nada relativo a los flujos de trabajo que desencadenan las peticiones de servicio, pedidos de clientes, órdenes de compra, etc., aunque sí hablan de programación de la producción y tareas de mantenimiento (orientación interna de optimización de la producción). Tampoco se refieren entre sus características a la posibilidad de configurar de manera estándar diferentes procesos operacionales (fábrica, almacén, taller, etc.) en función de las circunstancias.

Visto lo visto, y a riesgo de equivocarme, he llegado a la conclusión de que parecen modernos en su modelo de oferta informática, pero que deben de ser bastante antiguos en su enfoque de gestión de la empresa industrial.

En su página de portada también dicen que:

«Plexus is the only company in the world to deliver a comprehensive software solution for manufacturers via the software as a service delivery model, speeding technology deployments, lowering costs, and accelerating time to value.»

Además de no estar de acuerdo con la primera parte de su declaración (tenemos clientes que usan el nuestro para prestar a los suyos un servicio compartido y personalizado de gestión de “cajas” y de información), creo que no han profundizado bien en las implicaciones del SaaS.

Opino que éste no se refiere sólo a que todos los clientes comparten el código y estructuras de datos y documentos en una sola instancia, accediendo cada uno a sus datos de forma exclusiva, controlada y segura, obviamente. También debe poder lograrse de manera estándar (con plantillas y configuraciones que no sean “especiales”) que sus procesos operacionales de fabricación, logística y servicios sean específicos y acordes con sus necesidades.

Es decir, los modelos SaaS también deben distinguirse por su nivel de flexibilidad. Hay quienes se refieren sólo a que se pueden emplear unos módulos u otros según la empresa cliente, con pantallas según los usuarios, y con campos según sus necesidades.

Por otro lado, están los que sostenemos que la flexibilidad también ha de referirse, sobre todo, a que cada cliente de la instancia multi-tenant pueda introducir sus propias reglas y parámetros del flujo de proceso. Ello afecta a todas las actividades que median desde el tratamiento de los pedidos a los criterios de costeo y facturación de productos (bienes o servicios).

Todos los vecinos de un edificio en comunidad comparten ciertos servicios (ascensores, tuberías ascendentes y bajantes, piscina y jardín, etc.) y normas de uso de los espacios comunes, pero cada uno reforma y amuebla su casa como quiere, y desarrolla en ella las actividades que le apetece (siempre que no sean molestas, insalubres, peligrosas…, claro).

[Imagen de Plexus]

Posted in software | Etiquetado: , , , , , , | 3 Comments »

La motivación de los talentos

Posted by josempelaez en Viernes, 20 junio 2008

Leyendo una interesante entrada de Un nombre al azar sobre un tema colateral me topo con la frase: 

«Ahora que empresario suena mal y estamos renovando el lenguaje habría que llamarlo emprendedor.»

Por el motivo que sea (si es que ha de haber alguno), se me ocurre pensar en la palabreja start-up, que tan de moda está entre nuestros emprendedores (los de las puntocom y los de la post-burbuja rebautizada como web 2.0).

Ello me transporta a unas recientes reflexiones de Infoman sobre que, en las startups:

«pocos tienen pensado cómo van a: […] Gestionar el talento […]»

A mí, lo de «gestionar el talento» me lleva a otra expresión similar: «motivar a los empleados». A su vez, ésta me recuerda siempre una frase de cuando trabajaba en DEC con mi mentor y amigo Bienve. Un hombre fuera de lo común que, entre otras lecciones, me decía sabiamente algo así como: «a los empleados no hay que motivarlos, sino no desmotivarlos, porque cuando entran en la empresa vienen muy motivados».

Otra inquietud que nos hacía discurrir era el “agravio corporativo”, como decían quienes, habiendo escuchado campanas sin saber dónde, se referían así a las “comparaciones odiosas” entre los salarios de los departamentos. Esto podría llevarnos nuevamente al comienzo de esta entrada, pero no me voy a dejar. Bueno, lo cierto es que, por lo que fuese, Bienve y yo éramos considerados bastante heterodoxos en relación con las denominadas políticas de empleo y de compensación [allí eran employment y compensation & benefits].

Y lo de la heterodoxia me ha conducido a una entrevista al profesor de filosofía de la UCM Carlos Fernández Liria publicada hace poco. En ella, a propósito de la materia de «educación para la ciudadanía», con la que discrepa profundamente por orientarse a valores en lugar de a contenidos, manifestaba que:

«La tendencia educativa es a deteriorar el contenido y apostar por una gestión asistencial del material humano. Se asocia educación con psicopedagogía y orientación social. Esto es una estafa, una mentira que oculta un problema.»

Y no sigo porque lo que me ha venido ahora es lo de la “desaceleración acelerada” que tenemos en España y bueno, como que no es plan. Si me desvío ahora por esta senda voy a desbarrar en demasía.

Recogiendo velas, y volviendo a lo que iba, ¿para qué diantres se necesita gestionar el talento de quien es accionista en un cierto porcentaje por asumirse que tiene algo relevante para la empresa en cuestión? ¿No debería ocuparse el más experto en alinear los objetivos e instruir a los noveles talentosos en los contenidos necesarios que aún ignoran? ¿Cómo van a prevenir su desánimo si los “gestionan” siguiendo algún manual? ¿Por qué debemos emplear vocablos nuevos para referirnos a situaciones, conocimientos, habilidades, etcétera que los psicólogos evolutivos son capaces de rastrear hasta tiempos prácticamente ignotos?

Hablamos de start-ups, emprendedores, emprendizaje, emprendimiento, emprendiduría… y, mientras tanto, los sindicatos siguen la pista del dinero aplicando de manera sui géneris el principio de los vasos comunicantes. ¡Sí que hay que tener talento para que los gestores que pregonan la innovación acepten que los distingos salariales se igualen por arriba!, como  «Un nombre al azar» nos recuerda.

Parece que, como los empresarios deben de ser unos explotadores, los políticos han de estar al quite y aplicarse al diálogo social, que para eso les votan los ciudadanos bien educados… El problema es que, en una economía global, el empleo que sigue a las inversiones se rige por otros  principios, creo yo.

[Ilustración de Iván Solbes, Público. Está en otra inspiradora entrada de Fdez. Liria sobre cómo unos estudiantes con talento se han opuesto a la gestión mercantilista del «Proceso de Bolonia» que han hecho la CRUE y ANECA en contra de los fundamentos de la universidad.]

Posted in gestión | Etiquetado: , , , , , | 1 Comment »