Estamos en directo

Mi compañero de fatigas, Javier Peris, tiene un programa de radio que emite desde Valencia los Domingos de 22:00 a 24:00. El nombre del programa es "Tecnología y Sentido Común".

----------------------------------

My fellow, Javier Peris, has a radio program that is broadcast from Valencia on Sundays from 22:00 to 24:00. The program name is "Technology and Common Sense".

Estamos en directo

Master en Ciencias Políticas IX

Esta semana se publicaban algunas conversaciones sobre la trama "Púnica", aparte de los papeles de Panamá, y otras historias para no dormir.

Siguiendo con la serie sobre "Master en Ciencias Políticas", ayer se me ocurrió este dibujo.

-----------------------------------------

This week we have heard some conversations about the "Púnica" plot apart from Panama papers, and other stories.

Continuing with the series of "Master in Political Science", yesterday I thought in this drawing.

Master en Ciencias Políticas IX

Cuestión de experiencia

Ayer arrancaba el Congreso de itsmf con esta gran verdad. La experiencia no sólo añade conocimiento, sino un montón de años.

-----------------------------------------------

Yesterday started the itSMF Congress with this great truth. The experience not only adds knowledge, but a lot of years.

Cuestión de experiencia

Alinear TI con el negocio

Desde tiempos inmemorables, hemos oído la frase “Alinear TI con el negocio”, como una de las máximas de los marcos de referencia utilizados en los departamentos de sistemas.

Estos estándares nos decían que TI tenía que alinearse con el negocio, para poder ofrecer una mejor gestión de los servicios.

---------------------------------------

Since immemorial time, we have heard the sentence "Aligning IT with the business" as one of the points of the frameworks used in IT departments

These standards were saying we had to align IT with the business, to provide better service management.

------------------------------------

Sinceramente, a mí me parece que la frase está obsoleta. Si analizamos la frase, yo entiendo que un negocio define una estrategia, y una vez que esa estrategia es comunicada internamente a la compañía, el departamento de TI la estudia para alinear sus servicios con las necesidades del negocio. ¿No os parece alejado de lo que debería ser?

Yo creo que el departamento de TI, debe formar parte de ese grupo de personas que definen esa estrategia, de tal forma que cuando es comunicada internamente, ya no hace falta que TI se alinee con dicha estrategia, porque ha participado en su propia definición, es decir hemos pasado a la frase “TI está integrado con el negocio”. Ya no somos un ente separado.

Es otra de las evoluciones que debemos incorporara a la hora de analizar los estándares actuales, y adaptarlos a las nuevas necesidades “ágiles” del negocio.

Pero por otro lado, también tenemos que hablar del “alineamiento consigo mismo”, y con esto me refiero, a la conexión extremo a extremo, dentro de TI, es decir, integrar, que no alinear, las diferentes áreas de TI, desarrollo y operaciones.

Durante años hemos vivido esa rivalidad dentro del departamento de sistemas, donde parecía que desarrollo y operaciones eran empresas diferentes. Seguro que todos conocemos compañías donde estos departamentos, llegaban a trabajar en edificios separados. ¿Cómo es posible un entendimiento, bajo esta premisa?

Nuevos métodos como DevOps, exponen la necesidad, ya no de trabajar en colaboración, sino en estar integrados desde el inicio en los mismos proyectos. Intentar que no nos comportemos como dos entes independientes, sino como uno sólo, con un solo objetivo.

En los marcos de referencia, en los que hemos trabajado durante años, había una “frontera” entre ambas áreas, y así podíamos utilizar marcos de desarrollo, o marcos de operaciones. Es el momento de adaptar esos modelos, para que sirvan a los nuevos propósitos que nos tenemos que marcar. Trabajar en conjunto para poder aportar la mejor gestión de servicios, extremo a extremo, dentro de nuestras organizaciones, y así poder apoyar las nuevas necesidades del negocio.

Alinear TI con el negocio

Seguridad versus agilidad

La gestión de la seguridad es uno de los procesos que podemos encontrar en la mayoría de metodologías. Sin embargo el grado de importancia que se ha ido dando a este proceso ha ido variando a lo largo del tiempo.

-----------------------------------------

The security management is one of the processes that can be found in most of methodologies. However, the level of importance that has been given to this process has been changing over the time.

------------------------------------

Si nos acordamos de la versión 2 de la metodología que más hablamos, la seguridad se encontraba dentro de otro proceso (el de disponibilidad), y no tenía entidad suficiente para ser un proceso independiente. Por aquel entonces la seguridad se basaba únicamente en tres conceptos

•           Confidencialidad
•           Integridad
•           Disponibilidad

Sin duda los tres son de vital importancia, pero claramente no son suficientes para una buena gestión de la seguridad.

De hecho en la versión 3, se convirtió en un proceso independiente, y nos daba ciertas pautas para mejorar las políticas, sistema gestión, gestión de riesgos, etc. De hecho hay una referencia clara a la ISO correspondiente, como mejor forma de gestionar la seguridad.

Y una vez que hemos contado un poco de historia, ahora toca reflexionar cómo podemos agilizar el proceso de seguridad, si fuera posible, y en qué medida debemos manejar el equilibrio entre seguridad y agilidad.

Para un paranoico como yo, creo que no hay equilibrio. La seguridad puede agilizarse a través de automatismos, pero nunca reducirla para tratar de hacerla “ágil”. De hecho, en mi opinión, debe potenciarse, dado que cada vez más, la seguridad se está convirtiendo en el caballo de batalla (o de Troya).

