Puntos clave del artículo
Procesos antes que la herramienta
Quién aprueba, cuáles son las excepciones y qué rastro de decisión debe quedar.
Inventario de lo que ya existe
El CRM, los sistemas sectoriales, el sistema de gestión documental y el paquete ofimático a menudo ya cubren parte de los flujos.
Requisitos contra el vendor lock-in
Exportación, API, BPMN, derechos de configuración, plan de salida.
Coste a varios años
Compra, implantación, mantenimiento y coste de salida, comparados con vuestros propios escenarios.
Zdjęcia ilustracyjne
Después redacta los requisitos que protegen frente al vendor lock-in: exportación de datos e historial de expedientes en formato abierto, API documentada, procesos registrados en el estándar BPMN, derecho a configuración propia y reglas claras de salida del contrato. Nombra los riesgos que hoy eres capaz de identificar. No seas ingenuo: anota todos los riesgos. Compara las ofertas con vuestros propios escenarios y en coste total a varios años (inversión más costes operativos recurrentes). Licencias, renovaciones, formación, mantenimiento del equipo, cambios, migraciones. Piensa en la probabilidad de que el proveedor pierda a sus consultores clave, decida sustituir a administradores y desarrolladores por IA, o deje de dar soporte al sistema operativo actual.
Este artículo está dirigido a los consejos de administración de empresas y sociedades municipales (spółka komunalna) que quieren ordenar el flujo de documentos, facturas de gasto, contratos o solicitudes, y se enfrentan a la elección de un sistema workflow, es decir, una herramienta que conduce el expediente de una persona a la siguiente según unas reglas establecidas. Habitualmente hay tres caminos posibles: una plataforma BPM lista para usar, una herramienta low-code o un sistema a medida desarrollado a petición; las reglas que siguen aplican a los tres. También será útil para los directores financieros, porque son ellos quienes suelen pagar las consecuencias de una mala elección.
Por qué el vendor lock-in nace desde el principio
El vendor lock-in rara vez es resultado de una sola mala decisión. Normalmente empieza antes de lo que la empresa percibe: los procesos quedan descritos dentro de la herramienta del proveedor y no en documentos propios; los datos y el historial de expedientes están en un formato que no se puede extraer fácilmente; solo el socio implementador conoce la configuración; y el contrato habla mucho de la implantación y poco de lo que ocurre cuando la empresa quiere marcharse. Al cabo de unos años, cambiar de sistema cuesta más que mantenerlo, aunque haya dejado de responder a las necesidades.
Paso 1. Describe los procesos antes de hablar con los proveedores
Antes de redactar una solicitud de ofertas, conviene describir los flujos que el sistema debe soportar: quién inicia el expediente, quién lo aprueba y en qué orden, cuáles son las excepciones y los umbrales (por ejemplo, una ruta distinta por encima de un importe determinado), cuáles son los plazos y qué rastro de decisión debe quedar en caso de auditoría. Lo mejor es registrarlo en el estándar BPMN, que entienden distintas herramientas. Así la descripción del proceso pertenece a la empresa, no al sistema.
Sin esta descripción se comparan presentaciones de proveedores, no soluciones. Cada demostración parece buena, porque el proveedor muestra su mejor escenario, no vuestra excepción más complicada.
Paso 2. Comprueba qué tienes ya
Parte de los flujos a menudo se puede resolver con herramientas que la empresa ya posee: el CRM, los sistemas sectoriales, el sistema de gestión documental o el paquete ofimático. A veces la conclusión del análisis es que no hace falta un sistema nuevo, sino un cambio de procedimiento o de configuración. Este inventario también muestra las integraciones que el nuevo sistema deberá soportar, por ejemplo con el sistema financiero-contable y el KSeF (Sistema Nacional de Facturación Electrónica), así como los puntos donde hoy se pierde información. Más: inventario de sistemas TI.
Paso 3. Requisitos que protegen frente al vendor lock-in
Estos requisitos conviene incluirlos en la solicitud de ofertas como condiciones, no como deseos:
- Exportación de datos e historial de expedientes en formato abierto y documentado, en cualquier momento y sin coste adicional.
- API documentada para la integración con otros sistemas, con derecho de uso también para otros contratistas.
- Procesos registrados en un estándar (BPMN) que se puedan exportar y reconstruir en otro lugar.
- Derecho a la configuración por parte del equipo propio o de cualquier socio, con documentación de los cambios.
- Reglas de salida del contrato: periodo transitorio, ayuda en la migración de datos y su coste conocido de antemano.
- Elección del socio de mantenimiento: si tras la implantación se puede cambiar de empresa implementadora sin perder el soporte del fabricante.
Es como alquilar una oficina con un contrato que indica cuánto cuesta entrar, pero calla sobre la salida. Mientras todo funciona, nadie lo nota. El problema aparece el día en que hay que mudarse.
Lo mismo aplica a RPA, ERP y CRM
Estas reglas rigen para cualquier sistema que ordene el trabajo de la empresa. En cada caso, sin embargo, conviene empezar por preguntar qué se quiere conseguir, porque de la respuesta depende si siquiera se está eligiendo la clase correcta de herramienta.
RPA. La primera pregunta es: ¿por qué RPA y no BPM? El robot de software asume tareas repetitivas de una persona dentro de los sistemas existentes, pero no cambia el proceso; el BPM ordena el propio proceso. Si el objetivo es liberar a las personas de copiar datos entre sistemas, el robot puede bastar. Si el objetivo es un flujo de expedientes nuevo y más corto, el robot a menudo perpetúa el antiguo. El robot también depende de las pantallas y formatos de otros sistemas: cualquier cambio en ellos puede detenerlo, por lo que conviene conocer el coste de mantener los escenarios y tener su descripción fuera de la herramienta del fabricante.
ERP. Aquí la pregunta clave es: ¿queremos que el ERP nos aporte buenas prácticas y procesos ya definidos, o que dé soporte a nuestros propios procesos, que construyen nuestra ventaja competitiva? En el primer caso conviene ceñirse al estándar del sistema y limitar los cambios, porque cada uno dificulta las actualizaciones y el cambio de socio. En el segundo, a veces funciona mejor un ERP sencillo rodeado de un sistema BPM ágil, en el que se modifican los procesos que distinguen a la empresa sin tocar el núcleo. En ambos casos, los datos financieros, de almacén y de personal, así como las integraciones con el KSeF y los bancos, deben poderse extraer por completo, junto con su historial.
CRM. Antes de empezar a comparar ofertas, conviene aclarar qué entendemos por CRM: ordenar los procesos de atención al cliente, la venta multicanal o una plataforma de captación de contratos. Son tres proyectos distintos, con usuarios distintos, integraciones distintas y un indicador de éxito distinto. Sea cual sea la variante, la exportación de la base de clientes con el historial de contactos y los consentimientos, así como la API hacia los sistemas de ventas y atención al cliente, deberían ser una condición en la solicitud de ofertas, no un extra.
Paso 4. Compara el coste total, no el precio de la licencia
Las ofertas conviene compararlas en coste total a varios años: compra e implantación, mantenimiento y licencias, desarrollo y coste de salida del contrato. La licencia más barata suele resultar la más cara en el tercer año, cuando cada cambio de proceso implica un encargo de pago a un único socio. La comparación mejor se hace con vuestros propios escenarios: que cada proveedor muestre el mismo caso difícil de vuestra empresa. Más sobre evaluación de ofertas: evaluación de ofertas y conversaciones con proveedores.
Para el director financiero, las dos cifras más importantes son las que normalmente faltan en la oferta: el coste de cambiar un proceso tras la implantación y el coste de abandonar al proveedor. Conviene pedirlas explícitamente en la fase de evaluación de ofertas.
Paso 5. Recepción y contrato de mantenimiento
El sistema conviene recibirlo según escenarios de prueba y criterios acordados previamente, no según las declaraciones del proveedor. El contrato de mantenimiento debe especificar en qué plazo se corrigen los errores, quién introduce los cambios y a qué coste, y debe confirmar las cláusulas de exportación de datos y salida del contrato.
Ejemplo práctico
En un grupo de filiales de una multinacional, la empresa utilizaba un sistema ERP centralizado y, al mismo tiempo, necesitaba automatizar procesos financieros del grupo procure-to-pay, cumpliendo además las directrices corporativas de compras (corporate purchasing guidelines). Existía una fuerte tentación de recurrir a las herramientas corporativas de trabajo en grupo, pero resultaron bastante caras y no cumplían los requisitos de independencia ni permitían una salida sencilla si surgían problemas.
En reuniones con las partes interesadas preparamos una descripción detallada de requisitos que iba más allá de las funciones estándar de las soluciones ya hechas. Desarrollamos varias formas alternativas de integración con los sistemas sectoriales y mecanismos para reducir el riesgo de dependencia de un único proveedor. El resultado fue una estrategia de aplicaciones coherente, basada en estándares, y un entorno en el que los nuevos flujos se crean de forma ágil, mediante prototipado en reuniones breves con los propietarios de los procesos, incluidos los no técnicos. Este entorno envuelve al sistema ERP: aporta gran flexibilidad allí donde la empresa se diferencia, sin los costes de grandes implantaciones.