Algunas ‘mejores prácticas’ de TI para el fracaso –y algunas ‘mejores prácticas’ para evitarlo

Así es, una mejor práctica no es una receta de cocina. La preparación que hagamos de un ‘platillo’ y su resultado depende de muchos factores referidos a las herramientas, nosotros mismos como çocineros’, de los ‘comensales’ y su entorno.

Una real mejor práctica es considerar la preparación del ‘platillo’ para garantizar su resultado. Así, intervienen el ecosistema tecnológico en operación –moderno, vigente, legacy, integrado, interconectado- plataforma tecnológica e infraestructura de soporte, la cantidad necesaria de especialistas con el perfil apropiado, la experiencia, competencias (conocimientos, aptitudes, actitudes), orientación técnica o de gestión, requisitos del negocio, apetito de riesgo, intereses personales, los recursos para la producción del servicio (en adición al ecosistema tecnológico y el personal de apoyo, se necesita información, aplicaciones, recursos financieros) y capacidades para asegurar el rendimiento esperado (modelo de gestión, organización implementada, procesos establecidos, conocimiento gestionado), ambos activos de servicio necesarios para entregar el servicio con el valor esperado (con la utilidad y la garantía de rendimiento esperada), aparte claro del presupuesto, coyuntura socio-económica, entorno regulatorio y legal, mercado (cultura, exigencias, demografía, restricciones, gobierno, importación/exportación).

Estamos propensos a decir sí o no a todo y esto varia como buena práctica de acuerdo a la cultura y clima organizacional, buscando no quedar mal –aunque esto es lo que ocurre al no cumplir si accedemos o no entregar si era posible y alguien después nos lo hizo ver.

Una real buena práctica es explicar qué debe hacer para satisfacer las solicitudes, luego de realizar el análisis previo correspondiente. Lo que sigue será una conversación más que una excusa.

Tampoco es una buena práctica blandir que se cumple con el acuerdo de nivel de servicio (SLA) aceptado por el cliente, o con el nivel de servicio organizacional (OLA) requerido y comprometido por las áreas internas de la empresa, cuando es evidente la existencia de reclamaciones al respecto, y tratamos de minimizar el impacto haciendo bromas a costa de clientes, usuarios –o peor, de nuestro soporte- ‘inexperto’. Puede haber un contrato en ambos casos, pero no es bueno mantener las relaciones a distancia.

Una real buena práctica es identificar y enfrentar cambios –incluso sustanciales, investiguemos con transparencia. Recuerde que las relaciones requieren confianza, que la confianza no sucede a menos que reconozca a los colegas y clientes como personas reales que, si les gusta, trabajarán con usted para arreglar lo que falla y que el propósito de los contratos no es definir las relaciones -es definir lo que sucede cuando no hay confianza y algo va seriamente mal.

Tomamos como buena práctica poner nombre a nuestros proyectos, desde hace poco incluso, no siempre ha sido así. Pero esta buena práctica de la dirección de proyectos la utilizamos para nombrar el proyecto como una implementación de software (y nos preocupamos de que el producto software funcione) y no como los resultados esperados por el negocio (no establecemos los requisitos y criterios de validación necesarios para el entregable). El trabajo de TI se realiza cuando el software satisface los requisitos y cumple con las especificaciones –se ha hecho el aseguramiento y control de calidad apropiados al producto software, su verificación. Entonces sabemos quién es culpable de no alcanzar los resultados esperados por el negocio ¿verdad?

Una real buena práctica implica identificar al real sponsor del proyecto. Me refiero no al que ha sido nombrado (otra ‘buena práctica’), sino al que le interesa el éxito del proyecto porque su reputación está en juego y actúa en beneficio del negocio, y no asume el encargo sólo por intereses personales. Otra es designar correctamente a alguien realmente encargado de realizar las validaciones oportunas, correctas y apropiadas.

Insistir en un retorno de inversión de la plataforma actual al instaurar la buena práctica del gobierno de TI es también una perjudicial para los proyectos donde la tecnología puede ayudar a los departamentos de negocios a ofrecer mejores resultados más rápido, o para aquellos proyectos que buscan ayudar a impulsar la satisfacción del cliente.

No podemos discutir que estos proyectos son críticos, por lo que una real buena práctica es que se necesita establecer correctamente los casos de negocio oportunos, necesarios y apropiados, y la organización debe implementar los cambios que sean identificados con prontitud.

El aumento de la eficacia de la misión y la eficiencia operativa son beneficios clave que se pueden lograr con el cloud computing. Recordemos la definición del NIST. Pero aplicar una estrategia al respecto es otra cosa, considerando por supuesto la seguridad en la nube. Tomamos como buena práctica la mera adopción de una solución comercial enfocada en IaaS, PaaS o SaaS. Sí hay orientaciones al respecto, pero dependerá de cada organización su definición y el éxito de su implementación ya que se deberá mantener las evaluaciones tecnológicas y las inversiones alineadas con las estrategias empresariales. Es una buena práctica reutilizar el recurso humano (exigirle más, por decirlo amablemente), pero debemos considerar que, probablemente, se requiera una reorganización de la organización de TI para ofrecer mayor agilidad empresarial y soporte a iniciativas empresariales clave.

