Resumen

  • Atlassian presenta un caso ilustrativo en el que una aplicación de Confluence pasa del precio para 25 usuarios al de 100 al trasladar la suscripción a Teamwork Collection en un sitio con 100 usuarios de Jira.
  • La colección cuenta una sola vez a cada usuario de sus productos incluidos. Las aplicaciones de Marketplace conservan reglas propias que pueden ampliar su base de cobro durante la mudanza.
  • Las opciones por instancia, las licencias Enterprise para varias instancias y el diseño de cobro Forge por usuarios autorizados trazan límites distintos. La comparación depende del modelo disponible y de la oferta del proveedor.

Setenta y cinco personas pueden entrar en la base de cobro de una herramienta por una decisión tomada sobre otros productos. El responsable de la herramienta tendrá que justificar la compra ampliada, aunque el proyecto aprobado fuera reunir las suscripciones principales.

La guía de facturación de Marketplace de Atlassian permite seguir ese movimiento con números. Un Confluence Cloud de 25 usuarios, con una aplicación instalada, se traslada a Teamwork Collection. En el mismo sitio hay 100 usuarios de Jira. La aplicación pasa al precio de 100.

El paquete ha cambiado la cantidad que el proveedor puede cobrar. La regla vincula ese salto con la suscripción, sin exigir que las otras 75 personas empiecen a utilizar la aplicación. Para un equipo especializado, el peligro está en aprobar la plataforma compartida y descubrir después qué alcance compró para sus herramientas.

La población se cuadruplica. El importe requiere la tarifa de la aplicación, sus tramos y sus descuentos. Esa cotización pertenece al expediente de la migración: si compras solo compara Jira y Confluence, deja fuera una consecuencia que la propia Atlassian ya ha puesto por escrito.

Una sola línea de factura, varias licencias por revisar

La explicación de las Collections establece un recuento de usuarios únicos entre las aplicaciones incluidas. Una persona con acceso a alguna de ellas es facturable; si accede a varias, cuenta una sola vez. En Teamwork Collection, productos incluidos como Jira, Confluence y Loom se reúnen en una línea de suscripción.

Para una empresa cuyos empleados trabajan con varias herramientas, la propuesta resulta fácil de defender. Una persona sigue siendo una persona al cambiar de aplicación. El comprador gana una forma más sencilla de presentar el conjunto y de explicar su factura.

Las aplicaciones de Marketplace llevan consigo otra relación comercial. Atlassian indica que su cobro depende de la licencia y del vínculo con la aplicación anfitriona, y advierte de cambios de precio al trasladarlas a una colección. El paquete puede eliminar duplicados dentro de sus productos mientras una herramienta externa hereda una base de usuarios mayor.

Esos dos movimientos caben en la misma operación porque cuentan cosas distintas. La colección agrupa personas comunes a sus productos. El proveedor de la aplicación vende una licencia cuyo alcance puede depender del entorno anfitrión. El ahorro calculado para el primer grupo no resuelve la compra del segundo.

Aquí importa quién preparó la decisión. El equipo que busca reunir productos puede medir la integración y la sencillez administrativa. El responsable de una aplicación especializada tendrá que explicar por qué una necesidad de su equipo llega ahora con una factura para más personas. Ahí hay una decisión presupuestaria concreta: alguien ha ampliado el contrato de una herramienta al reorganizar los productos que la rodean. Su responsable necesita conocer el nuevo precio antes de quedar comprometido con la configuración.

Cincuenta usan la herramienta. Quinientos sostienen la licencia

La documentación de los modelos Forge hace explícita la diferencia. En el modelo estándar se paga por todos los usuarios de la instancia anfitriona, con independencia de cuántos utilicen la aplicación de Marketplace.

Atlassian lo ilustra con una instancia de Jira de 500 usuarios, de los cuales 50 usan la aplicación. A la tarifa pedagógica de 2 dólares por usuario y mes, el cálculo da 1.000 dólares para los 500. La función de estas cifras es mostrar cómo se construye la base de cobro.

Para una herramienta de uso especializado, esa base puede complicar la entrada en una gran empresa. Un equipo quiere resolver su propio trabajo y debe justificar una licencia dimensionada para el entorno compartido. Cuanto menor sea el grupo interesado respecto a ese entorno, más importante resulta explicar el beneficio de la compra.

También puede haber valor en una licencia amplia. Una aplicación destinada a toda la organización puede evitar una administración minuciosa de quién entra y quién sale de su lista. La comparación útil consiste en relacionar el alcance comprado con la necesidad que se pretende atender, junto con el trabajo de gestionarlo.

