Blogs

7 factores que afectan el TCO de RPA en la nube

Su empresa está considerando una implementación en la nube de Robotic Process Automation (RPA). Buena elección. RPA en la nube ofrece muchos beneficios potenciales, incluido el ahorro de costos en gastos de capital, la capacidad de escalar fácilmente, una mayor productividad y eficiencia, y más.

Entonces, ¿cuánto costará aprovechar la RPA en la nube? Para obtener una imagen precisa, debe mirar más allá del precio de licencia de una plataforma RPA y los costos de infraestructura. La imagen a continuación le da una idea sobre los componentes del costo y cuánto afectan el costo total de propiedad (TCO) para una implementación de RPA en la nube.
Estos son los factores a considerar:

# 1 Asesoramiento y consultoría
Este factor incluye el costo de seleccionar un proveedor de RPA adecuado junto con el estudio de los procesos regulares en la empresa para encontrar los que merezcan la automatización. Si está contratando a un proveedor de servicios externo para el trabajo, considere la cantidad que pagaría por los consultores. Para un modelo de centro de excelencia, se incluiría el tiempo y esfuerzo invertido por las pymes y los analistas en identificar oportunidades de proceso. Una empresa podría ahorrar en este costo automatizando el descubrimiento de procesos , lo que también podría hacer que las implementaciones sean más rápidas y precisas.

# 2 Licencias
Este factor incluye los gastos incurridos para comprar los componentes centrales de la solución RPA, como el orquestador, el diseñador y los Bot Runners. Además, considere el costo de agregar un componente de alta disponibilidad / recuperación ante desastres para ayudar a garantizar la continuidad del negocio. Podría integrarse con la solución RPA en una implementación en la nube.

# 3 Configuración de infraestructura
Calcule el costo de configurar el sistema, incluidos los equipos de escritorio, los servidores y las máquinas virtuales. El tipo de implementación tendrá un gran efecto en este costo. Si una empresa opta por la implementación en la nube, podría ahorrar en gastos de capital, como hardware. También debe considerar el sistema operativo que admite su proveedor de RPA. Si solo es compatible con Windows y sus máquinas existentes se ejecutan en MAC o Linux, calcule el costo de realizar un cambio a Windows.

# 4 Desarrollo e implementación
Este factor se refiere a los costos asociados con el desarrollo, la configuración y el traslado de los bots de software desde la concepción hasta la producción. El costo varía según cómo se realice el desarrollo. Por ejemplo, tener un recurso de desarrollo interno podría costar menos que contratar a un proveedor de servicios externo. Si una plataforma de desarrollo viene con características fáciles de usar, como una interfaz de usuario fácil de arrastrar y soltar, el recurso interno podría incluir usuarios comerciales transformados en desarrolladores ciudadanos .

Considere la facilidad con la que la solución se puede integrar con sus aplicaciones existentes. ¿Es necesario configurar la integración o la solución está lista para usar? ¿Puedes reutilizar los bots y los fragmentos de código? Estos puntos pueden marcar una gran diferencia en el tiempo de desarrollo y los costos relacionados.

# 5 Complementos
Todos los demás componentes necesarios para complementar su proyecto de automatización se incluirán en esta categoría. Dependiendo del requisito del proyecto, puede variar desde una solución de procesamiento de documentos inteligente , una plataforma de análisis (para realizar un seguimiento de los bots, el rendimiento y el ROI) y una herramienta de descubrimiento de procesos. Considere la cantidad de proveedores con los que está tratando aquí porque si sus soluciones aún no están integradas, es posible que deba gastar más en implementación y mantenimiento.

# 6 Entrenamiento
Si una empresa opta por la automatización, los empleados deben recibir formación sobre esa solución específica. Por lo tanto, la disponibilidad de sesiones de capacitación en línea ( seminarios web, materiales a pedido o plataformas de capacitación de proveedores) y la documentación del proveedor facilitarían la capacitación. También ayuda si la solución es intuitiva y solo requiere un conocimiento técnico mínimo para operar. Entonces, los usuarios comerciales pueden adquirirlo más rápido.

# 7 Mantenimiento y soporte
La solución debe ejecutarse con un mantenimiento mínimo. TI no debería dedicar mucho tiempo a la instalación y actualización. Una solución basada en navegador facilitará el trabajo de TI, especialmente en este mundo pospandémico donde trabajar desde casa es la norma. Pero como cualquier otro producto de TI, su solución RPA puede necesitar soporte ocasional. La disponibilidad y el costo del soporte de su proveedor o proveedor de servicios sería algo para revisar antes de finalizar su solución.