Es una real buena práctica recordar que el ser humano es adaptable pero no es una máquina multitarea y tiene dignidad. Entonces conviene planificar –una buena práctica que muchas veces olvidamos por las presiones del mercado. Una buena planificación es muy importante porque en ella establecemos roles, responsabilidades, alcance del modelo de despliegue y servicios a emplear o entregar, controles, aspectos de diseño y de operación (que seguramente será necesario afinar), cumplimiento regulatorio y legal, integración de tecnología legacy con la nueva, cargas de trabajo, procesos establecidos, exposición al riesgo o apetito de riesgo, sponsor (real), ámbito de influencia, gobernabilidad, plazos, presupuestos, valor real para el negocio considerando las inversiones con base en su estrategia de negocio digital, entre otros muchos factores a considerar.  Otra real buena práctica es que todos los proyectos que se lancen deberían estar totalmente equipados, con “personal completo”, lo que significa que el proyecto nunca esperará a que un miembro del equipo esté disponible para trabajar en él.

Una buena práctica es emplear métodos ágiles, pero el pretender combinarla con la premisa de abaratar costos ya no lo es. La combinación es factible pero complicada en su control y gestión, y hasta contraproducente en cuanto a resultados esperados. Esto sólo si hablamos de contar con recursos y capacidades internas al país (on-shore); sin hablar de los recursos y capacidades que podrían verse interesantes fuera del país (off-shore).

Una real buena práctica es realizar una apropiada planificación tras reconocer que están implicados diferentes aspectos, no sólo el costo del recurso humano con el perfil adecuado, sino los costos de la tecnología a emplear y los mecanismos de seguridad necesarios, así como aspectos de locación, demográficos, culturares, idiomáticos, entre muchos otros.

Gestión de proyectos en la gestión pública

Ya antes habíamos comentado sobre los proyectos fallidos.

De hecho, mucho se habla hoy sobre este tema de que en la gestión pública se deben gestionar proyectos o, al menos, de que deberíamos emplear técnicas de gestión de proyectos en la gestión pública.

Interesante propuesta, e ideal desde todo punto de vista, pero ¿y la acción?

Hace un tiempo se pretendió utilizar una herramienta para gestionar proyectos en una entidad del estado. Obviamente esta iniciativa fracasó. Los motivos fueron, entre otros, pero no limitados a, la expectativa de alcanzar los beneficios siempre promulgados por una eficiente gestión de proyectos, además de una pronta toma de decisiones informada, pero sin tener en cuenta las restricciones y plazos de ley para ciertas actividades, las ocurrencias producto de una deficiente formulación de los expedientes técnicos, y formalismos establecidos, pero no estandarizados, de los diferentes actores. Hay aquí una relación e integración interesante de gobierno, riesgos, y cumplimiento, y se comprueba que todo proyecto debe ser continuamente monitorizado para validar que se mantiene entregando el valor esperado.

El gerente general deseaba conocer realmente el portafolio de proyectos de la institución. Deseaba dejar un portafolio de proyectos ordenado, organizado, y controlado. En la fecha de la presentación oficial del producto desarrollado, se dio cuenta este gerente que no iba a inaugurar una determinada obra -estratégica- durante su vigencia en el cargo. Los sub-gerentes se excusaron, adujeron carencia de información oportuna, apareció un sin número de actividades extra, y atacaron el producto. El ejercicio sirvió al gerente para tomar una decisión referente a la inauguración, y para corroborar, según él, que efectivamente no se le informaba ni oportuna ni apropiadamente, y que las gerencias no trabajaban en equipo.

El producto no tenía nada de malo. Se había desarrollado en conjunto con el personal asignado como un producto dinámico, de alcance holístico para la tarea. Este dinamismo permitía reducir, lo mejor posible, la incertidumbre y el riesgo[1], pero era necesario dedicarle –constantemente-un tiempo; no es que me pueda limitar horas antes a completar el cuadro, de forma aislada, para presentarlo en la fecha prevista, apoyándome en “mi experiencia pasada”. El alcance era holístico por cuanto involucraba todas las gerencias, desde la concepción de la idea hasta la inauguración del proyecto una vez terminado. Un problema es que los sub-gerentes lo consideraron un mero plan estático, y no un producto sujeto de continua actualización (¿una de las excusas del momento?). El compromiso de apoyo se dio, puntualmente para el momento y por exigencia del gerente general, atendiendo a únicamente su ámbito de competencia, y falló la comunicación interna, y la continuidad del compromiso (genuino) para las actualizaciones pertinentes y constantes, el sinceramiento de reconocer que se necesita y de adoptar una herramienta de control.