En las normas clásicas hablamos de seguridad, pero cuando se escribieron, prácticamente no había smartphones, lo mismo ocurría con las App’s. No existían los smartwatches, no se habían inventado los wearables, ni se hablaba del Internet de las cosas. Es decir, nada relativo a la ciberseguridad.

Normas actuales como PCI DSS, obligan a realizar hacking éticos de forma periódica, a realizar escaneos de red. Normas no escritas recomiendan tener algún soporte para analizar la Darkweb, y ver que se dice de nosotros. Tener un SOC externo, que realice estas tareas, puede ser altamente recomendables. Etc.

La seguridad es un proceso que tiene que estar presente en todos los proyectos desde el inicio, para que puedan tenerse en cuenta las necesidades desde el primer momento, y no encontrarnos con sorpresas de última hora.

Concienciar a nuestros usuarios, e incluso a nuestros clientes, puede ser muy útil para evitar infecciones de malware.

Ya se sabe que sólo hay dos tipos de empresas. Las que son atacadas, y las que no son conscientes de que están siendo atacadas. Ahora nos toca posicionarnos en una de las dos.

Aligerar los controles para ser más ágiles, puede repercutir en consecuencias graves, así que en mi opinión, este proceso debe estar vivo cada día, incorporando nuevos controles, aún a riesgo de ralentizar el proceso en sí, y no esperar a una nueva versión que puede llegar entre tres y cinco años.

Los datos son la nueva moneda de este siglo, y hay que mantenerlos a buen recaudo y custodiados, así que aquí lo dejo con una pregunta.

¿Estás seguro que estás seguro?

Seguridad versus agilidad

Día del libro 2016

Hoy es el día del libro. Estos días (ayer y hoy), se celebra el aniversario de la muerte de dos grandes escritores, Cervantes y Shakespeare.

Creo que se merecen un homenaje

-------------------------------------

Today is the World Book Day. These days (yesterday and today), is the anniversary of the death of two great writers, Cervantes and Shakespeare.

I think they deserve a tribute

Día del libro 2016

Gestión Financiera Ágil

Hoy me he propuesto reflexionar en voz alta sobre el proceso de Gestión Financiera, y cuestionarme algunas de las tareas que se realizan, para tratar de agilizarlo.

Sin entrar en mucho detalle, voy a centrarme en los tres grandes bloques que ya veíamos en las metodologías de hace 10 años, y que en algunos casos fueron modificadas o incluso eliminadas posteriormente en algún estándar internacional.

------------------------------------------------

Today I plan to think aloud about the financial management process and questioning some of the tasks that are work with and try to make them agile.

Without going into much detail, I will focus on three main blocks already saw in the methodologies of 10 years, and in some cases were modified or even eliminated later in some international standard.

-----------------------------------

Como podréis ver, intento no poner nombres de metodologías ni estándares, aunque según vaya entrando en harina, sabréis a que me refiero, eso, si no lo sabéis ya.

Recuerdo que hace una década (o algo más), hablábamos de tres grandes bloques dentro de este proceso.

1.  Presupuestación.
2.   Contabilidad.
3.  Facturación.

El primer punto, la presupuestación, creo que es una tarea que debemos mantener. TI es quién conoce qué necesitamos y cuándo lo necesitamos, y por lo tanto tiene que tener un plan a tres o cinco años, que le ayude a preparar los presupuestos anuales de forma coherente.

Aquí hay que tener en cuenta que no todo se basa en nuestras previsiones sino que hay otros parámetros que entran en acción y que tendremos que ayudar a valorar.

•          Necesidades por cambios legales.
•          Necesidades por temas relativos a la seguridad.

Nuestras previsiones podrán prever las necesidades por obsolescencia, que es algo que podemos planificar con tiempo.

•          Bien porque se ha llegado al límite de su vida útil.
•          Bien porque se ha llegado al fin del soporte del fabricante (hw o sw).

Con todo esto podremos planificar nuestros costes de inversión, y nuestros gastos asociados.

El segundo punto, la contabilidad, es algo que empiezo a replantearme desde cero.

¿No estaremos haciendo un trabajo que debe ser realizado por otros departamentos?

¿No estaremos en algunos casos haciendo un trabajo doble a nivel corporativo?

¿No estaremos basándonos en unas premisas que nos dice nuestra metodología, y que quizás no sea la misma que la compañía realiza a nivel corporativo?

Si hablamos de empresas pequeñas, claramente no tiene sentido. Al final hay una cuenta común de gastos, porque no hay departamentos claros donde imputar.

Si hablamos de empresas grandes, en algunos casos es tan tremendo el follón de separar estos conceptos para imputar a cada área, que muchas veces nos cuesta más el collar que el perro, y estaremos incurriendo en un gasto que no tiene retorno a nivel corporativo. Eso sí, tendremos un control absoluto de quién gasta qué. Pero claro, si queremos ser ágiles y enfocarnos al cliente, me van a perdonar Ustedes que les diga que al cliente esto le importa un pimiento.

Por lo tanto, y en mi modesta opinión lo quitaría, aunque esto cree polémica y un debate que espero sea fructífero.

El tercer punto, la facturación, claramente no ha lugar, desde mi punto de vista, porque si elimino el punto anterior, nunca podré llegar a este.

De hecho, como bien sabéis esta tarea ya se quitó en un estándar internacional que acaba en 20000.

Del resto de conceptos que están dentro de este proceso, de momento no los voy a tratar. Como ya dije la semana pasada intentaremos agilizar aquellas tareas que entendamos que no aportan un valor añadido al cliente, y estas que he comentado hoy, son las primeras que me han venido a la cabeza.

Otro día que tenga ganas de estrujarme mi materia gris, seguro que doy otro repaso.

Gestión Financiera Ágil