¿Cuáles son buenas formas de garantizar la continuidad del negocio con un producto SaaS?

Question

Para mi tesis de licenciatura, estoy investigando cómo los proveedores de SaaS pueden organizar algún tipo de garantía de continuidad del negocio.

Probablemente conozca los arreglos de fideicomiso de código fuente para el software 'shrink-wrapped'. Brindan a los clientes acceso al código fuente y toda la documentación aplicable siempre que el proveedor del software se mete en problemas (financieros). Claramente, esto no funciona para SaaS, porque los clientes no tienen ningún uso para el código fuente, y los clientes probablemente no pueden permitirse el lujo de no poder iniciar sesión en su sistema CRM durante un par de semanas porque el proveedor de SaaS se declaró en quiebra. Actualmente estoy investigando diferentes métodos para resolver este problema.

¿Conoce a soluciones buenas y prácticas para resolver este problema de continuidad? ¿O empresas que ya ofrecen una buena solución?

Gracias!

Answer 1

Bueno, hacemos SaaS pero no estoy seguro de que la administración haya pensado en la continuidad. Creo que la situación más común es que un proveedor de SaaS limita sus servicios y responsabilidades por contrato para que ni siquiera tengan que pensar en ello.

Como una posible solución: la empresa puede acordar por contrato proporcionar cierto esfuerzo para migrar los datos a un sistema de software alternativo de elección del cliente en caso de que cierre su funcionamiento. A falta de eso, apenas hay nada que esperar.

Como una opción muy calva: dar a la base de datos de copia de seguridad al cliente que empleará a consultores o hacer pedazos fuera de él. Pero es más bien un caso de emergencia.

Answer 2

Supongo que siempre puede diseñar su sistema para que, en caso de que su empresa esté a punto de hundirse, pueda proporcionarles a los clientes suficiente software del lado del servidor, archivos de configuración y datos que puedan alojar su propia versión de su servicio . Esencialmente, ofrézcales o véndales una imagen de su sistema para que alojen (ya sea internamente o paguen a alguien más) el tiempo suficiente para pasar a un nuevo sistema. Si ejecuta todo el software del lado del servidor dentro de una máquina virtual, esto puede hacer que sea más fácil (en esencia) otorgarle al cliente su servidor. Incluso puede organizar que la imagen de VM se transfiera directamente a un proveedor de hosting de terceros (y pagar por adelantado el tiempo suficiente para cumplir con el resto del contrato actual del cliente) si su empresa está a punto de cerrar.

Answer 3

La disponibilidad del servicio siempre es algo que se debe tener en cuenta al subcontratar algo, ya sea desarrollo, catering o hosting (¿qué harías si ejecutaras una fábrica y tu proveedor de servicios fallara, dejando el restaurante de tu empresa sin personal?)

En el caso del software, código de depósito en garantía es un paso para asegurar la mínima interrupción (incluso si no, por supuesto, siempre habrá alguna interrupción).

Tener un contrato con un proveedor de alojamiento de copia de seguridad, donde la aplicación se implementa en modo de espera en frío con la sincronización de base de datos normal a veces puede ser una opción. Para las aplicaciones que requieren un alto tiempo de actividad (que supongo que es el caso aquí, ya que puede aceptar incluso unos días de inactividad) eso es una necesidad de todos modos. Después de todo, el proveedor de SAAS no puede declararse en quiebra, pero si una aeronave se bloquea en el edificio que aloja su granja de servidores, su aplicación también se verá interrumpida (trabajé para un proveedor de SAAS y tuvimos nuestras propias granjas de servidores de respaldo en varios ubicaciones para garantizar la continuidad del servicio, además de volcados de código regulares enviados a un servicio de custodia y enviados a almacenamiento en una ubicación segura para tener copias de seguridad fuera del sitio, no hay razón por la que un cliente no quiera tener también su propia copia de seguridad en frío, o al menos una opción de contrato para hacerse cargo del contrato de alojamiento en caso de interrupción del servicio debido a la quiebra del titular actual del contrato).

Answer 4

Como un pequeño proveedor de SaaS, los posibles clientes nos hacen esta pregunta. Lo tratamos haciendo que nuestro producto sea de código abierto. Puede que esta no sea una opción adecuada para muchos, pero fue lo mejor para nosotros.

Answer 5

Como cliente de SaaS, dependo mucho de servicios como la facturación, el correo electrónico y el seguimiento de errores de software. Hasta que respondí esta pregunta, no lo había pensado mucho: puedo abandonar el contrato en cualquier momento, ¿por qué no? Por otro lado: mis datos deben estar seguros. He preguntado a mis proveedores (no esperaba una respuesta pronto de gmail :-) y mientras tanto tomé medidas para hacer copias de seguridad con frecuencia.

