Una evaluación independiente del proyecto antes de firmar: qué se integrará con el sistema financiero-contable, cuánto cuesta realmente a cinco años y cómo comparar dos ofertas con criterios estandarizados. Para empresas de calefacción urbana, servicios de aguas, transporte urbano y sociedades portuarias.
Una empresa municipal o portuaria suele contar con su propio departamento de TI y un presupuesto de inversión, pero las decisiones sobre el rumbo de la digitalización se toman a partir de una única recomendación, sin una verificación externa del riesgo, el coste y las alternativas.
Su empresa no es una administración pública. Una sociedad mercantil funciona con una lógica distinta a la de un organismo público: otro horizonte de decisión, otra forma de justificar las decisiones, otra presión por los resultados. Trabajamos en su idioma —riesgo, coste, continuidad operativa—, no en el de la administración.
La facturación electrónica estructurada obligatoria a través de KSeF (el sistema nacional polaco de facturación electrónica) exige integrarse con los sistemas financiero-contables existentes, no solo comprar un módulo nuevo.
El inventario aporta: una matriz de integración con el sistema financiero-contable y la lista de sistemas que deben intercambiar datos con él.
Integrar un sistema nuevo con el sistema financiero-contable existente es el foco de conflicto más habitual: la pregunta es «¿se puede conectar?», no «¿hay que sustituirlo todo?».
El inventario aporta: el requisito de integración recogido en las especificaciones desde el primer día, no añadido mediante una modificación del contrato tras la firma.
Cada nuevo módulo o se integra en lo que ya tiene, o se convierte en otra isla de aplicaciones por la que la empresa paga dos veces.
El inventario aporta: las categorías A/B/C/D y el orden de las implantaciones.
Muchas empresas de servicios públicos, sobre todo de calefacción urbana, abastecimiento de agua y transporte, entran en el ámbito de la ley polaca reformada sobre el sistema nacional de ciberseguridad (KSC), aunque estén constituidas como sociedades mercantiles.
El inventario aporta: un registro de sistemas y un registro de riesgos.
Un ERP grande e integrado parece una opción segura, pero puede convertirse en una gran dependencia de un único proveedor, sin agilidad ni margen para tecnologías más nuevas. No hay una única respuesta correcta: depende del modelo de negocio y del tamaño de la empresa.
El inventario aporta: qué se queda en el ERP y qué conviene separar como sistema independiente y bien integrado.
El responsable de TI detecta la necesidad, pero no tiene autoridad sobre los jefes de otros departamentos para obtener su colaboración: falta capacidad de influencia, no conocimiento.
El inventario aporta: un mandato de la dirección para que un asesor externo recopile lo que necesita el departamento de TI.
Sin una matriz de comparación común se comparan cosas que no son comparables, y gana la mejor presentación, no la mejor oferta.
El inventario aporta: criterios de comparación acordados antes de las reuniones con los proveedores, no durante ellas.
Antes de que la empresa compre otro módulo, pregunto para qué y qué se considerará un éxito. A menudo resulta que detrás de la petición de un sistema hay un proceso que primero hay que ordenar, y la herramienta llega solo en un segundo paso.
La solicitud«Necesitamos un sistema de circuito de facturas para KSeF».
Una página para el director general y la jefa de contabilidad, una presentación para la reunión del consejo de administración y un conjunto completo de documentos para negociar con los proveedores.
Esquema preliminar. Sesión de 60 a 90 minutos incluida en el precio.
| Su plan | Lo que recibe la dirección | Qué riesgo cubre |
|---|---|---|
| Circuito de facturas para KSeF | Una matriz de integración con el sistema financiero-contable, requisitos para las especificaciones, una opción de integración y otra de sistema nuevo con el coste a 5 años. | Otra isla de aplicaciones junto al sistema financiero-contable, modificaciones del contrato para pagar la integración, doble introducción de datos. |
| Integración con el sistema financiero-contable y el ERP | El requisito de integración recogido en las especificaciones desde el primer día, preguntas para los proveedores. | Descubrir tras la firma que «no se puede conectar» y tener que sustituir un sistema que nadie quería sustituir. |
| Expediente digital de personal y nuevos módulos | Categorías A/B/C/D, orden de las implantaciones, plan de gestión del cambio. | Resistencia del equipo desde el inicio y módulos que no se comunican entre sí. |
| Consejo de vigilancia y propietario | Una recomendación en una página, ofertas comparadas con criterios estandarizados, coste total a 5 años. | Una decisión tomada «por la presentación» y preguntas sobre su fundamento a posteriori. |
En función del número de sistemas y departamentos. Confirmo el precio exacto tras una conversación de 30 minutos sobre el tamaño de su empresa.
Decide sobre el proyecto de TI a partir de la recomendación de su propio departamento, y necesita una segunda opinión independiente antes de firmar, no a posteriori.
Recibe: una recomendación en una página y dos opciones de decisión con su coste a 5 años, listas para presentar al consejo de vigilancia.
Resultado: una decisión que puede defender ante el consejo de vigilancia.
Responde de la integración de los nuevos sistemas con el sistema financiero-contable existente, que suele ser el primer y más duro punto de fricción de cualquier proyecto.
Recibe: una matriz de integración con el sistema financiero-contable y requisitos que pueden exigirse al proveedor por contrato.
Resultado: costes previsibles e integración sin modificaciones del contrato.
Un aliado cuando una evaluación independiente refuerza su recomendación con cifras y argumentos de gestión, no un competidor que viene a ocupar su lugar.
Recibe: un registro de sistemas, una metodología repetible y argumentos de gestión para respaldar su propia recomendación.
Resultado: la confirmación independiente de su propia recomendación.
Este mismo modelo de colaboración dio buenos resultados en la digitalización de una terminal de contenedores: una voz externa e independiente en la mesa de la dirección, junto a la competencia del propio departamento de TI de la empresa, no en su lugar.
Un registro de sistemas, integraciones y dependencias, con especial atención al sistema financiero-contable y sus conexiones. Clasificación A/B/C/D y mapa de riesgos. Un resumen de una página para la dirección.
Antes de que la dirección apruebe la recomendación del departamento de TI: una segunda opinión sobre el riesgo, el coste total y las alternativas. Señalo dónde otras empresas en una situación similar pagaron de más por no prever la integración, la migración de datos o la resistencia del equipo. Cuando el director general tiene una idea pero no tiempo para desarrollarla por escrito, basta una conversación de 15 a 20 minutos para que, en unos 2 días, vuelva con un concepto listo para su valoración.
Una matriz de comparación de dos (o más) ofertas con criterios comunes, preguntas para los proveedores y asistencia a las reuniones en representación de la dirección, para que la decisión que se somete al director general se base en datos comparables y no en la capacidad de persuasión de una presentación.
Asistencia a reuniones con proveedores, valoración de nuevos proyectos en paralelo a la recomendación de su departamento de TI y una visión actualizada de dónde empresas similares han pagado de más por decisiones sobre la nube, las API o la automatización.
El departamento jurídico de esa misma organización dispone hoy de un archivo electrónico de procedimientos de contratación, un circuito de facturas con OCR, integración con KSeF y un módulo de asistencia jurídica, desarrollados como proyectos sucesivos, cada uno apoyado en el anterior, con el mismo mecanismo: la dirección formula su intención y Krogis la convierte en acción.
«El mismo modo de trabajar que en la digitalización de la terminal de contenedores: una voz independiente para la dirección junto a la competencia del propio departamento de TI de la empresa, no en su lugar».
Un sistema multilingüe de gestión de contrapartes sobre una plataforma de procesos: registro, consultas, ofertas y reclamaciones, que sigue en uso hoy. Identificación de objetivos, análisis de requisitos y elaboración del concepto de un sistema de gestión de relaciones con las partes interesadas. Experiencia en la digitalización de un gran operador de infraestructuras.
Diseño, implantación y puesta en marcha de una plataforma de trabajo colaborativo y gestión de procesos de negocio que abarca, entre otros, un archivo electrónico de procedimientos de contratación, un circuito electrónico de justificantes de gasto, expedientes digitales de personal, gestión de la correspondencia y asistencia jurídica.
Temas recurrentes y anonimizados de conversaciones sobre digitalización, no citas de ninguna empresa concreta.
«Antes de seguir adelante, necesito saber si esto se va a poder conectar siquiera con nuestro sistema financiero-contable; todo lo demás es secundario».
«Siempre presentamos a la dirección dos ofertas en paralelo; necesitamos a alguien que nos ayude a compararlas de forma justa, no solo a elegir la presentación más vistosa».
«Aunque el proceso esté automatizado, quiero tener una posibilidad real de decidir manualmente cuando lo considere necesario».
«No queremos que nos traten como a un organismo público: somos una empresa y ponderamos el riesgo y los resultados de forma distinta a como lo hace la administración».
En la mayoría de los casos puede hacerse mediante una API o una integración específica, siempre que el requisito de integración se recoja en las especificaciones desde el primer día y no se añada mediante una modificación tras la firma del contrato. Es uno de los puntos de fricción más habituales en los proyectos de TI de las empresas municipales, y uno de los más fáciles de resolver con antelación.
Muchas empresas de servicios públicos, sobre todo de calefacción urbana, abastecimiento de agua y transporte, entran en el ámbito de la ley polaca reformada sobre el sistema nacional de ciberseguridad (KSC, NIS 2), aunque operen como sociedades mercantiles y no como administraciones públicas. Conviene comprobarlo caso por caso, ya que la inclusión depende de la escala y del tipo de actividad.
Hace falta una matriz de criterios común —funcionalidad, arquitectura y apertura, seguridad y cumplimiento normativo, tecnología y proveedor, coste total— acordada antes de las reuniones con los proveedores, no durante ellas. Sin ella, a menudo se comparan cosas que no son comparables, y gana la mejor presentación, no la mejor oferta.
Sí. La lógica del Código de Sociedades Mercantiles polaco difiere de la de la administración pública: el horizonte de decisión es otro, también la presión sobre los resultados financieros, y algunas obligaciones (la contratación pública, por ejemplo) pueden no aplicarse a una empresa en la misma medida que a un organismo público. Por eso la comunicación con las empresas municipales y el asesoramiento que reciben deben plantearse en lenguaje de negocio —riesgo, coste, continuidad—, no en lenguaje administrativo.
Hay que calcular el coste total de propiedad a varios años vista —licencia, implantación, mantenimiento, formación, integración— y compararlo con el coste real de los sistemas actuales, dispersos, no con el precio nominal que tenían hace años. Una afirmación genérica de que una sola plataforma ahorrará dinero suele desmoronarse en cuanto se hacen los números.
Primero, enumere con qué debe funcionar el nuevo sistema: el sistema financiero-contable, el circuito de facturas para KSeF, los sistemas técnicos y la atención al cliente. Determine quién decide sobre los procesos en la empresa y defina por escrito los requisitos, integraciones incluidas, antes de empezar a hablar con los proveedores. Compare las ofertas en una única matriz y por su coste total, y base la recepción del sistema en escenarios de prueba acordados.