Si lo anterior se corrigiera, entendiendo que se requiere un cambio de real[2] contenido (estructura, procesos de negocios, sistemas de gestión, tecnología, cultura, las propias personas, etc.), seguramente mejoraríamos la calidad de los proyectos y obtendríamos mejores resultados, sobre todo, sostenibles en el tiempo.

[1]       Fuente: http://salineropampliega.com/2014/11/gestion-de-proyectos-en-la-administracion-publica.html

[2]       Fuente: http://salineropampliega.com/2017/02/entrevista-a-akira-bloise-sobre-como-implementar-la-direccion-de-proyectos-en-una-organizacion-12.html

Las limitaciones del ¿qué debo hacer? –o el por qué y qué debo aprender

Hace unos seis años trabajaba como supervisor de la implementación en un proyecto importante para el estado peruano cuyo producto recién en este año está siendo considerado y se busca utilizarlo –bueno, parte del ‘éxito’ es que, aunque su uso había sido declarado obligatorio en esa época, recién se está ejerciendo presión.

En ese entonces la empresa que había sido contratada para la implementación tenía serios problemas. Se observaban deficiencias y se informaban, con oportunidad y suficiencia. Pronto nos dimos cuenta que el “diseñador” de la solución era “responsable” de la implementación; hablo de persona. Lamentablemente, las observaciones no eran levantadas y, el responsable simplemente se sentaba en las reuniones de avance y preguntaba al equipo supervisor “¿qué debo hacer?” Con el cuento de que todos queremos un bien para el Perú, “a pedido” de la gerencia, resolvíamos como cliente los problemas del proveedor. Obviamente hubo retrasos pero ignoro si alguna multa hubo de por medio.

En otra institución, los desarrolladores de software buscaban rápidamente que el líder usuario les indicara qué hacer para comenzar a hacer –menos mal no empezaban a hacer antes de saber qué hacer, como en el cuento. Muchas veces, cuando lo que comenzó a hacerse era entregado, no terminaba siendo lo que se había solicitado. Bueno, esto lo hemos escuchado muchas veces. Una razón es que los requisitos no estuvieron bien definidos y, por ende, los requerimientos tampoco.

En los casos anteriores es evidente que se buscaba un mero cumplimiento, “¿qué debo hacer?”, implicando que la responsabilidad es de otro, no del que recibe el encargo. Luego, el resto es historia, sobre todo cuando las cosas salen mal; alguien se hará cargo; alguien será el títere y otro el titiritero; no es mi culpa, hice lo que me dijeron; entre otras excusas.

Lo verdaderamente malo es que no aprendemos de nuestros errores y, como dicen, quien no conoce su historia, está condenado a repetirla. Aquí viene la segunda parte, por qué debo aprender y, sobre todo, qué debo aprender[1], para evitar repetir errores. Mucho se ha hablado de esto también, pero poco se hace, y poco hacemos –o logramos hacer. El propósito no es sólo tener datos; es usar la información que esos datos nos proporcionan[2]. Se requiere una organización que aprenda[3]. Por el momento tendremos que lidiar con la cultura de la empresa, con el “aquí se hace así” o con el “siempre se ha hecho así”. Pero empecemos el cambio. Yo termino el año con aportes. A pesar del miedo de mis colaboradores, y de otros colaboradores, en el último mes he logrado hacer que, al menos, el área competente evalúe nuevos formatos de procedimientos, y que re-evalúen el contenido de otros procedimientos. Veremos cómo termina esto.

[1]  Fuente: http://theleanthinker.com/2016/11/12/its-what-must-we-learn-not-what-should-we-do/; disponible en dic/2016

[2]  Fuente: http://www.qualitydigest.com/inside/quality-insider-column/two-questions-get-you-nowhere.html; disponible en dic/2016

[3]  Fuente: http://www.qualitydigest.com/inside/quality-insider-article/engine-and-fuel-quality-improvement.html; disponible en dic/2016

Autoservicio de TI

Desplegar tecnología para lograr que los usuarios de ésta se ayuden cuando tienen dificultades con la tecnología (sí, más tecnología para la tecnología) es algo que por mucho tiempo se ha tratado –y en algunos casos esta “innovación” ha funcionado y en otros no; bueno, siempre hay espacio para mejorar.

Los medios de acceso son variados. Existen versiones de respuesta humana o incluso robótica. Las interfaces son cada vez más útiles y usables. Sistemas de información y flujos de trabajo unos más integrados –y útiles- que otros. Actividades unas mejor implementadas que otras, como emisión y renovación de la identificación del usuario, entrenamiento, disponibilidad de opciones tipo push-pull para instalaciones o actualizaciones, ejecución de políticas de retención, solicitudes variadas (provisión de recursos, programación de atenciones, consultas sobre funcionalidad u operación, requerimientos de reparación, de información), entre otras[1]. Todos gozan de una interesante y mayor agilidad, los que entregan (TI tradicionalmente), y los que reciben (siempre el usuario). La experiencia de usuario está garantizada –depende del usuario calificarla.

fig1

