Modelo de Gestión de servicios

Nuestro enfoque

Nuestro modelo de gestión de servicios de tecnologías de la información (ITSM) se enfoca en la facilidad de uso, la colaboración y el intercambio de conocimientos, para que los equipos de TI puedan ganar eficiencia, mantenerse ágiles y enfocarse en brindar valor.


Bienvenido a un nuevo mundo. A medida que el rol de lo digital aumenta en todas las empresas, la mayoría de los servicios de hoy en día están habilitados por TI. Lo que es aún más emocionante es que los equipos de TI se sientan en el centro de esta transformación. Desde la computación en la nube hasta blockchain, robótica, IA e IoT, las nuevas tecnologías se han disparado en la última década. Han servido como catalizador para nuevas formas de trabajar, lideradas por profesionales ágiles (Agile), lean y DevOps.


En Any2cloud nos adaptamos a enfoques más ágiles que valoran la facilidad de uso, la colaboración y el intercambio de conocimientos por encima de flujos de trabajo complejos e inflexibles.


Para lograr enfrentar estos grandes desafíos hemos incorporamos a ITIL (Information Technology Infrastructure Library) como nuestra guía de buenas prácticas para la gestión de servicios de tecnologías de la información (ITSM), así como una gamma de metodologías y marcos de trabajo que nos ayudan a fortalecer nuestro modelo de gestión de servicios.


Entre algunas de las metodologías y marcos de trabajo que aplicamos, según sea el caso, se encuentran:

• Scrum

• PMP

• Lean

• Kanban • Six Sigma

• DevOps

• Design Thinking

• ITIL 4

Prestación de servicios

Si bien los equipos de TI han utilizado tradicionalmente el modelo Waterfall de fases secuenciales fijas, muchos equipos están cambiando a una gestión de proyectos ágil. En lugar de una sola versión de alto riesgo, estos equipos ponen el valor en el centro y dividen el trabajo en incrementos e iteraciones más pequeños. Están abiertos a cambios y requisitos en evolución basados en comentarios y pruebas. También se dan cuenta de los beneficios del aprendizaje continuo a partir de tiempos de ciclo más cortos.


En Any2Cloud hemos adoptado un modelo híbrido de gestión de proyectos, llamado “Diagrama de Gantt Ágil”, que brinda a los equipos de trabajo una forma simple y visual de realizar el seguimiento de las tareas a lo largo del ciclo de vida de un proyecto. 


Con este modelo lograremos:


• Visibilidad de las actividades, hitos, fechas y compromisos a entregar.

• Gestión del proyecto mostrando el progreso, avances de resultados, bloqueos y desviaciones.

• Desarrollar sinergia entre los equipos de trabajo 

• Creamos un ciclo de retroalimentación corto y rápido.

• Encontrar resultados muy rápido


Gestión de cambios

Dado que los servicios son dinámicos o entes vivos es necesario contar con un proceso de gestión de gestión de los cambios eficiente y adaptable. En este entorno dinámico, brindar una experiencia superior a nuestros clientes es un diferenciador clave, y se vuelve fundamental para el éxito. Se trata de equilibrar el riesgo con moverse rápido. 


A continuación, nuestro proceso lógico de gestión de cambios que debe ser solicitado a través de nuestros canales de contacto de soporte, listados en la sección de: Servicios de Soporte.





Todo este proceso es solicitado desde nuestra plataforma de soporte.


Any2cloud cuenta con el paquete de horas de servicios, que posibilita la rápida, práctica y controlada forma de solicitar y contratar los servicios para solicitudes de cambios a proyectos activos. Entendiendo por solicitud de cambio, a cualquier actividad que este fuera del alcance del proyecto original.


Nombre del Plan

Cantidad de Horas

Precio Total US$

Plazo de vigencia

SC Básico

10

$900

12 meses

SC Medio

20

$1,700

12 meses

SC Avanzado

30

$2,450

12 meses

Servicios de Soporte

La forma de dar soporte y atención ha cambiado para siempre debido que los clientes ahora exigen la misma velocidad y facilidad de soporte de las corporaciones más grandes como Netflix y Amazon. Hasta ayer el contacto principal con el soporte de TI suele ser el correo electrónico, y la capacidad de autoservicio no se encuentra en ninguna parte. En el backend, los equipos de TI se esfuerzan por configurar un catálogo de solicitudes de servicio y mantener actualizada una base de conocimientos.