Al comprender el TCO de su implementación de RPA, puede seleccionar el mejor proveedor para respaldar su viaje y concentrarse en lo más importante: aprovechar esos beneficios de RPA.

Read More
Blogs

La seguridad multicapa que requiere la RPA como servicio

Es posible que la seguridad no sea lo primero que se le ocurra cuando se piensa en la automatización robótica de procesos (RPA) . Sin embargo, ha sido durante mucho tiempo la piedra angular de las principales plataformas de RPA porque los procesos que RPA automatiza acceden de manera rutinaria a numerosas aplicaciones comerciales, atraviesan multitud de dispositivos de la empresa y manejan grandes volúmenes de datos que impulsan los flujos de trabajo comerciales. Y eso es solo RPA local.

Hoy en día, a medida que las empresas se trasladan a la nube, crece el interés en RPA-as-a-Service, que ofrece la funcionalidad de RPA en la nube, totalmente alojada y administrada por el proveedor de RPA. Esto agrega la seguridad en la nube como otra consideración importante cuando las empresas están evaluando a los proveedores de RPA como servicio.

Aquí hay 12 estándares de seguridad que debe buscar en plataformas RPA como servicio o RPA nativas de la nube.

1. Certificación ISO 27001
Para obtener una certificación ISO 27001, un proveedor de RPA debe demostrar el pleno cumplimiento de los estándares de confidencialidad, integridad y disponibilidad para los activos de información relacionados con su servicio en la nube. Esta línea de base para las prácticas de seguridad de TI fue creada por la Organización Internacional de Normalización (ISO) y es una certificación reconocida internacionalmente para medir la seguridad de los sistemas de seguridad de la información.

Para lograr esta certificación, los proveedores de RPA como servicio deben completar con éxito una auditoría integral e independiente de sus controles técnicos y políticas de seguridad de TI. Más importante aún, el nivel de seguridad que asegura esta credencial puede aumentar el valor que las empresas obtienen de RPA-as-a-Service al permitirles automatizar procesos sin preocuparse de que sus datos confidenciales se pongan en riesgo.

Al evaluar una solución en la nube RPA, la certificación ISO 27001 debe ser una de las primeras cosas que debe solicitar.

2. Certificación SOC 2 Tipo 1
Creado por el Instituto Estadounidense de Contadores Públicos Certificados (AICPA), la certificación de Controles de Sistemas y Organización (SOC) 2 Tipo 1 mide los controles de seguridad de TI basados ​​en cinco principios:

Disponibilidad : Atestigua que una solución RPA-as-a-Service está disponible para usarse según lo acordado en el contrato con un cliente.
Confidencialidad : Si un servicio de RPA-as-a-Service maneja datos sensibles, como información financiera o propiedad intelectual (IP), debe presentar cómo usa, accede y protege esa información en el informe SOC 2 para el auditor.
Integridad de procesamiento : se utiliza para determinar si el proveedor de RPA como servicio entrega datos completos, válidos, precisos y autorizados de manera oportuna.
Seguridad : aborda si el producto RPA-as-a-Service protege a los clientes contra el acceso no autorizado mediante controles de acceso adecuados.
Privacidad : este principio se refiere a cómo el proveedor de RPA recopila y usa información personal, como información de identificación personal (PII), tanto en lo que se refiere al aviso de privacidad del proveedor como a los principios de privacidad generalmente aceptados de AICPA. La PII incluye cosas como el nombre, la dirección, el número de teléfono y el número de seguro social de una persona.
La certificación SOC 2 es emitida por auditores externos. Evalúan hasta qué punto un proveedor cumple con uno o más de estos principios en función de los sistemas y procesos que tienen implementados. El informe SOC 2 Tipo 1 ofrece a los clientes potenciales la tranquilidad de saber que un proveedor de RPA como servicio ha pasado una auditoría y que sus datos estarán seguros. Los informes SOC 2 son únicos para cada organización. Cada proveedor de RPA-as-a-Service diseña sus propios controles para cumplir con uno o más de los principios de confianza.

3. Certificación SOC 2 Tipo 2
Si bien el SOC 2 Tipo 1 describe los sistemas de un proveedor de RPA como servicio y aborda si cumple con los principios de confianza en una fecha específica, el SOC 2 Tipo 2 informa los resultados de una auditoría que ha evaluado la efectividad operativa de una RPA. sistemas del proveedor durante un período de tiempo específico, por ejemplo, un año.