Empoderar a los consumidores (usuarios y clientes) de servicios especializados para que ellos mismos se auto atiendan cuando tienen necesidades relacionadas con la tecnología de la información está muy de moda hoy en día[2].

Los usuarios finales obtienen las herramientas que necesitan para maximizar la productividad, tienen acceso a una vasta base de conocimiento[3] –y hasta a información a la que antes no tenían acceso (y no hablo de seguridad sino de alcance, disponibilidad, re-utilización porque esta iniciativa depende de la calidad y cantidad de información disponible y las facilidades disponibles para accederla[4] y generarla, incluso por comunidades de usuarios[5], y las medidas adoptadas para retener su control), y los departamentos de TI reducen la tensión cotidiana de las llamadas que llegan al servicio de atención al cliente[6].

Interesante. Se reducen costos al pasar del “modo bombero” a un estado de eficiencia y efectividad, y se re-enfoca la mesa de servicio a incrementar la satisfacción del cliente o del usuario.

Sí, nada nuevo hasta aquí. Pero, Gartner[7] nos alerta de las generalidades en que hemos incurrido antes, lo cual nos fuerza a sincerar los resultados frente a las expectativas de esta innovación –y preparar un buen caso de negocio primero.

  • El autoservicio de TI reduce costos en el soporte nivel 1 principalmente con relación a las solicitudes varias que ya comentamos. Algunas cosas todavía requerirán una llamada al servicio de TI o la asistencia de un técnico de soporte. Es una mezcla cuyo balance debe ser cuidadosamente considerado con respecto al valor esperado, con el objetivo de no incurrir en gastos innecesarios –aunque suene trillado esto último.
  • El autoservicio de TI requiere cuidado y actualización constante; no es una inversión que se realiza una sola vez y nos olvidamos luego. Es un continuo asegurar que el servicio lo seguimos entregando ‑como área de TI- como fue comprometido, y nuestro “consumidor” lo sigue recibiendo –su apreciación del valor- de forma oportuna, consistente y constante. El conocimiento, hemos mencionado, juega un papel vital y como tal debe ser gestionado apropiadamente para mantener su vigencia y utilidad.
  • Los usuarios finales acudirán a los autoservicios sólo si no tienen alternativa, lo cual dependerá de la estrategia que implemente la organización para su “adopción”, ya que la inclinación a su aceptación potencialmente será variada –tanto como la cultura organizacional, la mentalidad de los usuarios, la brecha generacional, así como los plazos límite que se establezcan.
  • Para una implementación exitosa del autoservicio de TI se requiere de requisitos previos que lo complementen, como un conjunto correctamente seleccionado de herramientas y procesos, adecuados, probados, afinados, y mantenidos, por personas con roles y competencias técnicas apropiadas, que apoyen, por ejemplo: la automatización de las actividades antes enumeradas, entre otras; y a los usuarios en las decisiones que deben tomar y en las tareas que deben realizar. Si se implementa adecuadamente, el autoservicio puede mejorar la satisfacción del cliente, proporcionar análisis de tendencias de incidentes, identificar oportunidades de capacitación, permitir ejecutar escenarios del tipo “que pasa si” para determinar a dónde llegarán las finanzas de la compañía para el trimestre, y consolidar el conocimiento que existe actualmente en los silos en toda la organización de soporte. La retroalimentación obtenida de un piloto o varios] es atractiva –y útil, para identificar la diversidad de información que sea requerida y permitir flexibilidad y agilidad en satisfacerla.
  • Así es, no dejemos de lado la utilidad, usabilidad, garantía, no sólo de los servicios entregados, con base en procesos gestionados y sujetos a una mejora continua, sino también de los medios utilizados para su entrega, como la interface de usuario utilizada –portal bien diseñado, amigable e intuitivo por supuesto, con el que sea fácil pedir ayuda.

Como siempre, una buena venta del valor del servicio ayudará a que los usuarios lo adopten voluntariamente (menor rechazo inicial; servicios conscientes del contexto que conocen su rol, ubicación y equipo[8]; adopción más rápida; disponibilidad de diferentes medios de contacto; apoyo a las aplicaciones actualmente en uso –aunque no hayan sido provistas por el departamento de TI; naturalidad, facilidad y flexibilidad en el procesamiento de solicitudes; compromiso consciente; finalmente interiorización), buscar qué necesitan hacer, qué quisieran hacer y no pueden –aún, qué les ha funcionado, qué les molesta, y otros posibles aspectos a considerar[9] -una mejora continua de funcionalidad y alcances, promocionar lo realizado, buscando cada vez una mayor aceptación. Identificar los temas correctos que ayudarán a los usuarios a ayudarse a sí mismos, toma tiempo y esfuerzo, no olvidemos considerar el costo total de propiedad de la solución integral.

[1]        Fuente: http://www.techrepublic.com/blog/10-things/10-ways-it-can-use-self-service/; disponible en dic/2016

