CONSULTORÍA · PROCESOS · INTEGRACIÓN
Cuando el software obliga a cambiar una forma de trabajar que sí funciona
Un software puede estar bien implantado y aun así obligar al equipo a trabajar por fuera para terminar determinadas gestiones. Antes de adaptar la empresa a la herramienta hay que comprobar si ese cambio simplifica el trabajo o elimina algo que todavía hace falta. La respuesta se ve mejor en las tareas que hace el equipo cada día.
Un SaaS se construye para muchos clientes, así que no puede reproducir cada forma particular de trabajar. Esa estandarización es parte de su ventaja. Permite empezar con funciones ya resueltas y facilita que el proveedor mantenga el producto sin crear una versión distinta para cada empresa. La contrapartida es que algunas decisiones del producto vienen dadas de antemano.
Una parte de esas diferencias se debe a costumbres que merece la pena abandonar. Otra responde a necesidades que siguen siendo válidas. El trabajo está en distinguir una de otra antes de modificar el proceso solo para que quepa en el software.
El SaaS ya viene con decisiones tomadas sobre cómo trabajar
Un CRM obliga a registrar las oportunidades de una forma concreta. Un ERP hace lo mismo con pedidos o facturas. En un software sectorial ocurre igual. La pantalla, los permisos y las acciones disponibles responden a decisiones que el proveedor ya ha tomado antes de que la empresa empiece a usarlo. La empresa puede adoptarlas tal cual o comprobar si alguna choca con una necesidad propia.
Eso forma parte del modelo SaaS. El proveedor mantiene un producto común y lo actualiza para muchos clientes. AWS incluye entre sus principios la eficiencia operativa y una experiencia unificada. También advierte de que las personalizaciones únicas se alejan de esa lógica. Pretender que el producto reproduzca cada detalle interno de una empresa suele chocar con el propio modelo. La pregunta que queda es más concreta: qué merece conservarse y qué puede asumir el estándar sin crear trabajo nuevo.
El software, por tanto, llega con una forma de representar el trabajo ya definida. Puede encajar mejor que la actual y merece aprovecharla cuando eso ocurre. Cuando obliga a crear tareas nuevas por fuera, hay que revisar el encaje.
Aceptar una decisión del software sin revisar cómo afecta al trabajo puede salir caro. El estándar puede mejorar una tarea, pero también puede eliminar algo que el equipo sigue necesitando. Para saberlo hay que mirar qué cambia para quien hace esa gestión.
Primero hay que saber qué diferencia existe
Antes de cambiar de plataforma conviene identificar qué está fallando. Una incomodidad de uso no plantea el mismo problema que una función necesaria que ha desaparecido. Tampoco exige la misma respuesta.
1. El estándar encaja
El proceso estándar del software cubre lo que la empresa necesita y evita trabajo innecesario. En ese caso, adaptarse al SaaS suele ser lo más razonable.
2. Basta con configurar
La función ya existe y el problema se resuelve con configuración. En este caso, añadir otra herramienta solo complicaría la gestión. El trabajo está en ajustar bien la aplicación y evitar soluciones paralelas que después haya que mantener.
3. El trabajo continúa en otra aplicación
El SaaS resuelve su parte, pero para terminar la gestión hay que consultar o actualizar otra aplicación. Eso puede ser perfectamente normal si el paso entre ambas está bien resuelto.
4. Falta una capacidad necesaria
La empresa pierde una función que necesita para trabajar. Otra señal es tener que compensar esa carencia cada día con tareas manuales. Si el mismo rodeo se repite una y otra vez, deja de ser una excepción.
Estas situaciones pueden convivir en una misma implantación. Un CRM puede resolver bien el seguimiento comercial y quedarse corto en una gestión concreta de postventa. También puede necesitar datos del ERP para completar una tarea. Localizar esa carencia antes de juzgar toda la herramienta evita decisiones desproporcionadas. Cambiar de plataforma por un problema localizado puede crear más trabajo del que resuelve.
En un ecommerce, por ejemplo, la tienda puede resolver bien la venta mientras otras aplicaciones siguen interviniendo en la gestión del pedido.
Una etiqueta como “rígido” o “flexible” dice poco por sí sola. Hay que mirar la tarea concreta que está fallando.
Cuando alguien dice “no encaja”, hay que averiguar qué quiere decir
Después de una migración aparecen quejas muy distintas. Algunas se deben al aprendizaje. Otras señalan que una tarea necesaria ya no puede hacerse igual. Si se tratan todas de la misma forma, se corre el riesgo de personalizar por cualquier molestia o de ignorar una carencia real. Antes de decidir, lo más útil es pedir ejemplos concretos.
Cuesta acostumbrarse
La queja puede ser tan simple como «antes lo hacía más rápido». Hay una curva de aprendizaje, pero la empresa sigue pudiendo hacer lo mismo. Aquí el problema suele disminuir cuando la persona conoce mejor la herramienta.
La forma anterior de trabajar era mejorable
A veces el nuevo software obliga a abandonar una costumbre que aportaba poco. Si cada comercial utiliza nombres distintos para las mismas fases, una clasificación común facilita el seguimiento. Aquí el cambio puede mejorar la gestión sin quitar ninguna capacidad necesaria. La resistencia inicial no convierte esa costumbre en una necesidad de negocio.
La empresa ha perdido algo que necesita
En otros casos falta una condición que sí afecta al trabajo diario. Puede obligar a llevar un control por fuera o impedir terminar una gestión dentro del software. Ese coste vuelve a aparecer cada vez que se repite el caso. Si además intervienen varias personas, el riesgo de que cada una lo resuelva de una manera distinta aumenta.
Si falta aprendizaje, la respuesta puede ser formación. Cuando la forma anterior de trabajar era innecesariamente complicada, se puede simplificar. Si se ha perdido una función que el negocio necesita, hay que comprobar si puede recuperarse con configuración o conectando otra herramienta. Un cambio mayor debería llegar después de descartar esas opciones.
La entrada sobre SaaS, integración o automatización a medida desarrolla las opciones disponibles. Aquí interesa llegar un paso antes y concretar qué se ha perdido o qué trabajo nuevo ha aparecido.
Cuándo merece la pena adaptarse al SaaS
Hay empresas que intentan conservar en el nuevo software todo lo que hacían antes. Eso suele encarecer la implantación y deja muchas particularidades difíciles de mantener. Cambiar de plataforma también sirve para revisar costumbres que existen solo porque siempre se han hecho así. No todo lo antiguo merece reproducirse.
Oracle recomienda aprovechar los procesos estándar en las implantaciones ERP en la nube cuando encajan con la necesidad. También advierte de que las personalizaciones innecesarias aumentan el mantenimiento y pueden dificultar futuras mejoras. Conservar cada excepción por defecto suele encarecer la implantación.
Adaptarse al estándar suele compensar cuando
- El proceso no aporta una ventaja competitiva ni una necesidad específica.
- La diferencia actual procede de hábitos heredados.
- El estándar simplifica el seguimiento del trabajo.
- Las excepciones son pocas y pueden gestionarse de forma razonable.
- La estandarización facilita el control del proceso.
- La personalización necesaria costaría más que el valor que preserva.
Si cinco comerciales utilizan nombres distintos para las mismas fases de venta, adoptar los estados del CRM puede simplificar el seguimiento. No hay mucho que ganar manteniendo cinco vocabularios. También resulta más fácil formar a una persona nueva si todos utilizan la misma clasificación.
La situación cambia si esa diferencia afecta a algo que la empresa necesita para trabajar. Si desaparece una condición que influye en una comisión o cambia la forma de atender a un cliente, ya no se está eliminando una costumbre; se está perdiendo una condición que la empresa utiliza.
Cuándo adaptarse empieza a generar más trabajo
Ese coste rara vez aparece en una factura. Se nota cuando el equipo empieza a hacer comprobaciones que antes no existían o mantiene registros duplicados para compensar lo que falta en el software. También se ve cuando alguien crea una hoja auxiliar que acaba siendo imprescindible.
Tener que rehacer por fuera algo que antes quedaba resuelto dentro de una gestión ya indica que el cambio ha creado trabajo adicional. También ocurre cuando una tarea digital termina en una exportación o en una hoja auxiliar porque la herramienta no permite completarla. Si ese rodeo forma parte de la rutina, ya no puede considerarse un caso puntual.
El porcentaje de cobertura tampoco cuenta toda la historia. Un software puede resolver casi todo un proceso y dejar fuera justo la parte que exige más criterio o que diferencia a la empresa. Ese pequeño porcentaje puede concentrar una parte importante del trabajo.
| Lo que ocurre | Qué conviene preguntar |
|---|---|
| Se copia información entre aplicaciones. | ¿El proceso atraviesa varios sistemas y falta una integración? |
| Aparecen hojas paralelas. | ¿Guardan una preferencia personal o una información que el sistema no representa? |
| Una tarea depende de recordar el paso siguiente. | ¿Falta una regla que cree automáticamente la tarea siguiente? |
| Se pierde una excepción valiosa. | ¿Es realmente excepcional o forma parte habitual del modelo de negocio? |
| La migración obliga a cambiar herramientas adyacentes. | ¿El beneficio global compensa ese coste de cambio? |
| El equipo evita registrar información. | ¿El equipo necesita formación o la nueva forma de trabajar añade tareas innecesarias? |
Si el estándar reduce trabajo, adaptarse tiene sentido. Si obliga a mantener tareas permanentes fuera del software, esa parte de la implantación merece otra revisión.
El coste de adaptarse no termina con la implantación
La cuota del SaaS es solo una parte del coste. La implantación consume tiempo mientras el equipo aprende y mientras se preparan los datos. Después hay que comprobar qué tareas desaparecen y cuáles seguirán repitiéndose porque la herramienta no cubre esa necesidad. Esa segunda parte suele pasar desapercibida al principio.
Ese esfuerzo inicial entra dentro de cualquier implantación seria. Lo que interesa separar es el trabajo que desaparece cuando termina la adaptación del que seguirá repitiéndose después.
Aprender la herramienta es un coste temporal. Lo mismo ocurre con la pérdida de velocidad de las primeras semanas. Comprobar todos los días una hoja externa es distinto. También lo es copiar datos entre CRM y ERP durante años. Ese trabajo debería entrar en el cálculo aunque no figure en la factura del proveedor. Si requiere una persona concreta para que nada falle, además crea dependencia interna.
Muchas implantaciones se evalúan demasiado pronto. Cuando el equipo ya puede completar las gestiones básicas, el proyecto parece terminado. Unos meses después merece otra revisión: ¿qué tareas siguen existiendo solo para compensar una limitación del software?
Trabajo temporal
Aprendizaje y ajustes necesarios mientras el equipo se acostumbra al nuevo sistema.
Trabajo que se queda para siempre
Tareas que siguen haciéndose fuera del software o se duplican cada vez que aparece el mismo caso.
El esfuerzo de las primeras semanas puede compensar si después el trabajo mejora. Las tareas que siguen repitiéndose indefinidamente deben entrar en el cálculo.
Hay otro coste menos visible: lo que la empresa deja de hacer para adaptarse. Si una limitación obliga a abandonar una forma de atención que funciona bien, el coste puede aparecer en el servicio o en las ventas. Esa pérdida no siempre se ve en las métricas del proyecto de implantación.
La frecuencia y el impacto cambian mucho la decisión. Una excepción que aparece unos minutos al mes rara vez justifica un desarrollo. Si afecta a muchos casos y obliga a varias personas a trabajar por fuera del sistema, el análisis cambia. En ese punto ya merece la pena calcular alternativas.
Cuando una hoja, el correo o WhatsApp se vuelven imprescindibles
Tener una hoja de cálculo paralela no significa que la implantación haya fallado. Tampoco es raro utilizar correo o WhatsApp para determinados casos. La señal cambia cuando uno de esos canales guarda un dato imprescindible para decidir después qué hacer dentro del SaaS. Si ese dato no se actualiza en la aplicación principal, el equipo empieza a trabajar con versiones distintas.
La pregunta es bastante concreta: ¿qué se está resolviendo fuera del software y qué obliga a hacer después?
Si una hoja contiene el único registro fiable de un dato importante, la empresa depende de ella. Si una aprobación solo puede resolverse por correo, esa parte no está reflejada en el software. Y si un mensaje de WhatsApp cambia algo que debería constar en el CRM, alguien tendrá que actualizarlo después. El canal puede seguir siendo válido; lo que hay que evitar es que el dato definitivo quede únicamente allí.
No hay que eliminar esos canales por principio. Lo problemático es que alguien tenga que recordar después qué cambió y copiarlo manualmente a otra herramienta.
Aquí una automatización puede evitar parte del trabajo manual. Puede leer el mensaje y relacionarlo con el registro correcto. Antes de actualizar nada, deben aplicarse las comprobaciones necesarias. La automatización de WhatsApp conectada con CRM y ERP es un ejemplo de este tipo de integración.
Qué mirar cuando la migración ya está en marcha
En una migración puede ocurrir algo incómodo: la herramienta nueva mejora muchas tareas y, al mismo tiempo, complica otras que antes estaban resueltas. Parte de esa incomodidad desaparece cuando el equipo aprende. Otra parte descubre funciones que se utilizaban de verdad y que ya no tienen equivalente directo. Separar ambas situaciones evita discusiones genéricas sobre si el nuevo software “es mejor” o “es peor”.
Lo hemos visto en trabajos con HubSpot, Salesforce y Vrepro. En esos casos interesaba revisar qué había cambiado en tareas concretas después de la migración, no emitir una valoración general sobre la plataforma.
Una persona puede necesitar tiempo para aprender la nueva herramienta. Otra descubre un paso que antes no existía. También puede faltar una función necesaria. Las tres situaciones pueden producir la misma queja, pero exigen respuestas distintas.
Si falta aprendizaje, la formación suele bastar. Cuando aparece un paso nuevo hay que comprobar si realmente aporta algo. Y si ha desaparecido una función necesaria, toca decidir cómo recuperarla.
Llamar “resistencia al cambio” a cualquier objeción hace fácil pasar por alto una carencia real. Conservar todas las costumbres porque alguien protesta produce el problema contrario.
La forma más útil de analizar una queja es bajar a una tarea concreta. ¿Cómo se hacía antes? ¿Qué ha cambiado ahora? Con esas dos respuestas se puede comprobar si el nuevo paso tiene sentido o simplemente añade trabajo. Si hace falta, se prueba con varios casos antes de modificar toda la implantación.
Las excepciones deberían revisarse antes de eliminarlas. Algunas existían por limitaciones del sistema anterior. Otras seguirán apareciendo porque forman parte del negocio.
Cuando una nueva plataforma obliga a cambiar herramientas que ya funcionan
Pensemos en una empresa que utiliza correo corporativo alojado en Raiola y trabaja con Thunderbird. Parte de la documentación está en Google Drive y Sheets. Además, hay automatizaciones que conectan esas herramientas con otras aplicaciones. Todo eso puede funcionar bien durante años sin necesidad de unificarlo. Cambiar una sola pieza puede afectar a varias de esas relaciones.
La empresa encuentra una plataforma que resuelve bien una necesidad concreta, pero la integración de correo está pensada para Gmail o Microsoft 365. De repente la decisión ya no afecta solo a la nueva plataforma. Puede obligar a cambiar el correo del equipo y también las automatizaciones que dependen de la configuración actual. Ese coste debe valorarse antes de aceptar la nueva herramienta como una mejora aislada.
Una opción es cambiar de proveedor de correo. Otra es mantenerlo y construir una integración. También se puede renunciar a esa función o elegir otra plataforma. El coste de implantación depende de cuál de esas alternativas sea viable. No hay una respuesta universal porque el impacto depende de las herramientas que ya estén funcionando.
La comparación no puede quedarse en la licencia. También cuenta todo lo que hay que modificar para que la nueva plataforma encaje con lo que ya funciona.
Antes de aprobar la compra hay que revisar qué herramientas que hoy funcionan tendrían que modificarse como consecuencia.
IA APLICADA A PROCESOS
Dónde puede ayudar la IA cuando el SaaS deja trabajo fuera
La IA es útil sobre todo cuando la entrada no llega en campos ordenados. Un correo puede explicar una petición de muchas maneras. Lo mismo ocurre con un mensaje o con un documento. Antes de conectar aplicaciones, alguien tiene que entender qué se está pidiendo y con qué registro se relaciona. Esa es la parte donde un modelo puede ahorrar trabajo sin sustituir las reglas del negocio.
Entender la petición
Interpretar lo que pide una persona aunque no utilice la terminología del software.
Leer datos de un documento
Extraer la información que después tendrá que comprobarse.
Relacionar la solicitud
Identificar a qué cliente, pedido o expediente corresponde antes de continuar.
Preparar un resumen
Dar a una persona la información necesaria sin obligarla a abrir varias fuentes.
Señalar una discrepancia
Avisar cuando lo recibido no coincide con lo que ya figura registrado.
Preparar un borrador
Redactar una respuesta o una propuesta de acción cuando las reglas ya están definidas.
La IA sirve para entender la entrada. La decisión debe apoyarse después en los datos registrados y en las reglas correspondientes.
Por ejemplo, la IA puede leer un correo en el que un cliente pide cambiar una entrega. Antes de confirmar nada hay que consultar el pedido registrado y comprobar si ese cambio es posible. Con una factura ocurre algo parecido: extraer sus datos no equivale a aprobar un asiento contable.
Aquí la IA sirve para una tarea muy concreta: evitar que cada petición tenga que llegar con el formato perfecto. Una vez entendida la entrada, las reglas del negocio y las aplicaciones correspondientes determinan qué puede hacerse. Si falta un dato o existe una excepción, el caso puede pasar a una persona.
Dentro del equipo también puede ahorrar tiempo. Ante una incidencia, un resumen preparado con datos autorizados evita abrir varias aplicaciones solo para entender qué ha ocurrido.
Ejemplos de tareas que suelen quedar fuera del SaaS
CRM: el lead llega por correo o WhatsApp
El CRM puede gestionar bien las oportunidades y aun así recibir leads por canales donde la información llega en texto libre. La IA puede preparar esos datos para crear o completar el registro. Así se evita copiar la misma información antes de empezar el seguimiento.
Despacho jurídico: parte de la información llega fuera del expediente
El software jurídico puede seguir siendo la referencia del expediente aunque parte de la documentación llegue por otros canales. La guía sobre cómo automatizar lo que ocurre entre expedientes, email y documentos desarrolla ese caso.
Gestoría: el documento llega antes que el asiento
El programa contable puede seguir siendo el lugar adecuado para registrar la operación. Si la documentación llega por otros canales, la automatización documental con IA puede preparar los datos antes de que alguien los valide o los envíe al programa contable.
Clínica: la solicitud llega fuera de la agenda
La agenda sigue siendo la referencia para las citas. Una duda administrativa o una petición de cambio puede llegar por teléfono o mensajería. Ese mensaje puede registrarse sin utilizar la IA para decidir nada asistencial.
Academia: varias aplicaciones participan en la gestión del alumno
El software académico puede gestionar bien los grupos mientras el campus o los pagos se resuelven en otras aplicaciones. Eso puede funcionar perfectamente. La guía sobre cómo conectar lo que queda fuera del software académico entra en ese caso. La dificultad aparece cuando responder a una gestión obliga a revisar varias herramientas a mano.
Industria: un cambio de pedido llega por email
Un cliente puede pedir por correo que se modifique un pedido ya registrado. La IA puede identificar qué solicita y preparar los datos. Antes de aplicar nada hay que comprobar el pedido en el ERP.
Administración de fincas: la avería llega antes que el expediente
Una avería puede comunicarse por distintos canales. La persona que la atiende tiene que identificar la comunidad y registrar la incidencia. Parte de ese trabajo puede automatizarse sin sustituir el software sectorial.
La aplicación principal puede seguir siendo válida aunque una parte de la gestión necesite otra solución.
Antes de comprar otra herramienta, concreta qué problema quieres resolver
Cuando un software empieza a resultar incómodo, la reacción habitual es buscar uno más completo. Puede ser la decisión correcta, pero también puede trasladar las mismas tareas manuales a otra plataforma. Antes de comparar productos hay que identificar la causa concreta.
Preguntas que ayudan a decidir
- ¿Qué proceso concreto no está funcionando como necesitamos?
- ¿La diferencia es una preferencia o afecta al resultado del negocio?
- ¿Podemos simplificar el proceso y adoptar el estándar sin perder valor?
- ¿La herramienta ya permite configurarlo y no lo estamos aprovechando?
- ¿El problema aparece porque el proceso cruza varias aplicaciones?
- ¿Qué información queda hoy en hojas, correos o chats paralelos?
- ¿Qué parte del trabajo necesita interpretar lenguaje o documentos?
- ¿Qué sistema debe confirmar cada dato importante?
- ¿Qué excepciones necesitan criterio humano?
- ¿Cuánto cuesta mantener este problema frente a resolverlo?
Con esas respuestas ya se puede decidir qué hacer con el software principal. Antes merece la pena revisar la tarea concreta que falla. Ese orden evita comprar una solución nueva para un problema secundario. La priorización de procesos ayuda a no dedicar recursos a un problema de poco impacto.
Tampoco tiene sentido reproducir dentro del software cada particularidad histórica de la empresa. Merece la pena conservar lo que aporta algo real al negocio. El resto puede aprovechar el estándar y reducir mantenimiento.
Que “el sistema funcione así” no cierra la discusión
Hay tareas en las que adoptar el estándar simplifica la gestión. En otras, esa misma decisión elimina una capacidad que la empresa necesita.
Para elegir bien hay que mirar qué cambia en el trabajo diario y cuánto cuesta cada alternativa.
Utilizar varias aplicaciones no es un defecto por sí mismo. Salesforce documenta como habitual que un mismo proceso empresarial implique dos o más aplicaciones. La complicación aparece cuando una aplicación necesita datos de otra y el equipo tiene que moverlos manualmente.
Al final hay que separar lo que puede asumir el estándar de lo que realmente necesita otra solución.
Si el SaaS ya resuelve bien la gestión y lo único que sobra es una costumbre antigua, adoptar el estándar también puede ser la mejor decisión.
Preguntas frecuentes sobre cuándo un SaaS encaja y cuándo no
¿Un SaaS obliga siempre a cambiar los procesos de la empresa?
Cualquier software obliga a organizar parte del trabajo de una forma determinada. La empresa tiene que comprobar qué cambios simplifican la gestión y cuáles eliminan una capacidad necesaria.
¿Es malo adaptar un proceso al software?
No. Puede ser una buena decisión si elimina una costumbre que ya no aporta nada. Antes conviene comprobar si el cambio afecta a una necesidad real.
¿Cómo sé si necesito cambiar de SaaS o integrar el que ya tengo?
Si cada aplicación cumple bien su función y el problema está al pasar información de una a otra, una integración puede resolverlo sin migrar todo. Si falta una función necesaria, hay que comprobar si puede añadirse o si realmente hace falta cambiar de plataforma.
¿Tener Excel o procesos manuales fuera del SaaS significa que la implantación está mal?
No necesariamente. Puede ser una solución temporal o una excepción legítima. Merece revisión cuando esa herramienta paralela guarda información imprescindible o obliga a repetir trabajo de forma permanente.
¿Dónde aporta IA en una arquitectura basada en SaaS?
La IA encaja bien cuando primero hay que entender un mensaje o un documento. Después, los datos que determinan la acción deben comprobarse en las aplicaciones autorizadas.
¿La IA puede evitar una migración de software?
A veces reduce el trabajo que queda fuera del software. No corrige una carencia estructural ni un problema de seguridad, así que en algunos casos la migración seguirá siendo necesaria.
¿Qué debería analizar una empresa antes de comprar un nuevo SaaS?
Primero hay que definir el problema que se quiere resolver. Después hay que probar la herramienta con situaciones reales y revisar qué cambios exigiría en el resto del trabajo.
DIAGNÓSTICO DE ENCAJE
¿Tu software está obligando a cambiar una forma de trabajar que sí funciona?
Podemos revisar qué tareas encajan bien en el SaaS y cuáles siguen obligando al equipo a trabajar por fuera. A partir de ahí se puede comprobar si el problema se resuelve configurando mejor la herramienta, conectándola con otra aplicación o planteando un cambio de software.
Revisar dónde el software está condicionando el procesoFuentes
- AWS — SaaS Architecture Fundamentals: principios del modelo SaaS, eficiencia operativa, experiencia unificada y relación con personalizaciones específicas. Consultar fuente.
- Salesforce Architects — Integration Patterns: patrones para integración de datos y procesos entre Salesforce y otras aplicaciones empresariales. Consultar fuente.
- Oracle — Plan de proyecto de implementación de un ERP: estandarización, procesos listos para usar, personalización, integración y gestión del cambio en implantaciones ERP cloud. Consultar fuente.
Los ejemplos de implantación y migración incluidos en el artículo se utilizan como observaciones profesionales y escenarios operativos. No implican una valoración negativa de las plataformas mencionadas ni que el mismo comportamiento se produzca en todas las organizaciones.