En Any2cloud entendimos este gran desafío de poder conectar la necesidad, la urgencia, el nivel de servicios, la facilidad y la conexión de los equipos de trabajo, todo esto en un solo modelo. Por lo que diseñamos un modelo de atención Omnicanal (WhatsApp, Facebook Messenger, WebChat, etc) y autoservicio para ofrecer más valor, al tiempo que ofrece facilidad de acceso a canales instantáneos por encima del tradicional correo electrónico.



Modelo de Servicio de Soporte



Los canales de contactos disponibles para servicio técnico son:


1. WhatsApp: https://wa.me/+50663036361

2. Facebook Messenger: https://m.me/any2cloud 

3. Instagram: https://www.instagram.com/direct/inbox/

4. Web: https://www.any2cloud.com

5. Email: soporte@any2cloud.com



Niveles de soporte (SLAs)

Los SLA (Acuerdos de nivel de servicio) definen los términos acordados para los servicios y gestionan las expectativas de nuestros clientes. Hemos diseñado una estructura de SLAs escalables y alineados con las exigencias de su negocio.


Contamos con tres (3) modelos de soporte, los cuales son:


1. Soporte Estándar

2. Soporte Avanzado

3. Soporte Premium


Soporte Estándar:

Prioridad

Tiempo de respuesta (tras recibir la solicitud o ticket)

Clasificación

Alta

Dentro un plazo de ocho (8) horas de recibida la solicitud para soporte

*horario hábil

Requerimientos que afectan la continuidad del negocio; disrupción de servicios, falla mayor.

Media

Dentro un plazo de doce (12) horas de recibida la solicitud para soporte

*horario hábil

Requerimientos que sin una acción pronta pueden llevar a una falla mayor en los servicios o sistemas asociados.

Normal

Dentro de un plazo de veinticuatro (24) horas recibidas la solicitud para soporte o según disponibilidad de técnicos.

*horario hábil

Requerimientos comunes o cambios en configuraciones sin afectar servicios.


• Horarios: Lunes a Viernes de 8 a 17 horas. No se incluyen días festivos o asuetos.

• Modalidad: soporte remoto.

• Valor agregado: Incluye mantenimientos preventivos y préstamo de equipos ante la necesidad de un reemplazo por fallas *sujeto a disponibilidad y tipo de equipo, consulte a su asesor de ventas.

• Cantidad de incidencias:  Ilimitada

• Limitaciones: perímetro de la ciudad capital. Interior de la capital u otros países quedan sujetos a evaluación y se notificará de los mismos por correo o teléfono.

• Restricciones: NO se contemplan o categorizan en prioridad Media o Alta las tareas de mantenimiento, implementaciones o desarrollo de funciones; se contemplan únicamente las tareas relacionadas a fallas directas.

• Horas de soporte en sitio:  Se facturan por separado bajo precio regular



Soporte Avanzado:

Prioridad

Tiempo de respuesta (tras recibir la solicitud o ticket)

Clasificación

Alta

Dentro un plazo de seis (6) horas de recibida la solicitud para soporte

*horario hábil

Requerimientos que afectan la continuidad del negocio; disrupción de servicios, falla mayor.

Media

Dentro un plazo de diez (10) horas de recibida la solicitud para soporte

*horario hábil

Requerimientos que sin una acción pronta pueden llevar a una falla mayor en los servicios o sistemas asociados.

Normal

Dentro de un plazo de veinticuatro (24) horas recibidas la solicitud para soporte o según disponibilidad de técnicos.

*horario hábil

Requerimientos comunes o cambios en configuraciones sin afectar servicios.


• Horarios: Lunes a Viernes de 8 a 17 horas. No se incluyen días festivos o asuetos.

• Modalidad: Soporte remoto/sitio.

• Valor agregado: Incluye mantenimientos preventivos y préstamo de equipos ante la necesidad de un reemplazo por fallas *sujeto a disponibilidad y tipo de equipo, consulte a su asesor de ventas.

• Cantidad de incidencias:  Ilimitada

• Limitaciones: Perímetro de la ciudad capital. Interior de la capital u otros países quedan sujetos a evaluación y se notificará de los mismos por correo o teléfono.

• Restricciones: NO se contemplan o categorizan en prioridad Media o Alta las tareas de mantenimiento, implementaciones o desarrollo de funciones; se contemplan únicamente las tareas relacionadas a fallas directas.