Miedo: ninguno de mis proveedores realmente explica lo que sucede en detalle en sus términos de servicio. ¿Dónde debería esperar tal información? ¿Dónde colocaría un desarrollador ese texto?

Answer 6

Con respecto a este problema, una posible manera de manejarlo es darse cuenta de que, si bien tengo que hacer negocios con la compañía X para una pieza de software, es mis datos que reside en almacén de datos de ese software. Ergo, se me debe proporcionar una copia (en XML o en cualquier formato acordado). De esa forma, si la empresa deja de funcionar, simplemente necesito la última copia de mis datos, y puedo llevarla a otro lado.

Después de haber trabajado en la industria de SaaS, sé que muchas empresas tienen diferentes formas de guardar datos de usuario, pero también conocen a sus competidores y desean que las empresas les faciliten la carga de datos. .

Answer 7

Buena pregunta. En una empresa de SaaS para la que trabajé, formaba parte de un equipo que desarrolló un conjunto de herramientas para uso interno del equipo de alojamiento para implementar rápidamente la instalación de un cliente. Desplegar a un cliente era un procedimiento complicado que involucraba sitios de prueba/producción con 7-10 servidores cada uno. También contamos con procedimientos para realizar copias de seguridad nocturnas de los datos de los clientes.

Supongo que las herramientas que desarrollamos para uso interno podrían haber sido productivas para el propósito que usted describe, y estas herramientas junto con los datos del cliente podrían permitirles hacerse cargo del producto. El conjunto de herramientas era lo suficientemente flexible como para permitir al cliente volver a implementar sus datos en una configuración de servidor diferente. Por ejemplo, en una emergencia podrían implementar una aplicación que se había ejecutado en 8 servidores en una configuración de 2 servidores, y una vez que tuvieran su centro de datos configurado, volver a implementarlo nuevamente a la configuración de servidor 8 más eficiente.

Answer 8

creo que es necesario distinguir dos casos:

1. Un proveedor de SaaS es el suministro de un servicio cuasi-genérica. Es concebible que los datos puedan ser transferidos a un proveedor alternativo, y un proveedor podría prometer que los datos estarán disponibles en una forma que pueda ser utilizada por ese proveedor.
2. Un proveedor de SaaS que ofrece un servicio único. No hay otra alternativa práctica al proveedor que no sea crear su propio centro de datos. Para cuando haya hecho esto, es posible que ya no esté en el negocio.

La pregunta que hace normalmente aparece en el contexto de una compañía que considera usar servicios de SaaS. En estos casos, una empresa prudente (como parte de su plan de continuidad comercial) necesita (a) asegurarse de la viabilidad financiera del proveedor (es interesante que la mayoría de las personas que responden a esta pregunta lo consideren como el principal riesgo), y (b) asegurar que el proveedor tenga un plan de continuidad comercial adecuado que garantice los servicios en caso de que se produzcan todos los riesgos importantes. (Por ejemplo, si un centro de datos tiene un incendio y tiene que cerrarse temporalmente, ¿hay una alternativa? ¿Está en espera activa? ¿Se duplican los datos? ¿Cuántos datos se pueden perder? ¿Se puede redirigir el tráfico de la red? .)

Por supuesto, el cliente también tiene que preocuparse por los problemas de conectividad de red: el proveedor puede estar en el negocio pero inalcanzable. Y (en casos transfronterizos), political and regulatory risks.

Las preocupaciones para un proveedor de SaaS en realidad no son tan diferentes de cualquier otro proveedor de servicios o productos críticos subcontratados. (Si ha ensamblado bridas personalizadas y arandelas personalizadas para producir artilugios, tendrá problemas si su proveedor no puede suministrarle sus bridas por el motivo que sea).

Interesantemente una preocupación para un proveedor de SaaS con algunas grandes clientes es la viabilidad financiera y la continuidad del negocio de sus clientes. El fracaso de un minorista importante a veces resulta en la falla de sus proveedores: no solo los proveedores quedan con grandes deudas no aseguradas, sino que carecen de una parte importante de su cadena de distribución.

Jan Husdal escribe un interesante blog on issues of supply chain business continuity, aunque no creo que haya cubierto específicamente los problemas de SaaS.

Un indicador a tener en cuenta para el futuro puede ser el requisito de que un proveedor tenga un plan de continuidad del negocio auditado con un estándar reconocido (por ejemplo, BS-25999). Es posible que veamos que los estándares de continuidad del negocio se propaguen de la misma manera en que se propagaron las normas ISO-9000, ya que cada empresa rechaza los requisitos de certificación para sus proveedores críticos.

Buena suerte con su tesis. Has elegido un tema interesante. También es posible que desee hacer su pregunta en el Disaster Recovery Journal group on LinkedIn. Es la única área de debate realmente activa sobre problemas de continuidad del negocio que he encontrado.