Datos del sector de las Artes Gráficas
Es interesante conocer datos del sector en el que nos (me) movemos. Además, algunos son significativos. Sorprende que estos datos no se encuentran fácilmente. Los que publico aquí son el resultado del Informe Económico de Graphispag 2007, feria que se celebra cada cuatro años en Barcelona.
| DATOS DEL SECTOR DE LAS ARTES GRÁFICAS | ||||
|---|---|---|---|---|
| Datos monetarios en millones de € | 2005 | 2004 | 2003 | 1998 |
| Número de empresas | 15.010 | 15.549 | 14.193 | 14.996 |
| Empleo (número de ocupados) | 183.884 | 179.574 | 177.983 | 167.864 |
| Producción | 24.824 | 23.284 | 22.411 | 17.694 |
| Inversión material | 1.150,7 | 1.105 | 1.024 | 1.020 |
| Exportación de productos | 1.928 | 1.977 | 1.954 | - |
A destacar.
- En 2005, la población activa según el INE se situaba en casi 21 millones de personas. Por lo que el sector de las artes gráficas emplea al 0,87% de la población activa.
- La exportación de productos desciende ligeramente desde 2003 a 2005. Esta exportación hace referencia principalmente a prensa, y puede deberse a diversos motivos:
- Pérdida de importancia del papel impreso en prensa en el exterior
- Competencia de países emergentes en grandes tiradas (Brasil, China...)
- La producción ha experimentado un aumento lineal desde el 98 al 2005. No ha existido burbuja en este sector.
- Es un sector ya muy maduro, donde el número de empresas crece muy poco. De hecho disminuye en 2005 y se mantiene en los niveles de 1998. Es muy posible que también sea síntoma de un sector saturado en oferta.
He encontrado datos fiables de 2008 (concretamente de su segundo trimestre), en la web de Alabrent, donde se obtienen algunos datos destacables:
- El sector de las artes gráficas emplea a 180.000 personas (ha registrado el crecimiento ecónomico español de los tres últimos años). Se ha mantenido la tasa de empleo de 2005.
- El sector de las artes gráficas representa el 1% del PIB español.
En próximas entradas compararé estos valores con los de otros sectores...
Estos datos han sido obtenidos de la web del Ministerio de Industria, Turismo y Comercio.
Foros de artes gráficas en Internet
Vengo del mundo de la informática y los sistemas de información. La cantidad de foros públicos donde usuarios de todo el mundo comparten impresiones, opiniones o comentarios es enorme por cualquier tecnología, tendencia o tipo de sistema.
En las artes gráficas, al contrario, es muy pobre. Básicamente he encontrado sólo tres foros con un mínimo de movimiento en cuanto a número de mensajes o usuarios. Dos en español y sólo uno en inglés de consideración. Desde luego, o no son fáciles de encontrar (lo dudo con buscadores como Google) o casi no existen.Aquí una relación de los encontrados:
- Colour Printing Forum. Foro en Inglés, con una participación que considero pobre para un foro internacional.
- Área temática de Artes Gráficas de la Comunidad Macuarium. En español, principalmente para diseñadores y algunos impresores (y los menos empresarios...). Es curioso, es un subárea dentro de un foro dedicado íntegramente al mundo Mac (Apple y Macintosh...)
- Foro de eMagister de Artes Gráficas. En español, también. Utilizado muchísimo por trabajadores del sector para hacer preguntas sobre su situación contractual o laboral, aunque también se encuentran las opiniones de algunos empresarios.
Publicaciones sobre artes gráficas sí que existen varias en español (otro día las comentaré), pero con información demasiado corporativa proporcionado por los diferentes proveedores del sector y casos reales (con mucha componente de marketing) de empresas españolas.
¿Será que los empresarios de artes gráficas no usan mucho las nuevas tecnologías? ¿Será que en general son muy reservados y reacios a exponer sus opiniones y experiencias en foros públicos? Un poco de ambas cosas...
La gran ironía del capitalismo… mamá banco
Hay cierto componente de la crisis en la que estamos que fastidia. Todos hemos pasado por la "humillación" de ir a un banco. Sí, digo humillación, porque salvo que tengas millones de euros en el banco, el trato que generalmente recibes es de cierta prepotencia y de abuso de fuerza por tu necesidad. Simplemente porque tu necesidad es la de dinero. Y los bancos, VENDEN dinero.
Si necesitáramos un coche, no nos sentiríamos tan inferiores cuando nos acercamos a un concesionario. Y ni mucho menos existe prepotencia en un concesionario. Cuando pides una hipoteca, o un préstamo, tienes que llevar tus nóminas, avales, e incluso, es necesario hasta enseñarle tu ropa interior (si es Calvin Klein, saben que tienes dinero y es más probable que te presten algo). Sin embargo, si son ellos, los bancos, quienes deben invertir en fondos mundiales (sistema globalizado), no hay exigencia de ningún tipo de garantías, ni siquiera, de información sobre dónde se está metiendo dinero (¿o alguien metería dinero en hipotecas concedidas a gente sin dinero ni trabajo? ¿Existiría esta crisis si a las operaciones entre bancos se les exigiera la misma transparencia que en sus operaciones con su cliente?).
Es curioso. A sus clientes, toda la exigencia del mundo. A sus proveedores (otros bancos que le venden dinero a ellos), ninguna. El mundo al revés.
Por supuesto, esta es una versión simplista de la realidad. Los bancos son el motor y el alma del sistema capitalista... Debemos aceptar que los bancos, son un ente de necesaria existencia, al igual que la administración pública o el gobierno. Eso sí, con decisiones igualmente incomprensibles según el sentido común. Pero jode...
Hace 40 años…
Tendemos a concentrar períodos de tiempo en momentos concretos. Así podemos evocarlos fácilmente pasados ciertos años.
Hace 40 años, en 1968, mi padre, Antonio Pinelo, firmó un documento en el que certificaba la compra de una Minerva, modelo Hispania. Una máquina tipográfica. Era el resultado de un proceso de valoración, de pensar en el futuro, de querer implantarse por separado. Una historia de una una persona que empezó a trabajar muy joven, con 12 años, en una época en la que las cosas eran sólo fáciles para unos pocos. Nació ahí una empresa con sello propio. El que a día de hoy lo impregna aún todo. El de la personalidad, perseverancia y tesón de su fundador.
Son muchas las sensaciones que pasan por la mente de todos hoy día. Felicidades (como el cumpleaños de un niño), agradecimiento (por contribuir al crecimiento personal y profesional de más de una veintena de personas a lo largo de estos años) e ilusión por un futuro, que esperamos siga la misma línea.
Otro ERP se une a la liza… OpenERP
Permitidme que copie una entrada de Jordi Esteve en barrapunto, que me ha hecho plantearme el estudio de OpenERP.
Empieza aquí....
OpenERP . Hace 1 año escaso el repositorio SVN del desarrollo de OpenERP solo era accesible por sus partners que pagaban una cuota "elevada" (Abanq actualmente no ofrece ni esto). Hace 6 meses el repositorio SVN fue abierto a todo el mundo y hace 3 meses todo el desarrollo se ha migrado a launchpad, plataforma de desarrollo de software libre creada por Canonical. Aquí se
gestionan diferentes ramas con bazaar (similar a svn), bugs, translations (en este momento Español está casi al 100% y catalán al 80-90%), ...
En OpenERP Commiters casi 60 personas, muchas sin relación con la empresa madre, estamos desarrollando módulos que posteriormente algunos son traspasados a la versión oficial por el OpenERP Quality Team.También hace pocas semanas se ha creado el OpenERP Spanish Localization Project a partir del código desarrollado en el svn de google-code. Aquí se alojan los módulos de localización como la validación cifs, cuentas bancarias, planes contables, remesas de recibos 19 y 58, importación extractos bancarios 43, ...
La tecnología que usa también es muy importante: framework de desarrollo en python y ficheros XML, modular (más de 300 módulos), informes diseñados desde OpenOffice, clientes de escritorio para windows, mac y linux versión Qt y versión Gtk, cliente-sevidor web (si, la misma aplicación es a la vez una aplicación de escritorio y una aplicación web), conectores para diferentes tiendas on-line: os-commerce, virtuemart, magento, ...
Termina aquí...
A ver qué tal es OpenERP...
Detalles que no me van gustando…
Estoy ya enfrascado en adaptar tanto AbanQ como OpenBravo a mis necesidades de almacenaje de materias primas para el proceso productivo (que en el caso de las artes gráficas, es papel, tintas o barnices, y determinados consumibles para maquinaria, que aunque no son materias primas, sí inciden en la producción, como mantillas, solución de mojado, etc).
La primera en la frente con AbanQ. Una de las premisas básicas de los sistemas ERPs es la de la no duplicidad de la información en el modelo de datos. Para ello, por ejemplo, se tiene un maestro de proveedores (que puede ser una tabla donde se almacenan todos los proveedores). Y cuando debemos hacer una referencia a un proveedor desde cualquier otra entidad (por ejemplo, un pedido a proveedor o un albarán de proveedor), incluimos en esta otra tabla una columna o campo que almacena un dato, el identificador único de la tabla maestra de proveedores. De esta forma, tenemos una relación establecida y los datos no duplicados.
Veo que el modelo de datos de los módulos oficiales de AbanQ en su versión 2.2, duplican la información. Tenemos una tabla de proveedores, donde existen campos o columnas como el nombre o el CIF del mismo. Sin embargo, veo, con desagrado, que en la tabla de pedidos a proveedores, encuentro campos que duplican información: veo en esa tabla, el id del proveedor (lógico), pero también el nombre del mismo o su cif. ¿Para qué quiero tener repetida la información del proveedor en la tabla de pedidos de proveedores? Pero ya no es sólo la repetición. Imaginemos que modificamos el nombre del proveedor. Estamos obligando al sistema a que extienda esa modificación del nombre a todos las tablas que también almacenan el nombre del proveedor.
Este es un error de diseño grave del modelo relacional. Voy a preguntarlo en los foros, a ver qué respuesta obtengo, porque también existe la posibilidad, de que esté interpretando mal el modelo de datos.
Este error no ocurre en OpenBravo, donde de hecho existe un maestro genérico, "Terceros" que almacena todas las entidades ajenas a la empresa pero que influyen en la misma: Clientes, Proveedores, Acreedores, Empleados, etc. OpenBravo y su modelo de datos, respeta ese diseño básico del modelo relacional de bases de datos.
Actualizado a 21 de Noviembre de 2008. Me ha contestado Federico Albujer en los foros de AbanQ a esta inquietud en el modelo. Reproduzco aquí su respuesta, ya que me ha parecido muy interesante:
Donde dije digo, digo Diego…
Hace unos días, publiqué que descartaba AbanQ como posible ERP que adaptar a mi empresa... Sin embargo, a día de hoy tengo que rectificar. Es cierto que AbanQ en cuanto a funcionalidad es menor a OpenBravo u OpenXpertya. Pero, la construcción de OpenBravo es mucho más compleja, aparte de que existe bastante polémica alrededor de la aplicación (como puede verse en algunos hilos de barrapunto, aquí, sobre su licencia y sus formas como empresa, o aquí, entrada de una persona que tenía un blog dedicado en exclusiva a OpenBravo y que tuvo que cerrar).
Lo que sí está claro es que OpenBravo es un fork de Adempiere o Coimpiere, y en el que no acabo de ver (que no significa que no exista) la programación modular que sí tiene AbanQ. Es por ello, y aunque AbanQ esté por debajo en funcionalidad que voy a volver a contemplarlo. Por su modularidad.
Todo lo que encuentre que falte, lo iré implementando yo, y poniendo a disposición de la comunidad. Al fin y al cabo, AbanQ está desarrollado en Qt (que conozco con soltura)...
Manejo de clientes esporádicos
Hay algunos problemas, que se presentan en la gestión del día a día que pueden parecer sin importancia, pero que a la larga pueden dar lugar a una cantidad de problemas importante. Uno es la gestión informática de clientes esporádicos. Si tengo un cliente que sé que va a venir un sólo día y quizás no aparezca nunca, ¿realmente interesa crearle una ficha de cliente en el sistema? ¿Realmente merece la pena esa inversión de tiempo y de distorsión de información en el sistema?
El día que mi padre, fundador de la empresa, me planteó este problema, pensé que lo mejor era dar de alta a todos los clientes con ficha propia en el sistema, fueran o no esporádicos. Sin embargo, esta aproximación tiene problemas importantes.
- La agenda de clientes puede llegar a hacerse inmanejable, con cientos de registros de clientes que nunca se volverán a utilizar.
- Se tendrán además, registros inconsistentes. Inevitablemente todos tendemos a no incorporar toda la información de un cliente esporádico... total, si no va a volver a venir, ¿para qué complicarnos introduciendo toda la información?
Por otro lado, almacenar todos los clientes tiene otra serie de ventajas
- Un funcionamiento lineal del sistema informático (para crear una factura siempre debe existir clientes creados)
- Una agenda de clientes potenciales (ya que fueron clientes alguna vez nuestro) que nos puede permitir rescatarlos en el futuro.
En nuestro caso optamos por una solución intermedia. Nuestra agenda de clientes presenta una estructura relacional 1 a muchos, con una tabla que gestiona la información del cliente, y otra las posibles direcciones (o sucursales) de ese cliente. Para los clientes esporádicos, introduje una modificación en el programa, que permitiera la creación de un único cliente mostrador, pero con múltiples direcciones para clientes esporádicos directamente desde facturas, albaranes o presupuestos. La solución es efectiva.
Al plantear la mudanza a OpenBravo u OpenXpertya o cualquier otro ERP, esta opción deja de estar disponible para nosotros. A no ser que la implemente... me lo estoy pensando.
Continuando con los ERPs…
He estado estos días probando OpenXpertya y OpenBravo. La verdad, es que se nota el núcleo común de ambas, Compiere. La filosofía de trabajo en ambas es igual (la forma de configurar las entidades o clients, por ejemplo es igual en ambas, el workflow, o los sistemas de navegación). Hay diferencias. Presento algunas.
Qué me gusta de OpenXpertya
- Su entorno de escritorio en Java. OpenBravo sólo tiene entorno web, y el trabajo se hace algo más incómodo. OpenXpertya ofrece tanto la interfaz web, como la interfaz Java, lo que se agradece. Hay detalles que pulir, pero si me decanto por esta herramienta, iré corrigiendo los bugs que encuentre, y subiéndolo a OpenXpertya (si me dan permiso).
- Integrado con herramientas en OpenOffice.
- Muy enfocado al mercado español.
Qué no me gusta de OpenXpertya
- La comunidad que hay detŕas, debe ser escasa. Sus foros tienen muy poca actividad (escasamente 1 o 2 mensajes al día, algunos hace meses que no se actualizan). Su wiki es bastante pobre aún.
- La propia respuesta comercial no parece fuerte. No me han respondido aún a peticiones para un soporte comercial.
- Carece de un módulo de producción, como sí tiene OpenBravo.
Qué me gusta de OpenBravo
- Su módulo de producción. Me parece un buen punto de partida para implantar el ERP en centros productivos.
- Su interfaz web está mucho más cuidada que la de OpenXpertya... sin embargo no tiene entorno de escritorio, lo que para mí es un handicap.
- Su comunidad parece más viva. Su wiki es bastante más completo que el de OpenXpertya y ayuda bastante más. Sus foros, presentan algo más de actividad.
- No necesitas JBoss para hacerlo funcionar. ¿Realmente usa OpenXpertya EJB o similares para necesitar un servidor de aplicaciones?
Qué no me gusta de OpenBravo
- No tiene entorno de escritorio.
- No parece tan enfocado al mercado español (aunque es desarrollado por una empresa española).
- No tiene (o no lo he encontrado) integración con OpenOffice.
Seguiremos comentando...
Elección de un ERP en artes gráficas
Existen varios ERPs de conocido prestigio en el mercado español, como por ejemplo Inextrama (basado en SAP), Optimus (creo que realizado en MySQL y sobre python...), Palmart... Creo que cualquier industria gráfica de mediano tamaño necesita de un ERP con el que gestionar su operativa diaria.
Curiosamente, nosotros no tenemos ningún ERP tal cual implementado, y sí una serie de herramientas desarrolladas por mí en Qt para presupuestar, facturar...
Necesitamos uno. Y como los de pago no me acaban de convencer (demos demasiado... orientadas, sin posibilidad de utilizarlo y saber si realmente puede adaptarse a nuestras necesidades) y dado que uno de los módulos más complejos (el de presupuesto) lo tengo realizado, hemos decidido implementar un ERP opensource al que acoplar nuestros módulos existentes.
Entre los ERP opensource existentes, estoy valorando tres.
De ellos AbanQ es el que me parece menos evolucionado. Es un desarrollo realizado en C++ con las librerías Qt, y con soporte de varias bases de datos. Sin embargo, me parece que sigue un desarrollo demasiado lineal (es como si me faltara la interrelación entre todas las tablas) y que, aunque muy modular y ampliable, está aún por detrás en funcionalidad.
OpenBravo y OpenXpertya provienen de una misma base, Compiere, proyecto ERP también en software libre, y que ha tenido un fork, Adempiere. Son proyectos robustos, realizados en Java, "relativamente" modulares, y ampliables. OpenXpertya está enfocado casi exclusivamente frente al mercado hispanoamericano (España y Latinoamérica), a diferencia de OpenBravo, lo que lo sitúa en una posición de ventaja frente a esta. OpenXpertya cuenta además con un cliente pesado Java (de escritorio) frente a OpenBravo que sólo tiene interfaz web. Esto es una ventaja añadida para OpenXpertya. Sin embargo, la documentación alrededor de OpenBravo parece más extensa (OpenXpertya tiene un manual de pago de la versión 1.9 y va por la 2.2...), y su comunidad parece mayor que la de OpenXpertya. Estos son factores muy importantes.
Sigo analizando y comentando...
Categorías
- Artes Gráficas (26)
- ERP Open Source (20)
- General (26)
- Librerías Qt (24)
- Mundo empresarial (21)
- Programación (13)
- Uncategorized (1)
Mis blogs favoritos
Programación
Mi empresa
Entradas anteriores
- diciembre 2010 (1)
- octubre 2010 (1)
- abril 2010 (1)
- marzo 2010 (2)
- febrero 2010 (1)
- diciembre 2009 (5)
- noviembre 2009 (3)
- julio 2009 (1)
- junio 2009 (2)
- mayo 2009 (3)
- abril 2009 (4)
- marzo 2009 (12)
- febrero 2009 (2)
- enero 2009 (2)
- diciembre 2008 (6)
- noviembre 2008 (10)
- octubre 2008 (1)
- septiembre 2008 (6)
- agosto 2008 (5)
- julio 2008 (12)