Estos informes internos brindan a los clientes y prospectos información crítica sobre cómo un proveedor de RPA como servicio administra los datos.

4. Certificación SOC 1 Tipo 2
La auditoría SOC 1 Tipo 2 es una certificación semestral que les dice a los clientes y clientes potenciales que un proveedor de RPA como servicio tiene implementados los controles y procesos internos adecuados con respecto a la seguridad y disponibilidad para garantizar que los datos del cliente se mantengan seguros.

SOC 1 es más apropiado para empresas que deben cumplir con las regulaciones de informes financieros como Sarbanes-Oxley (SOX). Otras regulaciones federales, como Gramm-Leach-Bliley (GLBA) y la Ley de Responsabilidad y Rentabilidad de Seguros de Salud ( HIPAA ), requieren que las corporaciones auditen los controles internos de sus proveedores, incluidos aquellos que brindan servicios de tecnología como RPA-as-a -Servicio. Los controles que se auditan incluyen pero no se limitan a:

Seguridad de información
Seguridad física
Acceso lógico
Monitoreo de red
Gestión de configuración
Gestión de vulnerabilidades
Copia de seguridad y restaurar
Administracion de incidentes
Desarrollo de aplicaciones

5. Certificación ISO 22301
La estabilidad y resistencia de su proveedor de RPA deben ser una consideración, especialmente cuando está invirtiendo en RPA-as-a-Service. Más allá del servicio en la nube que ofrece su proveedor de RPA, ¿qué sucede si ocurre un desastre y los sistemas fallan? La certificación ISO 22301: 2019 “Seguridad y resiliencia – Sistemas de gestión de la continuidad del negocio” cubre qué tan bien una empresa está preparada para responder y recuperarse en caso de una emergencia o desastre. La RPA se implementa a menudo en procesos críticos para el negocio, y el proveedor de RPA como servicio debe tener un plan de continuidad empresarial claro para que sus clientes no se vean afectados.

6. Estándares industriales validados
Varias industrias tienen estándares para garantizar que las plataformas RPA-as-a-Service le brinden controles de seguridad que se pueden usar en los casos de uso más sensibles. Por ejemplo, la Ley Federal de Administración de Seguridad de la Información (FISMA) requiere que las agencias federales implementen planes de seguridad de la información para proteger los datos sensibles.

Los estándares de la industria admiten controles como la autenticación centralizada (directorio activo), la gestión centralizada de registros, las capacidades de análisis y generación de informes a través de la gestión de eventos e información de seguridad (SIEM), y la partición de la red y el control de acceso a la red a través de las redes de área local virtual (VLAN). También auditan para verificar que los firewalls estén instalados e integrados con RPA-as-a-Service cuando sea apropiado.

7. Integración con marcos de autenticación reconocidos por la industria
Cuando se trata de autenticación y administración de identidad (AIM), las organizaciones deben pensar en la seguridad en dos frentes: sus usuarios humanos que acceden a la plataforma RPA-as-a-Service y los bots que también interactúan con la plataforma y con las aplicaciones empresariales. Debido a esto, es imperativo que las plataformas RPA-as-a-Service puedan integrarse sin problemas con los sistemas de seguridad empresarial.

Dado que el inicio de sesión único (SSO) es una forma común para que las empresas mejoren la seguridad, las plataformas RPA como servicio deben ser interoperables con SSO mediante el lenguaje de marcado de aserción de seguridad (SAML 2.0). Las organizaciones también deben considerar si RPA-as-a-Service puede integrarse de forma segura con Microsoft Active Directory y el soporte Kerberos estándar de la industria.

8. Accesibilidad solo para personas y dispositivos autorizados
La autenticación exitosa es el primer nivel para hacer cumplir el control de acceso. Igualmente importante es la autorización de acceso, que se adhiere al principio de privilegio mínimo. Este principio significa que los usuarios comienzan con la menor cantidad de acceso que necesitan y, con frecuencia, ningún acceso. Luego, el administrador debe proporcionar explícitamente acceso a las características y funcionalidades de cada tipo de rol utilizando role-RBAC para asegurar una clara separación de tareas.

