Contabilidad analítica en SaaS B2B

En los años 90 prácticamente todas las empresas de software medianamente grandes tenían un departamento de servicios bien diferenciado del de desarrollo. El software se distribuía en CDs y los partners se encargaban comunmente de la parametrización en las implantaciones. Actualmente cada vez más empresas tienen ingenieros haciendo devops. El software se distribuye como servicio y hay menos espacio para los partners. La evolución en la distribución y en la realización de adaptaciones a medida implica que las empresas deben modificar también su organigrama, su contabilidad analítica y su política de facturación.

Ejemplo ingresos SaaS B2BEn el modelo de negocio clásico de licencias el fabricante cobraba una cantidad inicial (más o menos solía ser el 50% del coste total del proyecto). El implantador cobrabra otro 50% en parte por sus servicios y en parte como comisión de venta (si había traído al cliente). Cada año siguiente, el fabricante cobraba un mantenimiento anual en torno al 20% de lo facturado inicialmente en concepto de licencia y garantía, y el implantador cobraba lo que buenamente podía por sus servicios y soporte. Cuando había que hacer modificaciones a corto plazo estas eran por cuenta del partner. El ritmo de actualizaciones del fabricante era relativamente lento, una nueva versión cada dos años, o a lo sumo, una nueva versión cada año.

El cálculo de costes era relativamente sencillo. Para el fabricante de software el beneficio dependía del número de copias vendidas. Como el coste mrginal de cada nueva copia vendida tiende a cero, a partir de determinado umbral el fabricante hacía un pingüe negocio. El implantador lo que tenía que vigilar es que todas las horas empleadas en servicio al cliente fuesen facturadas con un margen suficientemente amplio.

Para cambiar la facturación en concepto de licencias más servicios por una cuota fija mensual hay que ser muy cuidadoso en la estimación de costes de producción y soporte. El software como servicio es un cambio en el modelo de distribución, no un cambio en la forma esencial en que se desarrolla y se mantiene el software. Ciertamente es mucho más eficiente que los clientes compartan una única granja de servidores —todos con el mismo software— en vez de tener cada uno copias del software en sus respectivos servidores. Pero en SaaS B2B el mantenimiento evolutivo a medida hay que seguir haciéndolo igualmente.

Estructura de servicios EULA vs SaaS Ahora el departamento de desarrollo ya no hace sólo desarrollo siguiendo un roadmap de ciclo largo, sino que se gestiona con sprints de dos semanas en los que se tiene tendencia a mezclar todo: corrección de bugs, cambios solicitados por los clientes y nuevas funcionalidades.

Las herramientas para hacer Scrum, como JIRA, no son en general muy buenas para llevar la contabilidad de costes. El esfuerzo por tarea se mide en una unidad llamada story point que, básicamente, no se puede mapear directamente con ningún coste interno del proveedor. Es posible imputar horas a cada tarea y asignar las tareas a clientes. Pero si no se diseñan bien los informes desde el principio es facilísimo perder la cuenta del esfuerzo que se está empleando en cada cliente.

Debe contabilizarse, además, el tiempo que emplea en devops cada desarrollador en función de su experiencia. Idealmente cuando más senior es un desarrollador menos tiempo debería pasar haciendo devops en favor de más tiempo pensando en arquitectura y mejora de procesos. Que es lo contrario de la tendencia natural a que los programadores senior reciban más tickets de soporte (porque supuestamente los resuelven antes) y la innovación queda en manos de los junior.

Otro efecto secundario de las devops SaaS es que existe una tendencia a reemplazar al gerente de cuenta por la nueva figura del lead developer. Los gerentes de cuenta son la segunda especie más odiada por los programadores después de los jefes miganillas. Interrumpiendo a lo largo de todo el día con asuntos (de poca monta) del cliente, los gerentes de cuenta no dejan al pobre programador concentrarse en las cosas importantes para la evolución del producto. Los gerentes pasan largas horas al teléfono y, aparentemente, añaden poco valor simplemente moviendo información de un lado para otro como bedeles de los clientes y los programadores. La solución ha sido en algunos casos eliminar de un plumazo a los gerentes. Entonces lo que sucede es que los lead developeres ganan cuota de poder, a fin de cuentas se supone que son ellos los que conocen la forma óptima de hacer el mantenimiento evolutivo. Pero resulta que, históricamente, los desarrolladores han sido por lo general pésimos comerciales. Los gerentes tienen, por último, una ventaja inesperada: dado que no son capaces de hablar en un lenguaje tan técnico como los desarrolladores, ni conocen tan a fondo el producto, con frecuencia pueden elaborar explicaciones que están más próximas a lo que el cliente entiende. Es decir, si el programador se lo explicó al gerente de cuenta y este lo entendió, entonces existe una probabilidad mayor de que el cliente lo entienda si se lo explica a su vez el gerente que si se lo explica directamente el programador.

Como conclusión, daré el siguiente conjunto de recetas para evitar un modelo de negocio SaaS defectuoso en su relación entre ingresos y costes:

1. Antes de empezar, definir cómo se van a repartir los costes de desarrollo entre los clientes y cómo se va a contabilizar el esfuerzo empleado en adquiri y mantener a cada cliente.

2. En la medida de lo posible, seguir asignando siempre el mismo gerente de cuenta y siempre el mismo desarrollador a cada cliente.

3. Asignar el mínimo de clientes a cada desarrollador para reducir al mínimo el trabajo en curso (WIP).

4. Hacer a los programadores conscientes de la relación entre ingresos y costes de un cliente. Asignar ratios de rentabilidad por cuenta y vigilar constantemente que no estén siendo rebasados.

5. Mantener un registro único y compartido de toda la información para cada cliente, incluyendo un backlog de todos los cambios hechos a medida y documentación detallada sobre sus singularidades técnicas y funcionales.

Posts relacionados:
El cash flow del software como servicio es horrible.
El calvario del software como servicio.

Compartir:
  • Twitter
  • Meneame
  • Facebook
  • Google Buzz
Esta entrada fue publicada en Casos Prácticos, Modelos de Negocio, Organizando la Comunidad. Modelos de Desarrollo. Guarda el enlace permanente.

Una respuesta a Contabilidad analítica en SaaS B2B

  1. Emilio dijo:

    Hola Sergio,

    Justo este es uno de los problema que estábamos analizando como gestionarlo. Nuestro SaaS esta mas orientado a pequeñas empresas, pero a pesar de eso, en algunos casos tenemos que ajustarlo un poco para algunos clientes.

    Finalmente hemos encontrado la forma de gestionarlo en el modulo de seguimiento económico de proyectos que tenemos en nuestro propio producto.

    Saludos.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *