Continuidad de negocio. What the "FAQ"?


Llamémoslo "continuidad de negocio", "recuperación de desastres", "gestión de continuidad operacional", "preparación de emergencias", "disaster recovery", "business continuity", "resiliency planning", "business recovery", "emergency management", "continuity programs", ... y, por supuesto, todas las combinaciones intermedias. Todo ello aderezado con un buen número de acrónimos del tipo: BCP, BCM, DRP, CM, BIA, IR, ...

Entre el material que uso para dar formación sobre BCP tengo una "slide" muy bonita (está mal que yo lo diga) para resumir la respuesta de una organización ante un desastre. Así que he pensado colgar aquí una versión resumida (más gráfica) de la mencionada slide y comentar una serie de cuestiones recurrentes (FAQ) que aparecen siempre que presentamos un plan de continuidad (BCP o "business continuity plan").

Mi FAQ particular sobre BCP es el siguiente decálogo de 10 puntos (casualmente):
  • Los desastres son, por definición, imprevistos y difícilmente repetibles. Es difícil preparar un desastre concreto porque no se suelen anunciar y no se repiten frecuentemente. "No podemos quemar un rascacielos todos los sábados por la tarde para garantizar que la organización está entrenada ante esta situación".
  • El comité de crisis debe tomar el control de la situación lo antes posible. Toda la información sobre el incidente debe llegar al "puesto de mando" (o "torre de control"), todas las decisiones sobre el incidente deben salir del "puesto de mando" y todas las comunicaciones hacia el exterior deben ser supervisadas por el comité de crisis. "En resumen, el comité de crisis se come el marrón del desastre".
  • El objetivo principal del comité de crisis es recuperar la actividad de la empresa lo antes posible. Estrictamente hablando, el objetivo es recuperar el nivel de servicio de la organización. 
  • Son objetivos secundarios del comité de crisis: evitar crisis de reputación, aminorar el impacto en clientes y proveedores, controlar los costes económicos y organizativos de la crisis. Importante tener en cuenta que estos objetivos secundarios son, eso, menos importantes que el objetivo principal.
  • Durante el funcionamiento en contingencia la actividad debe ser percibida como "normal" desde el exterior (clientes, proveedores, etc.). El cliente debe percibir que recibe la atención habitual, aunque "es normal que los empleados estén jodidos durante la contingencia: cambio de ubicación, falta de comodidades, limitación de espacio, recursos, etc".
  • La vuelta a la normalidad no significa, necesariamente, volver a la situación anterior al desastre. No siempre, pero es habitual que durante la recuperación de la actividad se aproveche para optimizar procesos, actualizar plataformas tecnológicas, etc. "No es realista construir otra torre igual de grande, igual de obsoleta e igual de insegura en el mismo sitio para poder afirmar que se ha vuelto a la normalidad". 
  • "Wait and see" (esperar y ver) es siempre una opción. Todos los procesos imprevistos que requieren tomar una decisión admiten, de alguna manera, aplazar la decisión. Lo correcto, sin embargo, suele ser empezar a hacer lo que haya que hacer lo antes posible. "A nadie le dieron nunca una medalla por no hacer nada. En general, no hacer nada significa que si aciertas nadie te lo agradece y si fallas te vas a comer el marrón tú solo".
  • Todas las acciones del comité de crisis deben ser comunicadas. No sirve para nada tomar decisiones si no se comunican. "Los miembros del comité no suelen caracterizarse por ejecutar sus propias decisiones directamente, así que, al menos, necesitan comunicar sus decisiones para que alguien las ejecute".
  • El comité de crisis debe estar activo 24x7 hasta que se restablezca el funcionamiento normal de la organización. Siempre es posible utilizar algún mecanismo de turnos, atención "on call", ampliar el comité con nuevos miembros, etc. "En última instancia, este requisito es un incentivo para resolver la crisis lo antes posible".
  • La respuesta al desastre termina cuando, una vez restablecida la operación normal, se presenta un informe "post mortem" del incidente. El informe debe incluir: auditoria de los gastos incurridos durante el desastre y la recuperación, impacto en los clientes, valoración de la comunicación interna y externa durante la crisis, etc. "Es muy habitual incurrir en gastos no justificados o injustificables durante una crisis. También es, de alguna manera, inevitable".
Y éste es mi decálogo. medio irónico medio serio.

<Continuidad de negocio. What the FAQ? />

Hola, me llamo Javier Tobal y he comprado un billete en la web de Renfe

"Hola, me llamo Javier Tobal y he comprado un billete en la web de Renfe". Esto no debería ser noticia, pero esta vez me fijé en un detalle que me había pasado desapercibido anteriormente o, tal vez, sea una "mejora" introducida recientemente.