Muchas empresas tienen aplicaciones comerciales alojadas tanto en las instalaciones como en la nube con las que los empleados y los bots deben interactuar. Los procesos automatizados pueden requerir iniciar sesión en aplicaciones empresariales como Salesforce, SAP HANA u Oracle DB. El uso de casilleros para almacenar credenciales y datos confidenciales evita las filtraciones o exposiciones de datos porque los bots solo acceden a lo que necesitan para un proceso determinado. Si se utilizan casilleros, no es necesario codificar la información de las credenciales dentro del bot.

Tener una bóveda de credenciales es una parte importante de una plataforma RPA-as-a-Service. Cuando se integra de forma nativa dentro del sistema, las organizaciones pueden configurar inmediatamente el acceso a sus aplicaciones empresariales. Se debe incluir soporte para la integración de bóvedas, casilleros y claves de credenciales de terceros, como CyberArk y Azure Key Vault, para cumplir con las políticas de la empresa sobre el acceso seguro a las aplicaciones.

9. Protección de datos
Los datos deben protegerse durante la transmisión entre la red de una empresa y el servicio en la nube del proveedor de RPA como servicio, incluso mediante el cifrado de la capa de transporte (TLS) que aprovecha al menos certificados de servidor RSA de 2048 bits y claves de cifrado simétrico de 128 bits. Todos los datos, incluidos los datos del cliente que se transmiten entre centros de datos con fines de replicación, deben estar a través de un enlace cifrado dedicado que utilice cifrado AES-256. Los datos en reposo deben estar en todas las instalaciones de almacenamiento de datos utilizando cifrado asimétrico con claves AES de 256 bits.

También es fundamental adherirse a los estándares de privacidad de datos, como el reglamento general de protección de datos (GDPR). Si bien a nivel regional el nombre de la regulación o directiva de privacidad puede variar, la implementación de controles aceptados a nivel mundial para cumplir con los requisitos de privacidad debe integrarse en la plataforma del proveedor de servicios RPA-as-a-Service.

10. Protección del código
Dado que la RPA a menudo implica la automatización de procesos críticos para el negocio, los proveedores de RPA como servicio deben cumplir con estrictas prácticas de ciclo de vida de desarrollo de software para garantizar que el producto no solo se prueba en busca de debilidades de amenazas o malware, sino que se monitorea continuamente. Se pueden aplicar las mejores prácticas de la industria para garantizar que el código del producto esté protegido. A medida que la RPA se traslada cada vez más a la nube, los proveedores deben tener un equipo de Operaciones de seguridad (SecOps) con una postura de seguridad proactiva y un protocolo de gestión de defensa contra amenazas. Para mayor protección y validación, los proveedores de RPA también pueden integrar herramientas de escaneo y prueba de terceros a lo largo del ciclo de vida del desarrollo del producto, como Veracode Verified Continuous.

11. Auditoría granular
Todas las soluciones de RPA deben incluir amplias capacidades de auditoría, incluido el registro, la supervisión y la generación de informes avanzados. Las soluciones RPA-as-a-Service no son una excepción a esto.

Según Deloitte, hay cinco etapas en una auditoría:

Planificación: obtenga una visión integral de las áreas y procesos comerciales donde se ha implementado RPA.
Tutorial: Comprenda la relación entre el proceso automatizado y la TI, e identifique los riesgos y los controles.
Evaluación del diseño: evalúe el diseño del control, identifique el proceso de manejo de excepciones e identifique cualquier brecha en la seguridad
Efectividad operativa: Realice pruebas sustantivas de todos los controles.
Informes: informe sobre las brechas entre los riesgos y los controles, y haga recomendaciones sobre cómo solucionarlos.
Las principales plataformas de RPA como servicio proporcionan herramientas integradas para hacer estas cosas de forma rápida y sencilla.

12. Equipos dedicados de CloudOps y SecOps
Además de contar con certificaciones, estándares y capacidades de seguridad, los proveedores que ofrecen RPA como servicio deben tener experiencia operativa en la nube y la seguridad dedicada a garantizar que el servicio esté en funcionamiento y protegido contra amenazas de seguridad. Como práctica recomendada, esto involucra a dos equipos especializados, CloudOps y SecOps.

CloudOps (nube + operaciones) se refiere a las mejores prácticas y procedimientos que permiten que las plataformas en la nube, así como las aplicaciones y los datos que residen en ellas, funcionen durante períodos de tiempo prolongados.

SecOps (seguridad + operaciones) implica la colaboración entre los equipos de operaciones y seguridad de TI, donde la tecnología y los procesos, para mantener seguros los sistemas y los datos, están integrados. El objetivo es minimizar el riesgo y mejorar la agilidad empresarial.

Read More