[2]        Fuente: http://www.computerworld.com/article/2500959/enterprise-applications/self-service-it.html; disponible en dic/2016

[3]        Fuente: http://www.servicenow.com/products/express/it-self-service-portal-for-smb.html; disponible en dic/2016

[4]        Fuente: http://whatis.techtarget.com/definition/customer-self-service-CSS; disponible en dic/2016

[5]       Fuente: https://www.atlassian.com/it-unplugged/best-practices-and-trends/technologies-for-self-service-success; disponible en dic/2016

[6]        Fuente: http://www.axiossystems.com/solutions/end-user-self-service; disponible en dic/2016

[7]        Fuente: http://www.gartner.com/newsroom/id/1426813; disponible en dic/2016

[8]        Fuente: http://www.bmc.com/it-solutions/it-self-service.html; disponible en dic/2016

[9]        Fuente: http://www.informationweek.com/strategic-cio/team-building-and-staffing/7-ways-to-avoid-self-service-it-pitfalls/a/d-id/1297292; disponible en dic/2016

Gobierno, riesgo, seguridad [de la información]

“Se requiere mantener la seguridad de la información de la plataforma tecnológica utilizada para proveer los servicios de TI”. Sí, sí, frase trillada –pero, ¿controlamos la seguridad de la información? ¿Qué significa mantener segura nuestra plataforma tecnológica en el creciente y cambiante entorno de las amenazas a las que está expuesta?

Bueno, es el mantra de la seguridad en nuestros días pero, ¿cuánta seguridad es necesaria o apropiada, cuándo aplicarla, en dónde aplicarla, cómo aplicarla, porqué aplicarla, a quién le interesa -o afecta…? [Sí, 6W-2H].

¿La seguridad debería o podría ser implementada por demanda?[1]; implica que las organizaciones de TI cuentan con la flexibilidad de ajustar su postura de seguridad mediante la adición de la funcionalidad que sea necesaria y posible, acorde con las exigencias crecientes y cambiantes de las necesidades del negocio y de los entornos de las amenazas a las que a diario [bueno, bueno, a cada instante -dramático ¿no?] estamos expuestos -o experimentamos. Cualquier ajuste implica monitorizar para evaluar, priorizar y controlar, con la visibilidad necesaria para el negocio. Lo que pueda ser posible de implementar estará en función de la capacidad de adaptación de la organización, para una fácil y rápida implementación –recordemos que el modelo actual de la seguridad es aditivo. Las cada vez cambiantes amenazas seguramente requerirán capacidades avanzadas de seguridad [lo que desde ya es un constante desafío, el contar con defensas que respondan apropiadamente a las actuales amenazas –la dinámica de la seguridad de la información], y estaremos más o menos expuestos por nuestras [posibles] limitadas habilidades de seguridad.

No olvidemos que el costo de un dispositivo móvil robado es nada en comparación con el valor de los datos perdidos[2]. Ya hemos tratado esto varias veces antes. Fatal si el dispositivo es propio [personal] pero si el dispositivo es propiedad de una empresa –en el afán de facilitar la usabilidad (o tal vez la ubicuidad)- deberemos tener cuidado con nuestras acciones al respecto –trabas a la usabilidad- porque está involucrada la intimidad de las personas –la privacidad de los empleados (seguridad de la información de por medio). Así, las organizaciones deberán, entre otras acciones pero no limitadas a las siguientes: implementar la tecnología necesaria [o cuando menos las políticas] para asegurar que los empleados no puedan descargar aplicaciones de repositorios no autorizados o no oficiales -gestión de aplicaciones móviles (MAM); la tecnología apropiada para crear entornos autenticados y cifrados de confianza, para almacenar, utilizar y compartir los datos empresariales –contenedores; buscar aislar los datos corporativos de los datos personales y de cualquier amenaza que pudiera estar presente en el dispositivo móvil – gestión de contenidos móviles (MCM); realizar análisis de reputación de aplicaciones para evaluar y responder a las vulnerabilidades y amenazas de aplicaciones móviles que pudieran poner en peligro los datos de negocios; incluso aplicar políticas de seguridad de aplicaciones móviles basadas en la identidad autenticada del usuario

Tampoco olvidemos los temas referidos a seguridad de la información -¿cumplimiento tal vez?- sobre el paradigma de computación en nube que tratamos antes, como agente disruptivo, paradigma que resumimos en la siguiente figura:

gráficos 01

Fuente: Chuman Zuñe, Freddy; Cárdenas Saldívar, Iván; Cáceres Meza, Jack Daniel. ” Diseño de una nube privada segura para el sector público peruano”. Universidad Tecnológica del Perú. Escuela de Posgrado. 2013.

Este paradigma es también una consideración de riesgo porque ¿cuáles son los objetivos de negocio que la organización espera alcanzar?, ¿cómo encajan estos objetivos dentro de la estrategia global de la organización?, dentro del marco de la seguridad de la información por supuesto. Así, la figura siguiente presenta algunos de los riesgos identificados para la adopción del modelo de computación en nube, y también presenta algunos marcos de trabajo y normas que, correctamente aplicados, nos ayudan a gestionar estos riesgos:

Fuente:          Chuman Zuñe, Freddy; Cárdenas Saldívar, Iván; Cáceres Meza, Jack Daniel. " Diseño de una nube privada segura para el sector público peruano”. Universidad Tecnológica del Perú. Escuela de Posgrado. 2013.

Fuente:          Chuman Zuñe, Freddy; Cárdenas Saldívar, Iván; Cáceres Meza, Jack Daniel. ” Diseño de una nube privada segura para el sector público peruano”. Universidad Tecnológica del Perú. Escuela de Posgrado. 2013.

Muchas organizaciones se esfuerzan por implementar el software, hardware, y servicios que les permitan identificar y reducir los riesgos. Pero pocos involucran a su gente – las mismas personas que crean y utilizar la información que está siendo protegida e incluso la excluyen por desconfianza[3]. Bueno, sabiendo que el nuevo modelo de seguridad tiene cinco dimensiones, a saber:

  1. Enfocar la seguridad de la información en los activos críticos, nucleares –un enfoque basado en riesgos (lo que puede ser difícil para muchas organizaciones) para establecer el “mejor esfuerzo” podría ser más racional.
  2. Proteger los activos clave con varias capas de sistemas de defensa. Asumir que la empresa ya está comprometida (ya sea por los delincuentes cibernéticos, los competidores, o el gobierno – ¿para los paranoicos?), y desarrollar una estrategia en torno a esa suposición. Comprender que hay muchas fuentes de compromiso, no sólo el centro de datos, computadora personal o dispositivo móvil.
  3. Involucrar a las personas que utilizan la información para proteger los activos [de información] con los que trabajan –especialmente el personal ejecutivo y personal operativo que hemos identificado como claves. “Hazlo o no. No intentes”, ¿recuerdan?
  4. Formar equipo con socios comerciales para impulsar su (y sus) sistemas inmunológicos. Porque todo no se puede proteger de la misma manera. Así, habrá que desarrollar una declaración de aplicabilidad –sí, ayuda el 6W-2H, especialmente en este moderno ecosistema digital. De seguro recuerdan estas palabras: “El miedo es el camino hacia el lado oscuro. El miedo lleva a la ira. La ira lleva al odio. El odio lleva al sufrimiento”[4].
  5. Hacer de la seguridad un problema del negocio – no sólo un problema de TI, porque las posibles alternativas de solución no son siempre tecnológicas. Es hora de pensar en un modelo de seguridad holístico, donde se utilizan múltiples tecnologías y técnicas de gestión, con una amplia aceptación de las medidas estratégicas y tácticas a implementar y rendición de cuentas del valor obtenido de esta implementación –entra el gobierno corporativo de TI (COBIT), en capas y adaptado al riesgo [identificado, evaluado (evaluar los datos y sistemas; identificar los riesgos para dichos sistemas; evaluar los riesgos[5] para la probabilidad, gravedad e impacto (las variables no solo han cambiado, sino que se han multiplicado[6]); y la identificación de los controles[7], salvaguardias y medidas correctivas), y gestionado (el residual por supuesto, luego de haber realizado nuestro trabajo previo de mitigación y/o transferencia) –porque conocemos realmente el riesgo[8]] y el valor que han sido estimados. Sin olvidar, claro, que es igual de importante mantener el ojo en los cambios internos a través de la evaluación continua de la política de riesgos, tolerancia al riesgo, y los indicadores clave de riesgo; pruebas de control y de evaluación de resultados; e informar sobre las actividades de garantía, incluida la auditoría interna, gestión de control y cumplimiento[9]. La gestión del riesgo influye en muchas áreas de la compañía. Su correcta aplicación e involucramiento en la empresa permite que la organización sea más flexible, medible y rentable[10].

Surge entonces la necesidad de integrar [para evitar solapamiento de funciones] gobierno corporativo, gestión de riesgos y cumplimiento corporativo, tres pilares que trabajan en conjunto con el fin de garantizar que la organización cumple sus objetivos –obtiene el valor que sus stakeholders esperan (la idea que compraron y los hizo invertir). Recordemos que gobernar (estructuras, políticas, procesos y controles de la dirección y la gerencia ejecutiva[11]) es asegurar unos objetivos (controlar que se logren), en base a la estrategia empresarial acordada, a partir de la administración de unos recursos determinados y manteniendo el riesgo a niveles aceptables[12].

La figura siguiente muestra una base de esta integración –compleja evidentemente[13]. Por supuesto que existen diversas opciones comerciales pero su elección depende de nuestro correcto –y previo- entendimiento de los objetivos del negocio[14]. Para una adecuada implementación es necesario que existan definidas las metas estratégicas, los planes tácticos para alcanzar estas metas, y las actividades operativas necesarias y apropiadas para la realización de dichos planes.