La cuestión es que Renfe ha implementado un mecanismo de autocompletar para algunos campos: población, calle y, también y sorprendentemente, para los campos nombre y apellidos!!! Esto me dejó anonadado, desconcertado y, como se puede ver en mi tuit, contrariado.

Las principales "pegas" que le pongo a esta funcionalidad:
  • El nombre es un valor único, personal. ¿qué sentido tiene que una aplicación informática me dé a elegir el nombre entre una lista de posibles nombres?
  • Todo el mundo sabe escribir su nombre. Hasta mi hijo de 3 años lo hace.
  • No hay nombres más importantes que otros. Me imagino al señor "Rodrigues" preguntando "¿por qué me debería apellidar "Rodríguez"?
  • La web de Renfe reconoce mi apellido (sorprendente) pero me lo cambia por "Tobalina" cuando pulso el tabulador. Esto pasa porque el autocompletar está ordenado por frecuencia del nombre y selecciona el primero de la lista. 

Pero lo que al principio parecía peor, o al menos más heterodoxo, es que los datos (nombres o apellidos) parecían extraerse de la base de datos de clientes. Sólo así se explicaría que aparecieran apellidos aparentemente raros y no aparecieran otros más populares. En mi caso, tengo un nombre muy común (300.000 en España) y un apellido relativamente raro (500 en España) pero Renfe conoce ambos. Hice unas pruebas manuales buscando un caso que confirmara mi teoría.



Y como así no conseguí nada concluyente, busqué la manera de automatizar esta investigación. Al final, la web usa un método en el servidor llamado "nombresManagerAjax.getNombresFrecuentes.dwr" que devuelve la lista de elementos para el autocompletar.

Aquí se ve cómo funciona:
Remote Address:213.144.49.57:443
Request URL:https://venta.renfe.com/vol/dwr/call/plaincall/nombresManagerAjax.getNombresFrecuentes.dwr
Request Method:POST
Status Code:200 OK

Request Headers
Accept:*/*
Accept-Encoding:gzip,deflate,sdch
Accept-Language:es,en-US;q=0.8,en;q=0.6
Connection:keep-alive
Content-Length:270
Content-Type:text/plain
Cookie:tipoUsuario=N; url_logout=/vol/index.do; tipoUsuario=N; org.springframework.web.servlet.i18n.CookieLocaleResolver.LOCALE=es_ES; __g_u=202999812043209_0; JSESSIONID=0000C560QoOyAIi2PyCr_modONr:16dv7ekdi; __g_c=a%3A1%7Cb%3A3; s_cc=true; s_sq=%5B%5BB%5D%5D; s_fid=38BB206B580BA00C-03798198EB657DDB; s_nr=1401562262384-Repeat; gpv_p6=Venta%3ARegistro%20Cliente
Host:venta.renfe.com
Origin:https://venta.renfe.com
Referer:https://venta.renfe.com/vol/datosComprador.do
User-Agent:Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.114 Safari/537.36

Request Payload
callCount=1
page=/vol/datosComprador.do
httpSessionId=0000C560QoOyAIi2PyCr_modONr:16dv7ekdi
scriptSessionId=C93936BC746559589B085F596EBEA0E1804
c0-scriptName=nombresManagerAjax
c0-methodName=getNombresFrecuentes
c0-id=0
c0-param0=string:EIL
c0-param1=string:
batchId=75

Response
Connection:Keep-Alive
Content-Language:es-ES
Content-Length:131
Content-Type:text/javascript;charset=ISO-8859-1
Date:Sat, 31 May 2014 18:53:18 GMT
Keep-Alive:timeout=10, max=98
throw 'allowScriptTagRemoting is false.';
//#DWR-INSERT
//#DWR-REPLY
dwr.engine._remoteHandleCallback('75','0',["EILEEN","EILA"]);
Una vez descubierto cómo se hace la consulta, se podría "machacar" este método para obtener todos los nombres que devuelve el método "getNombresFrecuentes.dwr".
Pero no hizo falta desarrollar ningún script, en seguida se comprueba que lo que apuntaba Alejandro Ramos (@aramosf) en Twitter era la solución. Los programadores de la web de Renfe han cargado las estadísticas del INE de nombres y apellidos más frecuentes en España. En concreto han cogido los nombres y apellidos que tienen una frecuencia superior a 500.

En resumen, aunque no me gusta esta funcionalidad se puede comprobar que los nombres y apellidos no salen de la base de datos de clientes, sino de las estadísticas públicas del INE.


<Hola, me llamo Javier Tobal y he comprado un billete en la web de Renfe />