Blog

No llegaremos nunca, porque llegar es detenerse, estaremos siempre en movimiento, porque siempre habrá ideales no alcanzados, hechos a crear, ideas a transformar en realidades.
                                                                                                     Dr. Carlos Fosalba

Todo sistema ERP debe ser localizado para cada país (e incluso para cada estado de un país con estructura federal). En la localización hay que considerar las leyes, decretos y reglamentaciones tributarios incluyendo la Seguridad Social que sean aplicables a todos los sectores de actividad, así como otros sistemas de uso generalizado en el territorio como ser plataformas de pago, consulta de morosidad, facturación electrónica, etc. A su vez, para cada vertical o industria o sector, pueden existir normas legales y reglamentarias que obliguen a hacer una sub localización específica.

El gobierno en el sentido más amplio (central o federal, estadual, municipal, entes autónomos o autárquicos, empresas de servicios públicos de derecho privado, etc.) es un importantísimo sector de actividad que tiene normas, sistemas, procedimientos, usos y costumbres diferentes (parcialmente) al resto de la economía. En tal sentido podemos destacar la contabilidad presupuestaria y el control del gasto, el registro central de proveedores (RUPE), la agencia de compras estatales (ACCE), el SIIF (Sistema Integrado de Información Financiera), etc. Para este sector de actividad gubernamental operan los sistemas GRP, sector sobre el que nos referiremos en el resto de este post.
A su vez cada organismo estatal tendrá sus propias brechas o adaptaciones (Gaps o customizaciones) de acuerdo a las particularidades de sus procesos propios, y de la regulación. Acabamos de describir una jerarquía de localizaciones de un GRP: país, (quizás estado, departamento), gobierno, y organismo estatal.
Un digresión técnica pero relevante: Éste sistema jerárquico de localizaciones y adaptaciones se simplifica y potencia si sigue los lineamientos de la programación orientada a objetos (POO) donde a efectos de este análisis, es relevante la propiedad de herencia o sea que los objetos de una clase sean creados a partir de otras clases ya existentes, obteniendo características (atributos y comportamientos) similares a los ya existentes en una clase superior.

Vamos a introducir una variable más: la propiedad intelectual y los derechos de distribución del software:

 1. Si los derechos de autor son propiedad de una empresa, ella será quien ejerce la gobernanza relativa a la versión del software. Normalmente el propietario:

    • cede una licencia de uso por única vez o en forma periódica a cada       organismo usuario,
• cobra un cargo periódico por mantenimiento y soporte,
• determina el contenido de las versiones, su periodicidad y plazo de vigencia (plazo durante el cual la versión tendrá servicios de soporte),
• define la dirección estratégica del producto,
• etc.
Cuando la propiedad intelectual del software es de una empresa, es usual que cada organismo estatal decidirá cuando realizar la actualización (upgrade de versión) del software y qué integraciones y customizaciones requiere.
2. Pero cuando es software de código libre (en inglés Open Source), las decisiones de actualización y customización son más complejas pues no hay un único interlocutor como el propietario del software o, aunque lo haya, no se ocupa de los distintos niveles de localización y customización; o sea, no se responsabiliza por el sistema jerárquico de localizaciones y adaptaciones.
En este caso surge la conveniencia de establecer un Comité de Gobernanza de esta temática de modo que cada organismo estatal no reinvente la rueda o sea realice nuevamente localizaciones o customizaciones ya realizadas. Para obtener economías de escala, mediante la homogenización de versiones, localizaciones y customizaciones, es muy importante mantener la coordinación entre organismos respecto a distintos niveles o versiones del software, juzgar sus funcionalidades y capacidades así como determinar sus integraciones con otros sistemas (estatales). Precisamente las integraciones con otros sistemas (estatales) puede ser motivo de potenciales conflictos de competencia entre distintos organismos que deberán ser resueltos de la forma usual, más allá que en este caso se trata de procesos automatizados.
De no establecerse un Comité de Gobernanza, el mercado (o sea el conjunto de usuarios del GRP y la comunidad de implementadotes y desarrolladores de software) será quien regule la gobernanza del GRP con un funcionamiento más impredecible y con probablemente menor eficiencia. Esto ha ocurrido en relación a varias componentes / productos de código libre, pero generalmente de menor complejidad o alcance que un GRP.

El Comité de Gobernanza del GRP tiene que:

• recomendar cuál es la versión a ser instalada en los organismos que comienzan a usar el software, o, si ya lo usaran, la versión a la cual evolucionar (upgrade).
• Definir qué localizaciones dentro de la jerarquía, cada organismo debe utilizar, pero con flexibilidad como para acompasar distintos ritmos de implantación del GRP de acuerdo al nivel de recursos que pueden disponibilizar, a las necesidades y culturas diversas de los organismos usuarios del GRP, y al grado de autonomía de cada organismo.
• Idem para customizaciones que apliquen a un conjunto de organismos.
• El conjunto de los 2 puntos anteriores determinará el plan de liberación (“nacimiento”) y pérdida de soporte (“muerte”) de localizaciones y customizaciones.
• Recabar necesidades de los diferentes organismos e informar a los mismos sobre modificaciones, mejoras e incorporaciones de nuevas funcionalidades y capacidades.
• Definir y controlar las integraciones del GRP con otros sistemas.
• Planificar las actividades de capacitación para el conjunto de los usuarios estatales del GRP.
• Definir criterios de sustentación y continuidad operativa.
• Prever o planificar el financiamiento (presupuestal) para solventar estas actividades (puede utilizar recursos ya disponibles en varios organismos).
• Identificar, analizar y mitigar el riesgo asociado a cada nueva mejora o agregado al GRP.
• Definir qué funcionalidades recomienda implantar a cada organismo en función de la complejidad y sofisticación de la funcionalidad y su relación con el grado de experiencia y madurez de los usuarios del organismo (fortaleza de la contra parte).
• Definir la dirección estratégica del GRP teniendo presente que la estrategia debe considerar tanto a productores como a consumidores del GRP; o sea, tanto la comunidad o empresas desarrolladoras e implementadoras, como los organismos usuarios.
• Promover actividades con los usuarios.

Alfredo Halm