Fuente:          http://www.slideshare.net/jack_caceres/curso-control-de-acceso-y-seguridad-05-gestin-de-riesgos-2

Fuente:          http://www.slideshare.net/jack_caceres/curso-control-de-acceso-y-seguridad-05-gestin-de-riesgos-2

El cumplimiento puede ser complicado (¿no es el actual ambiente de negocios cada vez más complejo y regulado?[15]), así como buscar reducir las pérdidas y mejorar la toma de decisiones[16], considerando los riesgos planteados en la figura anterior, además de la ciberdelincuencia, las redes sociales, las tecnologías emergentes, los partner o socios de negocio, estrategias más agresivas por parte de los competidores, necesidad de innovación permanente, necesidad de formación continuada y de valor, o disponer de asesoramiento externo experto en múltiples ámbitos, debido al entorno cambiante, mayor gradiente de obsolescencia en los modelos de negocio, entre otros factores a considerar. ISACA nos señala que la seguridad de la información es un componente central en el modelo GRC[17]. La siguiente figura muestra los factores que han propiciado la aparición de la GRC:

Motivos-GRC

La OCEG nos proporciona en la siguiente figura una vista de componentes del Modelo de Capacidad de GRC que esta promulga.

gráficos04

Cada Elemento que se muestra incluye un análisis de los controles y acciones de gestión y aborda consideraciones del diseño y la implementación. Los Elementos definen los aspectos centrales de las capacidades efectivas y pueden servir como un punto de arranque para la evaluación del estado actual del enfoque de una organización. Los Elementos pueden ser aplicados en todos los niveles de la organización para direccionar objetivos empresariales, capacidades departamentales o acciones o controles en áreas críticas. ¿Le son interesantes los elementos considerados? Yo creo que sí.

[1]       Fuente: http://resources.idgenterprise.com/original/AST-0165708_Level3QuickPulse.pdf; disponible en julio/2016

[2]       Fuente: http://searchdatacenter.techtarget.com/es/cronica/Cinco-formas-de-impulsar-la-seguridad-de-aplicaciones-moviles?utm_medium=EM&asrc=EM_EDA_60596204&utm_campaign=20160711_Cinco%20formas%20para%20impulsar%20la%20seguridad%20de%20las%20apps%20m%C3%B3viles_&utm_source=EDA; disponible en julio/2016

[3]       Fuente: http://core0.staticworld.net/assets/media-resource/17273/infoworld-new-security.pdf; disponible en julio/2016

[4]       Fuente: http://www.govinfosecurity.com/blogs/7-star-wars-day-cybersecurity-lessons-p-2121?rf=2016-05-05-eg&mkt_tok=eyJpIjoiTkdVME9HWTJaRFZpTW1ZeiIsInQiOiI2NUNwMGZqQnhuaUpzaU1udTNPT0xiU2NcL1ZMSk5MSEJrTlZQUklBYlBGZFduUmZwSHgydW9RZ1RIYjV4ZVZNcFJQRHlIRlBqb1d6UG1WN1VCK052YVZsbkZZUVdnQVlVbmNGYnJleEc2WkU9In0%3D; disponible en julio/2016

[5]       Fuente: http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-30r1.pdf; disponible en julio/2016

[6]       Fuente: http://www.pwc.es/es/soluciones/auditoria/grc-suite.html; disponible en julio/2016

[7]       Fuente: http://www.sans.edu/research/security-laboratory/article/security-controls; disponible en julio/2016

[8]       Fuente: http://www.cio.com/article/3065048/security/how-to-perform-a-risk-assessment.html?token=%23tk.CIONLE_nlt_cio_security_2016-05-06&idg_eid=0f3e0907b81179ebb4f3b209b6424bae&utm_source=Sailthru&utm_medium=email&utm_campaign=CIO%20Security%202016-05-06&utm_term=cio_security#tk.CIO_nlt_cio_security_2016-05-06; disponible en julio/2016

[9]       Fuente: http://www.oceg.org/resources/building-blocks-grc/; disponible en julio/2016

[10]     Fuente: http://www.deloitte.com.mx/agrc/grc.htm; disponible en julio/2016

[11]     Fuente; http://www2.deloitte.com/content/dam/Deloitte/mx/Documents/risk/mx(es-mx)ServiciosGRC.pdf; disponible en julio/2016

[12]     Fuente: http://www.aspectosprofesionales.info/2014/08/la-responsabilidad-penal-corporativa-el.html; disponible en julio/2016

[13]     Fuente: http://searchdatacenter.techtarget.com/es/definicion/Software-de-GRC-gobernanza-gestion-de-riesgos-y-cumplimiento; disponible en julio/2016

[14]     Fuente: http://searchdatacenter.techtarget.com/es/cronica/La-seleccion-de-herramientas-de-GRC-comienza-entendiendo-los-objetivos-de-negocio; disponible en julio/2016

[15]     Fuente: http://www.epicor.com/lac/solutions/enterprise-risk-management.aspx; disponible en julio/2016