Las reglas de Jira añaden una distinción precisa. Si el sitio tiene 100 usuarios de Jira y 80 agentes de Jira Service Management, la guía aplica a las aplicaciones la cantidad mayor: 100. La suma de 180 describe otra operación. Si se desactiva la suscripción de Jira de 100 usuarios, el precio correspondiente a los 80 restantes empieza en el siguiente ciclo de cobro.

Por tanto, la lista de personas que abrieron la herramienta solo explica una parte de la decisión. Hay que identificar también qué producto anfitrión fija la cantidad, dónde está instalado y cuándo cambia el tramo aplicable. Una estadística de actividad y una licencia describen poblaciones que pueden tener tamaños muy diferentes.

El mapa de instalaciones también reparte el presupuesto

El manual de facturación Enterprise ofrece otro ejemplo, con una organización ficticia llamada Acme. Sus 8.000 usuarios de Jira se distribuyen en dos instancias, de 5.000 y 3.000. Una aplicación instalada en la primera se factura, bajo ese esquema por instancia, en el tramo de 5.000 usuarios.

El tamaño total de la empresa y el tamaño de cada compra de aplicaciones pueden diferir. Elegir la instancia equivale también a elegir un ámbito de licencia. Una herramienta para un trabajo concreto puede ocupar un espacio distinto del que necesita una herramienta común a todos.

Separar entornos trae tareas adicionales: mantener configuraciones, explicar accesos y organizar la colaboración entre equipos. Una factura de aplicación menor debe compararse con ese trabajo. De lo contrario, compras puede registrar una rebaja mientras administración absorbe la diferencia en horas.

Atlassian documenta además una opción de facturación para varias instancias de Jira o Confluence en Cloud Enterprise. Agrupa las instancias bajo una suscripción de aplicación a nivel de organización y cuenta una vez a cada usuario único entre ellas, según el tramo elegido al comenzar la suscripción. Para usar las funciones, todavía hay que instalar la aplicación en las instancias correspondientes.

Ese modelo resuelve la repetición de una persona en varios entornos. Cobrar solo por una parte autorizada de los usuarios dentro de una única instancia aborda una selección diferente. Antes de celebrar que se eliminan duplicados conviene decir qué duplicado se está eliminando.

La página emplea el futuro al indicar que todas las aplicaciones ofrecerán precios para varias instancias. La compra concreta tiene que ajustarse a las opciones disponibles para la aplicación elegida. Un modelo documentado orienta la comparación; el proveedor debe ofrecerlo en la operación que se quiere contratar.

Recortar permisos requiere un vendedor dispuesto a vender menos alcance

La guía de adopción de cobro por usuarios de Forge describe una alternativa: el administrador decide quién recibe acceso a la aplicación y la organización paga por ese grupo. La autorización define la población. El uso efectivo de la herramienta sigue siendo otra medida.

Los documentos consultados presentan esta capacidad como EAP y permiten construir, desplegar y probar en entornos ajenos a producción. Sitúan la publicación en Marketplace, la configuración de precios, las revisiones y las aprobaciones entre las actualizaciones futuras. La guía también incluye condiciones para aplicaciones publicadas y transiciones a producción; en una compra actual hay que comprobar el modelo realmente activado en la aplicación.

El diseño reserva decisiones al proveedor. El socio puede elegir la transición y ajustar precios; sus clientes existentes pasan con la aplicación al nuevo modelo. La capacidad se dirige a Forge, mientras que una aplicación Connect necesita adoptar Forge previamente. Una lista de permisos más corta solo se convierte en una compra más estrecha cuando la licencia admite ese alcance.

La posibilidad tiene interés para los productos especializados. Podrían entrar en organizaciones grandes sin pedir a una pequeña unidad que justifique de inmediato una licencia para todo el anfitrión. A la vez, el proveedor puede revisar el precio por usuario al reducirse la población facturable. El total sigue dependiendo de ambas variables.

Para calcular el importe o el ahorro de una migración particular hacen falta la licencia aplicable, el tramo seleccionado y la oferta del proveedor. Las reglas oficiales ya permiten exigir esos datos en el momento adecuado: antes de reorganizar la compra y dar por descontado el resultado.

Agrupar productos puede mejorar la colaboración y simplificar la administración. Comprarlos bien exige que las aplicaciones acompañantes lleguen con su propia cuenta actualizada. Los 25 usuarios del ejemplo no necesitan una herramienta más grande para encontrarse con el precio de 100. Basta con que la suscripción cambie de casa.