• Horas de soporte en sitio:  Se facturan por separado bajo precio regular



Soporte Premium:

Prioridad

Tiempo de respuesta (tras recibir la solicitud o ticket)

Clasificación

Alta

Dentro un plazo de cuatro (4) horas de recibida la solicitud para soporte

*horario hábil

Requerimientos que afectan la continuidad del negocio; disrupción de servicios, falla mayor.

Media

Dentro un plazo de ocho (8) horas de recibida la solicitud para soporte

*horario hábil

Requerimientos que sin una acción pronta pueden llevar a una falla mayor en los servicios o sistemas asociados.

Normal

Dentro de un plazo de veinticuatro (24) horas recibidas la solicitud para soporte.

*horario hábil

Requerimientos comunes o cambios en configuraciones sin afectar servicios.


• Horarios: Lunes a Viernes de 8 a 17 horas y Sábados de 8 a 17 horas sujeto a disponibilidad de los técnicos de guardia. No se incluyen días festivos o asuetos.

• Modalidad: Soporte remoto/sitio.

• Valor agregado: Incluye mantenimientos preventivos y préstamo de equipos ante la necesidad de un reemplazo por fallas *sujeto a disponibilidad y tipo de equipo, consulte a su asesor de ventas.

• Cantidad de incidencias:  Ilimitada

• Limitaciones: Perímetro de la ciudad capital. Interior de la capital u otros países quedan sujetos a evaluación y se notificará de los mismos por correo o teléfono.

• Restricciones: NO se contemplan o categorizan en prioridad Media o Alta las tareas de mantenimiento, implementaciones o desarrollo de funciones; se contemplan únicamente las tareas relacionadas a fallas directas.

• Horas de soporte en sitio:  Se facturan por separado bajo precio regular


Disponibilidad y resiliencia de la infraestructura

Todos nuestros desarrollos de software reposan en la infraestructura de Amazon Web Services (AWS) que comúnmente cuenta con requerimientos de nivel de servicio o Service Level Agreement (SLA) de hasta 99.9% de disponibilidad, esto indica que el sistema que estamos diseñando no deberá superar más de 52.56 minutos fuera de línea en 365 días. O por ejemplo un SLA de 99.99% de durabilidad nos indica que por un giga-byte (GB) de información no deberíamos superar la perdida de información por más de 100 bytes.


En términos de recuperación de desastres tenemos dos métricas principales: Recovery Point Objective u Objetivo de Punto de Recuperación, el cual nos indica cuánto tiempo puede existir en términos de perdida de información, por ejemplo, un RPO de una hora indica que si el sistema falló a las 12:00 pm, debemos poder contar con todos los cambios de información generados hasta las 11:00 am, es decir, debemos contar con los mecanismos necesarios para capturar ese cambio de información y resguardarlo en una localidad secundaria. El Objetivo de Tiempo de Recuperación o Recovery Time Objective indica cuánto tiempo el sistema puede estar fuera de línea, por ejemplo, si el RTO es 1hr y el sistema falla a las 12:00 pm, el sistema debe contar con su funcionalidad al 100% a la 1:00 pm.


Cuando diseñamos una arquitectura de software inicialmente nos enfocamos en los requerimientos funcionales, es decir, que es lo que nuestro sistema debe resolver. Una vez que tenemos esta arquitectura es necesario garantizar nuestros atributos de calidad, como son los niveles de servicio (SLAs). Utilizando nuestro AWS Well Architected Framework, específicamente el pilar de Confiabilidad (Reliability) podemos enriquecer nuestra arquitectura para alcanzar SLAs específicos.


Para la mayoría de nuestros desarrollos logramos alcanzar el siguiente SLA:





La infraestructura de AWS está distribuida geográficamente en regiones, estas regiones se encuentran aisladas unas de otras, tanto de forma geográfica como en software. Es decir, si existe algún desastre natural las regiones están lo suficientemente alejadas y aisladas para no verse afectadas al mismo tiempo y los servicios son desplegados de forma independiente en cada una de estas regiones.


Dentro de una región de AWS contamos con diferentes zonas de disponibilidad, estas zonas de disponibilidad se encuentran a una distancia que permita latencias de 1ms, cuentan con sistemas redundantes y existe una distancia entre ellas que permita reducir el riesgo de un evento natural que pueda afectar a más de una zona de disponibilidad.