[16]     Fuente: https://www-01.ibm.com/software/es/analytics/rte/an/risk-compliance/; disponible en julio/2016

[17]     Fuente: http://www.isaca.org/chapters7/Monterrey/Events/Documents/20101206%20Uniendo%20al%20Gobierno%20(GRC).pdf; disponible en julio/2016

Algo sobre analytics

El diccionario Webster Revised Unabridged define analytics como “la ciencia del análisis” y análisis como “el trazado de cosas hasta su fuente, y la resolución de conocimiento en sus principios originales“.

Desde una perspectiva de negocios, estas definiciones implican que analítico es comprender las causas raíz de los eventos y condiciones del negocio. El clásico error es adquirir/desarrollar herramientas que son demasiado complejas para los usuarios casuales pero no lo suficientemente sofisticadas para los usuarios de peso.

MINEDU: Proyecto NEO

El objetivo principal del Proyecto NEO es normar la estructura de operatividad del Área de Calidad de la OFICINA DE INFORMÁTICA (OFIN) DEL MINISTERIO DE EDUCACIÓN (MINEDU).

  1. Acta de constitución del Proyecto NEO
  2. Plan de gestión del Proyecto NEO
  3. Proceso Verificación de la calidad y seguridad del producto software

Más en el marco de la computación en nube -cloudcomputing

Más en el marco de la computación en nube -cloudcomputing

Otro interesante artículo sobre el tema del cloud computing donde Forbes, Líderes de Negocios del Mundo, como indican en su página Web, nos dice que el departamento de TI ha sido completamente puesto de lado en el ámbito de las tecnologías de automatización de mercadeo. Para el modelo SaaS, las necesidades de integración y cooperación entre diferentes soluciones, sin dejar de lado los hábitos de compra de los depaen el marco de la computación en nube -cloudcomputingrtamentos de mercadeo, son factores determinantes para esto. Aquí hablamos del intercambio fluido de datos entre las soluciones empleadas, de ida y vuelta, considerando los diferentes proveedores; bueno, entre algunos proveedores por el momento.

Según el artículo, todo lo anterior ocurre a tal punto que la tecnología se asemeja más la tecnología de consumo que a las tradicionales aplicaciones de negocio. Los usuarios de mercadeo que no son técnicos pueden hacer de forma fácil que el software haga lo que ellos desean que haga.

El problema será que, posiblemente, los departamentos de TI tengan que, en algún momento, entretejer diferentes soluciones para lograr los objetivos del negocio. Bueno, de hecho, en el artículo acompañante, Forbes nos dice en este artículo que por años los gerentes de informática han tenido que elegir entre las mejores aplicaciones de su clase que se enfocaban en resolver un problema y colecciones combinadas de muchas aplicaciones construidas para trabajar juntas. Lo anterior es cierto porque en los negocios existen muchas variaciones (producto, industria, tamaño de la empresa, cultura e idiosincrasia) y probablemente no se cuente con una única solución que satisfaga cada necesidad. Consideremos que cada solución puede, incluso, ser utilizada de forma diferente. ¿Cuál será el eje central? ese mismo, los datos; ¿cómo? esa es otra historia. No olvidemos que luego se tiene la responsabilidad de integrar el flujo de procesos a través de aplicaciones e integrar la funcionalidad entre aplicaciones, tales como gestión de identidades, la gestión del rendimiento empresarial y cumplimiento, en diferentes magnitudes, dependiendo de la solución elegida.

11 reglas para la retención efectiva de clientes

(Artículo preparado para difusión interna en la Red Científica Peruana -RCP)

(www.uber-uk.com)

La ciencia de guardar (mantener) a clientes no sólo satisfechos sino leales no es demasiado difícil para un negocio de aún el tamaño más pequeño, pero los proveedores debe acertar en los fundamentos para que una estrategia de lealtad sea eficaz. Esto, desde luego, quiere decir obtener datos actualizados y exactos del cliente para luego utilizarlos inteligentemente con la finalidad de ganar la clase de conocimiento interno necesario para construir una verdadera lealtad de cliente. Por consiguiente, Uber ha compilado su lista de ‘ primeros once’ datos fundamentales de cliente, que son“: Continue reading

Cinco razones para capitalizar en la computación en la nube

Cinco razones para capitalizar en la computación en la nube

(Artículo preparado para difusión interna en la Red Científica Peruana -RCP)

Cinco razones por las que los proveedores de servicio de telecomunicaciones deben capitalizar en la computación en la nube para sus negocios y clientes:

La competencia, presiones de costo, y demanda por servicios y aplicaciones en todo momento y lugar y con cualquier dispositivo están forzando a los proveedores de servicios de telecomunicaciones a considerar modelos alternativos de provisión para adquirir y proporcionar los servicios de TI que demandan los clientes.

El término nube puede ser solo un término de mercadeo para los portadores y no una oferta real de producto. El la palabrita de moda utilizada en el mercadeo actual. Podremos terminar llamando a la computación en la nube de otra forma. Continue reading